#16009: Deprecate `optional` from Text.ParserCombinators.ReadP -------------------------------------+------------------------------------- Reporter: dbaynard | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | Keywords: Applicative, | Operating System: Unknown/Multiple Parsers, ReadP | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems there is some disagreement on what the type of `optional` should be, within `base`. `Control.Applicative` defines it as {{{#!haskell optional :: Alternative f => f a -> f (Maybe a) }}} By contrast, `Text.ParserCombinators.ReadP` defines it as {{{#!haskell optional :: ReadP a -> ReadP () }}} Worse, ReadP implements `Alternative`. So it entirely possible to specialise {{{#!haskell optional :: ReadP a -> ReadP (Maybe a). }}} In the broader Haskell ecosystem (and beyond) there is further confusion. The `Applicative` definition is used by `parsers`, `megaparsec` and purescript's `Data.Maybe`. The `ReadP` definition is used by `Parsec` and purescript's `Text.Parsing.StringParser`. `Cabal`, like `base` defines both. I propose to begin to deprecate `ReadP.optional` ASAP, following suggestions in https://www.reddit.com/r/haskell/comments/8cqgds/inconsistent_optional_defin.... Code which used the old form may still compile; otherwise `void` should be applied. There have been some suggestions for new names for the `ReadP` definition, such as `optionally` or `optional_`. It may be worth exporting this function directly from `Control.Applicative`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16009 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler