Great Ladislav! That seems to have done it. I remember the discussion on this before now. It is easy to forget these little things.
Your comments below made me realise that: if I remove a part of the input string, starting before the internal pointer, and ending after the internal pointer, then I should move the internal pointer back *before* I do the remove. This way there is no chance back in the parse dialect for the internal pointer to "realise" that it is after the end of the input string. I agree with your proposed behaviour for parse. I suppose you have submitted this idea to feedback a long time ago? It might also be submitted with more urgency because such a dangerous removal can crash rebol. Anton. > 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.
