Re: [Caml-list] Pattern matching over elements at the front of a container

[Jon Harrop <postmaster@jdh30.plus.com>]

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