Re: small incompatibility

[Rici Lake <lua@...>]

On 22-Oct-05, at 5:24 AM, Mike Pall wrote:

> [This needs a few changes to keep the stack level unchanged for
> the luaL_Buffer methods.

Yes, I noticed that when I looked at your patch; I had the
same thought.

>  And a returned string needs to be
> processed literally and not with %n escapes. Oh well ...]

Well, that's also an option, isn't it? It makes no sense for the
return values of functions, which can be presumed to do all the
work necessary, but it is easy to imagine situations where you
might want to use %n escapes in a table value.

The more I think about it, the more I think:

1) It is really not pleasant to define radically different
behaviour for 'false' and 'nil'. Either 'false' should have
the same semantics as 'nil' or it should be an error.

2) Much though I hate to say it, function calls and table
lookups in this context are not the same thing.

In effect, the table lookup is a part of the
pattern match; i.e. the non-existence of the key
indicates that the match failed and consequently
no replacement should take place. (Logically, this
should cause the pattern matcher to continue to
back-track.)

If the key exists, the value is "what the replacement
should be": it could then be a string (with %n escapes)
just as though the string had been in place of the table,
or it could be a function, just as though the function
had been in place of the table.

The function call is the action of the replacement,
and really ought to return a string or something that
would normally be coerced into a string (i.e. a number).
However, also coercing nil/false into the empty string
is convenient (and historical practice).

In other words, a table of functions is effectively a
switch statement: the table defines the cases, and the
functions are the bodies.