rusini

Syntax-wise, MANOOL is a homoiconic programming language. It has its advantages and drawbacks, as everything, but it is definitely not designed to cause first good impression to those who are not familiar with such concept (seen, e.g., in CommonLisp, Scheme, or Clojure, which are considered incomprehensible by some people).

But what do you think about the article idea itself (apart from the syntax matters as it is orthogonal anyway)?

IMHO, the language size DOES matter and IS related to the language complexity and especially the syntax complexity. However, I believe many designers ARE aware of complexity issues and many languages turn into a mess only with time. BTW, I have designed a PL with a syntax, which is specifically designed to be not-prone to this syntax complexity problem as the language evolves.

There's also general philosophical advice that one should use the LEAST powerful tool for a task among all viable options. Many, especially newbie, developers just don't get it.

So, in general Wirth is right. But he is also known for oversimplifying his "50-page" language reports, and according to my experience, 50 pages is not sufficient to specify precisely even a small (but useful) PL. One such well-known lack of precision is nominal vs structural type equivalence in Pascal.

I know :) And that's cool, and that property is the base of my own programming language. I am also trying right now to find some explanation why it's cool based on some fundamental conclusions from theoretic computer science...

I just feel that when someone says that Lisp does not have syntax or that syntax is not important, it's plain wrong...

And even Scheme.

The syntax of S-expressions is the syntax. It's a form to serialize trees (made out of pairs) and it is described by some grammar.

I have designed a programming language that borrows an important part of its architecture from Lisp(s) (maybe mostly Scheme, but also Kernel: http://klisp.org). However, I have always opposed to the concrete syntax of S-expressions (being mostly unable to be productive with it).

My arguments are not on the familiarity side (with the infix notation), but on the psychological one:

1. S-expressions are not the most simple, natural, or uniform surface form (as they claim); they do have syntactic sugar (quote, even lists themselves!, etc.), so why not to add some more sugar (but sufficiently abstract of course)?

2. Humans' brain has limited "stack" space (especially when closing parentheses); infix forms may "cascade" and do not consume the stack (equally machine on human, due to possibility of "tail recursion")

3. Lack of diverse "visual clues" for humans (note how most natural languages have 40-60 phonemes, and none less than 15)

4. S-expressions and homoiconicity are related but orthogonal features (so the homoiconicity argument is often not valid)

Having that said, when I finally managed to write a working 50+-lines program in Scheme, with "proper" indentation, I was just proud of it, and I said, "Wow, it looks cool!". But I am still on the side of the above rational arguments! My point is that as my experiment demonstrates, it is probably too easy to get on an emotional side of computer-human interaction once you accomplished something a bit challenging (like speaking in classic S-expressions)?

Wow, are we preparing for a global catastrophe?

This was quite unintentional as the main point is how amazingly bizarre it looks.

BTW I already had a publication on HN about MANOOL: https://news.ycombinator.com/item?id=20599209

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).

> no one wants to use GNU/AT&T assembler syntax

I am the one who enjoyed using AT&T syntax. It remainded me old-days PDP-11 assembler.

Well, what about this program?:

    -- factorial
    { {extern "manool.org.18/std/0.2/all"} in
    : let
      { Fact =
        { proc { N } as
        : unless N.IsI48[] & (N >= 1 - 1) signal
        {if (~)[N.IsI48[]] then TypeMismatch else InvariantViolation}
        else
        : var { Res = 1 } in
        : do Res after
        : while N <> 0 do Res = N * Res; N = N + ~1
        }
      }
      in
      Out.WriteLine[/* Out; */ "Factorial of 10 is "; Fact[10]$]
    }

It has absolutely all syntactic features and even makes sense!

Sorry, I did not had time to add that content (I was in hurry to show my work and at least make an intro, after 4 years of silence and hard work :-) BUT thank you for the suggestion! I will include those benchmarks shortly.

Refs to wikipedia help me to focus on using common terminology as much as possible (and I actually wrote the Intro also for some of my friends that do not understand what "programming" means if I do not speak of "computer programming" and add a link to wikipedia :-). BTW personally, I also find hyperrefs annoying aesthetically...

Thank your for commenting!

> 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" :-)