- 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

Bug in Cabal creating user package.conf
by Ashley Yakeley 30 Apr '05

30 Apr '05

I don't know if this has already been mentioned, but there's a bug in Cabal which I noticed when I tried to configure a package: $ runghc Setup.hs configure ... configure: Reading installed packages... cannot parse package list It turns out Setup created a user package.conf consisting of the two characters "[]" without a newline, which it was then unable to parse. Adding a newline fixed the problem. -- Ashley Yakeley, Seattle WA

2 2

RE: Cabal vs Haskell [sic]
by Simon Marlow 28 Apr '05

28 Apr '05

On 23 April 2005 00:21, ross(a)soi.city.ac.uk wrote: > On Fri, Apr 22, 2005 at 11:28:21PM +0100, Simon Peyton-Jones wrote: >> And this observation points towards a simpler solution: rather than >> invisibly pre-pend the package name, just get the programmer to do >> so. So package P exposes a module called P.M and package Q exposes >> Q.M. All P's internal modules are called P.something, and similarly >> for Q. (We rely on some social mechanism for allocating new package >> names, as now.) Now of course you can import P.M and Q.M in a single >> module. > > This would obscure the hierarchy a bit. A common current practice is > a variant of this: modules either have allocated names or their names > have the form > > allocated prefix + proper name + whatever you like > > e.g. Graphics.Rendering.OpenGL.GL.Texturing.Queries -- it seems to > work pretty well, and should scale, as long as the proper names are > distinct, e.g. package names or otherwise allocated. Right. Also, prepending package names to module names to avoid the overlap restriction suffers from another difficulty: versioning. You can't combine two versions of a package without including the version number in the module names of all the modules in the package. But then you end up with source code that has to be edited when the version of a package changes, which is highly undesirable. IMO, it's a good thing that package names and versions are separate from module names. It means we can (mostly) stick to the original aim of using the module hierarchy to reflect functionality, and not clutter it up with version numbers and other administravia. Cheers, Simon

8 14

RE: Help! no environment variable expansion in package files ?!?
by Simon Marlow 28 Apr '05

28 Apr '05

On 28 April 2005 15:24, Daan Leijen wrote: >> I suggest you use CPP ('gcc -E -undef -traditional -P' or 'cpphs'). >> This is what we use in GHC to get values into the package.conf files. >> e.g. in a Makefile you would write something like: >> >> > This does not work for me. For the *binary* installer for windows, > I use a batch file (.bat). The user unzips the binary files (.hi & .o) > in some location and runs "register.bat" which calls ghc-pkg with > the .pkg files. This batch file sets the current directory (= the > install directory) as an environment variable that used to be expanded > in the .pkg files. Now, I need to generate those .pkg files inside > the .bat file which seems a lot of extra work, if it works at all.. Ah, I see. I'll look into re-enabling this feature in 6.4.1. For the time being, maybe write a little Haskell program to transform .pkg files? > Another thing that causes me trouble is that I seem to need to > list all exposed modules explicitly. For me, this means that I > need to put those modules into the configure script which makes > everything much more fragile. Is there a way to use a wildcard, > ie. saying "expose everything in here"? Sorry, no. I started to implement something like that, but it turned out to be a lot harder than I thought (can't remember why, exactly). Cheers, Simon

2 1

RE: Help! no environment variable expansion in package files ?!?
by Simon Marlow 28 Apr '05

28 Apr '05

On 28 April 2005 14:37, Daan Leijen wrote: > I am trying to prepare a new release of wxHaskell based > on ghc 6.4 but I am in despair. It seems that the new > package descriptions do no longer allow environment > variables in there. For example: > > import-dirs:${wxhlibdir}/imports > > I would like the ${wxhlibdir} to be replaced by the > value in the environment. This feature is absolutely > *essential* to get the windows installer working. > I use a batch file that gets the current directory > and puts that in the environment before call ghc-pkg. > > On unix, I can use sed to make it work, but this does > not hold for windows. What can I do to allow the user > to install wxhaskell at arbitrary places using just a > batch file? (ie. we can not assume that cygwin is available) > I can hardly believe if no one has thought of this before, > so I hope it is just a syntax issue. I didn't port the feature to the new version of ghc-pkg. Sorry about that, the reasons were that (a) there are other ways to do it, and (b) the other ways are in general better, because you can substitute multiple values for a variable. I suggest you use CPP ('gcc -E -undef -traditional -P' or 'cpphs'). This is what we use in GHC to get values into the package.conf files. e.g. in a Makefile you would write something like: package.conf : package.conf.in gcc -E -undef -traditional -P -x c $< >$@ \ -DWXHLIBDIR='"$(wxhlibdir)"' (untested; I copied this mostly from GHC's build system). Another option, if you use autoconf, is to process the file using the configure script. Cheers, Simon

2 1

Help! no environment variable expansion in package files ?!?
by Daan Leijen 28 Apr '05

28 Apr '05

Hi all, I am trying to prepare a new release of wxHaskell based on ghc 6.4 but I am in despair. It seems that the new package descriptions do no longer allow environment variables in there. For example: import-dirs:${wxhlibdir}/imports I would like the ${wxhlibdir} to be replaced by the value in the environment. This feature is absolutely *essential* to get the windows installer working. I use a batch file that gets the current directory and puts that in the environment before call ghc-pkg. On unix, I can use sed to make it work, but this does not hold for windows. What can I do to allow the user to install wxhaskell at arbitrary places using just a batch file? (ie. we can not assume that cygwin is available) I can hardly believe if no one has thought of this before, so I hope it is just a syntax issue. All the best, -- Daan. ps. If someone knows a solution, please tell me soon as this is my last day the university and thus my last opportunity to build a wxHaskell release on multiple platforms.

1 0

Bug in Network.CGI
by Philippa Cowderoy 26 Apr '05

26 Apr '05

Network.CGI doesn't decode CRLFs in form data into \n. As it does text mode IO, this can lead to all sorts of fun with newlines doubling up on the browser end. -- flippa(a)flippac.org The task of the academic is not to scale great intellectual mountains, but to flatten them.

1 0