World: r3wp

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?

I'm not sure what you mean. Do you want to parse set-words?

yes, I saw this in Chris's  validation lib " Defining a good dialect 
(simple, short, efficient) isn't an easy task. Chris did some work 
about such form validation dialect in QM. See http://www.rebol.org/documentation.r?script=filtered-import.r
" (on this url)

I think I get it. You can't use the set-word directly, as it's used 
to store the current location in the parsed block.

you can always check for any set-word!, but I don't know how you 
would check for a specific set-word!.

from his dialect: 

name: string! is not within ["Carl"]
age: integer! is between [18 65]
start-date: date! is after 30-April-2007

yes, basically in this case I am not looking for specific set-word 
but taking it as value .. I will try that

I'm just starting to play with dialects : it's really a pleasure 
to play with.

set key set-word! (key: to-word key)

is how he does it.

aha this words yes

>> a: [ id: ]
== [id:]
>> parse a [ set ttt set-word! ( print ttt ) ]
id
== true

:) thanks a lot

a variant on that would be:

parse a [ttt: set-word! (print ttt/1)]

you solved my problem and it looks much better in Chris's style.. 
thanks to both

this is now:
	id: required and integer

 name: optional "janko" check ( either current == "janko" [ "can't 
 be janko" ] [ none ] )
	vatnum: optional "11ss" and int
	website: optional "123" and int do ( current: current + 1000 )
	phone: optional "NO" calc ( join "oh-" current )
	adress: optional ""

this was before:

	id required and integer .

 name optional "janko" check ( either current == "janko" [ "can't 
 be janko" ] [ none ] ) .
	vatnum optional "11ss" and int .
	website optional "123" and int do ( current: current + 1000 ) .
	phone optional "NO" calc ( join "oh-" current ) .
	adress optional "" .