Re: [ANN] GSL Shell new beta release with anti-gran graphics module

[David Kastrup <dak@...>]

Francesco Abbate <gslshell@gmail.com> writes:

> 2009/12/3 David Kastrup <dak@gnu.org>:
>> And it can't even sensibly deal with multiple return values.
>>
>> local x=3
>> fun2(|x| x*x,x)
>>
>> Is this
>> fun2(function(x) return x*x end, x)
>> or
>> fun2(function(x) return x*x, x end)
>> ?
>
> I think you didn't understood the point. The notation
>
> |<args>| <expr>
>
> in meant to replace
>
> function(<args>) return <expr> end
>
> only in the case we have an expression and returned value.

Tell that to Steve.  He proposed

    Also, for 'quoting' an expression so that it can be called in
    another context:

    timer(1000,|| print 'timer finished')

which does not really worry about expression and returned value.  That
may not have been _your_ intent, but you can bet that people will use it
like that because it is sooooo convenient.

The unsuspecting reader will think about some logical or here.  I just
don't think that Lua is the right language for people who find writing
in line noise elegant.

Anyway, functions in Lua can return more than one value.  So you are
trying to propose a syntax that can only be used for _some_ anonymous
Lua functions, not in general.  And that means that we have not just
syntactical sugar, but different semantics.

> As you should know, in Lua, a comma separated list of expression is
> *not* an expression so there is no ambiguity whatsoever.
>
> I repeat it:
> - the comma ',' is *not* an operator in Lua
> - a comma separated list of expression is *not* an expression
>
> so there is no ambiguity. If you want to return multiple values you
> should use the ordinary notation.

Making it different.  And there _still_ is the issue of needing to
introduce an operator precedence.

Is

|x| x or y

the same as

function(x) return x end or y

or

function(x) return x or y end

?

If you say the latter, then you need to extend the precedence hierarchy
of Lua by another level.  There are already 8 levels.

Is this syntax extension worth introducing another precedence level?

-- 
David Kastrup