I would assume that this function:
foo list@(h:t) = list
is equivalent to
foo list = list
where (h:t)=list
But passing [] to the first generates an error
even though h and t are never used! Passing [] to
the second works just fine.
At this point, I sort of understand the reason for
tis 2004-03-30 klockan 17.30 skrev S. Alexander Jacobson:
I would assume that this function:
foo list@(h:t) = list
is equivalent to
foo list = list
where (h:t)=list
But passing [] to the first generates an error
even though h and t are never used! Passing [] to
the second
A lot. If everything were irrefutable, then the following:
mymap f (x:xs) = f x : xs
mymap f [] = []
would never get to the second branch and would fail when it reached the
end of a list. so would it if you put the lines in the other, more
natural, order, though perhaps it's less clear
On Tue, 2004-03-30 at 18:01, S. Alexander Jacobson wrote:
Thanks for the ~ syntax, but my question is really
why you need it? What benefit do you get from
refutable patterns?
Alternatively, would anything break if a future
Haskell just treated all patterns as irrefutable?
A short
G'day all.
Quoting Duncan Coutts [EMAIL PROTECTED]:
Or finally, the it's what you want most often argument.
How about the it's the most natural thing argument?
Pattern matching on the LHS of a function definitions looks, for all the
world, like a set of rewrite rules. That's because, in some
Andrew Bromage:
Pattern matching on the LHS of a function definitions looks, for all the
world, like a set of rewrite rules. That's because, in some sense, they
are.
In this definition:
f (x:xs) = 1 + f xs
f [] = []
Intuitively, the first rule should only fire if the expression being
