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
-
I was hoping to add a feature to
TokenParsers
that 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.lexical
member was aScanners
object withTokens
mixed in. It doesn't work in general because of the separation ofTokens
fromScanners
(which is whatStdLexical
does).Since the whole point of
TokenParsers
is to read tokens, it seems logical to me thatTokens
should be combined intoScanners
instead of decoupled; after all,Tokens
doesn't provide an interface for accessing tokens, so it can't stand alone. The current design seems to assume that the authors of theTokenParsers
subclass will know howTokenParsers.lexical
is intended to be used, presumably because the same authors will have written it. IncorporatingTokens
intoScanners
and requiringTokenParsers.lexical
to be aScanners
object 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