[Haskell-cafe] different arities

[Henning Sato Rosen]

These two functions have the same type. Is this behaviour intended?
(Can functions of the same type have different arities?)

-------------------------------------------
data Fun = Increment | Square
fun:: Fun -> Int -> Int
fun Increment n = n+1
fun Square = (\n -> n*n)
-------------------------------------------

Error message in
HUGS:
ERROR "arity.hs":17 - Equations give different arities for "fun
GHC:
arity.hs:3: Varying number of arguments for function `fun'

/Regards Henning

[Marco Túlio Gontijo e Silva]

Post by Henning Sato Rosen
data Fun = Increment | Square
fun:: Fun -> Int -> Int
fun Increment n = n+1
fun Square = (\n -> n*n)

I think that this is because you gave two definitions of the same
function with different number of variables.

fun Increment n = n+1
fun Square n = n*n

will do it.

You don't have to go that far to see this error, you can do something
like:

add :: Int -> Int -> Int
add 5 = (+10)
add x y = x + y

Will give you the same error message.
--
[]'s
marcot
mailto:***@minaslivre.org
jabber:***@jabber.org
ICQ:50599075
MSN:***@dcc.ufmg.br
Tel:[phone]
Cel:91844179
http://www.dcc.ufmg.br/~marcot/
"A crocrância é fundamental
para quem quer ser fundamental."
Bizarro da Silva e marcot

[Henning Sato Rosen]

You have met up with one of the rules for function bindings in standard
Haskell (http://www.haskell.org/onlinereport/decls.html). The use of "arity"
in the error message is a poor choice of words. The rule is that each clause
in the function binding must contain the same number of argument patterns.

Oh, I see, thanks Scott and Marco for answering! I am beginning to
realise that everything worth knowing about Haskell really is in the
report:-)

Regards/Henning

--------------------------------------------------------------------------------------------------

BTW, what might the reason for that be, is it for the sake of ease of
translation/implementation, or for the sake of some principle? I
mean, as soon as a person realises that there are multiple syntaxes
for declaring a function, he/she will unify them to one abstract
function in the head (where the resulting type matters, not the
syntax).
So, even if one probably should avoid mixing as in the example, for
readability reasons, one might still argue that the restriction goes
against PoLS.

Just a thought.

[Keith Wansbrough]

Post by Henning Sato Rosen

Haskell (http://www.haskell.org/onlinereport/decls.html). The use of "arity"

[..]

Post by Henning Sato Rosen
BTW, what might the reason for that be, is it for the sake of ease of
translation/implementation, or for the sake of some principle? I
mean, as soon as a person realises that there are multiple syntaxes
for declaring a function, he/she will unify them to one abstract
function in the head (where the resulting type matters, not the
syntax).

The two reasons that occur to me are:

(i) to catch more errors, specifically, to catch the error of
accidentally missing an argument. Consider:

f False False = 0
f False True = 1
f True = error "TF not allowed"
f True True = 3

Without the rule, this would be accepted; with the rule, it is
rejected - rightly so, I think.

(ii) to make the meaning of pattern-matching easier to define and more
regular. The current definition (sec 4.4.3.1 of the report - see the
Translation sidebar) makes essential use of the fact that the array of
patterns is rectangular. Without this, the precise order of matching
might be ambiguous, or at least harder to define.

http://www.haskell.org/onlinereport/decls.html#sect4.4.3.1

HTH.

--KW 8-)