[not had time to read your whole message, about to go out] On Fri, Feb 22, 2002 at 09:00:29AM -0500, Gregor N. Purdy wrote: > Of course, thats all irrelevant if it doesn't compile. There are two > ways out, from my perspective: > > (1) Split core.ops into multiple oplibs, with the *really* core > stuff (Parrot couldn't do anything reasonable without them) > left in core.ops, and other stuff moved out to loadable oplibs. > There might even be enough heat generated by a discussion of > this we could have a nice marshmallow roast :) > > (2) Switch the implementation of find_op() to something that > makes for smaller code (I almost said simpler, but I think > nested switches aren't inherently non-simple, just hard for > the compiler to keep in mind all at once when they are this > large). I had considered laying down static data structures > for a hash table, or binary search tree or something, but I > decided to make the first implementation the fastest, all > other considerations be damned.
I was considering suggesting pinching the constant routine from perl5. [ie the thing that was written to fix the original POSIX.xs meltdown] I'm biased - I wrote it. It cuts down the options with two switches, then a (short) linear scan with memcmp of whatever strings fall out together from the switches. It was the "best" compromise I could think of. [note, not the whole hog of ExtUtils::Constant, with its ability to return all sorts of types of constants. Just the switch builder] Nicholas Clark -- EMCFT http://www.ccl4.org/~nick/CV.html
