On Thursday, 26. June 2008 18:46:25 Larry Wall wrote:
> Neither "is" nor "does" is quite right here, because the mathematicians
> have seen fit to confuse representation semantics with value semantics.  :)

Hmm, but the uppercase types should hide the representation type.
IOW, there's only one Int but int8 to int64 or so. Same with Num
and num32 to num128 and perhaps num8 and num16 in the OpenGL world.

> I think what we want is something more like
>     Int as Rat
>     Rat as Num
>     Num as Complex

So, how does this auto-coercion interact with dispatch? And
how do these in turn interact with generic function/type

I imagine a first round of dispatch then some well defined
second attempt after "standard" coercions. Note that there
might be coercion conflicts if several paths of conversion
are available. Then we need some concept of "coercion distance"
that favors more direct paths over longer ones and less lossy
ones over lossier ones. The tricky part then becomes the interaction
of coercion with dispatch. E.g. if there is an Int arg and two
dispatch targets for Rat and Num and two conversions Int as Rat
(lossless) and Int as Num (lossy?).  

OTOH, I regard Complex as a structural type like e.g. Vector
or Matrix that is built on top of other numeric types. That is we
have Complex[Int] as the Gaussian Integers and Complex[Rat] and
Complex[Num] in the same coercive relations as the underlying Rat
and Num.

Regards, TSa.
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Reply via email to