January 2006 - Libraries

Re: Who needs Ord for Sets and Maps anyway?
by Okasaki, C. DR EECS 20 Jan '06

20 Jan '06

Adrian Hey wrote: > Well, speaking of "non-trivial comparisons" reminds me of something > that's been worrying me about this whole approach to implementing > Sets and Maps. I.E. Requiring that element/key types are instances > of Ord and assuming that lookup etc is achieved by performing some > kind of binary search. > > This seems wrong in general. [...] and > This also highlights another reason why IMO specifying "biasing" > is bad, because doing this implicitly assumes that Sets/Maps somehow > contain concrete structural representations of elements/keys. > This is not necessarily so. It's not true with any implementation > like that described above (or even simple tries). You've just highlighted why the collections hierarchy in Edison was a lattice of 8 classes. Basically, there are two choices in each of three different dimensions: 1. The set/map distinction 2. Require Ord or don't (your first point above) 3. "Observable" or not (your second point above) I think the last point is the one that caused the most confusion, but it is exactly the issue you highlight above -- some structures contain the actual elements/keys, but some (such as tries or sets based on bitmaps) don't. The non-observable parts of the hierarchy are there precisely to support implementations like tries and bitmaps where it is not easy to get your hands on the actual elements. -- Chris

11 21

RE: Idea to allow people to comment on Haskell docs
by Simon Peyton-Jones 20 Jan '06

20 Jan '06

| I guess the question is if people will actually start commenting on | functions. So I would vote for the addition to haddock and see what is | happening. Maybe we need then need to gather statistics about what links | are clicked most and check which ones of these are empty (and left the | user frustrated). That reminds me. One very useful, but probably hard-to-implement, feature would be if the "User comment" link looked different if there were actually some comments at the other end of the link. "Is it worth clicking this?" thinks the user. Kind of like Amazon, which says "Click here to see 4 user reviews" or "Write the first review". Simon

3 2

Re: Who needs Ord for Sets and Maps anyway?
by Okasaki, C. DR EECS 17 Jan '06

17 Jan '06

[My sincere apologies for the multiple posts. I forgot to include the subject line on my previous post, which makes it unclickable in the archive...] I wrote: > You've just highlighted why the collections hierarchy in Edison was a > lattice of 8 classes. Basically, there are two choices in each of > three different dimensions: > > 1. The set/map distinction > 2. Require Ord or don't (your first point above) 3. "Observable" or > not (your second point above) Oops, I typed too fast. Edison actually has two choices in each of four different dimensions. The first is the set/map distinction, but those are in two separate class hierarchies. Within each of those class hierarchies, the three dimensions are Ord/not, Observable/not, and "unique"/not, where the last dimension is the difference between sets and bags. -- Chris

1 0

Re:
by Okasaki, C. DR EECS 17 Jan '06

17 Jan '06

I wrote: > You've just highlighted why the collections hierarchy in > Edison was a lattice of 8 classes. Basically, there are > two choices in each of three different dimensions: > > 1. The set/map distinction > 2. Require Ord or don't (your first point above) > 3. "Observable" or not (your second point above) Oops, I typed too fast. Edison actually has two choices in each of four different dimensions. The first is the set/map distinction, but those are in two separate class hierarchies. Within each of those class hierarchies, the three dimensions are Ord/not, Observable/not, and "unique"/not, where the last dimension is the difference between sets and bags. -- Chris

1 0

Re: New bug tracker: Trac
by Jean-Philippe Bernardy 16 Jan '06

16 Jan '06

Hello, I'd wish to use Trac to manage my work on the libraries, though I can't find a subproject or something dedicated to the base package. Are there plans/policies regarding usage of Trac for libraries ? Cheers, JP. On 12/6/05, Simon Marlow <simonmar(a)microsoft.com> wrote: > Hi Folks, > > We've been meaning to switch bug trackers for some time, and yesterday I > finally got annoyed enough with SourceForge to do something about it. > I've imported all our SourceForge tracker data into a new Trac > installation: > > http://cvs.haskell.org/trac/ghc > > Not only do we get a faster and more flexible bug tracker, but we also > get online browsing of the darcs repository (well, for some reason it > isn't working right now, but I hope to get it fixed). Also the Trac > wiki will be a good place to put the User Guide annotations that we've > been talking about. > > The bug tracker is set up to mail glasgow-haskell-bugs(a)haskell.org with > any and all ticket modifications at the moment; if you're on that list, > there will probably be an increased volume of mail as we'll be making > more use of the bug tracker than before. My feeling is that we don't > need to create a new mailing list for this, but by all means speak up if > you disagree. > > The wiki is currently closed because I don't want to have to deal with > spam. Use HaWiki for now. > > Developers with an account on cvs.haskell.org: please add yourselves as > users on the Trac, so I can give out permissions to edit tickets. You > create a user like this: > > - log in to cvs.haskell.org > - htpasswd /srv/trac/ghc/trac.htpasswd <username> > - type your password when prompted > - let me know when you've done this > > Cheers, > Simon > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc(a)haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc >

2 1

Idea to allow people to comment on Haskell docs
by Duncan Coutts 16 Jan '06

16 Jan '06

All, People were taking recently about how to make it easier for people to contribute to the official documentation. Well here's a suggestion: We have the Haddock-generated pages link to a wiki. Each module would link to one page of a wiki. On that wiki page people could add their extended documentation, notes, example code snippets, pitfalls etc. The PHP online docs have a similar (albeit more integrated) solution where each module has user-contributed notes at the end of each page. For example here's the documentation for the PHP array module: http://www.php.net/manual/en/ref.array.php Actually having a wiki might be better than the PHP solution where they have a series of attributed contributions since with a wiki an 'editor' can re-arrange the notes to improve the organisation. The nice thing about most wikis is that if you link to a page that doesn't yet exist then it can be created. So the wiki does not even need to be prepared before the docs get pointed at it. The first person to add notes for a module will just create the corresponding wiki page. So we'd want to patch haddock to generate the links (controlled by an extra flag I guess). So I expect that there should be at least a top level link to the corresponding wiki page. How about links for each documented entity (eg functions)? That could generate links with anchors #functionName. If there were no such anchor then the browser just defaults to the top of the page which is ok. How would we put the wiki links in for each documented entity? How about a little [wiki] icon (with a suitable mouse-over descriptive text) in the right margin of the name. eg: rawSystem :: String -> [String] -> IO ExitCode [wiki] The computation ... Other suggestions? Just use a top level per-module wiki link? Duncan

4 4

Map for FGL
by Christian Maeder 16 Jan '06

16 Jan '06

Hi, I wonder how well http://www.haskell.org/ghc/docs/latest/html/libraries/fgl/Data-Graph-Induct… performs wrt. other Map implementations. It may be worth replacing this implementation, too. Cheers Christian

2 5

What's the current bug report procedure?
by Seth Kurtzberg 16 Jan '06

16 Jan '06

All, I have a (minor) but to report in the networking (Network and Network.Socket) libraries. If the /etc/protocols file is missing, an error message is printed saying that a service could not be found. This occurs even when no service is involved (the port number is specified explicitly using the constructor PortNumber). I'm aware that the procedure changed; can you point me at the right place to report this and/or the right people/bug tracker/whatever? Thanks, Seth Kurtzberg

1 0

please send your cabal bug reports, wishlist, and patches!
by Isaac Jones 16 Jan '06

16 Jan '06

Greetings, I'm trying hard to get a better hold on the Cabal[1] project, and a more clear idea of all the outstanding work that needs to be done. I've gone through my mailbox to dig up stuff like this, but no doubt some has slipped between the cracks. I started a bug tracker / wiki a few weeks ago, and would like your help to make sure that it reflects _all_ of the work that needs to be done in Cabal. If you've sent me a feature request or bug report that hasn't been added to Cabal, can you please check if it is on the wiki, and if not, create a "ticket" (bug report) for it: Cabal Wiki & Bug Tracker: http://hackage.haskell.org/trac/hackage/ If you're not sure, or don't want to use the bug tracker, just email me. This bug tracker is a great place to make more complex feature requests, as it has full wiki markup. See this ticket for a nice example: http://hackage.haskell.org/trac/hackage/ticket/27 Also, if you've sent me any patches that are not yet applied, please re-send them to me. peace, isaac [1] http://www.haskell.org/cabal

1 0

simplifying user hooks (non-backward-compatible)
by Isaac Jones 16 Jan '06

16 Jan '06

Andres Loeh proposed simplifying the hooks interface now that they've grown to include not only pre-and-post hooks, but also er, "during" hooks too. That is, all of the actions are hooks now (preConf, confHooks, postConf). http://hackage.haskell.org/cgi-bin/trac/trac.cgi/ticket/23 So we could now get rid of the pre and post hooks, as long as the user could call to the default hooks thusly: myHooks = defaultUserHooks { confHook = myConf } myConf pd cf = do myPreConf lbi <- confHook defaultUserHooks myPostConf pd cf lbi (for suitable myPreConf and myPostConf functions) This would greatly simplify the Distribution.Simple.UserHooks structure bringing it from 34 fields to 14 fields, or so. Downsides: Making pre and post hooks would now be slightly harder, and it would break existing hooks-using code. I like it. What are your feelings? peace, isaac

2 6