Re: omit parenthesis for functions of zero arguments /customcontrol structures

[David Manura <dm.lua@...>]

Julien Hamaide <julien.hamaide <at> elsewhere-entertainment.com> writes:
> If a function without parameter is automatically call without ()
Olivier Delannoy wrote:
>It's easyer to type () than rembering names are function call one 
>month or even a week later.

I'm not saying function calls with zero arguments should be allowed to omit
parenthesis.  In some languages this can be done, but in Lua it is generally a
problem:

  x = f()  -- omitting parenthesis would be entirely different
  f        -- but this might be ok

Rather, it is function definitions with zero arguments that might be allowed to
omit parenthesis, in which case the "function" (or "do") keyword is still
required, so I believe there is no ambiguity in meaning:

  f = function print("hello") end  -- expression form
  function f print("hello") end    -- statement form

  function f (g).x(a) end  -- but careful here!

My other suggestion however was that function calls with exactly one argument be
allowed to omit parenthesis.  In fact, Lua already allows that if the argument
is a literal string or table:

  f "hello"
  f {"hello"}

However, it was never clear to me why Lua does not uniformly allow that for all
literal and variable types.  For one thing, the syntax would expand Lua's data
definition capabilities, and it cannot (usually?) be confused with any other
construct:

  f 123
  f x

Some cases may initially seem less obvious, but I think it's clear if function
evaluation is assigned highest precedence and the rules are followed exactly:

  f x y z  -- f(x)(y)(z) not f(x,y,z)?
  f x ()   -- f(x)() not f(x())?
  f x * 2  -- f(x)*2 not f(x*2)?

Those rules may seem unintuitive sometimes:

  print 2 * 3  -- invalid: print(2) * 3 not print(2*3)

But that is just as invalid as the following:

  print "2" .. "3"  -- invalid: print("2") .. "3" not print("2" .. "3")

Bret Victor <bret <at> ugcs.caltech.edu> wrote:
> Lua:  function () return foo + bar end
> Smalltalk:  [ foo + bar ]

Exactly.  There, the value of the last statement is implicitly used as the
return value of the block, so no explicit "return" keyword is needed.  It keeps
simple things simple.  One downside though is that, without care, this type of
thing can lead to ill-defined interfaces where a function that should have no
return value actually does return a value if the last statement evaluates to
something.  In Perl, a recommended way to deal with this is to always explicitly
include a "return" in external functions.

Gavin Wraith <gavin <at> wra1th.plus.com> wrote:
> Permit me to puff RiscLua's brand of mild sugar, requiring
> only a couple of extra lines in llex.c:
> RiscLua: \ () => foo + bar end

Interesting.  I can't say I'm particularly fond of such syntax where the left
side is delimited by various symbols and the right side by the keyword "end"
because it is asymmetric, and "\ () =>" would look like gibberish to the
untrained eye.