"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