I meant to give the interceptor idea a try but didn't manage to get free time over the week end.

If it's implementable, I like it better because it's not restricted to source location. It can be used probably to do other cool things that apply to not only one or two single parsers but to *all* parsers.

locate() is not bad, but it's already doable without a core framework change:

Parser<LocationAware<T>> locate(Parser parser) {
  return sequence(INDEX, parser, INDEX).map(…);
}

And it doesn't require unchecked casting.

The main issue with this kind of combinator is that locate() call will proliferate in user's code base. Adding a core combinator doesn't address this issue.


On Jun 27, 2013, at 2:19 PM, Xikilze <notifications@github.com> wrote:

> In src/main/java/org/codehaus/jparsec/LocatableParser2.java:
> 
> > +	  private final Parser<T> parser;
> > +	  private LocatableHandler<U> handler;
> > +
> > +	  public LocatableParser2(Parser<T> parser, LocatableHandler<U> handler) {
> > +	    this.parser = parser;
> > +	    this.handler = handler;
> > +	  }
> > +
> > +	  @SuppressWarnings("unchecked")
> > +	  @Override boolean apply(ParseContext ctxt) {
> > +	    int begin = ctxt.getIndex();
> > +	    if (!parser.apply(ctxt)) {
> > +	      return false;
> > +	    }
> > +
> > +	    handler.handle((U) ctxt.result, ctxt.source.subSequence(begin, ctxt.getIndex()).toString(), begin, ctxt.getIndex());
> I say it is can be more difficult in the sense I don't know if it is as simple as invoking an interceptor in Parser.run. abailly's solution (which is very similar to the one I implemented some time ago, that's why I submitted the little patch) has the advantage of not being intrusive with the existing codebase : combinating a new parser, isn't it the nature of JParsec ?
> 
> If you fell you can easily implement a far more elegant solution, then submit your patch...
> 
> —
> Reply to this email directly or view it on GitHub.
>