World: r3wp

Interesting! It sounds like it is related to OF, Carl's idea to replace 
DELECT. That would be useful for making DELECT-style dialects without 
the parameters being optional. How important is it that the parameters 
be mandatory?

By the way, Carl has already decided that REP 11 will take the form 
of the USE proposal. The RULE! type will have to wait for UDTs.

Brian, OF optionnal parameters can be constructed using  ALL like 
this:
ALL  [rule1 | rule2 | opt rule3]
so ALL, is more generalist

That sounds good to me. OF is not set in stone yet, so that should 
definitely be brought up. Good idea :)

quickie ... will words set by parse go into a global context still?

Yes, but you will be able to make recursion-safe local words with 
USE.

and will we be able to do things like  [ copy obj/var to something 
]

That sounds like a good idea too.

part of constructing objects while parsing

If you don't know what the field will be, you might want to append 
to the object instead in a paren. Setting obj/var only works if there 
is already an var field in obj, but append will work even if there 
isn't.

mostly I want to collect all the data into a predefined object

but if you  do that you must limit the behaviour of INTO.
currently INTO enter in paren! path! and block!.
if think it's to versatile

to reduce the number of variables I work with

INTO sh

so, for the latter situation ... [ append obj/var to something ] 
will allow me to build the object?

Steeve, have you looked at the INTO parse proposal on the wiki? It's 
at the end. It's my favorite, if only because of the example :)

the INTO/string, yes i always tought it was an excellent idea Brian

ah ok it's covering my request

The INTO and CHANGE proposals were made after I checked with Carl 
that keyword modifiers were workable.

That reminds me, I have a few edits to make.

ah i feel better

after a good beer

Check the page again - you're on it (INTO proposal).

haha seriously, u can't credit me on that, you had already done the 
proposal.

But i will accept the credit if Carl accept the ALL ehancement ;-)

More names are good. (check private chat)

I'm serious about attribution here. I didn't attach my name to any 
proposal I didn't come up with.

check private chat, plz

here we go for proposals

Brian i hear you ;-)

It occured to me (as I'm sure that it has occured to others) that 
it is possible for parse rules to do one bad thing even if you exclude 
all of the modification statements, word setting statements, and 
parens: ANY and SOME can go into infinite loops if they don't advance 
the position. I would like to propose that there be some form of 
warning or error if SOME or ANY loop again on the same position they 
did last time. This condition should be screened for with a PARSE 
refinement. If the refinement is set then when the point is reached 
where ANY or SOME would repeat at the same position, the rule would 
fail (and possibly backtrack to the next alternate).

Maybe that and a few other restrictions could be enabled when a /safer 
refinement is used.

i'm thinking...

Because of get-words there may be times where you don't want the 
position to advance, so this would have to be an option rather than 
standard behavior, or it would be a backwards compatibility problem 
that might not be worth it.

The way the new behavior would be formulated is this: ANY or SOME 
would only succeed if one of these conditions happened:
- The rule argument fails (after the first round for SOME).
- The rule argument succeeds *and* the position changes.

I'm not sure how REVERSE would fit in, but it sounds workable so 
far...

i never had such a case. I don't really see your point. When all 
rules failed in an ANY block, then we have a break

it's the responsability of sub-rules to do some skip to avoid such 
cases

Ah, but if one of the rules succeeds but doesn't advance the position 
(like NONE), you get an infinite loop.

yes but who do such things ?

The reason you would enable this option is to catch sub-rule logic 
errors.

i always take care to advance in the serie

ah ok, it's to help for debugging purposes ?

Yeah, or malicious rules from third parties because you can't easily 
statically determine whether the bug would happen. Most malicious 
rules can be screened for, but others can't. It's a bad idea to run 
third-party rules anyway, but some people can't avoid it.

but i see the interest to set no backwards capabilities in some case, 
we coold have a special command (like FREEZE) to throw an error when 
we have a backward effect

Backwards isn't a problem (especially with REVERSE) - stasis is.

i have to reread the effect of REVERSE

At the very least the infrastructure should be added to detect this 
kind of error so that PARSE tracing can warn about it.

REVERSE changes the direction of PARSE. This helps with recognizing 
language patterns that LR is better at than LL is.

I have some ideas about how REVERSE and should work with backtracking 
that I haven't written down yet.

and ->