So I asked Simon Peyton-Jones and Phil Wadler how languages other than C and its derivatives did conditional expressions; one of the replies was: On Mon, 31 Jan 2000, Philip Wadler wrote:
Tony Hoare had a nice ternary `if'. He writes
if c then d else e
as
d <c> e
This satisfies an associative law:
d <c> (e <c> f) = d <c> f = (d <c> e) <c> f
The paper appeared, I think, in CACM circa 1982.
Perhaps this would be a good time to ask around and see what else people have in their back pockets? A-week-of-coding-can-sometimes-save-an-hour-in-the-library'ly yours, Greg
On Mon, 31 Jan 2000, Philip Wadler wrote:
Tony Hoare had a nice ternary `if'. He writes if c then d else e as d <c> e
Ka-Ping Yee writes: Wait -- how the heck is this supposed to parse if 'c' is an arbitrary expression?
Replace '<' and '>' with the symbols of your choice --- embedding the conditional in the middle is still an interesting idea...
I think we've run out of bracket-like thingies. (Yes, that would be the technical term). -- ?!ng
Well, if people are going to spell there names like *that*, it's no wonder we've run out of bracket-like thingies... :-) save-the-punctionally yours Greg
On Mon, 31 Jan 2000 gvwilson@nevex.com wrote:
So I asked Simon Peyton-Jones and Phil Wadler how languages other than C and its derivatives did conditional expressions; one of the replies was:
On Mon, 31 Jan 2000, Philip Wadler wrote:
Tony Hoare had a nice ternary `if'. He writes
if c then d else e
as
d <c> e
Wait -- how the heck is this supposed to parse if 'c' is an arbitrary expression? I think we've run out of bracket-like thingies. (Yes, that would be the technical term). It also looks pretty opaque -- even if you do intuit that it's ternary-select (which i wouldn't if you hadn't told me) it still isn't really obvious which side is which. -- ?!ng
From:
d <c> e Replace '<' and '>' with the symbols of your choice --- embedding the conditional in the middle is still an interesting idea...
Which brings us back to if and else: a = condition ? truecase : falsecase would be a = truecase if condition else falsecase What's unintuitive at this point is the shortcutting, assuming that it would still apply. 'condition' would get evaluated before truecase, and truecase might not get evaluated at all. Still, it 'reads' good to me. Not sure it's all that Pythonic though. --david
On Mon, 31 Jan 2000 gvwilson@nevex.com wrote:
So I asked Simon Peyton-Jones and Phil Wadler how languages other than C and its derivatives did conditional expressions; one of the replies was: <snipped> Perhaps this would be a good time to ask around and see what else people have in their back pockets?
Adding nothing to the discussion, let me just mention how Scheme (my
second favourite language) does it:
(if bool true-result else-result)
Well, of course this isn't relevant to Python because statements are not
expressions, but there might be something in it: if could be also used
as a function taking three arguments:
print if(long_answer, "Very good!", "correct")
I have no idea how this will play with the parser. Anyone?
--
Moshe Zadka
[Moshe Zadka]
... Adding nothing to the discussion, let me just mention how Scheme (my second favourite language) does it:
(if bool true-result else-result)
Well, of course this isn't relevant to Python because statements are not expressions, but there might be something in it: if could be also used as a function taking three arguments:
"if" is a special form in Scheme; all Python functions are strict; short-circuiting is essential here.
print if(long_answer, "Very good!", "correct")
I have no idea how this will play with the parser. Anyone?
if(a, b, c) can't be distiguished from if (a, b, c): before the colon is seen, so it requires more lookahead than Python's parser is comfortable doing.
[Greg Wilson, quoting Philip Wadler]
Tony Hoare had a nice ternary `if'. He writes
if c then d else e
as
d <c> e
Noting that he first wrote "if c then d else e" so it would be *clear* what the heck he was talking about. So that's exactly the point at which Python should stop. After that, it's no longer clear, just formally elegant. I love Haskell too (and thank Philip for that), but it ain't Python.
This satisfies an associative law:
d <c> (e <c> f) = d <c> f = (d <c> e) <c> f
Nobody writes nested ?: using the same condition twice; it's more interesting as an endcase absorption law. Does x <c1> (y <c2> z) = (x <c1> y) <c2> z ? Nope (e.g., suppose c1 is true and c2 is false).
participants (5)
-
David Ascher -
gvwilson＠nevex.com -
Ka-Ping Yee -
Moshe Zadka -
Tim Peters