[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Free format strings?
- From: "Peter Hill" <corwin@...>
- Date: Fri, 27 Dec 2002 23:07:29 -0000
> I actually have to type it as:
> a = "abc"..
> rather than
> a = "abc"
> as that gives the error
> stdin:1: unexpected symbol near `..'
Björn De Meyer:
> I'm sorry, but what's going on here is more of a quirk of the Lua
> interpreter than a problem in the language. When you use the lua
> interpreter as an interactive tool, every line is compiled separately as a
> chunk, unless the interpreter detects that the line is not finished (such
> as in function definitions, loops, etc)
Whoops. I just assumed the interpreter processed stdin as a file. I should
have realised that the ">" prompt implied more. :-P
> In essence this causes a difference between the behaviour of the lua
> interpreter when run interactively and when run on a file. Just take this
> local try = "Hello"
> In Lua, when it is not run interactively, the only newline/freeform
> conflict that exists is the one documentend, namely for function calls.
> Oh, and by the way, these limitations of freeform, and of the return
> statement exist in Lua exist because of difficult problems with the parser
> and the parsing of ambiguous statements. If you or someone else could
> solve these problems without altering the language, then that would be
Unfortunately, if a syntax is ambiguous then (by definition) it can't be
fixed without changing the language, at least in some manner. I guess the
aim is to be the least distruptive, without being too ugly.
x = f
x = f(a)(b)
ambiguity was discovered the most minimal resolution, given that Lua was up
to then entirely free form (so newlines didn't 'exist' outside string
literals) AND that ";" already existed, was to require the use of ";":
x = f ;
for two different statements and have the ambiguous form resolved as a
Good in theory, but apparently a bit ugly so the not-quite-freeform rule was
introduced. It's sort of ok, since it mimics the layout programmers would
generally use. But, as a special case kludge, it is rather unaesthetic.
I stick by my earlier comment... that, given that Lua has ceased to be fully
freeform with regard to the termination of parsing of one particular type of
statement by a newline, it should be extended to terminate parsing ANY
"complete" statement when a newline is encountered. The programmer can
freeform a statement over a line break if they desire by simply leaving the
statement incomplete at the line break. Ie, one would write:
a,b = x(),
a,b = x()
since in the second case, the statement parsing would complete at the end of
the first line, and the second line would be a syntax error. This is very
human readable... the reason why the current non-freeform rule was
introduced in the first place (I presume).
Note, this in no way invalidates mutliple statements on a line. The
following would be fine:
a=5 print(a) x=7
> Perhaps this problem indicates that some solution is needed to make the
> interactive lua interpreter work more accurately. However, I fear that
> this will be difficult.
If we accept the above syntax mod then we are a step closer. We would then
need two more things.
(a) Browsing the manual I can find a "lua_load()" but not a "lua_do()".
Presumably, one could create a "lua_do" along the same lines (using a reader
function etc) without much extra code (since it should be able to share
functionality with "lua_load"). The idea here is that "lua_do" doesn't load
an entire chunk then execute it but rather that it compiles and executes
completed statements as they become available.
The "reader" function could then be something like:
char *reader(blah, *size)
(*size) = strlen(buffer);
(b) That just leaves wanting the ">>" prompt. For this, we enhance the
definition of the reader function (when called by "lua_do") to have an extra
parameter. This parameter will be true if "lua_do" received text that
finished with a partial statement, and false if only complete statements
were received. So we have:
char *reader(blah, *size, int partial)
printf(partial ? ">>" , ">");