2011/1/27 Henning Thielemann :

On Thu, 27 Jan 2011, Kazu Yamamoto (山本和彦) wrote:

...

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

There are several reasons to stick to explicit or qualified imports:  http://www.haskell.org/haskellwiki/Import_modules_properly

What that article fails to mention is the inconvenience of using qualified imports in combination with operators. /M -- Magnus Therning                      OpenPGP: 0xAB4DFBA4 email: magnus@therning.org   jabber: magnus@therning.org twitter: magthe               http://therning.org/magnus

On Thu, Jan 27, 2011 at 4:29 AM, Christian Maeder wrote:

Am 27.01.2011 07:16, schrieb Kazu Yamamoto (山本和彦):

...

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

Another problem:

Control.Applicative.optional corresponds to Text.Parsec.Combinator.optionMaybe whereas Text.Parsec.Combinator.optional returns "()".

...

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?

If we are lucky removing the "infixr 1 <|>" operator does not break too much existing code, because the combination with "infixl 1 >>" needs always brackets, currently. (But a changed interpretation might be hard to notice.)

However, using "a >> b <|> c" would then no longer be an error and interpreted as "a >> (b <|> c)", whereas  "a *> b <|> c" would be "(a *> b) <|> c".

I think the change would be worth it, even if painful for existing users. I'm less sure how to go forward for the different "optional" combinators. I would want to port over 'many' to be the one exported from Applicative as well. Antoine

Christian

...

--Kazu

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

While you're hacking around on parsec a nice improvement would be to relax the type on the language generators in Text.ParserCombinators.Parsec.Language. (This one could be done without so drastic a change as bumping from 3 to 4): They can all be instantiated for Monad m => GenLanguageDef String s m instead of LanguageDef, this would greatly extend their usability. You could even go a little farther and relax them so they can work over Bytestrings, etc. I for one always feel a little twinge when I'm forced to copy and paste them and change the signature just because I'm working in a parser that provides state, uses _any_ base monad, or consumes some other Char source. -Edward Kmett On Fri, Jan 28, 2011 at 8:57 AM, Christian Maeder wrote:

Am 27.01.2011 07:16, schrieb Kazu Yamamoto (山本和彦):

...

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?

If parsec is not changed I could create a parsec4 package where the conflicting functions are removed from Text.Parsec.

This will break code that uses "optional" from Text.Parsec. Is there a need for a renaming of Text.Parsec.Combinator.optional, like "voidOptional"?

Such a function would be better placed inside Control.Applicative though:

voidOptional v = const () <$> v <|> pure ()

or

voidOptional = void . optional

using the new Control.Monad.void.

C.

...

--Kazu

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Fri, Jan 28, 2011 at 10:59 AM, Antoine Latter wrote:

On Fri, Jan 28, 2011 at 10:52 AM, Edward Kmett wrote:

...

While you're hacking around on parsec a nice improvement would be to relax the type on the language generators in Text.ParserCombinators.Parsec.Language. (This one could be done without so drastic a change as bumping from 3 to 4): They can all be instantiated for Monad m => GenLanguageDef String s m instead of LanguageDef, this would greatly extend their usability. You could even go a little farther and relax them so they can work over Bytestrings, etc. I for one always feel a little twinge when I'm forced to copy and paste them and change the signature just because I'm working in a parser that provides state, uses _any_ base monad, or consumes some other Char source. -Edward Kmett

I'd be happy to apply a patch for this.

To be more clear, to the 'parsec' package. I think Christian would have to do it for the new 'parsec3' package. Antoine

...

On Fri, Jan 28, 2011 at 8:57 AM, Christian Maeder wrote:

...

Am 27.01.2011 07:16, schrieb Kazu Yamamoto (山本和彦):

...

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?

If parsec is not changed I could create a parsec4 package where the conflicting functions are removed from Text.Parsec.

This will break code that uses "optional" from Text.Parsec. Is there a need for a renaming of Text.Parsec.Combinator.optional, like "voidOptional"?

Such a function would be better placed inside Control.Applicative though:

 voidOptional v = const () <$> v <|> pure ()

or

 voidOptional = void . optional

using the new Control.Monad.void.

C.

...

--Kazu

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Am 29.01.2011 09:29, schrieb Roman Cheplyaka:

* Antoine Latter [2011-01-28 11:00:56-0600]

...

...

I'd be happy to apply a patch for this.

To be more clear, to the 'parsec' package. I think Christian would have to do it for the new 'parsec3' package.

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.

2. If the packages are supposed to be compatible (as follows from the above quote), the fact that they have different maintainers (and different code repositories, I suppose) does not help.

(I've got not code repository for parsec3) HTH Christian

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/28/11 12:45 , Christian Maeder wrote:

I would rather see separate helper functions for lexing and comment skipping than having them bundled as TokenParser or LanguageDef.

Do we have a reasonable alternative to them, considering that the idea was to work around Haskell's lack of parameterized modules? (And from my POV they look like helper functions already.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1E9EMACgkQIn7hlCsL25XvsQCbBOz5CavxlWAPEP29CBgtqX97 A4YAn08LHO/kiSVdBYuN2uJKeocbjSha =YTGe -----END PGP SIGNATURE-----