World: r3wp

I think this can be done by precompiling the parse rule, so that 
every step also does a profiling test. This will slow down the parse 
a bit, but hey, you get your information.

... you can as well use profiler to see, where your parse hangs.

Paul, in the Parse blog comments section:
http://www.rebol.net/cgi-bin/r3blog.r?view=0155#comments

you wrote: "I would like to see Parse be able to return true on Datatype! 
value."

Could you clarify this ?
I think PARSE does this already:
	parse reduce [integer!] [datatype!] ;== true

Maybe you wanted not to have to reduce.  eg:

	parse reduce [ 'integer! integer! ] [ datatype! datatype! ]


would return true, even though only one of the two input values is 
of type datatype!

If that is the case, then I think this came up already some time 
in the past. I think, as then, that it was a bad idea, because it 
causes a distinguishability problem. PARSE would sometimes not be 
able to distinguish between a word! and a datatype!. This would cause 
problems when parsing code, because you would have to test if words 
looked like datatypes, and treat them specially.

Anton, trying creating a word string! and a datatype! string! value 
and insert into a block.  [string! string!]  and then do your testing. 
 I remember discussing this with BrianH when I ran into the issue. 
 I don't have REBOL on the computer I'm currently working from right 
now so I can't present any test at the moment and I'm turning this 
laptop back in to the company soon.

That's essentially the same as the example above, isn't it ?
You want this to return true:

	parse reduce [ 'string! string! ] [ datatype! datatype! ]

?

Yes, I believe we didn't want to reduce.

I don't think there is a way around it at this time without digging 
into parse code itself.

The only thing I think might be nice is to have a serialized way 
of seeing datatypes

in Parse.

so that way you wouldn't need to use reduce.

#[datatype string!]  That way we can read data direct from a file 
port and without loading or reducing use parse to identify respective 
datatypes and datatype!.

Actually, if I recall the problem seemed to be using datatype in 
the rule block as follows:   set n datatype!   And it failed to work.

Mabye someone can confirm.

Well, this works already:
parse [#[datatype! string!]] [ datatype! ]  ;== true

and these:
>> parse [#[datatype! string!]] [set n datatype!]
== true
>> parse reduce [string!] [set n datatype!]
== true

It was the fact that we didn't want to do the reduce on the third 
one.  Not a big deal Anton.  I'm the only one that wanted that functionality. 
 In fact I think I changed my storage medium to workaround the issue.

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