March 2005 - Glasgow-haskell-users

Re: GHC 6.4 release candidates available
by Benjamin Franksen 02 Mar '05

02 Mar '05

I haven't followed this thread too closely so please excuse me if this has already been mentioned (or even fixed). After I installed the latest binary package (20050228) the documentation was not correctly linked from the main documentation page. 'Hierarchical Libraries' on the main page points to /usr/local/share/ghc-6.4.20050228/html/libraries/index.html, but in this directory there is no index.html, only subdirectories. The link named 'Cabal' is also dead: file:/usr/local/share/ghc-6.4.20050228/html/Cabal/index.html does not exist). This is clearly non-critical, but it would be nice if it could be fixed in the final version. Ben

1 0

RE: readline fun
by Simon Marlow 01 Mar '05

01 Mar '05

On 02 February 2005 15:51, Ian Lynagh wrote: > The Debian ghc6 package curently has both a build-dependency and a > normal dependency on libreadline4-dev. The former is so the readline > library (and ghci) can be built, and the latter so compiling programs > with the readline package behaves correctly. > > Now I want to move over to libreadline5-dev instead. Clearly, to build > the new ghc6, I need the old ghc6 installed, and thus need > libreadline4-dev installed (as it's a dependency). However, > libreadline4-dev and libreadline5-dev can't be installed > simultaneously. > > I believe this isn't a /real/ problem because the readline package of > the old GHC isn't actually needed to compile a new GHC, so > libreadline4-dev isn't actually needed. Thus I can solve this problem > by doing a build by hand on each arch. However, it would make my life > a lot easier if things weren't so entangled in the first place. I bet the old GHC will work fine with the new readline. Can't you solve it that way? (apologies if I'm just being naïve... I've never used a Debian system). > While I could just split the readline package off into a separate > ghc6-readline package for Debian, I fear this may cause confusion for > users, and it would mean satisfying cabal package deps was not > necessarily sufficient for Debian systems. So what would be really > useful for me is if the split were done by ghc itself, in much the > same way as how the opengl libraries can be split off. Then, in > particular, cabal packages using readline would have to explicit > state it rather than assuming it'll be there by default. Not sure what you're asking for here. The OpenGL libraries can't easily be split off. You want us to ship the readline package separately, say as a Cabal package? That's a possibility, but we like to keep the GHC sources as self-contained as possible, and adding another dependency just makes it harder to build GHC. Sure, readline would be optional, but mostly you want it ("why doesn't up-arrow work in the GHCi I just built?"). Ideally, we would have a home-grown readline replacement (System.Console.SimpleLineEditor doesn't count: it depends on your terminal using ANSI escape sequences). Cheers, Simon

2 1

RE: new ghc under solaris
by Simon Marlow 01 Mar '05

01 Mar '05

On 24 February 2005 11:35, Christian Maeder wrote: > I've made progress with ghc HEAD under solaris 8. In fact I could > successfully install a ghc-6.5 compiler that was able to compile a > couple of files (including "Hello World") > > But on one file (by chance HughesPJ.hs with an unqualified module > name) > I got a "Bus Error" (see below) I'll try now if "gmake bootstrap3" > fails, too. > > During "gmake" also the _FILE_OFFSET_BITS warning was not entirely > gone: > > In file included from ../includes/ghcconfig.h:4, > from ../includes/Stg.h:42, > from ../includes/Rts.h:19, > from RetainerSet.c:14: > ../includes/ghcautoconf.h:364: warning: `_FILE_OFFSET_BITS' redefined > /usr/include/sys/feature_tests.h:96: warning: this is the location of > the previous definition. > > (There were numerous other warnings, too many to post here.) I don't think the _FILE_OFFSET_BITS warnings have anything to do with the bus error, but if you send me the whole log I'll look into eliminating them. What version of gcc are you using? Cheers, Simon

3 2

RE: Scrap your boilerplate (but don't scrap them precious comments)
by Simon Marlow 01 Mar '05

01 Mar '05

On 01 March 2005 10:43, Ross Paterson wrote: > On Tue, Mar 01, 2005 at 09:42:17AM -0000, Simon Marlow wrote: >> One thing I'm going to do for the 6.4 docs is include a link to the >> source code file (pointing to cvs.haskell.org) for each module. > > Of course this won't work when the exported names are defined > elsewhere. But I also think it would be going too far: it will > encourage users > to refer to the source code as the true documentation in all cases, > leading to both reliance on accidental features and reduced demand for > better interface documentation. That's true. I also discovered that adding the source code links isn't as easy as I thought, so it won't happen anyway. Cheers, Simon

1 0

RE: Scrap your boilerplate (but don't scrap them precious comments)
by Simon Marlow 01 Mar '05

01 Mar '05

Including the source code in Haddock output is a good idea. Retaining the original indentation would be tricky (but possible, the HaRe folks have to solve a similar problem). Marking up the source code with hyperlinks requires applying Haskell's static scoping rules to the source code - currently Haddock doesn't have to do this, it only deals with type signatures and type declarations. One thing I'm going to do for the 6.4 docs is include a link to the source code file (pointing to cvs.haskell.org) for each module. Cheers, Simon On 01 March 2005 01:20, Ralf Lammel wrote: > That's a very good point. > Me too, I would often wish to see some principled > code details when entering documentation. For instance > what is the point of _explaining_ that "inc" aliases > "add 1", why not just show that equation! I agree that > gmap?? are a bit of this kind. It is so much easier to > explain them, while showing code. It is so much of a > hassle to explain them while not showing code. The > implementations of gmap?? are almost like algebraic > properties ... I mean these are rather principled > implementations. A documentation tool should support > algebraic laws _and_ such principled implementations. > > It would really help to link the function signatures > with the function definitions in the sense of a limited > code browsing functionality. > > I am sure this is not a new discussion topic, > but we really need this IMHO. > > Ralf > >> -----Original Message----- >> From: glasgow-haskell-users-bounces(a)haskell.org >> [mailto:glasgow-haskell- users-bounces(a)haskell.org] On Behalf Of >> Benjamin Franksen >> Sent: Monday, February 28, 2005 4:11 PM >> To: glasgow-haskell-users(a)haskell.org >> Subject: Scrap your boilerplate (but don't scrap them precious >> comments) >> >> Hi, >> >> I have been racking my brain over the infamous 'gfoldl' and 'gunfold' >> combinators. (Yes, I have read the papers). What finally made me >> understand how they worked was reading the code: first the >> implementation of the gmap functions (Data/Generics/Basics.hs), then >> the long and detailed comments in the same file, and finally the >> instance definitions for the built-in types (in >> Data/Generics/Instances.hs). >> >> IMHO, a lot of this could and should be part of the >> (haddock-generated) documentation. >> >> It is such a waste: all these wonderful comments in the source file, >> that could be added to the docs with a keystroke! Instead, they >> simply say >> >> "Left-associative fold operation for constructor applications" >> >> which is really a bit terse for gfoldl, of which the source file >> comment (rightly) states that its type is a "headache". >> >> Furthermore, (example) implementations can sometimes be extremely >> helpful to understand things; this is especially true for a language >> like Haskell, in which the implementation is often already the >> shortest (or at least a very short) and most precise way to specify >> a functions semantics. >> >> In this case, the implementations of gfoldl helped me to understand >> what the function itself does. However, how and why these extremely >> abstract combinators can serve as the basic building blocks of all >> the more concrete and better understandable variants is best >> documented by the implementation of just these variants gmapXX and >> friends. (Maybe one or two examples implementations would suffice). >> At least, it should be stated in the docs what the type constructor >> ('c') is in each case. >> >> I don't know if haddock can add the implementation of a function to >> the documentation. If not, such a feature should be considered. >> >> SYB is a wonderful piece of work and deserves to be documented as >> well as it is programmed. >> >> Ben >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

RE: Scrap your boilerplate (but don't scrap them precious comments)
by Ralf Lammel 01 Mar '05

01 Mar '05

That's a very good point. Me too, I would often wish to see some principled code details when entering documentation. For instance what is the point of _explaining_ that "inc" aliases "add 1", why not just show that equation! I agree that gmap?? are a bit of this kind. It is so much easier to explain them, while showing code. It is so much of a hassle to explain them while not showing code. The implementations of gmap?? are almost like algebraic properties ... I mean these are rather principled implementations. A documentation tool should support algebraic laws _and_ such principled implementations. It would really help to link the function signatures with the function definitions in the sense of a limited code browsing functionality. I am sure this is not a new discussion topic, but we really need this IMHO. Ralf > -----Original Message----- > From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- > users-bounces(a)haskell.org] On Behalf Of Benjamin Franksen > Sent: Monday, February 28, 2005 4:11 PM > To: glasgow-haskell-users(a)haskell.org > Subject: Scrap your boilerplate (but don't scrap them precious comments) > > Hi, > > I have been racking my brain over the infamous 'gfoldl' and 'gunfold' > combinators. (Yes, I have read the papers). What finally made me > understand > how they worked was reading the code: first the implementation of the gmap > functions (Data/Generics/Basics.hs), then the long and detailed comments > in > the same file, and finally the instance definitions for the built-in types > (in Data/Generics/Instances.hs). > > IMHO, a lot of this could and should be part of the (haddock-generated) > documentation. > > It is such a waste: all these wonderful comments in the source file, that > could be added to the docs with a keystroke! Instead, they simply say > > "Left-associative fold operation for constructor applications" > > which is really a bit terse for gfoldl, of which the source file comment > (rightly) states that its type is a "headache". > > Furthermore, (example) implementations can sometimes be extremely helpful > to > understand things; this is especially true for a language like Haskell, in > which the implementation is often already the shortest (or at least a very > short) and most precise way to specify a functions semantics. > > In this case, the implementations of gfoldl helped me to understand what > the > function itself does. However, how and why these extremely abstract > combinators can serve as the basic building blocks of all the more > concrete > and better understandable variants is best documented by the > implementation > of just these variants gmapXX and friends. (Maybe one or two examples > implementations would suffice). At least, it should be stated in the docs > what the type constructor ('c') is in each case. > > I don't know if haddock can add the implementation of a function to the > documentation. If not, such a feature should be considered. > > SYB is a wonderful piece of work and deserves to be documented as well as > it > is programmed. > > Ben > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

RE: gunfoldl
by Simon Peyton-Jones 01 Mar '05

01 Mar '05

Regardless of the programming, this should not have crashed GHC. I've fixed it, and added a regression test. Thanks for bringing it up. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Akos Korosmezey | Sent: 18 February 2005 20:05 | To: GHC-users list | Subject: gunfoldl | | | I wrote a little data structure with quantified constructors: | | module MyModule where | import Data.Generics | import Data.HashTable | | data Item = forall a. (Data a) => Leaf Bool a | | forall a. (Data a) => Branch Bool a Int Int | | deriving (Typeable) | | I want it to make an instance of Data: | | instance Data Item where | gfoldl k z (Leaf b v) = z (Leaf b) `k` v | gfoldl k z (Branch b v a1 a2) = z (\x -> Branch b x a1 a2) `k` v | --gunfoldl k z c = case constrIndex c of | -- 1 -> k z (Leaf undefined | undefined) | toConstr (Leaf _ _) = leafConstr | toConstr (Branch _ _ _ _) = branchConstr | dataTypeOf _ = itemDataType | | itemDataType = mkDataType "Subliminal.Item" [leafConstr, branchConstr] | leafConstr = mkConstr itemDataType "Leaf" [] Prefix | branchConstr = mkConstr itemDataType "Branch" [] Prefix | | But, when I try to compile it with ghc-6.4-20050217: | | ghc -fglasgow-exts -i. -c kicsi.hs | | kicsi.hs:13:4: | Warning: No explicit method nor default method for `gunfold' | In the instance declaration for `Data Item' | ghc-6.4.20050217: panic! (the `impossible' happened, GHC version | 6.4.20050217): | cgPanic | k{v a1vu} | static binds for: | local binds for: | gunfold{v r22q} | SRT labelghc-6.4.20050217: panic! (the `impossible' happened, GHC | version 6.4.20050217): | initC: srt | | Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, | or http://sourceforge.net/projects/ghc/. | | If I uncomment the gunfoldl lines: | | ghc -fglasgow-exts -i. -c kicsi.hs | | kicsi.hs:12:8: `gunfoldl' is not a (visible) method of class `Data' | | Compilation exited abnormally with code 1 at Fri Feb 18 20:55:32 | | Could you please help me? | | Thanks | Akos | -- | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ~~~~~~ | Akos Korosmezey Tel: +36-1-439-5936 | Ericsson Telecom Ltd. ETH/GSCD/RUNB Fax: +36-1-437-7576 | P.O.B. 107, H-1300 Budapest, Hungary Home: +36-26-342-687 | mailto:Akos.Korosmezey@ericsson.com Mobile: +36-30-740-7732 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ~~~~~~ | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Scrap your boilerplate (but don't scrap them precious comments)
by Benjamin Franksen 01 Mar '05

01 Mar '05

Hi, I have been racking my brain over the infamous 'gfoldl' and 'gunfold' combinators. (Yes, I have read the papers). What finally made me understand how they worked was reading the code: first the implementation of the gmap functions (Data/Generics/Basics.hs), then the long and detailed comments in the same file, and finally the instance definitions for the built-in types (in Data/Generics/Instances.hs). IMHO, a lot of this could and should be part of the (haddock-generated) documentation. It is such a waste: all these wonderful comments in the source file, that could be added to the docs with a keystroke! Instead, they simply say "Left-associative fold operation for constructor applications" which is really a bit terse for gfoldl, of which the source file comment (rightly) states that its type is a "headache". Furthermore, (example) implementations can sometimes be extremely helpful to understand things; this is especially true for a language like Haskell, in which the implementation is often already the shortest (or at least a very short) and most precise way to specify a functions semantics. In this case, the implementations of gfoldl helped me to understand what the function itself does. However, how and why these extremely abstract combinators can serve as the basic building blocks of all the more concrete and better understandable variants is best documented by the implementation of just these variants gmapXX and friends. (Maybe one or two examples implementations would suffice). At least, it should be stated in the docs what the type constructor ('c') is in each case. I don't know if haddock can add the implementation of a function to the documentation. If not, such a feature should be considered. SYB is a wonderful piece of work and deserves to be documented as well as it is programmed. Ben

1 0