#152: Proposal: Add transformers and revise the mtl package to depend on it
--+-
Reporter: ross |Owner: dons
Type: enhancement | Status: new
Priority: major
#152: Proposal: Add transformers and revise the mtl package to depend on it
--+-
Reporter: ross |Owner: dons
Type: enhancement | Status: new
Priority: major
#145: Proposal: Add Package: text
--+-
Reporter: dons |Owner: dons
Type: defect| Status: new
Priority: major |Milestone: 2011.x.0.0
Component: Pa
#145: Proposal: Add Package: text
--+-
Reporter: dons |Owner: dons
Type: defect| Status: new
Priority: major |Milestone: 2011.x.0.0
Component: Pa
#145: Proposal: Add Package: text
--+-
Reporter: dons |Owner: dons
Type: enhancement | Status: new
Priority: major |Milestone: 2011.x.0.0
Component: Pa
#145: Proposal: Add Package: text
--+-
Reporter: dons |Owner: dons
Type: enhancement | Status: new
Priority: major |Milestone: 2011.x.0.0
Component: Pa
#145: Proposal: Add Package: text
--+-
Reporter: dons |Owner: dons
Type: enhancement | Status: new
Priority: major |Milestone: 2011.x.0.0
Component: Pa
Hey all,
This is a loose end in the package policy situation: when the HP has a
major upgrade, the policy is to do all major upgrades for any packages
contained in the HP, as long as they don't add new dependencies.
One exception to this rule has been parsec, where parsec 2 was
considered "blesse
On Sat, Nov 6, 2010 at 5:18 PM, Don Stewart wrote:
> Hey all,
>
> This is a loose end in the package policy situation: when the HP has a
> major upgrade, the policy is to do all major upgrades for any packages
> contained in the HP, as long as they don't add new dependencies.
>
> One exception to
I have built a very early candidate for the Haskell Platform 2011 set,
ignoring any active proposals, using GHC 7.
Issues that were raised:
= Haskell Platform packages that have broken the HP policy, by adding new
dependencies that are not part of the Haskell Platform set:
* cgi (kno
I would like to see some changes before it becomes a blessed package.
I'd love to hear your thoughts on the following ideas:
* Get rid of the user state type parameter u. If you want state, set m =
StateT s.
* Text.Parsec.Prim currently exports its own version of <|> specialized
to the ParsecT
On Sat, Nov 6, 2010 at 5:24 PM, Martijn van Steenbergen
wrote:
> I would like to see some changes before it becomes a blessed package. I'd
> love to hear your thoughts on the following ideas:
>
> * Get rid of the user state type parameter u. If you want state, set m =
> StateT s.
I'm not really f
Hello,
For some alternative design choices you might also be interested in
Parsimony (http://hackage.haskell.org/package/parsimony).
It is similar to a trimmed-down Parsec 2, but it supports token
streams other then lists (e.g., it can parse directly from
byte-strings).
Parsers supports user state
On 11/06/10 11:53, Dmitry Astapov wrote:
> One one hand, parsec 3 is more versatile, on the other hand, parsec 2 is
> often faster.
Is this even since parsec 3.1, whose main claim to fame was making
parsec3 performance be comparable to parsec2 performance?
http://www.haskell.org/pipermail/haskel
On Sat, Nov 6, 2010 at 3:11 PM, Antoine Latter wrote:
> Assuming we move the Parsec 'many' implementation into the Alternative
> class definition, this should have no/little impact on performance for
> all the combinators mentioned by Stephen.
I can't speak for Parsec, but I certainly have a loca
15 matches
Mail list logo
