"David Simmons" <david.simmons / smallscript.net> writes: [...] > In dynamic languages which lack multi-methods, we see "double-dispatching" > (a poor-man's workaround) for receiver+1arg cases where all the types are > known up front at design time [i.e., no 3rd party development or late > deployment time integration issues]. same in statical typing: http://www.eptacom.net/pubblicazioni/pub_eng/mdisp.html > I am not sure why you mentioned these generally well understood facts [at > least they are generally well understood within the dynamic language > implementation community]. because your chart has a "yes" for multi-methods in C#/C++ ! [...] > > cf the Castagna's nice paper > > http://citeseer.nj.nec.com/castagna95covariance.html > > Sorry, I could not access the paper on that site without an ACM online > library membership. Feel free to send me a PDF if available. click on "Cached: PDF" (hail CiteSeer!) > > > > > > > > If it had such facilities then it could, at runtime, truly dispatch > > > on one or more parameters to a function (including <this> as a > > > parameter). > > > > Java, C#... are in the same category > > I agree, they are broken. But <g> you are preaching to the choir; I am a > dynamic language advocate, but the problem is not being dynamic or not: a statically typed language *can* have multiple dispatch! eg: Cecil, MultiJava (http://www.cs.washington.edu/homes/todd/papers/oopsla00.html) adding multiple dispatch to java: http://citeseer.nj.nec.com/dutchyn01multidispatch.html [...] > All the "crap" regarding genericity in Java [and C#] would never have been > an issue if they did away with (or offered alternatives to) the VTable > dispatch mechanism C++ has vtable and genericity (parametric polymorphism, aka templates). I don't see the limitation that makes Java and C# not having genericity. (AFAIK Java 1.4 will have generics) >-- which is something I appear to be influencing the > thinking on at Microsoft. It would also be trivial to inherently provide > proper AOP if true predicate based calltime binding and dispatch was > performed. NOTE: I am being very careful to stay away from the potentially > dodgy term "dynamic binding" because, like the broad use [and now relatively > meaningless] term object-oriented, it has become rather polluted. > > Similar issues occur with static language notions of sealed and final as > well as interfaces. And closely related is the need for selector > namespaces, which I invented in 1996. Which, to my great satisfaction, are > now going to be a part of the ECMAScript (JavaScript 2.0) standard. The > ECMAScript selector namespace design, as far as I known, is unrelated to my > work -- which is what makes it so satisfying because it means that > independent parties trying to solve similar problems came to the same > fundamental conclusions about its importance. apropos could you add some "alt=" to http://www.smallscript.net/ (is nicer for links/lynx users) it seems like SmallScript description is missing or??? All i can find is ugly words (pricing, Microsoft, .asp's, Technology Preview...) i couldn't find info about this "selector namespace", any link? > > > > > http://people.mandrakesoft.com/~prigaux/overloading2.java > > Sure, the example is clearly illustrating the problem. Static type binding > of dynamic type information does not work. I.e., languages which only have > static binding cannot provide proper semantics for method-implementation > selection based on argument types. hum. C++ and Java do not have "only static binding". [...] > It is worse than just describing C++ like mechanism as "the vtable-trick". > VTables are actually (demonstrably) slower than "true" (receiver only) > dynamic-binding-dispatch mechanisms. This fact is (reasonably well) > understood today. It is a reality that will increasingly be the case as long > as the gap between processor core speeds and L2 cache and memory speeds > continues to widen. > > It is fairly easy to illustrate on the Intel processor family. I've posted > (on comp.lang.smalltalk within the last 12 months) at least two detailed > explanations showing the machine instructions, cycle-times, and benchmarks. > The originally published technique was developed by David Ungar and > published in OOPSLA papers in the mid-80's. It has been a standard part of > most jit-based Smalltalk implementations for the last ten years or so. are you talking about http://www.sun.com/research/self/papers/type-feedback.html ? the idea is quite simple: specialize for a given type of object to allow inlining. In that case, to know which specialization to have, run-time feedback is used. This applies well to JITs of course. I don't see why it prooves that vtable is bad/slower. vtable can also benefit from specialization. This is also why the default in C++ in no "virtual" methods, so that performance is the best. This is a well known, no? In the ML family, the same happens when going from polymorphic functions (needing boxing) to monomorphic functions (with unboxed data) see for example: - the SPECIALIZE pragma in ghc http://www.haskell.org/ghc/docs/4.04/users_guide/users_guide-5.html) - type-based unboxing (Leroy) http://citeseer.nj.nec.com/88305.html > > However, I intentionally have not published information on techniques I have > developed (on the AOS Platform VM) for hi-performance predicate based > (incl - multi-method) dispatching. Especially with regard to implementation > on the .NET platform, where I am still exploring with Microsoft [who needs > this technology as much as Sun/Java does]. "Where Do You Want To Go Today?" ;p Microsoft has a *lot* of people working on languages. Hopefully many are allowed to publish their work (and even release GPL apps) [...] > > i don't know what you call "general tail-recursion". Of course the > > poor C compiler has hard time analysing things to proove the > > tail-recursion optimisation is safe. > > I think we might be speaking about something without our having the same > definition of terms. Can you cook up a simple example (or some pseudo-code) > to illustrate what gcc can do? once again: http://people.mandrakesoft.com/~prigaux/47.c http://people.mandrakesoft.com/~prigaux/48.c http://people.mandrakesoft.com/~prigaux/50.c http://people.mandrakesoft.com/~prigaux/53.c