- Glasgow-haskell-users

web site layout
by Ross Paterson 10 Mar '05

10 Mar '05

There's currently no way to give a permanent URL for the best available version of the 6.4 documentation, i.e. the latest minor release. How about either a symlink 6.4-latest, or renaming the directory 6.4 as 6.4.0 and making 6.4 a symlink to the latest? Same goes for dist, I suppose.

2 1

GHC 6.4 Release Candidate Binary for Mac OS X
by Wolfgang Thaller 10 Mar '05

10 Mar '05

I've uploaded a Mac OS X installer based on the stable tree from March 2nd + the patches I committed yesterday at: http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050302.pkg.zip This package is built with support for dynamic libraries (some human intervention was required to build it). Mac users, please start testing and send lots of feedback to me and to the list. Cheers, Wolfgang

5 9

RE: Restricted Types and Infinite Loops
by Simon Peyton-Jones 10 Mar '05

10 Mar '05

Simon: as I mentioned yesterday, I think I've fixed your infinite-loop problem. If you can build GHC from source, or use last night's snapshot build, you could see if you agree that it's fixed. Simon | -----Original Message----- | From: Simon David Foster [mailto:s.d.f@btinternet.com] | Sent: 18 February 2005 09:36 | To: Ralf Laemmel | Cc: GHC Users; Simon Peyton-Jones | Subject: Re: Restricted Types and Infinite Loops | | On Fri, 2005-02-18 at 02:18 +0100, Ralf Laemmel wrote: | | > Here I assume that you don't _really_ depend on ClassB to be a | > superclass of ClassA. (Why would you?) | | Ok, here's what the real class head is (or was before I butchered it to | make it work); | | class (Data (DictXMLData h) a, XMLNamespace a) => XMLData h a where | | We want to do this so that it is unnecessary to store XML Namespaces in | the XMLData instances (which is supposed to be for only encoding). There | are two reasons why this is necessary; | | * 1 - We have another class XSDType a, which gives types an XSD Type. | This also depends on the types having a namespace. If we don't have this | class dependency, we end up with repeated data. | * 2 - In various contexts, you will require a different namespace for a | particular element, but the same encoder. For example, when creating a | SOAP Envelope, the "int" data-type could have the SOAP Encoding | namespace or it could have the XSD Namespace. Further it may not have a | namespace at all, in which case the default instance (XMLNamespace a) | will take over. By taking the dependency out you bind a particular | namespace to an encoder. | | For now, the various encoders for XSD data-types are in the XSD Module, | this means that any user that wants to encode an int or string must | import the XSD module, since we can't centralise the encoder. | | > This is a simpler recursion scheme in terrms of class/instance constraints. | | Maybe, but sadly it doesn't achieve my goal. I could do Namespaces via a | hook, but that makes the construction and encoding of namespace tables | almost impossible. | | Thanks, | | -Si. | | -- | Simon David Foster <s.d.f(a)btinternet.com>

1 0

RE: infix type operators
by Simon Peyton-Jones 09 Mar '05

09 Mar '05

OK, it's done for 6.4 SImon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 08 March 2005 16:29 | To: glasgow-haskell-users(a)haskell.org | Subject: infix type operators | | The User's Guide says: | | The only thing that differs between operators in types and | operators in expressions is that ordinary non-constructor | operators, such as + and * are not allowed in types. Reason: | the uniform thing to do would be to make them type variables, | but that's not very useful. A less uniform but more useful thing | would be to allow them to be type constructors. But that gives | trouble in export lists. So for now we just exclude them. | | Conal has pointed out that the uniform thing would be useful for | general arrow combinators: | | liftA2 :: Arrow (~>) => | (a -> b -> c) -> (e ~> a) -> (e ~> b) -> (e ~> c) | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 3

RE: environment variables for ghc
by Simon Marlow 09 Mar '05

09 Mar '05

On 09 March 2005 21:13, Frederik Eaton wrote: >>> I agree that the case you're presenting is indeed more difficult, >>> but I don't think you're doing the estimations right for the one at >>> hand. The cost and annoyance of perhaps tens of thousands of people >>> adding and remembering to maintain wrappers named 'ghc' somewhere >>> in their path to accomplish this simple task (after scrounging in >>> the documentation to find that ghc for some reason fails to be like >>> many other compilers, a nontrivial cost in itself since the lack of >>> environment variables isn't specifically documented) - or simply not >>> doing so, and typing in -package-conf hundreds of times as I have >>> done, because they may not have write access to the main >>> package.conf - I think outweighs the cost of one person, once, >>> adding central support for environment variables, a bit of >>> documentation in the man page, perhaps a ghcbug program if we want >>> super-detailed bug reports... >> >> Are you volunteering to be that person? ;-) > > Are you saying that a patch would be accepted? > > Frederik We'll definitely take the environment variable patch if it comes with a ghcbug script :-) Cheers, Simon

3 2

RE: environment variables for ghc
by Simon Marlow 09 Mar '05

09 Mar '05

On 09 March 2005 19:55, Frederik Eaton wrote: > I agree that the case you're presenting is indeed more difficult, but > I don't think you're doing the estimations right for the one at hand. > The cost and annoyance of perhaps tens of thousands of people adding > and remembering to maintain wrappers named 'ghc' somewhere in their > path to accomplish this simple task (after scrounging in the > documentation to find that ghc for some reason fails to be like many > other compilers, a nontrivial cost in itself since the lack of > environment variables isn't specifically documented) - or simply not > doing so, and typing in -package-conf hundreds of times as I have > done, because they may not have write access to the main package.conf > - I think outweighs the cost of one person, once, adding central > support for environment variables, a bit of documentation in the man > page, perhaps a ghcbug program if we want super-detailed bug > reports... By the way, GHC 6.4 keeps a local package.conf in your home directory, and you can install packages into it with ghc-pkg --user, or ./setup --user for Cabal packages. Cheers, Simon

1 0

RE: environment variables for ghc
by Simon Marlow 09 Mar '05

09 Mar '05

On 09 March 2005 08:29, Frederik Eaton wrote: > Is it possible to set environment variables which ghc will look at, > corresponding to command line options such as '-i' or '-package-conf'? > I.e. the equivalent of gcc's LIBRARY_PATH, CPATH, etc... or perl's > PERL5LIB or even PERL5OPT (which is the most flexible). These would be > really convenient since I have a package.conf file in my home > directory for locally installed packages, and some modules in another > directory that I often link to. There's the GHCRTS environment variable that you can use for setting heap sizes and so on, and the ~/.ghci file, but nothing for setting ghc command-line arguments. We're a bit wary of adding more things that we have to ask for in a bug report... Cheers, Simon

4 9

RE: Registerised x86_64 port: test version available
by Simon Marlow 09 Mar '05

09 Mar '05

On 09 March 2005 10:14, Ralf Hinze wrote: > this is just to let you know that I successfully compiled the lastest > snapshot (ghc-6.4.20050308). Initial tests look promising. Thanks! > > Cheers, Ralf > > PS: Just curious: is the gcc route easier than the NCG? To me it seems > much more fragile. It's initially easier to get going, but yes it's more fragile. Currently we can't go it alone with the NCG because the NCG isn't quite capable of compiling the hand-written .cmm files in the runtime. At some point we'll fix this. Cheers, Simon

1 0

Registerised x86_64 port: test version available
by Simon Marlow 09 Mar '05

09 Mar '05

I've put up an x86_64/Linux registerised build for testing here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4-x86_64-unknown-linux .tar.bz2 This is a binary distribution: ./configure && make -k install. The -k is necessary because it doesn't have all the docs. It was built on Fedora FC3. Note it claims version 6.4, but actually it's 6.4.20050308. Still no GHCi, no foreign export dynamic, no native code gen. But it seems to work (this is a stage 3 build). Enjoy! Simon

4 3

RE: infix type operators
by Simon Peyton-Jones 09 Mar '05

09 Mar '05

Yes, that makes sense. I think I will do that. Whether it'll make it into 6.4 is doubtful S | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 08 March 2005 16:29 | To: glasgow-haskell-users(a)haskell.org | Subject: infix type operators | | The User's Guide says: | | The only thing that differs between operators in types and | operators in expressions is that ordinary non-constructor | operators, such as + and * are not allowed in types. Reason: | the uniform thing to do would be to make them type variables, | but that's not very useful. A less uniform but more useful thing | would be to allow them to be type constructors. But that gives | trouble in export lists. So for now we just exclude them. | | Conal has pointed out that the uniform thing would be useful for | general arrow combinators: | | liftA2 :: Arrow (~>) => | (a -> b -> c) -> (e ~> a) -> (e ~> b) -> (e ~> c) | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0