World: r3wp

Sorry, I've been overwhelmed with school beauracracy and other concerns. 
I haven't had time to compose my thoughts.

I hope you will have an opportunity to read it in RAMBO soon ;-)

what's the low down?

an IF PARSE keyword working with parens as follows: IF (evaluate 
expression)

would it solve your need?

The real trick here is that they have to fix a parse bug that has 
been there since the beginning: Parse doesn't backtrack past parens.

didn't notice that , an example?

I think it would .. but I can also get by by rewriting the parse 
rule.  It would end up much longer though.

at the moment, I just fudge it by adding a far distant date.

Fudge, the Minister of Magic and Wizardry?

Cornelius

:-)

Damn. I gave feedback about this years ago, checked over and over 
again in new revisions, and then finally gave up. But when I was 
trying to come up with an example of the problem for you Ladislav, 
it turns out that they must have fixed the doesn't-backtrack-through-parens 
problem sometime during the View 1.3 development cycle. I guess that 
shows me :)

G
 looks like fudged "C"

Works on string and block parsing too. They didn't even have block 
parsing when I first noticed that problem.

and your old example was?

(just to check with 1.2.48)

parse "abc" ["a" (print "a") "c" | "a" "b" "c"]

It used to fail, return false, because the paren shortcircuited the 
backtracking, so it wouldn't return to the position before the "a", 
it would return to the position the parser was at when the paren 
started.

It was so long ago, I don't even remember if View was in its first 
beta yet.

It was certainly before the parse break keyword was added.

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.