Comments on: PARSE: the definition of NOT
The proposed definition of NOT was simply to invert the success or failure of the following rule.
So, NOT is not defined to complement a value. It inverts the rule result.
For some expressions, this difference can seem a bit misleading.
Take this line:
>> parse "a" [not "b"]
At first, that looks like a bug, because it is true that "a" is NOT "b". However, parse is returning false because you did not finish parsing the input!
You can discover this if you add a bit of debugging:
>> parse "a" [not "b" (print 'ok)]
So, you can see that the NOT "b" was in fact true. Now, you need to finish the rule, in whatever way you require:
>> parse "a" [not "b" "a"]
>> parse "a" [not "b" skip]
>> parse "a" [not "b" to end]
Notice that NOT works like AND (and also like OR, the "|") -- it always resets (backtracks) the input.
Why does it do that? Consider this case:
>> parse "abc" [not "test" ...]
Although it is true that "abc" is not "test" the parser cannot advance the input because it cannot determine how much to advance it by. In other words, not matching the input only tells you what the input is not, not what it is.
You can verify this with a little debugging (here, using the new ?? debugging feature):
>> parse "ab" [not "ax" ?? | ?? end]
>> parse "ab" [not "ab" ?? | ?? end]
Both cases show that the input is still at "ab" regardless of the success of the NOT.
Thanks for the explanation.
Is there a way to achieve the same behaviour as using a "complemented" bitset in Rebol 2?
Yes, a complemented bitset in R3. However, that's still lurking on the TBI (to be implemented) list. They work differently from R2.|
Post a Comment:
You can post a comment here. Keep it on-topic.