On Fri, 17 Oct 2003, Juergen Boemmels wrote:
> Why not this way: > > Have a small number of _real_ core.ops which have fixed assigned > numbers below say 256. This ops never change during the lifetime of > parrot. All other libs are inited (not necessary loaded) at byte-code > loadtime. The bytecode has a list of needed oplibs with the acompaning > base offset. The ops of that oplib are added to core starting at base > offset.
Yep, that's the plan. (And has been for years, though it has been quite a while since the discussion came up last)
I know we've had these discussions before but refresh my memory:
I am confused between:
a) Dynamic oplibs that are "on-demand" but always included in Parrot b) Dynamic oplibs that are add-ons and not included in Parrot
I think (a) is a big win, especially for memory sensitive embedded platforms. (b) is a big lose. It invites people to spend time writing custom ops rather than reimplement their language in pure Parrot.
(b) also muddies the water when you try to explain to someone why Parrot bytecodes are "sorta portable."
-Melvin
