On 10/27/04 Luke Palmer wrote: > Stéphane Payrard writes: > > That would allow to implement typechecking in imcc. > > > > .sym Scalar a > > a = new .PerlInt # ok. Perlint is derived from Scalar > > Ugh, yeah, but what does that buy you? In dynamic languages pure > derivational typechecking is very close to useless. The reason C++[1] > has pure derivational semantics is because of implementation. The > vtable functions have the same relative address, so you can use a > derived object interchangably. In a language where methods are looked > up by name, such strictures are more often over-restrictive than > helpful.
Actually, if I were to write a perl runtime for parrot, mono or even the JVM I'd experiment with the same pattern. I guess it could be applied to a python implementation, too. You would assign small interger IDs to the names of the methods and build a vtable indexed by the id. In most cases the method name is known at compile time, so you know the id and you can get the method with a simple load from the vtable. This is much faster than a hash table lookup (I hinted at this in my old RFC for perl6). Of course the table would be sparse, especially in pathological programs, so you could have a limit, like 100 entries or less with IDs bigger than that using a different lookup (binary search on an array, for example). There are a number of optimizations that can be done to reduce the vtable size, but I'm not sure this would matter in parrot as long as bytecode values are as big as C ints:-) Maybe someone has time to write a script and run it on a bunch of perl programs and report how many different method names are usually created. Of course it also depends how much the hash lookup will cost wrt the total cost of a subroutine call... lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
