World: r3wp

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.

You are missing a parameter in your example.

along with 'ANY which reparses until nothing was changed... that's 
the basis for my original proposal...  it reparses until nothing 
changed...

oh... sorry didn't get that... yes  there would be an extra paren 
there.

CHANGE works like that already. If the rule it is matching fails, 
the change fails.

I'm probably not getting you...

but, in R2,  I'm not using it for some reason I don't remember... 
I actually use the change/part within a paren and manually set the 
series using the :here trick.

Right. All of the PARSE proposals have (awkward) R2 equivalents :)

ahh... its all string based.

yep... cause I've been doing all of them in remark for a year  :-)

although the 'USE really makes a BIG capability boost in PARSE.

I had to clean up a few REBOL 2 assumptions in the proposals list, 
mostly by Peta, through no fault of their own :(

so I'll go back to the batcave and continue working on remark v2, 
and some other stuff... I want to release since a long time

its fun to be able to read all that stuff about parse and *get* it.

Yeah, the R2 equivalent of USE is the most awkward :(

not so long ago, it used to be magic...  nothing to big, or I'd get 
really lost.

The biggest problem you would have if compiling the new rules to 
their R2 equivalents would be to generate all of the intermediate 
variables and make sure their bindings are not corrupted on recursion.

If you weren't careful you could easily overflow system/words :(

Must go now - it's been fun :)

yes cool.  ciao...

I finished the Parse Proposals cleanup again. Enjoy!

I have read the cleanupped version. I like the "To-Thru" proposal 
to match for multiple ends but I have read that full grammar could 
not be used for "performance reasons".

However the proposal is really big and I think that implementing 
it would not be so easy and fast. Will we see it complete at the 
end of 2009 ? It is only Carl working on it :-(

The real advantage to the TO/THRU enhancement comes when it lets 
you avoid creating charsets, which are a lot less useful with Unicode. 
It should be pretty easy to implement.

I think that the proposals are more than Carl was thinking they would 
be - apparently he had forgotten the previous proposal lists. I don't 
think that it will be too much of a problem though, as there are 
not really that many proposals that are likely to be accepted. Some 
are competing proposals, of which only one would be chosen. Also, 
there aren't that many proposals overall - they are just thoroughly 
specified.

Lets see how things evolves. Proposal are very interesting as they 
would easy a lot of work on building parse rules. Everything is silent 
apart some blog messages where I have read for the first time the 
word "Beta" connected with REBOL3.

(*ease)

Good night. Here in Italy is 20 past 1AM.

My main concern is that Carl's main requirements of the proposal 
process have been ignored in some cases:

- That the proposals be concisely specified. The Purpose and Importance 
statements should be one sentence each.
- That there be no discussion of theory.
- That there be no specification of equivalent rules.
- That all discussions happen outside of the wiki.
- That this is a proposals page, not documentation.

While I appreciate the speculative documentation, it will need to 
be moved to another page once the proposals process is done.

As it is, I hope Carl will read a paper that long when he gets to 
the point of taking on PARSE.

The whole point of the proposals process was to prevent exactly what 
happened, so in that respect I failed.

If Carl sticks to his word in his intial request all the proposals 
will be rejected:


Each improvement will require test code be provided that would certify 
its correctness. No test code, no improvement. (Sorry... you often 
ask me what you can do to help. Please don't put the burden of testing 
such changes on me.)

The test code hasn't been written yet.

The initial request was not the blog post - that came later.