From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 9880DBC48 for ; Wed, 6 Apr 2005 22:31:57 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j36KVvAb012487 for ; Wed, 6 Apr 2005 22:31:57 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA17462 for ; Wed, 6 Apr 2005 22:31:56 +0200 (MET DST) Received: from saul.cis.upenn.edu (SAUL.CIS.upenn.edu [158.130.12.4]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j36KVsRD012484 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 6 Apr 2005 22:31:56 +0200 Received: from localhost (SAUL.CIS.upenn.edu [158.130.12.4]) by saul.cis.upenn.edu (8.12.10/8.12.9) with ESMTP id j36KVjCP011512; Wed, 6 Apr 2005 16:31:53 -0400 (EDT) Date: Wed, 06 Apr 2005 16:31:44 -0400 (EDT) Message-Id: <20050406.163144.51837136.eijiro_sumii@anet.ne.jp> To: caml-list@inria.fr Cc: sumii@saul.cis.upenn.edu Subject: Re: [Caml-list] ambitious proposal: polymorphic arithmetics From: Eijiro Sumii In-Reply-To: <20050406.151450.98562588.eijiro_sumii@anet.ne.jp> References: <87psx7lszi.fsf@qrnik.zagroda> <38697.131.254.50.45.1112810460.squirrel@mail.irisa.fr> <20050406.151450.98562588.eijiro_sumii@anet.ne.jp> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4254473D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 4254473A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 eijiro:01 sumii:01 eijiro:01 sumii:01 bool:01 ocaml:01 dispatching:01 bool:01 val:01 val:01 pervasives:01 polymorphic:01 constructor:01 constructor:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: P.S. > From: "Marcin 'Qrczak' Kowalczyk" > | + 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 = # 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 = # (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