[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Unpack Operator
- From: Tim Hill <drtimhill@...>
- Date: Sat, 10 Feb 2018 23:09:35 -0800
> On Feb 10, 2018, at 2:01 PM, Sean Conner <sean@conman.org> wrote:
>
> It was thus said that the Great Paige DePol once stated:
>>
>> I wonder then really... why even have positional vs named arguments? I really
>> like how they've laid out how it works, but practical examples of the system
>> at work makes me think that just named arguments would be nicer overall.
>
> That's were I was going with my examples. Perhaps a more concrete example
> will help. In C, you have structures:
>
> struct foo
> {
> int x;
> int y;
> int z;
> int a;
> int b;
> int c;
> };
>
> And you can initialize them. Default, it follows a position notation,
> much like function calls:
>
> struct foo f1 = { 1 , 2 , 3 , 4 , 5 , 6 };
>
> But in C99, you can designate the fields being initialized, so this now
> becomes something like named positions:
>
> struct foo f2 = { .a = 4 , .b = 5 , .c = 6 , .z = 3 , .y = 2 , .x = 1 };
>
> Furthermore, you can mix the two:
>
> struct foo f3 = { 1 , 2 , 3 , .c = 6 , .b = 5 , .a = 4 };
>
> I don't see why this can't work for function calls as well.
>
> -spc
>
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.
—Tim