Hmm, I'd be a little surprised if this was smaller than some of the 8-bit era forths (the TIL book had a 50ish-byte "inner interpreter" for Z80 but that didn't include any of the baseline "words" that this does.) I'm sure it wins for 32-bit systems though.
TIL Book https://archive.org/details/R.G.LoeligerThreadedInterpretive...
I own a couple hard copies of this before it got popular. Most folks will only ever encounter the above PDF. It is absolutely wonderful book written in such a matter of fact style, the only thing comparable are the works of Nils Holm.
Re:milliForth
by n_plus_1_acc on Monday November 06, 2023 @03:08AM
(#38159947)
Python, 13 bytes: `eval(input())`
um, sir... please show us the implementation of eval.
it's evals all the way down.
Easy, just make a CPU where "eval" is an instruction
Well there are already forth chips, so forth still wins.
Where do I find the implementation of int 0x16 and int 0x10?
Re:milliForth
by RodgerTheGreat on Monday November 06, 2023 @10:09AM
(#38163620)
The main advantage of a miniature Forth like this over BLC, Lisp, Brainfuck, etc, is that Forth grants low-level access to the hardware; you can easily bootstrap from it to something indistinguishable from a feature-rich Forth with a full suite of metaprogramming capabilities, or implement an entire operating system on top of it.
Nothing is stopping Lisp from having low-level access to hardware.
Is low-level hardware access part of the language definition [1] ?
Miniature Lisps are similar to Forth in this way. Having worked with both I'm inclined to favour Lisps for providing cleaner structure and abstractions for code and data to build up from, with low overhead despite the superfical differences. (See SectorLisp2 (436 bytes) vs SectorForth (491 bytes) size: https://justine.lol/sectorlisp2/).
Lisps are given low-level hardware access primitives (peek/poke etc) when they are designed for bootstrapping an OS, and low-level OS primitives (such as system calls) when they are designed for bootstrapping a rich environment on a different OS. Basically the same primitives as Forth for the same purposes.
Re:milliForth
by fuzzballcat on Monday November 06, 2023 @12:54PM
(#38166030)
Author here! I was trying to be very careful about making sure to phrase things in a way that was clear I was referring to "real" languages (ones that are used for actual production purposes), but inevitably I forgot to do so where you've highlighted. I've updated the wording so it's more clear.
And for those that aren't aware: https://en.m.wikipedia.org/wiki/Open_Firmware was a forth based bootloader for PowerPC.
This is a very cool project, author, love it!
Re:milliForth
by fuzzballcat on Monday November 06, 2023 @06:50PM
(#38171027)
Funnily enough, milliFORTH is now smaller than the Binary Lambda Calculus 383 byte implementation.
The sectorlambda implementation of Binary Lambda Calculus is shorter yet at 383 bytes [1].
And the BLC self-interpreter is only 29 bytes [2].
> A FORTH in 422 bytes — the smallest real programming language ever, as of yet.
That may still be true, as BLC is an esoteric programming language.
[1] https://justine.lol/lambda/
[2] https://ioccc.org/2012/tromp/hint.html