[Haskell-cafe] Pattern matching does not work like this?

Richard O'Keefe ok at cs.otago.ac.nz
Wed Jul 15 21:56:07 EDT 2009


On Jul 15, 2009, at 9:57 PM, Magicloud Magiclouds wrote:

> Hi,
>  I do not notice this before. "fun ([0, 1] ++ xs) = .." in my code
> could not be compiled, parse error.

I apologise to everyone for my previous message in this
thread.  There was a Haskell message in amongst some Erlang
messages, and I thought this was an Erlang problem.

There are some programming languages, including Erlang,
in which <explicit list> ++ <pattern> IS accepted as a
<pattern>.  Haskell is not one of them.  It could be,
and there would be no ambiguity in elementary cases,
and it would no more involve matching against ++ than
n+1 involves matching against +.  Since the pattern on
the left of the ++ is required to be an explicit list,
there is no the slightest question of backtracking or
anything more general than ordinary pattern matching.

Consider
	[a,b,c]++xs
	 a:b:c:xs

The second is in general shorter (though less clear; it is
a real pity that Haskell syntax doesn't include something
like Clean's [head:tail], the inconsistency is irritating).
It's not the general case that this syntax was invented for,
but the case where the list is a string.

	"abc"++xs
	'a':'b':'c':xs

One of the arguments advanced against n+k patterns is
"which scope should + be looked up in? what if the + in
the standard prelude is not in scope?"

The same question can be asked about list++tail patterns;
what should it mean if the prelude's ++ was not in scope?

Programmers who have met "abc"++Xs sometimes turn around
and ask for Xs++"abc".  Perhaps it is better to keep the
camel's nose out of the tent.



More information about the Haskell-Cafe mailing list