Hacker News Reader

Comment by tom_mellior | Hacker News Reader

So, looking at some examples on rosettacode.org... This is basically a Smalltalk dialect, which is good. But it is also, completely needlessly, a Forth dialect. So instead of Smalltalk's statement separator (the period), you "end" statements by "dropping" some value.

That is, instead of:

    foo doSomeThing.
    bar doSomeOtherThing

you write:

    foo doSomeThing drop bar doSomeOtherThing

Why?

It also has named variables (which some Forth purists don't like), but instead of the reasonable Smalltalk syntax of

    x := baz compute: #something

it uses

    baz compute: #something ->x

for assignment.

Why?

This might eventually turn into a nice programming language, all it needs to do is drop (haha) some of the Forth baggage and admit to itself that its Smalltalk subsystem has everything one needs.

View on HN

The "drop" is not a statement terminator or separator.

There is a stack. You push values on the stack, then you call a function. The function takes its arguments off the stack, and pushes the return value(s) on the stack.

If you do not need the return value (which seems to be the case in your example) you ignore it by just removing it from the stack.

That's what the drop is for.

I know. De facto it's for separating parts of the computation ("statements").

The -> syntax plays nicely with the stack nature of the language. It's basically just a word that pops TOS, and as a special effect it introduces a name with that value. (IIUIC, I didn't study the language.)

The greater point I'm making is that the language does not have a "stack nature" in any real or useful sense.

It has implemented syntax superior to Forth's by using variables and by using Smalltalk-like keyword (i.e., infix) syntax. Yes, there is a remainder of Forth-like stack syntax for expressions. It's ugly, jarring, hard to understand, and comes without any advantages since the Smalltalk-like parts require the language to use a real parser anyway!

The number of "Smalltalk-like" keywords is limited and this is not a syntax : they are executed like any other words.

imo you're overestimating the "smalltalk-like" part, as it is mainly word naming conventions (a ':' at the end of some words to show that something is required after) and not syntax. The "something" required after is read from the input stream as a part of the word's execution (like many Forth words).

There is no "real parser" : the parser is like any Forth parser ie one word at a time separated by blanks.

In fact, it is an Forth-like interpreter with immediate words and parsing words that use the stack structure a lot.

I guess you know a lot more about this than I do. But maybe you are overestimating the Forth-like part?

> There is no "real parser" : the parser is like any Forth parser ie one word at a time separated by blanks.

> In fact, it is an Forth-like interpreter with immediate words and parsing words that use the stack structure a lot.

Looking at an example like

    : catalan(n) n ifZero: [ 1 ] else: [ catalan(n 1-) 2 n * 1- * 2 * n 1+ / ] ;

(from http://rosettacode.org/wiki/Catalan_numbers#Oforth) it seems like, if what you say is true, then : must be a parsing word that not only reads "catalan(n)" but also somehow decomposes it in a way and sets things up such that the later call "catalan(n 1-)" is understood correctly even though "catalan", "(", and "n" are not separated by whitespace. It very much looks like there is some tokenization going on.

Also, is "ifZero:" really a separate message from "else:", i.e., or is "ifZero:" also a parsing word that looks if what follows is a well-formed expression followed by "else:"?

If you have parsing words everywhere, you have a parser. It may not be a classical parser where everything is written in one place, but it's a parser nonetheless.

I don't think there's anything wrong with implementing a Smalltalk dialect in Forth, with lots and lots of parsing words, and compiling the Smalltalk surface syntax to stack-based Forth code on the fly. That's lovely. It's just a shame to expose the underlying Forth in the surface syntax...

>Looking at an example like

> : catalan(n) n ifZero: [ 1 ] else: [ catalan(n 1-) 2 n * 1- * 2 * n 1+ / ] ; >(from http://rosettacode.org/wiki/Catalan_numbers#Oforth) it seems like, if what you say is true, then : must be a parsing word that not only reads "catalan(n)" but also somehow decomposes it in a way and sets things up such that the later call "catalan(n 1-)" is understood correctly even though "catalan", "(", and "n" are not separated by whitespace. It very much looks like there is some tokenization going on.

You are right, I forgot to say that the following characters stop the parsing of a name : { } [ ] ( ) | This is a difference with a classical Forth interpreter.

The call to catalan( n 1- ) is just sugar, the interpreter replace it by : n 1- catalan. It is not related to how : works.

The following definition is exactly the same : : catalan( n ) n ifZero: [ 1 ] else: [ n 1- catalan 2 n * 1- * 2 * n 1+ / ] ;

>Also, is "ifZero:" really a separate message from "else:", i.e., or is "ifZero:" also a parsing word that looks if what follows is a well-formed expression followed by "else:"?

Yes, ifZero: is really a separate word from else: . It is the same structure as the Forth structures :

if then

if else then

the if does not know if there will be a then or a else and is not a parsing word. This is the same with ifZero:. It is not a parsing word and it is the else: word that do the job.

By the way, you can see the definition of all these words in the prelude.of file (they are all written in Oforth).

>If you have parsing words everywhere, you have a parser. It may not be a classical parser where everything is written in one place, but it's a parser nonetheless.

Not much more than in a classical Forth, where you find lots of parsing words too. I have no problem to call this "a parser". I'am just saying that there is nothing different from a classic Forth.

> I don't think there's anything wrong with implementing a Smalltalk dialect in Forth, with lots and lots of parsing words, and compiling the Smalltalk surface syntax to stack-based Forth code on the fly. That's lovely. It's just a shame to expose the underlying Forth in the surface syntax...

All the ifTrue:, else:, ... are not parsing words. There are not "lots and lots" of parsing words, at least not much more than in a classical Forth. There is nothing to do with the Smalltalk messages mecanism. There is nothing more here than a "if else then" Forth structure...

Thanks for this explanation! I understand much more clearly now. And I must admit I'm a bit disappointed :-(

Reply on news.ycombinator.com