World: r3wp

look in:   http://www.rebol.net/wiki/Parse_Project

Read the parse proposals linked above.

its also a good read to know many of the "tricks" in parse   :-)

By the way what I currently have been doing is setting a value to 
another word to differentiate why the parse failed - whether it was 
syntax or because of an invalid word.

(of R2)

I was the editor of the proposals and manager of the proposal process.

I remember posting on the blogs a long time ago... its nice to see 
it was all compiled.... thanks brian !

Yeah currently I would just set another value called 'flag in the 
parens and then check it after the parse was complete.  If it was 
true then I know a word wasn't found.

In theory, the best proposals (I have a list in my head) will be 
able to be compiled to R2 parse rules. Tested theory :)

the whole of the enhancements will make PARSE SOOOOOOO much more 
conscice and fun to use for advanced stuff.     :-)

I now have a real reason to want R3.

I don't  know if  'Check functionality really needs to be BUILT as 
much as just communicated.

Did you see my advanced example at the bottom? :)

It shows the power of parse.

not yet... reading it as I chat, cook and do some income tax stuff... 
I' m a bit like reichart... I've got an exec kernel in my brain  
 ;-)

In fact that method I was showing is how TRETBASE will be parsing 
search criteria to ensure only acceptable words are used in the block 
that will be reduced.

A lot of the workarounds require variables, which can be difficult 
to use concurrently. The proposals are all attempts to get around 
that.

That idea is to put all the operators (since they are words in the 
words containers along with field names which get later set to values 
and other set-words as desired).

the main thing is about the recursiveness.

I do that will calling my rule inside the rule.

remark has a stack which it must manage manually... proposals might 
make some of that management useless.

The CHECK workaround is the easiest way to do reserved words that 
can change at runtime.

Here is what I currently had:


rule: [some [set w word! (unless find valid-A w [flag: true]) | into 
[rule] | any-type!]] ; rule for parsing the Ablock

Actually the last part of that rule was for testing something currently.

I might have a new proposal brian.  but I am reading the whol... 
to make sure its not somewhere in the current ideas.

You would be surprised. The modifying proiposals are not going to 
be expanded though.

Still, if we missed something suggest it here first :)

I had enough trouble with someone who was making hostile changes 
without discussing them first :(

Not that your changes would be hostile, but discussing them is still 
good.

I love the idea of 'REVERSE  :-)

Particularly the REVERSE rule variant. There are some sweet ones 
in there :)

Whoops, Peta added some more false comments. Must fix...

the new stuff allows what I want to do, but still makes it non-trivial... 
a bit like the first example.


a lot is done in so few lines... but its not obvious to analyse... 

my idea was for a system called 'PERSIST

Please go on - we already rejected something with a name like that, 
perhaps yours is different.

as in :

PERSIST rule1 rule2

its a mixture of  [any change at only ]  as your first example

the idea being, as long as rule1 matches, return the AT of that rule, 
executing the second one there.

?

It sounds like AT.

the differentiation is quite subtle, and I am pretty sure that the 
rejected was mine   hehehe.

but new that I  have rebuild remark WITH parse and that I have read 
the proposals, I am in a much better state to explain it, I think.

but it will need precise thinking... something I can't cook up in 
a matter of seconds without generating a lot of short questions like 
the above.

Cool. I understand everything on that page, so your timing is good 
for a discussion :)

a better way of calling could be 'UNFOLD if you think about it functionally.

remark is the basis for my proposal.   I can already to what I propose 
in parse v2... but I beleive it could be done so simply and could 
reduce your first example (the recursive file list) to a 5 line affair.

maybe even less ;-)

so I'll try to cook up an example of how it would be used, and the 
effect it would have... then you can tell me if I'm nuts  ;-)

I finished the Parse Proposals cleanup again. Enjoy!

so, I put a lot of thought into it, and with the new stuff... especially 
  'CHANGE  'AT 'ONLY ,  the problem with 'UNFOLD is that its too 
problem specific.

the general idea was to build a system which basically does an:

rule: [ any [at change only [  rule  ]] | skip]


the problem is that what to skip and what to change, differs from 
problem to problem, and since these are tied up within subrules, 
they become hard to use within a generalized procedure.


in R2 the above is pretty harsh to implement, although it can be 
done... with the use of the 'USE operation, these words already make 
recursivity and stack issues pretty easy to tackle..

hehe... synchronicity.

CHANGE doesn't work the way you think it does - look again.

no I really did a good read, and understand your example... its the 
'AT which does the trick.