In my trip through Haskell programming I keep discovering how clean and enjoyable the language is. By the end I am someone that loves doing abstractions and I guess I’ve found my world.
I discussed with some colleagues lately how a programming language creates a whole culture around it. This culture inherits from language properties and shapes the language programming style.
Take for example Java; there are a lot of different ways to program in java. The java syntax does not force you to program OOP. It is just more convenient to do so. Same thing goes with other programming languages. However it is not only about paradigm, it is really about a whole mindset.
While programming a web site with Haskell, I was searching for a function that parses a string to return me an int. As I’ve been for a long time a C#/Java programmer I expected to find a simple function like what I used to use in these language. A function that simply takes a string and produces and int. After a fair search I didn’t find such a “simple” function. I’ve rather found a function with slightly more complicated/richer signature (type). This function takes a string and returns a list of int-string pairs. This got me thinking, there should be a reason for not offering the simple function I was searching for…
I quickly started understanding why libraries implementers chose to offer this function with this signature and I did so simply by imagining its use. Imagine that I pass a string that is not the expected type (in our case int) to this reads (stands for read string) function, what would happen? Well in the simple version of C# and Java, the parsing function well throw an exception when passed a string that can not be parsed. In some way, the signature of the function promises me to get always the expected type (in our case an int) as a return of using it but it actually lies! Throwing an unexpected exception comes as a surprise as the signature (the function type) looked extremely kind but behaved irresponsibly unexpectedly when I trusted it. But what about the Haskell version?
Well the type of the Haskell function tells me “I will try to parse the string passed, and each time I find a fit with your expected type I will return a pair with the value in the expected type and a remaining string that represents what remains”. So here the function type tells me that it will try to parse and that it will might face several possibilities. There is no lie here, no magic, no false promise, parsing strings can produce several possibilities depending on the parsing method, and that what the function tells me.
I like the no surprise / safe programming culture in Haskell. I guess there are a lot of lessons to be learnt from this style of programming.
PS: Some might call this safe style “defensive programming” to make it look rigid, I guess there is no point in calling it so, and I would rather call it communicative programming, no surprise programming, or intention revealing programming. I like DbC!
You have a point, but it’s not the best example.
The following function is a “simple” string->int conversion (actually, not just int).
read :: (Read a) => String -> a
Comment by Sebastian — November 2, 2008 @ 11:03 pm
The function you’re looking for is called ‘read’. It has type String -> a and is overloaded on the return type. Works for ints, floats, lists etc.
Comment by Jam — November 2, 2008 @ 11:51 pm
But read has exactly the problem discussed here: it will throw an exception if the parser fails.
Try read “twenty”::Int
Comment by Fran — November 4, 2008 @ 8:44 pm
@Fran
I was referring to reads that “Normally, [] [it] returns a singleton list, containing a value of type a that was read from the input string and the remaining string that follows what was parsed. If no parse was possible, however, the result is the empty list, and if there is more than one possible parse (an ambiguity), the resulting list contains more than one pair.
Of course we can have other non safe functions, but that is the idea, it is more about a culture of usage than an impossibility to be done.
Comment by Sadache — November 6, 2008 @ 5:32 pm