Skip to main content

Curried Functions, my favourite!

I have understood the concept of "currying" for quite some time now but it wasn't until last night that I really understood how useful it (currying) can be when you want to use a standard library function but pass it something slightly different...

I was playing with reading a file using the "withFile" function,

withFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r

Thing is, the function I wanted to write, as part of its duties, needed to print the filename to the console output before doing its thing... I knew that it could be done and for once I was going to think it through and make it happen!

My function had the same type, (Handle -> IO r), but now I wanted to add in the String that would be the filename and the penny dropped... by using partial application I could "part-bake" a call to my function and leave it in such a state that it would "fit" the required type... read on...

got:  Handle -> IO r
want: String -> Handle -> IO r

Started with...

At the time of hacking, my main function was pretty simple:

main :: IO ()
main = do
    args <- getArgs
    withFile (args!!0) ReadMode myFunc

myFunc :: Handle -> IO ()
myFunc h = do ...

The first thing that I did was to add the "String" for the filename *before* the existing type like this:

myFunc :: String -> Handle -> IO ()
myFunc fname h = do
    putStrLn $ "Processing file: " ++ fname
    ...

Why before and not after ? Simple... so that after partial application with a String, the traversal of the path leaves what the "withFile" function requires: Handler -> IO r

If I had put the String at the end, the type signature of my function would have been not even wrong and the nearest you could get without changing the expected return type is:

Handle -> String -> IO r

Which means that I would have had to supply the handle first (which I don't have) and the type of the partially applied function given to "withFile" is now completely wrong!

Ended with...

After fiddling the type signature I ended up with this, which works and I understand why! Hurrah!!

module Main where

import System.Environment

main :: IO ()
main = do
    args <- getArgs
    -- note the partial application before the call to the
    -- withFile function!
    withFile (args!!0) ReadMode $ myFunc (args!!0)

myFunc :: String -> Handle -> IO ()
myFunc fname h = do
    putStrLn $ "Processing file: " ++ fname
    ...

The call to withFile is given what it wants, a filename, obtained by accessing the first command line argument ((args!!0)) and then using the $ function to String -> Handle -> IO r into Handle -> IO r.

I feel that my basic understanding of both currying and partially applied functions is going to really help my Haskell coding from now on. It's so easy once you get it... but getting there! Ah, that's the real journey...

Comments

Popular posts from this blog

PHP and Lisp: multiple-value-bind (MVB)

This is another article in my attempts to find new ways of looking at PHP and making it less of a chore to type in all that code. As much as I love PHP I hate wasting keystrokes. More typing is more errors is more grief. Being an off and on user of Lisp, although not as much as I used to, one of the things that I always liked in Lisp was the ability to be able to return multiple values from a function at once using (values) and then marry that with (multiple-value-bind) to create convenient named bindings for whatever you were about to do. I recently found myself wanting to return a couple of values from a helper function and I just didn't want to go to the trouble of having to type all those character required to create an array with keys for the two values and then I remembered MVB and a little light went on in my head! If somebody else has already done this then I apologise up front but it was new to me and I haven't seen it anywhere else so this could be a first! ...

Angular.JS ... absolutely awesome BUT...

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaagh! Sort the documentation soon please!  More soon, I really do like it though. :)

You are not here not reading this post...

Some days it's hard to really appreciate what a software developer is or does. And I have "been one" for over a quarter of a century and I still don't know what I do. I can translate management speak into meaningful English and then understand what "they need" as opposed to "what they think they need." I can translate "business requirements" into an internal mental model composed of data stores and processes and subsequently translate that model into "working code" in any language you care to mention to produce a "deliverable". But... I still don't truly understand what happened along the way. I think it is more to do with the underlying nature of the universe rather than the mechanical processes. Codds rules and normalisation for instance, one can learn, understand and apply these rules to great effect but what does "de-normalisation to 2NF" mean to a bunch of atoms and molecules which don't...