Re: Unpack Operator

[Paige DePol <lual@...>]

Sean Conner <sean@conman.org> wrote:

> It was thus said that the Great Paige DePol once stated:
>> 
>> You always seem to have the most interesting and esoteric posts, Sean! :)
>  You're welcome.  I try 8-P

I like posts that make me think about things, and it is always great to
get another viewpoint... to see things through another's eyes! :)


>  Hmm ... I now notice that you said "unpack operator" and not "unpack
> function".  Ah, reading comprehension, where art thou?

Indeed I did, but that is okay, the conversation is still pertinent! 


>  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.  

My initial reaction would be the first condition, however, I do plan to add
an "@option" compiler directive to allow tweaks to the language. So adding
something like "@option unpack first", or "@option unpack last", or as you've
indicated a preference for "@option unpack all" to preserve all values...
though I may need a better keyword than "all" as that may be a bit ambiguous.

Whenever I create software I always try to give options whenever possible.
I figure why limit options if the result of providing a setting doesn't
significantly impact performance.

This way I can have other options like "@option array [0|1]" to have arrays
start at the 0th or 1st index. Or "@option switch [break|fallthrough]" for
my switch/case patch. Or "@option jumpto [condition]" for setting default
behaviours for jumpto labels. I also will offer "@option strict" for forcing
variable declarations and/or variable types as well.


>> 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].

Yes, that as well. Which when declared can be of significant value to the
compiler for making optimised code. In vanilla Lua documenting your expected
use of a variable is a great idea... however, I like it better when I tell
the compiler what I am doing and it helps validate my usage of variables.


>> 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')

Yes, either that or with colons perhaps?

local addr,err = net.address2(host: 'www.google.com', proto: 'www')

I am probably in the minority, but I really liked the syntax for Objective-C:

local addr,err = [net addressWithHost: "www.google.com" andProtocol: "www"] 

With named parameters the coder should also be able to provide the parameters
themselves in any order, so the following would be the same:

local addr,err = net.address2(host: 'www.google.com', proto: 'www')
local addr,err = net.address2(proto: 'www', host: 'www.google.com')

At least, that is my goal... and with my Token Storage system it would be
fairly trivial to implement really. I use the token storage system quite
extensively as well to implement various language features as well! 


> [1]	An example of my own documentation format here:
> 	https://github.com/spc476/lua-conmanorg/blob/a14a432e63fbacfec01c941c67040d3cba73edd1/src/fsys.c#L1110
> 	I'm still working on the format.

I, too, am devising a documentation format. I would like to be able to
generate comprehensive documentation that can be converted to web pages
via a script... much like how Apple did their documentation for Obj-C. 

~Paige