Reading http://www.seas.upenn.edu/~cis194/spring13/lectures/04-higher-order.html it states
In particular, note that function arrows associate to the right, that
is, W -> X -> Y -> Z is equivalent to W -> (X -> (Y -> Z)). We can
always add or remove parentheses around the rightmost top-level arrow
in a type.
Function arrows associate to the right but as function application associates to the left then what is usefulness of this information ? I feel I'm not understanding something as to me it is a meaningless point that function arrows associate to the right. As function application always associates to the left then this the only associativity I should be concerned with ?
Function arrows associate to the right but [...] what is usefulness of this information?
If you see a type signature like, for example, f : String -> Int -> Bool you need to know the associativity of the function arrow to understand what the type of f really is:
if the arrow associates to the left, then the type means (String -> Int) -> Bool, that is, f takes a function as argument and returns a boolean.
if the arrow associates to the right, then the type means String -> (Int -> Bool), that is, f takes a string as argument and returns a function.
That's a big difference, and if you want to use f, you need to know which one it is. Since the function arrow associates to the right, you know that it has to be the second option: f takes a string and returns a function.
Function arrows associate to the right [...] function application associates to the left
These two choices work well together. For example, we can call the f from above as f "answer" 42 which really means (f "answer") 42. So we are passing the string "answer" to f which returns a function. And then we're passing the number 42 to that function, which returns a boolean. In effect, we're almost using f as a function with two arguments.
This is the standard way of writing functions with two (or more) arguments in Haskell, so it is a very common use case. Because of the associativity of function application and of the function arrow, we can write this common use case without parentheses.
When defining a two-argument curried function, we usually write something like this:
f :: a -> b -> c
f x y = ...
If the arrow did not associate to the right, the above type would instead have to be spelled out as a -> (b -> c). So the usefulness of ->'s associativity is that it saves us from writing too many parentheses when declaring function types.
If an operator # is 'right associative', it means this:
a # b # c # d = a # (b # (c # d))
... for any number of arguments. It behaves like foldr
This means that:
a -> b -> c -> d = a -> (b -> (c -> d))
Note: a -> (b -> (c -> d)) =/= ((a -> b) -> c) -> d ! This is very important.
What this tells us is that, say, foldr:
λ> :t foldr
foldr :: (a -> b -> b) -> b -> [a] -> b
Takes a function of type (a -> b -> b), and then returns... a function that takes a b, and then returns... a function that takes a [a], and then returns... a b. This means that we can apply functions like this
f a b c
because
f a b c = ((f a) b) c
and f will return two functions each time an argument is given.
Essentially, this isn't very useful as such, but is important information for when we want to interpret and call function types.
However, in functions like (++), associativity matters. If (++) were left associative, it would be very slow, so it's right associative.
Early functional language Lisp suffered from excessively nested parenthesis (which make code (or even text (if you do not mind to consider a broader context)) difficult to read. With time functional language designers opted to make functional code easy to read and write for pros even at cost of confusing rookies with less uniform rules.
In functional code,
function type declaration like (String -> Int) -> Bool are much more rare than functions like String -> (Int -> Bool), because functions that return functions are trade mark of functional style. Thus associating arrows to right helps reduce parentheses number (on overage, you might need to map a function to a primitive type). For function applications it is vise-versa.
The main purposes is convenience, because partial function application goes from left to right.
Every time you partially apply a function to a set of values, the remaining type has to be valid.
You can think of arrow types as a queue of types, where the queue itself is a type. During partial function application, you dequeue as many types from the queue as the number of arguments, yielding whatever remains of the queue. The resulting queue is still a valid type.
This is why types associate to the right. If types associate to the left, it will behave like a stack, and you won't be able to partially apply it the same way without leaving "holes" or undefined domains. For instance, say you have the following function:
foo :: a -> b -> c -> d
If Haskell types were left-associative, then passing a single parameter to foo would yield the following invalid type:
((? -> b) -> c) -> d
You will then be forced to circumvent it by adding parentheses, which could hamper readability.
Related
A professor teaching a class I am attending claimed the following.
A higher-order function could have only one arrow when checking its type.
I don't agree with this statement I tried to prove it is wrong. I tried to set up some function but then I found that my functions probably aren't higher-order functions. Here is what I have:
f x y z = x + y + z
f :: a -> a-> a -> a
g = f 3
g :: a -> a -> a
h = g 5
h :: a -> a
At the end of the day, I think my proof was wrong, but I am still not convinced that higher-order functions can only have more than one arrow when checking the type.
So, is there any resource or perhaps someone could prove that higher-order function may have only one arrow?
Strictly speaking, the statement is correct. This is because the usual definition of the term "higher-order function", taken here from Wikipedia, is a function that does one or both of the following:
takes a function as an argument, or
returns a function as its result
It is clear then that no function with a single arrow in its type signature can be a higher-order function, because in a signature a -> b, there is no "room" to create something of the form x -> y on either side of an arrow - there simply aren't enough arrows.
(This argument actually has a significant flaw, which you may have spotted, and which I'll address below. But it's probably true "in spirit" for what your professor meant.)
The converse is also, strictly speaking, true in Haskell - although not in most other languages. The distinguishing feature of Haskell here is that functions are curried. For example, a function like (+), whose signature is:
a -> a -> a
(with a Num a constraint that I'll ignore because it could just confuse the issue if we're supposed to be counting "arrows"), is usually thought of as being a function of two arguments: it takes 2 as and produces another a. In most languages, which all of course have an analagous function/operator, this would never be described as a higher-order function. But in Haskell, because functions are curried, the above signature is really just a shorthand for the parenthesised version:
a -> (a -> a)
which clearly is a higher-order function. It takes an a and produces a function of type a -> a. (Recall, from above, that returning a function is one of the things that characterises a HOF.) In Haskell, as I said, these two signatures are one and the same thing. (+) really is a higher-order function - we just often don't notice that because we intend to feed it two arguments, by which we really mean to feed it one argument, result in a function, then feed that function the second argument. Thanks to Haskell's convenient, parenthesis-free, syntax for applying functions to arguments, there isn't really any distinction. (This again contrasts from non-functional languages: the addition "function" there always takes exactly 2 arguments, and only giving it one will usually be an error. If the language has first-class functions, you can indeed define the curried form, for example this in Python:
def curried_add(x):
return lambda y: x + y
but this is clearly a different function from the straightforward function of two arguments that you would normally use, and usually less convenient to apply because you need to call it as curried_add(x)(y) rather than just say add(x,y).
So, if we take currying into account, the statement of your professor is strictly true.
Well, with the following exception, which I alluded to above. I've been assuming that something with a signature of the form
a -> b
is not a HOF*. That of course doesn't apply if a or b is a function. Often, that function's type will include an arrow, and we're tacitly assuming here that neither a or b contains arrows. Well, Haskell has type synonyms, so we could easily define, say:
type MyFunctionType = Int -> Int
and then a function with signature MyFunctionType -> a or a -> MyFunctionType is most certainly a HOF, even though it doesn't "look like one" from just a glance at the signature.
*To be clear here,a and b refer to specific types which are as yet unspecified - I am not referring to an actual signature a -> b which would mean a polymorphic function that applies to any types a and b, which would not necessarily be functions.
Your functions are higher order. Indeed, take for example your function:
f :: a -> a -> a -> a
f x y z = x + y + z
This is a less verbose form of:
f :: a -> (a -> (a -> a))
So it is a function that takes an a and returns a function. A higher order function is a function that (a) takes a function as parameter, or (b) returns a function. Both can be true at the same time. Here your function f returns a function.
A function thus always has type a -> b with a the input type, and b the return type. In case a has an arrow (like (c -> d) -> b), then it is a higher order function, since it takes a function as parameter.
If b has an arrow, like a -> (c -> d), then this is a higher order function as well, since it returns a function.
Yes, as Haskell functions are curried always, I can come up with minimal examples of higher order functions and examples:
1) Functions that takes a function at least as parameter, such as:
apply :: (a -> b) -> a -> b
apply f x = f x
2) at least 3 arguments:
sum3 :: Int -> Int -> Int
sum3 a b c = a + b + c
so that can be read as:
sum3 :: Int -> (Int -> Int)
I am currently studying functional programming and it's most important feature : Higher Order Functions.
It's not as crystal clear as I'd like currently and therefore I'd like to understand perfectly how HOFs work.
Considering this function
{- Curried addition. -}
plusc :: Num a => a -> (a -> a)
plusc = (+)
To what extent can we say that this function uses currying and is a HOF ?
EDIT : Basically, I don't understand how the definition of the function stands for an addition (parameters, associativity, etc )
I wouldn't personally call plusc a HOF, because its arguments aren't functions. A way to spot an obvious HOF is to look for a parens in the signature that aren't at the leftmost side:
{- equivalent signature -}
plusc :: Num a => a -> a -> a
When we remove optional parens, it's obvious that the function isn't a HOF that takes functions, but it's curried.
Note: Since every curried function can return a function, though, we might say that after partially applying it, it returns a function, and as such operates on functions - so it is a HOF. I don't think this is particularly helpful way of describing/learning the concept, but I suppose the definition would span both parameters and results.
An uncurried version would simply group its arguments:
plusUnc :: Num a => (a, a) -> a
Now a HOF might take such a function and turn it into some other one:
imu :: Num a => (a -> a -> a) -> (a -> a -> a)
imu f = \a b -> f a b
Note: The lambda impl could obviously be simplified, I spelled it out just for illustration.
Note that f is the "lower" order function that's being passed into imu. To use it:
imuPlus = imu plusc -- a function is being passed
imuPlus 1 2 -- == 3
Note: since we're mixing both concepts (and you asked for both), imu is also curried. An uncurried version could look like this:
imuUnc :: ((a -> a -> a), (a, a)) -> a
Now it is a HOF (it has a function in the parameters), but it doesn't return a function, which differs from the examples above.
It's just much easier to use when it's curried, though, mostly because of partial application.
I was doing a Haskell types exercise and this one has stumped me. The provided expression is:
f2 f g h = h.g.f
And the type for f2 is apparently:
f2 :: (a -> b1) -> (b1 -> b) -> (b -> c) -> a -> c
This seems overly complicated for such a short expression. Can someone explain why this makes sense as the type?
Why do you think it's complicated? It's just a function that takes three functions (of matching types) and returns a new one.
I've renamed b1 to b and updated other names, for consistency. So here is a slightly edited version:
f2 :: (a -> b) -> (b -> c) -> (c -> d) -> a -> d
Here, f2 takes f which has type a -> b. Meaning, it's a function, with some input of some type a (a can be just anything, no restrictions here) and some return value of type b.
Then f2 takes g which input's type must match f's output, so it's b -> c. It cannot be, like, e -> c (where e is something different from b), or the code won't make sense as it won't be possible to compose f . g.
And exactly the same goes for the third argument, h, with type c -> d.
The result of function composition (what f2 returns) is a new function that takes in whatever f does and returns whatever h returns, so it's a -> d. With this we've covered the whole type definition.
Basically, it's a relatively long definition, but I think it's of a very simple nature.
I find these “determine the type of such and such expression” generally a bit backwards. Types should always come first: you want to program a solution to some task, you formulate the problem description as a type signature. Then you go ahead and actually write an implementation.
In this case, you'd start with the problem: I have three functions f, g and h, and a value of type that I can pass to f. Furthermore, the functions have pairwise matching result/argument type. Hence the signature
f2 :: (α -> β) -> (β -> γ) -> (γ -> δ) -> α -> δ
You could now go on and implement this in explicit-pointed form, i.e.
f2 f g h x = h (g (f x))
which is still quite brief. After all, it's quite a simple task!
But in Haskell you can make it even shorter, by using the standard composition operator .. The fact that the final implementation is so extremely short is basically just down to the fact that f2 does essentially the same thing as ., just twice. So this isn't more surprising than if you have a very complex task with a complicated type signature, but discover some library that contains a function which does almost that exact task. Obviously, invoking that ready-build function will give you a much shorter implementation than the task complexity would suggest, but the complexity is merely deferred to the library function.
why doesn't Haskell use some kind of special format to reflect this, or -> c can be understood in another way?
You can look at babel’s type signature in two ways.
(1) babel takes two inputs of type a and b; it produces an output of type c.
(2) babel takes an input of type a and produces an output of type (b -> c).
(1) gives you back a value of type c with babel fully applied. (2) gives you back a intermediate function of type (b -> c) with babel partially applied; if you choose to apply the intermediate function to a value of type b, you then get the result as you would get from case (1).
This ability to choose partially or fully apply a function gives you the power to build complex functions by gluing simple (intermediate) functions together.
why doesn't Haskell use some kind of special format to reflect this…?
By default, all functions in Haskell take one input; a function of two arguments is just a function that returns a function. Currying by default is already clear in the type signature. This is why (->) associates to the right so we don't have to write babel :: a -> (b -> c)
Haskell uses a concept called currying, which means there are only single parameter functions, and multiple parameter functions are just functions returning another functions, with the previous parameter "baked in", until all the parameters are filled in.
so
add :: Int -> Int -> Int
add x y = x + y
is equivalent to
add :: Int -> (Int -> Int)
add = \x -> \y -> x + y
You can think of a function like babel :: a -> b -> c as a pipeline.
It's a function that takes an a, then returns a function that takes a b, which then returns a c. Partial application is what makes this work, any application returns something, either a function or the last value c.
Reading https://wiki.haskell.org/Currying
it states :
Much of the time, currying can be ignored by the new programmer. The
major advantage of considering all functions as curried is
theoretical: formal proofs are easier when all functions are treated
uniformly (one argument in, one result out). Having said that, there
are Haskell idioms and techniques for which you need to understand
currying.
What is a Haskell technique/idiom that a deeper understanding of currying is required ?
Partial function application isn't really a distinct feature of Haskell; it is just a consequence of curried functions.
map :: (a -> b) -> [a] -> [b]
In a language like Python, map always takes two arguments: a function of type a -> b and a list of type [a]
map(f, [x, y, z]) == [f(x), f(y), f(z)]
This requires you to pretend that the -> syntax is just for show, and that the -> between (a -> b) and [a] is not really the same as the one between [a] -> [b]. However, that is not the case; it's the exact same operator, and it is right-associative. The type of map can be explicitly parenthesized as
map :: (a -> b) -> ([a] -> [b])
and suddenly it seems much less interesting that you might give only one argument (the function) to map and get back a new function of type [a] -> [b]. That is all partial function application is: taking advantage of the fact that all functions are curried.
In fact, you never really give more than one argument to a function. To go along with -> being right-associative, function application is left-associative, meaning a "multi-argument" call like
map f [1,2,3]
is really two function applications, which becomes clearer if we parenthesize it.
(map f) [1,2,3]
map is first "partially" applied to one argument f, which returns a new function. This function is then applied to [1,2,3] to get the final result.