World: r3wp

Too many recursions.
Maybe the rule is too complex or you get an infinte loop.
Just show your rule and the problem.
For sure someone will help.

Thanks Oldes, I've tried your hint, but it made my parse rule too 
complex, so I've used an additional word as discriminant.
Hope that R3 will improve this.

sqlab, your are right. There is an infinite loop. I am fixing it. 
It's a C++ parser, so the rule is very complicated.

paul asked: "Question for you regarding parse.  How do you force 
parse to return false immediately without processing the rest of 
the string or block one it evaluates a paren?"

example: 


parse/all s [some ["12345" here: (print "*" here: tail here) :here 
skip]]


basically, in the paren, you assing the tail of the data being parsed, 
and force parse to move to it, then try going beyond....  the skip 
makes it return false, otherwise it returns true.

oops example forgot string to parse... hehehe

>> s: "12345 12345 12345"
== "12345 12345 12345"

>> parse/all s [some ["12345" here: (print "*" here: tail here) :here]]
*
== true

>> parse/all s [some ["12345" here: (print "*" here: tail here) :here 
skip]]
*
== false

Not exactly what I'm talking about.

Well maybe...

parse/all s [some ["12345" (print "*") end skip]
is that not enough ?

Well the skip is  going to produce false unless you know how much 
to skip

the here: tail here: is just the code you assign IF something you 
want to check programatically matched.

now the question, paul, is do you want the WHOLE parse to fail, or 
just that rule?  up to the paren?

or do you want to do, basically, look ahead assertion?

The skip will produce false because it is attempting to skip past 
the end.

The phrase [end skip] will always fail and return false.

What I'm talking about is this:

words: [this that blah]


result: parse [this that bleh blah][some [set w word! (unless find 
words w [do something to return false here)]]

result should evaluate to false in my example

For now, you want a continuation variable. Like this:

result: parse [this that bleh blah][some [set w word! (cont: unless 
find words w [[end skip]]) cont]]

continue: none	;means continue is ok
stop: [end skip]

result: parse [this that bleh blah][some [set w word! (unless find 
words w [continue: stop]) continue]]

ahah, same idea

Brian, I thought I tried that.

checking that one hold on.

I was working on another idea where only THAT rule failed !

for a general failure, the above works for sure.

yeah that will work Brian.  i think I was setting the word that I 
had placed at the end and that is why it failed before.

That is the equivalent of the CHECK proposal.

What is the Check proposal?

look in:   http://www.rebol.net/wiki/Parse_Project

Read the parse proposals linked above.

its also a good read to know many of the "tricks" in parse   :-)

By the way what I currently have been doing is setting a value to 
another word to differentiate why the parse failed - whether it was 
syntax or because of an invalid word.

(of R2)

I was the editor of the proposals and manager of the proposal process.

I remember posting on the blogs a long time ago... its nice to see 
it was all compiled.... thanks brian !

Yeah currently I would just set another value called 'flag in the 
parens and then check it after the parse was complete.  If it was 
true then I know a word wasn't found.

In theory, the best proposals (I have a list in my head) will be 
able to be compiled to R2 parse rules. Tested theory :)

the whole of the enhancements will make PARSE SOOOOOOO much more 
conscice and fun to use for advanced stuff.     :-)

I now have a real reason to want R3.

I don't  know if  'Check functionality really needs to be BUILT as 
much as just communicated.

Did you see my advanced example at the bottom? :)

It shows the power of parse.

not yet... reading it as I chat, cook and do some income tax stuff... 
I' m a bit like reichart... I've got an exec kernel in my brain  
 ;-)

In fact that method I was showing is how TRETBASE will be parsing 
search criteria to ensure only acceptable words are used in the block 
that will be reduced.

A lot of the workarounds require variables, which can be difficult 
to use concurrently. The proposals are all attempts to get around 
that.

That idea is to put all the operators (since they are words in the 
words containers along with field names which get later set to values 
and other set-words as desired).

the main thing is about the recursiveness.

I do that will calling my rule inside the rule.

remark has a stack which it must manage manually... proposals might 
make some of that management useless.

The CHECK workaround is the easiest way to do reserved words that 
can change at runtime.

Here is what I currently had:


rule: [some [set w word! (unless find valid-A w [flag: true]) | into 
[rule] | any-type!]] ; rule for parsing the Ablock