Hi Petr, 9-Jan-2000 you wrote:
[...]
>> >This will not work imho :-)
>>
>> You're right. As I said, it was completely untested ;-)
>>
>> I used "to" instead of "thru", and we need the /all refinement. But
apparently
>> that's still not enough, though I don't know why...
>>
>As I said - it doesn't matter if you used 'to or 'thru, because once you are
back
>from 'b's maddening :-), you are standing just behind the last occurance of
"ing"
>in the parsed string ...
Erm, we should be standing just in front of it, otherwise there's now point?
And I wanted to see if we had a separator just behind the "ing", which means
I should use 'thru.
>> To make things even more spooky, look at this:
>>
>> sep: charset " ,.!?"
>> b1: [skip b1 | "ing"]
>> b2: [skip b2 | "ing" sep to end]
>> a: [b1 | b2]
>>
>> The idea here is that b1 will match any string ending in "ing", and b2 will
>> match any string which contains "ing" followed by a separator. Now, watch
>> this:
>>
>> >> parse/all "ringing bells" b2
>> == true
>it's just the same as 'b1, it just contains the code to skip to the end of
the
>string ....
Yes. As I said above:
The idea here is that b1 will match any string ending in "ing", and b2 will
match any string which contains "ing" followed by a separator.
Notice the use of "ending in" and "contains".
[...]
>6) so b1 is true for the first time and we are standing just behind the "ing"
>string, so at beginning of "bells", or " bells", once parse/all is used ....
You _do_ mean that we're in front of the "ing" string, right? We cannot see
what is just to the left of our position, so talking about what happens when
we're at the right of "ing" makes no sense.
Besides, b1 will never ever return true for "ringing bells", as this string
does not end in "ing".
>and now back to parse/all a
>a is subrule!
Huh???
>b2 part of this subrule is NEVER applied. Know why? Just because at some
point, we
>returned true from b1, so there is no need to perform OR option. The 'false
it
>there, because all we need to do is to skip to the end of the string ...
But if we returned true from b1, the result of the whole parsing should be
true too. But of course b1 will not return true, as b1 will only match
strings _ending_ with "ing", and "ringing bells" is not ending with "ing".
>> >as for "ringing bells"
>>
>> >Again, you are going to reach end of the string, then going back
recursively
>> >until first "ing" (applied from end of the string) is not matched. :
>>
>> >>> b: [skip markb: (print ["markb: " markb index? markb]) b | back-b:
(print
>> >["back-b: " back-b in
>> >dex? back-b]) "ing"]
>> >== [skip markb: (print ["markb: " markb index? markb]) b | back-b: (print
>> >["back-b: " back-b index
>> >? back-b]) "ing"]
>> >>> parse str a
>> [...]
>> >back-b: g bells 7
>> >back-b: ng bells 6
>> >back-b: ing bells 5
>> >== false
>>
>> >Your code will fail with something like "ringing sounding bell" ... it
will
>> match
>> >sounding, so generally said - the last occurance of "ing" contained in the
>> string
>> >...
>>
>> It should then try to match the part to the right of the "|" in the top
rule
>> (rule a), which should match. But that doesn't seem to happen.
>No, why? | means OR, not continuation of the rule. There is no need for OR,
as
>your first part of rule got 'true. Parser then tries to continue after right
] of
>rule. Remember [blabla | bleble] is just subrule, once blabla is true, it
then
>skips behind the right ] ...
Either I do not understand you, or you have missed the point that the rule to
the left of the "|" is returning _false_, not true.
>> >change 'a to [b to end] and once succesfully back from 'b, it will
continue
>> "to
>> >end" and return "true" ...
>>
>> But that's not what it should do. Then the rule would match all strings
with
>> "ing" in it.
>Yes, backtracked from the tail of the string ...
I repeat: That's not what it should do.
>> We only want to match strings that either end in "ing" or have a
>> word inside it (words are separated by spaces, commas, etc.) that end with
>> "ing".
>>
>I don't understand it as for above parse/all "ringing bells" [thru "ing"]
should
>be sufficient ...
Nope, see below:
>well if you want to return false for str: "ringdong bells", that's another
story
>....
And that's exactly what I want to do!
>parse/all str [thru "ing " to end]
But a word can end in ",", ".", "!", "?", etc. I wanted to cover all these
instances with my "sep" variable, which is a bitset. You cannot do that in
the above way, since 'thru doesn't accept the block ["ing" sep] instead of
your "ing " string.
>and if it doesn't cover "ringdong bellsing", then just add space to the
parsed
>string before parse is applied ... what a hack :-)
That's why I had my b1 block... and your solution only accepts " " as a
separator. And I wanted it all to be inside the parse rule, not using other
REBOL commands, which is also why I didn't just start by splitting up the
string with
strings: parse str " ,.!?"
which would simplify things a bit. I would do this for a "real-life" program,
I guess, but not on a mailing list ;-)
Guess I'd better just go to bed now...
Kind regards,
--
Ole Friis <[EMAIL PROTECTED]>
"Ignorance is bliss"
(Cypher, The Matrix)
