World: r3wp

but at certain point a string can be converted to a binary an vice 
versa

Yes, but that is a real conversion, with encoding and decoding.

Just like converting from a .jpg to an image! and back.

when u say 'real' u mean a large time consuming conversion ?

Hopefully not time-consuming but definitely large, depending on the 
size of the string.

The Unicode changes were pretty significant and deep.

not the subject, but speaking of consuming operations, what about 
the old idea to have subset of serie (range) without the need to 
copy/part series ?

Carl spoken of that in the past

*abouty

It was rejected as a base type because it was deemed unnecessary, 
but could be added as a UDT.

UDT ?

about proposals, currently we have only one atom operation to control 
advance in the serie: [skip].
We could had some other atom operations, like DROP,SWAP,ROT,DUP.
(any reference to FORTH language are intentional)

don't ask me an usage, it's only because i'm currently working on 
a FORTH engine

UDT = user-defined datatype!, a planned feature of R3. Yes, this 
includes user-defined function types in theory.

DROP, SWAP, ROT and DUP are stack modification operations, not parse 
advancement operations like SKIP. Don't forget REVERSE and matching 
operations - they advance too.

My bad: REVERSE doesn't advance.

i know what they are (trust me) it was a sort of transposition to 
parse

image just that parsing a serie is like working with a stack, the 
analogy is not as bad as you think

*imagine

in an other way, SWAP, ROT, DUP or DROP are not just advance operations 
, they modify the serie too.

... I really don't what could be their usage, forget that...

*don't know

Just some ideas for possible usage.


[[item1 item2 | item2 item1 SWAP] ]   ; Put previous two matched 
items in order.
==> [item1 item2]  ; Always sorted.


[ROT [a b c d e]] ;  Rotate items matched by next subrule, if it 
matches. 
==> [b c d e a]  ; 


[start: a [b c] DUP start]  ; Duplicate items from start to current 
parse index.
==>  [a b c a b c]


[a DROP [b c]] ; If next subrule matches, then remove items matched, 
and set parse index back to the beginning of the remove.
==>  [a]

(DROP is just like REMOVE, so not really needed, I think. Just doing 
the exercise to see.)

The above can be categorized by how they fetch their arguments:
- Take two previously matched items/subrules (like SWAP).
- Match the next subrule (like ROT, DROP).
- Use a variable to take the parse index (like DUP).

well done Anton. To have a more genralized form, all these operations 
could work on an Index, like your DUP

We can implement DUP today using our own function (not a parse command). 
The equivalent to above DUP example would be:

[start: a [b c] finish: (DUP start finish length: finish - start) 
skip length]
or maybe

[start: a [b c] finish: (DUP start 'finish) :finish]  ; (where DUP 
modifies 'finish)

So that's what the DUP command would save us.

BrianH: as for parse catching infinite loops - don't you think that 
ppl would always want to be protected by such a feature? So why not 
make it standard? How usefull is parse, if it loops infinitely? Your 
app hangs, or crashes anyway ...

not always. if you need maximal speed. and you  trust the data and 
rules.

Hanging parsers to me is usually a problem when developing them.

Steve said in r3-alpha world:

Sometimes some of my parse rules can take overnight to resolve on 
some complex random files...and I would like to be able to set a 
time limit in parse so that if it is recursively grinding on time, 
that I can halt it

So Steve needs to leave his parse rule unattended for long periods.

And when he returns, if it timed out, he wants to see where it got 
up to.

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.