World: r3wp

yes, an example is desirable

The result of the next paren tells if 'if counts as success. a value 
of false or none triggers a fail.

(sorry for english.)

as success -> as match

parse [... ] [ if ( some-test ) | if ( another test ) ]

Yup, you got it. You don't need to specify a block afterwards because 
the parse dialect has built-in control flow.

at present we can only match on datatypes and literal ( non integer 
) values.

is there a better word than if, for grahams example?

if implies a then, and we have none.

away-rule: [
	'away set .. [
		'from ... |
		'every set day word! 

  if ( either day = to-word pick system/locale/days current-date/weekday 
  [
			repend away-days [ current-date current-date ]
			true
			][
			false
		   )

		) |
		break

	]
	( reason: copy "" )
	opt ...
]

oops .. close

Then is everything after the if clause. Parse already has control 
flow.

Here is a rewording of the proposal. Any problems?

I would like an IF clause in parse, that would work like this:
- Syntax: if (test)

- Behavior: The paren is executed like any other paren in parse, 
but the return value of that paren is checked, treated like the condition 
argument to the if native. A false or none value would cause the 
parse to fail as if it had failed to find some syntactic element 
- otherwise the parse should continue. Failure should trigger any 
normal backtracking and advancement to the next alternate, just like 
failure of a syntactic match would at that point.


This clause would allow parse flow to be directed by semantic criteria 
as well as syntatic, allowing parse to handle a greater range of 
grammars. An if clause would be sufficient to make parse into a predicated 
parser, similar in capabilities to ANTLR.

to me it sounds like "do somewhing", not just continue.

more like verify or assure.

assert
, although more like debugging.

It means I can do this

if ( clause ) |
break

I guess to exit the rule.

BrianH: then Rambo-it! :-)

The control flow of parse is more like that of Prolog or Icon than 
it is like Pascal. "Then" is a Pascal thing.

the new wording looks better

Graham: you can do even if (not clause)

which might do what you wanted for if (clause) | break

I think 'or should be an alternative to | ( off topic )

Should the keyword be named TEST? I chose IF because it was less 
likely to be used for variables in existing code, and it corresponds 
to the equivalent concept in the different semantic model. Plus, 
that's how they say it in other predicated parsers.

conditionally

saw that in one forth book.

If there are no other comments or suggestions, I'll submit it as 
worded above.

I am ok with that. after thinking about prolog&icon withthe if too.

Go.

yes

I didn't do a really useful example, just one to demonstrate the 
current way of faking the behavior.
Example:  [if (test) | ...]
Fix:  [(unless test [dummy: [end skip]]) dummy | ...]

On a (slightly) different note, has anyone tried to implement incremental 
parsing with parse? Last time I tried something like continuations, 
but there must be a better way...

For instance, can you put a wait in a parse paren?

Interesting idea. I guess that would work. but not with async.

for small things i would just reparse the whole thing.

See, this is why I wanted that if clause. It's so easy to mess up 
the workaround.
Fix:  [(dummy: unless test [[end skip]]) dummy | ...]

what i would like is in incremental parse as base for multitasking.

I was thinking about parsing data larger than available memory, or 
coming over a slow link.

Something like do/next for parse.

Or beeing interactive, where the next things depend on what you reply.

but i know no good way with parse only.

f: open/direct file
a: copy/part f 4096

parse a [some [rule1 | rule2 | b: if (if a: copy/part f 4096 [b: 
join b a]) :b]]

With the IF workaround applied, if you can.

Well, I submitted the entry when you all said it was OK (I forgot 
to mention). Now we get to see how it all turns out. I like RAMBO 
much more than feedback - more public.

Later all!

Keep us informed on the outcome :)

btw, my compile-rules.r implements IF (i don't recall if exactly 
as noted above, but i think so, or very close). i had a rep with 
this and other things too.

http://www.compkarori.com/vanilla/display/TO, THRU And NOT PARSE Rules 
implements IF too, but using IF [...] instead of IF (...) , which 
is the only difference as far as I can tell

Gabriele, I recall that it didn't work the same, but have no way 
of checking that right now because I couldn't find your compile-rules.r 
on rebol.org and you didn't provide a link just now.