May 2005 - Libraries - Haskell.org

RE: Data.Dynamic
by Simon Peyton-Jones 03 May '05

03 May '05

Here's a rather long-ago message from John Meacham that I failed to reply to. Simon M and I talked about this. While we aren’t rabidly against hashTypeRep (with an IO type), if you are going to have an IO type you might as well have typeRepId :: TypeRep -> IO Int, which gives a unique Int, distinct for each TypeRep. But beyond that, it's very inconvenient to have to do IO. One way to sidestep the determinacy issue is to provide TypeRepMap as part of the interface to TypeRep data TypeRepMap a insertTR :: TypeRepMap a -> TypeRep -> a -> TypeRepMap a union, get elts, etc etc The downside is that it needs a pretty big interface to be useful. The upside is that it can be purely functional. My suggestion would be for someone to bite the bullet, design the interface, and implement it efficiently (not difficult). Though I hate offering such a big interface, TypeReps are useful, and should be efficient, and this is a way to get that without compromising with determinacy. So a) do others agree b) any volunteers to do the legwork? Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of John | Meacham | Sent: 08 March 2005 00:05 | To: libraries(a)haskell.org | Subject: Re: Data.Dynamic | | On Mon, Mar 07, 2005 at 12:52:53PM -0000, Simon Peyton-Jones wrote: | > but typeRepIndex :: TypeRep -> IO Int | > looks stranger. It breaks the TypeRep abstraction. Would you care to argue for it? | | Mainly the reasons Geore Russell brought up a while ago, fast maps via | an compare or Hash on TypeReps are needed for various type-indexed | structures. | | http://www.haskell.org//pipermail/haskell-cafe/2004-November/007734.html | | We had no consensus on creating an Ord instance, since it could differ | between runs so was 'unsafe' in a weak sense, but adding something in IO | would be good enough for most applications and would sidestep the whole | issue :). | | Perhaps calling it hashTypeRep :: TypeRep -> IO Int and only | guarenteeing the weaker many-to-one semantics of hash functions would be | more appropriate and future-safe. | | Another alternative would be | compareTypeRep :: TypeRep -> TypeRep -> IO Ordering | but I prefer the hash version. | | I still think we should have two ordering classes, one for the natural | ordering in the prelude, and one for an efficient ordering for creating | maps or sets with the side condition that code may not depend on the | particular order it gives, just that it is a total order. But that is | another discussion :) | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

Re: Who maintains haskell-src?
by Niklas Broberg 03 May '05

03 May '05

Seems there's some trouble with your mail server, I keep getting 'delivery failure'. Hopefully mails through the list will get through. Anyway, I've now merged my repo with the changes to haskell-src in CVS. There were no merge conflicts. > I'd also like to parameterize the parser over the Extensions > type currently in Distribution.Extension (maybe it should move to > Language.Haskell.Extension) so that users could selectively enable > extensions. I agree that the parser (and the lexer too) should be parametrized over extensions. The Extensions type in Distribution.Extension looks a bit messy, but I guess that's a different issue entirely, I suppose once that's stable we'll have no problems using it. I've started adding some infrastructure to my lib for doing this parametrization, it seems to be fairly straight-forward (but tedious). I'll keep working on it. There are a few non-conservative changes introduced in haskell-src-exts, so I guess it's best to wait until all the extension parametrization is there before adding my stuff to the official cvs. /Niklas

3 2

Who maintains haskell-src?
by Niklas Broberg 03 May '05

03 May '05

The reason I ask is my haskell-src-exts (http://www.cs.chalmers.se/~d00nibro/haskell-src-exts) library that extends the haskell-src modules with support for syntactic extensions. I believe this functionality is something that most users of haskell-src are interested in, so perhaps it might be a good idea to actually add my extensions to the standard package. It won't be this very minute since there are some issues, but if I get a clearance I'll make an effort to work them out. /Niklas

3 3

package license fields
by Daan Leijen 03 May '05

03 May '05

Dear Cabal design team, I see that the license field in the package descriptions must be one of the following values: GPL, LGPL, BSD3, BSD4, PublicDomain, AllrightReserved or OtherLicense. Can (should?) we add the "WxWidgets" license? (essentially L-GPL but allows commercial use). -- Daan

2 3