World: r3wp

I started looking at the R3 Gui too.  I am mostly intrested in drawing 
my own graphics on screen, controled by a bit of maths & trig, but 
with real-time interaction from sliders etc.  I suspect this is not 
the sort of thing that newbies are expected to do, but writing text 
in different fonts on coloured buttons dosn't do anything for me.. 

I am finding that using any part of Rebol makes it easier to understand 
the discussion here & get more in tune with what behaviour to expect.

I have been working on my Parse understanding and came up with this:
parse/all {aX--baX~~a--aX~~} [some
  [
    "a" h: some[ 
      [ 
        ["--" :h copy result to "--" (print result) thru "a" h:]
        |["~~" :h copy result to "~~" (print result) thru "a" h:]
      ] |[skip]
    ]
  ]
]
I am extracting the text between "a" and either "--" or "~~" 

Is my method a reasonable aproach or is there a simpler or more readable 
way to do this sort of thing please?

here is my way:
parse/all {aX--baX~~a--aX~~} [
	"a"
	some [
	    s:
		any [
		    t: ["--" | "~~"] (result: copy/part s t print result) break
			| skip
		]
		thru "a"
	]
	to end
]

If the empty one doesn't need to be recorded as empty:
parse/all {aX--baX~~a--aX~~} [                             
   some [

      ["a" some ["--" break | "~~" break | X: (print X/1) skip] | skip]
   ]
]

Mine'll also only grab one character at a time, so {abbb--} would 
need something extra

If it's a fixed length format .. why bother use parse and just use 
copy/part ?

Thanks for the examples, I will be digesting them for a while I think.

I started looking at a real life problem where the ending sequence 
of what I wanted to extract was two different things (". " OR "." 
newline), that led me to look at this sort of structure & try to 
understand how parse rules can be adapted.  My example is educational 
only, not from real life. It was intended to be a short example of 
non-fixed length format with multiple cases to extract and 2 different 
end-of-data-to-extract markers. I think a better example of what 
I intended should have XX as the data to extract in one case. {aX--baX~~a--aX~~aXX~~} 
perhaps.   Thanks.

Righto, here's my updated one - good practice for me, too, I rarely 
use parse like this:

parse/all {aX--baX~~a--aX~~aXX~~} [                              
          

   some [                                                           
             

      ["a" S: some [E: ["--" | "~~"] (print copy/part S E) break | skip] 
      | skip] 
   ]
]

Lot of ways with parse...

content: complement charset "-~"
parse/all {aX--baX~~a--aX~~aXX~~} [

   some [                                                           
             

      thru #"a" opt [copy result some content ["--" | "~~"] (print result)]
   ]
]

It is strange this parse learning..  I look at these rules & understand 
what is happening.  BUT I try to write my own without looking at 
these & I always get confused again.  It dosn't seem very complex, 
but it does seem very easy to get wrong. Does any one have any tricks 
for formatting the code in a way that helps keep track of what the 
logic is doing?

Have you looked at brett handley's visual parse thing?

http://www.rebol.org/view-script.r?script=parse-analysis-view.r

I remeber looking at this before, but I couldn't work out how to 
use it... With a bit of luck I will understand it now, although it 
does look quite complex. Thanks.

Looks like the instructions are written for someone who already knows 
how to use it...
- run the script  ## this dosn't seem to do anything

- Run the parse-analysis.r script and use the tokenise-parse function 
to get the base data.  ## dont understand what this means, tried 
a few things but they all give errors.

The example works, but I cant even see the parse expressions in it 
so I dont understand why it works or how to adapt it for my own example.

When I first looked at this in April I got quite frustrated because 
it looked as if it was there to help newbies learn about parse, but 
it was too hard for newbies to understand how to use... now I can 
at least understand how to run the example.  Thanks

I sympathise....the documented examples for parse-analysis are certainly 
less than clear on what steps you need to take to prep a parse for 
analysis.


If you have worked it out for some simple examples, then adding a 
discussion thread to the script may help other's in future.

I will work it out, I am determined.  Thanks for your encouragement.

I often have trouble visualizing how things work, and I don't feel 
that I really understand something until I can do that.  With PARSE, 
even though it can be tedious and create volumes of output, it may 
help to write some simple grammars and have it print output for every 
rule. Have a probe at the start of the rule, and a probe if it's 
successful, nesting the output helps a lot too.


Don't get discouraged, it's not an easy thing to grok for a lot of 
people.

In my largest grammar, where incoming data may be malformed, I've 
found it invaluable to have the rule tracing built in, enabled by 
a flag. e.g. 

    TSAFE-CHAR: [
        (rule-trace "TSAFE-CHAR IN")
        copy =TSAFE-CHAR charset-21
        | charset-22
        | charset-23
        | charset-24
        | charset-25
        | NON-US-ASCII
        (rule-trace "TSAFE-CHAR OUT")
    ]

    rule-trace: func [value /local rule-name action] [
        rule-name: first parse value none

        ;print [tab rule-name tab found? find don't-trace rule-name]
        action: second parse value none
        if all [
            any [
                trace-rules? = true
                action = form trace-rules?
            ]
            not found? find don't-trace rule-name
        ][
            val: attempt [mold get to word! join "=" rule-name]
            print ["===" value  any [val ""]]
        ]
    ]


Don't-trace allows you to turn off selected rules that may get called 
a lot. You could also set tracing levels if you wanted.

This makes it easy to test input that doesn't parse and, if I can't 
find the problem or location quickly, turn on the trace and see exactly 
where it fails. 


I've also thought about, and asked Carl for, a way to get the position 
where the parse failed, including a line number.

Thanks for the extra comments. was working all last night & with 
my daughter all day so not found enough nureons to study this yet. 
 Thanks.

The main thing I do is, at some point that happens a lot in the code, 
display the data.  Makes it easier to step through the code and do 
- in your head - what the code is doing.  If it suddenly doesn't 
match up, the loic somewhere was wrong.  For example, when working 
on the last one, I had to debug part of it and did this:

parse/all {aX--baX~~a--aX~~aXX~~} [                              
          

   some [                                                           
             

      ["a" S: (? S) some [E: ["--" | "~~"] (print copy/part S E) break 
      | skip] | skip] 
   ]
]

I seem to be going backwards with learning this. Perhaps I think 
I know the grammer, but don't.

I am trying to write out long hand what I want to do, then convert 
it to a parse, but I dont have any words to describe how parse skips 
back to a previous point, so I cant write what I want to do long 
hand either..  e.g. gather the x in pairs from {fd doixx s x x x 
oie    x }

test for "x" or skip  then when x is found do the same thing but 
escape to the outside loop.   

If I could write the above in a format that made more sense I think 
I would have a better chance of then converting it to a parse.

test for "x" or skip seems to be   ["x" | skip]

doing it twice to get the x in pairs would seem like  ["x" | skip] 
["x" | skip] 

but that dosnt work because it lacks the loop control so I add that 
by a bit of guess work because I dont understand it properly.
parse/all data [some[["x" | skip] ["x" | skip]]]

but this is just completly wrong & I think the reason it is wrong 
is because I have completely misunderstood some or skip or | or where 
the point in the string the parse pointer gets to after each step.... 
 I have tried using OPT & break in the second section but just get 
more muddled.

Gregg's suggestion sounds as if it might be helpfull, but I cant 
understand it yet.  Izkata's suggestion is very helpfull, but in 
my case tends to just show that I am miles away from anything like 
a solution.  Thanks.

Often there are ways to work round these needs to be more efficent 
with Parse (like editing the data to be parsed before you start), 
but it would be nice to understand how the loops work enough to use 
them & start developing more resiliant parse rules.

MIke, my first advice would be to avoid trying to "go back" during 
a parse operation at this stage. I think that is something to leave 
until you feel more comfortable with parse.

If possible, it would probably better to forget the concept of loops 
when thinking about parse too.

Perhaps a good starting point is to think that when you "parse" something, 
you are asking does it conform to the rules I have supplied. If it 
does parse returns true, if it doesn't parse returns false.

>> parse "abcdefghi" ["abcdefghi"]

== true

>> parse "abcdefghi" ["abcde"]    

== false

You're already familiar with to,thru,  end and to end: 

>> parse "abcdefghi" ["a" to "i"]
 
== false
>> parse "abcdefghi" ["a" thru "i"]
 
== true
>> parse "abcdefghi" ["abcde" to end]

== true

Perhaps the second thing to realise is a rule can be split into "sub-rules':

>> parse "abcdefghi" ["abcde" "fghi"]

== true

Each "subrule" can have some Rebol code executed if it is "triggerred":


>> parse "abcdefghi" ["abcde" (print "abcde found") "fghi"(print 
"fghi found")]

abcde found

fghi found

== true

>> parse "abcdefghi" ["abcde" (print "abcde found") "xyz"(print "xyz 
found")] 
 
abcde found

== false

(What Gregg referred to was a much more sophisticated way of getting 
the parse to show you what happened).

Sub-rules can be optional by using the | (or) and enclosing the options 
in a block:


>> parse "abcdefghi" ["abcde" (print "abcde found") ["fghi" (print 
"fghi found") | "xyz"(print "xyz found")]]                       
                                                   
abcde found
fghi found
== true

Sorry about the formatting, It's one of the big problems with AltME 
under Mac OS X.

Skip tells parse to move to the next item:

>> parse "abcdefghi" ["abcdefgh" skip]
== true   ;; because the skip took us to the end

We can specify that a sub-rule should be repeated:


>> parse "abcdefghi" ["abcde" 4 skip] 

== true

A better example of repetition:

>> parse "aaa" [4 "a"]

== false

Some and Any are forms of repetition, this shows the difference:

>> parse "aaa1000" [some "a" to end]

== true

>> parse "aaa1000" [any "a" to end] 

== true

>> parse "bbb1000" [any "a" to end]   

== true

>> parse "bbb1000" [some "a" to end]

== false

I apologise if you are already happy with these basic concepts, in 
which case I hope you don't mind the refresher.

Maybe these are some variations of what you are looking for


parse/all "fd doixx s x x x oie    x } " [some [copy d   "x" (print 
d) | skip]]


parse/all "fd doixx s x x x oie    x } " [some [copy d 1 2  "x" (print 
d) | skip]]


parse/all "fd doixx s x x x oie    x } " [some [copy d  2  "x" (print 
d) | skip]]


parse/all "fd doixx s x x x oie    x } " [some [copy d   "xx" (print 
d) | skip]]


parse/all "fd doixx s x x x oie    x } " [some [[copy d  "x"  copy 
e  "x" (print [e d]) ] | skip]]


parse/all "fd doixx s x x x oie    x } " [some [ (g: copy "" ) 2 
[copy d  "x"  (append g d)  ]  (print g )  | skip]]

or you are looking for the pairs

 parse/all "fd doixx s x x x oie    x } "  [ some [  [ (g: copy "" 
 ) 2 [ copy d "x"  (append g d ) any notx  | skip  ] (if not empty? 
 g [print g]) ]  ] ]

I forgot notx

notx: complement charset "x"

parse/all "fd doixx s x x x oie    x } "  [ some   [ (g: copy "" 
) 2 [ copy d "x"  (append g d ) any notx  | skip  ] (if not empty? 
g [print g]) ]  ]

Thanks PeterWood. I like to think I am ok with the most basic concepts, 
so now I am trying to learn things that will help me some my real 
life probelms in a better way.  I use parse pretty much every day 
& always have a rebol console up on my work PC, but ANY SOME & OPT 
& |  I do not understand in context.  I understand them in abstract 
terms, but not how to apply them in conjuction with [] . I do understand 
your examples of some & any (these examples are usefull to me). skipping 
an un-known number of chars to get to the next match is the bit I 
find hard to understand how to construct, paticularly if it needs 
to be done in the context of a previous match.

sqlab, I dont know about this syntax at all. I dont think I understand 
what is happening here.

copy to "x"  & copy thru "x"  I understand, but copy "x"  I didn't 
expect to see.

In the parens you use the COPY function, not the PARSE copy operation. 
Is that what you meant?

The compliment syntax & the    to 1 3 digit   where digit is a charset 
seems to be "unreliable" as far as I can understand.

this is what I dont expect.

parse/all "fd doixx s x x x oie    x } " [some [copy d   "x" (print 
d) | skip]]

I dont think I have ever seen the PARSE copy operation documented. 
  I will have  a hunt for it.

have you ever read the parse documentation in the old RT publisehd 
rebol 2.3 pdf  ?  its a good reference... there are only minor changes 
from that version up to the latest... I don't think any of the examples 
would fail in the current parse.

chpter 15 or the Rebol Core Manual  http://www.rebol.com/docs/core23/rebolcore-15.html
 may have a use of this syntax in a complicated example, but no description 
of what is happening exactly.