Lambda the Ultimate

(this is when we all need to be using hyperscope. or google wave, i guess.)

am implicit in all this for me is, "gosh, do i actually remotely understand what i thought i understood, at all?"

thinking about my reaction to the wikipedia entry, my theory is that the core issue is: there are many concepts which need to be explained to get the full point across, and they are in some ways intertwined, so it requires effort to get a layered and clear explanation defined and cleaned up and written. i think the text as it stands doesn't do a good job and there is too much which can/not be "read in" to the text, making it confusing e.g. to me.

Understanding dispatch

Developers of computer software typically organize source code into named blocks called subroutines, procedures, subprograms, functions, or methods. The choice of term depends on the language being used and, sometimes, on subtle differences between their characteristics. The name of a function is used to refer to it from other source code that calls the function. When code is executed, a call to a function causes control to be transferred temporarily to the called function, and often subsequently returns control to the instructions following the function call in the caller.

i think this first paragraph hilights that one needs to know exactly what the audience is. i don't think that paragraph does much good. it is, i think, aimed at people who really don't grok programming, and as such doesn't do a good job of really getting them up to speed correctly to transition to understanding the actual details of multiple dispatch, especially vs. other approaches.

Function names are usually selected so as to be descriptive of the function's purpose. Sometimes, it is desirable to give several functions the same name, often because they perform a conceptually similar task, but operate on different types of input data. In such cases, the name reference at the function call site is not sufficient for identifying the block of code to be executed. Instead, the number and type of the arguments to the function call are also used to select among several function implementations.

as i read it, this is signature overloading rather than late binding. or, if it is also mean to include the issue of early vs. late binding, it should say so somehow. the part that bugs me most wrt the overall text is where it says "different types of input data".

In "conventional", i.e. single dispatch, object-oriented programming languages, when you invoke a method ("send a message" in Smalltalk, "call a member function" in C++) one of its arguments is treated specially and used to determine which of the (potentially many) methods of that name is to be applied. In many languages, the "special" argument is indicated syntactically; for example, a number of programming languages put the special argument before a dot in making a method call: special.method(other,arguments,here).

this isn't about different types of input data, this is about late binding.

In languages with multiple dispatch, all the arguments are treated symmetrically in the selection of which method to call. Matching recognizes first, second, third, etc. position within the call syntax, but no one argument "owns" the function/method carried out in a particular call.

The Common Lisp Object System (CLOS) is an early and well-known example of multiple dispatch.

I don't agree with much of what you're saying.

if it is also mean to include the issue of early vs. late binding, it should say so somehow

I disagree. Introducing concepts of early vs. late binding at that point would be tangential, distracting, and confusing to readers who don't already grok the various 'type' issues for programming. This is a mistake I make far too often. The authors of the article were wise to separate this aspect of the description into a later paragraph.

the part that bugs me most wrt the overall text is where it says "different types of input data"

I agree that this could be better. Introducing 'types' is a mistake here, due to both potential for confusion and technical issues. After all, the values of the inputs can also be used for dispatch (predicate dispatch may involve multiple dispatch).

this isn't about different types of input data, this is about late binding.

The paragraph to which you referred was about single dispatch. It said so in its first sentence. It is pointing out that the binding of the code is selected primarily by a single 'special' argument. (I.e. there may be many functions named 'method' throughout the code, but the 'special' argument has unique privileges in selecting which might be called.)

It is not about late binding. It could just as easily be a static binding, i.e. if the concrete type of the special argument is known at the call site.

i could attempt a re-write and ask for critique here?

You are, of course, permitted to do so. Wikipedia asks only that you document your sources, take a neutral point of view, and exclude original research.

My first critique - before you've written anything - is that you need to rewrite it for proper capitalization. ;p

i'm percolating it.

"The paragraph to which you referred was about single dispatch. It said so in its first sentence."

sure, but to my reading of the overall section of the document, that just makes it worse and more confusing to me. in particular, Java is (as far as i know) considered single-dispatch, but the way i read their description it should be called something between single + multiple dispatch because of method signature overloading, which doesn't exactly fit their description of single or multiple inheritance.

perhaps in other words, i think there are more distinctions which should be make to really properly make clear what all the options are, and i feel that the wikipedia text conflates too much while simultaneously wasting prose on very much less relevant stuff.

anyway -- i should write up my own version to see if it makes any more sense to other people and also hilights the issues i see in the original.

but the way i read their description it should be called something between single + multiple dispatch because of method signature overloading, which doesn't exactly fit their description of single or multiple inheritance.

Ah, the difference between static (overloading) and dynamic dispatch! Hopefully multi-methods someday become accepted as standard practice so we can relegate this abomination to history.