Re: Ternary operator patch

[David Kastrup <dak@...>]

Miles Bader <miles@gnu.org> writes:

> We all know you love a good excuse to froth about C++,

When in doubt, try ad hominem attacks to discredit people with different
opinions.

> but how exactly does this change make the Lua grammar messier?

It introduces ? as a new special character, it overloads the existing
meaning of : with something completely unrelated and does not fit
together with anything already in Lua.  That it does not appear to
conflict all too much is solely due to Lua having kept such constructs
at bay up to now, and I don't think it is a good idea to abandon that
practice.

Operators in Lua tend to be overloadable.  But ? : can't actually be
made into an overloadable operator since it relies on delayed
evaluation.  Calling it ? : suggests that it has similar semantics and
operator priorities as C has, but the priorities in C are much more
fine-grained than that of Lua, to the degree where compilers emit
warnings if you actually make use of them because more likely than not
you are getting them wrong.

It introduces a construct perfectly equivalent to if/then/else into
expressions.  Lua is an imperative language: this tries to fudge
existing control functionality into expressions, inventing a completely
separate syntax not recognizably related.  The long run is to have a
language diverge into one that works mostly self-contained within
expressions, and one equivalent (boring) one that does the same job with
statements.

I prefer my languages to be boring and leave the cleverness to the
programmers.

One of the strengths of Lua is that it does _not_ offer a million
different ways for solving the same task.  So trying to make it more
"functional" by dragging in existing functionality in
expression-internal ways through the back door which one can't get rid
again afterwards is the wrong move in my book.

It would make more sense (if at all) to think about how to change the
syntax in a way that the existing if-then-else-end will do the job of
conditional evaluation in a suitably painless way.  Figuring out a good
way for that would likely get repeat-until and while-do into the mix at
no extra cost rather than having to think about more line-noise
characters to get an in-expression equivalent for those as well.

I think that local variables and assignments do a good job for that in
an imperative language.  If other people disagree, then one should
figure out how to smoother wrap the existing control structures into
expressions rather than make functionally equivalent things that look
utterly different.

-- 
David Kastrup