Agreed that it's less intrusive API.

It's still a side-effect-based design though and as you said, it still requires user to wrap each parser in locate().

Let's wait and learn from a real-life use case first. Questions I'm looking forward to be answered are:
* Does user need the substring image or the indices are enough?
* From user perspective (assuming jparsec can support whatever they want), what's the ideal syntax to attach location information to domain objects?
  * Is it that each domain object declare the location fields and then user code needs to call ```new Foo(value, begin, end, source)``` in the MapN implementations?
      * If so, could we change the MapN interfaces to abstract classes that carry getLocation() method for user to call so that users don't have to wrap all their parsers?
      * Or, maybe add new set of map interfaces like MapWithLocation (bad name) so that lambda will still work in Java 8?
  * Or maybe maintain an extra identity ```Map<Object, Location>``` so that domain object design doesn't have to change?
  * Or maybe user would rather define a custom LocationAware super class, and register an "interceptor" with jparsec that whenever it seems a LocationAware type in any parser result, calls its ```setLocation()``` method? This requires least amount of boilerplate, and isn't intrusive, though it's still side-effect based.