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 KAA04379; Thu, 11 Dec 2003 10:52:48 +0100 (MET) 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 KAA04361 for ; Thu, 11 Dec 2003 10:52:47 +0100 (MET) Received: from beaune.inria.fr (beaune.inria.fr [128.93.8.3]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hBB9qkr22738; Thu, 11 Dec 2003 10:52:46 +0100 (MET) Received: by beaune.inria.fr (8.8.8/1.1.22.3/14Sep99-0328PM) id KAA0000003164; Thu, 11 Dec 2003 10:52:45 +0100 (MET) Date: Thu, 11 Dec 2003 10:52:45 +0100 From: Luc Maranget To: skaller Cc: Pierre Weis , caml-list Subject: Re: [Caml-list] Question Message-ID: <20031211105245.A2501@beaune.inria.fr> References: <200312101027.LAA20728@pauillac.inria.fr> <1071071631.4023.16.camel@pelican> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1071071631.4023.16.camel@pelican>; from skaller@ozemail.com.au on Thu, Dec 11, 2003 at 02:53:51AM +1100 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 invariants:01 runtime:01 slower:01 unspecified:01 optimised:01 expr:01 blabla:01 compiler:01 compiler:01 semantics:01 ocaml:01 wrt:01 wrt:01 rec:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > The when construct introduces a guard to a pattern matching > > clause. This means that a when construct is global to the entire > > pattern of the clause it appears in; it means in particular that no > > when construct can be nested into a pattern and the question of its > > distributivity wrt any other construct is pointless. > > > > > Is there a good reason for this? > > > > Yes: simplicity, complexity invariants preservation for runtime > > pattern analysis decisions even in the presence of when clauses, > > easier understanding of the compiler warnings, simplicity and > > well-definedness semantics (in particular the desired invariance wrt > > the order of evaluation). > > Whoa! Can you say that slower? Felix allows nested when clauses > in patterns (however it doesn't allow alternatives yet). > The current implementation is unoptimised, > I just evaluate the match of each pattern in turn until one matches. > > One small difference .. the argument of a when clause is > an expression .. and felix expressions are purely functional > so there is no issue of order of evaluation changing anything. > > So, what have I lost? In some sense order of evaluation may not be an issue (at worst it can be left unspecified!). That said. When clauses inside patterns would for sure much complicate optimized compilation and maybe diagnostics. So basically you loose optimised compilation and simple diagnostics. Moreover at the moment the AST types for patterns and expression are not mutually recursive. Expressions depend on patterns but not the other way round. As far as I know, The compiler take advantage of this in many places, with code that more or less looks as follows let rec treat_pat = blabala ;; let rec treat_expr = blabla ... treat_pat ... ;; Making patterns and expressions mutually dependant, would perhaps, break some untold assumption, hidden invariant etc. To conclude adopting the Felix way in Ocaml is by no mean a trivial change and benefits are unclear, how many programs do realy use this feature ? Cheers, -- Luc Maranget ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners