Re: # comments (proposal)

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

Peter Hill:
> Perhaps the chunk loading code should simply skip the "#! blah<newline>"
> preamble (if it exists) ... its format is the same regardless of whether
> the file is source code or precompiled Lua ... and THEN examine the next
> byte to determine whether the file is precompiled or not.

Luiz Henrique de Figueiredo:
> The problem is that files with precompiled code must be open in *binary*
> mode. We look at the first byte to check this and reopen the file in
> binary mode if it seems to contain precompiled code. To handle the #!
> thing we'd have to read the first line.

And...?

Either open the file in binary mode regardless of whether it is pre-compiled
or not (does that produce any significant difference?) or reopen the file
and skip until the first <newline> (which is only a few characters).


Peter Hill:
> But doesn't that mean that currently on a unix system you wouldn't be able
> to have precompiled executables? That's not right. :-(

Luiz Henrique de Figueiredo:
> Yes, unfortunately. Like you said, perhaps this hints that this whole
> bussiness should be handled elsewhere.

I'm beginning to feel that things are more like the off-the-cuff comment I
made in the last email about specialised IDE wrappers than I realised.
Whatever system you are working on your Lua code may be potentially wrapped
in some way.

Which actually makes me wonder about another topic I've been pondering. In
the source code there is a ZIO module that seems to be a general character
stream, presumably so the parser can be the same regardless of whether the
code is coming from a string or a file.

In Lua itself, however, the Parser is reduced to either a file source
(loadfile / dofile) or a string source (loadstring) and nothing else. This
strikes me as rather limiting. If a programmer wants to compile code from an
odd source (eg, over a network, or from inside a wrapped file, a database,
etc) then they have to extract the whole thing into a string first.

It would be far more flexible if the parser (the 'load' and 'do' actions)
took a general "stream" function that simply produced characters upon demand
until end-of-stream. The 'dump' function could do the reverse.

Aside from making direct execution of code from exotic sources more
agreeable, it would also allow an IDE to have an "unwrapper" function which
gets the raw source file (via the original stream function), removes any
embedded codes etc, then forwards the result on to the parser.

*cheers*
Peter Hill.