Re: Unpack Operator

[Paige DePol <lual@...>]

Benoît de Chezelles <benoit.dechezelles@gmail.com> wrote:

> 2018-02-10 10:49 GMT-08:00 Paige DePol <lual@serfnet.org>:
>> So this splat and double splat are essentially unpack operators, which
>> was the original title and discussion topic of this thread. Nice!
> Hehe, maybe we're going somewhere after all with all of this!
> 
> Next we'll need to find a way to apply all or part of this to Lua.

I have an implementation of something I call the Index data type.

By upgrading the VM Instruction from 32bit to 64bit I was able to give each
register a separate offset value. This value is basically the offset into
the Index data type that must be in the register. Also if the index offset
values are not needed there are various extended opmodes available.

This allows for the creation of structs and object variable encapsulation
with very fast access to Index elements at the vm instruction level.
I have the struct and object system defined, tuples are next on my todo
list after I finish coding the object model.


>> Okay, my reading of the documentation last night lead me to believe there
>> should be an error that there was no named argument 'a', so how is 4, 5, 6
>> being assigned to a, b, c in this example?
>> 
>> Oh wait, it's because in this case a, b, c aren't named parameters they are
>> just positional ones with default values. I see. My bad. Sigh!
>> 
>> So then that does make sense, sorry Sean, I totally was thinking that a, b,
>> c were named arguments not positional parameters in these specific examples.
>> As there is no way to easily determine where positional and named parameters
>> start and stop that is why they use a solo 'splat' marker.
> 
> Yes exactly, and also positional arguments can be called as named arguments
> too (detailed below).

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.


>> So in Crystal you can create tuples using the same syntax we use
>> for tables in Lua then? Good to know, guess I should have clicked
>> on the links for Tuple and NamedTuple!
>> 
>> And in these cases the
>> created tuple is just being created and unpacked... that doesn't
>> seem the most terribly efficient method for passing arguments.
> 
> Sure, in this case the use of (named)tuple is completely useless, but
> when you have
> a (named)tuple coming from outside (the caller, generated from a json
> string, ..), it
> starts to be useful!
> 
> About the efficiency, I'll going a bit out of topic here, and I'm not
> sure I'll explain it clearly enough..
> 
> Basically in Crystal, Tuple & NamedTuple are a compile-time immutable construct,
> allocated on the stack (the real stack, there is no VM or bytecode or
> anything), as all
> the types are known at compile time, the compiler can pass the correct
> values from
> the (Named)Tuple, or the default values, or positional/named values
> at the correct places on the stack so the method body can find them
> and use them.

This is pretty much what I do as well for tracking elements of a struct,
or the variables defined for an object. The compiler tracks it all and
then uses the offset values in the vm instruction to access the elements.


> It's not a dynamic data structure that you create then unpack, they
> are just a virtual
> concept to powerfully manipulate a set of values on the stack (not
> sure it even mean
> something..), so there is very little to no overhead to use them to
> pass args in Crystal.

In my system they would be subtypes of the Index, however, I plan to use
memory arenas to manage Index allocation. This way I should be able to
ensure speedy reuse of Index data types as the script runs.


> Quoting a question from above:
>> So the "splat" qualifier is actually an operator as well? I missed the
>> line that sort of intimated at this possibility and thought that the
>> symbol was a variable qualifier for function parameters only.
> 
> It's not really an operator, well, it is but it works only on Tuple
> (for *) and NamedTuple (for **).

In Lua, however, it could also be used for unpacking tables, either
as an array with *, or as a hash with **.


>> Thanks for the live example, that helped to clarify things. The
>> previous post of mine would have all made sense were the a, b ,c
>> arguments named and not positional... I still like the syntax
>> though having to have a solo splat on all functions without any
>> positional arguments is a bit of a wart.
>> 
>> Obviously, I missed the importance of the solo splat as a way
>> to separate the two styles of parameters. Because a, b, c had
>> default parameters I was thinking they were named parameters.
> 
> The solo splat in Crystal is only used to force the user to call the
> next arguments using
> named parameter, but all params are always callable with its name:

Yes, somehow I also seem to have missed that the first time through. I
really should probably not try to comprehend things and post about them
after a long day right before bed. I really missed a couple fundamental
things about this model. I think I just assumed that the two argument
types would be discreet and my brain ran from there!


>> Again, Sean, sorry... I had just misunderstood the syntax s
>> your examples were correct and my clarifications were not! :(
> 
> I'd say "don't be sorry", reading the documentation of a new language
> which have different
> paradigms and expect to understand everything is a no-no! It's normal
> to be confused here I
> think, even though one know another language (Lua) very well :)

Well in my defense I was tired. I think I also partially have an idea for
how I'd like to implement named parameters. Crystal has some things that
are similar to my ideas so I skipped over the bits that didn't match what
some of my own ideas were and that lead to confusion and a bit of noise.

I still do thank you for sharing this link, it did give me something to
contemplate... especially once I'd properly comprehended the content! ;)

~Paige