- Libraries - Haskell.org

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

23 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

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

23 Sep '05

On 22 September 2005 23:02, Andrew Pimlott wrote: > 2. Similar comments apply to build-depends. I wrote a module Foo.hs: > > module Foo (foo) where > import Control.Monad.Identity > foo = runIdentity (return ()) > > and a cabal file (working from an example obviously): > > Name: foo > Version: 1.1 > License: BSD3 > Build-Depends: base > Exposed-modules: > Foo > > This built and installed without error, but when I created another > module that imports Foo and tried to compile it with "ghc > --make", I got undefined references to Control.Monad.Identity. > Eventually, I found that I need to add mtl to build-depends. > Again it would have been better to get an error during package > creation, and this was particulary tricky to figure out because > "build-depends" sounds like it should only affect package at > build-time. This is fixed in newer versions of Cabal when used with newer versions of GHC (6.4.1). Missing dependencies are now reported as build errors, because GHC is invoked with the -hide-all-packages option. Cheers, Simon

1 0

cabal beginner issues (other-modules, build-depends)
by Andrew Pimlott 23 Sep '05

23 Sep '05

Two issues I've encountered while trying out cabal: 1. The use of "other-modules" is a bit confusing. I realize now that other-modules must contain all modules in the source tree used by the exposed modules. However, since the package built and installed without error when I left out this field, I was surprised to get undefined references when I tried to use the package. I guess this happened because ghc --make found the other modules automatically, but cabal didn't. I would rather have the build step fail in this case. Maybe cabal shouldn't be using --make. 2. Similar comments apply to build-depends. I wrote a module Foo.hs: module Foo (foo) where import Control.Monad.Identity foo = runIdentity (return ()) and a cabal file (working from an example obviously): Name: foo Version: 1.1 License: BSD3 Build-Depends: base Exposed-modules: Foo This built and installed without error, but when I created another module that imports Foo and tried to compile it with "ghc --make", I got undefined references to Control.Monad.Identity. Eventually, I found that I need to add mtl to build-depends. Again it would have been better to get an error during package creation, and this was particulary tricky to figure out because "build-depends" sounds like it should only affect package at build-time. 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. (I know there are other compilers than ghc.) I am using Debian ghc6 package 6.4-4.1. Andrew

2 1

Unexpected behaviour in Text.PrettyPrint.HughesPJ
by Anders Höckersten 22 Sep '05

22 Sep '05

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

1 0

HaXml Status
by Dominic Steinitz 20 Sep '05

20 Sep '05

Can anyone clarify this? I need to be able to handle namespaces some I'm using Graham Klyne's version http://www.ninebynine.org/Software/HaskellUtils/20040802-Haxml-1.12.zip. There is a 1.13 version on the HaXml website http://www.cs.york.ac.uk/fp/HaXml. From the words on the website, it doesn't look like 1.13 has incorporated Graham's changes. When I try and build Graham's version with GHC 6.4, I run into problems such as parseUriReference should really be parseURIReference and others (actually that's because of the Haskell HTTP package http://www.haskell.org/http/ rather than GHC). Does 1.13 support namespaces or is my best bet to go through Graham's version and update it so it builds with GHC 6.4 and the latest packages? Thanks, Dominic.

3 2

RE: cabal design
by Simon Marlow 19 Sep '05

19 Sep '05

On 16 September 2005 18:03, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> Ok, I've read through this discussion. Could somebody explain to me >> why this whole "virtualization" thing can't be solved by simply >> adding the flag >> >> --package-db=<file> >> >> to Cabal? It would be another option in the --user/--global family. >> The idea isn't new - I'm sure we've discussed this before. It seems >> to suffer from none of the problems of the other suggestions, but >> perhaps I'm missing something. For Hugs, the <file> would actually >> specify a directory. Additionally, --package-db=<file> is a step on >> the way to other things that we want to do (--in-place). > > The problem I have with --package-db= as a directory for Hugs (and > nhc, and jhc) is that it conflicts with the meaning of the --prefix > flag. That is, if you specify a package database, it changes the > location of the installation, which is not what you might expect. > Also, we'd have to make sure people don't try to use --prefix and > --package-db together in the case of Hugs (unless they're equal). Ah, I has read the section "Hugs Package Database" on the wiki and for some reason my brain had accepted it as The Truth rather than just a proposal. Nevertheless, such a setup is already possible using symbolic links, at least on Unix. I think that assuming a level of indirection between the package database and the actual installed location of the package is not a bad thing - Hugs will catch up. This isn't so bad. To be precise: --package-db works fully for GHC --package-db works fully for Hugs on Unix-like systems, using symbolic links. --package-db will not work on Windows with Hugs, currently. > Another option, since this will only really work for GHC, is to add > --ghc-options and --ghc-pkg-options and people can specifcy the > database they want, and it'll be clear that it's not a portable > option. That's ok, but not as attractive (IMO). Other systems will want to have the same facilities, and we'll end up with users of Cabal having to know the right --<foo>-options flags to pass to Cabal for their compiler. If we standardise on the idea of a package database as a filesystem path, which should be enough for everyone, then we can provide a portable interface. > So for the sake of those who haven't read the wiki page, here's my > --root= proposal. This basically directly implements "virtualization" > in Cabal: > > * For GHC > o --prefix now becomes $(ROOT)/$(PREFIX) > o the ghc-pkg file is stored in $(ROOT)/.whatever > o Cabal adds package-conf related flags to ghc and ghc-pkg to > look at $(ROOT)/.whatever. *this* is the bit I have a problem with. You haven't specified how we figure out the value of ".whatever", and it looks like it should vary depending on the value of $(ROOT), at least for GHC. Also, having both --root and --prefix is quite confusing - I don't think I fully grasp the significance of having both options, and I'm sure it'll confuse users. This just doesn't look as simple as the --package-db flag. We want the ability to specify the package db anyway, and this gives us virtualisation too. Two birds with one stone! Cheers, Simon

1 0

HaXml Status
by Dominic Steinitz 19 Sep '05

19 Sep '05

Malcolm, Thanks. I finally got Graham's version to build by: ./configure and then using the following Setup.hs and HaXml.cabal files. I haven't tried with Hugs or nhc. I had to modify a few bits of code on the way (e.g. changing parseUriReference to parseURIReference) but I assume that these will be fixed by the fact you are merging the two versions? Otherwise let me know and I will attempt to provide patches. Dominic. PS I may to expose a few more modules as I go along. [dom@tility HaXml]$ more Setup.hs import Distribution.Simple main = defaultMain [dom@tility HaXml]$ more HaXml.cabal name: HaXml version: 1.12 license: LGPL license-file: COPYRIGHT author: Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> homepage: http://www.cs.york.ac.uk/fp/HaXml/ category: Text synopsis: Utilities for manipulating XML documents description: Haskell utilities for parsing, filtering, transforming and generating XML documents. exposed-modules: Text.ParserCombinators.HuttonMeijerWallace, Text.ParserCombinators.Token, Text.XML.HaXml, Text.XML.HaXml.Combinators, Text.XML.HaXml.DtdToHaskell.Convert, Text.XML.HaXml.DtdToHaskell.Instance, Text.XML.HaXml.DtdToHaskell.TypeDef, Text.XML.HaXml.EntityHelpers, Text.XML.HaXml.Escape, Text.XML.HaXml.ExtEntity, Text.XML.HaXml.Haskell2Xml, Text.XML.HaXml.Html.Generate, Text.XML.HaXml.Html.Parse, Text.XML.HaXml.Html.Pretty, Text.XML.HaXml.Lex, Text.XML.HaXml.OneOfN, Text.XML.HaXml.Parse, Text.XML.HaXml.Pretty, Text.XML.HaXml.QName, Text.XML.HaXml.SubstitutePE, Text.XML.HaXml.Types, Text.XML.HaXml.Unicode, Text.XML.HaXml.Validate, Text.XML.HaXml.Verbatim, Text.XML.HaXml.Wrappers, Text.XML.HaXml.Xml2Haskell, Text.XML.HaXml.XParserUtils, Text.XML.HaXml.Xtract.Combinators, Text.XML.HaXml.Xtract.Lex, Text.XML.HaXml.Xtract.Parse hs-source-dirs: obj/ghc build-depends: base, haskell98, mtl, HTTP extensions: CPP ghc-options: -fglasgow-exts

1 0