> I think we're seeing this through a bit different eyes. It is not clear to
> me whether your mixed math with Polynomials was commutative. IOW, that not
> only could you perform:
> 
> polynomial + 4
> 
> but also that you could perform:
> 
> 4 + polynomial
> 
> IMO, any mixed math you add to the system, should be communtative. VS, IMO,
> did not do a complete implementation of the DD stuff. At least as far as
> points goes. In 3.0.1, you could add a simple number to a point, but not a
> point to a number. I would argue in VS, that you hadn't done DD (not the
> way I understand it). To have implemented it the way I understood it, you
> would've done something like:
> 
> Polynomial>>+ aNumber
> 	^aNumber sumFromPolynomial
> 
> Then, for any potential argument you would've implemented the
> sumFromPolynomial: message, *including in Polynomial itself*. That's the
> beauty of DD, is that there are NO isThisOrThat checks and subsequent
> branches. The traversal of messages ends up in the right place.

Personally, I think that Double Dispatching (DD) is a better way to go than
coersions.  VW implements both, using coersion to avoid the n^2 problem
with DD.  The problem with coersion, is that it implicitly assumes a tower
of types, that is to say, a tree where each node has only one child. Thus,
it is "trivial" how to raise or lower a numeric type.  The problem is, this
simplistic scheme only works for the simplest of arithmetic embedings, i.e.
Rational->Integer.  Even adding the "Real" type to the tower raises all
sorts of thorny problems which are usually ignored by the 
Real == FloatingPoint camp.

There is a rather good discussion of the issues in Structure and Interpretation 
of Computer Programs (using Scheme as a language).

If you want to see how easy it is to make mistakes in this area, and
have access to VW:

notice that:

(3 at 4) * (5 + 6i)
evaluates to: 15 at 24

(3+ 4i) * (5 + 6i)
evaluates to: (-9 + 38 i)
______
((1/3) raisedTo: 0) isInteger
evaluates to: false

123456781234567812345678i real isZero
evaluates to: false
______


The moral of the story is that unification must proceed very carefully
lest the unity you acheive be only valid in a limited context.

For instance, is
	(x^2 + x + 2)
the same polynomial as
	(y^2 + y + 2)
?

The answer is yes, if they are considered as functions, but no if they
are considered as syntactical forms.

Is the real number 4 the same as the complex number (4,0) ?
There is a natural isomorphism between complex numbers with a zero
real part, and the real numbers, and, most fortunately, this embedding
preserves most of the laws of real arithmetic when extended (or mapped)
into the complex domain.  A similar embedding puts the natural numbers into
the integers into the rationals into the algebraics.

However, the "natural" isomorphism between Smalltalk Points, and complex
numbers is not so natural, as my example above shows.

I have been playing around with this stuff for a while, and I've found that
coersion is, in general, a bigger problem than it is worth.  It only works
properly when the number of types is small.  But when the number of types
is small, the n^2 DD issue, just isn't tooooo difficult to swallow.

-- Mike Klein