From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA15877; Thu, 4 Oct 2001 14:28:15 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 OAA15863 for ; Thu, 4 Oct 2001 14:28:14 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f94CSCP08151; Thu, 4 Oct 2001 14:28:12 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA15855; Thu, 4 Oct 2001 14:28:11 +0200 (MET DST) Date: Thu, 4 Oct 2001 14:28:11 +0200 From: Xavier Leroy To: Gregory Morrisett Cc: Pierre Weis , Daniel Grossman , caml-list@inria.fr Subject: Re: [Caml-list] Pattern matcher no more supposed to warn on non exhaustive patterns ? Message-ID: <20011004142811.E14657@pauillac.inria.fr> References: <706871B20764CD449DB0E8E3D81C4D4301EE6C00@opus.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <706871B20764CD449DB0E8E3D81C4D4301EE6C00@opus.cs.cornell.edu>; from jgm@cs.cornell.edu on Thu, Oct 04, 2001 at 12:29:47AM -0400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > The issue with threads is a bit more troublesome. Consider: > > let x : (int->int) option ref = ref (Some (fun x -> x));; > > let foo z = > match z with > {contents=None} -> 0 > | {contents=Some(f)} -> f(0); > > The question is, does Caml core dump because the pattern matcher > assumes that the contents *has* to be a Some(-) in the second > case? Or does it do the derefence and check atomically? Or > does it add a default case that raises a Match exception? It reads the "contents" field once, let-binds its value, and use it in the remainder of the "match": (function z/52 (let (match/54 (field 0 z/52)) (if match/54 (apply (field 0 match/54) 0) 0)))) Since reading a record field is atomic, no crash can occur: foo either matches on the "old" or the "new" contents of the reference. - Xavier Leroy ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr