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

[David Kastrup <dak@...>]

steve donovan <steve.j.donovan@gmail.com> writes:

> On Thu, Dec 3, 2009 at 11:50 AM, David Kastrup <dak@gnu.org> wrote:
>> function(x) return x*(x-1) end
>
> The notation really shines when you start doing functional things like
> currying:
>
>> div = |x| |y| x/y
>> = div(1)(10)
> 0.1

function div(x) return function(y) return x/y end end
print div(1)(10)

Sorry, but I don't see the point in a notation that saves hardly any
token, but obfuscates what is happening.

> But the real motivation is that it makes using functions like 'map' a
> little more pleasing:
>
> squares = map(|x| x*x, values)

squares = map(function(x) return x*x end, values)

The "little" here is just hiding a closure.

> Also, for 'quoting' an expression so that it can be called in another context:
>
> timer(1000,|| print 'timer finished')

timer(1000,function() print 'timer finished' end)

> Perhaps the issue here is that those two little lines are easy to get
> lost in the otherwise keyword-driven syntax of Lua?

It's just not the Lua style.  It does not tell the tale.  Lua does not
have the C obsession (worse in perl) with having an operator for
everything, requiring priorities in the vast maze of their ilk and
making things undecipherable unless you generously parenthesize, in
which case there is even less amount of saved source code.

This notation is more or less used in Ruby, but it is unclear when you
can use it, what effects it has on scoping, how to nest and so on.

The Lua syntax fits on a single small page.  And that's a very large
benefit not to be thrown away lightly.

"|list| expr" may be well definable as pure syntactic sugar for
function(list) return expr end, but it still needs operator priorities
to establish where expr ends.  Foreigners to the language will not know
how to read this construct, whereas reading the equivalent in current
Lua syntax is immediately comprehensible.

It does not reorder the linear reading order of list and expr, it does
not avoid reevaluation.  It saves very few tokens.  So it has much less
raison d'être than, say, C's ?: operator.

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)
?

-- 
David Kastrup