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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
