r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Parse] Discussion of PARSE dialect

Brock
27-Jun-2007
[1993]
... but it allows multiple characters... damn
Steeve
27-Jun-2007
[1994]
and it works too with the serie "AAA"
Brock
27-Jun-2007
[1995]
which is bad
Steeve
27-Jun-2007
[1996]
yrp
btiffin
27-Jun-2007
[1997]
parse can change the string as it goes right?  What if you tried 
marking them off with X's as you found them?
Brock
27-Jun-2007
[1998]
I was thinking the same thing, removing each character from a block 
as each rule is processed.
Steeve
27-Jun-2007
[1999]
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
Brock
27-Jun-2007
[2000]
so your ideal solution would not use anyting other than parse?
Steeve
27-Jun-2007
[2001x2]
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"
Brock
27-Jun-2007
[2003x2]
what about a 'unique function or something that tests the string 
for unique characters?
... then parse
Steeve
27-Jun-2007
[2005]
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
Brock
27-Jun-2007
[2006]
I think you've lost me.  So when you say sub-rules, you are really 
saying sub 'parse' rules for your dialect?
Steeve
27-Jun-2007
[2007]
yep
Brock
27-Jun-2007
[2008x2]
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
Steeve
27-Jun-2007
[2010x2]
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
Brock
27-Jun-2007
[2012]
so the parse string would be better indicated something like "A B 
C" where each of those characters could be a sentence?
Steeve
27-Jun-2007
[2013]
yep
Brock
27-Jun-2007
[2014]
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]]
Steeve
27-Jun-2007
[2015]
wrong, same problem ever, if it's the same sentence many time
Brock
27-Jun-2007
[2016]
yes, that's what I stated above, if it wouldn't allow for the same 
value to be passed twice, this would work.
Steeve
27-Jun-2007
[2017]
yep
Brock
27-Jun-2007
[2018x4]
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.
Steeve
27-Jun-2007
[2022x2]
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).
btiffin
27-Jun-2007
[2024]
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.
Steeve
27-Jun-2007
[2025]
argh, this is uggly :-)
not better than my current solution using counters
btiffin
27-Jun-2007
[2026x2]
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...  :)
Steeve
27-Jun-2007
[2028x2]
take a whisky on the rocks
i got a beer
Brock
27-Jun-2007
[2030x3]
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
Steeve
27-Jun-2007
[2033]
have you tested ? doesn't work at all for many cases
Brock
27-Jun-2007
[2034x3]
>> parse "BC" [[rule] [rule] [rule]]
== false
>> parse "ABC" [[rule] [rule] [rule]]
== true
>> parse "BBC" [[rule] [rule] [rule]]
== false
Steeve
27-Jun-2007
[2037x2]
parse "CBA"  = false
in any order, i said
Brock
27-Jun-2007
[2039]
damn, doesn't handle the varying order of elements
Steeve
27-Jun-2007
[2040]
:-)
btiffin
27-Jun-2007
[2041]
Yeah, this problem needs to allow alternatives and then remove them 
(or Steeve's counter)
Steeve
27-Jun-2007
[2042]
agree