World: r3wp

but i agree that Ladislav''s rule is more secure

I suppose any data can get damaged, so it is better for the rules 
to crash & burn than hide the fact that the data is damaged

digit: charset "0123456789"
alpha: charset [#"a" - #"z" #"A" - #"Z"]

prefix: [1 2 digit]
sufix: [some digit opt ["-" some digit]]
range: [copy range! [prefix #"/" sufix] (prin ["range:" range!])]

rand: [copy rand! [1 4 digit | some alpha] (prin [newline "random:" 
rand!])] 

target: [rand range any [#"," range]]

parse/all inp [some [target | skip]]

is that ok ?

hmm, random is optionnal, so it should be:

target: [opt rand range any [#"," range]]

/all has to be removed i guess

I think this is what Ladislav has given us so far:
alpha: charset [#"a" - #"z" #"A" - #"Z"]
a-word:  [some alpha]
one-to-two: [#"1" - #"2"]
digit: [#"0" - #"9"]
non-zero-digit: [#"1" - #"9"]
a-number: [one-to-two 3 digit | non-zero-digit 0 2 digit]
random-part: [a-word | a-number | none]


record: [random-part whitespace repeated-part any ["," repeated-part]]


I understand how it relates to the data, but not how to use it to 
extract the bit I want....

what is the data you want? (comming in late on this discussion)

the data is structured with a key words or a vlan number followed 
by ports & ranges of ports. (like 2/2,2/4-6)
I want to restructure this data so I end up with
port 2/2 vlan55 disabled name3
port 2/4 vlan55 disabled name4
port 2/5 vlan88  named somthing else

the generall concept: 

   Once you match data, you add a parens, in which you add rebol code 
   to execute.

first I am extracting the ports & ranges from the data. after that 
I need to recreate the actual ports and key information & do that 
for several types of input & colate it.

if you need parts of the data in your parens, the you add pointers 
to the data within the rules (use copy or here:) and se those within 
the processing parens.

Do you know where Ladislav was heading with his suggestions? I understood 
what he was saying, but not what he was going to do with the structures 
he recomended.

I understand his rules... look at steeve's rules, they already include 
parens, where he lists the data.

that is where you execute stuff.

so you'd just create a block before the parse, and dump the data 
which you want in there, using your new structure.

Am I making sense?

So do you think Ladislav thought he had described everything he needed 
to? because he had a rule that would match part of the data & could 
be skipped on finding each match in turn somehow...

it looks complete for a single record

but steeve's might actually be simpler and already includes the basis 
for what you want to do... it you try his rules on your data?

it = did

I tried Peters rules & Steves first rules, then Ladislav gave me 
some more structure to it which seemed like a good idea when things 
get more complex. But I cant quite fit it all together.

This AltME client is hard work too, why dosn't the group have a web 
based forum, then I could access it on the PC where my development 
is being done too. AltME is a NoNo for corperate use.

reboltalk.com would be a possibility if it wasnt so embarassingly 
full of spam

I think one of the most confusing things about leaning Parse, is 
the occurance of  some & any & | , and the use of [ ]  

the constructs are quite straight forward, but the need for [ ]  
etc is a raw mystery to me.

[ ] identifies rules which must ALL match as a group.

or a roll back occurs at the start of the [ ]  and tries the next 
rule following a "|" in the current rule (if any)

its pretty much the same as parens in regexp actually.

altme should use port 80 :-(

it is installing non aproved applications that is the issue, and 
the need for a proxy config? perhaps that is covered.  I may just 
install it I suppose.

So the parse keeps going inside the [] till all the | are exhausted 
or it gets a match. then looks for the next | in the outer nesting 
of [] ??

almost.  if one of the options match (  [option1 | option2 | option3] 
)

then the rule itself is considered a match and it won't attempt the 
other option.

That is what I meant to say.

so if the current rule is an option, then it will match too.

read the "|"  as: "continue if  previous rule didn't match"

I read "any" matches 0 or more occurances --- I dont understand what 
that means in practice. it sounds like a loop perhaps?

I can see any digit  makes sense

but not any [long expression]

parse {aaa} any [[here: "a" (print here)] | [skip] ]  does not work 
for how I imagine.. I expect it to return aaa aa a

it simply means that the following rule won't cause the current to 
fail even if it doesn't match any  [long expression]

that's what it returns here... ' :-/

note: above should be...

parse "aaa" [any [[here: "a" (print here)] | [skip] ]]

any outside of parse is something else.

even if it's similar in intent.

my first any needs to be inside the [ ... that would seem to mike 
it apply to the "a"

>> parse "aaa" [any [[here: "a" (print here)] | [skip] ]]
aaa
aa
a
== true

>> parse "zaz" [any [[here: "a" (print here)] | [skip] ]]
az
== true

>> parse "zzz" [any [[here: "a" (print here)] | [skip] ]]
== true

that seems logica, but this does not
 parse {aaa}  [any[here: "a" (print here)] | [skip] ]
aaa
aa
a

note that the rule returns true everytime.  it did not fail.

why does it skip in my example?

it doesn't... each time it hits "a" the first rule matches.