Minimal how? about bee HOT 3 CLOSED

You're quite right that (my) pForth is not in any simple sense "minimal". (You may or may not have noticed that in 1999 I presented a paper at EuroForth about my experiences implementing Machine Forth, and of course even that is not minimal compared with your efforts.)

A more accurate description might be "minimal effort", in the sense that Bee is designed to be a simple VM with a small instruction set with which one can easily implement a Forth compiler that is not too slow. The actual instruction set was chosen from the minimal set of primitives that pForth itself requires, again, avoiding particularly slow compromises such as implementing / or ROLL in Forth; no low-level Forth word should be difficult or terribly slow to implement with Bee's instruction set, while easy combinations (such as : - NEGATE + ;) are allowed.

The result is (intended to be; I have yet to take full advantage of Bee to simplify pForth, whose back-end interface is currently badly-defined, hacky, and more complicated than it need be) that both Bee and pForth can be easily implemented with a modest amount of code, and acceptable performance for a naive implementation. (Currently, pForth boasts some of the slowest implementations of Forth you're likely to find in terms of machine cycles per Forth primitive.)

Does my description above (something like the second paragraph) sound like a reasonable explanation of Bee's aims? I understand that with Forth systems perhaps more than any other language, the precise trade-offs explored by a particular system need to be delineated if they are to be kind to (potential) readers/users!

from bee.

That's a great explanation. Thanks!

from bee.

(Reopening as I will fix the documentation.)

from bee.