Re: # comments (proposal)

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

Peter Hill:
> # on the first line is NOT a commenting scheme... it is an allowance for a
> scripting language directive. Remember that even a *compiled* Lua module
> will need a '#! Lua' at the front of it to run automatically, even though
> the rest of the file is binary rather than human readable.

Luiz Henrique de Figueiredo:
> This sounds reasonable but the current code looks at the first byte in
> the chunk to decided whether to parse it as source code or to load it as
> precompiled binary.

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

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.


Peter Hill:
> Ie, the auto script running is a part of being a unix *file*, and so "#!"
> only has meaning as the first line of a *file* (not a chunk) and
> 'dostring' should not allow it. In essence, the main part of the Lua
> parser should never see it.

Luiz Henrique de Figueiredo:
> Except that in practice you'd want IDEs to be able to load full files and
> edit and run them, even with the #! on the first line. Running them would
> be via dostring. Of course, you could remove the #! line but if we start
> to do this, there'll be a lot of code duplication around.

It strikes me that the "#!" prefix is more of an operating system property
than a Lua property. If I distributed a Lua module I doubt that I would put
a "#!" line in the source, especially since the actual Lua-interpreter-path
depends on the individual system's filesystem.

IDEs are a fairly small subset of applications, and they are just as likely
to do processing on the code anyway, such as coloring various types of
syntax or extracting function definitions to create a jump-to list. So
processing an optional prefix line is going to be no great hastle.

And such a line might end up being transparent to the programmer anyway,
with the IDE settings choosing what prefix path to prepend to saved sources!
It makes sense since it is the IDE that understands the file system. And if
someone (under program control or via an IDE) decided to merge several
sources I'd *expect* them to strip out the "#!" headers from all but the
first file. The prefix line in not a part of the code and I'd expect an IDE
to strip it out on loading and insert it on saving.


On the other hand, since I don't consider the "#!" to be part of the Lua
code (just a particular operating system data tag that has been allowed in
standard code to make things a bit easier) it may not even be visible to the
IDE. The "#!" prefix is basically a file type that has been included
"in-band". Perhaps file opening commands should simply recognise it as some
kind of file type extension just like ".exe" and the "chmod a+x" flag are?

Just tossing around ideas here... but perhaps in such a case the file system
could be extended to include a Lua code file type? For example:
    io.open("fred","wl")

would create a file with "chmod a+x" and the first line as "#! /usr/bin/Lua"
(or whatever the _LUA_INTERP global has in it), while
    io.open("fred","rl")

would check that the file was executable and then skip the "#!" prefix.


More thoughts... I'd guess (though I'm not sure) that, if a Lua script was
invoked as a unix command that the Lua interpreter would not even get to
*see* the "#! Lua<newline>" prefix. Its addition to Lua is basically just to
allow multiple modes of execution of the same file on a unix system... both
directly from the shell (which needs the "#!") and via "dofile()" (which
doesn't want it). It is even possible that only versions of Lua compiled for
a unix platform would have "dofile()" skip over the "#!" header.

Regardless of all this, I still maintain that it should be "#!" that is
allowed for, not "#", and that it should only occur at the beginning of a
*file*, not chunk.


> Anyway, this is an issue that we have been discussing, so perhaps 5.1 will
> bring a good solution.

Good to hear! It's not a major issue but it certainly is an oddity (being
essentially outside the language) and it may just be the tip of the iceberg
as more Lua IDEs evolve (that may want to save Lua code with their own
layout wrapping etc).


Peter Hill:
> it might be nice to have a 'savefile()' as well.

Luiz Henrique de Figueiredo:
> Lua 5.0 has lua_dump and also string.dump.

I couldn't find a reference to "string.dump" in the Lua5b reference manual.
Does it take a function and return a string that is a compiled-module?

*cheers*
Peter Hill.