[Patch] Short lambdas, short methods and DSL-friendly syntactic diet.

[Pierre-Yves Gérardy <pygy79@...>]

The rationale for the patch follows, but let's first check what
changes compared to standard Lua:

* .:(args; body) is a short function. The semi-column after the args
is optional except if the arg list is empty, e.g. .:(... => ...)
* ::(args; body) is a short method. "self" is added as the first
parameter behind the scenes.
* in a short function or method (but not in a regular function):
  - you can optionally use "=>" instead of "return"
  - the "then" token is optional in a "if" block.
* Syntactic aspartame for short functions (and numbers for
consistency), similar to what already exists for strings and tables:

  square 2 --> 4
  {1,2,3,"4"}:map .:(n; if (type(n)=="number") => n*n; else => n; end)
--> {1,4,9,"4"}
  mt ={
    map = ::( callback;
      local tbl={}
      for k,v in pairs(self) do; tbl[k] = callback(v); end
      => setmetatable(tbl, getmetatable(self))
    )
  }
* putting the argument list of a function on the next line doesn't
trigger a syntax error.
* the semi-column is legal before the first statement of a chunk.

49 LOC added, 4 changed 2 removed. It could be made shorter by mixing
body() and shortbody(). That would make the binary slightly lighter at
the expense of more convoluted code (the patch adds 60 bytes to the
binary on Mac OS X x86). The Lua code base is amazingly flexible :-).

Rationale:
---------

These changes are quite extensive, but fairly consistent in my eyes.
I've tried to respect the philosophy of the language.

The semantics of Lua, coupled with tail recursion, are very nice to
write functional code, but the current syntax makes it look clunky.
This patch turns functions into first class citizens in terms of
syntax too.

The syntax relies on the current usage of . and : in function/method
calls and definitions. I had initially chosen " .( " and " :( " or "
.[ " and " :[ ")as opening tokens, but :( made the code look
depressing (tilt your head to the left). It may seem silly, but I
think it's important because the point of syntax is to make the code
enjoyable to read. Furthermore, .:( and ::( are more distinctive
(geometric), and that's another important role of syntax.

The extended syntactic diet allows create neat, "syntaxless" DSLs.

With DSLs in mind, I've also removed the "ambiguous syntax" error,
since there's actually no ambiguity in my eyes. Lua treats carriage
returns as white space, I don't understand the need to make an
exception in this case (but I would love to be know why it is like
that). DSL Example:

keyboard "ingame" :config
    "esc"    :pressed .:( ; goto "menu" )
    "arrows" :held    .:( key, dt; hero:move(key,dt) )
    {" ", "return"}
      :pressed  .:( ; hero:shoot() )
      :held     .:(dt; hero:accumulaEtenergy(dt) )
      :released .:( ; hero:releaseDevastativeBlow() )
() -- this "closes" config() by sending nil to the function returned
by :released(func).

This could of course be done using tables, but I find this cleaner.

Next up are the only cases of the "ambiguous" statements I can think
of. If you want to use such a complex expression at the beginning of a
line, you can prefix it with a semi-column, you'll be safe, even in
vanilla Lua. In order to allow such an expression at the beginning of
a block, I've also allowed a semi-column as the first token in a chunk
(principle of the least surprise). The result is not exactly good
looking, but it's not ugly either, and I don't think that this kind of
construct is used often, anyway.

  ;(someFunc or someOther)
      (foo[fighter], bar[tender], baz[lurhman], last[argument])
-- the carriage return adds some readability to functions with long
name or long argument lists

  ;(someTable or another)[key] = value

The parser should be fully backwards compatible with existing Lua
5.2work2 code. I haven't checked the parser of Lua 5.1.4 yet (I assume
it's fairly similar, though).

I hope some of you find this useful. This is the first time I code in
C, so some bugs may have crept in because of my inexperience (and
absent-mindedness), don't stab me too hard if you find one :-).

Cheers,
-- Pierre-Yves

Attachment: shortfunctions_and_syntactic_aspartame.diff
Description: Binary data