Finishing study of Axiom to Aldor
While writing a parser I found out how many how complex syntax and structure Axiom had. I ended up dropping the plan of writing an interpreter for this language.
When reading on Axiom I also ended up reading about Aldor. It appears to be a revision to the extension language used by Axiom.
I found a paper and a guide on Aldor:
The user guide explains all the constructs so well that I don't feel any need to search further explanation elsewhere. Many of them appear to be the same as in Axiom so it also helped to understand those.
The take-away
Aldor & Axiom are doing a much better job with their type system than what the modern Java or Python does. I think this has to do something with the problem they are attempting to solve.
Object oriented programming attempts to provide a tool to add architecture into programming. It introduces a lot of complexity with the assumption that it would be useful.
Axiom introduces complexity in order to solve a problem that is present when you should create code for symbolic algebra that interacts meaningfully.
Highlights
Aldor uses _ character as an escape instead of backslash.
Aldor associates types to variables and expressions rather than values.
New types appear to be constructed as abstract data types by
shadowing existing types. x @ MyType pretend Rep converts
out of the abstract data type and the y @ Rep pretend MyType
converts into the abstract data type. The 'at' symbol is
treated as type check, and 'pretend' is a reinterpreting type cast.
In this kind of a language the abstract data type -construction ensures that the previous value is not treated the same way as what represents the type in the system. It is important because the behavior that you want might interfere with the existing behavior of the representation.
The type domains and categories can retrieve any kind of parameters, including constants. The type appears to be resolved before evaluation happens though.
Z <: Y <: X <: REPRESENTATION| | || || categories
You are allowed to extend types from existing ones in the same way it happens with object oriented programming languages, but the extension from more than one object at a time does not make sense and cannot be done. Instead you use categories to specify whether the type is suitable for a specific use case. The category specifies the behavior and properties of different operations in the type.
There is no correspondence to the category theoretic categories here though.
Every type and category is associated with an operator table. The operator table is exposed when the type is used in a function, and the implementation for each operation done is retrieved from those tables.
This old language has something to provide syntactically as well. It allows you to stack iterators.
while n ~= 1 for free k in 1.. repeat {if odd? n then n := 3*n + 1 else n := n quo 2;}
Additionally you can use these same iterators to create lists, for example, here's an example of a cartesian product:
[i * j for i in h for j in k]There are some other languages that allow the same stacking, but in Axiom this system gives a nice association between generators and loops. The treatment where these forms are using the same syntactic element give it a nice algebraic feel.
Additionally the language has a format for reducing a list that's quite pretty:
*/[1, 2, 3]That produces 6 as an answer. It's not pretty that it uses
the division symbol for this purpose, but it's pretty that
the language had a notation for this kind of purpose.
Later
The things I learned from here was valuable but for now I am going to leave these two languages alone.
I will eventually resume to see how Axiom implements the computer algebra so that I get some references and cues for solving the details out in my own type system.
It will be soon. Meanwhile I'm studying more category theory to be better prepared for understanding the problems that arise.