World: r3wp

Ah, but if one of the rules succeeds but doesn't advance the position 
(like NONE), you get an infinite loop.

yes but who do such things ?

The reason you would enable this option is to catch sub-rule logic 
errors.

i always take care to advance in the serie

ah ok, it's to help for debugging purposes ?

Yeah, or malicious rules from third parties because you can't easily 
statically determine whether the bug would happen. Most malicious 
rules can be screened for, but others can't. It's a bad idea to run 
third-party rules anyway, but some people can't avoid it.

but i see the interest to set no backwards capabilities in some case, 
we coold have a special command (like FREEZE) to throw an error when 
we have a backward effect

Backwards isn't a problem (especially with REVERSE) - stasis is.

i have to reread the effect of REVERSE

At the very least the infrastructure should be added to detect this 
kind of error so that PARSE tracing can warn about it.

REVERSE changes the direction of PARSE. This helps with recognizing 
language patterns that LR is better at than LL is.

I have some ideas about how REVERSE and should work with backtracking 
that I haven't written down yet.

and ->

i just have a doubt, in my scripts i like using parse to change a 
serie. Some of this rules are recursives so that they can apply several 
modifications on modifications. In such a case i would break your 
rule to not  return in the same point.

That is why it would be optional.

By recursives you meant iteratives. Recursives don't use loops.

I have a set of rules in an any block wich apply modifications, the 
same block of rules is applied until there is no more modifications.
I don't know h

how to call that

That is iterative changes. Each round of changes is an iteration.

ok

That kind of thing can be very powerful. As long as you have a fixpoint 
(a reachable condition to break you of the loop) you'll be fine.

yeah i know it's difficult to create, but when it works it's incredibly 
compact and powerfull, i like compactness

Rewrite rules usually work this way.

about your proposal i just will say that is not an high request but 
if it's free i take it

I think it will be better to include this in the tracing infrastructure.

ok another proposal

currently when we parsing a serie we can't mix constant string! and 
constant binaries together

we have to choose depending of the type of the serie

That will be moreso in R3 because string! and binary! aren't compatible 
any more.

Unicode changes. A binary is a series of bytes, a string is a series 
of codepoints.

AS-STRING and AS_BINARY are gone.

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