May 2005 - Haskell-Cafe

lhs2TeX and line numbers in error messages produced by LaTeX
by Stefan Wehr (formerly Heimann) 02 May '05

02 May '05

Hi! I use lhs2TeX for typesetting literate haskell code. The problem is that LaTeX uses the line numbers from the .tex file generated by lhs2TeX and not the line number from the original .lhs file when producing error messages. Does anyone have a solution for this problem? Cheers, Stefan -- Stefan Wehr (formerly Heimann) Web: http://www.stefanwehr.de PGP: Key is available from pgp.mit.edu, ID 0B9F5CE4

2 1

RE: [Haskell-cafe] fptools in darcs now available
by Simon Marlow 02 May '05

02 May '05

On 28 April 2005 04:52, John Goerzen wrote: > I am pleased to announce that I have used tailor.py to successfully > convert the entire history of fptools HEAD branch, dating back to > 1996, from CVS to darcs. For those of you that don't know, fptools > represents the development area for the GHC Haskell compiler as well > as many other related projects. It contains 21,949 changesets. Great news, thanks John. Is it possible to set up a two-way synch so we can move over to darcs gradually? It's not really practical for us to move over in one go, we've simply accumulated too many dependencies on CVS, and there are lots of people using the repo with CVS. If we had a two-way synch, we can experiment with darcs non-destructively. Off the top of my head, a few other things we need before we can even think of switching over: - split up the full fptools repo into pieces (as we discussed on #haskell). - a web interface to the repo - commit mails to the cvs-<blah>@haskell.org lists Cheers, Simon

9 11

RE: [Haskell-cafe] fptools in darcs now available
by Simon Marlow 01 May '05

01 May '05

On 28 April 2005 16:02, John Goerzen wrote: >>> 3. Rename the smaller project's files as appropriate >>> >>> 4. Checkpoint here >> >> Won't that leave a lot of useless history in each individual project? >> When I do 'darcs get' locally to check out a few sub-repositories, >> won't I get N copies of all the old history? > > Yes, but they'll all be hardlinked together, so no matter how many > copies you get, the old history is only stored on disk once. If I do 'darcs get' to get a bunch of different repositories from cvs.haskell.org to my local filesystem, they won't all end up hard-linked together, surely? > I bet some darcs hacker could come up with a script that would even > let us remove the patches from a descended repo that don't apply > anymore. Now that sounds like a plan. > I know it's not ideal, but trying to manually convert each part of the > CVS repo, one at a time, is far, far less ideal. Not something I care > to attempt, anyway :-) I don't understand why converting each part of the repo separately is so hard? (but I've never used the tools - I'm just curious about why it's so difficult). > The other thing is that having a big repo in darcs may turn out to be > not as bad as we all thought at first. The only really annoying thing > there is how long it takes to do an initial darcs get (~5 min for me > if I use --partial). Other than that, darcs performs quite nicely. I agree with your list of pros/cons, and just to be clear, I'm not stuck on the idea of having a split repo. In fact, the simplicity of a single repo is very attractive. But what worries me is: if I just want to check out e.g. Haddock, I have to get the entire fptools repo (350M+, wasn't it?). I can build a source distribution with just the bits I want, but I can't get a darcs tree with anything but the whole lot. So, here's two potential solutions: 1. Make it possible to 'darcs get' just part of a tree. Patches that don't touch any files in the "live" parts of the tree are discarded. (I don't know if this is possible, or how difficult it is). 2. Create separate repositories for GHC, Happy, Haddock etc., and duplicate the shared fptools structure in each project. Each time we modify something in the shared part of the tree, we pull the patch into the other trees. (is it possible to cherry-pick from a tree that doesn't have a common ancestor? If not, can we make the repositories appear to have common ancestry?). Cheers, Simon

7 9

Random State Monad and Stochastics
by Lemming 01 May '05

01 May '05

When working with QuickCheck (the framework for tests with randomised input) I encountered some interesting connections between random variables in stochastics and their implementation in Haskell. I see the following correspondence between notions in programming and in mathematics: random generator ~ random variable / probabilistic experiment result of a random generator ~ outcome of a probabilistic experiment Thus the signature rx :: (Random a, RandomGen g) => State g a can be considered as "rx is a random variable". In the do-notation the line x <- rx means that "x is an outcome of rx". In a language without higher order functions and using a random generator "function" it is not possible to work with random variables it is only possible to compute with outcomes, e.g. rand()+rand(). In a language where random generators are implemented as objects computing with random variables is possible but still cumbersome. In Haskell we have both options either computing with outcomes do x <- rx y <- ry return (x+y) or computing with random variables liftM2 (+) rx ry This means that liftM like functions convert ordinary arithmetic into random variable arithmetic. But there is also some arithmetic on random variables which can not be performed on outcomes. For example, given a function that repeats an action until the result fulfills a certain property (I wonder if there is already something of this kind in the standard libraries) untilM :: Monad m => (a -> Bool) -> m a -> m a untilM p m = do x <- m if p x then return x else untilM p m we can suppress certain outcomes of an experiment. E.g. if State (randomR (-10,10)) is a uniformly distributed random variable between -10 and 10, then untilM (0/=) (State (randomR (-10,10))) is a random variable with a uniform distribution of {-10, ..., -1, 1, ..., 10}.

1 0