- Haskell-Cafe - Haskell.org

Here's a curve ball for Haskell.
by Daniel Carrera 03 May '05

03 May '05

Alright, in Haskell there are no side-effects when you call a function twice on the same data you get the same result... I just decided I'll try to write a good pseudo random number generator in Haskell :-) I'm off to class now, but I'll try it tonight. Cheers, Daniel.

1 0

Re: [Haskell-cafe] Speed comparison?
by Daniel Carrera 03 May '05

03 May '05

Greg Buchholz wrote: > You might find the "The Great Computer Language Shootout" > informative... > > http://shootout.alioth.debian.org/ Thanks! That's a great resource. At first glance, Haskell seems to do well over-all. Cheers, Daniel.

2 1

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

03 May '05

On 01 May 2005 19:28, Sven Panne wrote: > Gour wrote: >> Simon Marlow (simonmar(a)microsoft.com) wrote: >>> 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. >> >> Great news, thanks Simon. >> >> Nice to hear you are considering to move to darcs. > > Hmmm, > > I don't want to spoil all the enthusiasm for a new tool, especially a > Haskell-based one, but being an old CVS veteran who recently fell into > love with subversion, I'd really like to know the benefits switching > to darcs. First of all, let me say that we haven't committed to darcs in any way - we're just planning to experiment with it. Besides, it's not my decision alone - lots of people (yourself included) have code in the CVS repository, so pulling the rug out is not an option. On to darcs vs. Subversion. I too was excited by Subversion until quite recently: it does a great job of being a "better CVS than CVS", but I don't think it goes far enough. The lack of distribution and good support for merging are the two main drawbacks, as I see it (I'm aware of SVK, though I haven't tried it). Fundamentally, darcs is built on a model that is far simpler than SVN: a repository is just a set of patches, a branch is just a repository. I think having a simpler model will have benefits in terms of accessibility - I've met several people who were just not comfortable with the CVS model, and couldn't get to grips with it. Distribution is useful, as others have mentioned. Having a local copy of the repo that I can commit to before pushing patches to the main repo is a big win, as is allowing other developers to have their own local branches, and the convenience of 'darcs send' is going to make it easier for people to contribute to GHC, and for us to accept contributions. Last I checked, SVN's branching support was lacking: making a branch is easy, but merging between branches is hard, just like CVS. Sure they plan to fix this (or maybe they've already improved things), but my guess is that darcs' support for merging will always be superior because It's What Darcs Does. Good support for merging just falls out of darcs' simpler model. And I aggree with Manuel's point: we should support darcs because it's written in Haskell! Cheers, Simon

1 0

A little bit OT: Google as a global directory/resolver for cabalized packages?
by Dimitry Golubovsky 03 May '05

03 May '05

If one tries to search Google: http://www.google.com/search?hl=en&lr=&c2coff=1&q=exposed-modules+version+f… it returns URLs of all Google-indexed .cabal files (currently 7- just this few?) So if one makes such a request from a program, then parses the resulting HTML extracting <a> tags containing links ending with ".cabal", it would result in a directory of .cabal files locations suitable for furter processing. Similarly, if all locations of a particular package need to be found, package name needs to be added to the query string. Using Google API might be an alternative, but it returns only up to 10 results (per their docs) which might be enough to find all mirrors of a single package, but not the whole list of available packages. Publishing in such a directory might be simple: just place one's .cabal file in a place where Google can index it. One weakness: too easy to spam. Could this be a (cheap) way to set up package name -> URL resolution? -- Dimitry Golubovsky Anywhere on the Web

3 2

Random State Monad and Stochastics
by Dominic Steinitz 02 May '05

02 May '05

I don't think they are in the standard libraries but there was some discussion about them a few months ago but I couldn't find a reference. Peter, Can you supply one? I think you were a participant in the discussion. Did you put a library of this sort of thing together? Here's my tuppenceworth which I used to send a sequence of ip packets (as actions) and to stop when I got a destination unreachable: sequenceWhile_ :: Monad m => (a -> Bool) -> [m a] -> m () sequenceWhile_ p [] = return () sequenceWhile_ p (x:xs) = x >>= \c -> if (p c) then sequenceWhile_ p xs else return () Dominic.

2 1

RE: [Haskell-cafe] Typeclasses and instances
by Simon Peyton-Jones 02 May '05

02 May '05

I've finally gotten around to fixing this. The fix won't be in 6.4 (ever) as mentioned below, but it's done in the HEAD. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Simon Peyton-Jones | Sent: 18 March 2005 13:01 | To: Mark Carroll; haskell-cafe(a)haskell.org | Subject: RE: [Haskell-cafe] Typeclasses and instances | | Strange. This is a bug in GHC that crept in when I implemented GADTs. | It turns out to be slightly structural; fixing it will change the | interface-file format. So it won't get fixed in 6.4; but will in the | HEAD. That doesn't bother me; the context on a data/newtype decl is a | strange thing anyway; only useful for generating extra errors... but | yes, it's a bug thanks for pointing it out. | | Simon | | | -----Original Message----- | | From: haskell-cafe-bounces(a)haskell.org | [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Mark | | Carroll | | Sent: 17 March 2005 19:58 | | To: haskell-cafe(a)haskell.org | | Subject: Re: [Haskell-cafe] Typeclasses and instances | | | | Another note, with more help from friends: | | | | It turns out that GHC 6.4 will let me do, | | | | newtype Floating a => Test a = Test [a] deriving Show | | | | x = Test [False, True] | | | | but, if I change "newtype" to "data", it then says, | | | | No instance for (Floating Bool) | | | | I'm not sure I quite understand what's going on. | | | | -- Mark | | _______________________________________________ | | Haskell-Cafe mailing list | | Haskell-Cafe(a)haskell.org | | http://www.haskell.org/mailman/listinfo/haskell-cafe | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

HGL documentation
by Peter Padawitz 02 May '05

02 May '05

Is there a HGL documentation in one volume (e.g. pdf file)? Printing all pieces of http://www.haskell.org/ghc/docs/latest/html/libraries/HGL is a little tedious... Peter

1 0

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