4 ms·
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
by 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 agoNice 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 agoDon't you mean dc instead of bc?
- lolc 9y agoIndeed, it's dc. Muscle memory knows which one I use.
- mikekchar 9y agoForth 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 agoEdit: 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 agoI 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 agoSmalltalk does not decompile code (though one can with some limits), but works with an integrated code management. Interlisp-D also did that.
- jecel 9y agoActually, 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 agoHow 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.
- mikekchar 9y agoYeah, what I was thinking of was that the ability to create an AST from the running image is how the refactoring browser works. I'm not really aware of any Forth analogy, but it's fairly common (in my limited experience) for Forth programmers to hack away in the repl, decompile what they've done and then bung it in the block editor -- so it's kind of a manual version of the same thing. I really wasn't trying to make any profound statement. Just noting something that looked kind of similar :-)