[Haskell-cafe] Does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus?
compl.yue at icloud.com
Sun Oct 25 23:28:49 UTC 2020
Regarding the Alternative instance of ParsecT from Megaparsec here: https://github.com/mrkkrp/megaparsec/blob/ccf314b0b940bdbfec3820b18f42d241e6920b61/Text/Megaparsec/Internal.hs#L202-L205 (https://link.getmailspring.com/link/34AABC73-FAC8-4126-8356-62E7FE0DA273@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fmrkkrp%2Fmegaparsec%2Fblob%2Fccf314b0b940bdbfec3820b18f42d241e6920b61%2FText%2FMegaparsec%2FInternal.hs%23L202-L205&recipient=aGFza2VsbC1jYWZlQGhhc2tlbGwub3Jn)
-- | 'empty' is a parser that __fails__ without consuming input.
instance (Ord e, Stream s) => Alternative (ParsecT e s m) where
empty = mzero
(<|>) = mplus
I come to this question, does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus?
First of all, can I somehow regard Alternative as a repurposed Monoid? So this question applies similarly to Monoid as well?
Then I think the lack of failure semantic in Alternative/Monoid might have two different interpretations:
1) It must NOT fail
2) Whether it can fail or not is not cared
Which one is correct? I feel 1) is in spirit of purism, that pure code should not fail, but it's a monad, then 2) may in monad's spirit to be effectful and composable with other effects including failing.
I'd think it violates the law when interpretation 1) is taken.
Background about my confusion: https://github.com/mrkkrp/megaparsec/issues/429#issuecomment-716170935 (https://link.getmailspring.com/link/34AABC73-FAC8-4126-8356-62E7FE0DA273@getmailspring.com/1?redirect=https%3A%2F%2Fgithub.com%2Fmrkkrp%2Fmegaparsec%2Fissues%2F429%23issuecomment-716170935&recipient=aGFza2VsbC1jYWZlQGhhc2tlbGwub3Jn)
The parsing of whitespaces is so handled in Megaparsec's idiom that every lexeme should consume (discard) all whitespaces following it. But after tinkered around with some related issues, I by now would think a silent, joinable empty / mempty might be more sense making for each whitespace block to be parsed individually, i.e. without association with any lexeme while neither will fail the overall parsing.
The demand comes in that I'd like the doc comment parser to evaulate to empty and contribute nothing to an enclosing many , in case all following it is whtespaces till eof; while in case it's followed by some artifact definition, the doc comment parser should evaluate to a syntactic doc node assoicated with that artifact. empty seems an ideal device for that purpose, but in the fact it is implemented with mzero, the overall parsing will fail, which makes it infeasible.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe