World: r3wp

(using recursion)

like  Tables: [Table Tables | Table]

Table: ["<table>" Content "</table>"]

...and so forth.

rule: use [table row][
	row: [<tr> </tr>]
	table: [<table> any [table | row] </table>]
	[table]
]

As Robert de Niro said in one of my favorite movies of all time, 
"Analyze This"  "...hey, you...you're good!"

rfc: I have a (not so) little function that attempts to match a block 
of values to a given specification.  Example:

	>> probe match [%image.png :red 300x100 /old][
	[	file: file! | url!
	[	size: opt pair!
	[	attributes: any get-word! | refinement!
	[	]
	make object! [
		file: %image.png
		size: 300x100
		attributes: [:red /old]
	]


There's not much to the rules, they are -- one (default), opt (zero 
or one), any (zero or many), some (many).  If they don't match, they 
return an error.  Any suggestions?  Optimizations?

	http://www.ross-gill.com/r/match.r

Ways of making it smaller???

One of the desired effects is precedence, for example:

	match [http://rebol.com%image.png][
		link: file! | url!
		image: file! | url!
	]

Returns:

	[link: http://rebol.comimage: %image.png]

I do something like that, but text based, in QML. not sure if it 
can be of any help.

.

What's the best approach to support normal Rebol things like FOREACH, 
IF, ANY, ALL and set-words, get-words within a dialect? I don't want 
to write Rebol parse rules for this.

Example: parse XYZ mydialect

XYZ: [
	repeat x 1 14 [
		a: get-point x 7
		set-point 7 x (a * 2)
	]
]
]

get-point and set-point are the dialect things. The rest should be 
normal rebol.

Is there a best practice how to get Rebol control structure support 
into dialects?

but isn't this just a regular rebol code block then .. a: get-point 
x 7 and set-point looks like a normal rebol func too?

Just assume that get-point and set-point is done via a dialect.

aha, I would also like to know if that is possible .. I still haven't 
figured out how they do ( some code ) in parse

Use Gab's compile-rules module.

Gab = Gabriele

Robert, if you don't want to use parse rules you might try DO/next. 
Don't use DO/next (or Gabriele's compile-rules) if your dialect data 
can come from an untrusted source - use parse rules and dialect operations 
that call the REBOL functions if necessary.

But *only* the REBOL functions that you want to support and can do 
so safely.

You can't make that restriction with DO/next or Gabriele's compile-rules 
without a sandbox - hard to do in R2.

Check out the source of the R2's layout function.
?? layout

Brian: I think, that Rbert wants to use parse rules. The question 
is, what is the best way how to setup such a rules.

compile-rules: Ok, will take a look at it.

The other option would be not to use a dialect at all and create 
normal functions for everything. But I like dialects :-)

Robert, in compile-rules, INTERPRET is what you want to look at.

Brian: so, see, even normal people want DO in PARSE, and not only 
that, they want all the control structures... look at compile-rules 
how much effort that is. :-)

Gab, where can I find the script?

I found it here http://www.colellachiara.com/soft/PDFM2/compile-rules.r
but I don't know if it's uptodate.

Ok, found version 1.40 on my system.

History states a version 1.50...

Just because normal people want DO in PARSE doesn't make it a good 
idea. Little girls want a pony, but it's not a good idea if they 
live in an apartment. DO in PARSE would be a feature that couldn't 
be used most of the time because of its security problems.

:)

A better analogy might be little boys asking for a machine gun though 
:(

Please no : keep the pony !

That's why I ony want some control structures routed into the dialect 
context.

Brian, right, so I have to workaround all the time, write slow code 
with deep parse recursions, and all those funny and nice things. 
Or, give up and pretend REBOL was PHP.

We already had a long discussion about the "security problems" and 
I still strongly disagree that there's any more security problems 
than having DO in REBOL has.

I'm not saying that I don't support the addition of a DO operation, 
just that it has security implications. I already added DO to the 
Parse Proposals long ago. Here it is: http://www.rebol.net/wiki/Parse_Project#DO

There is more semantic detail in the new DO Parse Proposal than there 
was in your original Parse REP. Being more specific about binding 
issues and error handling deals with most of the security implications. 
This makes the operation *exactly* as secure as DO, and not less 
so. You can even sandbox the data using the same methods you would 
use to sandbox DO in R3.

It also makes the data *exactly* as difficult to sandbox in R2 as 
it is to sandbox R2 DO code :(

I'm working on the sandboxing in the R2-Forward project though.

I don't have to tell *you* how difficult it is to sandbox DO dialect 
code, Gabriele: You've already done half the work :)

can I ask how did Chris make in his dialect so that set-words are 
used >>a: [ id: ]<< .. how do I parse this, this for example doesn't 
work >>parse a [ 'id: ]<< , any Idea? :)

make = made

remove the '.

It doesn't seem to work >>parse a [ id: ]<<

or did you mean something else?