> This immediately makes me want to read said postcard. Is there something to this effect? [Couldn't find it.]
I actually did not do such exercise, sorry :-) BUT: 1) almost all syntactic features are demonstrated in the first two examples/lessons in the wiki (and could be compressed further); 2) the formal context-free grammar can be found in the large PDF (caution: crude, work in progress!): https://github.com/rusini/manool/releases/download/v0.2-beta... It has only 25 rules. That's comparable with Smalltalk. Besides, Smalltalk was a source of inspiration for the syntax, since it is culturally a cousin of LISP, does not use S-expressions, but its syntax does allow for a kind of DSLs (think ... ifTrue: ...). MANOOL is similar in that respect, but its syntax is closer to S-expressions (allows you to express name bindings).
>I didn't see the advantage...
S-expressions have syntactic sugar to express lists: (A B C) -> (A . (B . (C . ()))) MANOOL has that and slightly more: infix/postfix operators (and one prefix), etc.: A[B; C] -> {A B C}, A + B -> {(+) A B}, {A: B C} -> {A {B C}}, A.B[C] -> {B A C}, etc... (it does not have dotted pair notation, but I hope the idea is clear).
That syntactic sugar is abstract and independent of what actually A[B; C] and A + B mean. The intention, for example, is that the syntax (at the context-free grammar level - surface syntax) does not need to change no matter what features we need in the future. It is said that context-free grammars are not modular: as the language evolves it is easy to introduce ambiguities (think C++). MANOOL approach does not suffer from that; features (like keywords if, while...) can even be made available selectively in a limited scope, if needed. I call it "universal grammar".
On the other hand, I strongly suspect that the resulting syntax is better than S-expressions "psychologically" (sorry LISP'ers :-). It is not a matter of our familiarity with infix notations (from mid school), but our brain has very limited "stack". Anyway, the point of MANOOL is not its syntax or homoiconicity; it was originally just a nice implementation strategy. The point lies deeper in some semantic features...
BTW that's not the first time that someone comes and suggests something to replace S-expressions and... fails. BUT one successful example is Smalltalk (albeit the result is not quite "homoiconic"), so that inspired me too.
As to why {} instead of ()... the main reason is that () had to be reserved for explicit grouping of subexpressions (just like in mid school or Smalltalk): (1 + 2) * 3. BTW that's why I had to use [] for "applications" and that might look ugly to people (but think about failed M-expressions).
As to optional ";", that was precisely one of those "design compromises" I am talking about. Personally, I am not a fan of "semicolon omissions" :-)