Live data from Hacker News

Implementing a Forth

ratfactor.com

51–60 of 70 posts

Re: Implementing a Forth

#51
Problem with Forth and Lisp is that you can freely start to improve language, so it sort of destroys the usefulness in a company of full of Salarymen and Office Droids.

Here is Grok's scheme to make Forth more readable:

  Below is a Forth implementation of a simple parser that transforms
  (. (+ 1 2)) into 1 2 + . and executes it. This assumes the input is
  provided as a string or entered interactively, and the parser outputs
  the transformed Forth code to the input stream for execution.
  
  
  \ Buffer to store transformed output
  20 CONSTANT BUF-SIZE
  CREATE BUF BUF-SIZE ALLOT
  VARIABLE BUF-PTR
  
  : INIT-BUF ( -- )
    BUF BUF-SIZE ERASE
    0 BUF-PTR ! ;
  
  : ADD-TO-BUF ( c -- )
    BUF-PTR @ BUF-SIZE  WHILE
      OVER C@ CASE
        '(' OF DROP 1 /STRING ENDCASE  \ Skip (
        ')' OF DROP 1 /STRING ENDCASE  \ Skip )
        '.' OF BL ADD-TO-BUF '.' ADD-TO-BUF BL ADD-TO-BUF
               DROP 1 /STRING ENDCASE
        '+' OF BL ADD-TO-BUF '+' ADD-TO-BUF BL ADD-TO-BUF
               DROP 1 /STRING ENDCASE
        BL OF BL ADD-TO-BUF DROP 1 /STRING ENDCASE  \ Handle spaces
        ELSE
          DUP ADD-TO-BUF  \ Copy number characters
          DROP 1 /STRING
        ENDCASE
      REPEAT
    2DROP ;
  
  : EVAL-EXPR ( addr u -- )
    PARSE-EXPR
    BUF BUF-PTR @ EVALUATE ;  \ Execute the transformed string
  
  \ Example usage
  : TEST ( -- )
    S" (. (+ 1 2))" EVAL-EXPR ;
  
  TEST

Re: Implementing a Forth

#52

Problem with Forth and Lisp is that you can freely start to improve language, so it sort of destroys the usefulness in a company of full of Salarymen and Office Droids. Here is Grok's scheme to make Forth more readable: Below is a Forth implementation of a simple parser that transforms (. (+ 1 2)) into 1 2 + . and executes it. This assumes the input is provided as a string or entered interactively, and the parser out…

Bloody Grok does not seem tobe able to make generic parser, so that Forth whitespace requirements can be ignored. When said I want "Pascal-type" tokenizer, it started to print Pascal-language compiler, which was amazingly complex and long. I cannot imagine many humans can produce that much Forth and survive.

Re: Implementing a Forth

#54
I have made a living with Forth since 1981. I have written very few new Forth kernels, but have ported them to many CPU architectures. Forth is no longer fashionable, but it works.

Writing a new Forth may be an interesting project, but you will not write a good one until you have a few applications under your belt. Forth is a very subtle language. The internet is full of abandoned Forth kernel projects. Many of these may well have succeeded if they had a purpose that was not yet satisfied.

It is perfectly possible to write large applications in Forth. One of our clients has an application of 1.4 million lines of Forth source code. It is hosted on VFX Forth, which compiles Forth to native code. The VFX version runs at least ten times faster than the previous threaded code version, built on MPE's ProForth compiler.

Re: Implementing a Forth

#55
I've messed around with Forth before, and even created my own one. I could do cool things with it, and gotten a DSL-like language.

I used words like IMMEDIATE and POSTPONE to create words that create words. I quickly get lost doing that, though.

Forth is very very cool to play with. Pragmatically, virtually any other language is better.

Re: Implementing a Forth

#56
post #54

I have made a living with Forth since 1981. I have written very few new Forth kernels, but have ported them to many CPU architectures. Forth is no longer fashionable, but it works. Writing a new Forth may be an interesting project, but you will not write a good one until you have a few applications under your belt. Forth is a very subtle language. The internet is full of abandoned Forth kernel projects. Many of these…

I'm really curious, how many people collaborate on that 1.4MLOC application? I'd think you might end up with "too many cooks in the kitchen" sort of problems because of how much power the language gives everybody.

It's a sort of silly trivial example... but I've watched multiple python codebases slowly become unmaintainable because Python has no way to enforce what can be called or overridden by instances or subclasses, and the org grew beyond its ability to enforce discipline about it in code review.

I feel like Forth would offer orders of magnitude more "temptations" for somebody who just needs to get something done, but I've never seen it done at scale.

Re: Implementing a Forth

#57
post #7

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

I always joke that forth doesn't actually exist. The only forth code that seems to exist is forth implementations.

Re: Implementing a Forth

#58

Problem with Forth and Lisp is that you can freely start to improve language, so it sort of destroys the usefulness in a company of full of Salarymen and Office Droids. Here is Grok's scheme to make Forth more readable: Below is a Forth implementation of a simple parser that transforms (. (+ 1 2)) into 1 2 + . and executes it. This assumes the input is provided as a string or entered interactively, and the parser out…

Did you actually test that code? Never mind the tiny buffer size or possible hallucinations, but just from looking at the "parser", it does seem to do nothing more than copy the expected tokens in the same order it reads them on input, ignoring any parentheses.

This CAN'T possibly work, not even for the example input. Maybe if it reversed the string, but unless I've forgotten completely how to read Forth it doesn't do even that.

And for some reason this kind of garbage is apparently the future of programming, and people seem compelled to post it everywhere...

Re: Implementing a Forth

#59

Problem with Forth and Lisp is that you can freely start to improve language, so it sort of destroys the usefulness in a company of full of Salarymen and Office Droids. Here is Grok's scheme to make Forth more readable: Below is a Forth implementation of a simple parser that transforms (. (+ 1 2)) into 1 2 + . and executes it. This assumes the input is provided as a string or entered interactively, and the parser out…

Did you actually test that code? Never mind the tiny buffer size or possible hallucinations, but just from looking at the "parser", it does seem to do nothing more than copy the expected tokens in the same order it reads them on input, ignoring any parentheses. This CAN'T possibly work, not even for the example input. Maybe if it reversed the string, but unless I've forgotten completely how to read Forth it doesn't d…

Also Lisp isn't just about a prefix syntax, it's the whole eval/apply and lists.

Re: Implementing a Forth

#60

Problem with Forth and Lisp is that you can freely start to improve language, so it sort of destroys the usefulness in a company of full of Salarymen and Office Droids. Here is Grok's scheme to make Forth more readable: Below is a Forth implementation of a simple parser that transforms (. (+ 1 2)) into 1 2 + . and executes it. This assumes the input is provided as a string or entered interactively, and the parser out…

Did you actually test that code? Never mind the tiny buffer size or possible hallucinations, but just from looking at the "parser", it does seem to do nothing more than copy the expected tokens in the same order it reads them on input, ignoring any parentheses. This CAN'T possibly work, not even for the example input. Maybe if it reversed the string, but unless I've forgotten completely how to read Forth it doesn't d…

This was kinda joke. I have done it in real life, but that was in 1976. And the mechanism was totally different, more Lisp-like, but could not make Grok to do it, so I suggested simple pre-parser.
Post reply on HN