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

Writing a Forth in Haskell

reinvanderwoerd.nl

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Writing a Forth in Haskell

#41

Post by Marazan »

andybak wrote: post #40

Can anyone point me to a Forth implementation where the absolute bare minimum is written in (C/assembly/whatever) and everything possible is then bootstrapped in Forth itself? I recall reading what the minimal word set needed to be able to write the rest of standard Forth (Fig Forth if I recall) but I seem to remember that most implementations don't push the purity quite that far for performance reasons.

Jonesforth is pretty minimal bootstrap

https://rwmj.wordpress.com/2010/08/07/jonesforth-git-reposit...

Re: Writing a Forth in Haskell

#42

Post by zevv »

andybak wrote: post #40

Can anyone point me to a Forth implementation where the absolute bare minimum is written in (C/assembly/whatever) and everything possible is then bootstrapped in Forth itself? I recall reading what the minimal word set needed to be able to write the rest of standard Forth (Fig Forth if I recall) but I seem to remember that most implementations don't push the purity quite that far for performance reasons.

Self promotion: https://github.com/zevv/zForth

zForth is yet another Forth, but with some special features not found in most other forths. Note that zForth was written for engineers, not for language purists or Forth aficionados. Its main intention is to be a lightweight scripting language for extending embedded applications on small microprocessors. It is not particularly fast, but should be easy to integrate on any platform with a few kB's of ROM and RAM.

Re: Writing a Forth in Haskell

#43

Post by spelc »

coliveira wrote: post #15
Karrot_Kream wrote: post #13

Earlier quoted context omitted.

In addition to other comments: Forth is a really cool language, but has the pitfall of trading time for space. It's a very lean language, and incredibly dynamic, but its heavy reliance on jumps makes it run slowly on modern hardware and thrashes most branch predictors.

Modern CPUs are optimized for C code. This is not the fault of FORTH, but it certainly is a problem for its adoption.

Over the last twenty years or so, I have written serious Forth code generators for six CPU architectures. There's only one code generation algorithm that's not regularly present in most Pasgol family compilers. The results are the VFX Forth systems at http://www.mpeforth.com.

Re: Writing a Forth in Haskell

#44

Post by throwaway7645 »

rwmj wrote: post #39
throwaway7645 wrote: post #31

Earlier quoted context omitted.

Good advice...yea I remember you saying you weren't using Forth anymore a year ago. What new language are you looking at?

The new language is also a toy, but it's based on SML, Lisp and others.

Gotcha. I was originally assuming OCaml based off of your site.

Re: Writing a Forth in Haskell

#45

Post by lacampbell »

kazinator wrote: post #29
lacampbell wrote: post #25

Earlier quoted context omitted.

Even at the most basic level, Forth and lisp are quite different. Lisp has grouping and evaluates using a tree. forth has no grouping* and evaluates completely linearly. * well you can hack it to give it grouping, but usually it doesn't.

Lisp's abstract model doesn't use stacks to pass arguments. Arguments are just lexical variables and they live in environments like other lexical variables: completely foreign stuff to Forth. Environments often have to survive the termination of a lexical scope's execution; it is required when a closure has escaped. So things can't even be compiled to a stack-based machine, using a "pop everything when returning" str…

I had this dumb idea of actually evaluating LISP in a forth inspired way. It would be a stack of subroutine/accumulator pairs. so given

    (+ 1 2 3)
"(" would pop an pair on a stack, + would set its subroutine, and 1 2 3 would be fed to the subroutine and accumulate a value. when ) is encountered, the data is fed into the subroutine/accumulator pair lower on the stack, so you could still have nesting.

Horribly inefficient, but I thought the idea was neat. I'm sure I'm not the first to think of it though.

Re: Writing a Forth in Haskell

#46

Post by pedrow »

gerdesj wrote: post #19
jacquesm wrote: post #11

Earlier quoted context omitted.

Forth is probably the smallest true high level language there is. It is entirely self-contained, needs just about nothing in terms of hardware support and can run in as little as 2K of memory. It is well suited to things like real-time control, you'll probably have a hard time getting used to stack manipulation (especially in the beginning) and it tends to keep you up all night (not sure if that is a strength or a we…

I remember writing a fairly trivial program in Forth on a ZX81 for a school open day. You needed the 16K RAM pack thing with the usual lump of Blu Tac to stop it wobbling. When I "discovered" Forth, it seemed like science fiction (soo fast!) to me after BASIC juddering around the screen.

Probably worth mentioning the Jupiter Ace here[0] - a ZX81/Spectrum era computer which had Forth in ROM, instead of BASIC which was common at the time. The basic model only had 1K of RAM. I never used one but I remember when it came out, reviewers commented on its speed and memory efficiency.

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

Re: Writing a Forth in Haskell

#47

Post by Gracana »

andybak wrote: post #40

Can anyone point me to a Forth implementation where the absolute bare minimum is written in (C/assembly/whatever) and everything possible is then bootstrapped in Forth itself? I recall reading what the minimal word set needed to be able to write the rest of standard Forth (Fig Forth if I recall) but I seem to remember that most implementations don't push the purity quite that far for performance reasons.

In addition to what others have linked, look up "moving forth," which is a series on porting forth... It covers the low-level bits that you'd need to port to run Forth on a new platform.

Re: Writing a Forth in Haskell

#48

Post by ruste »

flavio81 wrote: post #37
moomin wrote: post #2

Surely you just take an existing LISP implementation and call "reverse" at the correct location in the code? :p

Forth uses a stack machine. In this way, since calls to functions are really simple and easy, higher performance can be achieved. I love Lisp, but what you suggest is not really Forth and will also not give you the performance benefits and simplicity of implementation that Forth has.

I think he was joking.

Re: Writing a Forth in Haskell

#49

Post by Karrot_Kream »

spelc wrote: post #43
coliveira wrote: post #15

Earlier quoted context omitted.

Modern CPUs are optimized for C code. This is not the fault of FORTH, but it certainly is a problem for its adoption.

Over the last twenty years or so, I have written serious Forth code generators for six CPU architectures. There's only one code generation algorithm that's not regularly present in most Pasgol family compilers. The results are the VFX Forth systems at http://www.mpeforth.com .

I've looked over your products over the years and been super impressed by your results. Thanks for all your hard work!

Re: Writing a Forth in Haskell

#50

Post by moomin »

ruste wrote: post #48
flavio81 wrote: post #37

Earlier quoted context omitted.

Forth uses a stack machine. In this way, since calls to functions are really simple and easy, higher performance can be achieved. I love Lisp, but what you suggest is not really Forth and will also not give you the performance benefits and simplicity of implementation that Forth has.

I think he was joking.

:)
Post reply on HN