Re: [Caml-list] ambitious proposal: polymorphic arithmetics

[Eijiro Sumii <eijiro_sumii@anet.ne.jp>]

P.S.

> From: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
> | + can't be treated in the same way, because it won't distinguish
> | whether it's called as 1 + 1 or true + true. If it returns 2 in the
> | former case, it would produce a nonsensical bool value in the latter
> | case.
> | 
> | OCaml doesn't have a mechanism for making +, - applicable to a limited
> | set of types and for dispatching their implementation based on the type
> | rather than on the physical representation.
> 
> This is an excellent point.  (Somebody else also pointed it out in a
> reply to me.)

Since this seems to be the most serious issue, I checked what could
happen in slightly greater detail.

----------------------------------------------------------------------
        Objective Caml version 3.08.2

# let c = (Obj.magic (Obj.magic true + Obj.magic true) : bool) ;;
val c : bool = <unknown constructor>
# if c then 123 else 456 ;;
- : int = 123
# type t = A | B ;;
type t = A | B
# let d = (Obj.magic (Obj.magic B + Obj.magic B) : t) ;;
val d : t = <unknown constructor>
# (function A -> 78 | B -> 90) d ;;
- : int = 90
# 
----------------------------------------------------------------------

So, it indeed leads to "unknown" values and behaviors, but doesn't
seem to break memory safety (in this case, at least).  This may or may
not be regarded as something similar to the "undefined" (or only
partially specified) behavior of Pervasives.compare for function
values.

Or are there actually other cases where even memory safety can be
broken?

	Eijiro