[1/8] from: anton::lexicon::net at: 10-Sep-2002 0:10
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.
[2/8] from: gscottjones:mchsi at: 9-Sep-2002 9:54
> I have here a bit of confusion: > parse "abc" [start: "abc" (remove/part start 3) :start end]
<<quoted lines omitted: 10>>> Also, this is the same both in latest beta > and last full release.
Hi, Anton, You may feel confused, but you actually are not! :-) Let me re-word what you have said, using slightly more information, and I hope this reframes the issue in words that then make sense. parse "abcd" [ start: "abc" check: ( print [start/1 check/1 ] ;yields a and d remove/part start 3 print start/1 ; yields d ) :start to end ] My analysis: *without* the 'to, then the parser matches through the pattern, demonstrated by the check. So start still points to the initial start of the string, but the parser has already moved through it. So it seems consumed. parse "abcd" [ start: to "abc" check: ( print [start/1 check/1] ;yields a and a remove/part start 3 print start/1 ;yields d ) :start to end ] My analysis: 'to only matches "to" the pattern, as demonstrated by check. Parse still hasn't "moved through" the pattern, so it doesn't seem consumed. Did that help? --Scott Jones
[3/8] from: lmecir:mbox:vol:cz at: 10-Sep-2002 18:06
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
[4/8] from: rotenca:telvia:it at: 9-Sep-2002 20:05
> parse "abc" [start: "abc" opt (remove/part start 3) :start to end] ; > true
very interesting! I tried also any, repeat, some and all work! parse x: "12345678" ["123" h: 3 (remove h)] x ;== "12378" --- Ciao Romano
[5/8] from: anton:lexicon at: 10-Sep-2002 1:54
No, thanks for trying anyway! Perhaps I wasn't too clear. I understand already the difference between using 'to and not using 'to. (Or maybe I don't!) The question is why does the first parse not complete the input to the end? Your versions returned false and true like mine. Here is my annotated version: parse "abc" [ start: ; mark start of string "abc" ; eat 3 characters, so now at index 3 (remove/part start 3) ; remove all the characters ; so now at index ??? :start ; set current index to the start end ; expect to be at the end ] ;== false ; what??! The reason I am asking this particular question is because I don't want to use 'to. 'to has two different actions, that I don't necessarily want to use together: 1 - move through any characters (until...) 2 - I am at a position in the string which starts with the following... I only want the second action of 'to, if you know what I mean. Like "I expect the following string to be here, at the current index position (and I don't want to walk through it.)" If there were such a word, like, in my imagination, 'here: parse "abc" [start: here "abc" (remove/part start 3)] should return true, and I could use that to make the above parse rule complete. But that still leaves me with the question, why doesn't it get to the end as it is? Anton.
[6/8] from: anton:lexicon at: 10-Sep-2002 5:16
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.
[7/8] from: lmecir:mbox:vol:cz at: 10-Sep-2002 0:03
It has been discussed with RT, but they preferred to explain the current behaviour rather than to change it (compatibility reasons?). If you (or others) let them know that you prefer simplicity, they may change their mind. (Please, do!) OTOH, I am not sure if any crashes can happen this way?
[8/8] from: anton:lexicon at: 11-Sep-2002 17:18
I am sure it can crash rebol. I just don't have a simple example yet. I will try to strip it down to a small example. Anton.
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted