World: r3wp

Yes; ANY is a shortcut for OR'ing vaues together, and ALL is a shortcut 
for AND.

I use ANY and ALL a lot because they can be handy in situations where 
an EITHER can be too cumbersome, such as inline result output for 
printing:

print any [select names name "No Name Found"]

In other cases they take up more space than an EITHER.

unlike a series of and/or  any/all will stop evaulating conditions 
at the first condition that deternims the result

so the first true for any  and the first false for all

Mike, memoizing has never caused me any technical problems. Just 
be sure to document it clearly.

I take that back, I've messed up a couple times and created uncontrolled 
growth in the memoized data. You do have to watch out for that. :-)

instead of:
any [ do[a: 1 false] ]
why not to use just:
any [ (a: 1 false) ]

That is interesting Oldes.  I thought I tried something like that, 
but now I see I must have been confused about what the () do.

so does the ANY cause the () to evaluate its contents?  If I just 
put [(true)] it is not evaluated, but all[(true)] is.   Then again 
to-logic [(false)] is not evaluated. There must be a trick I am missing 
here I think.  Thanks,

Yes, ANY and ALL evaluate the block.

And parens are evaluated by default.

>> first [(true)]
== (true)
>> type? first [(true)]
== paren!
>> type? first reduce [(true)]
== logic!

One of my biggest AHA moments in REBOL was seeing that there is no 
code, only data that *may be* evaluated, and knowing when evaluation 
occurs is key (and easy to trip over :-).

Using blocks and *not* evaluating their contents--perhaps "deferring 
evalutation" is a better way to say it--is also a powerful aspect 
of REBOL. Being able to prevent parens from being evaluated is a 
good example.

I think I would love to know when evaluation occurs.. So far I mostly 
just have to test every fragment of code I write & if I am lucky 
I guess right first time. I am slowly getting better at it, but I 
would say it is often a bit of a mystery.

I have submitted a script to the Library.  http://www.rebol.org/view-script.r?script=cisco-extract.r

Its purpose (apart from learning Rebol) is to read Cisco config files 
& present the interface information in a tab separated text file.

Hi, I have done a bit with fairly basic parse expressions, but I 
am now trying to understand more.

Am I right to think that ALL SOME & ANY are the only controls of 
this type?  Or am I missing another in the set?

Do ALL & ANY work in the parse dialect the same way that they do 
described above?  Thanks.

ALL is not an operation in the parse dialect. ANY and SOME are looping 
operations in parse.

Ah. that is why I am getting erros with it.  I thought I was just 
using it wrongly. Thanks.

The errors are rather cryptic

ANY is like regex *, SOME is like regex +, OPT is like regex ?.

is there any way to get rebol help on the parse dialect?   like ? 
PRINT etc please?

You have to look online, sorry.

ok.  I really like the ? help functions. While learning they help 
a great deal.  Thanks.

Unfortunately, parsing is considered a hard subject. Learning PARSE 
might take some time if you haven't had experience or taken a class 
in parsing before, even when you read the online docs.

Do you think proposed parse enhancement will slow parse performance?

Some of them will speed up parse performance, others will have little 
effect outside of their specific operation.

Performance should improve overall with the parse enhancements, in 
theory.

There were almost no changes to existing operations. Most of the 
proposals were for new operations that would replace complex code 
patterns, and those would be faster, easier and less buggy than the 
code patterns they replace.

I had a really usefull walk-through of Parse with Maxim a few weeks 
ago here.  I wouldn't say Parse has been any harder for me to learn 
about than any other aspect I have delved into so far, in fact I 
found the GUI stuff the most confusing to get ahead with.

new GUI should be much better to understand ...

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.