In Forth the CREATE - DOES> pattern is quite powerful as it allows extending the compiler by defining defining words (e.g. VARIABLE, CONSTANT). While the pattern isn't too hard to understand, the implementation of DOES> is notoriously complicated, and each Forth implementation method (ITC, DTC, STC, etc) requires a tailor made implementation of DOES>.

The Forth community has always been divided about the usefulness of the pattern: some call it The Pearl of Forth, other claim that they never really needed it: not all want to extend the compiler, and some prefer another type of meta-compilation. In eForth there is no DOES> at all, and I've seen several discussions about the why. My guess is that in the pursuit of simple portability DOES> fell off the cliff.

However, my goal for an STM8 eForth is a self contained Forth development system, and not a tethered Forth where the compilation happens on a host Forth system. I have certain use cases, like experimenting with new defining words (e.g. allocating memory in RAM or EEPROM while compiling to Flash), and I also find the CREATE-DOES> pattern quite intriguing.

By the way: while working on DOES> I found an edge case where CREATE to NVM did unexpected things. I pushed an updated version to GitHub, and also the binaries here in the files section received an update.

PS: at the last SVFIG Forth Day, Bill Ragsdale presented a different take on "defining defining words" which has the advantage of clearer semantics and a less complicate implementation. His paper is here.