- Libraries - Haskell.org

Problem with xhtml 1.5.1.1: html tags are split
by Gwern Branwen 05 Feb '11

05 Feb '11

On Thu, May 13, 2010 at 11:38 AM, Gwern Branwen <gwern0(a)gmail.com> wrote: > On Tue, May 11, 2010 at 3:00 AM, Bjorn Bringert <bjorn(a)bringert.net> wrote: >> I support finding a new maintainer. > > Alright; as the old maintainer, I guess it falls on you to advertise > on -cafe and libraries. Has a request gone out yet? I didn't notice anything (maybe it got lost in all the recent haskell.org downtime), and the current Hackage page of xhtml is still listing Bjorn. Anyway, John MacFarlane has found a workaround which he's implemented in HEAD Pandoc (http://code.google.com/p/pandoc/issues/detail?id=134) from http://groups.google.com/group/pandoc-discuss/browse_frm/thread/915586b5c5e… : > Many people have wanted pandoc to produce "more normal" HTML output, > without nesting, but with line breaks between block elements (where > they aren't semantically significant). Something like this: > > <ul> > <li>a <a href="/foo">link</a></li> > <li>another list item</li> > </ul> > > I've found that I can get this kind of output, even using Text.XHtml's > renderer, by modifying the writer to insert raw newlines after block > elements, and using 'showHtmlFragment' rather than 'prettyHtmlFragment'. This may be useful for other people to know. (There are quite a few users of xhtml: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/xhtml-… ) -- gwern http://www.gwern.net

1 0

Proposal: Change to library proposal process
by Ian Lynagh 02 Feb '11

02 Feb '11

Hi all, The current proposal process requires that both a ticket is created and a mailing list post sent at the start of the proposal. The ticket creation means: * Redundant work is done: The same information is repeated in two places * Some replies end up on the list, while others end up as a ticket comment * Tickets for rejected or abandoned proposals tend to hang around, cluttering up the bug tracker I propose that proposals are instead started by sending a message to the list, and a ticket is only created when and if consensus for the change has been reached. This proposal is orthogonal to the proposal to give some libraries maintainers, so that they no longer use the process. The proposal process would change to: Start: Send a mail to libraries@, with subject beginning "Proposal:", containing details of the change and a proposed deadline (at least 2 weeks time). End: If consensus for the change has been reached, file a ticket in the GHC trac, including: * A link to the start of the thread in the archives * A summary of the discussion * Details of the change, ideally in the form of a patch Suggested deadline: 24 Jan 2011 Thanks Ian

20 36

Re: parsec3 vs parsec-3.x
by Roman Cheplyaka 02 Feb '11

02 Feb '11

* Christian Maeder <Christian.Maeder(a)dfki.de> [2011-01-31 09:34:47+0100] > > Perhaps I missed something. Can someone please explain why do we have to > > have two different third parsecs? Should one of them be deprecated? When > > would a user prefer one to another? > > parsec-2 (and possibly its compatibility layer) may be deprecated or > superseded at some stage. > > > I read the description of parsec3 package on hackage, it tries to give > > some explanation, but still: > > > > 1. It's not clear why "you may want to develop your code using this > > subset of parsec3 modules". What advantage does it give? > > The parsec3 package only ensures that you are not using the > compatibility layer for parsec2 given by the modules > Text.ParserCombinators.Parsec*, because parsec3 code developed with > these modules might not work with parsec2 or parsec-2.x. >From the description of parsec3 on hackage [...] I do not recommend to unconditionally use parsec3 as dependency in cabal files of packages for hackage. But you may want to develop your code using this subset of parsec3 modules and finally change the dependency from parsec3 to parsec-3.1.1 [...] I got an impression that parsec3 should be used only during the development, not in a released package. But as a developer of a package I have pretty good understanding of what modules I'm using, and if in doubt I can simply run "grep -r Text.ParserCombinators.Parsec ." Maybe it would become more clear if you elaborate on who and how exactly might benefit from this package? Thanks, Roman -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often. In-Reply-To: <4D467427.1000104(a)dfki.de>

3 7

Applicative and parsec3
by Kazu Yamamoto 31 Jan '11

31 Jan '11

Hello, I'm using parsec3 with the applicative style. Since the functions in Control.Applicative and parsec3 conflicts, I need to use the "hiding" keyword as follows: import Control.Applicative hiding (many,optional,(<|>)) import Text.Parsec This is inconvenient for me. I would like to use them as follows: import Control.Applicative import Text.Parsec Christian, the maintainer of parsec3, told me that it is possible to use the functions of Control.Applicative in parsec3 instead of implementing its own functions. But (<|>) of parsec3 is "infixr 1" while that of Control.Applicative is "infixl 3". This may be an issue. Any ideas to solve this issue? --Kazu

8 15

Proposal: Applicative => Monad: Call for consensus
by John Smith 28 Jan '11

28 Jan '11

The patches attached to http://hackage.haskell.org/trac/ghc/ticket/4834 make Applicative a superclass of Monad. Default definitions are provided for backwards compatibility. Advantages: The class hierarchy correctly models the logical relationship between Applicative and Monad. Boilerplate Applicative instances that duplicate Monad functions will no longer be required. Disadvantage: All Monads will be Applicatives, even if you're only interested in the Monad interface. This is akin to all Ords being Eqs, even if you're not using ==. Backwards Compatibility: Existing Monad definitions will have to be changed to declare Applicative. The original function bodies can be used unchanged, but they are now declared in a different class. Calling code should work unchanged. This ticket has already been discussed on the mailing lists. The purpose of this message is to call for consensus by the deadline of 1 February. Please note that although the ticket references the wiki page at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal, the patches attached to the ticket are much more conservative than the more ambitious reforms on the wiki. (I would like to change the ticket description to make this clearer, but I can't edit it.)

29 104

Use explicit language extensions in base
by Bas van Dijk 27 Jan '11

27 Jan '11

Hello, I just wrote a patch that removes the extension fields from base.cabal and adds LANGUAGE pragmas where needed: http://hackage.haskell.org/trac/ghc/ticket/4925 This has the advantage that modules become more modular (since they don't need to depend on external make or cabal files which specify how to build them). For the record: this is not a library proposal. It's just an internal patch for base. It would be great if someone could review and apply it. Regards, Bas

2 1

Proposal: Add missing Foldable/Traversable instances for Prelude types
by Edward Kmett 27 Jan '11

27 Jan '11

I'd like to propose adding the following missing instances to Data.Foldable and Data.Traversable respectively, since there isn't a canonical location that they could be added outside of those packages without orphans, their definition is unambiguous, and they are quite useful (plus, I happen to need them for a monad transformer in my adjunctions package). instance Foldable (Either a) where foldMap f (Left a) = mempty foldMap f (Right b) = f b instance Foldable ((,)e) where foldMap f ea = f (snd ea) instance Traversable (Either a) where traverse f (Left a) = pure (Left a) traverse f (Right a) = Right <$> f a instance Traversable ((,)e) where traverse f ~(e,a) = (,) e <$> f a Discussion period: 2 weeks -Edward Kmett

8 9

transformers
by Edward Kmett 27 Jan '11

27 Jan '11

Do changes to the 'transformers' package fall under the purview of the libraries change control process? -Edward

4 7

question about cabal
by Kathleen Fisher 26 Jan '11

26 Jan '11

Hi all, I have another question about cabal. (Thanks for the information about whether cabal supports two cabal files in one directory). I have a library pads-haskell with a cabal file pads-haskell.cabal. If I ask to install this library from the current directory: > ~/.cabal/bin/cabal install -w ~/sw/ghc-7.01/bin/ghc --package-db=/Users/kfisher/sw/ghc-7.01/lib/ghc-7.0.1/package.conf.d I get the following error messages: > Resolving dependencies... > cabal: cannot configure mainland-pretty-0.1.0.1. It requires containers >=0.2 > && <0.4 > For the dependency on containers >=0.2 && <0.4 there are these packages: > containers-0.2.0.0, containers-0.2.0.1 and containers-0.3.0.0. However none of > them are available. > containers-0.2.0.0 was excluded because regex-posix-0.94.4 requires containers > ==0.4.0.0 > containers-0.2.0.0 was excluded because regex-base-0.93.2 requires containers > ==0.4.0.0 > containers-0.2.0.0 was excluded because containers-0.4.0.0 was selected > instead > containers-0.2.0.0 was excluded because regex-bytestring-0.0.1 requires > containers ==0.4.0.0 > containers-0.2.0.1 was excluded because regex-posix-0.94.4 requires containers > ==0.4.0.0 > containers-0.2.0.1 was excluded because regex-base-0.93.2 requires containers > ==0.4.0.0 > containers-0.2.0.1 was excluded because containers-0.4.0.0 was selected > instead > containers-0.2.0.1 was excluded because regex-bytestring-0.0.1 requires > containers ==0.4.0.0 > containers-0.3.0.0 was excluded because regex-posix-0.94.4 requires containers > ==0.4.0.0 > containers-0.3.0.0 was excluded because regex-base-0.93.2 requires containers > ==0.4.0.0 > containers-0.3.0.0 was excluded because containers-0.4.0.0 was selected > instead > containers-0.3.0.0 was excluded because regex-bytestring-0.0.1 requires > containers ==0.4.0.0 (even though mainland-pretty-0.1.0.1 is already installed: > /Users/kfisher/sw/ghc-7.01/lib/ghc-7.0.1/package.conf.d: > Cabal-1.10.0.0 > ... > mainland-pretty-0.1.0.1 ) That's question number one: why is it trying to configure a library that is already installed? If instead of asking cabal to install the library, I compile Setup and then do a configure, build, and register in place: > >./Setup configure -w ~/sw/ghc-7.01/bin/ghc --with-haddock=/Users/kfisher/ghc-head/bin/haddock --package-db=/Users/kfisher/sw/ghc-7.01/lib/ghc-7.0.1/package.conf.d > >./Setup build > >./Setup register --inplace Everything works just fine. That's the second question: why does cabal install not work while breaking it into pieces does work? I've run into this in working with other libraries on Hackage, but have never understood why sometimes I had to do the installation by hand. Can someone help me understand what is going on here with cabal and how to fix it so that cabal install will work for my library? If this is already documented somewhere that I missed, please just point me to the relevant documentation Thanks! Kathleen

2 1

Proposal: Add Applicative/Alternative instances to Text.Read.ReadPrec
by Edward Kmett 24 Jan '11

24 Jan '11

I propose adding the missing Applicative/Alternative instances to Text.Read.ReadPrec, as I've wanted to use them now on more than one occasion when manually building Read instances. Discussion Period: 2 weeks

2 1