Playing with miniSqueak (SqueakJS) the thing that strikes me the most is that Smalltalk method notation is so very nearly almost stack machine notation, and yet not quite. But almost!
If we had ordinary Forth-like words but made them force a lookup against an object on the top of the stack, that probably gets us 95% of the way to native Smalltalk in a stack machine. Wondering about prefix runes (maybe a . or : ) on a word to indicate that they indirect through an object on the first or second place of the stack, to account for parameters?
Ie instead of
Pen new mandala: 35
we’d have maybe
.Pen .new 35 :mandala
If a single selector required multiple parameters, then just use multiple colons between words:
.Point .new 1 2 :x:y
Then we could mix these method selectors with non-OOP words, that don’t have any rune, and it’s always clear what’s going on. Everything on the working stack at every point is data and all stack effects are caused directly by the selectors themselves.
Not sure but it’s worth thinking about. It’s not great in terms of human factors, but neither is Smaltalk notation for me, and this at least puts as thin a barrier as possible between the programmer and the machine. It’s in the spirit of Forth. Possibly, it’s also in the Brutalist spirit of “truth to materials”. A stack machine isn’t exactly a truth but I like to have as clear a picture as I can in my mind of what the machine is actually doing, and not what the compiler is pretending that the machine is doing.
Selectors would literally just be words. A . selector would be something like “self-address SEND” where SEND is “>R DUP GET-CLASS <R SWAP CALL” and a single-param : selector would be “SWAP self-address SEND”. Two parameters and up and the selector would do ROT or nastier juggling instead of SWAP, to bring the buried object to the top of the stack. Sorry about that. Maybe take it as a hint to avoid multi-parameter methods if you can. But you’re at least avoiding have to store the parameters in main memory.
The class is a word taking the selector and object and parameters as an argument and then using those to figure out how it wants to dispatch. Simplest would just be a set of comparisons with the most common selector first. Next simplest, and probably best, an array of selectors/methods to iterate through. Finally a hash table if you must but maybe don’t.
. and : as runes don’t play nicely with Unxtal, sadly.
Someone’s probably already done OOP like this in Forth several times over in the last 30 years, right? I’ve probably read it and forgotten it. If there’s anything I can claim as my own it might be the prefix rune syntax but that’s also probably something someone else has done.