No no no no...
I'm basically saying that the stuff for that shouldn't be part of the core of parrot, as it's very platform specific.
Or, as you said, "There is no reason that you cannot build that on top of Parrot, and once you have done so, that interface would be available to any code running on that interpreter that wanted access." which is exactly what I'm talking about... I want to extend some of those facilities to any scripting language that is able to address them. There are other APIs that are used to load rexx into compiled programs (rexxstart, rxsubcom*, etc) that I'd also like to generalise, esp. because with the introduction of object rexx some of those APIs become broken in certain ways that can be catastrophic to the system. It's not like it's unfixable; it's that IBM won't actually do it without someone throwing a ton of dough at them to do it. With that in mind, I'd like to be able to create function-alike APIs that would add some functionality, and 'hook' the current calls to work on a subset of the new calls, so that daemons using user hooks written in rexx would get un-fscked when the system uses the object rexx interpreter.
