-
Notifications
You must be signed in to change notification settings - Fork 23
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
Comments
Indeed. 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 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 Thoughts? |
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. |
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.
The text was updated successfully, but these errors were encountered: