World: r3wp

I've been refactoring my parse rules ever since, just because I was 
so frustrated I gave up on a fix.

since the function header is parsed by block parsing, perhaps you 
are exaggerating ...!

It wasn't always so. This was at least 5 years ago.

View 1.2.48 works OK

See, all I need is a GREAT DEAL of patience :)

we're all patient othewise we wouldn't be here...

It looks like it has been repaired around the time you finally gave 
up ;-)

I should have known that would do it :)

Ladislav, while you're here, tell me what you think of this draft 
of the RAMBO request:

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

- Behavior: The paren would be executed like any other paren in parse, 
but the return value of that paren would be checked. If the return 
value is one that would count as false for the IF native function 
(false or none), then the parse would fail at that point as if parse 
had failed to find some syntactic element. At that point, any normal 
backtracking and advancement to the next alternate would be performed, 
if any.


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.

perfectly understandable for me and I support this, but I am afraid, 
that there are many that wouldn't understand it. Anyway, if it is 
meant for Carl, it may suffice

(otherwise a somewhat elementary formulation might be desirable)

It's a RAMBO entry, not documentation. Still, is there anything you 
find unclear there, awkward or incomplete? Am I missing anything?

don't think so

Aside from a meaningful example that would demonstrate the importance 
of this proposal? That I know is missing...

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.