As you may know, I recently switched to ArchLinux... those guys are doing an excellent work and, after some months, I got completely addicted to that kdemod thing... I missed Xmonad though, which jumped from 0.2 to 0.5 in the meanwhile and I badly wanted to give it a try and test out the new features...
What to do? Well, it's indeed possible to run xmonad and kde side-by-side on the same PC. You could fire up a new Xserver on a different display but switching between them may not be fast enough.
Instead, my solution relies on Xnest, an X server running in a window of another X server.
Here's the command line I use:
kstart --desktop 2 --fullscreen -- xinit ~/.xinitrc.xmonad -- /usr/bin/Xnest :10 -geometry 1600x1200 -ac
where .xinit.xmond simply contains:
/usr/bin/xmonad
The command will open a new full-screen Xnest window, with no window decoration, on virtual desktop number 2. Now, you can use the usual shortcuts to switch between virtual desktops to go back and forth KDE and Xmonad.
Best of the two worlds!
UPDATE! Too bad, cut&paste doesn't work between Xnset and the real X server beneath. Any hints?
January 21, 2008
December 05, 2007
More on Point-Free Programming Style
I discovered that programming in Point-Free Style can be addictive! Today, I wrote two perverse functions using PFS before discovering I had spent almost two hours just two add two lines to my code!!!
Here's the one of the two:
foo = uncurry (.) . (map . second . drop . length &&& (filter . (flip $ flip isPrefixOf . snd)))
Sorry if it didn't fit in your screen. I used the name foo purposedly: can you imagine what this function does?
If you can't come up with a solution in less than 1 minute, the above code is a failure as it means nothing to you (i.e. its meaning is not apparent).
Try with the following version:
foo p [] = []
foo p ( (k,l):os ) | p `isPrefixOf` l = (k,take (length p) l) : foo p os
| otherwise = foo p os
Sorry for the bad layout.
It took two hours to me to figure out how and where to put all those . and $ in the first version but it was fun, just like winning a game.
On the other hand, I wrote the second version as I was writing this post. I think the reason why I write PFS code much much slower lies both in my lack of knowledge of PFS programming and my way of reasoning about programs.
Nevertheless, PFS is appealing to me because I'm used to write shell scripts to automate things on the systems I manage: PFS is all about composing and piping functions, mostly like you compose and pipe shell programs.
I wonder if I'll be able to guess the meaning of the PFS functions I wrote after some months: we'll see.
As a side note, I noticed that the following pattern is coming up rather often when coding in FPS:
goo = uncurry g . (foo &&& bar)
which means:
goo i = foo i `g` bar i
So, I wonder whether the following combinator would help to making FPS code more readable:
f `interspersedBy` g = uncurry g . f
So, the above snippet would become:
goo = (foo &&& bar) `interspersedBy` g
Here's the one of the two:
foo = uncurry (.) . (map . second . drop . length &&& (filter . (flip $ flip isPrefixOf . snd)))
Sorry if it didn't fit in your screen. I used the name foo purposedly: can you imagine what this function does?
If you can't come up with a solution in less than 1 minute, the above code is a failure as it means nothing to you (i.e. its meaning is not apparent).
Try with the following version:
foo p [] = []
foo p ( (k,l):os ) | p `isPrefixOf` l = (k,take (length p) l) : foo p os
| otherwise = foo p os
Sorry for the bad layout.
It took two hours to me to figure out how and where to put all those . and $ in the first version but it was fun, just like winning a game.
On the other hand, I wrote the second version as I was writing this post. I think the reason why I write PFS code much much slower lies both in my lack of knowledge of PFS programming and my way of reasoning about programs.
Nevertheless, PFS is appealing to me because I'm used to write shell scripts to automate things on the systems I manage: PFS is all about composing and piping functions, mostly like you compose and pipe shell programs.
I wonder if I'll be able to guess the meaning of the PFS functions I wrote after some months: we'll see.
As a side note, I noticed that the following pattern is coming up rather often when coding in FPS:
goo = uncurry g . (foo &&& bar)
which means:
goo i = foo i `g` bar i
So, I wonder whether the following combinator would help to making FPS code more readable:
f `interspersedBy` g = uncurry g . f
So, the above snippet would become:
goo = (foo &&& bar) `interspersedBy` g
December 04, 2007
Arrows first encounter
UPDATE: My post appeared on Reddit's programming feed. Thank you! Also, my post's title should've been "Point-free programming style first encounter", but I'm too lazy to change it ^_^
I was really busy lately so no post around for a while. Surprisingly, I wasn't busy wrinting code but actually thinking about the problem: this is feasible in Haskell as the code is more concise and the typing system keeps you from doing stupid design mistakes (or at least make them appear earlier than in other programming language).
Now, done with the ritual Haskell-awe prologue, here my post for today.
Lately, I've been working to a program manipulating objects which turned out to be monomials, which I represented as a pair of (Double,[Int]), i.e.:
(4.0,[1,2,-1,-2]) -> 4.0 x(1,1) x(2,2) x(3,-1) x(4,-2)
where x(i,j) are unknowns indexed by a pair. Since I assume that the first component of the unknowns' pairs will be the sequence 1,2,3,... I only need to specify the second component. I know, it's kinda weird, but it has to do with my domain problem which is related to finite difference operators for PDE.
Now I want to define a "product" operator which works like this:
(k,[b,c,d]) * (h,[e,f,g]) = (k*h,[a+e, c+f, d+g])
I can define this like follows:
prod (k,ll) (h,rl) = (k*h, zipWith (+) ll rl)
This is perfectly correct and good as it's very expressive.
Now, I want to apply the same function monadically to list arguments, i.e.:
prod :: [(Double,[Int])] -> [(Double,[(Double,[Int])] -> [(Double,[Int])]
To do this, I'll use liftM2 which take a function of two arguments and applies it to every pair formed taking an element from the first list and an element from the second. So:
prodM = liftM2 prod
But I'll never use prod by itself, so let's put this in a lambda abstraction and rename prodM to prod:
prod = liftM2 $ \(k,ll) (h,rl) -> (k*h, zipWith (+) ll rl)
Again, this is correct but my Haskell soul is becoming more strict and such a formulation sounds bad to me (I could've felt perfectly right with some month ago). I don't like lambdas when used this way, I see as an intrusive element in the perfect world of function combinators/operators (and liftM2 is such a combinator). More, I had to specify that prod requires two tuples while it'd be neat if the compiler could infere this automatically: I see this as code replication issue.
The solution to this dilemma is using point-free style programming. I'll abuse arrow combinators a bit. Specifically, there's the (***) operator which takes two function f and g and applies them to a tuple:
(f *** g) (a,b) = (f a, g b)
What if I need to combine two tuples using two separate binary operators? I.e.:
(f ***' g) (a,b) (c,d) = (f a c, g b d)
Arrows module doesn't provides such a combinator but we could build one. First, if we combine f and g using (***), we get a pair of two functions as f and g are partially evaluated. What we need now is to interpose (***) between these two functions. How to do this? Simple, we just need to uncurry (***). So, now:
(f ***' g) = uncurry (***) . (f *** g)
and we're done as f ***' g returns a function taking two tuples and apply f and g separately to each component. This is good as we can rewrite prod as:
prod = liftM2 $ uncurry (***) . ((*) *** (zipWith (+)))
which is essentially a smart combination of functions. Notice that no arguments of prod has been specified: this is where point-free programming style really lies. Changing the way prod is written will change the type of its arguments, in single place, without requiring you to rewrite them in two places (i.e. the argument list).
I was really busy lately so no post around for a while. Surprisingly, I wasn't busy wrinting code but actually thinking about the problem: this is feasible in Haskell as the code is more concise and the typing system keeps you from doing stupid design mistakes (or at least make them appear earlier than in other programming language).
Now, done with the ritual Haskell-awe prologue, here my post for today.
Lately, I've been working to a program manipulating objects which turned out to be monomials, which I represented as a pair of (Double,[Int]), i.e.:
(4.0,[1,2,-1,-2]) -> 4.0 x(1,1) x(2,2) x(3,-1) x(4,-2)
where x(i,j) are unknowns indexed by a pair. Since I assume that the first component of the unknowns' pairs will be the sequence 1,2,3,... I only need to specify the second component. I know, it's kinda weird, but it has to do with my domain problem which is related to finite difference operators for PDE.
Now I want to define a "product" operator which works like this:
(k,[b,c,d]) * (h,[e,f,g]) = (k*h,[a+e, c+f, d+g])
I can define this like follows:
prod (k,ll) (h,rl) = (k*h, zipWith (+) ll rl)
This is perfectly correct and good as it's very expressive.
Now, I want to apply the same function monadically to list arguments, i.e.:
prod :: [(Double,[Int])] -> [(Double,[(Double,[Int])] -> [(Double,[Int])]
To do this, I'll use liftM2 which take a function of two arguments and applies it to every pair formed taking an element from the first list and an element from the second. So:
prodM = liftM2 prod
But I'll never use prod by itself, so let's put this in a lambda abstraction and rename prodM to prod:
prod = liftM2 $ \(k,ll) (h,rl) -> (k*h, zipWith (+) ll rl)
Again, this is correct but my Haskell soul is becoming more strict and such a formulation sounds bad to me (I could've felt perfectly right with some month ago). I don't like lambdas when used this way, I see as an intrusive element in the perfect world of function combinators/operators (and liftM2 is such a combinator). More, I had to specify that prod requires two tuples while it'd be neat if the compiler could infere this automatically: I see this as code replication issue.
The solution to this dilemma is using point-free style programming. I'll abuse arrow combinators a bit. Specifically, there's the (***) operator which takes two function f and g and applies them to a tuple:
(f *** g) (a,b) = (f a, g b)
What if I need to combine two tuples using two separate binary operators? I.e.:
(f ***' g) (a,b) (c,d) = (f a c, g b d)
Arrows module doesn't provides such a combinator but we could build one. First, if we combine f and g using (***), we get a pair of two functions as f and g are partially evaluated. What we need now is to interpose (***) between these two functions. How to do this? Simple, we just need to uncurry (***). So, now:
(f ***' g) = uncurry (***) . (f *** g)
and we're done as f ***' g returns a function taking two tuples and apply f and g separately to each component. This is good as we can rewrite prod as:
prod = liftM2 $ uncurry (***) . ((*) *** (zipWith (+)))
which is essentially a smart combination of functions. Notice that no arguments of prod has been specified: this is where point-free programming style really lies. Changing the way prod is written will change the type of its arguments, in single place, without requiring you to rewrite them in two places (i.e. the argument list).
November 14, 2007
Random numbers (where it all started)
At first, Haskell seemed a reasonable language... until Monads appeared! Until then, purity was a clear plus of Haskell but... what about a random number generator (RNG)?
A pure function is deterministic: it depends only on its inputs and, as computers are deterministic as well, its output must be the same given the same input data.
Conversely, an RNG function (at least as it's known in the imperative world) must be non-deterministic and return a different outcome whenever it's called (without arguments).
So, how to code an RNG function in Haskell? Enter Monads.
Haskell can't give up on purity, so the solution is simple: instead of returning a value, an RNG function returns a computation.
A computation is like a machine with some pipes going in. By itself, the machine doesn't do anything. But, if you run it, providing fuel through the pipes, it will eventually produce something.
The machine is pure, while the fuel is impurity (or side-effects). The fuel comes from the environment under which the machine is run.
So, an RNG function is actually a machine which, when run under the special enviroment of the IO Monad, provides a number. More, you can build a special RNG machine (i.e. write an RNG computation) producing an infinite list of random numbers: just fill in sufficient fuel until more random numbers are needed!
In this way, Haskell let's you stay on the pure side when building the computation, letting you do all sort of things a computer theorist would do to a program (applying transformations, proving properties...), and getting you dirty when running your computation.
Sometimes it's hard to catch up with the meaning of Monads at first because the first Monad you encounter is the IO Monad, which is implicitly run by the Haskell run-time environment. So, you lose the concept that a Monad computation must be run to produce something useful.
For instance, the State Monad has runState function. But, as I said in one of my previous post, IO has its own run function: unsafePerformIO, from Foreign module.
So, let's see how to build an RNG computation:
randomList r = do g <- getStdGen
return $ randomRs r g
randomList takes a pair representing a range of numbers and return a computation that, when run, provides an infinite list of numbers. Indeed, randomList's type is:
Num a => (a,a) -> IO [a]
Specifically, when you state:
g <- getStdGen
you are saying something like: "g is a pipe. When you run this computation, please provide a StdGen value here". randomRs is a plain pure function taking a StdGen (which is basically a seed with a next function iterated to provide an infinite list of random number from it) and the range to which random numbers must be belong to.
How do we run this machine? Simple: put unsafePerformIO in front of it.
randomList r = unsafePerformIO $
do g <- getStdGen
return $ randomRs r g
Now randomList produces an infinite list of random numbers because it'll run the computation inside it.
But, beware! randomList is now and impure function masked as a pure function. Haskell could tricked by this masking and make the wrong thing misled by the purity assumption.
So, I promised myself not to write another Monad tutorial, but I did, at last!
A pure function is deterministic: it depends only on its inputs and, as computers are deterministic as well, its output must be the same given the same input data.
Conversely, an RNG function (at least as it's known in the imperative world) must be non-deterministic and return a different outcome whenever it's called (without arguments).
So, how to code an RNG function in Haskell? Enter Monads.
Haskell can't give up on purity, so the solution is simple: instead of returning a value, an RNG function returns a computation.
A computation is like a machine with some pipes going in. By itself, the machine doesn't do anything. But, if you run it, providing fuel through the pipes, it will eventually produce something.
The machine is pure, while the fuel is impurity (or side-effects). The fuel comes from the environment under which the machine is run.
So, an RNG function is actually a machine which, when run under the special enviroment of the IO Monad, provides a number. More, you can build a special RNG machine (i.e. write an RNG computation) producing an infinite list of random numbers: just fill in sufficient fuel until more random numbers are needed!
In this way, Haskell let's you stay on the pure side when building the computation, letting you do all sort of things a computer theorist would do to a program (applying transformations, proving properties...), and getting you dirty when running your computation.
Sometimes it's hard to catch up with the meaning of Monads at first because the first Monad you encounter is the IO Monad, which is implicitly run by the Haskell run-time environment. So, you lose the concept that a Monad computation must be run to produce something useful.
For instance, the State Monad has runState function. But, as I said in one of my previous post, IO has its own run function: unsafePerformIO, from Foreign module.
So, let's see how to build an RNG computation:
randomList r = do g <- getStdGen
return $ randomRs r g
randomList takes a pair representing a range of numbers and return a computation that, when run, provides an infinite list of numbers. Indeed, randomList's type is:
Num a => (a,a) -> IO [a]
Specifically, when you state:
g <- getStdGen
you are saying something like: "g is a pipe. When you run this computation, please provide a StdGen value here". randomRs is a plain pure function taking a StdGen (which is basically a seed with a next function iterated to provide an infinite list of random number from it) and the range to which random numbers must be belong to.
How do we run this machine? Simple: put unsafePerformIO in front of it.
randomList r = unsafePerformIO $
do g <- getStdGen
return $ randomRs r g
Now randomList produces an infinite list of random numbers because it'll run the computation inside it.
But, beware! randomList is now and impure function masked as a pure function. Haskell could tricked by this masking and make the wrong thing misled by the purity assumption.
So, I promised myself not to write another Monad tutorial, but I did, at last!
November 07, 2007
Again a post about Haskell performances
I've found an interesting article describing how to make an Haskell program run as fast as the OCaml version, which is often regarded as the workhorse among FP languages. Three points grabbed my attention the most:
- ghc 6.8 seems to boost the performances of Haskell programs: in some cases the benchmarks show programs run twice as faster as those compiled with ghc 6.6.
- Faster Haskell programs are written similarly to OCaml version.
- OCamls versions are no longer than their Haskell versions.
November 05, 2007
"Making Haskell programs faster and smaller"
November 02, 2007
Subscribe to:
Posts (Atom)
