RE: instance overlap in 6.6 candidate
| What are the disadvantages of compiling every library | with -fallow-overlapping-instances? It's not H98, so it has to be an option, enabled by a flag. Of course you are free to put the flag at the top of every module. Sergey's point is that the libraries are pre-compiled, so you can't add flags to them. The old model was that every instance is potentially overlappable; and you only need the flag when you *use* the instances. But people complained that the clients of their library should not need to know import Foogle and use -fallow-overlapping-instances. 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 03:39:06PM +0100, Simon Peyton-Jones wrote: | | data Equation = ... | instance Show Equation where ... | | instance Show [Equation] | where | showsPrec _ eqs = certain program which prints a list of equation | in a `nicer' way than by the default list printing | | | | 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. Let me exlain a bit more the reason. show [1, 2, 3] = [1,2,3] -- all right, let it be. Now, for the list eqs :: [Equation], the GHC instance prints it, for example, as --- [[21] n+0 = 0 (Parents [[1],[2]]),[22] n+(s n) = s (n+m) (Parents [[33], [44]]),[23] n*0 = 0 (Parents [[],[]])] --- And I would like it to be at least [[21] n+0 = 0 (Parents [[1],[2]]), [22] n+(s n) = s (n+m) (Parents [[33],[44]]), [23] n*0 = 0 (Parents [[],[]]) ], which is easier to read. I decided that to overlap with the ghc instance is the simplest and best solution. I thank Ian Lynagh [EMAIL PROTECTED] who suggests L instance Show Equation where LshowsPrec _ eq = ... LshowList eqs = certain program which ... Indeed. I even wrote a showsList function, without knowing of the showsList class method! But as Ian writes, L This doesn't address the general issue So far, I tried this overlap only for Show List and Show Pair, but probably, users and myself would like to partially redefine some other library instances. Simon Peyton-Jones writes (Incidentally, 6.5 has been like this for about a year without complaints. I am sorry for this, I am slower than GHC. I have been with 6.4.1 last 1-2 years, and ignored the further version matters. Finally, a week ago decided to look into what is coming with 6.6. 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.) The difference for me is to have a little bit less-or-more comfort. DoCon-2.09 has ported from 6.4.1 to 6.6-candidate only by removing the `data' name from `dependencies', and it looks like working all right. In Dumatel-1.06, it reports the error of this library overlap for `Show'. For exampl, I can define the showsList method, as Ian suggests. Generally, I suspect that ghc-6.4.1 is better at this point of library overlaps, but I am not sure. Anyway, the GHC developers have now more of feedback, they know better and can decide. Thanks, - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
instance overaps with lib
More about instance overlaps with the GHC library: I need to print in a special way the data of [Equation], (Term, Term), [(Term, Term)], (Equation, Equation). The first can be by defining showList in instance Show Equation. But Show has not a method of showPair. So, I need to write the function showsTermPair and to use it together with another home-made function showsListGeneric. And in ghc-6.4.1, it was sufficient to define the instances and to use only `shows'. About prompt feed-backs from users: this issue of possible fisfeature with overlaps does not look tragic. But with the Map library for Haskell-98, I take it as a considerable loss. It was said that I had a chance to make it standard, if asked about it in time. - 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 overaps with lib
On Tue, Sep 05, 2006 at 12:50:39PM +0400, Serge D. Mechveliani wrote: More about instance overlaps with the GHC library: I need to print in a special way the data of [Equation], (Term, Term), [(Term, Term)], (Equation, Equation). The first can be by defining showList in instance Show Equation. But Show has not a method of showPair. So, I need to write the function showsTermPair and to use it together with another home-made function showsListGeneric. You seem to be using special instances to do two things: add spacing and remove extraneous parentheses. A neater way to do the latter would be to use the precedence parameter of showsPrec for Term to control whether the parentheses are added in the first place, e.g. (untested) showsPrec p t = (case t of VarT v - shows v App f [] [] - showString (name f) App f [] [r] - showParen (p app_prec) $ showString (name f) . showChar ' ' . showsPrec (app_prec+1) r ... where app_prec = 10 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries
HaXml (no longer builds) In what way does HaXml fail to build for Hugs? Is it easily fixable? ... and there's the famous Data.FiniteMap. So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries
On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote: HaXml (no longer builds) In what way does HaXml fail to build for Hugs? Is it easily fixable? ... and there's the famous Data.FiniteMap. So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? I'd rather see HaXml updated to use Data.Map, perhaps with a compatibility layer for older GHCs. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance overaps with lib
On Tue, Sep 05, 2006 at 12:11:20PM +0100, Ross Paterson wrote: [..] You seem to be using special instances to do two things: add spacing and remove extraneous parentheses. A neater way to do the latter would be to use the precedence parameter of showsPrec for Term to control whether the parentheses are added in the first place, e.g. (untested) showsPrec p t = (case t of VarT v - shows v App f [] [] - showString (name f) App f [] [r] - showParen (p app_prec) $ showString (name f) . showChar ' ' . showsPrec (app_prec+1) r ... where app_prec = 10 Thank you very much. I have to study this. Because I always defined Show via showsPrec, and also was always missing of what is the first argument of showsPrec. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries
On Tue, 2006-09-05 at 12:12 +0100, Malcolm Wallace wrote: HaXml (no longer builds) In what way does HaXml fail to build for Hugs? Is it easily fixable? ... and there's the famous Data.FiniteMap. So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? I certainly would not object. It should still be marked deprecated of course, producing suitable warnings. As I said before, I'm happy for it to die by the time of GHC 6.8. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries
On Tue, 2006-09-05 at 12:19 +0100, Ross Paterson wrote: On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote: HaXml (no longer builds) In what way does HaXml fail to build for Hugs? Is it easily fixable? ... and there's the famous Data.FiniteMap. So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? I'd rather see HaXml updated to use Data.Map, perhaps with a compatibility layer for older GHCs. Using a compatibility layer is not that easy at the moment. There is a feature which will likely go into some upcoming version of Cabal that will make it easier to depend on different packages (eg a compat-finitemap) depending on what packages versions we are building against. For example you'd put something like the following in the .cabal file: configuration: package(base = 2.0) build-depends: compat-finitemap However since this feature is not available yet it's rather hard to add a compatibility layer. Generating the .cabal file is a no-no. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cvs commit: hugs98 Makefile RPM.mk hugs98/libraries/tools convert_libraries
On Tue, Sep 05, 2006 at 02:21:31PM +0200, Duncan Coutts wrote: On Tue, 2006-09-05 at 12:19 +0100, Ross Paterson wrote: On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote: So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? I'd rather see HaXml updated to use Data.Map, perhaps with a compatibility layer for older GHCs. Using a compatibility layer is not that easy at the moment. It's not that hard. Cabal itself does it for several packages, including Data.Map. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FiniteMap
So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? I'd rather see HaXml updated to use Data.Map, perhaps with a compatibility layer for older GHCs. OK, I've looked more closely at all uses of Data.FiniteMap in HaXml, and they are far from critical, so have reverted them to using simpler lookup structures. As far as I can tell, none of my other software now depends on FiniteMap either, so I withdraw the threat to resuscitate it. (Sorry Duncan!) Regards, Malcolm ___ 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
Hi Simon, Which version of the testsuite should I be using to test my builds of the release candidates? Best Wishes, Greg On Sep 1, 2006, at 6:03 AM, Simon Marlow wrote: Only a week late, we are pleased to announce the Release Candidate phase for GHC 6.6. Snapshots beginning with 6.5.20060831 are release candidates for 6.6 Download snapshots from here: http://www.haskell.org/ghc/dist/current/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060831- src.tar.bz2 http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060831-src- extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that we normally supply with GHC (and a couple of new ones) - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux (Fedora Core 5), i386/Linux (RedHat 7(!)), and Windows. More may appear later. Please test as much as possible, bugs are much cheaper if we find them before the release! Which brings me on to the release itself: we had planned to release before ICFP, but that only leaves just over a week, which isn't really enough time to test the RC thoroughly, so it's looking like the 6.6 release will happen after ICFP now. In the meantime we have the RC to play with, so enjoy... Cheers, Simon ___ 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: FiniteMap
On Tue, Sep 05, 2006 at 02:13:33PM +0100, Malcolm Wallace wrote: So does anyone have any objections if I go ahead and commit the replacement (compatibility) implementation of Data.FiniteMap to the main repository for packages/base? I'd rather see HaXml updated to use Data.Map, perhaps with a compatibility layer for older GHCs. OK, I've looked more closely at all uses of Data.FiniteMap in HaXml, and they are far from critical, so have reverted them to using simpler lookup structures. Why not do it the other way round: #if __GLASGOW_HASKELL__ = 604 || __NHC__ = 118 || defined(__HUGS__) -- Data.Map, if it is available import Prelude hiding (lookup) import Data.Map (Map, lookup, fromList) #else -- otherwise, a very simple and inefficient implementation of a finite map type Map k a = [(k,a)] fromList :: [(k,a)] - Map k a fromList = id -- Prelude.lookup :: k - Map k a - Maybe a #endif ___ 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
On 05 September 2006 14:21, Gregory Wright wrote: Which version of the testsuite should I be using to test my builds of the release candidates? Good question. We haven't made any tarballs of the testsuite, but just grabbing the current sources from darcs is fine. Cheers, 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 9/5/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote: The old model was that every instance is potentially overlappable; andyou only need the flag when you *use* the instances.But peoplecomplained that the clients of their library should not need to knowimport Foogle and use -fallow-overlapping-instances. I think that any module that depends on this feature in any way should require the flag.Foogle might define some overlapping instances which are meant to be used only in its implementation--that is, users of Foogle aren't meant to make use those instance declarations. In that scenario, I could see a case for not requiring importing modules to specify the flag. But, I think that depends on a mechanism for controlling whether or not an instance declaration get exported in order to be useful. - Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Program slower with local definitions
Hello *, I noticed a five percent speed up by making local definitions global. This is the first version with local definitions: f = some expression based on mySet where mySet = foldl (flip Set.insert) Set.empty myList myList = some constant list Then I moved mySet and myList to the top level which gave me the speed up. Shouldn't both versions show the same behaviour with regard to run time? Doesn't the compiler lift mySet and myList to top level automatically? Are myList and mySet evaluated in every call to f when defined locally? I am using ghc 6.4.2 on Windows XP. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Program slower with local definitions
Michael Marte [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Hello *, I noticed a five percent speed up by making local definitions global. Maybe the global defintions are monomorphic, and the local defintions are polymorphic. You could evaluate the types of the global types and apply them to the local definitions to see if that then gives the same result. (just guessing). Rene. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Program slower with local definitions
That's odd. Making things more global can reduce optimisation opportunities, but making things ore local should not. You can say -ddump-simpl to get an idea of what the differences are. If you can make a smallish repo case, I'll take a look, though perhaps not before ICFP. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Michael Marte | Sent: 05 September 2006 17:40 | To: glasgow-haskell-users@haskell.org | Subject: Program slower with local definitions | | Hello *, | | I noticed a five percent speed up by making local definitions global. | | This is the first version with local definitions: | | f = some expression based on mySet | where | mySet = foldl (flip Set.insert) Set.empty myList | myList = some constant list | | Then I moved mySet and myList to the top level which gave me the speed up. | | Shouldn't both versions show the same behaviour with regard to run time? | Doesn't the compiler lift mySet and myList to top level automatically? | Are myList and mySet evaluated in every call to f when defined locally? | | I am using ghc 6.4.2 on Windows XP. | | Michael | ___ | 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
GHC non-termination
Hello all,
I've discovered that GHC doesn't deal very well with the following
program. It appears to diverge when running the following program
with 'runghc'. The main compiler can also be persuaded to diverge in
a similar fashion. Hugs exhibits correct behavior, ie, it prints
hello.
This is with GHC 6.4.2. I've tested on linux x86 and PPC OS X.
newtype Mu a = Roll { unroll :: Mu a - a }
omega :: a
omega = (\x - (unroll x) x) (Roll (\x - (unroll x) x))
main = putStrLn hello
Rob Dockins
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC non-termination
You and many others --- but the example is always the same!
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-g
hc
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Robert Dockins
| Sent: 05 September 2006 20:48
| To: glasgow-haskell-users@haskell.org
| Subject: GHC non-termination
|
| Hello all,
|
| I've discovered that GHC doesn't deal very well with the following
| program. It appears to diverge when running the following program
| with 'runghc'. The main compiler can also be persuaded to diverge in
| a similar fashion. Hugs exhibits correct behavior, ie, it prints
| hello.
|
| This is with GHC 6.4.2. I've tested on linux x86 and PPC OS X.
|
|
|
| newtype Mu a = Roll { unroll :: Mu a - a }
|
| omega :: a
| omega = (\x - (unroll x) x) (Roll (\x - (unroll x) x))
|
| main = putStrLn hello
|
|
|
| Rob Dockins
|
| Speak softly and drive a Sherman tank.
| Laugh hard; it's a long way to the bank.
|-- TMBG
|
|
|
| ___
| 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: GHC non-termination
Ah. My apologies for bringing up such a well-worn issue, then.
On Sep 5, 2006, at 3:38 PM, Simon Peyton-Jones wrote:
You and many others --- but the example is always the same!
http://www.haskell.org/ghc/docs/latest/html/users_guide/
bugs.html#bugs-g
hc
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Robert Dockins
| Sent: 05 September 2006 20:48
| To: glasgow-haskell-users@haskell.org
| Subject: GHC non-termination
|
| Hello all,
|
| I've discovered that GHC doesn't deal very well with the following
| program. It appears to diverge when running the following program
| with 'runghc'. The main compiler can also be persuaded to
diverge in
| a similar fashion. Hugs exhibits correct behavior, ie, it prints
| hello.
|
| This is with GHC 6.4.2. I've tested on linux x86 and PPC OS X.
|
|
|
| newtype Mu a = Roll { unroll :: Mu a - a }
|
| omega :: a
| omega = (\x - (unroll x) x) (Roll (\x - (unroll x) x))
|
| main = putStrLn hello
|
|
|
| Rob Dockins
|
| Speak softly and drive a Sherman tank.
| Laugh hard; it's a long way to the bank.
|-- TMBG
|
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Floating point problems
On Fri, Sep 01, 2006 at 10:11:30AM +0100, Simon Marlow wrote: Nowadays -mfpmath=sse is better than -ffloat-store, because SSE2 has single and double-precision floating point arithmetic. I get pretty reproducible arithmetic on x86_64 this way, where SSE2 is the default. Thanks for the tip! -- David Roundy ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.6 candidate
Hello, I successfully downloaded and installed ghc-6.5.20060901 on Windows XP (SP2 etc.). However, when attempting to build fps-0.8, I received a large number of errors stemming from gcc being unable to find Stg.h or HsBase.h. As far as I could tell using -v, gcc is still being passed the old path to the include files (ghc-dir\include, perhaps) whereas said files were actually located in ghc-dir\lib\i386-unknown-mingw32\include. Moving the files from the new location to the old solved the compilation problem. Was this a problem in the distributed build, or did I do something wrong when I was installing it? Thanks. /g -- It is myself I have never met, whose face is pasted on the underside of my mind. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.6 candidate
trevion: Hello, I successfully downloaded and installed ghc-6.5.20060901 on Windows XP (SP2 etc.). However, when attempting to build fps-0.8, I received a large number of errors stemming from gcc being unable to find Stg.h or HsBase.h. As far as I could tell using -v, gcc is still being passed the old path to the include files (ghc-dir\include, perhaps) whereas said files were actually located in ghc-dir\lib\i386-unknown-mingw32\include. Moving the files from the new location to the old solved the compilation problem. Was this a problem in the distributed build, or did I do something wrong when I was installing it? Note that you shouldn't have to build fps 0.8 with ghc now, it comes included in the base library :) -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
