Hi Anton,
this is an old parse "glitch". The difference between your rules is, that
the second one didn't cause the internal pointer to "get past the end" of
the input and therefore it didn't fail.
Current parse behaviour:
1) If a rule causes the internal pointer to "get past the end" of the input,
PARSE considers it a failure. This means, that even a PAREN! rule can fail,
if it removes a part of input.
2) to yield TRUE PARSE must
2a) "get successfully" through the whole rule
2b) get to the end position of the input
My favourite behaviour looks different:
1) "past end" position doesn't mean a failure
2) to yield TRUE PARSE has to "get successfully" through the whole rule
If you want PARSE to behave like I proposed above, you can use the following
workaround:
parse "abc" [start: "abc" opt (remove/part start 3) :start to end] ; ==
true
HTH
-L
----- Original Message -----
From: "Anton"
> I have here a bit of confusion:
>
> parse "abc" [start: "abc" (remove/part start 3) :start end]
> ;== false
>
> parse "abc" [start: to "abc" (remove/part start 3) :start end]
> ;== true
>
> The first parse "consumes" the "abc" before removal,
> and the second one doesn't.
>
> Why does it matter whether "abc" is consumed or not?
>
> I am setting the input position to the start of the
> string afterwards with :start.
> I have verified that before the removal, start is at
> the beginning of the string.
>
> Also, this is the same both in latest beta
> and last full release.
>
> Anton.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
