You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently all line and column indexes in PEG.js are 1-based. This is OK if this information is mostly presented to users, but it can inconvenient for machine processing where 0-based indexes would often work better.
The line and column indexes are currently visible on two places:
line and column properties of exceptions thrown on parse errors
line and column variables inside actions and predicates (available if the parser was built with the trackLineAndColumn option)
Indexing should be consistent on both.
For me, the question whether to have 0-based or 1-based reduces to a question whether the "display to users" or "use for computation" use case happens more often. I need to wait for users to adopt 0.7.0 (where position tracking was implemented for the first time) to answer that.
This was split off from #33 where this issue was raised by @paulftw.
The text was updated successfully, but these errors were encountered:
Is it possible to just make this a configurable option?
I would say that, in general, it is easier for a programmer to handle 1-based indices than it is for an end user to handle 0-based indices. So, I think the default of 1 is good, but if someone wanted to override it, that would be nice.
Currently all line and column indexes in PEG.js are 1-based. This is OK if this information is mostly presented to users, but it can inconvenient for machine processing where 0-based indexes would often work better.
The line and column indexes are currently visible on two places:
line
andcolumn
properties of exceptions thrown on parse errorsline
andcolumn
variables inside actions and predicates (available if the parser was built with thetrackLineAndColumn
option)Indexing should be consistent on both.
For me, the question whether to have 0-based or 1-based reduces to a question whether the "display to users" or "use for computation" use case happens more often. I need to wait for users to adopt 0.7.0 (where position tracking was implemented for the first time) to answer that.
This was split off from #33 where this issue was raised by @paulftw.
The text was updated successfully, but these errors were encountered: