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
I'm parsing a simple programming language with parsy. During parsing, I equip syntax tree nodes with their position in the file using .mark(), but this doesn't capture the filename. Then I encounter an issue when raising errors during runtime, as the reported error location doesn't mention a filename.
A workaround I can see but find extremely inelegant would be to traverse the whole syntax tree after parsing a file to equip all the nodes' locations with the right filename.
Would it make sense to augment .parse() to take an optional filename to thread through the parser? This would allow the filename to be mentioned in ParseErrors, but also via new combinator like .mark_file() for my use case.
The text was updated successfully, but these errors were encountered:
I think this does make sense and would be a good addition.
The optional filename should probably be named 'source' and be documented something like "a string representing the source document e.g. a filename". This allows for other things e.g. URLs.
I haven't thought this through, but perhaps if the source is present, then mark() should automatically add it as a 4th element in the tuple.
Or, we could have mark_source() which would have the new behaviour and leave mark() as it is. This would allow us to return something more useful like a namedtuple so that there are named fields. In this case mark() would be soft deprecated (i.e. no warnings, just docs that suggest using mark_source() instead.
I'm parsing a simple programming language with parsy. During parsing, I equip syntax tree nodes with their position in the file using
.mark()
, but this doesn't capture the filename. Then I encounter an issue when raising errors during runtime, as the reported error location doesn't mention a filename.A workaround I can see but find extremely inelegant would be to traverse the whole syntax tree after parsing a file to equip all the nodes' locations with the right filename.
Would it make sense to augment
.parse()
to take an optional filename to thread through the parser? This would allow the filename to be mentioned in ParseErrors, but also via new combinator like.mark_file()
for my use case.The text was updated successfully, but these errors were encountered: