World: r3wp

the DOC is just the temp var for the second parse.

But, in that case your "inner parse" fails, without you noticing 
it?

why? it does not fails.. or maybe fails, but I have the data from 
the doc div, that's all.. it's lazy parsing :)

btw.. I need to parse the source only once so I really don't have 
to care about some exceptions.

I have the data
 - I doubt you get the data if the "inner parse" fails

believe me I have.. :) the script is already ready.. I was just thinking 
if there is some special parse keyword, like INTO, so I could do 
it without the second parse next time, that's all. I use such a lazy 
parsing very often.

in your case I would need to jump at least over each tag start, not 
using thru "<h5". But then there would be problem, that I need to 
stop the doc div only if it's exactly "^/ </div" (to avoid case that 
there would be another inner giv). I know it's not safe, but I can 
see what I do by examining the source I want to parse first. (240kB 
html in my case)

Aha, that "I can see what I do by examining..." looks substantial. 
Nevertheless, there is still a way how to do a similar thing without 
calling Parse again

I believe, but important is if it would be easy enough to satisfy 
 my lazines... something like the INTO for block parsing.

what about this, is it the rule you wanted?

some [
    thru {<h2><a} thru ">" copy name to {<}
    to {^/ </div>} doc: [
        thru {<pre class="code">} copy code to {</pre} (
            probe name
            probe code
        )
        any [
            here: if (lesser? index? here index? doc)
            thru {<h5>} copy arg to {<}
            thru {<ol><p>} copy arg-desc to {</p></ol>}
            (printf ["  * " 10 " - "] reduce [arg arg-desc])
        ] 
    ]
    :doc
]

aha, I missed there should be doc-start and doc-end

some [
    thru {<h2><a} thru ">" copy name to {<}
    doc-start: to {^/ </div>} doc-end: :doc-start
	[
        thru {<pre class="code">} copy code to {</pre} (
            probe name
            probe code
        )
        any [
            thru {<h5>}
			here: if (lesser? index? here index? doc-end)
			copy arg to {<}
            thru {<ol><p>} copy arg-desc to {</p></ol>}
            (printf ["  * " 10 " - "] reduce [arg arg-desc])
        ] 
    ]
    :doc-end
]

Nevertheless, both the variant you posted, as well as the variant 
I posted parse a part of the text more than once. A variant parsing 
the text only once can be written as well.

this should work with R3:

    some [
        thru {<h2><a} thru ">" copy name to {<}
        copy doc to {^/ </div>} :doc
		thru {<pre class="code">} copy code to {</pre} (
			probe name
			probe code
		)
		any [
			thru {<h5>} copy arg to {<}
			thru {<ol><p>} copy arg-desc to {</p></ol>}
			( printf ["  * " 10 " - "] reduce [arg arg-desc] )
		]
    ]

notice the :doc,  which allows to switch the current input parsed

The last Ladislav's version is working, but it's far to be easy to 
use for lazy parsing. I think that I will stay with my version;-)

Use what suits your needs best. Nevertheless, as far as code size, 
etc. are compared, they are the same (even sharing the property, 
that the part of code is parsed twice).

Was Carl's proposed LIMIT keyword implemented yet?

Not yet, I guess.

That is what he proposed to deal with this issue. I look forward 
to it.

I use the new INTO string feature a lot with file management code.

Hey you don't like my solution ? it's simple enough, don't need of 
LIMIT

I like your solution, and would use solutions like that. I just would 
prefer to have LIMIT :)

It has a lot of overhead though (copy overhead).

I knew, you would say that... :-)

You have to be careful with INTO string though because there is a 
lot of PARSE code out there that depended on INTO failing with non-blocks, 
and triggering an alternation. Learn to like AND type INTO if your 
code depends on that.

Hey you don't like my solution ?

 - I guess, that Oldes does not like it, since it does not "stay in 
 the limit" of DOC

He just has to switch again that. I don't think he even understood 
or read what I proposed

Ah, I must have misunderstood the solution then. I thought it was 
a two-pass thing with subparsing of a copy.

aha, you would like to use the get-word to switch the input

Brian, it is

I have seen that proposed, but it is not available currently (I would 
support such a proposal, though)

Ladislav, It's working in R3 currently

since a while

Checking

That's what I thought. I originally proposed that kind of input switching 
in 2000. It can cause problems with backtracking though, so a sub-parse 
in an IF operation can be safer.

Lot of back tracking problems may arrise in a lot of way when you 
do parsing.
I'm not sure it's an argument :-)

There are no backtracking problems with COPY x TO thing IF (parse 
x rule). But that was the original reason we didn't have input switching. 
The reason I requested input switching in the first place was to 
make it easier to implement the continuous parsing that Pekr was 
requesting at the time :)

I don'"t see where is the problem, you just have to switch back the 
original serie if the sub-rule fail, no need of if (parse ...) thing

Originally, only position was reset, not series reference. I would 
welcome tests that show what the current behavior is. Ladislav?

I didn't say the reference was restored automaticly , you have to 
do it yourself.

....
restore: [:switch-serie sub-rule | :restore]

If it is not restored automatically on failure, backtracking and 
alternation, then that is a problem that needs a ticket submitted 
for it.

Agreed, It would be a nice improvment

but it may slow down parse, no ?

Not much, just one more pointer assignment at alternation.

Ladislav, are you  lost in translation ?
Or are you crying :-)

It fails. Here is the test code that I will put in the ticket:
>> a: "a" b: "b" parse a [:b "b" (print true) fail | "a"]
true
== false  ; should be true
>> a: "a" b: "b" parse a [:b "b" (print true) fail | "b"]
true
== true  ; should be false

So, half of the request succeeds: You can set the position to another 
series. I wonder if you can change series types from string to block.

Yup, you can.

It is not a simple problem though, as not only would you have to 
add a series reference to the fallback state but you would need to 
make those series references visible to the garbage collector so 
they won't be freed; backtracking to a freed series would be bad.