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"]
== false

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)]
ok
== false

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"]
== true
>> parse "a" [not "b" skip]
== true
>> parse "a" [not "b" to end]
== true

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]
|: "ab"
== false

>> parse "ab" [not "ab" ?? | ?? end]
end: "ab"
== false

Both cases show that the input is still at "ab" regardless of the success of the NOT.

2 Comments

Comments:

Peter Wood
5-Oct-2009 19:15:55 Thanks for the explanation.
Is there a way to achieve the same behaviour as using a "complemented" bitset in Rebol 2?
Carl Sassenrath
5-Oct-2009 19:50:08 Yes, a complemented bitset in R3. However, that's still lurking on the TBI (to be implemented) list. They work differently from R2.

Comments on: PARSE: the definition of NOT

Comments:

Post a Comment: