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

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

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

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! ...

Handling multipart/form-data with NanoHTTPD

I am in the process of reviving an old project from 2014 that I never finished because of other work commitments. In that time, bitrot has set in, the Android API has moved on and all in all, the home-brewed HTTP server I wrote using SocketServer and the org.apache libraries had to go! I looked around, found a couple of contenders and after much time decided to go with NanoHTTPD because it is lean, small and fits in exactly two files. The main server is in one file `NanoHTTPD.java`and there is another file called `ServerRunner.java` which manages instances of running servers. The others The other project I looked at is this one:  https://github.com/koush/AndroidAsync which led me a merry dance and I just couldn't figure out how get the POST data I had uploaded. I spent a few days really digging at it with Wire Shark too to make sure the data was going up. It was. Whatever... I had used it via a gradle dependency entry but I dropped it and went back to NanoHTTPD. For m...