Coupling of Tokens and Scanners
#462
Unanswered
peteraldous
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I was hoping to add a feature to
TokenParsersthat allows users to provide a string that represents a single token and get a parser that recognizes that token (this sort of interaction comes essentially for free in a scannerless parser); however, I was only able to make it work in my own code because myTokenParsers.lexicalmember was aScannersobject withTokensmixed in. It doesn't work in general because of the separation ofTokensfromScanners(which is whatStdLexicaldoes).Since the whole point of
TokenParsersis to read tokens, it seems logical to me thatTokensshould be combined intoScannersinstead of decoupled; after all,Tokensdoesn't provide an interface for accessing tokens, so it can't stand alone. The current design seems to assume that the authors of theTokenParserssubclass will know howTokenParsers.lexicalis intended to be used, presumably because the same authors will have written it. IncorporatingTokensintoScannersand requiringTokenParsers.lexicalto be aScannersobject would provide a defined interface that would allow for features like the one I described above.I'm guessing, however, that this has been considered and that the authors of this library decoupled the two classes for a reason. If you're willing, I would love to better understand the rationale behind this design choice.
(My agenda here is that I would like for this library to be a viable option for my undergraduate compilers students. A few improvements, mostly to documentation, will suffice. I'm happy to contribute code and docs, but I want to make sure I understand before I write much of either.)
Beta Was this translation helpful? Give feedback.
All reactions