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.