Re: Short function definition syntax; thoughts on Lua

[David Kastrup <dak@...>]

Doug Rogers <doug.rogers@elbitsystems-us.com> writes:

> Norman Ramsey wrote:
>>  > And other line noise looks like line noise only if you've never seen C.
>> Come on, David---be fair. ...
>> I agree that Lua's goal is not to *maximize* information density.
>> I believe Lua's goal is *appropriate* information density: there
>> should be enough keywords to guide beginners, but for experts, there
>> is not too much syntactic noise.  And I do think that in the case of
>> anonymous functions, Lua's design is out of balance...
>
> I'm with you, Norman. I would love to have a concise form for function
> definition. I've found '|args|expr' to be beautiful and sufficient for
> my experiments with gsl-shell;

gsl-shell is gsl-shell.

> so much so that I miss it when I come back to plain Lua, even when
> writing scripts or larger programs as opposed to an interactive
> shell. If this particular form suffers from ambiguities or surprises
> then perhaps some other form will work.
>
> I can see David's point about adding precedence levels (implicitly or
> not), but clearly there's a balance to be reached. My personal opinion
> is that this syntactic sugar would be nearly as useful as the colon
> operator - possibly more so for me. And I think Lua would remain in
> balance with this feature.
>
> I'm generally not a fan of adding features to Lua.

And this is not a feature.  It is an input transformation from an
insider shorthand to a more obvious form.  That's a downward spiral.

Now you are clamoring for a shorthand for
function (x) return x*x end
The next cry will be for a shorthand for
function (x) if x>0 then return 1 else return 0 end
because it would be soooooo convenient to write
|x| x>0 ? 1 : 0
and so forth and so on.

There is a price for functional line noise syntax in a procedural
language.  You end up completely replicating your control structures
with different syntax for "functional" use.

APL inside of Lua.  I repeat: Lua is a procedural language basing its
control flow on statements, not expressions.  Functional languages have
their own place and style.  If you want a functional language, use a
functional language.

> The good news for you, David, is that the more verbose form will still
> be available.

That's completely irrelevant unless I am not supposed to ever read code
written by other people.

Every "optional" language element needs to be learnt and read and
understood by anybody working with code from others.

I don't think that this kind of syntax fits well with the rest of Lua,
and I'd hate to have to teach beginners what it means exactly.

One major feature of Lua is that you can throw Lua code at unsuspecting
colleagues, and they can figure out what it does.  Line noise style
syntax may be concise, but it does not help people figure out things.

Lua has "and" and "or" instead of "||" and "&&", and that

> But even that might not be true. If 5.2 includes a standard interface
> for token filters, or for the components necessary for Metalua, then
> there will be no more griping about simple syntax mods. We'll just use
> a Lua-only module that provides the syntactic sugar we crave.

With multiple people using multiple incompatible syntactic sugar.

> And along the way I think they were been bitten by the functional
> programming bug.
>
> That bug spreads a good kind of disease! I'm not a believer in the
> mantra that all languages lead to LISP, but I do think that LISP's
> simplicity (more than its proximity to lambda calculus) makes it a
> prime environment in which to determine the *essential* elements of a
> programming paradigm or feature.

So program in LISP.

-- 
David Kastrup