RE: ghc cyclic import error confusing
Following Bryan's suggestion I've improved GHC's error message when there's a module cycle: Module imports form a cycle: module `Foo4' imports `Foo' which imports `Foo2' which imports `Foo3' which imports `Foo4' Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Bryan Richter | Sent: 14 April 2011 18:24 | To: glasgow-haskell-users@haskell.org | Subject: Re: ghc cyclic import error confusing | | On Wed, Apr 13, 2011 at 11:44:33AM +0100, Simon Marlow wrote: | On 09/04/2011 04:32, Evan Laforge wrote: | I've found ghc's cyclic import error to be rather confusing, and I | finally took the time to understand why. Here's an example: | | Module imports form a cycle for modules: |Cmd.Cmd (./Cmd/Cmd.hs) | imports: Perform.Midi.Instrument Instrument.MidiDb Instrument.Db |Perform.Midi.Instrument (./Perform/Midi/Instrument.hs) | imports: Cmd.Cmd |Instrument.MidiDb (./Instrument/MidiDb.hs) | imports: Perform.Midi.Instrument |Instrument.Db (./Instrument/Db.hs) | imports: Instrument.Search Instrument.MidiDb | Perform.Midi.Instrument |Instrument.Search (./Instrument/Search.hs) | imports: Instrument.MidiDb Perform.Midi.Instrument | | It seems to be in a strange order and mentions extraneous modules. I | would find this much easier to read: | | Perform.Midi.Instrument - Cmd.Cmd - Instrument.MidiDb - | Perform.Midi.Instrument | | So the algorithm that GHC uses is this: | |- do a strongly connected component analysis |- build until we hit a cycle |- then, report the error for the cycle | | Now, the modules in the cycle are a strongly connected component: | every module is reachable from every other module by following | imports. We report all the modules in the strongly connected | component and their imports, but omit imports of modules outside the | cycle. | | Instead, the order goes Cmd.Cmd - Instrument.MidiDb, and then goes | backwards to Perform.Midi.Instrument - Cmd.Cmd. Then it goes | forward again to Instrument.MidiDb - Perform.Midi.Instrument. So | the order makes you jump around if you want to trace the import | chain. The duplicated module that joins the cycle is not visually highlighted. | Whats more, it further confuses the eye by merging in multiple loops. | I suppose it could be useful to include additional loops, but I would | find it easier to read if they were included on their own line, such | as: | | Cmd.Cmd - Instrument.Db - Instrument.Search - | Perform.Midi.Instrument - Cmd.Cmd | | However, I think probably the shortest loop is the most interesting | one, and if there are multiple shortest loops, simply picking one | randomly is likely to be sufficient. | | Picking the shortest one sounds reasonable. However, there could be a | single edge which if removed will break all the loops, and they might | want to know which it is. | | If you want to play with this, the code is very localised: it is a few | lines in GhcMake.cyclicModuleError | | http://hackage.haskell.org/trac/ghc/browser/compiler/main/GhcMake.hs#L | 1446 | | Hi Simon and Evan, | | Thanks for bringing up a problem, and providing useful information about it, in a way | that is understandable enough for a newcomer to have an opinion about it! | | So, here is my newcomer's opinion: The error displays a strongly connected graph, | with one or more cycles, but labels it a cycle. As you both point out, having all | the information about the strongly connected modules is very useful. Labeling it a | cycle, however, gives the reader an expectation that is bound to be confounded. | | Perhaps the following change would be sufficient? | | | | --- tmp/GhcMake.hs~ 2011-04-14 09:46:02.177298318 -0700 | +++ tmp/GhcMake.hs2011-04-14 09:52:25.121290827 -0700 | @@ -1460,7 +1460,8 @@ | | cyclicModuleErr :: [ModSummary] - SDoc cyclicModuleErr ms | - = hang (ptext (sLit Module imports form a cycle for modules:)) | + = hang (ptext (sLit Module imports form a strongly connected graph, | + with one or more cycles, for these modules:)) | 2 (vcat (map show_one ms)) |where | mods_in_cycle = map ms_mod_name ms | | | | | | -Bryan | | P.S. I'm not sure what the accepted method for formatting/wrapping string literals | is, so I left it as an exercise. :) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to install GhC on a Mac without registering?
For use at high school level, I would imagine that you would want to build a special distribution anyway. One that for example already includes packages, such as Gloss, that would be useful in teaching children programming in Haskell without they having to go through learning to use cabal (which is a bigger hurdle than installing Xcode IMHO). But I wonder, would those students not use school equipment (which supposedly would have all software pre-installed)? Do they bring their own Macs? (I'd be surprised to find a whole class of 6th graders all owning Macs...)As a further data point, yesterday one of my colleagues gave his 17-yr-old daughter a copy of the "Learn you a Haskell for Great Good" book. She started to read it, and wanted to play with Haskell on her MacBook Air. First step, download ghc. Discover that it will not install on Leopard. Step two: upgrade the operating system to Snow Leopard. One hour later, attempt to install ghc again. Discover that it requires XCode. Step three: buy XCode from the mac App Store, and wait two hours for the 4Gb download over a hotel wifi connection Step four: hotel wifi access runs out before the download is complete, so give up and go back to watching the movie she downloaded earlier, but has not been able to watch whilst all this downloading and upgrading has been happening.A happy customer?Regards, Malcolm___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to install GhC on a Mac without registering?
malcolm.wallace: For use at high school level, I would imagine that you would want to build a special distribution anyway. One that for example already includes packages, such as Gloss, that would be useful in teaching children programming in Haskell without they having to go through learning to use cabal (which is a bigger hurdle than installing Xcode IMHO). But I wonder, would those students not use school equipment (which supposedly would have all software pre-installed)? Do they bring their own Macs? (I'd be surprised to find a whole class of 6th graders all owning Macs...) As a further data point, yesterday one of my colleagues gave his 17-yr-old daughter a copy of the Learn you a Haskell for Great Good book. She started to read it, and wanted to play with Haskell on her MacBook Air. First step, download ghc. Discover that it will not install on Leopard. Step two: upgrade the operating system to Snow Leopard. One hour later, attempt to install ghc again. Discover that it requires XCode. Step three: buy XCode from the mac App Store, and wait two hours for the 4Gb download over a hotel wifi connection Step four: hotel wifi access runs out before the download is complete, so give up and go back to watching the movie she downloaded earlier, but has not been able to watch whilst all this downloading and upgrading has been happening. That is a nice story, but it doesn't change what I wrote earlier: * It would be nice to have a lightweight Haskell learner's distro (for your colleagues 17-yr-old daughter and others), preferably with libraries like a web framework, Gloss, etc included — an all in one package. * The standard, production-ready Haskell distro shouldn't duplicate tools already provided by the platform vendor, especially not C compiler and libraries that quickly lead to subtly hard to find bugs in projects that use these tools also directly (and not just via GHC). Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonoLocalBinds and hoopl
I ran into some more code like this, and I realized there was something pretty important: the majority of let-bindings do not have any free varaibles. They could very well be floated to the top level without having to make any source level changes. So maybe let should be generalized, if no free variables are captured. Some food for thought. Cheers, Edward Excerpts from Edward Z. Yang's message of Thu Dec 09 10:28:20 -0500 2010: Hello all, Here's an experience report for porting hoopl to manage MonoLocalBinds. The Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of code writing, along the lines of this: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block where f n = FF3 $ ff n m n = FF3 $ fm n l n = FF3 $ fl n FF3 f `cat` FF3 f' = FF3 $ f' . f f, m, l and cat are polymorphic functions that are only used once in the main expression, and are floated outside to improve readability. However, when MonoLocalBinds is turned on, these all become monomorphic and the definitions fail. In contrast, this (uglier) version typechecks: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) (FF3 . fl) (\(FF3 f) (FF3 f') - FF3 $ f' . f)) block One suggestion that I had was that we should generalize local bindings that are only used once, but Marlow pointed out that this would make the typechecker more complex and I probably would agree. As a userspace developer, I have two options: 1. Bite the bullet and put in the polymorphic type signatures (which can be quite hefty) 2. Inline the definitions 3. Move the polymorphic functions into the global namespace (3) and (2) are not so nice because it breaks the nice symmetry between these definitions, which always define f, m, l for the many, many definitions in Hoopl of this style. Cheers, Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: MonoLocalBinds and hoopl
That is an interesting thought. As it happens, each binding records what its free variables are, so it would not be hard to check whether all the free variables were top-level-bound. Of course, it would make the rule a bit more complicated. Rather than only top level bindings are generalised it would be only binding groups whose free variables are top-level are generalised Mind you, the rule is complicated already; for example bang-patterns are not generalised. So maybe this would be no worse. I must say I'm inclined to adopt this idea. Any comments from others? Simon | -Original Message- | From: Edward Z. Yang [mailto:ezy...@mit.edu] | Sent: 14 June 2011 14:04 | To: glasgow-haskell-users; Simon Peyton-Jones | Subject: Re: MonoLocalBinds and hoopl | | I ran into some more code like this, and I realized there was something | pretty important: the majority of let-bindings do not have any free varaibles. | They could very well be floated to the top level without having to make any | source level changes. | | So maybe let should be generalized, if no free variables are captured. | Some food for thought. | | Cheers, | Edward | | Excerpts from Edward Z. Yang's message of Thu Dec 09 10:28:20 -0500 2010: | Hello all, | | Here's an experience report for porting hoopl to manage MonoLocalBinds. The | Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of | code | writing, along the lines of this: | | fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block | where f n = FF3 $ ff n |m n = FF3 $ fm n |l n = FF3 $ fl n |FF3 f `cat` FF3 f' = FF3 $ f' . f | | f, m, l and cat are polymorphic functions that are only used once in the | main expression, and are floated outside to improve readability. However, when | MonoLocalBinds is turned on, these all become monomorphic and the definitions | fail. In contrast, this (uglier) version typechecks: | | fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) | (FF3 . fl) (\(FF3 f) (FF3 f') - FF3 $ f' . f)) block | | One suggestion that I had was that we should generalize local bindings that | are only used once, but Marlow pointed out that this would make the typechecker | more complex and I probably would agree. | | As a userspace developer, I have two options: | | 1. Bite the bullet and put in the polymorphic type signatures (which | can be quite hefty) | 2. Inline the definitions | 3. Move the polymorphic functions into the global namespace | | (3) and (2) are not so nice because it breaks the nice symmetry between these | definitions, which always define f, m, l for the many, many definitions in | Hoopl of this style. | | Cheers, | Edward | ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonoLocalBinds and hoopl
On 14/06/2011 14:28, Simon Peyton-Jones wrote: That is an interesting thought. As it happens, each binding records what its free variables are, so it would not be hard to check whether all the free variables were top-level-bound. Of course, it would make the rule a bit more complicated. Rather than only top level bindings are generalised it would be only binding groups whose free variables are top-level are generalised Mind you, the rule is complicated already; for example bang-patterns are not generalised. So maybe this would be no worse. I must say I'm inclined to adopt this idea. Any comments from others? I'd rather the rule were simple, but I don't feel that strongly about it. While we're in the area, do you feel inclined to implement this? http://hackage.haskell.org/trac/ghc/ticket/2357 it would clear up the problems with MonoPatBinds - unlike MonoLocalBinds, you can't use a type signature to extract yourself from a MonoPatBinds error, and that proposal resolves the problems nicely. Cheers, Simon Simon | -Original Message- | From: Edward Z. Yang [mailto:ezy...@mit.edu] | Sent: 14 June 2011 14:04 | To: glasgow-haskell-users; Simon Peyton-Jones | Subject: Re: MonoLocalBinds and hoopl | | I ran into some more code like this, and I realized there was something | pretty important: the majority of let-bindings do not have any free varaibles. | They could very well be floated to the top level without having to make any | source level changes. | | So maybe let should be generalized, if no free variables are captured. | Some food for thought. | | Cheers, | Edward | | Excerpts from Edward Z. Yang's message of Thu Dec 09 10:28:20 -0500 2010: | Hello all, | | Here's an experience report for porting hoopl to manage MonoLocalBinds. The | Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of | code | writing, along the lines of this: | | fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block | where f n = FF3 $ ff n |m n = FF3 $ fm n |l n = FF3 $ fl n |FF3 f `cat` FF3 f' = FF3 $ f' . f | | f, m, l and cat are polymorphic functions that are only used once in the | main expression, and are floated outside to improve readability. However, when | MonoLocalBinds is turned on, these all become monomorphic and the definitions | fail. In contrast, this (uglier) version typechecks: | | fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) | (FF3 . fl) (\(FF3 f) (FF3 f') - FF3 $ f' . f)) block | | One suggestion that I had was that we should generalize local bindings that | are only used once, but Marlow pointed out that this would make the typechecker | more complex and I probably would agree. | | As a userspace developer, I have two options: | | 1. Bite the bullet and put in the polymorphic type signatures (which | can be quite hefty) | 2. Inline the definitions | 3. Move the polymorphic functions into the global namespace | | (3) and (2) are not so nice because it breaks the nice symmetry between these | definitions, which always define f, m, l for the many, many definitions in | Hoopl of this style. | | Cheers, | Edward | ___ 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: How to install GhC on a Mac without registering?
Following up on the notion that Hugs might suit the casual introductory user better - I see that while you can find it online as a pre-built package, you're normally advised (haskell.org, Kent CS dept, etc.) to build it via MacPorts - which requires Xcode. I mention this because if anyone is seriously thinking about adding an optional gcc package to the GHC Mac platform, it might be worthwhile to find out why MacPorts doesn't do that. But if anyone from the Hugs98 scene is listening - might think about making a pre-built package a more visible option, if Xcode is as onerous as we're led to believe. Donn Cave ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wiki page about new memcpy/memmove/memset primops need a home
On Wed, Jun 8, 2011 at 11:26 PM, David Terei davidte...@gmail.com wrote: I would suggest it be put under the Commentary/Compiler. Here's a first draft: http://hackage.haskell.org/trac/ghc/wiki/MemcpyOptimizations Feel free to point out things that need clarification. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
