Missing utilities

[spookylukey]

There are probably a few missing pieces in terms of building parsers. Some of the following from Parsec/Parsimmon:

• notFollowedBy
  • https://hackage.haskell.org/package/parsec-3.1.11/docs/Text-Parsec-Combinator.html#v:notFollowedBy
  • https://github.com/jneen/parsimmon/blob/master/src/parsimmon.js#L634
• manyTill
  • https://hackage.haskell.org/package/parsec-3.1.11/docs/Text-Parsec-Combinator.html#v:manyTill
• lookAhead
  • https://hackage.haskell.org/package/parsec-3.1.11/docs/Text-Parsec-Combinator.html#v:lookAhead
  • https://github.com/jneen/parsimmon/blob/master/src/parsimmon.js#L618

It would be good to be able to easily express "discard everything until ..." or "collect everything until ..." which doesn't seem to be easy at the moment, but would be easier with the above utilities.

[tungd]

Hi, just wonder if there is anyone working on this? I've just finished one project using Parsy and willing to contribute.

[spookylukey]

I'm not working on this, contributions would be welcome. notFollowedBy is already implemented in the form of should_fail.

[lisael]

I've just sent a PR implementing the lookAhead #29

[lisael]

And here's a proposal for manyTill : #31

[lisael]

I've got a concern about my implementation of lookAhead. peek is a function rather than a method on Parser. It's something I find confusing when I'm working with Parsy: Is stuff a method or a function that takes a parser?

I did make a function, because it's how I implemented this as a helper function in a project of mine, no other reason.

Is there a rule of thumb for this dilemma, method or function?

Note that peek(p) is the exact equivalent of p.should_fail().should_fail() (and we should benchmark this to decide wich implementation is better). Maybe it makes sense to make it a method on Parser.

Same question for #31.

[spookylukey]

@lisael - yes, it is a bit hard to decide in some cases.

I think many_until makes more sense as a method, because it is similar to other things like many, and peek for a similar argument comparing to should_fail. I guess it's about a consistent fluent API.

For things that don't take a parser as an argument, or can take more than one, we use functions. I think that's a good rule of thumb.