November 2005 - Libraries

external core
by John Meacham 22 Mar '06

22 Mar '06

Now, the external core feature of ghc is great, but it is not utilized very much. The main reason I think is that there is a large barrier to entry in writing something that uses it since you need to parse/generate it. It would be nice if there were a standard library that came with ghc (or cabalized and portable even better) that could parse and pretty print external core. ideally, one could write a simple pass-through core processor that interacts with ghc in a single line and someone working on a new optimization need only worry about that. Also, it would make it very easy for jhc to generate and parse ghc core files (always an ulterior motive). I wanted to use jhcs front end to generate ghc core so I could get a true measure of the difference in just their back-end performance without taking into account ghc's superior high-level optimizations. In any case. I think all the code is out there in ghc and it just needs to be separated and cabalized. I know there was talk of creating a ghc internals library, but it would be nice if this code were portable and independent. John -- John Meacham - ⑆repetae.net⑆john⑈

3 4

Trie implementation
by Keith Wansbrough 11 Mar '06

11 Mar '06

Hi... I was writing some code yesterday to walk over a directory tree, and needed a Trie. Not seeing one around, I wrote a basic implementation of the functions I needed (attached below). Has anyone else done this? Should I polish it up and offer it for inclusion in Data? --KW 8-)

7 8

RE: lawbreakers in Text.PrettyPrint.HughesPJ
by Simon Peyton-Jones 01 Dec '05

01 Dec '05

It's a long time since I looked at this library. If you two can agree on what needs to be done, I'll gladly execute the change! Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Christian | Maeder | Sent: 24 November 2005 18:05 | To: Conal Elliott | Cc: libraries(a)haskell.org | Subject: Re: lawbreakers in Text.PrettyPrint.HughesPJ | | Conal Elliott wrote: | > Or the combinators (<>, $$, etc) might take care to build their results | > in reduced form, which seems to be the strategy that "nest" takes. | | maybe that is possible, too (as now an extra call of reduceDoc for | isEmpty is done). Fortunately isEmpty is rarely used, and if it is used | the original input is usually thrown away. | | > BTW, there's an invariant comment (about Doc, I think) that says "An | > empty document is always represented by @Empty@." If the combinators | > aren't going to ensure that's true, then probably the comment should be | > removed or fixed. | | The comment only seems to apply to RDoc that don't have Above or Beside | (at least on the top-level). | | Christian | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 3

Data.IntMap API
by Iavor Diatchki 30 Nov '05

30 Nov '05

Hello, Data.IntMap (distributed with GHC 6.4.1) contains the following instance: Ord a => Monoid (IntMap a) The instance is defined with mempty = empty, and mappend = union, neither of which requires the Ord instances on the values in the map, so the 'Ord a' constraint appears unneccessary. -Iavor PS: Isn't picking union for the monoid class a little arbitrary?

3 2

Cabal created permissions
by Bernd Brassel 29 Nov '05

29 Nov '05

Hi there, another thing I hope is worth mentioning after Simon so gloriously solved my last problem in record time: Now using Cabal 1.1.3, the permissions for globally installed packages go wrong. Even though I used umask 0000 for these procedures, the installed files had all no read permissons for no-roots. I think, this problem was not there with the cabal version shipped with ghc 6.4.1. I could work around it by hand, but maybe others have the same issues?

1 0

RE: Cabal and hIDE
by Simon Marlow 29 Nov '05

29 Nov '05

On 29 November 2005 10:35, Bernd Brassel wrote: > Hello there, > > I try to install hIDE by cabal, but I got some problems. > First of all, it seems that I need a newer version of cabal than what > is shipped with ghc 6.4.1. According to the README of Cabal, 1.1.3 I > unregistered the older cabal first. But then I get lots of warnings > the like: > > > Distribution/Simple.hs:432:25: > > Warning: This binding for `pkg_descr' shadows an existing > binding > In the definition of `mockPP' > > > > Is this okay? Or should I have uninstalled something else (and how)? > > Trying to use the new cabal to install hIDE, "runhaskell Setup.lhs > configure" runs without error, but then: > > > runhaskell Setup.lhs build > > Preprocessing executables for hIDE-0.1.0... > > Building hIDE-0.1.0... > > ghc-6.4.1: ghc-6.4.1: panic! (the `impossible' happened, GHC > version > 6.4.1): > > unknown exception > > > > Please report it as a compiler bug to > > glasgow-haskell-bugs(a)haskell.org, > > or http://sourceforge.net/projects/ghc/. > > I guess, something went wrong, didn't it?... You probably have another package that depends on the old version of Cabal, and since you unregistered it the dependencies aren't satisfied. The error message is a bug in GHC 6.4.1 (now fixed), it should read something like "package Cabal-1.0 not found". A common package that depends on Cabal is hs-plugins; remove this an re-install it after removing Cabal-1.0 and you'll be fine. Cheers, Simon

1 0

Cabal and hIDE
by Bernd Brassel 29 Nov '05

29 Nov '05

Hello there, I try to install hIDE by cabal, but I got some problems. First of all, it seems that I need a newer version of cabal than what is shipped with ghc 6.4.1. According to the README of Cabal, 1.1.3 I unregistered the older cabal first. But then I get lots of warnings the like: > Distribution/Simple.hs:432:25: > Warning: This binding for `pkg_descr' shadows an existing binding > In the definition of `mockPP' > Is this okay? Or should I have uninstalled something else (and how)? Trying to use the new cabal to install hIDE, "runhaskell Setup.lhs configure" runs without error, but then: > runhaskell Setup.lhs build > Preprocessing executables for hIDE-0.1.0... > Building hIDE-0.1.0... > ghc-6.4.1: ghc-6.4.1: panic! (the `impossible' happened, GHC version 6.4.1): > unknown exception > > Please report it as a compiler bug to > glasgow-haskell-bugs(a)haskell.org, > or http://sourceforge.net/projects/ghc/. I guess, something went wrong, didn't it?... Greetings Bernd

1 0

Text.Html
by Jun Mukai 29 Nov '05

29 Nov '05

hello, haskellers Text.Html seems to generate HTML 3.2. It is too obsolete to use, isn't it? Are there any plans to support HTML 4.x or xhtml? It is true that WASH-HTML (and other libraries?) can generate xhtml. But the situation that the standard library supports legacy version of HTML only is bad. IMHO, the Text.Html should be rewrite to generate HTML 4.x, or the new library named Text.Xhtml should be introduced.

3 3

RE: Text.Html
by Simon Marlow 28 Nov '05

28 Nov '05

On 28 November 2005 01:46, Jun Mukai wrote: > Text.Html seems to generate HTML 3.2. It is too obsolete to use, > isn't it? Are there any plans to support HTML 4.x or xhtml? > > It is true that WASH-HTML (and other libraries?) can generate xhtml. > But the situation that the standard library supports legacy version of > HTML only is bad. > > IMHO, the Text.Html should be rewrite to generate HTML 4.x, or the new > library named Text.Xhtml should be introduced. Yes, Text.Html needs a lot of work. There's a slightly improved version in Haddock. I think I asked a while back if anyone was interested in updating it, and didn't get any responses. We should consider whether Text.Html should be (a) just an improved version of what we have now (b) WASH's HTML library (or a derivative thereof) (c) an instance of a more general XML library (d) something else? I only have experience with (a), and I find it mildly inconvenient: the overloading doesn't really seem to buy much, but the table support is quite useful. (b) has a fully typed HTML implementation which prevents ill-formed documents, but the downside is that types are large, and type errors can be incomprehensible. Cheers, Simon

1 0

lawbreakers in Text.PrettyPrint.HughesPJ
by Conal Elliott 25 Nov '05

25 Nov '05

The comments in HughesPJ say that empty is an identity for <> and $$, but the implementation doesn't satisfy either of these laws. Here are the implementations: > p $$ q = Above p False q > p <> q = Beside p False q and definitions for empty and isEmpty: > empty = Empty > isEmpty Empty = True > isEmpty _ = False It's an easy fix, just adding these two lines before the current definitions of $$: > Empty $$ q = q > p $$ Empty = p And these before the current definition of <>: > Empty <> q = q > p <> Empty = p - Conal

2 5