World: r3wp

Well, you could easily make your own datatype matching rule:

>> datatype: [datatype! | 'string! | 'integer! | 'decimal! ] ; ... 
etc. for all the datatypes or just interesting ones
== [datatype! | 'string! | 'integer! | 'decimal!]
>> parse reduce ['integer! integer!] [datatype datatype]
== true

With a little extra effort you can automate the creation of the DATATYPE 
rule to include all rebol datatypes.

In Rebol2, it is a small problem to find all the datatypes, but in 
Rebol3 the complete list of all the datatypes is already supplied.

btw Brian, have you news about OF/ALL proposal ?

Carl is focussed on the GUI stuff right now, and his feedback is 
needed since he will be using the feature for that.

Ok, i only would to know if it was discussed

Right now I am integrating Peta's ideas from the PEG model. Good 
stuff.

i like the idea of the non consuming rule AND

but it's eay to simulate currently, it's not an enormous gain

*easy

It's not as easy as it seems in a recursive-safe manner, as Peta 
has demonstrated.

that always the case when manipulating indexes, whe have to push 
index in stack.

that's the aim of your USE proposal no ?

USE is going to have the same overhead the USE has in REBOL.

i'm wondering if special commands like (PUSH and POP) to save/restore 
the current index when entering in recursive rules would be usefull

i had the case IIRC (i simulated th

i take an example:

to simulate AND we do [here: rule :here] but it can't be used in 
a recursive manner.

If we had PUSH and POP to save and restore the current Index depending 
the level of the recursion (in fact they are stack operations)
So, we could write: AND: [push rule pop]

it could be very interesting and replace USE in many cases

would AND be equivalent to [use [success?] [[(success?: no) rule 
(success?: yes) fail | none] check (success?)]] ?

If it is equivalent, reading your rule, then I full agree to add 
AND :-)

petr, it depends on how it's useful. i've never had to write that 
in the past 9 years or so :)

also, the above is to be recursion safe. in most cases you can just 
use here: rule :here  or something like that.

(or, even use [here] [here: rule :here] might be a better way to 
put it. i was trying to avoid the here: :here thing in the above 
:)

here: :here concept is handy, understandable by beginners in parse 
like me. Adding recursion safety via USE is a good thing. Can't comment 
on AND usability, as I don't precisely understand its meaning ...

Gabriele, that would be one way to do AND (though Peta's workaround 
is probably the most efficient).

AND is a lookahead function, inspired by TDPL theory. Apparently 
PARSE is close to TDPL or PEG grammars, but missing a little.

Well, Peta's additions and changes have been integrated and cleaned 
up. There are more clear guidelines for the project now. Still haven't 
added Gabriele's DO operation yet, though I now know how to do so. 
Anything else?

Brian, good work until now ;-)

Reflecting on words -- where does 'and come from?  Reads a little 
awkwardly:

	cmd: [list [everything]]
	parse cmd ['list and block! into ['everything | 'something]]

'at might be more apt?

	parse cmd ['list at block! into ['everything]]
	parse cmd ['list not at [paren! | hash!] into ['everything]]

yeah i agree AND is not the best word for that job.
i prefer [IF] it means what it does...
But it's not a problem for me to keep AND

for example: [IF block! INTO rule]

it's just a scam, all rules are optionnal within parse... (so IF 
or something else...)

if we take in acount his defintion: none consumming rule.
Then something like REPLAY or REWIND is more adapted.

AND comes from the use of & in the PEG syntax papers, but it could 
also be seen as being like the AND operator in REBOL, prefixed.

Nonetheless, I agree that the names of AND and OF don't make much 
sense. The concept behind AND is sound though.

I have finally adapted Gabriele's DO proposal. Aside from naming 
issues, examples in need of explanation and any nagging questions 
we might be done here, with the exception of feedback from Carl about 
his proposals and any other issues. Anything else?

Added Chris's suggestion for AND to be named AT, and explained the 
advanced AND example (good luck!). If there aren't any more suggestions, 
I think this is ready to go to Carl.

nothing about my ALL ?

sob...

I need to talk to Carl - it's a variant of his OF proposal, which 
probably isn't done yet. I'll bring it up :)

ok, good luck

I edited the OF proposal to provide a syntax description similar 
to the other proposals and added your suggestion, Steeve.

thanks

the parse doc is becoming scary precise :-) I hope Carl is not scared 
by the amount of requests :-) Can't wait to do similar job to low 
level View. Maybe we could start :-)

Maybe we're already working on low-level View :)

ah, can't believe that :-) But - Cyphre would be involved, no? And 
AFAIK he is not :-)

Well then - transparent top window would be fine, but I think that 
more importantly - proper Unicode display should be a priority, and 
maybe looking at R3 alpha demo called button colors - it scrolls 
like molasses - there is either bug and there is more being redrawn 
than what is needed, or we have to think about other optimisations 
(e.g. I remember some 2 years ago Carl stating, that View might still 
render unnecessary things ...)

uh, wrong group, sorry ...

... another option I remember was to switch to compound rasterizer 
of AGG. And - REBOL timers are still substandard of what can be achieved 
imo ... But, as Carl said - those parts are going to be host part, 
hence open-source. We just need Carl to release sources. Hopefully 
it happens till I retire :-) (eventual replies to REBOL3 group, just 
wanted my comments to be at one channel)

Cyphre is a member of the development world for the new GUI.