Re: fun with table constructors

[Reuben Thomas <rrt1001@...>]

> But expressions beginning with brackets introduce ambiguity:
>
> 	a=b
> 	(f)(2)
>
> The code above is parsed as a=b(f)(2) not as a=b;(f)(2).

Ah.

> Some languages have a rule that newlines end statements if it makes sense to
> do so, but isn't that confusing too?

I use Lua as if it did, normally: I always put ; in when I have two
statements on the same line, and never when I have statements on different
lines. The difficult thing is that it must be possible to split a statement
across lines.

Haskell has a "layout rule" which uses white space for nesting. This seems
to work well most of the time: the amount of space at the start of a line
determines the nesting level, by comparison with previous lines which have
the same amount of white space.

Lua doesn't need the full glory of layout, because it has explicitly
delimited blocks (in Haskell, you either use braces *or* the layout rule).
A simple rule that could work for Lua might be:

  If a line starts with more white space than the previous one,
  treat it as a continuation; otherwise treat it as a new statement.

To count white space, expand tabs to some number of spaces, and then just
count the total number of spaces. Or to avoid the tab-counting problem,
declare it a syntax error if the shorter line's initial white space is not a
prefix of the longer line's initial white space.

But it's a great pity that you can't write and immediately apply anonymous
functions.

-- 
http://sc3d.org/rrt/ | Caution Children At Play Drive Slowly