-
Notifications
You must be signed in to change notification settings - Fork 67
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
Add type transform #85
Conversation
5456cf6
to
40dee4a
Compare
I've rewritten this on top of the latest master.
|
82acf8d
to
8c3e622
Compare
40dee4a
to
d233dd6
Compare
d233dd6
to
24b23ca
Compare
A few notes about the example and case insensitivity.
For (1,2) above, perhaps I misunderstood the example in this issue, feel free to enlighten me. |
I think you misunderstood the example; (1) and (2) don't sound right to me.
It then returns a closure which calls |
We recently added a
value
transform.This PR:
type
transform.moo.keywords()
.Lexer#has()
.The existing value transform takes the
text
and returns thevalue
. By default, the text is used unchanged.The new type transform takes the
text
and returns thetype
. By default, the type of the rule is used (e.g.identifier
).Example: case-insensitive keywords
This is my preferred solution for #67 / #78.
For example, you can create a customised version of
moo.keywords
which matches case-insensitively:Lexer#has()
This unfortunately makes it impossible to write a
Lexer#has
function, since we can't infer what token names might be returned by this custom function.This will make Moo incompatible with the current version of Nearley: we introduced
has()
so that we could tell whether%foo
refers to a custom token matcher such asfoo = { test: x => Number.isInteger(x) }
, or a lexer token. But custom token matchers will likely be removed [from Nearley] going forward, sohas()
will have no use.