lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On 04/05/16 12:47 AM, Duane Leslie wrote:
I needed a way to specify the upvalues of a function explicitly so
that I could serialise and de-serialise user defined functions in a
reliable way.  I have added the syntax of an angle bracketed parameter
list for upvalues which comes after the argument parameter list in the
function definition.

For example, the main chunk which was previously defined as:

function (...)
   stmt;*
   return
end

is now defined as

function (...) <_ENV>
   stmt;*
   return
end

A general existing function has the defined upvalues of <...> (i.e.
whatever it likes).

The declared upvalues must exist in the context of the function
definition (i.e. they cannot be globals to be looked up).

If a fixed upvalue list (i.e. without ...) is provided without _ENV,
then the function cannot lookup global values and this will actually
generate a syntax error at parsing rather than at runtime.  This has
the advantage that 'strict' mode is now enforceable at the parsing
stage rather than at runtime (current with _ENV modification).

If a fixed upvalue list is provided with _ENV but without locals from
its context then those locals will not be accessible and globals will
be sought instead.  This brings the 'strict' behaviour to closures
since I can prevent them from accidentally seeing a local variable in
their scope, and in combination with the normal strict _ENV I can
report it at runtime, or with disabling _ENV as well cause a syntax
error at parse time.

My motivation for this was to allow users to provide custom functions
in a controlled way.  I let them provide a function as a string, and
then I compile it with the following:

compiled = load("local "..table.concat(upvals, ", ").."; return
function (...) <"..table.concat(upvals,", ")..">; "..userfunc..";
end")()

Which gives a syntax error if they try to access a
variable/function/table that is not declared either as a local by them
or in the upvals list, and means that when I serialise using
`string.dump(compiled,true)` I know exactly what upvalues to bind
where when reloading the function.

Anyway, the patch is attached, and if anyone has an feedback I'd be
interested to hear it.

Regards,

Duane.
This is nice and all, but ever heard of loadx[1]?

[1]: https://github.com/SoniEx2/loadx

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.