World: r3wp

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.

it's different, as i made it as:

| 'if set val1 paren!                        ; NEW: apply rule only 
if condition is true
            element

      | 'either set val1 paren!                    ; NEW: choose rule based 
      on condition
            element
            element

i think there are pros and cons to both approachs.

i admit i haven't used if and either much though, what i used a lot 
was DO.

I prefer the continue-if-true version. I particularly like that there 
is a workaround now that the backtrack-through-paren bug has been 
fixed since I first suggested an IF clause.

BrianH: see the above link, it is an IF as you proposed, except that 
it uses a block instead of paren!, because that was simpler to implement, 
but it doesn't matter much, can be transformed

How do get parse out ^?

>> caret: charset [ #"\^" ]
** Syntax Error: Missing " at caret: charset [ #"\^" ]
** Where: halt-view
** Near: caret: charset #"a"