Applicative and parsec3

[Antoine Latter]

On Fri, Jan 28, 2011 at 10:59 AM, Antoine Latter <aslatter at gmail.com> wrote:
> On Fri, Jan 28, 2011 at 10:52 AM, Edward Kmett <ekmett at gmail.com> 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 <Christian.Maeder at dfki.de>
>> 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>