Re: Free format strings?

["Peter Hill" <corwin@...>]

Peter Hill:
> I actually have to type it as:
>     a = "abc"..
>     "def"
> rather than
>     a = "abc"
>     .."def"
> 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
> example:
>     local try = "Hello"
>     print(try)

> 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
> nice...

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.

When the:
    x = f
    (a)(b)
versus
    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 ;
    (a)(b)
for two different statements and have the ambiguous form resolved as a
single statement.

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(),
    y()
rather than
    a,b = x()
    ,y()
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 buffer[101];
    char *reader(blah, *size)
    {
      if (feof(stdin))
        return NULL;
      else
        {
        printf(">");
        fgets(stdin,buffer);
        (*size) = strlen(buffer);
        return 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)
and
    printf(partial ? ">>" , ">");

*cheers*
Peter Hill.