World: r3wp

ack... well.. it was worth a try  =P

as you can see, I know some, but am not too strong in parse   ^.^

=image 
    file: images/a picture.gif 
    size: 200x300
    caption: some caption below the picture 
    desc: some description for the picture


I'm trying to extend Makedoc2 for a project to generate a xml dialect 
and I need much more information to certain elements - e.g. images 
- so I'm trying to make it as easy as possible for the user. The 
above is what I actually wanted to parse - but the order of the information 
is supposed to be free and I can't and don't want to use rebol datatypes 
which might be the first thought to make the parsing easier, because 
normal people don't want to learn too many rules for all these things. 
So the b and c in the example corresponded more to the caption and 
desc in the above example.

So you want to handle both, not only one of them? Something like
 some[ ( caption: desc: none )
  set caption caption-rule 
  | set desc desc-rule
 ] ( if all[caption desc][handle-them] )

No, initalisation before some..
 ( caption: desc: none ) some[

but aren't this only block parsing rules ? (because of set)

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.