haskell channel

Compiling a windows application as supposed a console application from haskell

toby ho — Mon, 04 Feb 2008 11:06:54 -0500

The fact that my haskell application always runs in a command window(Windows land here) was really nagging me. I happened to be fiddling with C# express studio last night, and found out that the difference between a "console application" (one what always invokes a command window to run itself) and a "windows application" is but a compiler flag. So I thought, there must be an analogous thing in haskell, but first in gcc. I hunted down this gcc flag, and it turned out to be -mwindows. For compiling haskell using ghc, you'd use -optl-mwindows. This compiled at first, but didn't run, because it turns out that any time you try to print something to the console, it bombs out - this is the case for haskell only, for c, it just simply doesn't print anything on the screen. So I had to write a quiet version of my program that doesn't make use the putStr functions - err, actions - at all. Luckily this wasn't very hard because I had already separated out all my lib stuff that doesn't do any console IO to a separate file. Once that was done, it all worked. So now every time the scheduler runs my backup program there won't be an annoying window popping up. This is great!

Hello Haskell

toby ho — Mon, 21 Jan 2008 16:05:38 -0500

For the past four days I've been learning Haskell. As my first real program, I wrote a file backup utility - essentially a command line wrapper to rsync. The program was probably around 200 lines, just large enough for me to get comfortable with the language. There are many things I like about the language, and some that I don't, let's get started.

Safety of the Type System
After working mainly with ruby for a while it's refreshing to go back to a statically typed language. But Haskell's type system is way better than that in Java. Now, I've used OCaml before, but that was a long time ago and I had a lot of trouble with it, so I must say I didn't "get it" at that time. This is the first time I've really gotten comfortable with this kind of type system, and I love it. When you have a type system like this, you have less need for writting tests, because the compiler catches a large class of errors for you. Like in Ruby, I write tests almost religiously sometimes because I want the luxury of the safety provided by the test suite: so that I can safely refactor my code later. Well, in haskell it's like you have that safety without having to write those tests. Granted, there are still cases when you should test for logic, but you will never have your code fail due to nil-when-you-didn't-expect-it or no-such-method(with Java it's NullPointerExceptions and ClassCastExceptions). In my short experience, it's mostly true that once you get the program to compile, "It's just works!"

Type Inferencing
This works great in practice, not just in theory. All the discussions of static vs dynamic usually ignore type systems with type inference, and so are more of comparisons between old type systems and dynamic languages, and the dynamic advocates usually point out that it's easier for them to make refactorings involving changing the type of a variable. It's easier to show with an example. Let's say you have a piece of information that you need to pass to many different places in your code. At the beginning you use just a string to store it:
String filepath;
processFile(String filepath) ...
copyFile(String filepath, String filepath) ...
updateFile(String filepath) ...
processFiles(String[] filepaths) ...
Now let's say at a later time you find that a string is not enough, you need some more information to go along with each file path. you need:
FilePath filepath;
Now you are screwed. Even Eclipse can't help you with this type of refactoring. You need to make probably hundreds of changes all through out your code base, including: 1) every method/constructor declaration that references filepath; 2) every instance variable that holds a filepath; 3) every local variable that holds a filepath; 4) all the places where you create a filepath; and 5) all the places where you need to actually perform operations with filepaths. In dynamic languages, you would only have to make changes for items 4 and 5, because type information is not explicitly declared at function and variable definitions. But, this is true also for type inferencing languages like haskell. Therefore, if you are using one of these languages, the refactoring argument for dynamically typed languages is a moo point. Haskell is like the best of both worlds. What's more, the compiler guides you through the refactorings, whereas with dynamic languages, you need to rely on testing to make sure your refactoring didn't break any thing.

The Infamous IO Monad
To do any kind of IO in Haskell, you have to first grok the IO Monad. This is a scary proposition, but once you get it, you will be fine, and you'll be better for it. The way I look at it, there are 2 programming styles in Haskell: the functional style and the imperative style. The imperative style is required for any kind of IO operations, because IO operations are tainted, 'cause IO is a side effect, and functions shouldn't have side effects in the pure functional sense. To program in Haskell, you will need to be fluent in both programming styles. Now, the imperative style can be use for more than just programming IO, it's used for all monads. What's a monad, you ask? Oh brother, you'll have to ask me another day.

Runtime Errors
Now, even though with all it's safety, you can still have runtime exceptions in Haskell. But exceptions can't happen in functional code, only imperative code. So, an example would be file-not-found. Unlike the interpreted languages though, you don't get a stacktrace when you have an exception, so this is actually a minus for Haskell.

Weak Regex Support
I found the regex support a lot weaker than say perl/ruby/javascript, in fact even than python and Java. There's no syntax support for it, and the regex library in the standard distro is a bit hard to use. I was told that regex is not in the spirit of Haskell. Haskell hackers are more hip to something called Parsec. Fair enough, but I think having good regex support will help Haskell's popularity.

Third Party Libraries
In Haskell, the package system is Cabal. It's closer to Python's Eggs, I would say, but slightly lower level. Because Haskell is a compiled language at heart(although there is a bytecode mode), there are more C-isms in Cabal. Many third party libraries require compiling C code, and I've had problems with many of these on cygwin.

Interactive Shell
Give me my interactive shell or give me death! Thank god there's an interactive shell for Haskell. Again, best of both worlds. Although, the shell is limited - not like in ruby or python where you can pretty much type in any thing, in Haskell, you don't really have access to the full power of Haskell at the prompt. But still, it's a very very useful tool during rapid prototyping.

Haskell Deserves a Great IDE
It's my opinion that a compiled language nowadays really need an IDE to be pleasant to work with. If for nothing else than the ease of getting error markers inside your code editor; clicking an error to jump to its line number; and having it auto-compile when you save a file. I used the haskell plugin for Eclipse briefly, but it stopped working after the first session - some Java runtime exception =( There's no reason that Haskell can't have all the features of the cool Java IDEs out there and more, other than manpower.

Namespace Polution
Haskell is not an OO system. And as such it's more vulnerable to namespace polution, because objects act like little namespaces. This shows up in some of the standard library code for example: hGetContents, hGetLine are actions that read from a file handle. Those are not pretty names. I guess h stands for handle. In an OO system, this could have been h.GetContents. The problem of namespace collison is handled at compile time. If you imported 2 modules that both have a function called map, for example, you'd have to prefix "map" with the name of the module, like Data.List.map. But needless to say, that is not nice. You could alleviate this somewhat by passing functions around as values(ah, caught myself before I said variables).

Overall, I really dig Haskell and I plan to use it for more of my work as well as play, and I am sure I will have more to say about it as I learn more. Like, I haven't even dug into testing in Haskell, and QuickTest looks really cool.

foldr exercises

toby ho — Fri, 18 Jan 2008 10:09:45 -0500

I implemented some common ruby list operations in haskell using foldr:

import Data.Maybe
-- find f [] = Nothing
-- find f (x:xs) = if f x then Just x else find f xs
find f = foldr (\a b -> if f a then Just a else b) Nothing

-- select f [] = []
-- select f (x:xs) = (if f x then [x] else []) ++ select f xs
select f = foldr (\a b -> if f a then a:b else b) []

-- collect f [] = []
-- collect f (x:xs) = (f x) : (collect f xs)
collect f = foldr (\a b -> f a : b) []

main = do
putStrLn $ show $ find (==1) ~~(\x -> x == 1)~~ [3, 3, 5, 6, 2]
putStrLn $ show $ find (==1) ~~(\x -> x == 1)~~ [3, 3, 5, 6, 2, 1]
putStrLn $ show $ select (==1) ~~(\x -> x == 1)~~ [2,3,3,33]
putStrLn $ show $ select (==1) ~~(\x -> x == 1)~~ [2,3,3,33,1]
putStrLn $ show $ collect (*2) ~~(\x -> x * 2)~~ [1,2,3]

The commented out lines are the normal way of implementing the function while the line below is the foldr way. All 3 of these functions are already available in the the standard library Data.List as find, filter, and map respectively.

Update: made use of sections to make the code prettier.

a little haskell

toby ho — Thu, 17 Jan 2008 21:03:12 -0500

In the process of learning haskell today I found this tutorial and followed it and wrote my own version of wc. Here's the code:

import System.Environment
import Data.List
data Countable = CList [String] | CString String
count (CList s) = length s
count (CString s) = length s
main = do
[f] <- getArgs
s <- readFile f
putStr (wc s)
putStrLn (" " ++ f)
wc s= unwords (map (show . count) [CList (lines s), CList (words s), CString s])

I made use of a few haskell-ism already. The main work is in the last line, which is written in a pure functional way, while the main = do block is the imperative file IO stuff. I made use of functional composition: show . count. The length function, although works for either strings or lists, cannot in itself be used with the map function because in haskell members of a list must have the same type. This is why I also created my own datatype Countable with a count method for counting either lists of strings or the size of a string.

It's interesting that when you take a step back from this, you realize that most people coming from the imperative world would not understand what this program is doing at all.

Design Patterns Revisited: Iterators II

toby ho — Mon, 03 Dec 2007 18:15:58 -0500

I am learning Haskell afresh now, and it turns out that the iterator pattern is REALLY invisible in Haskell. This is a departure from other languages that claim to make iterators invisible like python, ruby and smalltalk, where although the syntax is minimal, you still need to understand the concept of iterators to use them. In Haskell, all expressions are lazily evaluated, so there's never even a need for the CONCEPT of iterators. Lazy evaluation of objects in lists or any collection - or any expression, for that matter - is given to you by default.