Hacker News Reader

Comment by RandomGuyDTB | Hacker News Reader

It's odd to highlight that Forth is 50 years old, considering C is 48 years old and still in very heavy use in operating systems development.

View on HN

Collapse OS was initially written in assembly for the Z80, a microprocessor first launched in 1976. The fact that Forth is 6 years older than the Z80 seems interesting enough of a step further back in time to be hightlighted.

I suspect that a lot of readers have no idea how old it is.

(I, on the other hand, have to be reminded that 50 years have passed.)

It's odd to compare C and Forth. They are so different.

Edit: as someone below mentioned there can not be a 'Standard Forth'. You just write your own one as you see fit.

There's ANS Forth. Chuck Moore doesn't like it, but it exists.

Perhaps Forth has changed less than C in that time. The C of 48 years ago can look quite different from modern C.

There has never been one Forth. In a world with N Forth programmers, one can expect roughly N implementations of Forth. Perhaps closer to 2*N. An ANS spec exists, but most Forth programmers would say it misses the point.

Forth is a collection of ideas and philosophies toward programming as much as it is a language. Two stacks and a dictionary. Threaded code (direct, indirect, token, subroutine, etc...). Collapsed abstractions. No sealed black boxes. Tight factoring.

C has changed. Forth is everchanging.

There has been OpenFirmware.

Well, shit... I've been a lil frustrated by a lack of a clear resource and consequentially haven't gotten far on a couple half-hearted attempts to learn it. I can just make it up myself? A little late in the weekend for a new project, but I'm suddenly interested again.

This is a slightly off topic question for you, do you think the attributes you named are required for having a “Forth” or are they just the most common implementation characteristics? My current pet language project certainly looks Forth-like, with different semantics and a modal dependent type system, but is not threaded nor does it have the traditional stacks and dictionary. I don’t know if I’d call it a Forth, but maybe it is?

"The dictionary" can be implemented in many ways; simple or clever, namespaced or not. A language without any form of local or global name binding would presumably need quotations ala Joy/Factor, which means your stacks probably have to store objects rather than raw numbers. This tips the scale in the direction of a higher-level language.

The stacks are likewise a description of semantics rather than implementation. Some Forths keep the top few stack elements in registers to reduce overhead. If the return stack isn't user-accessible (r> >r etc.) then, again, you're straying closer to a higher-level functional language than a Forth.

There are many kinds of threaded code. For example, subroutine-threaded code uses native subroutine call instructions in word bodies and does away with the inner interpreter. Threaded code is a natural consequence of disentangling conventional "activation records" into two stacks which grow and shrink independently. You could have a Forth without threaded code, I suppose.

Some Forths attempt to "seal off" or otherwise obscure some parts of their own internal workings from "user programs". This is more common among dialects which try to adhere to ANS specs, like GForth. This isn't a total anathema to Forthiness, but it tends to introduce additional complexity. If a word is useful for implementing a forth kernel, why couldn't it be useful in implementing other functionality, too?

If you're building something higher-level which vaguely resembles Forth, it's probably better to describe it as a concatenative language. A dependent type system doesn't sound very Forthy, imo.

"You could have a Forth without threaded code, I suppose."

VFX Forth from MPE UK is a native code generator. It evaluates source code and emits inline code or calls depending what you tell the compiler to do. It can expand everything to inline if you tell it but your code would get much bigger.

This is the state of the art for Forth compilers today.

Homemade systems and older systems use threaded code.

I have no affiliation with MPE.

I don’t think you’re wrong in your assessment. But just for fun I will point out that I probably assumed a bit to far when I stated no dictionary, there is a name binding mechanisms for ‘words’, but I have a quote form as well. Also, while I would say the language is functional, it is also intended to be low level, ideally, the base of the language is a dependently typed pseudo-assembly language, but the modal type system and homoiconic syntax enable building words that are semi-macros. It is, at this point, basically my attempt to blend Forth’s philosophical leanings with category/type theory. But thanks for the reply, outside perspectives are always great for me to hear.

Not really. Function definitions look different, and we can declare variables in the middle of function bodies, but those are surface-level changes. The language itself hasn't changed appreciably.

Not to mention lisp, in which HN is written.

Reply on news.ycombinator.com