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

Labels:

Comments

Post a Comment

Popular posts from this blog

The Coolest Shortest PHP Function I Will Ever Write

Having now released my own programming language, FELT , and learned a lot about this and that in the process I have of late, in the evenings, been struggling to reconcile my love of LISP and how simple FELT makes some PHP coding task leaner and meaner with the fact that I still have to use PHP for my day job. In my language, FELT , I have used the square brackets to define a "normal" array and curly braces to define a "key-value" array, mainly because this is identical to JSON format and anybody familiar with Javascript coding just won't have any issues getting to grips with that now will they! Let's take some simple examples of FELT code: (defvar simple-array [1 2 3 4]) (defvar simple-map {:name "Eric" :age 42 :occupation "Viking Hacker"}) When FELT has done its thing, we get the following PHP code, $simple_array = array(1, 2, 3, 4); $simple_map = array('name' => "Eric", 'age' => 42, ...
Post a Comment
Read more

Prime Peace

I think prime numbers are the numerical expression of peace. Restful nodes in the vibration of everything. Prime factorisation has always struck me as something truly astounding and it is reassuring to know that awsesome minds are hard at work trying to solve the Riemann hypothesis right now. There are some truly wonderful professional and amateur (in the nicest sense of the word) explorations I have watched recently and the ones that moved me the most, in order of cool factor were: This guy,Carlos Paris, has put in some serious work with AutoCAD and made some interesting observations. I truly enjoyed watching all of his four videos. Awesome work Carlos. As an interested amateur I found his work and thoughts to be very compelling. I am sure the professionals would groan or moan but to me this video is most excellent and informative. Speaking of the professionals, this video is also very interesting to watch as it goes some way to visually explaining the Riemann hypothesis in...
Post a Comment
Read more

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...
Post a Comment
Read more