We need to get search paths for loading of stuff into parrot, both at the pir/pasm assembly level and at runtime for dynamic library loading.
Now, bizarrely enough, I *don't* want to build this into parrot. (Yeah, I know. Yes, I am feeling OK :) At least not the runtime library loading, and if we can skip it for the assembly level that'd be fine too. What I'd like to do is pass off the job of finding generally-unqualified names to a library routine and have it look for the thing for me. That means we need a method of registering search paths (which ought be a library routine itself) too. So I'd like that stuff in the library.
To make this actually work we need some standards, and the ability to embed bytecode segments into an executable (like, say, parrot :) so they're always at hand. Hard to load in your library if your library finding code's in the library, after all. I'm also not averse to some sort of special accommodation for low-level library code so it can be found relatively quickly without a full namespace search if it seems necessary, though I'm not so sure about that one. We'll see.
Note here that I'm not talking about perl/python/ruby/tcl's standard library here -- this is parrot's low-level library, stuff that we need but isn't time-critical enough to warrant opcodes.
So. Anyone want to champion parrot's standard library? And anyone want to take a shot at getting fully functioning embeddable bytecode, along with spec'ing out whatever (hopefully minimal) APIs might be needed to make 'em work?
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
