Live data from Hacker News

Implementing Forth in Go and C

eli.thegreenplace.net

21–29 of 29 posts

Re: Implementing Forth in Go and C

#21

Speaking of Forth... Here's a fun bit of trivia. PowerPC and Intel Macs used to use Open Firmware[0] to define their firmware (BIOS). Macs with M1[1] architectures and subsequent generations may also, but I cannot attest to this. For those Macs which do use Open Firmware[0], a key implementation component of it is FCode[2]: FCode is a Forth dialect compliant to ANS Forth, that is available in two different forms: sou…

There is no OpenFirmware on Intel Macs. They used EFI, which isn't related to any sort of FORTH.

That got the rest of X86/AMD64 world UEFI.

Whatever the M+ ARM based Macs use is totally unrelated, too.

Adieu to logic, uh? (Which LLM hallucinated that stuff for you?)

Re: Implementing Forth in Go and C

#22
post #12
post #2

Nice to see another developer who tried to implement Forth in Go (here’s mine: [0]). It’s not easy and usually takes several iterations. His implementation, while working for his use cases, is actually quite far from the originals. He uses separate Go structures for words, memory, for-loops, etc. Most of the default Forth implementations of words will fail, since they expect the heap and stack to behave in a certain…

One of your "Click to run" examples is called "faculty calculation". I'm not a forth expert but it looks like a factorial function. Is "faculty" a replacement for "factorial" in some contexts?

Thanks. Fixed it.

Re: Implementing Forth in Go and C

#23
post #15

I must say, implementing Forth in almost any high-level language, even C, can be awkward and almost antithetical. A "high-level" Forth implementation often merely presents a Forth-compatible runtime, which runs the risk of missing what makes Forth so unique and useful. (The author actually seems to understand this: "The first implementation I tried is stubbornly different. Can we just make a pure interpreter?") That'…

Ah, but which assembly? If you just roll a simple VM in the host language, your instruction set becomes the assembly Forth integrates so well with. I'm assuming that's what they did in their C implementation.

True!

I don't think that's what happening, though. At a quick glance, the primitive words seem to be directly implemented in C: https://github.com/eliben/goforth/blob/3949fe0cc52131fdcae0e...

So it looks like this one kind of sits in between. It has primitive words implemented in C, but a dictionary accessible by Forth. The interpreter loop however seems to be implemented in C as well, not Forth.

Re: Implementing Forth in Go and C

#24
post #15

I must say, implementing Forth in almost any high-level language, even C, can be awkward and almost antithetical. A "high-level" Forth implementation often merely presents a Forth-compatible runtime, which runs the risk of missing what makes Forth so unique and useful. (The author actually seems to understand this: "The first implementation I tried is stubbornly different. Can we just make a pure interpreter?") That'…

I agree, Lisp and Forth share this beauty of needing only a handfull of Assembly written primitives, and then the whole world can be bootstraped out of them.

Re: Implementing Forth in Go and C

#25
I like Forth, I am aware of its shortcomings though there is one I haven't seen mentioned: the good practice with forth is factorization, i.e. splitting words into small ones where stack juggling is rarely necessary. The enormous issue with this, not seen in other languages, is that all those words have to be named, and naming is well-known as one of the hardest things in computing.

What is a simple expression in C, for example, in Forth becomes half-a-dozen words which all have to be named, and it is an enormous productivity killer. Especially when doing maths, you would have to find a name for all the intermediate steps of an equation instead of simply doing:

  float x = (-b + sqrt(4 * a * c)) / (2 * a * c);

Re: Implementing Forth in Go and C

#26

Speaking of Forth... Here's a fun bit of trivia. PowerPC and Intel Macs used to use Open Firmware[0] to define their firmware (BIOS). Macs with M1[1] architectures and subsequent generations may also, but I cannot attest to this. For those Macs which do use Open Firmware[0], a key implementation component of it is FCode[2]: FCode is a Forth dialect compliant to ANS Forth, that is available in two different forms: sou…

There is no OpenFirmware on Intel Macs. They used EFI, which isn't related to any sort of FORTH. That got the rest of X86/AMD64 world UEFI. Whatever the M+ ARM based Macs use is totally unrelated, too. Adieu to logic, uh? (Which LLM hallucinated that stuff for you?)

>> PowerPC and Intel Macs used to use Open Firmware ...

> There is no OpenFirmware on Intel Macs. They used EFI ...

I thought I remembered playing with Forth at the boot prompt on an Intel Mac. I guess I was wrong and it was on a PowerPC Mac.

> Adieu to logic, uh? (Which LLM hallucinated that stuff for you?)

Human memory. Yours may be perfect in every recall, being the first human ever to be able to claim this miraculous ability, but I highly doubt it.

Re: Implementing Forth in Go and C

#27

Earlier quoted context omitted.

There is no OpenFirmware on Intel Macs. They used EFI, which isn't related to any sort of FORTH. That got the rest of X86/AMD64 world UEFI. Whatever the M+ ARM based Macs use is totally unrelated, too. Adieu to logic, uh? (Which LLM hallucinated that stuff for you?)

>> PowerPC and Intel Macs used to use Open Firmware ... > There is no OpenFirmware on Intel Macs. They used EFI ... I thought I remembered playing with Forth at the boot prompt on an Intel Mac. I guess I was wrong and it was on a PowerPC Mac. > Adieu to logic, uh? (Which LLM hallucinated that stuff for you?) Human memory. Yours may be perfect in every recall, being the first human ever to be able to claim this miracu…

SCNR with that username. Think of me as moody Marvin, if it helps ;>

Re: Implementing Forth in Go and C

#28

I like Forth, I am aware of its shortcomings though there is one I haven't seen mentioned: the good practice with forth is factorization, i.e. splitting words into small ones where stack juggling is rarely necessary. The enormous issue with this, not seen in other languages, is that all those words have to be named , and naming is well-known as one of the hardest things in computing. What is a simple expression in C,…

> ...you would have to find a name for all the intermediate steps of an equation instead of simply doing...

Trying to understand this. Do you mean the operators in your example (-, +, *, /) would need to be named?

If so, I agree one-off terms wouldn't make it a great calculator substitute. In fact, you'd probably end up doing equations similar to the RPN on some HP calcs [0] to get the order of operations correct - minus the handy physical +, /, etc buttons. But for programming, wouldn't you either assign the parts or the whole of the term to a word?

[0] https://en.wikipedia.org/wiki/Reverse_Polish_notation

Re: Implementing Forth in Go and C

#29
post #23

Earlier quoted context omitted.

Ah, but which assembly? If you just roll a simple VM in the host language, your instruction set becomes the assembly Forth integrates so well with. I'm assuming that's what they did in their C implementation.

True! I don't think that's what happening, though. At a quick glance, the primitive words seem to be directly implemented in C: https://github.com/eliben/goforth/blob/3949fe0cc52131fdcae0e... So it looks like this one kind of sits in between. It has primitive words implemented in C, but a dictionary accessible by Forth. The interpreter loop however seems to be implemented in C as well, not Forth.

I remember when I realized just how little host language code was needed to bootstrap a Forth. Before that I was making the same mistake.

OP, I strongly recommend the book Threaded Interpreted Languages [1]. I had to read chapter 2 several times before it clicked (short and dense), but it's an excellent resource.

[1] https://archive.org/details/R.G.LoeligerThreadedInterpretive...

Post reply on HN