Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing a Forth

ratfactor.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Implementing a Forth

#41

Post by alexisread »

ofalkaed wrote: post #39
johnisgood wrote: post #37

Earlier quoted context omitted.

So if it is documented well, then it would be suitable for large-enough programs? Or do you have any tips?

I think it can work but it takes a different way of looking at things. The main thing is that you need to take the time to design that DSL from the start and stick to it, if you come to a place where the DSL can not do what you want you need to address the issue with the DSL instead of just falling back onto the underlying Forth. It is a very different way to program and at times you find yourself have to make massiv…

That's a nice take. Implicitly though, that implies treating words not as functions but as coupled routines, possibly because forth is untyped.

If anything goes wrong during development you need that model of the stack in your head to debug- I think that's the main differentiator, and if you had a typed forth with local variables, it would enable greater readability ie. I can scan the individual words/ functions without needing that stack model.

Just my POV, not sure if that resonates?

Re: Implementing a Forth

#42

Post by novosel »

jes5199 wrote: post #25
whobre wrote: post #7

I am under impression that more people implement Forth than use it for programming...

there's a myth I know where the true Forth enthusiasts end up making their programs so pure that they start needing their own special hardware (in one version, I heard that machine words were all 13 bits), their own networking stack, their own communication apps. Until eventually they transcend into a second internet, populated only by forth hackers, where everything is optimally elegant. and that's why we don't hear…

[Drinks] O true apothecary! Thy drugs are quick. Thus with a KISS I die. [Dies]

((One W. Shakespeare Romeo and Juliet.))

Re: Implementing a Forth

#43

Post by michelpp »

john-tells-all wrote: post #12

I adore the `Threaded Interpretive Languages` book! It very clearly describes the internals of a real language, and variations on how to get it all done. https://archive.org/details/R.G.LoeligerThreadedInterpretive...

Mastering Forth is also an excellent book and gets deep into the subject with very clear writing and excellent diagrams.

https://archive.org/details/mastering-forth-by-anderson-anit...

Re: Implementing a Forth

#45

Post by entaloneralie »

kragen wrote: post #40
entaloneralie wrote: post #38

Earlier quoted context omitted.

It's useful for programming with functions to return many elements at once. I program in forth for a living, and that has been one of my favourite advantage, multiple returns without unecessary re-bindings.

I thought you fixed a sailboat for a living :)

That's where all my savings are going, same difference Kragen ;)

Re: Implementing a Forth

#46

Post by ofalkaed »

alexisread wrote: post #41
ofalkaed wrote: post #39

Earlier quoted context omitted.

I think it can work but it takes a different way of looking at things. The main thing is that you need to take the time to design that DSL from the start and stick to it, if you come to a place where the DSL can not do what you want you need to address the issue with the DSL instead of just falling back onto the underlying Forth. It is a very different way to program and at times you find yourself have to make massiv…

That's a nice take. Implicitly though, that implies treating words not as functions but as coupled routines, possibly because forth is untyped. If anything goes wrong during development you need that model of the stack in your head to debug- I think that's the main differentiator, and if you had a typed forth with local variables, it would enable greater readability ie. I can scan the individual words/ functions with…

Forths can have local variables, both ANS Forth and gforth have them and if your forth does not have it you can make your own or possibly just include gforth's if your forth is compatible. Keeping track of the stack becomes second nature and all but the simplest implementations have great tracing and debugging if you get lost.

Forths can also have types but it is slightly different, gforth has a float stack with its own commands and you can implement others and any other feature you want.

Once you get used to working global and without type it gets surpringly easy, it is more difficult for me to work with type and scope than without and when I use something like C I am constantly fighting it and feel like erything is needlessly complicated.

Re: Implementing a Forth

#47

Post by ndiddy »

johnisgood wrote: post #24
kabdib wrote: post #19

Earlier quoted context omitted.

we used FORTH extensively in the bring-up of the Atari ST. it was easy for the hardware engineers to come up with little fragments of FORTH so they could exercise their chips without needing much support from the software team FORTHs are fun to write. they'll teach you a lot about ruthless simplicity i don't think FORTH is useful for large programs, but that's not the point of the language

Why is it not useful for large programs (if you keep your words small)? What about Factor?

There's no compile-time error checking and words can push/pop arbitrary amounts of data to/from the stack. This means that if a program grows beyond the point where you can keep the whole thing in your head, it's a nightmare to maintain since bugs like giving a word the wrong number of parameters can cause a cascading series of errors that's challenging to unravel. I don't think it's a coincidence that Forth advocates have a philosophy of "if a problem's too complex, redefine the requirements so you can fit it all in your head". Personally, while I find Forth fun to write trivial programs in, I would rather write nontrivial programs even in assembly than in Forth.

Re: Implementing a Forth

#49

Post by s-macke »

astrobe_ wrote: post #23
s-macke wrote: post #3

Not sure if this counts as an implementation, but this is my Forth compiler, written in the high-level language Go [0]. This is also a challenge, as Forth usually requires machine language, call stack access, and is naturally written in assembler. Took several tries until I found working data structures. The funniest thing is, you can easily write and invent your own control structures in Forth, as well as change the…

> This is also a challenge, as Forth usually requires machine language, call stack access, and is naturally written in assembler. Not really. Many implementations indeed do that, but only in pursuit of performance - the weakness of interpreted languages is speed. Otherwise one can just implement it as a bytecode interpreter, like e.g. Lua.

My code uses some kind of very abstract byte code in a global

    heap  []any
structure (threaded code). "any" can be different types including Go functions. But most of them are pointers as usual in Forth.

Re: Implementing a Forth

#50

Post by stevekemp »

firesteelrain wrote: post #31

Could you use the Crafting Interpreters book as a guide to build a Forth interpreter? https://craftinginterpreters.com/

You can start way simpler than that, as forth won't need an AST or a complex parser.

See this repository for a tutorial-approach to building a minimal forth-like language, in golang:

https://github.com/skx/foth

Post reply on HN