One related question is this, but some of the answer say that almost anything can be made point free, so what is wrong with this function?
\[x] -> x
http://pointfree.io/ doesn't seem to be able to write it in point-free style. Does this mean that it cannot be written that way? If so, what is the theoretical reason for it?
I can only observe that the function above is a "crippled" version of head
(or last
, fwiw) which can only operate on singleton lists. Indeed, applied on non singleton lists, it errors this way in ghci
:
*** Exception: <interactive>:380:5-13: Non-exhaustive patterns in lambda
Maybe the "non-exhaustivity" on the pattern is the reason why some functions cannot be written in point-free style?
Edit in the light of the answers:
I did not expect that the answers to my question could be so complex (I feel I just thought that the short answer was no, it cannot, actually), so I need to find some time to read them carefully, experiment a bit, and wrap my mind around them, otherwise I cannot decide which one should be accepted. For the time being, +1 to Jon Purdy's answer, which I could easily understand up to This is where I would stop in ordinary code.
A simple way to write this in pointfree form is to use a fold, where the accumulator state is one of the following:
Empty: We haven’t seen an element yet; keep it
Full: We have seen an element; raise an error
If the final state is Empty, we also raise an error. This accumulator can be represented naturally with
Maybe
:This is where I would stop in ordinary code. But…
If you don’t want to use an auxiliary data type, you can get rid of the
Maybe
by representing it with Böhm–Berarducci encoding:However, we can’t just do a wholesale replacement of
Just
withjust'
,maybe
withmaybe'
, and so on; the types won’t work out:The problem is that we’re returning a
Maybe'
from aMaybe'
continuation, and the compiler is trying to unify the two result types. One solution is to first eta-expand to let the typechecker know where we want to construct a distinct function:Then we can incrementally rewrite to pointfree form:
This is fully pointfree as well (far less readable than our original code, but better than what
pointfree
generates). In fact it’s good practice in pointfree code to use many small auxiliary definitions likefromMaybe'
instead of inlining everything, but we can proceed to inline their definitions.However, you can’t inline them naïvely and get exactly the same type—if you do, you’ll arrive at
(Foldable t) => t (a -> b) -> a -> b
. It could be a good exercise to work through where you need to eta-expand and rewrite in order to obtain the expected type,(Foldable t) => t a -> a
.Well, a data type isn't a function. As long as your function isn't unwrapping any data values (i.e. it's just shuffling them between functions/constructors), you can write it point free, but there's simply no syntax for point free matching. However, you only ever need one non-point-free function per data type: the fold. In Haskell, data types are pretty much defined by their folds. Taking the folds of the relevant data types as primitives, you can rewrite any function point free. Note that there are actually several possible "folds". For
[a]
, the recursive one (which comes from the Church/Böhm-Berarducci encoding) isfoldr :: (a -> b -> b) -> b -> [a] -> b
. Another possible fold is the "case
-but-it's-a-function" one,(a -> [a] -> b) -> b -> [a] -> b
, which comes from the Scott encoding (recursion can then be recovered withfix
, which is another "pointful pointfree primitive"), but, as @SilvioMayolo notes, there isn't such a function in the standard library. Either would do, but we don't have the latter predefined so let's just usefoldr
.can be written
fold
returns a pair, basically(what to return if this was the entire list, how to transform the head if it wasn't)
. For[]
, we want to return an error if that was the entire list, but otherwise pass through the element right before we hit[]
. Forx : xs
, if there is an element preceding it, we want to ignore it and return an error, and if there isn't, we want to pass it tosnd (fold xs)
, which checks ifxs = []
or else gives an error. We've eliminated all matches, so just shove this through pointfree.io to get the\x f -> _
in the argument tofoldr
out:Lovely.
Note: a previous version of this answer used an "inlined" auxiliary data type, basically because it just "came to me" as I was writing it. However, it failed to handle infinite lists properly (
behead [1..]
would hang). This version uses the built in pairs as the auxiliary data type, which have sufficient library support that I don't have to inline them to make it pointfree. It is slightly harder to inline(,)
, thereby eliminating the pointfullness inside the implementations offst
andsnd
, but it is still possible, using this newtype:Alternatively, cheat on the types a bit and use this:
Sure, pretty much anything can be made pointfree. The tricky thing is what functions you'll allow in the resulting expression. If we pattern match, we generally need a fold function to do the matching instead. So, for instance, if we pattern matched on a
Maybe a
, we'd need to replace that withmaybe
. Similarly,Either a b
patterns can be written in terms ofeither
.Note the pattern in the signatures
Maybe a
has two constructors, one which takes no arguments and the other which takes ana
. Somaybe
takes two arguments: one which is a 0-ary function (b
), and one which takes ana
(a -> b
), and then returns a function fromMaybe a -> b
. The same pattern is present ineither
Two cases. The first takes an
a
and produces whateverc
we want. The second takes ab
and produces whateverc
we want. In every case, we want one function for each possible term in the sum type.In order to systematically pointfree a function like
\[x] -> x
, we'd need a similar fold.[a]
is declared as, essentiallySo we'd need a function with this signature
Now,
flip foldr
comes closeBut it's recursive. It calls its provided function on the
[a]
part ofa : [a]
. We want a true fold, which isn't provided by Haskell's base libraries. A quick Hoogle search tells us that this function does exist in a package though, calledextra
. Of course, for this small example we can just write it ourselves very easily.Now we can apply it to your
\[x] -> x
easily. First, let's write what your function really does, including all of the messyundefined
cases (I'll useundefined
rather than a long error message here, for brevity)Now every case statement exactly matches each constructor once. This is ripe for transformation into a fold.
And now we transform the outer case as well
So we have
Or, if we want to be truly crazy about it
But this function isn't in base
Yeah, that's true. We kind of cheated by using a fold that didn't exist. If we want to do it systematically, we need that fold operator. But without it, we can still kludge it together with
foldr1
, which suffices for our particular purposes.So, to answer your question, we can't always systematically replace pattern matching like in your example with pointfree, unless we have a fold function with the right signature. Fortunately, that function can always be written, for any Haskell 98 data type (possibly GADTs as well, but I haven't considered that possibility in any depth). But even without that support, we can still make it work, kind of.