parse consumption
[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
From: "Anton"
> 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
Hi Ladislav,
> 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.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted