Hacker News Reader

Comment by lolc | Hacker News Reader

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.

View on HN

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.

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

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).

Smalltalk does not decompile code (though one can with some limits), but works with an integrated code management.

Interlisp-D also did that.

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.

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.

Yeah, 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 :-)

> 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

Lisps often provide built in editors; Common Lisp even has the standard function ED for invoking one[0], but like most of the "environment" functions its behaviour is left almost entirely unspecified. Lisp is also usually developed in an image-based fashion. Images are one of the features that separate Lisp and Smalltalk from almost everything else, not one that separates them from each other. Some Lisps provide access to source code from function objects, with varying degrees of integration, and again, Common Lisp provides the standard function FUNCTION-LAMBDA-EXPRESSION for this purpose[1]. They don't generally work via decompilation, but neither does Smalltalk.

0: http://www.lispworks.com/documentation/HyperSpec/Body/f_ed.h...

1: http://www.lispworks.com/documentation/HyperSpec/Body/f_fn_l...

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.

Don't you mean dc instead of bc?

Indeed, it's dc. Muscle memory knows which one I use.

Reply on news.ycombinator.com