search

mrkkrp / parser-combinators

Lightweight package providing commonly useful parser combinators
Other
52 stars 15 forks source link

Have non-empty combinators return a NonEmpty result #2

Closed recursion-ninja closed 7 years ago

recursion-ninja commented 7 years ago

When constructing the generalized parser combinators for the separate library, it would be nice for "non-empty" combinators to return NonEmpty typed values. Since Data.List.NonEmpty has been moved into base this provides much more type safe code.

Example combinators: endBy1, sepBy1, someTill, sepEndBy1, etc.

I have mixed feelings about some. It is probably more acceptable to re-export the Alternative instance and also some1 from Data.List.NonEmpty. In princliple some should be changed to return a NonEmpty type, but it is glued into a core type in the Haskell language so it's unlikely to be changed any time soon and the corrected function some1 from Data.List.NonEmpty is fine.

Hopefully providing the most "correct" interface should help the library adoption and reuse with other parsers.

mrkkrp commented 7 years ago

I'm not sure about this one. It does make sense, but people may expect those functions to return plain lists, because they are easier to work with. It would be kinda strange to switch these and leave some in its present form. I think when we have some returning NonEmpty (meaning we have consensus about this on base level), we can switch the rest.

The library is designed to be very conventional and familiar to those who have used Parsec/Attoparsec/Megaparsec/Parsers, so I'd rather wait and think twice before introducing such changes.

recursion-ninja commented 7 years ago

I understand the hesitation, however I cringe everytime I have to NE.fromList <$> sepBy1 ... in order to have type-safe results. I don't think NonEmpty is a huge lift for other users, there is (:|) for deconstructing the head in lieu of (:) and you can always call toList in O(1) if you demand less correctness. A much larger lift is tracking down "head of an empty list" errors.

I doubt some will ever return a NonEmpty value, it's just too much pain throughout the ecosystem at this point to outweigh correctness. Too much code has been written with the antiquated Alternative interface. It's the same reason return will never be removed form Monad, even though it's superfluous with pure in it's superclass Applicative. However, things aren't written in stone yet with this library; there's a chance to push the standard more towards correctness and expressibility.

Maybe we can conduct a survey to see if NonEmpty combinator results would be desirable?

mrkkrp commented 7 years ago

Maybe we can conduct a survey to see if NonEmpty combinator results would be desirable?

If you like, you can go ahead with that.

mrkkrp commented 7 years ago

Resolved via #4.