World: r3wp

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.

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.