September 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

Data.Monoid
by Ross Paterson 27 Oct '05

27 Oct '05

(regurgitating http://www.haskell.org/pipermail/libraries/2005-July/004057.html) I propose to replace the instance instance Monoid (a -> a) where mempty = id mappend = (.) with newtype Endo a = Endo { runEndo :: a -> a } instance Monoid (Endo a) where mempty = Endo id Endo f `mappend` Endo g = Endo (f . g) instance Monoid b => Monoid (a -> b) where mempty _ = mempty mappend f g x = f x `mappend` g x

7 14

RE: cabal beginner issues (other-modules, build-depends)
by Simon Marlow 12 Oct '05

12 Oct '05

On 23 September 2005 08:45, Johannes Waldmann wrote: >> Another way to look at both issues is that if ghc can figure out >> other modules and packages itself, the user shouldn't be required to >> specify them in a cabal file. ... > > Definitely. Having the list of modules in the .cabal is unnecessary > duplication of information (because it's in the sources already). > This is bound to get out-of-sync during development - > unless you use some kind of Makefile to generate the .cabal file, > which defeats the very purpose of Cabal itself. I know how to do this using GHC, but I'm not sure about other compilers. With GHC, we can generate the dependencies using 'ghc -M' and then parse the generated Makefile (a bit of a long way around, but I can't think of an easier way). Of course we'd avoid splatting an existing Makefile by redirecting the dependencies to a temporary file. How would we do this with nhc98 or Hugs? Perhaps because these systems don't actually need to know the value of other-modules we can get away with it. Comments? > Unrelated question: can someone please share an example that shows > how to put user-defined options for haddock in a .cabal? There's no good way to do it right now. You can override the whole haddock command using hooks, but you'd have to write quite a bit of code to do this. I plan to add something to allow extra Haddock args to be given (the Haddock support is a very bare-bones right now, it should get better). Cheers, Simon

4 6

cabal question / feature request
by Johannes Waldmann 11 Oct '05

11 Oct '05

Dear all. is there a way to get the preprocessed sources of a project from Cabal? Is this what "Setup copy" is for? (I guess not.) If I do "runhaskell Setup.hs sdist", I get a tarball with the original sources (macros not expanded). If I do "runhaskell Setup.hs haddock" it seems the preprocessed sources are built - but then deleted, so I only get what haddock makes of them (and this I don't like - I need more control over haddock options, so I need to run it outside cabal.) Can I get the desired effect by doing Setup configure for hugs and then Setup install? (Would this install preprocessed sources?) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

How to fix aclocal.m4 of OpenAL Library to works well Windows and Mac OS X platform?
by shelarcy 26 Sep '05

26 Sep '05

Hello. I'm trying to build OpenAL Library on Windows and Mac OS X. I have already done about OpenAL/configure.ac and OpenAL/Sound/OpenAL/Config.hs, but I don't know about how to fix OpenAL/aclocal.m4's FP_FUNC_ALCPROCESSCONTEXT_VOID and FP_FUNC_ALCDESTROYCONTEXT_VOID. These funcation doesn't works well on at least Windows and Mac OS X platform, so ALCPROCESSCONTEXT_VOID and ALCDESTROYCONTEXT_VOID isn't defined on there platforms. Does anyone has idea? -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

2 2

RE: Unexpected behaviour in Text.PrettyPrint.HughesPJ
by Simon Peyton-Jones 24 Sep '05

24 Sep '05

That does seem like a bug to me. I would love it if someone else could dig into the library and fix it.... it's years since I looked at it. Probably there are many things that could be improved. I have no ego investment in it, so it's 100% open to improvement. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Anders | Höckersten | Sent: 22 September 2005 07:42 | To: Haskell libraries | Subject: Unexpected behaviour in Text.PrettyPrint.HughesPJ | | Hi, | I've been using the pretty printer in Text.PrettyPrint.HughesPJ lately, | and I've encountered a behaviour that was very unexpected for me. If I | define this small example: | | test = text "foo" <+> empty <> text "bar" | | Running 'show test' now gives the string "foobar" as a result (whereas I | expected "foo bar").It seems the empty "eats" the space that I expect | <+> to give me. | | So is this how the library is supposed to work or have I encountered a | bug? | | Regards, | Anders | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

5 4

RE: cabal beginner issues (other-modules, build-depends)
by Simon Marlow 23 Sep '05

23 Sep '05

On 23 September 2005 10:47, Ross Paterson wrote: > On Fri, Sep 23, 2005 at 10:37:52AM +0100, Simon Marlow wrote: >> On 23 September 2005 10:20, Ross Paterson wrote: >>> Module dependency calculation would have to be done in the build >>> environment, not at the source, because the set of modules used may >>> be system-dependent. And you'd still need to specify >>> exposed-modules. >> >> Yes, that's what I had in mind. The calculation of other-modules >> would happen when .installed-pkg-info is generated. > > I forgot extra-source-files, which is needed in the source system and > has to include all the files not mentioned elsewhere that might be > needed > on any build system. Without other-modules you'd need it more often, > and it would be harder to compute. So let's do the second best thing, and automatically check the value of the other-modules field if appropriate tools are available (GHC or hmake). Cheers, Simon

1 0

RE: Unexpected behaviour in Text.PrettyPrint.HughesPJ
by Simon Peyton-Jones 23 Sep '05

23 Sep '05

Ah yes -- a better answer than mine. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Johannes | Waldmann | Sent: 23 September 2005 09:55 | To: Simon Peyton-Jones | Cc: Haskell libraries | Subject: Re: Unexpected behaviour in Text.PrettyPrint.HughesPJ | | | > | test = text "foo" <+> empty <> text "bar" | > | | > | Running 'show test' now gives the string "foobar" as a result (whereas I | > | expected "foo bar").It seems the empty "eats" the space that I expect | > | <+> to give me. | | by definition, x <+> empty == x. | | what happens here is related to precedences: | | Text.PrettyPrint.HughesPJ> text "foo" <+> empty <> text "bar" | foobar | Text.PrettyPrint.HughesPJ> text "foo" <+> ( empty <> text "bar" ) | foo bar | | best regards, | -- | -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- | ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: cabal beginner issues (other-modules, build-depends)
by Simon Marlow 23 Sep '05

23 Sep '05

On 23 September 2005 10:20, Ross Paterson wrote: > On Fri, Sep 23, 2005 at 09:50:18AM +0100, Simon Marlow wrote: >> On 23 September 2005 08:45, Johannes Waldmann wrote: >> >>>> Another way to look at both issues is that if ghc can figure out >>>> other modules and packages itself, the user shouldn't be required >>>> to specify them in a cabal file. ... >>> >>> Definitely. Having the list of modules in the .cabal is unnecessary >>> duplication of information (because it's in the sources already). >>> This is bound to get out-of-sync during development - >>> unless you use some kind of Makefile to generate the .cabal file, >>> which defeats the very purpose of Cabal itself. > > Module dependency calculation would have to be done in the build > environment, not at the source, because the set of modules used may > be system-dependent. And you'd still need to specify exposed-modules. Yes, that's what I had in mind. The calculation of other-modules would happen when .installed-pkg-info is generated. >> I know how to do this using GHC, but I'm not sure about other >> compilers. With GHC, we can generate the dependencies using 'ghc -M' >> and then parse the generated Makefile (a bit of a long way around, >> but I can't think of an easier way). Of course we'd avoid splatting >> an existing Makefile by redirecting the dependencies to a temporary >> file. >> >> How would we do this with nhc98 or Hugs? Perhaps because these >> systems don't actually need to know the value of other-modules we >> can get away with it. Comments? > > Cabal/Hugs needs other-modules to produce a complete package > (if modules are omitted the build succeeds but using it fails). Ah yes, good point. Since we can't do this unversally, perhaps it's not worth doing. Cheers, Simon

2 1