Re: making 6.6-candidate
Serge D. Mechveliani wrote: Dear GHC team, I am trying to make ghc-6.5.20060831 from source by ghc-6.4.1 under Linux, i386-unknown. It has got to /home/mechvel/ghc/6.4.1/inst/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -i../compat -ignore-package Cabal -funbox-strict-fields -c parser/Lexer.hs -o stage1/parser/Lexer.o -ohi stage1/parser/Lexer.hi and looped at this point during about 50 minutes, without any report. 50 minutes does seem like a rather long time... I've never seen this here. You might try adding +RTS -A16m -RTS to GhcStage1HcOpts in mk/build.mk, that should help speed up the build a bit (if you have enough memory). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: binary distribution of ghc-6.5.20060831 for i686-apple-darwin
Hiroaki Nakamura wrote: > I am a newbie to Haskell, and this is my first time to post here. > > Well, I successfully built a binary distribution of ghc-6.5.20060831 > for i686-apple-darwin. So I would like to contribute this, but is there > a place to upload this binary distribution? Please send us a link, we can upload it to the snapshot dir on haskell.org. > What I did is: > > First I built ghc-6.5.20060828 using binary distribition > http://pugs.blogs.com/dist/ghc-6.5.20060608.tar.bz2 > contributed by AudreyTang. > > Thanks to useful information on http://cvs.haskell.org/trac/ghc/wiki/X86OSXGhc > I followed the instruction about unpull and pull the "Fix Array imports" > patch. So is your build a stock 6.5.20060831, or does it lack some patches? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.6 Release Candidate
Bulat Ziganshin wrote: Hello Simon, Friday, September 1, 2006, 2:03:09 PM, you wrote: Only a week late, we are pleased to announce the Release Candidate phase for GHC 6.6. Release Notes don't mention new features added to "7.4.12. Generalised derived instances for newtypes", namely automatic deriving instances for constructor classes and MPTC also, section 7.4.7 of GHC documentation ( http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#linear-implicit-parameters ) mentions linear implicit parameters what was planned to omit from GHC 6.6 I don't remember saying that we were going to omit them... in any case they're still in. http://www.haskell.org/ghc/dist/current/docs/users_guide/ghc-language-features.html still don't mention -fparr option :) -fparr is definitely not working in 6.6, so documenting it would almost certainly be a bad idea. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: [GHC] #876: stack overflow on 'length . filter odd $ [0 .. 999999999]'
Duncan Coutts <[EMAIL PROTECTED]> wrote: > We have a reformulation of hylo fusion which we use for the > Data.ByteString library. That would cover lists too (and would make it > easy to fuse conversions String<->ByteString). > > I forget, does hylo fusion cover (++) efficiently? For our system it > works but is slower than we'd like. Well, there is a fairly straightforward RULE for (++) which essentially discovers the listy-ness of both arguments simultaneously, and deforests them together. xs ++ ys = foldr (:) ys xs RULES foldr f z (foldr (:) (foldr (:) [] s0) s1) = foldr f (foldr f z s0) s1 However this is not ideal, since it only deals well with a single (++), not a chain of them. But there is a separate set of RULES for deforesting concat/concatMap, especially as used in list comprehensions. It is relatively easy to convert a chain of (++)s to a single application of concat. I am still working on the details of the formulation of concatMap as a hylo-like structure, so no performance results yet. I hope to get it all finished and written up within a few weeks. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Data.FiniteMap
Is it too late to ask that Data.FiniteMap not die just yet? There are a number of progs/libs that this affects. It's not that people do not want to use the new Data.Map, but people are worried about having to drop support for earlier compilers. Data.Map only appeared in 6.4 iirc. So this forces packages to drop support for 5.04, 6.0 and 6.2. Perhaps 5.04 and 6.0 are not so important, but many people still use 6.2.2, particularly institutions, which tend to be slow to upgrade. I think there is a wrapper somewhere that provides the old Data.FiniteMap in terms of the Data.Map implementation. Could we use something like that in base for at least one more release? By the time of 6.8 I think people will be less concerned as 6.2 will be quite old by that time. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
I would advise against using a wrapper, because that will probably change the behaviour of FiniteMap in subtle ways (recall the left-bias stuff), laying the pavement for future headaches. Cheers, JP. On 9/4/06, Duncan Coutts <[EMAIL PROTECTED]> wrote: Is it too late to ask that Data.FiniteMap not die just yet? There are a number of progs/libs that this affects. It's not that people do not want to use the new Data.Map, but people are worried about having to drop support for earlier compilers. Data.Map only appeared in 6.4 iirc. So this forces packages to drop support for 5.04, 6.0 and 6.2. Perhaps 5.04 and 6.0 are not so important, but many people still use 6.2.2, particularly institutions, which tend to be slow to upgrade. I think there is a wrapper somewhere that provides the old Data.FiniteMap in terms of the Data.Map implementation. Could we use something like that in base for at least one more release? By the time of 6.8 I think people will be less concerned as 6.2 will be quite old by that time. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
On Mon, 2006-09-04 at 14:06 +0200, Duncan Coutts wrote: > Is it too late to ask that Data.FiniteMap not die just yet? > > There are a number of progs/libs that this affects. It's not that people > do not want to use the new Data.Map, but people are worried about having > to drop support for earlier compilers. Data.Map only appeared in 6.4 > iirc. So this forces packages to drop support for 5.04, 6.0 and 6.2. > Perhaps 5.04 and 6.0 are not so important, but many people still use > 6.2.2, particularly institutions, which tend to be slow to upgrade. Just a couple other data points: * 6.4 was never stable * 6.4.1 is not even marked stable in debian yet (only 6.2.2 is stable) * 6.4.1 was only marked stable in gentoo in March of this year (6.4.2 was marked stable in August) It's true that packages could use an external compat Data.FiniteMap but that causes problems too of course. The Cabal conditional configurations feature is not available yet. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC 6.6 Release Candidate
| > also, section 7.4.7 of GHC documentation | > ( http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions .html#linear-implicit- | parameters ) | > mentions linear implicit parameters what was planned to omit from GHC 6.6 I've now removed linear implicit parameters from the User Manual. They will probably disappear from the code base in 6.6.1. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
On Mon, Sep 04, 2006 at 02:32:34PM +0200, Duncan Coutts wrote: > > * 6.4.1 is not even marked stable in debian yet (only 6.2.2 is > stable) Debian doesn't have a concept of "marked stable". 6.4.1 didn't exist when sarge was released, so it has not yet had a chance to be included in a stable release. FWIW, I'm in favour of removing FiniteMap. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: overlapping instances in 6.6 candidate
You can see the rules here http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions .html#instance-overlap GHC 6.6's story is that an instance declaration can only be overlapped if you compile that module with -fallow-overlapping-instances. Since the list instance for Show was not compiled in this way, you can't overlap it. You may think this is annoying -- but it does mean that you can look at an instance declaration and see whether it might be overlapped, just by look at the flags for that module. Currently there is no workaround; you have to compile the instance decl that you want to overlap with the -fallow-overlapping-instances flag. It would be possible to relax this restriction, so that instances can overlapped if *either* you use -fallow-overlapping-instances when you compile the instance declaration, *or* you use that flag at the usage site. (But the exact usage site can be hard to pin down.) I'd be interested in feedback on this. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Serge D. Mechveliani | Sent: 02 September 2006 12:30 | To: glasgow-haskell-users@haskell.org | Subject: overlapping instances in 6.6 candidate | | Dear GHC developers, | | Can you, please, explain what has happened in 6.5.20060831 | with treating of overlapping instances? | | It seems to understand them differently than ghc-6.4.1. | For example, I compile the module | | | class C a where c :: a -> Bool | | instance C Int where c n = n > 0 | | instance C a => C [a] where c xs = and $ map c xs | | instance C [Int] where c xs = c $ head xs | | main = putStr (shows (c [1, (-2 :: Int)]) "\n") | | instance Show [Bool] where showsPrec _ xs = shows (head xs) | | | with the options | $dmCpOpt = | -fglasgow-exts -fallow-undecidable-instances | -fallow-overlapping-instances -fno-warn-overlapping-patterns | -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports | : | > ghc $dmCpOpt --make Main | | It reports | | | [1 of 1] Compiling Main ( Main.hs, Main.o ) | | Main.hs:11:0: | Overlapping instances for Show [Bool] | arising from use of `GHC.Show.$dmshowList' at Main.hs:11:0 | Matching instances: | instance (Show a) => Show [a] -- Defined in GHC.Show | instance [overlap ok] Show [Bool] -- Defined at Main.hs:11:0 | In the expression: GHC.Show.$dmshowList | In the definition of `showList': showList = GHC.Show.$dmshowList | In the definition for method `showList' | | | And it takes as all right the overlaps for the class C. | | [Bool] is a substitutional instance of [a], and according to the GHC | specification, the Show instance for [Bool] must override the more generic | one for Show a => [a]. | | Thank you in advance for explanation. | | - | Serge Mechveliani | [EMAIL PROTECTED] | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.FiniteMap
Duncan Coutts <[EMAIL PROTECTED]> wrote: > Is it too late to ask that Data.FiniteMap not die just yet? FWIW, I'm in favour of retaining Data.FiniteMap for ghc-6.6, to be removed only in 6.8. > There are a number of progs/libs that this affects. It's not that > people do not want to use the new Data.Map, but people are worried > about having to drop support for earlier compilers. I'll add my support to this argument. > I think there is a wrapper somewhere that provides the old > Data.FiniteMap in terms of the Data.Map implementation. Darcs patch attached, if it is of interest. Regards, Malcolm 20060904134021-6871e-359d97db8563acc3a2868666494b8f52a9c3a7f1.gz Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
instance overlap in 6.6 candidate
To my request on overlapping instances in 6.6 candidate Simon Peyton-Jones <[EMAIL PROTECTED]> writes on 4 Sep 2006 > [..] > > GHC 6.6's story is that an instance declaration can only be overlapped > if you compile that module with -fallow-overlapping-instances. Since > the list instance for Show was not compiled in this way, you can't > overlap it. > > You may think this is annoying -- but it does mean that you can look at > an instance declaration and see whether it might be overlapped, just by > look at the flags for that module. But why to restrict the user, why one needs to detect which library instance can be overlapped? Why not to allow all of them to overlap? Here is an example of how I alayws was using overlaps with standard instances. data Equation = ... instance Show Equation where ... instance Show [Equation] where showsPrec _ eqs = This gives the user possibility to redefine a certain part of the library instance. Is not ghc-6.4.1 better at this point? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: instance overlap in 6.6 candidate
| | data Equation = ... | instance Show Equation where ... | | instance Show [Equation] | where | showsPrec _ eqs = | | | This gives the user possibility to redefine a certain part of the | library instance. | Is not ghc-6.4.1 better at this point? Perhaps. That's what I'd like feedback about. What do others think? (Incidentally, 6.5 has been like this for about a year without complaints. Also I made the change because people wanted to be able to *use* overlapping instances (defined in a library) without having to give the -fallow-overlapping-instances flag.) Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance overlap in 6.6 candidate
On Mon, Sep 04, 2006 at 06:22:34PM +0400, Serge D. Mechveliani wrote: > > Here is an example of how I alayws was using overlaps with standard > instances. > > > data Equation = ... > instance Show Equation where ... > > instance Show [Equation] > where > showsPrec _ eqs = in a `nicer' way than by the default list printing > > This doesn't addrses the general issue, but in this case you can say data Equation = ... instance Show Equation where showsPrec _ eq = ... showList eqs = Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance overlap in 6.6 candidate
Simon Peyton-Jones wrote: | | data Equation = ... | instance Show Equation where ... | | instance Show [Equation] | where | showsPrec _ eqs = | | | This gives the user possibility to redefine a certain part of the | library instance. | Is not ghc-6.4.1 better at this point? Perhaps. That's what I'd like feedback about. What do others think? (Incidentally, 6.5 has been like this for about a year without complaints. Also I made the change because people wanted to be able to *use* overlapping instances (defined in a library) without having to give the -fallow-overlapping-instances flag.) Simon Could overlapping instances be broken into two flags, once with each of the desired semantics? -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance overlap in 6.6 candidate
"Simon Peyton-Jones" <[EMAIL PROTECTED]> schrieb im Newsbeitrag | | This gives the user possibility to redefine a certain part of the | library instance. | Is not ghc-6.4.1 better at this point? Perhaps. That's what I'd like feedback about. What do others think? ... Simon What are the disadvantages of compiling every library with -fallow-overlapping-instances? Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
