There was a big consolidation of the mechanisms by which functions run, which gave us the invention of FRAME!.
Behind the scenes, each function category actually has a different "Dispatcher"... the C code that knows how to interpret the array of properties each function instance has. So for instance, every time you create a FUNC-based function, the array of properties will have a BLOCK! of code in it...which is the interpreted code to run. This is different for each FUNC you make, but all of them share the same Func_Dispatcher() which knows what to do... to put together a FRAME! and that BLOCK!, specialize RETURN for the frame, and evaluate the block after binding it to the frame.
But while functions have many things in common, the cracks started to show in terms of the differences. For instance, answering the question RETURN-OF is different for each dispatcher. LAMBDA answers it with NULL because there's no parameter definition for the return, FUNC gives the parameter spec of its return, ENCLOSE will hand off the question to the function acting as a shim and ask it what its RETURN-OF, etc.
But that's not all. Some things that can act as functions have additional properties. Like when the FFI wraps a C function from a DLL as something you can call from Rebol, that "ROUTINE" can answer what address in memory the function is at.
Could We Expose DISPATCHER OF ?
I think the current model, with FRAME! and antiform FRAME!, works quite well...and I'm not eager to get rid of it.
But we could have entities related to these frames that you could query. And it could be these dispatchers that answer the -OF questions for a frame instance.
- FUNCTION!
- ADAPTER!
- ENCLOSER!
- ROUTINE! (FFI-FUNCTION! ?)
These could be extension types, and there could be an arbitrarily large number of them. There's no need for them to be particularly efficient--since they'd be singletons, whose jobs were to answer queries for the FRAME!s which they were associated with.
Just something I've been thinking about...