Re: Ambiguous Syntax (was Re: Free format strings?)

[RLake@...]

Peter Hill escribió:

> The only cases that require grouping are:
>    (i) (function (a) ... end)(123)
>    (ii) (<unop> x)(123)
>    (iii) (x <binop> y)(123)

> Case (i) is important but, as I mentioned on the list a few days ago, the
> code can be converted to allow:
>    function (a) ... end (123)
> by changing only a few lines.

Yes, but I find that unreadable. (function(a) .... end)(123) gives me a
better hint as to what is going on. Just a personal preference. (I would be
quite happy with more symbols and fewer words, but that is contrary to the
Lua spirit. I understand the appeal of:

    |: a, b, c : ... :|

and other such syntaxes for anonymous functions. But I wouldn't make that
suggestion seriously for Lua.

> Cases (ii) and (iii) are generally an error (unless there has been some
> metamethods at work, and even then things like (1+2)(Y) are pretty odd)
the
> exception being the boolean operators which can easily return functions.
For
> example "(fred or print)(123)".

But that is an important exception. Another example is overloading binops
to do things like functional composition, not uncommon at least in my code.

A long time ago I pointed out on this list that the solution is really
quite simple:

     function Do(x) return x end
     Do (table.move or default_move)(x, y)

This doesn't *require* a language feature but it would be slightly more
efficient if it had one. The word "Do" could be anything; do is a reserved
word, but it pretty well encapsulated the meaning. If it were a language
feature, it could also be an unambiguous unary operator such as !. Of
course, it could also be called identity (it is, after all, just the
identity function) but I don't think that leads to readable code.

Suppose the symbol ! were chosen. Some people would point out that there is
no practical difference between ! and ;
That is:

(current syntax)
    a = f;
    (table.move or default_move)(x, y)

(! syntax)
    a = f
    !(table.move or default_move)(x, y)

I argue that the latter is better because the symbolic oddity is on the
same line that requires it; if the previous line were subsequently moved
during an edit, it wouldn't be necessary to adjust semi-colons.

Rici