Accessing tuples []

[gavlooth]

I get this error:
(get [1 34 3 4 52 31] 0)
runtime error: "expected function"
in <function 0x55AF7B5DD3C0> (pc=8) (tailcall)
while:

(get @[1 34 3 4 52 31] 0)
1
(get (tuple 1 34 3 4 52 31) 0)
1

work fine

[gavlooth]

Trying to implementing into.
A couple of questions. Is recursively updating immutable data more expensive (computation-wise, memory-wise)
Than mutating data structures?
I am planning to implement group-by, but this will create problems with mutable data structures as they cannot be used to represent keys. Any suggestions ? wrapping them in tuples and passing them as keys would work but is not so elegant

[gavlooth]

I also read your c code but, i havent written in c for years, and dont have any working knowlege on virtual machines, compilers etc etc. Any suggestions for good references, expect lua specifications.

[bakpakin]

I have implemented the change that brackets and parens are equivalent, ala racket. I know this might be annoying for certain literals but it makes the syntax for mutability more consistent.

[gavlooth]

I see, so it expects to call a function. Then maybe you could consider @[] ~ @()

[bakpakin]

Mutable structures are more efficient, and they can be used as keys. Just because they don’t have value equality doesn’t mean they don’t have any equality semantics.

(def a @[1 2 3])

(def lookup {a :value})

(= (get lookup a) :value) #> true

[gavlooth]

I see. what i was using is {@[1 2 3] :value}. If i wanted to implement group-by i couldn't bind each data structure to a symbol, so probably i have to wrap to an immutable data structure

[bakpakin]

As for references for compilers, I can recommend any compiler textbook of merit, say Appel's. I think the compiler (src/compiler/compile.c) is the most confusing part of the code and can definitely be improved. It does some basic optimizations, like certain constant propagation, but there are still a lot of low hanging fruit. The compiler compiles S-exprs directly to bytecode in a single pass, similar to A-normal form.

The Lua source code or a description of the Lua bytecode is still a very useful resource. Here is a great introduction to Lua bytecode, which is quite similar to the bytecode format in dst. The entry to the bytecode interpreter is in src/core/vm.c, and it is pretty clear that majority of the code is in what is equivalent to an infinte loop with a switch statement inside (there are some optimizations for GCC, but it is much the same). The interpreter then loops over all of the bytecode instructions, which are just uint32_ts, decodes and executes the instructions. The most complicated parts are handling function calls, switching fibers, handling errors, and how closures work.

I plan to add some design docs for the project soon, which will include docs about the bytecode format.
The bytecode format should make the internals of the interpreter more accessible.

[gavlooth]

Thanks :)