I’d like to talk about this pet project I’ve had for a couple of months now. It is a concatenative programming language, called Jux.
disclaimer: This is very much a Work In Progress. I would like feedback, but do note that it is far from unfinished, as well as a hobby project that I can only devote so much time on right now
Jux is a concatenative programming language. This means that everything is a command that pushes a new value to the stack, possibly by consuming one or multiple things that were previously on top of the stack. So to add two numbers, one would type
1 2 add (or possibly
1 2 +). First a
1 is pushed, then a
2 is pushed, then the top two elements are popped, and the result of adding them is pushed back to the stack. Thus, everything is written in Postfix (AKA Reverse Polish) Notation. The internals of lists (called ‘quotations’) are not evaluated until a command that consumes it is used. This means that you can manipulate snippets of source code before it is evaluated; code == data == code. (Interestingly, this is an even simpler way of representing than Lisps S-expressions; and no parentheses are needed )
A slightly more complex code example would be:
\print_if_even " This function looks at the number on top of the stack, and prints `x is even!` if it is even, and if it is odd, it prints `x is odd!`. " [ [even?] [to_string " is even!" concat] [to_string " is uneven!" concat] ifte print ] def 42 print_if_even #=> 42 is even! 51 print_if_even #=> 51 is uneven!
(This takes the top element, checks if it is an even number, and then prints that number, followed by a message stating if it is even or not.)
Of course, all these fallback implementations written in Jux itself are a lot slower than if you were to perform them in the host language. So one could make an implementation more efficient by moving more and more commands from the standard library to the host language.
So, that is the basic concept: Make a language whose base is as small as possible, but whose apex (i.e. user-land) is feature-rich.
Jux is mostly meant to be an intermediate language to be compiled to. I am still researching (and I’d love feedback on) the idea of creating a bytecode variant of Jux.
Jux takes a lot of inspiration from Elixir (such as first-class documentation, explicitness is important.), as well as the earlier concatenative languages Joy, Cat and PostScript.
Here are the things I am very unsure about, and I would love to hear feedback from you people, because I know that many of you are involved in many different language - or framework building projects, and come from a large amount of different backgrounds.
- I wonder how hard it is (or if it is even possible) to build a compiler for Jux, instead of an interpreter.
- I wonder if it might be possible to (a version of) the Actor Model to the core language, without making the language ridiculously hard to implement. I would really love to do this; bring the Actor Model to a lot more places.
- I wonder if it might be possible to change the language to be more strongly-typed, which might improve speed and explicitness (without making the language a lot harder to implement).
- I wonder what a proper way to do FFI(Foreign Function Interface, calling parts of the host language from within Jux) would be.
Well, if you’ve read so far, you’ve made me very happy. I really wanted to share this idea with some other people, because one person can only think in a single way about a problem. I really look forward to any and all comments about this .