Okay, here are a few things that needed deciding, so they have been.
1) Remember those timer ops? Nevermind, they're gone. Timer PMCs instead, and I'm working on the event draft again.
2) Language as part of strings. Dead, at least for now. When Jarkko whacks me with the cluestick I do eventually feel the pain. (Spare me the brontosaurus jokes :) Of course, that brings us back to the wonderful world of global locales, so I'm not sure it's a net win. For now, the language/locale/whatever thing will still need a string to vector off of, in case I change my mind again.
3) Library loading. Jens is right, this can be bytecode. In fact, I think it should be. We'll bundle all these functions into parrot_stdlib.pbc, and take the _parrotlib namespace.
4) Iterators. We need 'em. I think they're probably important enough to warrant a vtable method, but I'm not quite sure there. (That whole "feels important"/"don't care that much" dichotomy) If someone wants to sketch a simple iterator design, go for it.
5) Slices. Tied to iterators. (Yes, this is partly because of the python bytecode thumping) I think it's likely that slices warrant low-level support, with vtable access. (get_slice to return an iterator of PMCs for the aggregate or something like that)
6) As part of events I think we're going to define a general-purpose protocol for event sources. Yes, it will be OO, and no, I don't think it's a sign of Ragnarok. (I could well be wrong here, though)
I think that's it, at least for now.
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
