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 PAA10965; Tue, 29 May 2001 15:50:07 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 PAA11130 for ; Tue, 29 May 2001 15:50:06 +0200 (MET DST) Received: from beaune.inria.fr (beaune.inria.fr [128.93.8.3]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f4TDo5v29460 for ; Tue, 29 May 2001 15:50:05 +0200 (MET DST) Received: by beaune.inria.fr (8.8.8/1.1.22.3/14Sep99-0328PM) id PAA0000018491; Tue, 29 May 2001 15:50:05 +0200 (MET DST) From: Luc Maranget Message-Id: <200105291350.PAA0000018491@beaune.inria.fr> Subject: Re: [Caml-list] ocaml and named constants To: skaller@ozemail.com.au (John Max Skaller) Date: Tue, 29 May 2001 15:50:05 +0200 (MET DST) Cc: caml-list@inria.fr In-Reply-To: <3B12F66C.5F5793F9@ozemail.com.au> from "John Max Skaller" at mai 29, 2001 11:07:56 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > Xavier Leroy wrote: > > > > I ask because it seems odd that camlp4 includes > > > a feature for creating real defined constants that are textually > > > substituted before compilation begins. > > > > One motivation for this is to be able to put named constants in > > patterns, e.g. > > > > match get_next_byte() with > > mpg_joint_stereo -> ... > > | mpg_78rpm -> ... > > | _ -> ... > > > > which cannot be done in plain ML. > > Is there any semantic reason why > one cannot use variables, or even expressions? Apart from > the obvious syntactic problem. Not that obvious, I think this would make pattern-matching look like even more complicated. It is good to stress on the fact that in match .. with p ->, p is a pattern 1. Some value ``whith holes'' 2. Something we programmer and compiler know without any computation. Just for the sake of avoiding : if x=mpg_joint_stereo else if x=... else if ... I would not throw away the simple idea of what a pattern is. Now the usual Caml answer to such extension of patterns (the same apply to non-linear patterns such as (x,x)) If you want pattern matching, you can have it ! match get_next_byte() with x when x = mpg_joint_stereo -> ... | x when x = mpg_78rpm -> ... | _ -> And, when the mpg_xxx are known constants some optimization (which does not exist now) could apply, such as replacing pattern ``x when x=1'' by pattern ``1''. Hence we need no extension for doing what you wish, we only need more optimisations. On the other hand, if we extend pm the way you want (if I got it right let us assume a backquoting mecanism) match get_next_byte() with << mpg_joint_stereo >> -> ... | << mpg_78rpm >> -> ... | _ -> ... Then we should treat the general case, and the semantics can only be let x = get_next_byte in if x=mpg_... etc. The overall benefit of including such a feature is not very clear for me. Compilation difficulties and programmer errors are, IMHO. on the way. -- > John (Max) Skaller, mailto:skaller@maxtal.com.au > 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 > checkout Vyper http://Vyper.sourceforge.net > download Interscript http://Interscript.sourceforge.net > ------------------- > To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr > ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr