From: Pixel Date: 2001-11-25T08:56:58+09:00 Subject: [ruby-talk:26382] Re: Table: Ruby versus Smalltalk, Objective-C, C++, Java; "David Simmons" writes: [...] > Overloading is the static-binding (language) name. Multi-methods is the > dynamic-binding (language) name. Some authors prefer to write it as > "multimethods" e.g., Art of the Metaobject Protocol and various other > excellent lisp references. [...] > However, be they statically or dynamically bound, the principle of the > facility is the same: in statically typed and analyzed/compiled languages > the binding (based on argument types) takes place at compile-time; in > dynamically typed languages the binding (based on argument types) takes > place at runtime. That principle being the use of all the argument types as > predicates in the binding process, rather than just using the > method/function name (and possibly the receiver's type). beurk, i don't like this. multiple dispatch is very seldom present in dynamic languages since the only typed parameter is the object. dynamic languages with optional type annotation can have multiple dispatch (dylan, CLOS). > > This requires significantly more precise explanation to present the issues > properly for languages that have static typing and limited dynamic typing > facilities [which leads to type-case expressions that are runtime checked > rather than using modern-adaptive-dynamic binding-techniques developed in > the mid-80's]. > > This is "closely" related to my comments on C++ lacking "Calltime Dispatch > Binding". I.e., C++ has static-overloading but lacks > calltime-dispatch-binding facilities to be able to provide runtime/calltime > overloading. like nearly every OO languages, C++ has runtime dispatch only based on the type of the object, not on the argument types. Dispatch on argument types is decided at compile time. This is not multiple dispatch (also called multi-methods) cf the Castagna's nice paper http://citeseer.nj.nec.com/castagna95covariance.html > If it had such facilities then it could, at runtime, truly > dispatch on one or more parameters to a function (including as a > parameter). Java, C#... are in the same category http://people.mandrakesoft.com/~prigaux/overloading2.java > > > - "Calltime Dispatch Binding": not in C++? weird > > Strictly speaking, vtable dispatch is not a binding process at all. It is > just a vectored indirection that is invariant with respect to methods being > added, removed, calling context restrictions etc. Whereas a calltime > dispatch binding facility actually performs the binding at call-time based > on various runtime alterable characteristics. i don't think the implementation of C++ should distinguish it from Java. Many OO languages do not allow adding methods at runtime and have the same behaviour as C++. Of course, in Ruby you can add methods at runtime and the vtable trick is not possible. > > > - what do you mean with "Tail Calling"? IMO it's an optimisation which > depend on > > the implementation. AFAIK many C++ implementations handle tail recursion > (gcc > > does it nicely since 2.96) > > I did not know gcc had this; I've never tried it. However it is not part of > the C++ standard. By that measure. there are many different C++ extensions > that exist (incompatibly) across implementations for providing very useful > features. do optimisations have to be in a standard ??? the use of tail-recursion or not does not alter the behaviour of a program until you reach stack overflow. But you can say the same for many optimisations. > > w.r.t. tail-calls, (if you say that gcc implementation supports > tail-recursion calls, I certainly am interested in verifying that because I > could use it for some VM build work). well, it works on 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 > However, I'm not really sure I see how > it (c++) could be doing this for anything other than calls to the current > method/function. Which is not general tail-recursion calling [otherwise one > could loosely claim that any language with a goto had tail-calling]. 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.