The initial concept Shixin and I talked about with extensions was essentially giving you three choices for each extension:
[+] : Build the extension into the interpreter executable
[-] : Don't build the extension at all.
[*] : Build the extension as a separately loadable .dll or .so file
And supposedly it was at some point able to do that. But I'd never seen it work. Because it was a mixture of Rebmake and the R3 Historical Extension model and loading code. Since it wasn't part of any testing regimen--and I never understood it to begin with--it probably only worked the day Shixin wrote it (if it would have worked for me at all, on another machine).
The mysterious feature atrophied, but I kept things related to it around. Because we need this ability to load bits of "native" code dynamically...most especially on the web (where native=wasm).
I decided to spend some time attacking the desktop versions. By no means was this fun, but, I did get it to work on Windows, Mac and Linux.
As a demonstration of it working, I made the UUID extension a DLL on all the platforms, and call it in a test:
(I'm fairly sure that the Mac version could not have worked prior to the development of the libRebol API and extension mechanics in their modern form. So it probably was in an "almost working since it's a lot like the linux version--except for link errors" state at the time of Shixin's writing.)
How Do You Use It?
Right now you do LOAD-EXTENSION and pass it a path. It gives you back a module, which you could then IMPORT or use directly as an object.
The UUID module was not designed to be IMPORT-friendly. It calls its method "generate" which is generic, so it only makes sense as mod-uuid.generate. So I just did:
mod-uuid: load-extension %/path/to/r3-uuid.dll
uuid: mod-uuid.generate
The way I've set up to think about extensions is that from a user's point of view, you can't tell the difference really from ordinary modules. So really this should be folded into IMPORT. You should be able to use a URL just as easily as you can use a FILE!.
Shorthand lookups present a bit of a problem, because since these contain native code there's not a single location that would work for all platforms. We could perhaps adopt a standard naming strategy so that if you put all the extensions in the same directory alongside each other it would know how to pick the right one...
It is kind of neat to see the single file encapsulating script code and native code together. But what would be really neat to see beyond this is having a form that works in the web browser. But this was not fun and so I'm going to need to do something else for a bit.