Re: Unpack Operator

[Sean Conner <sean@...>]

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.