When learning a new programming language, it's very important to learn the best practices arising from the community. For example, in Java you learn pretty soon to name your stuff in CamelCase: you'll make your code more readable by others and, at the same time, you're likely to avoid the mistakes others did before.
Haskell is no different and I found a good article by Bryan O’Sullivan, somewhat related to this.
October 31, 2007
October 25, 2007
Bye bye, Ubuntu
A couple of years ago, I started using a new and (at that time) unknown GNU/Linux dsitribution. It was called Ubuntu Warty 4.10. The things I liked in that distro were the hardware detection module and the fact it stemmed from Debian, which I always wanted to give a try.
Two days ago, I decided to upgrade my system (a Feisty Fawn) to the latest version, Gutsy Gibbon.
The upgrade process died at 60%, more or less, due to a problem in the nvidia-driver install script which managed to give up after seeing a diversion from the base package (ah! total functions!).
Now, I have a half-upgraded system and I can't finish the upgrade as apt-get says everything is current, and have xorg doing all sort of funny things, the Gnome applets not working anymore, mplayer segfaulting... I even filed a help request in the Ubuntu forums, like any other newbie out there, but got nothing in return: perhaps the community has become so large that a rather common help request now pass unobserved...
So, time to change. It happened in the past and is likely going to happen again in the future: I switched from Slackware to Red Hat to Slackaware to Gentoo to Ubuntu. Now it's time for ArchLinux. I've been using it for a while now, on a VMWare VM and, apart from being quite satisfied, I'm impressed as well.
pacman works like a charm: simple and effective. Everything gets configured neatly and almost everything worked out of the box.
Of course, this means that I'll have to configure my devices and xorg myself, insted of relying on some Ubuntuish automatic tool. But, at least, I'd know what's going on.
So, bye bye Ubuntu. Welcome ArchLinux.
Two days ago, I decided to upgrade my system (a Feisty Fawn) to the latest version, Gutsy Gibbon.
The upgrade process died at 60%, more or less, due to a problem in the nvidia-driver install script which managed to give up after seeing a diversion from the base package (ah! total functions!).
Now, I have a half-upgraded system and I can't finish the upgrade as apt-get says everything is current, and have xorg doing all sort of funny things, the Gnome applets not working anymore, mplayer segfaulting... I even filed a help request in the Ubuntu forums, like any other newbie out there, but got nothing in return: perhaps the community has become so large that a rather common help request now pass unobserved...
So, time to change. It happened in the past and is likely going to happen again in the future: I switched from Slackware to Red Hat to Slackaware to Gentoo to Ubuntu. Now it's time for ArchLinux. I've been using it for a while now, on a VMWare VM and, apart from being quite satisfied, I'm impressed as well.
pacman works like a charm: simple and effective. Everything gets configured neatly and almost everything worked out of the box.
Of course, this means that I'll have to configure my devices and xorg myself, insted of relying on some Ubuntuish automatic tool. But, at least, I'd know what's going on.
So, bye bye Ubuntu. Welcome ArchLinux.
October 22, 2007
Is Haskell really expressive?
My idea of an expressive program is one whose meaning (or at least the meaning of its functions when taken apart) is kind of intuitive.
Haskell is often remarkably pointed out as an expressive language. Nevertheless, I'd say that a language is simply a weapon in the hand of the developer and that expressiveness mostly depend solely on him.
Indeed, consider the following Haskell piece of code:
cartesian = (foldl (liftM2 $ flip (:)) [[]]).(map (\n -> [0..n-1]))
Apart from its name, would you tell that this function evaluates a multiple cartesian product? Actually you need to have an intermediate knowledge of Haskell and its libraries to catch the meaning of this function:
Haskell is often remarkably pointed out as an expressive language. Nevertheless, I'd say that a language is simply a weapon in the hand of the developer and that expressiveness mostly depend solely on him.
Indeed, consider the following Haskell piece of code:
cartesian = (foldl (liftM2 $ flip (:)) [[]]).(map (\n -> [0..n-1]))
Apart from its name, would you tell that this function evaluates a multiple cartesian product? Actually you need to have an intermediate knowledge of Haskell and its libraries to catch the meaning of this function:
- You should know that foldl is like a generic "summation"
- You should know that liftM2 will lift a function taking two arguments into a Monad (the List Monad actually).
- You should know that semantics of the List Monad has to do with non-determinism, i.e. passing two lists to a lifted function will result in applying that function to each and every pair built from them.
Writing programs this way is really concise but I sometimes feel like it's not really intuitive. My understanding of Haskell programs improves everyday and lots of Haskell snippets I've read in the past are now less obscure. But I think my most importat breakthrough in understanding the language will happen when I'm able to make the above snippet's meaning apparent even for the almost occasional (and non-Haskell) programmer.
Haskell concurrency
Here's an article introducing Haskell concurrency constructs for the two paradigms out there: message passing (à-la Erlang) and shared-memory (the rest of us).
October 16, 2007
Algebraic rules for GHC
As I'm still experimenting with Haskell, I'm not into Haskell code optimization yet.
Anyhow, I think the intermediate ghc user might find the following document interesting:
Playing by the rules
It sort of explains how to get advantage of the equational-like form of Haskell programs to teach ghc simple rules to optimize an Haskell program.
Anyhow, I think the intermediate ghc user might find the following document interesting:
Playing by the rules
It sort of explains how to get advantage of the equational-like form of Haskell programs to teach ghc simple rules to optimize an Haskell program.
October 15, 2007
Boilerplates
An interesting application of generic programming and data structures:
Haskell and Web Applications
Here is the documentation about Data.Generics.Basics which is useful to understand what the above article is all about.
Haskell and Web Applications
Here is the documentation about Data.Generics.Basics which is useful to understand what the above article is all about.
October 09, 2007
Control.Monad.Fix: recursive lambda abstractions
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-Fix.html
October 08, 2007
Tracing your code... the dirty way!
Problem: you want to trace your Haskell program but you're scared that touching anything might thrash your type hackery.
Solution: Use Debug.Trace.trace wherever you want to print something on the console:
Before: map f (x:xs) = (f x):(map f xs)
After: map f (x:xs) = trace "Here I am" $ (f x):(map f xs)
Explanation: I was trying to understand how HAppS worked and I really missed the possibility to put a harmless print statemente here and there in the code just to get the feeling of what was happening in the behinds, as I'd do in an imperative language like python.
The problem is that we have to deal with Haskell purity so if you want to print something in a Haskell program, you have to do it inside the IO Monad.
So far so good, but IO is not available everytime you need it... at least not the "official" one. In fact Haskell allows you to enter the IO Monad anytime you need it and perform an IO action straight away using the unsafePerformIO function.
"Unsafe" means that you use it at your own risk, since you're doing something impure in a pure environment. Of course, trace has nothing to do with the real meaning of the traced funcion, so it's perfectly safe to use it that way.
I spent almost an hour to figure out how to do this, so I hope this trick will save you time.
Solution: Use Debug.Trace.trace wherever you want to print something on the console:
Before: map f (x:xs) = (f x):(map f xs)
After: map f (x:xs) = trace "Here I am" $ (f x):(map f xs)
Explanation: I was trying to understand how HAppS worked and I really missed the possibility to put a harmless print statemente here and there in the code just to get the feeling of what was happening in the behinds, as I'd do in an imperative language like python.
The problem is that we have to deal with Haskell purity so if you want to print something in a Haskell program, you have to do it inside the IO Monad.
So far so good, but IO is not available everytime you need it... at least not the "official" one. In fact Haskell allows you to enter the IO Monad anytime you need it and perform an IO action straight away using the unsafePerformIO function.
"Unsafe" means that you use it at your own risk, since you're doing something impure in a pure environment. Of course, trace has nothing to do with the real meaning of the traced funcion, so it's perfectly safe to use it that way.
I spent almost an hour to figure out how to do this, so I hope this trick will save you time.
A new programming blog
I start this new blog for the following purposes:
- I'm learning new programming paradigms. Actually, I'm focusing on Haskell but I take a peek to other langs from time to time, like Lisp, Erlang and so on. Having a blog is a great way to get support from the community (provided I write interesting posts) and have a place to store my findings so I can look them up when needed.
- A place to post things I find on the web and worth mentioning.
- I don't know yet, but I'll add something in lazy-haskelish way as soon as I find it.
Subscribe to:
Posts (Atom)
