RE: block return semantic

[Tom Wrensch <Thomas.Wrensch@...>]

Hmm... the statement termination issue could be a real problem. I like not
having required statement termination, but it can cause problems in some
cases. I wonder if there's a general solution based on expression
priorities or some kind of syntactic trick. A nice little research project
for one of my students (* insert maniaical laugh *).

The 'or' trick is nice, and covers about half of the cases where I find an
if-then-else as expression to be useful.

I agree that I would rather extend if-then-else than try to add new
structures to a language like Lua. Its small footprint and relatively
small number of structures is too important to give up to add minor
features.

  - Tom

On Wed, 27 Jun 2001, Reuben Thomas wrote:

> > Could you elaborate on the "all sorts of reasons" for not allowing
> > if-then-else as an expression rather than just a statement?
>
> The sort of thing that's been discussed before: it might be nice, but it
> would have compatibility implications (especially because of Lua's optional
> statement terminators), efficiency implications; it would complicate the
> language &c. This argument has already been had (with me as a proponent of a
> more functional Lua!) on the list a few times.
>
> > is allowed. I find it quite useful for handling default values for
> > uninitialized variables
>
> You can use the "a = f(x) or d" trick for this
>
> > Note that an alternative approach would be to implement a special
> > expression version of if-then-else such as Java's <cond> ? <exp1> :
> > <exp2> form.
>
> I'd prefer a more functional Lua rather than a special case.
>
> --
> http://sc3d.org/rrt/ | Academics age by degrees
>