> That's why I stopped worrying about which implementation technique is the fastest and chose the one that made it the most trivial to extend the interpreter.

I like that, it appeals to my sense of pragmatism.

I wrote a Joy interpreter in Nim the other day, and when it came time to switch from machine ints to BigInts it was a breeze. There was a library already written, I updated the type and the compiler told me what else to change, the whole thing was over in fifteen minutes. And if I ever find that integer math is a performance bottleneck there is also a wrapper for GMP ready to go.

- - - -

BTW, I'm a big fan of Oberon, and I think Astrobe is awesome and admire you for making and supporting it. Cheers!

Is that dialect written in C available online? I'm collecting implementations at the moment. If you know any other C implementations besides the popular ones I'd be grateful for pointers to those too.

I've been wanting to put it online for a long time to show how I do it for cases like this, but I need to strip it first of semi-confidential stuff because I hack it a lot to do work-related things. And it also need some documentation to be useful as an "educational" Forth. Maybe one day...

For Forth implementations, although I suspect it might be yourself (you gotta admit this sort of fetish is not very common ;-), Charles Childers [1] is collecting them.

[1] https://github.com/crcx?tab=repositories

pfe ("portable Forth environment") was the first one I used; it was included in Slackware96 and included a Tetris game. You're probably aware GForth, BigForth, and F-83 are mostly written in Forth. I recently read through Retro-Forth, which compiles to an interpreter for a bytecode called Nga, written in C. There was another one I ran into recently but can't find now... aha, SOD32: https://lennartb.home.xs4all.nl/forth.html

Thanks, SOD32 looks interesting. It also led me to find this: https://github.com/kt97679/relf

Cool! Do you still have a copy of it?

Nowadays it's sometimes adequately fast to implement a JIT by spawning gcc or tcc and then running dlopen() on the result ;) It also makes the FFI easier :)

Technically I should still have a floppy and its backup, but the old laptop I used to make it is dead. It's kind of difficult to find floppy drives these days, and the whole thing is so old that the floppies might be no more readable.

The dlopen trick is something I'll remember if I need that sort of stuff, but I've grown wary of FFIs. With libraries, there's often #define constants or macros that make FFIs a bit awkward. I prefer to use static linking if the lib is not too big, or dynamic loading but still with light bindings if not. If you know a bit the internals of Lua, I use a very similar method to extend Forth's "vocabulary", and the loading (and manual linkink with dlsym) is done only when the extension is invoked and initializes itself.