[klibertp]

If you take a look at my reply to TazeTSchnitzel you'll see that I "solved" (I think? at least tried to) this problem with indentation (generally whitespace. You can delimit expressions in many ways.

And in Forth case, you can very easily define your own delimiters:

    : [ ;
    : ] ;

which should make you able to write:

    [ [ 1 2 + ] [ 3 4 + ] * ] . 
    21  ok

(tested with gforth and works [EDIT: but of course breaks Forth! Both [ and ] are already defined, so in practice you'd rather choose another chars])

I mean, there is no rule saying that postfix notation cannot provide grouping constructs. I still fail to see a fundamental difference here :)

BTW, it's not going as fast as I'd like, but I managed to parse TXR man page and use it for displaying docs along auto-completion: https://github.com/piotrklibert/txr-mode/blob/master/screen....

I think I'll be able to find some time this weekend (or next weekend) to clean up the code and make it usable for others as well :)

[kazinator]

Whitespace that is not significant to the machine does nothing to help me convince myself that the code is correct. Indentation could be wrong.

If I already know that the code is correct and properly indented, then it helps the readability.

> And in Forth case, you can very easily define your own delimiters:

Those delimiters do nothing but occupy interpreter cycles. Hopefully they get recognized as noops and optimized away by a Forth compiler.

The machine will accept garbage like:

  ] 3 2 + [ 4 /

The fake syntax you've created is there is sort of like a cargo cult airplane made out of bamboo sticks and palm leaves. It has some value as an annotation of correct code, that is all. It could be a useful annotation tool in the process of verifying a piece of code and convincing myself that it's correct. Forth should have these markers built-in so they don't have to be defined as words, and it should check their pairing and nesting. (A syntax highlighting engine can be taught to do that, of course.)

[klibertp]

> Whitespace that is not significant to the machine does nothing to help me convince myself that the code is correct. Indentation could be wrong.

A sloppily written code is hard to understand correctly in every language (to different degrees, of course). You can easily mistake

    if (...)
       do1();
       do2();

for

    if (...) {
       do1();
       do2();
    }

right? This is C - an infix language - and it's arguably its fault for providing this stupid form, but you usually don't judge how readable infix notation is based on this.

> Those delimiters do nothing but occupy interpreter cycles. Hopefully they get recognized as noops and optimized away by a Forth compiler.

I'd expect so.

> The machine will accept garbage like: > ] 3 2 + [ 4 /

Yup. And by the way, this garbage is actually nearly correct J code. One possible fix would look like:

       ] 3 2 + [ 4 (+ /) [ 4

this gives `10 11` as an answer (and please don't ask me why...). ] and [ are left and right identity functions, they simply do nothing, so they may be inserted in many places, in many cases interchangeably.

> Forth should have these markers built-in so they don't have to be defined as words, and it should check their pairing and nesting.

That's unnecessary in Forth, I'm sure you can implement a "real" - with a semantic meaning - grouping in Forth yourself. Comments in Forth are enclosed in parens, and the parens are normal Forth words, defined in Forth. I mean, it's already a grouping syntax with a DROP semantics; you can probably define grouping syntax with other semantics as well.

Also, in Forth there are only words, and the syntax is that simple, but that isn't a property of all postfix languages. We're talking about postfix as a notation in general, not about it's particular brand practiced by Forth. This is why I keep mentioning J, again and again: it's an infix language. I could bash infix notation forever had I used J as an example! It's the same with postfix notation and Forth.