World: r3wp

i really think it's not feasible without using counters

I think I have it
define a rule;
rule: [1 ["A" | "B" | "C"]]
then parse
parse "cAB" [[rule] [rule] [rule]]

the one indicates that there must be an occurence of one of the three 
characters... supplying the rule then requires three characters to 
be entered.

... but it allows multiple characters... damn

and it works too with the serie "AAA"

which is bad

yrp

parse can change the string as it goes right?  What if you tried 
marking them off with X's as you found them?

I was thinking the same thing, removing each character from a block 
as each rule is processed.

yeah it's possible but it's like hanging counters, you need to have 
some code to check the result and allowing the parser to continue 
further

so your ideal solution would not use anyting other than parse?

yeah i would use a clean dialect , cause i have many many rules of 
this type

moreover , i just  don't want parse simple series like "ABC"

what about a 'unique function or something that tests the string 
for unique characters?

... then parse

as i said , it was just an example , in fact in my case: "A" "B" 
and "C" are complex subrules, so unique don't apply

I think you've lost me.  So when you say sub-rules, you are really 
saying sub 'parse' rules for your dialect?

yep

Will there be more than three rules possible?  You indicate "A" "B" 
and  "C", but could another instance of this also have a fourth character?

each being unique sub-rules

yep, it's not limited

but when i say complex sub-rules , i mean that i have not to check 
single character only, but complex sentences

so the parse string would be better indicated something like "A B 
C" where each of those characters could be a sentence?

yep

so this is close, with the exception that it does not allow for easy 
testing of unique terms being passed?
r1: "Sent frag 1"
r2: "Sent frag 2"
r3: "Sent frag 3"
r4: "Sent frag 4"

rule: [1 [r1 | r2 | r4 | r3]]


parse "Sent frag 1 sent frag 3 sent frag 4 sent frag 2" [[rule] [rule] 
[rule] [rule]]

wrong, same problem ever, if it's the same sentence many time

yes, that's what I stated above, if it wouldn't allow for the same 
value to be passed twice, this would work.

yep

I guess I don't understand why a unique function wouldn't work as 
a test prior to parsing.

;very basic example - 
unique: func [str][
	compare-set: "ABC"

 either "" = difference str compare-set [return true][return false]
]

;;;; and yes, that is very ugly

replace;   either "" =
with:   either empty?

... and of course 'unique shouldn't be used as a name due to Rebol 
already having a unique function.

unique works for the rules which use simple constants, but i said 
it, i use more complex rules

parse data [all [rule1 | rule2 | rule3 | rule4]] 

all rules must apply 1 time and 1 time only  in any order, don't 
focus on what is inside rules (it contains sub-rules which contains 
sub-rules).

Ok, this is convulted and probably wrong


rule: [copy res subrule (remove/part find subrule compse [| (res)] 
2)]
subrule: ["filler" | "a" | "b" | "c"]
parse "fillerabc" [4 [rule] end]


Remove the alternatives from the rule as you find them...the filler 
is to allow | "a" to be found.

argh, this is uggly :-)
not better than my current solution using counters

Yep...convoluted and hard to verify all the cases to boot.  :)  I 
wouldn't use it to be honest, but it was teasing my brain too much...

Now, I'll slowly back out of the room...ducking and dodging...  :)

take a whisky on the rocks

i got a beer

This has it...
r1: "A"
r2: "B"
r3: "C"

rule: [opt [r1 r2 r3]]

parse "ABC" [[rule] [rule] [rule]]

opt = match zero or one time

don't ask me to explain it, but it seems to meet your sample requirements

have you tested ? doesn't work at all for many cases

>> parse "BC" [[rule] [rule] [rule]]
== false

>> parse "ABC" [[rule] [rule] [rule]]
== true

>> parse "BBC" [[rule] [rule] [rule]]
== false

parse "CBA"  = false

in any order, i said

damn, doesn't handle the varying order of elements