Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

position assumes parsing text from a file #24

Open
bwo opened this issue Jan 2, 2013 · 2 comments
Open

position assumes parsing text from a file #24

bwo opened this issue Jan 2, 2013 · 2 comments

Comments

@bwo
Copy link

bwo commented Jan 2, 2013

line number, column number etc. are hardcoded, and (what's worse) converted to strings early on in the process, losing structure. However, the parsing combinators themselves are agnostic as to whether they are parsing strings or some other structured data.

@youngnh
Copy link
Owner

youngnh commented Jan 3, 2013

Indeed.
And if we wanted to make Parsatron more flexible, here's the places that I can see that would need some generification:

Instead of a SourcePosition, the current record could probably be renamed to something more specific. Maybe FileSourcePosition or CharacterStreamSourcePosition or something. At the same time, a new, less specific Protocol/record/type/idea would need to be created that the parsers can generically manipulate. A Position, let's say.

The token parser calls inc-sourcepos on a position. Right now that function expects a SourcePosition record and a character, but it should probably become a generic function taking some generic Position object/record/type and a "token" consumed from the stream. How individual Position implementations want to update themselves would be up to them, the current inc-sourcepos body would become the implementation for the character stream implementation of Position.

Similarly, the ParseError record expects a SourcePosition and pulls out fields from that record to construct an error message. Anything wanting to call itself a Position would have to implement some function to construct from itself, a user-readable string that gives some indication of where in the input the error occurred.

Finally, a Position would need a method that returns an "initial" Position. For a character stream, that's currently a SourcePosition at line 1 column 1, others implementations would do something similar. With that in place, the run function could construct the right initial Position object to be passed around for the rest of the parsers to use.

Thoughts?

@bwo
Copy link
Author

bwo commented Jan 3, 2013

Those were about the thoughts I had---I have a branch logical-lines that implements some of this (and some other stuff---it's not super organized) but it's not in quite the state I'd like yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants