Brent Dax writes: > Dan Sugalski: > # Okay, since it seems reasonable to hang the trig functions off of > PMCs, > # we'd best get a list of the functions we want. I can think of: > # > # pow > # logarithm > # square root (yes, I know, it's for speed) > # > # Normal and hyperbolic versions of: > # sine > # cosine > # tangent > # cotangent > # arcsine > # arccosine > # arctangent > # arccotangent > > Okay, reality check. How often are we going to use acosh? Is it really > worth the space in the vtable for that few calls? And why can't we just > use find_method?
And let's not forget our handy trig identities. We definitely don't need all those vtable. Technically, all we need are sine and arccosine. I think putting in cosine, arcsine, and [arc]?tangent would be nice, too. Cotangent is easy, and is so infrequently used that it's kind of silly to include. And hyperbolics are very infrequently used, and can be implemented in terms of exp, which in turn can be implemented in terms of pow, but shouldn't. > Basically, where do you draw the line between a vtable method and a > find_method method? Unless the line is "methods that everything should > support", I'd say it's been crossed when you add acosh to the vtable. > And if that *is* where the line is, don't be surprised when vtables > cross the megabyte line. But that's not even the line. There are a lot of methods in there which a lot of classes don't support. Now that we have find_method, it might be a good idea to define our critera for vtable functions, and then prune the vtable accordingly. Maybe. > I'm really starting to wonder: why do we have only one type of vtable? > Why are Closures, Pointers, and Scratchpads forced to implement acosh, > splice, pop, or even get_float? And why are PerlInts forced to > implement invoke and can_keyed? > > Vtable.tbl already divides vtables into sections. I suggest we take > this a step further and express these sections in the vtables itself. > Sections that a particular object didn't need would be loaded with a > default, in which all of the methods would throw an exception. > > The result would mean that something like: > pmc->vtable->add > > Might become: > pmc->vtable->math->add > > And: > pmc->vtable->add_keyed > > Might become: > pmc->vtable->keyed->math->add > > This would make it easier to implement non-keyed objects, and the extra > dereference would be lost in the overhead of dealing with keys and > aggregates anyway. > > Best of all, if a PMC class doesn't need math calls, it can simply put > this in its vtable definition, in place of the curlies delimiting the > set of math calls: > > &Parrot_pmc_default_math_vtable Hmm. I think that's a pretty good idea. Of course, the indirections cost, but we have to give space part of the tradeoff somewhere. On another, related, but not too related, note... That is to say, <rant> When I went and tried to implement the Infinity pmc, I ran into a lot of problems. I just wanted a value that could be put into a perlscalar that could act like an infinitely large (or small) integer. I ended up copying tons of code from PerlInt, etc. just to get the polymorphism to work (for some reason putting it all up into perlscalar died big-time). As far as the var/value split, we need something to support that. 'fetch' and 'store' would be really nice, as sort-of unkeyed variants of get_pmc_keyed. If something like this already exists, some ops to actually manipulate it would be nice. Then one could implement Infinity (or even PerlNum) as a non-polymorphic object, and let PerlScalar handle the polymorphism. Which, as far as adding new typed, I think would be a Very Good Thing. </rant> Luke > --Brent Dax <[EMAIL PROTECTED]> > Perl and Parrot hacker > > "Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna > set myself on fire to prove it." >
