Mismatched or inconsistent syntax is also an issue. For example in Haskell the curried function signatures don’t actually match the non-curried function definition.
I would expect the signature of a curried function to match the definition of a curried function, and the signature of a non-curried function to match the definition of a non-curried function; expecting the signature of a curried function to match the definition of a non-curried function seems to be missing the point.
I presume the author was trying to make a more subtle point, but what?
It is only a minor issue of inconsistancy (I just don't like picking on the same languages all the time, so I look for examples elsewhere).
What I mean is that the signatures have a curried notation, like x -> y -> z, but the function is just a traditional function wehre both x and y can be used directly. That is, the function is truly multi-parametered.
I don't understand this point. If you have arguments x and y that you want to apply to this function, I don't see the problem in "using them directly".
Function application in Haskell is first class. If you have
f :: x -> y -> z
f x y = undefined
then use it like
(f 0)
you have a new function:
f 0 :: y -> z
then if you apply again,
(f 0) 1
and this final expression, equivalent to f 0 1, gives you something of type 'z'
The signature says how you can curry the function, but what I'm saying is that the body of the function is written essentially oblivious to that currying. For example, the body of the function would be written the same if the signature were "x->y->z" or "y->x->z".
If we consider (f 0) this provides an auto-currying of the function. However, this "f" is quite different from a function that has the signature "x->(y->z)" where the body would indeed need to be different (where the currying is explicit).
You don't have to syntactically consume all of arguments of a function to write its body.
f :: a -> Int -> Int -> Int
f x = (+)
There really isn't anything meaningful to do with a function before it has consumed all it's arguments other than returning another function.
> However, this "f" is quite different from a function that has the signature "x->(y->z)"
Yes, we have applied the argument of type 'x'. f 0 is no longer of type "x -> y -> z", or "x -> (y -> z)" (because of -> precedence, the two are equivalent), it is "y -> z".
5 comments
[ 5.8 ms ] story [ 19.6 ms ] threadMismatched or inconsistent syntax is also an issue. For example in Haskell the curried function signatures don’t actually match the non-curried function definition.
I would expect the signature of a curried function to match the definition of a curried function, and the signature of a non-curried function to match the definition of a non-curried function; expecting the signature of a curried function to match the definition of a non-curried function seems to be missing the point.
I presume the author was trying to make a more subtle point, but what?
What I mean is that the signatures have a curried notation, like x -> y -> z, but the function is just a traditional function wehre both x and y can be used directly. That is, the function is truly multi-parametered.
Function application in Haskell is first class. If you have
then use it like you have a new function: then if you apply again, and this final expression, equivalent to f 0 1, gives you something of type 'z'If we consider (f 0) this provides an auto-currying of the function. However, this "f" is quite different from a function that has the signature "x->(y->z)" where the body would indeed need to be different (where the currying is explicit).
> However, this "f" is quite different from a function that has the signature "x->(y->z)"
Yes, we have applied the argument of type 'x'. f 0 is no longer of type "x -> y -> z", or "x -> (y -> z)" (because of -> precedence, the two are equivalent), it is "y -> z".
Currying is explicit.
is just short hand for