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 OAA10701; Mon, 28 Jun 2004 14:03:09 +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 OAA10685 for ; Mon, 28 Jun 2004 14:03:08 +0200 (MET DST) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5SC37SH006318 for ; Mon, 28 Jun 2004 14:03:07 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay01.plus.net with esmtp (Exim) id 1Beuqo-0003oC-0h for caml-list@inria.fr; Mon, 28 Jun 2004 12:03:06 +0000 From: Jon Harrop To: caml-list Subject: Re: [Caml-list] Pattern matching over elements at the front of a container Date: Mon, 28 Jun 2004 13:01:00 +0100 User-Agent: KMail/1.6.2 References: <200406261215.26971.postmaster@jdh30.plus.com> <20040628095709.B17827@beaune.inria.fr> In-Reply-To: <20040628095709.B17827@beaune.inria.fr> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406281301.01048.postmaster@jdh30.plus.com> X-Miltered: at concorde with ID 40E008FB.003 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; postmaster:99 caml-list:01 2004:99 lovas:01 ad-hoc:01 matcher:01 unspecified:01 ad-hoc:01 usefulness:01 tradeoff:01 jones':01 non-linear:01 non-linear:01 unification:01 matcher:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Monday 28 June 2004 08:57, Luc Maranget wrote: > > In the case of lists, you can match against the first two elements using > > the pattern "a::b::_". As the "_" is not bound in the corresponding > > expression, an equivalent notation could be invented for arrays in this > > case. Is this feasible? Would anyone else find this useful? > > It is certainly feasible, whether it is worth including in the compiler is > debatable... Yes, I can see what William Lovas meant about these being "ad-hoc" forms of pattern matching. These ideas came up while I was writing an interpreter for a host language which supports very exotic pattern matching. However, its pattern matcher has an unspecified (and often very high!) complexity, so apparently simple pieces of code fail to terminate on reasonable input before my patience runs out. This is clearly undesirable. I thought my idea of using something like [|h1; h2; ..|] was rather nice, because it works in finite time in the limit of infinite input-array size, but it is ad-hoc: why not [|..; h2; h1|] then? I suppose list decapitation "h1::h2::t" marks the limit in the usefulness vs difficulty tradeoff. Internally, I guess list matching is also based upon data structure's shape, whereas my [|h; ..|] and Richard Jones' "prefix"^str are not, because the data structures are both arrays which are "atomic" in this sense. > > Also, is it not possible to alter the definition and implementation of > > OCaml such that the pattern "(a, a)" is treated as "(a, b) when a=b"? Has > > this not been done because the "=" is suspect? > > Just say No (to non-linear patterns) ! Can you define "non-linear pattern" for me? > Basically and you can interpret this by saying << = is suspect >>, this > apparently innocent addition is a radical change in semantics. Mikael Brockman wrote to me, pointing out that matching this could use "the same unification algorithm as is used in other pattern matching" which sounds like a much better interpretation of the equality to me. Is that not correct because patterns can only contain constant values and cannot be matched against arbitrary values, like expressions or variables? So the pattern matcher does not currently require any notion of equality beyond those of constructors and of values of primitive types? Cheers, Jon. ------------------- 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