Why can I curry one of the patterns but not the other in my pattern matching?

Question

I have I have a function with two arguments that I have to pattern match over. If I use currying on the first pattern it won't compile:

  drop' :: Int -> [a] -> [a] 
  drop' 0  = id -- ghci: "Equations for drop' have different numbers of arguments"
  drop' n (x:xs) = drop' (n-1) xs

The compiler gives this output:

99.hs:106:3:
Equations for drop' have different numbers of arguments
  99.hs:106:3-15
  99.hs:107:3-33
In an equation for `split':
    split xs n
      = (take' n xs, drop' n xs)
      where
          take' 0 _ = []
          take' n (x : xs) = x : take (n - 1) xs
          drop' 0 = id
          drop' n (x : xs) = drop' (n - 1) xs  
 Failed, modules loaded: none.

If I only give the curried pattern, however, then it compiles:

  drop' :: Int -> [a] -> [a] 
  drop' 0  = id -- compiles

What gives?

All equations defining a function must have the same number of arguments. So `drop 0 = id; drop n = \ (_:xs) -> drop (n-1) xs` would compile. — Daniel Fischer, Mar 23 '13 at 23:58
[Note that all clauses defining a function must be contiguous, **and the number of patterns in each clause must be the same.**](http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-830004.4.3) — Daniel Fischer, Mar 24 '13 at 00:02

score 10 · Accepted Answer · answered Mar 24 '13 at 00:03

10

The only explanation I could find (http://www.haskell.org/pipermail/haskell-cafe/2009-March/058456.html):

The problem is mostly syntactical, in the sense that most occurrences of definitions with a different number of arguments are plain typos. The other might be implementation issues: it makes pattern match rules more complex.

answered Mar 24 '13 at 00:03

Koterpillar

7,883
2
25
41

It seems to me that a lot of thought went into the various Haskell Reports on how to protect against programmer error, without sacrificing what you can express in the language. See also Daniel Fischer's comment, and even the dreaded monomorphishm restriction falls into this category. It's a slight hassle now, but you'll be thankful for it later. – yatima2975 Mar 24 '13 at 00:39
@yatima2975 I can understand the want to nip common programmer errors in the bud. But couldn't it just be a compiler warning? Though I guess having a bunch of compiler warnings could be annoying, too (not to mention the potential annotations for suppressing them), so I guess it's a decent compromise since I can't imagine a case where the code would be significantly less expressive with this slight restriction. – Guildenstern Mar 24 '13 at 01:57

score 1 · Answer 2 · answered Mar 24 '13 at 00:01

1

I can't tell you why for sure, but this is a known limitation. All cases of the same function have to have the same number of arguments.

answered Mar 24 '13 at 00:01

Peter Hall

53,120
14
139
204

score 1 · Answer 3 · answered Mar 24 '13 at 02:25

1

This is an annoying "feature" of GHC, to be sure, but to fix it, you can do this:

drop' n = \(x:xs) -> drop' (n-1) xs

You have to curry both or neither, and both to the same number of arguments. If this is a lint check, that's great: but I wish there were a compiler option to turn it on/off.

answered Mar 24 '13 at 02:25

jpaugh

6,634
4
38
90

2

Since this is identical to the other definition (and actually more verbose) it defeats the point a little IMHO. – daniel gratzer Mar 24 '13 at 03:10
@jozefg I posted this because I couldn't understand the other answers without further investigation: an alternate viewpoint is often useful. – jpaugh Mar 14 '16 at 14:18

Why can I curry one of the patterns but not the other in my pattern matching?

3 Answers3