This site is updated infrequently. For up-to-date information, please visit the new OCaml website at ocaml.org.

ambitious proposal: polymorphic arithmetics
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: 2005-04-06 (20:31) From: Eijiro Sumii Subject: Re: [Caml-list] ambitious proposal: polymorphic arithmetics
```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

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

```