More Operators (LLO Archive)
Created 2025-12-01, last modified 2025-12-01
Part of my archive of Layover Linux Official posts on Tumblr.
2025-10-03
It's been a doozy of a week in my personal life. I've managed to pull off some major advancements in my language project though.
First of all, infix "plus" and "dot" operators work. This itself is thanks to complete rewrites of the lexer, parser and evaluation engine, made possible by the test suite. I can't state enough how much better the new text processing code is, and how much it enables me to add new features.
prn> u8(1) + u8(7)
u8(8)
prn> [#foo, #bar].foo
#bar
This works because each infix operator is actually sugaring over a function call to a function like "plus" or "dot", which allows stupid and educational shenanigans.
prn> conv.repr
conv.fn(conv.repr)
prn> dot(conv, #repr)
conv.fn(conv.repr)
prn> dot(conv, #repr)(3)
'literal.num("3")'
prn> dot(conv, #repr)(3):repr()
"'literal.num(\"3\")'"
Silly fun. Speaking of which, if you've been following the project so far, you're probably used to the heavy dose of namespace::separators, which have now been removed in favor of nested tables. In fact, the language just got more self-documenting.
prn> conv
[#atom, conv.fn(conv.atom), #list, conv.fn(conv.list), #construct, conv.fn(conv.construct), #fn, conv.fn(conv.fn), #u8, conv.fn(conv.u8), #repr, conv.fn(conv.repr)]
Right now, these are just lists, which use a de facto key-value pairing convention to act as tables for any table operations. Eventually, I plan to add another pointer tag type for VVecs so that they can be marked as "tables", in the same way that a VVec can currently be marked as a list or construct - same shared data underneath, but treated differently by the language, particularly for display purposes. That's what was going on in my earlier "foo bar" example.
There's one more pointer alias for VVecs I plan to implement after {tables}, and those are plexes. A plex is like a struct, with a fixed structure of fields. This means that, as far as convention, it'll probably look something like this:
[ #fields, [#a, u8, #b, string], #values, [u8(2), "hello"] ]
The idea being, even in the highly dynamic interpreter mode, you're going to be able to reuse the fields table across many instances that all follow the same structural specification. I say pretty often, "a lot of things are VVecs under the hood", and now you see how true that is!
Right now, this is a pretty rapid growth phase of becoming a more useful language. Because the features play well with each other, each new feature adds more value than I even expect. It's still very toy, but it's making me start to really think about what needs to happen to get to dogfooding territory for useful (if not complex) tasks.
