Re: #! /bin/lua (was Re: ~= vs. !=)

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

Rob Kendrick:
>[...]
> What would make me happy is that lua_load function deals with this,
> rather than the lexer.  That way it works perfectly with both.  And if
> it's up to the interpreter to ignore it, why doesn't it if it's a
> compiled lump?

Edgar Toernig:
> I thought about that for Sol.  It's easy to do.  What kept me from
> adding it was that you have to remember the shebang line to add it
> to the compiled chunk later.  Not really difficult but becomes ob-
> trusive.  The alternative - hardcode a line in the dumper - was not
> acceptable for me.

That 'obtrusiveness' was why I suggested adding a file mode of 'lua
executable' to the file open commands. On a default system such a mode would
have no additional effect, and regardless of system it would be transparent
to the Lua coder as to what effect it did have (that would be for the person
who ported Lua to that OS to decide).

Thus, the Lua parser would do a 'Lua executable open' to read the source
(and hence see nothing odd). The dumper would do a 'Lua execuable create' to
dump the byte codes (and hence not have to worry about adding anything).

A Lua debugger would likewise use an 'open executable to read' and 'open
executable to create' to read and write Lua source code into an editting
window, and both the debugger & user would see nothing odd.

Ie, by adding an extra file mode (Lua executable) the whole operation is
nicely modularised in one place, and is transparent to all but the person
who ported Lua to the OS (assuming, of course, that people are well behaved
and actually *use* the new mode). If a porter should happen to wish to use
OS-specific calls (such as ones that deal with an "x" flag) then that is all
tucked into one neat maintainable place.

The essence of a transparent file feature is to put it both on read *and*
write!

*cheers*
Peter Hill.