7 ms·

The Oforth Programming Language

118 points by IFranckyI 9y ago

deleted 9y ago
[deleted]
lolc 9y ago
The last time I looked at Forth it was to get a more powerful replacement for the bc calculator. But the minimalistic approach of forth enthusiasts means there is no powerful REPL. Unfortunately Oforth doesn't seem very mature to me. To compile it, I had to install libc6-dev-i386 and g++-multilib so it could do its 32-bit compile. Now it fails on me with a segmentation fault. If I try the precompiled version, it just exits with a nonzero exit-code. So, back to bc, I guess :-) Edit: Ah I see, it needs --i for interactive mode.
- lolc 9y ago
  Nice it has some math functions predefined and is not finicky about types. Edit: And with .show it even shows the stack after each evaluation. This could replace bc for me if it was packaged in Debian.
- yiyus 9y ago
  Don't you mean dc instead of bc?
  - lolc 9y ago
    Indeed, it's dc. Muscle memory knows which one I use.
- mikekchar 9y ago
  Forth is a concatenative language. Its REPL is pretty similar to a Lisp REPL. Everything in Forth is accessible and it's actually common practice to override the interpreter to implement DSLs. Haven't spent any time looking at this, but 30 years ago I actually did quite a lot of programming in an object oriented Forth (3D star field animation system for the university's planetarium dome, on an Amiga with a bit of extra hardware). I really enjoyed it.
  - mikekchar 9y ago
    Edit: Thinking about it, I realise it's actually a lot closer to Smalltalk than to Lisp -- you have a built in editor, you build memory images that you constantly work with, all the code is decompilable so you can refactor easily, etc, etc Actual edit: you'd think I could find the edit button :-P
    - TeMPOraL 9y ago
      I guess Lisp was like that in the good days of Lisp machines. Nowadays, all that remained is "you build memory images that you constantly work with", and Emacs, which is merely a shadow of the old stuff (but still beyond awesome).
    - lispm 9y ago
      Smalltalk does not decompile code (though one can with some limits), but works with an integrated code management. Interlisp-D also did that.
      - jecel 9y ago
        Actually, a bytecode to text decompiler is a very important part of the typical Smalltalk IDE. In Squeak or Pharo, for example, you give the virtual machine a binary file like "work.image" to start the system and it looks for text files "work.changes" and "version4.sources" so the code browser can show you the sources. If these extra files are missing it will complain, but will continue to work normally. If you pay attention you will notice that the sources have no comments and all local variables are called t2 or t5 - that is the decompiler subtly doing its job.
        lispm 9y ago
        How is that 'important'? Usually one writes sources. And that's what is maintained by the Smalltalk development environment. Since Smalltalk usually comes with the system sources there is also no need to decompile the bytecode. OTOH some Lisps keep the s-expressions in the image and can run them directly via a Lisp interpreter.
protomyth 9y ago
Source code looks to be GPL3.
lallysingh 9y ago
They're trolling o'caml, aren't they? This is wonderful.
- FractalLP 9y ago
  No, I think OForth has been out for a long time. Probably not before OCaml, or even close, but still not a trolling thing. Both just use "O" to symbolize some Object stuff.
unclesaamm 9y ago
Sounds a lot like Factor. I wonder how it compares?
- metaobject 9y ago
  Here’s a HN post from 2010 drawing the comparison between Forth and Factor: https://news.ycombinator.com/item?id=1623697 https://news.ycombinator.com/item?id=1623697
sifoo 9y ago
Glad to see Forth getting some attention, took me around 25 years of coding to find it. For those looking for a different take on the same ideas, I'm working on a Lisp-inspired Forth here: https://github.com/basic-gongfu/cixl https://github.com/basic-gongfu/cixl
- cy_hauser 9y ago
  Whoa. I'm afraid to look ;-) My immediate thought is, "lets combine all the mental fun of stack juggling from forth with the tree juggling from lisp." My brain hurts!
  - groovy2shoes 9y ago
    Combining aspects of Lisp with aspects of Forth is not a new idea. The RPN calculators offered by HP used a language called RPL ("Reverse Polish Lisp")[1], including a user-level version (a little more Lisp-y) and a system-level version (a little more Forth-y). While RPL is what came immediately to my mind, I doubt it's the only historical example of such a combination; people have been drawing similarities between the Lisp family and the Forth family for ages. [1]: https://en.wikipedia.org/wiki/RPL_(programming_language) https://en.wikipedia.org/wiki/RPL_(programming_language)
    - sifoo 9y ago
      Thank you! PostScript is another example.
      - groovy2shoes 9y ago
        While I do get that feel with PostScript, as far as I can tell it was accidental rather than a conscious design decision. The stack-oriented nature of PostScript appears to have been influenced by the engineers' experiences with working with some stack-oriented architectures from Burroughs [1], rather than from Forth. Some aspects of PostScript were influenced heavily by other languages in use at Xerox PARC during the Interpress era [ibid], most notably Cedar, but considering that Interlisp was also in use at the time, it's not unreasonable to conjecture that it had some influence; however, any such Lisp influence was likely subconscious, and none of the people working on Interpress or PostScript or their forebears seems to explicated such an influence (as far as I can find). Charles Geschke and John Warnock, the co-founders of Adobe, both deny any influence from Forth, suspecting that some overlap of design requirements between the two languages led to the shared properties [2]. I know that can be hard to believe, given the striking similarity of the two languages, but it's not the only time that concatenative programming would have been independently invented: Manfred von Thun's Joy language is likewise similar to Forth, but, again, not inspired by it. Whereas the similarity of PostScript to Forth can be explained by a simultaneous need for portability and dynamism in tightly-constrained environments, Joy's similarity to Forth is a result of a desire for algebraic manipulation of program text (Forth's (somewhat) having this property may have been a conscious design decision, but I'd bet cold, hard cash that it was a happy accident). Indeed, any of these stack-oriented concatenative languages are computationally equivalent to a transformation monoid (algebra of functions and function composition) where evaluation proceeds according to a (possibly effectful) term-rewriting relation. Viewed in this light, the stack effectively becomes a mere implementation detail as far as the semantics are concerned, but I think that any language designer starting with such a monoid+rewriting semantics, when facing reasonable implementation on real hardware, is likely to come up with something quite similar to Forth &c. That is to say, starting with a low-level focus on efficient and portable implementation, or starting with a high-level focus on code representation as algebraic terms, there's a good chance you'll wind up with something similar to an established concatenative language, whether you mean to or not. --- [1]: "PostScript and Interpress: a comparison", Brian Reid: http://tech-insider.org/unix/research/1985/0301.html http://tech-insider.org/unix/research/1985/0301.html [2]: Masterminds of Programming, Federico Biancuzzi & Shane Warden (eds.)
blunte 9y ago
Forth was my second language behind Basic on the C64, and I didn't even know what a "language" was... it was just the way I got my HP 28C to do cool things...
luckydude 9y ago
I'm a forth programmer, I've implemented an editor in forth, a more(1) clone in forth, a grep(1) in forth and I did a bunch of stuff I've forgotten in forth for the geophysics department at UW Madison. I HATE forth. It's a miserable language, I just hate it. And then I went to Sun and the boot prom language was forth, still hated it. Then I got to PCs. The BIOS had no language and then Intel did whatever garbage they did and I was like please, just give me Forth. It's not what I'd do for debugging a panic but I could make it work. The Intel stuff was way worse. I suspect that Mitch priced himself out, otherwise we'd all be using Forth as the boot language, I dunno what happened. But if you had asked me 20 years ago would I be saying anything positive about forth I would have kicked you in the XXXs. Yet here I am wishing that forth was how we dealt with a panic. We'd all be happier.
- deleted 9y ago
  [deleted]
- luckydude 9y ago
  [I'm sticking this here because there was a dude who said this was a good reply and I tried to reply to him and HN say s his post was deleted. I don't know why, his post seemed pretty reasonable to me, he was asking if forth was a good boot loader. Shrug.] I don't for a minute think that forth is the best answer, it's an awful answer. Even lisp, which I hate with a passion, would be a better answer because more people have experience in lisp than forth. Forth is just less shitty than what Intel came up with, I think it was part of EFI, it's amazingly bad. I've designed a few programming languages and I'm not good at it, but holy crap, I could be drunk and come up with a better answer than Intel did. Forth is just a crappy language but it's less crappy than what Intel did. The idea that Forth is somehow special for boot loaders is nuts. There is nothing, that I know of, that makes forth somehow magical for that. What you want for the bootloader, and for the debugger that you drop into when there is a panic, is something like C but interpreted. You want to be able to walk a linked list of page table structures. And to its credit, Sun's forth could do that. It's sort of twisted to think it could but it did, there were forth words that did all sorts of kernel magic. I think that the magic of forth was that it was tiny, back 30 years ago you didn't want to have a lot of storage for your debugger. That's not the case today, if someone made the case that they could make things better, here you go, here's a gig of storage. That's a little crazy but still. Forth was cool when a meg of storage was a crazy amount. We can do better. Intel pushed us backwards, Forth would be a step forwards, but man, I'd take python or Tcl (because then I'd get my pet language L, http://little-lang.org http://little-lang.org) or even perl as a better boot language. Froth has no special boot sauce in my opinion. It was just small.
tom_mellior 9y ago
So, looking at some examples on rosettacode.org... This is basically a Smalltalk dialect, which is good. But it is also, completely needlessly, a Forth dialect. So instead of Smalltalk's statement separator (the period), you "end" statements by "dropping" some value. That is, instead of: foo doSomeThing. bar doSomeOtherThing you write: foo doSomeThing drop bar doSomeOtherThing Why? It also has named variables (which some Forth purists don't like), but instead of the reasonable Smalltalk syntax of x := baz compute: #something it uses baz compute: #something ->x for assignment. Why? This might eventually turn into a nice programming language, all it needs to do is drop (haha) some of the Forth baggage and admit to itself that its Smalltalk subsystem has everything one needs.
- jabot 9y ago
  The "drop" is not a statement terminator or separator. There is a stack. You push values on the stack, then you call a function. The function takes its arguments off the stack, and pushes the return value(s) on the stack. If you do not need the return value (which seems to be the case in your example) you ignore it by just removing it from the stack. That's what the drop is for.
  - tom_mellior 9y ago
    I know. De facto it's for separating parts of the computation ("statements").
- eequah9L 9y ago
  The -> syntax plays nicely with the stack nature of the language. It's basically just a word that pops TOS, and as a special effect it introduces a name with that value. (IIUIC, I didn't study the language.)
  - tom_mellior 9y ago
    The greater point I'm making is that the language does not have a "stack nature" in any real or useful sense. It has implemented syntax superior to Forth's by using variables and by using Smalltalk-like keyword (i.e., infix) syntax. Yes, there is a remainder of Forth-like stack syntax for expressions. It's ugly, jarring, hard to understand, and comes without any advantages since the Smalltalk-like parts require the language to use a real parser anyway!
HelloNurse 9y ago
Many details suggest that it's a very mainstream object oriented design dressed with somewhat Forth-like syntax, not an "extended" Forth. For example, both garbage collected objects and heap allocated objects, uncontrolled multithreading, everything is an object, arbitrary precision integers, caring so little about the stack that ROLL is missing, gratuitously different control structure syntax.
DonHopkins 9y ago
PostScript is essentially a cross between Forth and Lisp.

118 points by IFranckyI 9y ago

deleted 9y ago

[deleted]

lolc 9y ago

The last time I looked at Forth it was to get a more powerful replacement for the bc calculator. But the minimalistic approach of forth enthusiasts means there is no powerful REPL. Unfortunately Oforth doesn't seem very mature to me. To compile it, I had to install libc6-dev-i386 and g++-multilib so it could do its 32-bit compile. Now it fails on me with a segmentation fault. If I try the precompiled version, it just exits with a nonzero exit-code. So, back to bc, I guess :-) Edit: Ah I see, it needs --i for interactive mode.

lolc 9y ago
Nice it has some math functions predefined and is not finicky about types. Edit: And with .show it even shows the stack after each evaluation. This could replace bc for me if it was packaged in Debian.
yiyus 9y ago
Don't you mean dc instead of bc?
- lolc 9y ago
  Indeed, it's dc. Muscle memory knows which one I use.
mikekchar 9y ago
Forth is a concatenative language. Its REPL is pretty similar to a Lisp REPL. Everything in Forth is accessible and it's actually common practice to override the interpreter to implement DSLs. Haven't spent any time looking at this, but 30 years ago I actually did quite a lot of programming in an object oriented Forth (3D star field animation system for the university's planetarium dome, on an Amiga with a bit of extra hardware). I really enjoyed it.
- mikekchar 9y ago
  Edit: Thinking about it, I realise it's actually a lot closer to Smalltalk than to Lisp -- you have a built in editor, you build memory images that you constantly work with, all the code is decompilable so you can refactor easily, etc, etc Actual edit: you'd think I could find the edit button :-P
  - TeMPOraL 9y ago
    I guess Lisp was like that in the good days of Lisp machines. Nowadays, all that remained is "you build memory images that you constantly work with", and Emacs, which is merely a shadow of the old stuff (but still beyond awesome).
  - lispm 9y ago
    Smalltalk does not decompile code (though one can with some limits), but works with an integrated code management. Interlisp-D also did that.
    - jecel 9y ago
      Actually, a bytecode to text decompiler is a very important part of the typical Smalltalk IDE. In Squeak or Pharo, for example, you give the virtual machine a binary file like "work.image" to start the system and it looks for text files "work.changes" and "version4.sources" so the code browser can show you the sources. If these extra files are missing it will complain, but will continue to work normally. If you pay attention you will notice that the sources have no comments and all local variables are called t2 or t5 - that is the decompiler subtly doing its job.
      - lispm 9y ago
        How is that 'important'? Usually one writes sources. And that's what is maintained by the Smalltalk development environment. Since Smalltalk usually comes with the system sources there is also no need to decompile the bytecode. OTOH some Lisps keep the s-expressions in the image and can run them directly via a Lisp interpreter.

protomyth 9y ago

Source code looks to be GPL3.

lallysingh 9y ago

They're trolling o'caml, aren't they? This is wonderful.

FractalLP 9y ago
No, I think OForth has been out for a long time. Probably not before OCaml, or even close, but still not a trolling thing. Both just use "O" to symbolize some Object stuff.

unclesaamm 9y ago

Sounds a lot like Factor. I wonder how it compares?

metaobject 9y ago
Here’s a HN post from 2010 drawing the comparison between Forth and Factor: https://news.ycombinator.com/item?id=1623697 https://news.ycombinator.com/item?id=1623697

sifoo 9y ago

Glad to see Forth getting some attention, took me around 25 years of coding to find it. For those looking for a different take on the same ideas, I'm working on a Lisp-inspired Forth here: https://github.com/basic-gongfu/cixl https://github.com/basic-gongfu/cixl

cy_hauser 9y ago
Whoa. I'm afraid to look ;-) My immediate thought is, "lets combine all the mental fun of stack juggling from forth with the tree juggling from lisp." My brain hurts!
- groovy2shoes 9y ago
  Combining aspects of Lisp with aspects of Forth is not a new idea. The RPN calculators offered by HP used a language called RPL ("Reverse Polish Lisp")[1], including a user-level version (a little more Lisp-y) and a system-level version (a little more Forth-y). While RPL is what came immediately to my mind, I doubt it's the only historical example of such a combination; people have been drawing similarities between the Lisp family and the Forth family for ages. [1]: https://en.wikipedia.org/wiki/RPL_(programming_language) https://en.wikipedia.org/wiki/RPL_(programming_language)
  - sifoo 9y ago
    Thank you! PostScript is another example.
    - groovy2shoes 9y ago
      While I do get that feel with PostScript, as far as I can tell it was accidental rather than a conscious design decision. The stack-oriented nature of PostScript appears to have been influenced by the engineers' experiences with working with some stack-oriented architectures from Burroughs [1], rather than from Forth. Some aspects of PostScript were influenced heavily by other languages in use at Xerox PARC during the Interpress era [ibid], most notably Cedar, but considering that Interlisp was also in use at the time, it's not unreasonable to conjecture that it had some influence; however, any such Lisp influence was likely subconscious, and none of the people working on Interpress or PostScript or their forebears seems to explicated such an influence (as far as I can find). Charles Geschke and John Warnock, the co-founders of Adobe, both deny any influence from Forth, suspecting that some overlap of design requirements between the two languages led to the shared properties [2]. I know that can be hard to believe, given the striking similarity of the two languages, but it's not the only time that concatenative programming would have been independently invented: Manfred von Thun's Joy language is likewise similar to Forth, but, again, not inspired by it. Whereas the similarity of PostScript to Forth can be explained by a simultaneous need for portability and dynamism in tightly-constrained environments, Joy's similarity to Forth is a result of a desire for algebraic manipulation of program text (Forth's (somewhat) having this property may have been a conscious design decision, but I'd bet cold, hard cash that it was a happy accident). Indeed, any of these stack-oriented concatenative languages are computationally equivalent to a transformation monoid (algebra of functions and function composition) where evaluation proceeds according to a (possibly effectful) term-rewriting relation. Viewed in this light, the stack effectively becomes a mere implementation detail as far as the semantics are concerned, but I think that any language designer starting with such a monoid+rewriting semantics, when facing reasonable implementation on real hardware, is likely to come up with something quite similar to Forth &c. That is to say, starting with a low-level focus on efficient and portable implementation, or starting with a high-level focus on code representation as algebraic terms, there's a good chance you'll wind up with something similar to an established concatenative language, whether you mean to or not. --- [1]: "PostScript and Interpress: a comparison", Brian Reid: http://tech-insider.org/unix/research/1985/0301.html http://tech-insider.org/unix/research/1985/0301.html [2]: Masterminds of Programming, Federico Biancuzzi & Shane Warden (eds.)

blunte 9y ago

Forth was my second language behind Basic on the C64, and I didn't even know what a "language" was... it was just the way I got my HP 28C to do cool things...

luckydude 9y ago

I'm a forth programmer, I've implemented an editor in forth, a more(1) clone in forth, a grep(1) in forth and I did a bunch of stuff I've forgotten in forth for the geophysics department at UW Madison. I HATE forth. It's a miserable language, I just hate it. And then I went to Sun and the boot prom language was forth, still hated it. Then I got to PCs. The BIOS had no language and then Intel did whatever garbage they did and I was like please, just give me Forth. It's not what I'd do for debugging a panic but I could make it work. The Intel stuff was way worse. I suspect that Mitch priced himself out, otherwise we'd all be using Forth as the boot language, I dunno what happened. But if you had asked me 20 years ago would I be saying anything positive about forth I would have kicked you in the XXXs. Yet here I am wishing that forth was how we dealt with a panic. We'd all be happier.

deleted 9y ago
[deleted]
luckydude 9y ago
[I'm sticking this here because there was a dude who said this was a good reply and I tried to reply to him and HN say s his post was deleted. I don't know why, his post seemed pretty reasonable to me, he was asking if forth was a good boot loader. Shrug.] I don't for a minute think that forth is the best answer, it's an awful answer. Even lisp, which I hate with a passion, would be a better answer because more people have experience in lisp than forth. Forth is just less shitty than what Intel came up with, I think it was part of EFI, it's amazingly bad. I've designed a few programming languages and I'm not good at it, but holy crap, I could be drunk and come up with a better answer than Intel did. Forth is just a crappy language but it's less crappy than what Intel did. The idea that Forth is somehow special for boot loaders is nuts. There is nothing, that I know of, that makes forth somehow magical for that. What you want for the bootloader, and for the debugger that you drop into when there is a panic, is something like C but interpreted. You want to be able to walk a linked list of page table structures. And to its credit, Sun's forth could do that. It's sort of twisted to think it could but it did, there were forth words that did all sorts of kernel magic. I think that the magic of forth was that it was tiny, back 30 years ago you didn't want to have a lot of storage for your debugger. That's not the case today, if someone made the case that they could make things better, here you go, here's a gig of storage. That's a little crazy but still. Forth was cool when a meg of storage was a crazy amount. We can do better. Intel pushed us backwards, Forth would be a step forwards, but man, I'd take python or Tcl (because then I'd get my pet language L, http://little-lang.org http://little-lang.org) or even perl as a better boot language. Froth has no special boot sauce in my opinion. It was just small.

tom_mellior 9y ago

So, looking at some examples on rosettacode.org... This is basically a Smalltalk dialect, which is good. But it is also, completely needlessly, a Forth dialect. So instead of Smalltalk's statement separator (the period), you "end" statements by "dropping" some value. That is, instead of: foo doSomeThing. bar doSomeOtherThing you write: foo doSomeThing drop bar doSomeOtherThing Why? It also has named variables (which some Forth purists don't like), but instead of the reasonable Smalltalk syntax of x := baz compute: #something it uses baz compute: #something ->x for assignment. Why? This might eventually turn into a nice programming language, all it needs to do is drop (haha) some of the Forth baggage and admit to itself that its Smalltalk subsystem has everything one needs.

jabot 9y ago
The "drop" is not a statement terminator or separator. There is a stack. You push values on the stack, then you call a function. The function takes its arguments off the stack, and pushes the return value(s) on the stack. If you do not need the return value (which seems to be the case in your example) you ignore it by just removing it from the stack. That's what the drop is for.
- tom_mellior 9y ago
  I know. De facto it's for separating parts of the computation ("statements").
eequah9L 9y ago
The -> syntax plays nicely with the stack nature of the language. It's basically just a word that pops TOS, and as a special effect it introduces a name with that value. (IIUIC, I didn't study the language.)
- tom_mellior 9y ago
  The greater point I'm making is that the language does not have a "stack nature" in any real or useful sense. It has implemented syntax superior to Forth's by using variables and by using Smalltalk-like keyword (i.e., infix) syntax. Yes, there is a remainder of Forth-like stack syntax for expressions. It's ugly, jarring, hard to understand, and comes without any advantages since the Smalltalk-like parts require the language to use a real parser anyway!

HelloNurse 9y ago

Many details suggest that it's a very mainstream object oriented design dressed with somewhat Forth-like syntax, not an "extended" Forth. For example, both garbage collected objects and heap allocated objects, uncontrolled multithreading, everything is an object, arbitrary precision integers, caring so little about the stack that ROLL is missing, gratuitously different control structure syntax.

DonHopkins 9y ago

PostScript is essentially a cross between Forth and Lisp.