Previewing input #93
randomeizer
started this conversation in
Ideas
Replies: 2 comments 1 reply
-
I believe this is equivalent to our let identifier = Parse(Identifier.init) {
Prefix { $0.isNumber || $0 == "_" || $0.isLetter }.map(String.init)
}
.filter {
$0.first.map { c in c == "_" || c.isLetter } ?? false
} |
Beta Was this translation helpful? Give feedback.
1 reply
-
I've pushed a PR with an implementation of Thoughts? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi there,
I've been using the Parsing library in a couple of projects now, and the need to check on parsed content has come up a couple of times. I've pitched
Not
andPeek
elsewhere related to this.One concrete example from the project is parsing 'identifiers' (eg, function/variable/names).
Basically the rule is that the first character may be a letter or an underscore, and subsequent characters may be letters, underscores or digits. So, my first attempt was this:
It works, but feels a bit clunky having to append the two chunks of
Substring
to achieve it. So, withNot
andPeek
added, it is currently this:Which is better, but requiring a
Skip
feels somewhat redundant/noisy. While it makes sense forPeek
to return the value, it would be nice if there was another operator available that would confirm without returning the duplicated character(s).nom has a verify function which might be handy here. An example implementation could be:
Alternately, a variation on
Peek
(lets call itRequire
for now) which always returnsVoid
if theUpstream
Parser
is successful would allow us to omit theSkip
:There isn't really an analogue for this operator in
nom
, and I'm not sure ifRequire
is the right name. Other possibilities might beMatch
,Has
,Check
, orExpect
.Essentially, it's accounting for the scenario where you want to check the beginning of your input, but include that as part of a longer section of input to pass on to the next step.
Verify
lets you do that (and more), but is not optimised for that case.Prefix
lets you do it, but you have toSkip
sometimes, depending on how your upstreamParser
works.Thoughts on the concept in general? I think
Verify
is probably worth adding regardless, for doing more complicated post-parse checking. But I think it's kind of overkill for this purpose, and leads to some additional hoop-jumping in this context.Beta Was this translation helpful? Give feedback.
All reactions