From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr 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 AA478BBBB for ; Tue, 28 Feb 2006 16:51:12 +0100 (CET) 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 k1SFpCjX008473 for ; Tue, 28 Feb 2006 16:51:12 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA13425 for ; Tue, 28 Feb 2006 16:51:11 +0100 (MET) Received: from [128.93.11.101] (buzet.inria.fr [128.93.11.101]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k1SFpACa023039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2006 16:51:10 +0100 Message-ID: <44047166.70308@inria.fr> Date: Tue, 28 Feb 2006 16:51:02 +0100 From: Alain Frisch User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: louis.gesbert@laposte.net Cc: caml-list@inria.fr Subject: Re: [Caml-list] Bugs with pattern-matching and exceptions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44047170.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4404716E.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; frisch:01 frisch:01 caml-list:01 bug:01 ocaml:01 syntax:01 val:01 exn:01 bool:01 bool:01 val:01 exn:01 generative:01 constructors:01 pointer:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Louis Gesbert wrote: > More recently, I discovered a far worse bug which leads to some > inconsistency. Ocaml offers a syntax " exception E' = E " to create an > alias to an exception, which I have hardly ever seen used (with reason, it > seems). The problem you raise is not related to the "exception E' = E" construction. E.g.: # exception E of int;; exception E of int # let x = E 1;; val x : exn = E 1 # exception E of bool;; exception E of bool # let y = E true;; val y : exn = E true # x = y;; - : bool = true Comparing values of different types can be unsafe, I guess, when the values are custom blocks. Exception definitions are generative. The equality of two exception constructors, as checked by pattern matching, is implemented as reference (pointer) equality. Concretely, the identity of an exception constructor is a "string ref", whose content corresponds to the displayed name of the exception. Unfortunately, the generic comparison function has no way to know that the blocks under consideration are exceptions and that the constructoes should thus be compared physically. For equality, this would be quite simple to patch (e.g. reserve a special GC tag to indicate exception blocks). For the total ordering, one could e.g. generate a globally unique integer identifier (pointer comparison does not work because blocks can be moved by the GC). The other solution is to keep ourselves from using generic comparison for exceptions and to rely only on pattern matching. -- Alain