Re: Unpack Operator

[Paige DePol <lual@...>]

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! :)


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

The contents of 'test' would then be as follows:
{ 2, 3, 4, 6, 8, 0 }

Granted this is a contrived example, but it does demonstrate my meaning...
and potentially the syntax I may use to allow unpacking specific indices,
or a range of indices, from the source array.

Table keys could also be specified with a similar syntax:

local one = { one = 1, two = 2, three = 3, four = 4, five = 5 }
local two = { six = 6, seven = 7, eight = 8, nine = 9, zero = 0 }
local test = { $$one{two, three, four}, $$two{six, eight, zero} }

The contents of 'test' would then be as follows:
{ two = 2, three = 3, four = 4, six = 6, eight = 8, zero = 0 }

Extracting just the values from a table using keys could also be done:

local test = { $one{two, three, four}, $two{six, eight, zero} }

The contents of 'test' would then be as follows:
{ 2, 3, 4, 6, 8, 0 }

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 }

Granted, all the above examples could be written out in a longer format,
however, I think the unpack syntax makes things much easier to read and
also helps prevent typos by not repeating information (key names).


> (question marks because I don't know how to designate what type of call I
> want in an untyped language)

My language has optional typing, unless strict typing is enabled, however
for data types derived from the Index, like Objects, it is advisable to
declare the type to avoid costly runtime or typecasting checks.

Even with strict typing enabled, however, you can declare a variable as
being "Varies"... which is the same as being untyped, just explicitly
declared as such.

I also have an option to require all variables be declared... one language
feature I really dislike is the auto-creation of variables on first use!

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.


>  Related (tangent alert)---a structure (struct in C, record in Pascal) is
> nothing more than an array with possibly unequal sized items:
> [...snip...]
>  Look at that---named parameters in a function call!

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!


>  Now, I'm not saying your langauge has to unify arrays, structures and
> function parameters, but it could lead to some interesting features.
>  -spc (It looks like you've already unified several types already ... )

Yes, once I created the Index data type for holding object/class variables
other uses became quite obvious to me... and now the Index is an integral
part of my hard fork of Lua. For object variables it has proven to be quite
speedy, an Index offset is encoded right into the VM Instructions... so no
table lookups are required, the variable is just immediately available.

I did expand the Instruction size to 64-bit to accommodate the new offset
parameters, which are always available for register A, and optionally for
registers B and C. I have extended versions of B and C available as well,
plus a D register if neither B nor C need extensions or an index offset.

I am just finishing off adding property declarations and usage to my object
model, then I plan on creating some benchmark test cases!

Thanks for your comments, your insights are always appreciated!

~Paige