Lambda the Ultimate

foo bar; baz

(begin (bar foo) (baz foo))

(baz (bar foo))

If I have misunderstood monads then please send complaints to Dave Herman who taught me about them :-)

You're right, it's not the typical monad control operator bind, but it is the special case >> one (I hate how Haskell speaks in line noise). This evaluates the first argument then the second, ignoring the result of the first.

Most Haskell programmers would use do-notation where 'a >> b' would become 'do a; b' (or laid out vertically with no ';'). I find this hard to consider "line noise". Personally, I find typical Haskell code to contain much less non-alphanumeric characters than say C-style code, but that is just my opinion.

">>" is pronounced "then".

You know, of course, that there are those that argue that if you use if statements instead of dynamic dispatching, you are not faithful to the OOP doctrine...

If considered harmful


I'd really like to see predicate dispatch implemented more widely.

There are many types of polymorphism in the world:

* Internal vs External
* Parametric (generic) vs Subtype ("inheritance") vs Ad-Hoc (explicit enumeration)

Others may construct other taxonomies on the subject; I consider Luca Cardelli's On Understanding Types to be an excellent resource.

At any rate, the internal/external and parametric/subtype/ad-hoc axes are orthogonal; meaningful examples of each kind exist:

Overridding of inherited virtual functions (or abstract function specficiations--the bread and butter of OO) is internal subtype polymorphism.

Multi-Methods, ala CLOS or Dylan, are an example of external subtype polymorphism.

Templates (generics are examples of parametric polymorphism. In C++, Java, and other OO languages with generics, this can be internal; it is generally external in functional languages.

Pattern matching is a common example of internal ad-hoc polymorphism. Function/operator overloading is also ad-hoc polymorhism, and can be internal or external depending on the language (C++, for instance, allows either).

And finally, the procedural control structures (if, case) are time-honored ways of implementing external ad-hoc polymorphism. (Table-oriented programming is another way as well, though nobody other than topmind seems to use it. :)

The OO uber-zealotry that I refer to in the title of this message is the notion (which seems to spring from the Smalltalk community) that internal polymorphism is good, external polymorphism is bad--that any decision-making should be implemented through inheritance and specialization. (The communities of other OO languages--C++ and Java, and even Smalltalk-derived scripting languages like Python or Ruby, seem to have less of an issue with this).

Needless to say, I consider this a questionable stance to take. In many cases, decisions made by software which might be made on the type (or identity) of an object, are made in modules other than where the object is defined--and are only of concern to that particular module or application. 'Tis better, I think, to keep local concerns local, then burden an object definition with every possibly contingency in every possible application or domain the object might be useful in--which might be a very large set.

While internal polymorphism is a great thing to have and use--so is external polymorphism. One thing I like about C++ (despite its numerous flaws) is it doesn't force me into one style or another--I can define templates, overloaded operators, and such either within a class definition, or outside it. Many other languages make this more difficult. (Of course, C++ operator overloading is broken in the presence of subtypes--CLOS style multimethods would be preferable to the C++ implementation, which uses the declared static type of a term rather than the actual type of the object).

Needless to say, I consider this a questionable stance to take. In many cases, decisions made by software which might be made on the type (or identity) of an object, are made in modules other than where the object is defined--and are only of concern to that particular module or application. 'Tis better, I think, to keep local concerns local, then burden an object definition with every possibly contingency in every possible application or domain the object might be useful in--which might be a very large set.

You describe the C++ solution to this. Another solution is to separate the notions of object definition and code locality (temporal locality, too, if you're into that). This is the approach taken by Ruby, for example, and other languages with open classes. The idea, of course, is that those "contingencies" can be implemented both in the local application or domain and in the object definition. I think Pascal Costanza's ContextL addresses this problem in a similar way, and it's a bit more disciplined than Ruby's open classes.

So, really, to try to draw a general point from this... I'm not sure the internal/external metric is fine enough to capture the real design space here.

"dynamic dispatching"

That would be "use polymorphism instead of a case statement" :-)

Before we lose perspective, note that in many Smalltalks the ifTrue: ifFalse: ifTrue:ifFalse: messages are optimised away by the compiler. Ordinary Smalltalk code has many ifTrue: statements, and also makes use of double-dispatch.

withSide: side setTo: value  "return a copy with side set to value"
      ^ self perform: (#(withLeft: withRight: withTop: withBottom: )
                         at: (#(left right top bottom) indexOf: side))
             with: value

Helmut Eller used a similar dictionary trick in SLIME that I noted as interesting:

(defconstant +lowtag-symbols+ 
  '(vm:even-fixnum-type vm:function-pointer-type ...)
  "Names of the constants that specify type tags.
The `symbol-value' of each element is a type tag.")

...

  (let* ((lowtag (kernel:get-lowtag object))
         (lowtag-symbol (find lowtag +lowtag-symbols+ : key #'symbol-value)))
     ...)

My Smalltalk's rusty, but can't you approach the same sort of effect using a Dictionary?

   switch := Dictionary new.
   switch at: matchCode1 put: [actionCode1].
   switch at: matchCode2 put: [actionCode2].
   ...
   result := (switch at: matchCodeX) value.

Ok, so I don't know how you'd get a default, but essentially the Dictionary can act just as well as a Switch type statement.

I'm reminded of page 53 in the Tutorial on Good Lisp Style:

Rule of English Translation

To insure that you say what you mean:
1. Start with an English description of the algorithm
2. Write the code from the description
3. Translate the code back to english
4. Compare 3 to 1

My favourite slide is the one on Control Abstraction on page 57. I used to keep a printed copy on the wall of my office and I should do this again.