World: r3wp

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

kib2: yes, and they are technically very easy to make... I always 
thought it's soma magical process :)

Start layering multiple dialects and then you'll see some real power 
:-)

I am still at mostly basic dialecting rules, but even this is very 
interesting and a lot can be made

I'm still waiting who will be the first to write Rebol like interpreter 
as a dialect:)

has anyone made a dialect that would make some basic or typical sqlite 
? (so I won't be reinventing if not necesarry)

Oldes: making something like pypy in rebol rebreb maybe would probably 
not take so many years :)

Last year I created a small database which I wanted to talk to via 
a dialect. So I created a builder dialect that would build the database 
command dialect in two sets, one for server side for query handling 
and one for client side for response handling, so 3 dialects.

Then I would build client- and server-apps using a make-file like 
dialect which preprocesses and builds apps and uploads them to specific 
locations. 4 dialects. Great amount of control. Very little code.

( pypy is python interpreter in python )

Henrik: very interesting

Janko; you may know this; dobeash.com has RebDB as well as a SQLite 
driver.   RebGUI with RebDB ...  livin'   :)