headers
Christian Maeder | 1 Feb 2011 15:03
Picon
Favicon

Re: parsec3 vs parsec-3.x

Am 31.01.2011 22:28, schrieb Roman Cheplyaka:
> 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?

I agree, parsec3 is of limited use. It only ensures a disjoint module
name space with parsec2 xor parsec1 for old or more portable code.

So you could have parsec2 and parsec3 code without being forced to
compile your parsec-2.x sources via the compatibility layer of parsec-3.x.

C.

> 
> Thanks,
> Roman
>
Permalink | Reply | 6 comments |
headers
Roman Cheplyaka | 1 Feb 2011 21:29
Gravatar

Re: parsec3 vs parsec-3.x

* Christian Maeder <Christian.Maeder <at> dfki.de> [2011-02-01 15:03:41+0100]
> Am 31.01.2011 22:28, schrieb Roman Cheplyaka:
> > 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?
> 
> I agree, parsec3 is of limited use. It only ensures a disjoint module
> name space with parsec2 xor parsec1 for old or more portable code.

Please don't get me wrong, I am not claiming that it's useless, rather
genuinely trying to understand what problem it solves.

> So you could have parsec2 and parsec3 code without being forced to
> compile your parsec-2.x sources via the compatibility layer of parsec-3.x.

You mean using Parsec 2 and Parsec 3 interfaces in one package?

But why would anyone want to develop a package with one implementation
(Parsec 2) and release it depending on another implementation (Parsec 3
(Continue reading)

Permalink | Reply | 5 comments |
headers
Christian Maeder | 2 Feb 2011 09:07
Picon
Favicon

Re: parsec3 vs parsec-3.x

Am 01.02.2011 21:29, schrieb Roman Cheplyaka:
> * Christian Maeder <Christian.Maeder <at> dfki.de> [2011-02-01 15:03:41+0100]
>> Am 31.01.2011 22:28, schrieb Roman Cheplyaka:
>>> 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?
>>
>> I agree, parsec3 is of limited use. It only ensures a disjoint module
>> name space with parsec2 xor parsec1 for old or more portable code.
> 
> Please don't get me wrong, I am not claiming that it's useless, rather
> genuinely trying to understand what problem it solves.
> 
>> So you could have parsec2 and parsec3 code without being forced to
>> compile your parsec-2.x sources via the compatibility layer of parsec-3.x.
> 
> You mean using Parsec 2 and Parsec 3 interfaces in one package?

No, the parsec-3.x packages contains already both interfaces, but with a
(Continue reading)

Permalink | Reply | 4 comments |
headers
Antoine Latter | 2 Feb 2011 16:27
Picon
Gravatar

Re: parsec3 vs parsec-3.x

On Wed, Feb 2, 2011 at 2:07 AM, Christian Maeder
<Christian.Maeder <at> dfki.de> wrote:
> Am 01.02.2011 21:29, schrieb Roman Cheplyaka:
>> * Christian Maeder <Christian.Maeder <at> dfki.de> [2011-02-01 15:03:41+0100]
>>> Am 31.01.2011 22:28, schrieb Roman Cheplyaka:
>>>> 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?
>>>
>>> I agree, parsec3 is of limited use. It only ensures a disjoint module
>>> name space with parsec2 xor parsec1 for old or more portable code.
>>
>> Please don't get me wrong, I am not claiming that it's useless, rather
>> genuinely trying to understand what problem it solves.
>>
>>> So you could have parsec2 and parsec3 code without being forced to
>>> compile your parsec-2.x sources via the compatibility layer of parsec-3.x.
>>
>> You mean using Parsec 2 and Parsec 3 interfaces in one package?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Maeder | 2 Feb 2011 17:16
Picon
Favicon

Re: parsec3 vs parsec-3.x

Am 02.02.2011 16:27, schrieb Antoine Latter:
> What do you mean by 'different implementation'? The parsec-3
> compatibility layer simply re-exports the Text.Parsec.* functions and
> types in a different module hierarchy. Maybe I missunderstood what you
> mean.

I mean the two implementations: original parsec-2 code and the
compatibility layer of parsec-3

> I think I'm just really confused - under what scenario I would prefer
> using the 'parsec3' package to the 'parsec' package.

In the case, where you want your old parsec-2 code to (continue to) use
the original implementation and your new code to use the parsec3
implementation (in one project).

[...]
>> The main problem is that the parsec-3.x package is not split up into two
>> packages, which would allow to install the compatibility layer
>> separately if needed.
> 
> For those interested in the history behind this - the concern at the
> time was that many modules specified 'parsec' as a dependency without
> an upper-bound on which version they needed. Since we didn't want
> those to break, we re-exported the new modules under the old names.

It would have been perfect if parsec-3.x had just supplied the
Text.ParserCombinators.Parsec modules on top of a separate parsec3 package.

But now there are many packages on hackage that expect Text.Parsec
(Continue reading)

Permalink | Reply | 2 comments |
headers
Antoine Latter | 2 Feb 2011 17:31
Picon
Gravatar

Re: parsec3 vs parsec-3.x

On Wed, Feb 2, 2011 at 10:16 AM, Christian Maeder
<Christian.Maeder <at> dfki.de> wrote:
> Am 02.02.2011 16:27, schrieb Antoine Latter:
>> What do you mean by 'different implementation'? The parsec-3
>> compatibility layer simply re-exports the Text.Parsec.* functions and
>> types in a different module hierarchy. Maybe I missunderstood what you
>> mean.
>
> I mean the two implementations: original parsec-2 code and the
> compatibility layer of parsec-3
>
>> I think I'm just really confused - under what scenario I would prefer
>> using the 'parsec3' package to the 'parsec' package.
>
> In the case, where you want your old parsec-2 code to (continue to) use
> the original implementation and your new code to use the parsec3
> implementation (in one project).
>

Ah! So you want two implementations of a 'parsec' style parser in a
single package, then?

I've never found myself wanting to do that, but I can see how you
would end up with a smaller testing/upgrade overhead.

Antoine
Permalink | Reply | 1 comment |
headers
Christian Maeder | 2 Feb 2011 17:51
Picon
Favicon

Re: parsec3 vs parsec-3.x

Am 02.02.2011 17:31, schrieb Antoine Latter:
> On Wed, Feb 2, 2011 at 10:16 AM, Christian Maeder
> <Christian.Maeder <at> dfki.de> wrote:
>> Am 02.02.2011 16:27, schrieb Antoine Latter:
>>> What do you mean by 'different implementation'? The parsec-3
>>> compatibility layer simply re-exports the Text.Parsec.* functions and
>>> types in a different module hierarchy. Maybe I missunderstood what you
>>> mean.
>>
>> I mean the two implementations: original parsec-2 code and the
>> compatibility layer of parsec-3
>>
>>> I think I'm just really confused - under what scenario I would prefer
>>> using the 'parsec3' package to the 'parsec' package.
>>
>> In the case, where you want your old parsec-2 code to (continue to) use
>> the original implementation and your new code to use the parsec3
>> implementation (in one project).
>>
> 
> Ah! So you want two implementations of a 'parsec' style parser in a
> single package, then?

Well, yes, where my "single package" is for a large binary and the
source pool allows to create separate special-purpose binaries.

C.

> 
> I've never found myself wanting to do that, but I can see how you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Lynagh | 3 Feb 2011 00:24
Picon
Gravatar

Re: Proposal: Change to library proposal process

On Mon, Dec 27, 2010 at 01:36:43PM +0000, Ian Lynagh wrote:
> 
> 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.

There was some discussion, mostly about where to put the patches, but I
believe ultimately consensus for making this change (with patches being
sent to the list). I've updated
    http://www.haskell.org/haskellwiki/Library_submissions
accordingly.

There is also discussion going on about more radical changes, which
more-or-less mean stopping some or all packages being covered by the
process, but I believe that that is an orthogonal issue.

Thanks
Ian
Permalink | Reply | 0 comments |
headers
John Smith | 3 Feb 2011 14:43
Picon
Favicon

Proposal: Applicative => Monad: Is there any consensus?

There has been much discussion on this proposal, much of it orthogonal to the actual patch. The discussion
deadline has 
passed, but it is difficult to gauge whether consensus has been reached or not. Can we have a final yay or nay?

The patch is attached to http://hackage.haskell.org/trac/ghc/ticket/4834
Permalink | Reply | 27 comments |
headers
Stephen Tetley | 3 Feb 2011 14:54
Picon

Re: Proposal: Applicative => Monad: Is there any consensus?

I'd contend the proposal is too disruptive to be independent of a
language revision, so I'd vote no on the proposal as it stands.
Permalink | Reply | 25 comments |

Gmane