💾 Archived View for yonado.cities.yesterweb.org › writings › 15.8.2024.gmi captured on 2024-08-18 at 16:57:06. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Aluco is the name of a programming language I personally designed. It was inspired by Forth, Ruby, and a bunch of other stuff I can't remember.
Aluco is a concatenative language, probably. Like Forth. I like the idea of concatenation. The language is made up of operators, that was the basic idea that spawned the language. Everything is an operator in Aluco.
And, like the operators in any other language, the operators in Aluco are all built-in to the language. They're not like Forth words. In Aluco everything takes place in one or more thread(s) of concatenation, a thread for short.
So, in every thread there are two variables, LHS - Left-hand-side, and RHS - Right-hand-side. As you might guess, these store the values that each operator operates on. Operators can differ, they can use either the LHS or RHS only, or both, or none.
After an operator is ran, you should expect the value in the LHS to change. The RHS is an entirely temporary variable, so it doesn't change at all. After the LHS has changed, you can use it again without specifying any literals to use it with an operator again. Enough blabbering now, let's see some examples.
(1 + 2 + 3 + 4)
Each thread begins with a parentheses and ends with a closing parentheses. By typing a literal, you put that literal into the LHS. Any literals that come after an operator are put in the RHS.
In that example, we put 1 into the LHS and then 2 into the RHS. We use an addition operator. The operator puts the added results of the LHS and RHS into the LHS, in fact, every operator that uses both LHS and RHS should do that. Then, we use the LHS implicitly in the next operator. We put 3 into the RHS and tell the addition operator to do it all again. Finally, we use the LHS implicitly again with an RHS of 4 to get the final result into the LHS, which is 10. So, after all that the LHS ends up with 10.
We can continue using operators on the LHS implicitly, mutating the LHS as we go. This is why I called the language concatenative.
Here's a problem though. If we only have the LHS and RHS, then how can we do
1 + 2 * (3 + 4)
?
Well, that's what the threads are for (among other things). Threads store the LHS and RHS, so by starting a new thread we can effectively get another LHS and RHS.
(1 + 2 * (3 + 4))
Additionally, the LHS of a thread after it ends can be used as the LHS or RHS in the parenting thread, like in the example above.
Now, I hear you asking "why not just use a stack like Forth?" Well, various reasons.
The first reason is because the threads are waaaayy more readable than Forth's polish notation. The second reason is because we wouldn't need annoying stack manipulation like we do in Forth. Stack manipulation is pretty much the thing that breaks Forth for me. It's not fun to manage your stack. The third reason is because threads have more functionality than
Forth.
Any operator may "end" a thread, that is, by skipping all the code in the thread and continuing from the end, into the parenting thread or whatever else. This means we can use threads for control flow. Consider this psuedo-code:
(1 + 2 == 3 if? "1 + 2 == 3" is-printed)
1 + 2 gets put into the LHS. LHS == 3 puts a true or false result in the LHS. The LHS if? operator sees if it's 0, and if so it ends the thread.
So, operators may operate only within their thread. They're entirely caged in whatever thread they were invoked in.
Variables in Aluco are easy. All you have to do is write ->variable_name and the LHS will get stored into variable_name.
(1 + 2 ->result) (result == 3 if? "result contains 3" is-printed)
Let's replace this psuedo code with actual operators. I've thought up of some:
(1 + 2 ->result) (result == 3 ? "result contains 3" ,)
or
(result == 3 ? "result contains 3" .)
The . operator prints a string in the LHS without adding a newline at the end. The , operator does the same but adds a newline.
Aluco has two data types only. It has a number and an array. Arrays are just lists of numbers. Strings are also arrays. That's all there is to it.
The final thing I wanna talk about is what Aluco is meant to be. So, I can make my own Aluco with all the stuff I want in it (i.e. all the operators and misc. features), and YOU can also make your own Aluco with what you want in it.
You want a mathematical Aluco? Aluco for games development? Aluco for solving Advent of Code at a non-human speed? Go ahead. There is not one Aluco, but if you want an Aluco then stay tuned because I'll probably publish one soon to the capsule.
Forth is like this aswell, and I admired that aspect of Forth. Of course, Forth is infinitely easier to implement than Aluco (which is why there are so many Forths out there) but Aluco is still a relatively easy language to implement with not alot of syntax.
The basic idea of threads and operators are outlined in this writing. All you need to do is have these in your language for it to be like Aluco.
Also, Aluco is meant to be an all in one language. You get everything in an Aluco.
Here's some psuedo-code to get a better idea of Aluco.
("Hello, world!" ,)
So, there's no recursion allowed in my Aluco, so we'll have to use a non- recursive implementation.
(20 ->n 0 ->a ->temp 1 ->b) // n is the fib number (0 to-loop n // to-loop is a loop that goes from X to Y, like a for-loop b ->temp b + a ->b temp ->a) (a ,)
([1 2 [1 2 3] 4 "string"] ,)
(10 ->n 1 ->f) (loop (n <= 0 ? break) f * n ->f n - 1 ->n) (f ,)
Well, if you have any suggestions on the language, you can drop me an email.
Again, Aluco is supposed to be your own. As for my Aluco, I might make some changes to the one used in this writing. We shall see when the implementation (hopefully) gets finished.