[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Ambiguous Syntax (was Re: Free format strings?)
- From: RLake@...
- Date: Tue, 14 Jan 2003 11:08:39 -0500
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)
> exception being the boolean operators which can easily return functions.
> 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
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 ;
a = f;
(table.move or default_move)(x, y)
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.