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. :)

Communicating between controllers in AngularJS

I have seen many solutions to how to make controllers talk to each other whilst at the same time remaining within "da rulez" of writing Angular applications. I have been using Angular for about a month now and at times it has been swearier than a good Haskell session, it is most definitely worth it all in the end. I have written a really nice looking web application for my employer and they seem to like it. I think Angular. One thing I really aced (to my own satisfaction at least) was wrapping a REST (of any type) API using a resource. I will make a separate post about that. Do the simplest thing... Here is my own solution to the problem of how you can make different controllers communicate cleanly using the "event" system that Angular provides. All you have to do is ensure that the following event listener is added to your application root-scope: App.run( function( $rootScope )) { $rootScope.$on('broadcast', function( e, data ) { if (undef...