Equations for `foo' have different numbers of arguments

Hi. There is a limitation, in Haskell, that I'm not sure to understand. Here is an example: module Main where divide :: Float -> Float -> Float divide _ 0 = error "division by 0" divide = (/) main = do print $ divide 1.0 0.0 print $ divide 4.0 2.0 With GHC I get: Equations for `divide' have different numbers of arguments With HUGS: Equations give different arities for "divide" However the two equations really have the same number of arguments. What's the problem? Thanks Manlio Perillo

Bulat Ziganshin ha scritto:
Hello Manlio,
Tuesday, March 24, 2009, 5:44:14 PM, you wrote:
divide _ 0 = error "division by 0" divide = (/)
Equations for `divide' have different numbers of arguments
you should write
divide a b = a/b
Right. But my question was: why can't I write the function as I did? Why can't I write an equation in the curried form? Thanks (and thanks for the other responses, I will reply only here) Manlio

Manlio Perillo
Hi.
There is a limitation, in Haskell, that I'm not sure to understand. Here is an example:
module Main where
divide :: Float -> Float -> Float divide _ 0 = error "division by 0" divide = (/)
main = do print $ divide 1.0 0.0 print $ divide 4.0 2.0
With GHC I get: Equations for `divide' have different numbers of arguments
With HUGS: Equations give different arities for "divide"
However the two equations really have the same number of arguments.
What's the problem?
Equations not being what you think they are. They aren't "the symbol 'divide' equals that function" but "lhs of '=', '=', and rhs of '='. 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. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

Achim Schneider wrote:
The other might be implementation issues: it makes pattern match rules more complex.
But only marginally, right? f A B = biz f B = bar f = bam could be trivially rewritten to: f A B = biz f B y = bar y f x y = bam x y Martijn.

Yes, but this seems to have terrifying implications... On Tue, Mar 24, 2009 at 11:25 AM, Martijn van Steenbergen < martijn@van.steenbergen.nl> wrote:
Achim Schneider wrote:
The other might be implementation issues: it makes pattern match rules more complex.
But only marginally, right?
f A B = biz f B = bar f = bam
could be trivially rewritten to:
f A B = biz f B y = bar y f x y = bam x y
Martijn.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- /jve

Martijn van Steenbergen
f x y = bam x y
This would introduce another matching of x on the outside of bam, and I don't know if this works without significantly messing with e.g. strictness. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.
participants (5)
-
Achim Schneider
-
Bulat Ziganshin
-
John Van Enk
-
Manlio Perillo
-
Martijn van Steenbergen