Re: Unpack Operator

[Francisco Olarte <folarte@...>]

On Sun, Feb 11, 2018 at 8:09 AM, Tim Hill <drtimhill@gmail.com> wrote:
> The basic problem with any of these suggestions is that it involves making the compiler aware of the signature of a target function. As currently designed, Lua does not need to know ANYTHING about a target function at compile time; neither the number of arguments nor their type(s). Adding named arguments makes things far more complex. First, the compiler will need to know the signature of the target function. How will it do this for different compilation units? Do we add all the mess of header files, or locating some sort of class file look-aside files? This has all the horrors of Java compilation. Second, even if all that WAS available,which function is being called? Remember that functions in Lua are just VALUES, and the actual function to be called is not known until runtime (the “name" of the function is just a transient variable binding). This means that the binding of named values to arguments would need to be done at runtime, and would, upon examination, be functionally identical to packing the args into a table anyway.

> The net result would be a significant reduction in function call performance for everyone, just to avoid the occasional use of braces instead of parentheses when calling a function. I dont think this is a good trade-off at all.

IIRC Python does all kind of named/default argument thingies without
signatures. Of course, as you pointed below, with a huge performance
penalty ( python feels very slow when I use it ). An in python
functions / methods are values too, no headers / compilation needed.
It does so by packing, unpacking and repacking everywhere.

Francisco Olarte.