World: r3wp

I'm gonna try again:

>> s: {=image
{    file: images/a picture.gif
{    size: 200x300
{    caption: some caption below the picture
{    desc: some description for the picture}
== {=image
file: images/a picture.gif
size: 200x300
caption: some caption below the picture
desc: some description for the pictu...
>> parse head append s {^/} [
[    some [
[        thru {file: } copy file to {^/} |
[        thru {size: } copy size to {^/} |
[        thru {caption: } copy cap to {^/} |
[        thru {desc: } copy desc to {^/}
[        ]
[    ]

right, mistake. with strings that is copy, not set.

err wait.. then they can't have newline inside the description/caption 
  (x_x)

ok - have to try this ideas

IMHO 'to and 'thru are only for simple cases. You need a real bnf. 
or you can use two parses. the first takes only the lines after image, 
then a second processes the lines.

http://polly.rebol.it/test/test/parse-images.r

updated with pure parse-rule. but better support for such cases would 
be nice, should not be guru-level.

Has clean-script been updated for the new version of Core?

It barfs on data/(...)

How to exit a parse rule in the middle and return true ? ( to allow 
the next rule to be applied ... )

'break

interesting... will write that in the wikibook :-)

or "end skip". with break the parsed part counts as success. with 
end skip it counts as failure and backtracks.

This is part of my scheduler dialect

away-days  is a block of [ start-date end-date reasons ]
current-date is the date I am looking at

The syntax is

away 25-Dec-2005 on holiday
away 25-Dec-2005
away from 25-Dec-2005 to 7-Jan-2006 on "summer holidays"

I want to add

away every Wednesday at "golf course"

away-rule: [ 
	'away [ 
		set awaydate date! (repend away-days [ awaydate awaydate]) | 

  'from set awayfrom date! 'to set awayto date! ( repend away-days 
  [ awayfrom awayto ]) |
		'every set day word! ( 

   either day = to-word pick system/locale/days current-date/weekday 
   [
				repend away-days [ current-date current-date ]
			][
				...break out of rule... 
			]
		 )
	]
	( reason: copy "" )
	opt [ [ 'on | 'at ] set reason [ word! | string! ]]
	( append away-days to-string reason )
]

Now if the current-date matches a Wednesday, I am okay.

But if not, I want to leave the rule at that point, and move on to 
the next rule.

'break can only be used within the parse dialect, so that won't work.

the general way:

 rule: [  ( dummy-rule: [] if not ok? [ dummy-rule: [end skip] ) dummy-rule 
 ]

oh ... looks ugly.

It is.

Ok, we need a parse enhancement here !

BrianH proposed and enhancement I agree with, but I am afraid it 
sill isn't in RAMBO

still

which enhancement was this?

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...