Re: Unpack Operator
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Unpack Operator
- From: Sean Conner <sean@...>
- Date: 2018年1月22日 12:47:25 -0500
It was thus said that the Great Paige DePol once stated:
> Sean Conner <sean@conman.org> wrote:
>
> > Over a decade ago, I was perusing a book on the VAX architecture when I
> > came across two instructions, CALLS and CALLG. To use CALLS, you first push
> > data onto the stack, then the number of arguments, then issue the CALLS:
>
> You always seem to have the most interesting and esoteric posts, Sean! :)
You're welcome. I try 8-P
> > There is no particular need for an unpack() function if you implement the
> > language just right. The issue is distinguishing between a CALLS and a
> > CALLG type situation:
>
> For function calls sure, however, what if you wanted to unpack some data
> from a couple tables into another without a function call?
>
> local one = { 1, 2, 3, 4, 5 }
> local two = { 6, 7, 8, 9, 0 }
> local test = { $one[2:4], $two[1,3,5] }
Hmm ... I now notice that you said "unpack operator" and not "unpack
function". Ah, reading comprehension, where art thou?
> Simply merging the two key/value tables into one is as easy as this:
>
> local test = { $$one, $$two }
>
> The contents of 'test' would then be as follows:
> { one = 1, two = 2, three = 3, four = 4, five = 5,
> six = 6, seven = 7, eight = 8, nine = 9, zero = 0 }
Okay, but what's the result of:
local one = { one = 1 , two = 2 , three = 3 }
local two = { one = 99 , four = 4 , five = 5 }
local test = { $$one , $$two }
Is it:
{ one = 99 , two = 2 , three = 3 , four = 4 , five = 5 }
or
{ one = 1 , two = 2 , three = 3 , four = 4 , five = 5 }
or even
{ one = { 1 , 99 } , two = 2 , three = 3 , four = 4 , five = 5 }
My guess is the first one, but personally, I would like the last one as it
preserves all values.
> I have noticed that in a number of situations adding types to an untyped
> language is done in order to improve performance. Another good reason is
> to allow for better interoperability with a typed host language, like C.
Well, there's also intent on how the code will use the variable [1].
> I was thinking of adding named parameters, as well as optional parameters,
> and have been figuring out the best way to implement them. One issue I am
> trying to sort out is an efficient way to create a function signature that
> can be quickly calculated at runtime when necessary. Another issue is
> determining a nice readable syntax for named parameters!
Um, how about:
local addr,err = net.address2(host = 'www.google.com', proto = 'www')
> Thanks for your comments, your insights are always appreciated!
Again, you are welcome.
-spc
[1] An example of my own documentation format here:
https://github.com/spc476/lua-conmanorg/blob/a14a432e63fbacfec01c941c67040d3cba73edd1/src/fsys.c#L1110
or
https://github.com/spc476/lua-conmanorg/blob/a14a432e63fbacfec01c941c67040d3cba73edd1/src/net.c#L674
I'm still working on the format.