Now that Jens is digging into the architecture of the standard
library and all that entails, we need to think some about what is and
isn't going to go into the library, and how it should behave.

A good place to start is with the library loading code. This is in
the works, and something we need, but we also need to figure out
*how* it should work. Should it, for example, override the built-in
load_bytecode op? Or should it instead be presented as a regular
parrot sub, in which case what should it be called and what are its
semantics?

We also need to decide how the library itself will be loaded up.
(Given that the library has the code to find and load libraries
there's something of an interesting bit of fun possible there) My
personal preference is to have the bytecode for the library in an
OS-level shared library that parrot links against  for easy
upgrading, but that makes building parrot in the first place somewhat
problematic. (Which would be solved some if we had miniparrot
working... nudge, nudge! :)

Anyway, now's the time to weigh in on this, since once we nail these
bits down I think we'll spin off a separate parrot-stdlib list to
deal with the all-bytecode standard library. (And I'm still trying to
get a parrot-compilers list for compiler writers. Some day, I hope...)
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk