"?:", "a and b or c" or "iif"

[Michael Vanier]

> From: "Fred L. Drake" <fdrake at cnri.reston.va.us>
> Content-Type: text/plain; charset=us-ascii
> Date: Wed, 26 May 1999 13:08:58 -0400 (EDT)
> Cc: python-list at cwi.nl
> Newsgroups: comp.lang.python
> Reply-To: "Fred L. Drake, Jr." <fdrake at acm.org>
> X-Organization: Corporation for National Research Initiatives
> 
> 
> Michael Vanier writes:
>  > This sounds like another job for bytecodehacks :-)  
> 
>   The bytecode could certainly support such a construct, but ...
> 
>  > I personally detest the ?: operator in C, mainly because people who use it
>  > tend to write fun code like this:
>  > 
>  > a = (b ? (c ? d : (e ? f : g)) : (h ? i : j));
> 
>   *I* never wrote this!  1-)  I agree, this is unreadable, but that's
> not a good reason not to provide a facility to allow something
> semantically equivalent as an expression.

I agree, of course.  I've never been fond of bondage-and-disclipline
languages.  But, for instance, in ML you'd write:

   let a = if b then c else d  (* etc. etc.)

which at least subtly discourages the kind of abuse I showed above.  Of
course, we can't use if/else for this.

> 
>  > If something like this is coded, I *strongly* recommend that it not be an
>  > operator but something like an "iif"-type function.  Of course, to do that,
>  > you need to be able to define functions with lazy evaluation.  THAT
> 
>   By pushing the "laziness" to the function implementing the
> operation, the cost of function calls would increase, possibly
> substantially.  While this would be nice, the fact that an arbitrary
> callable might require either agressive or lazy evaluations of
> arguments (or both!) would mean that using bytecode to implement an ?: 
> equivalent is out of the order (if a function is used for that
> purpose.  It also means that the "laziness" or "agression" of an
> expression's evaluation is not evident at the call site.  I think
> *this* would be a huge mistake.  (Hmm.. it also means that the called
> function could have side-effects that changes the values of the lazily 
> evaluated expressions, as well -- it's looking worse & worse!)
>   I think it really needs to be a syntactic construct to avoid the
> problems I've identified; with syntax, the laziness of an expression
> is explicit.

A couple of points:

1) I would hope that the compiler could recognize the (usual) case where
   none of the arguments are lazily evaluated and generate code that's as
   good as the current python implementation.

2) It is true that it isn't evident from the calling side which arguments
   are lazy and which aren't.  I don't see why this is such a problem;
   could you give an example?  I hate to keep pointing at scheme and lisp,
   but the same argument is levelled against macros in those languages, and
   somehow their users manage to cope.  Even in current python, we don't
   know if an argument is supposed to be an integer or a string, but we
   manage :-)  It is true, though, that having lazy arguments is getting
   very close to having macros (without changing the syntax; thus it's very
   close to what bytecodehacks is doing, although not as general).

I think the larger issue is this: we don't want to saddle python with a lot
of ad-hoc additions to solve minor issues (like ?:,
assignment-in-expressions, etc. etc.) because that makes the language lose
its simplicity that we all like.  Therefore, I think it's best to look for
higher level meta-mechanisms that can provide a whole bunch of different
features that otherwise would require a lot of individual changes.  Of
course, the more powerful the feature, the more prone it is to abuse, so
there's a lot to think about.  But I prefer a few really powerful features
to a lot of not-so-powerful features.  That's a matter of taste, of course.

Mike


> 
> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.	     <fdrake at acm.org>
> Corporation for National Research Initiatives
>