I agree with you in that aesthetically and psychologically, the syntax of MANOOL is not the prettiest thing. But as I already commented, it is a result of trade

I agree with you in that aesthetically and psychologically, the syntax of MANOOL is not the prettiest thing. But as I already commented, it is a result of trade-offs, and the syntax aesthetics is simply not the main point of the language. Any language whose syntax is more semantic-tailored would almost always look better. However, in turn, we gain homoiconicity and syntactic macros, which is not simply a nice-to-have feature but a huge expressiveness boost, as they are already used to introduce useful constructs without clobbering the core implementation written in C++. Now: whether one can afford the advantage and pay the price on syntactic level is up to once's use case. Of course, we could still support homoiconicity given almost any grammar (think about Dylan or any language that formally has syntactic macro features... Julia? Rust?), but then there is another trade-off: the mapping "plain text -> AST" and the language itself would be much more complex (and the implementation simplicity is the ultimate goal of the MANOOL project that sometimes even goes in parallel with other appealing goals). As I have commented, personally, I had to struggle with myself once I devised the context-free grammar for MANOOL after a lot of experiments and realized that actually there were no much room for improvement given the constraints. However, surprisingly, I accustomed myself quite quickly (which I would not say it is always the case for authentic S-expression-based languages as LISP advocates suggest). After all, MANOOL is an intermediate point between S-expression-based languages and "normal" languages. Compare: Scheme: (define Fact (lambda (N) (if (= N 0) 1 (* N (Fact (- N 1))))) ; a lot of closing parentheses here ; use Fact Python: def Fact(N): if N == 0: return 1 else: return N * Fact(N - 1) # use Fact MANOOL: { let rec { Fact = { proc { N } as : if N == 0 then 1 else N * Fact[N - 1] } } in -- use Fact } Note that in the past, personally, I would prefer rather an "absolutely beautiful" Ada/VHDL/PL-SQL syntax: if ... then ... else ... end if; -- "very" explicit terminator and: while ... loop ... end loop; -- ditto Note that also, personally, I do not like the Python/Nim/Occam approach to code indentation, but that's a whole new (orthogonal) story, and if you like, I could expose my rationale separately... But here we are gradually approaching the story of ":". Note that ":" is a punctuation sign that does not has the usual meaning, as e.g., in Python, or even natural languages. Once upon a time, someone suggested me that if you have an "if" with two branches, one short and another much longer, the shorter branch should appear visually first. In practice, that worked well for me. It apparently has to do with a "stack" in our brain. Another observation I had is that the Ada syntax, however "elegant" as it may seem with short examples, may quickly become ugly as the code complexity raises. And the problem is the excess of indentation (well, to mitigate that, some would suggest creating abstractions and name things, but personally, I would prefer to avoid naming things as long as I can, without going into extremes of combinatory logic-based programming ;-). So, I though, maybe the authors of Algol-60 (and Pascal) were right, maybe I could write better, say: for I := 0 to 99 do if A[I] = Value then {note the lack of indentation} Found := I; ... and that is the point of those colons in MANOOL: instead of writing: { for ... do { if ... then ... else ... } } one can write: { for ... do : if ... then ... else -- note that ":" is aligned with the braces since their syntactic roles are very similar ... -- but anyway MANOOL is a free-form language } Note that those colons are actually a means to get some "right-associative" syntax rules in the language (which are useful in the cases mentioned above).