The new rule ByteStringHexEscape matches two hex digits, and fails with InvalidHexEscape on everything else. Note that we don't want to match more than two characters here, so we have cases for end-of-stream ($), one character (_) and two characters (_ _). We can't do something like _* because that would match \xaaaa and fail with InvalidHexEscape.
(This is a case where a syntax for mathing between given numbers of occurrences would be useful, e.g. _{0,2} would expand to $ | _ | _ _. alex has this feature.)
It would be good to have a more concise way of failling with a given error. For example, in the definition of byte_escape:
This is related to #35 and we use the same example.
Suppose in
b"\xa"
I want to fail with "invalid hex escape".With a "cut" operator as described in #35 the best we can have in a concise way is an "invalid token" error.
To raise a "invalid hex escape" error we need to use new rules. For example:
The new rule
ByteStringHexEscape
matches two hex digits, and fails withInvalidHexEscape
on everything else. Note that we don't want to match more than two characters here, so we have cases for end-of-stream ($
), one character (_
) and two characters (_ _
). We can't do something like_*
because that would match\xaaaa
and fail withInvalidHexEscape
.(This is a case where a syntax for mathing between given numbers of occurrences would be useful, e.g.
_{0,2}
would expand to$ | _ | _ _
. alex has this feature.)It would be good to have a more concise way of failling with a given error. For example, in the definition of
byte_escape
:Maybe we could have something like:
where
!
is the cut operator as described in #35, but when the match fails, instead ofInvalidToken
we now raiseInvalidHexEscape
.One question is whether we also want a syntax for specifying the error value, without also adding a "cut". So far I didn't need this.