Re: Confusive text in Lua doc "Variable Number of Arguments" about "arg"

[Philippe Verdy <verdyp@...>]

Another use would allow a Lua script loader to be able to load scripts written in another language:

'java'[==

  /*some java code here...*/

]==]

The Lua loader could even accept to load the script even if the final ']==]' marker ending the Lua long string is missing at end of a script file.

Note that here it would parse as two successive Lua strings, each one being a separate parser attribute:

- if a parser accepts and parses the first attribute, it will evaluate it (passing a reference to the rest of the script being parsed)

- if its evaluation succeeds (does not return an error caught by the loader), then the loader will continue parsing the rest of the script (that has not been already parsed during the evaluation of the first attribute)

- if a parser ignores one attribute, it just returns success, and the loader continue parsing to read the next attribute (if there's one) to process it the same way, or the rest of the Lua script

The evaluation of any attribute can do everything it wants in the context of the parser, including changing the behavior of the parser, or its bytecode generator or compiler (so it can alter how the Lua code present after the attribute will behave later when it will be executed)

Le jeu. 9 sept. 2021 à 12:56, Philippe Verdy <verdyp@gmail.com> a écrit :

Other uses for "parser attributes":

- could allow safely serializing code (including the bytecode generated by the lua parser itself, something not possible for bodies of functions written in pure Lua).

- could allow safe distribution of binary compiled code (with a digital signature embedded in one of the parsable attributes).

- could allow concealing the real script, by encrypting it (requires the loader to know the decryption key associated to a signature)

For example:

    function()[=[

      lua.signature([[ digital signature here ]]),

      lua.deserialize([[ bytecode representation here ]])

    ]=]end

A Lua loader not supporting any attribute would treat it exactly as if it was: function()''end

with an empty string discarded: function()end

so that this function would just always return nil

The same would apply to the full content of a Lua script, just containing a string constant (without any prior "return" statement): loading this script in a Lua loader not supporting any attribute would cause an error of execution returned by the loader, as it would evaluate to nil, just like trying to load any script that would be entirely empty.

Le jeu. 9 sept. 2021 à 12:36, Philippe Verdy <verdyp@gmail.com> a écrit :

This is quoted from Lua 5.2 (not 5.3 which is recent) And this is the only text available on official site lua.org (most sites still don't use version 5.3, or the very recent version 5.4 which is not compatible in many aspects).

Version 5.2 really had the implicitly declared local variable "arg", available in the body of every function definition (used to "capture" all function arguments in a pseudo-table, before the addition of "vararg expressions" using the nilary operator "...").

There's still in all current versions the implicitly declared local variable "self", available in the body of every function definition whose name uses the "colon" syntaxic sugar with a "object:" prefix before the given function name.

But it should be noted that you cannot use the "local" declaration

    local function object:method(parameters) body end

NOT equivalent to

    local object.method = function(self, parameters) body end

because the local variable "method" in the second case would not be visible in scope to the function body, and anyway "local object.method" has no sense, the locality of the name for methods is not defined by the current local scope but by the given object in which the method name will be used as a key to store the reference of the function.

And even without this erroneous "local", nothing warranties that the function body will be executed with the same object referenced by this "self" parameter (even if you use the "colon" syntaxic sugar declaring it implicitly... or not and then "self" is not implicitly declared and you can rename it as you want, such as "this", "obj", ...)

The function can still be called without the "method" style, so the function still needs to validate the possible types and values for its first parameter (Lua still does not enforces strict type validation in its declarations, and won't be able to do that... unless functions are annoted by "parser attributes", like what I described in earlier messages (attributes can just be one or more string constants at start of the function body or the start of a lua script, except that they are NOT comments, but they would use a Lua syntax, parsed by the Lua parser in the script loader, these attributes would be conditionally executed by this loader, but then normally invisible to the declared function, except by using some debugging or reflection interface exposed by the loader).

I still think that "parser attributes" are extremely useful, including for security (e.g. distribution of Lua code from external site: this requires validation of digital signatures or certificates that could be embedded easily in these attributes), or code generators (including IDE's that need reliable reflection capabilities to be exposed directly in the source code), or debuggers (that could be written in pure Lua, using their own loader), or for compilation or execution directives (e.g. for setting rounding modes, or allowing to restrict or relax the order of evaluation of operands, operations and function calls).

Supporting "parser attributes" in the Lua syntax is extremely easy: you can add them either at start of function bodies (or start of Lua scripts), or at start of any block (after "do", "repeat", "then", "else") or at start of any other statement (after a required semicolon ";" statement separator), or even at the start of any _expression_ (only after the "=" sign, or between parentheses/brackets/braces just after the leading "(" or "[" or "{") before the actual _expression_. Lua parsers would NOT be required to evaluate all these attributes, they could just discard all of them silently, they would just have to accept the presence of a string constant at these locations. These parser attributes should still use a syntax clearly defined in Lua (probably a comma-separated list of "key", or "key=value", or "key(values)"), and should use naming conventions for its keys, to scope them by use (Lua itself could reserve its own scope, vendors or applications could use conventional dotted naming schemes like those in Java, dotNet, Python... and even already by Lua itself for naming its modules loadable with "require").

Le jeu. 9 sept. 2021 à 11:22, Andrew Gierth <andrew@tao11.riddles.org.uk> a écrit :

>>>>> "Philippe" == Philippe Verdy <verdyp@gmail.com> writes:

 Philippe> See https://www.lua.org/pil/5.2.html.

Stop right there - the website copy of PIL is _NOT_ the documentation,
it is a book about an old version of Lua (5.0) and as such is obsolete
in many respects including this one.