Mailing List Archive

> > 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: <gvwilson@nevex.com>

> > > > 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 <mzadka@geocities.com>.
INTERNET: Learn what you know.
Share what you don't.

[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).