World: r3wp

Steeve, your latest suggestion is very similar to the RULE! type 
REP (11). Unfortunately, Graham is right that this would basically 
require rewriting PARSE from scratch as a function type. This is 
something I have wanted to do for years, and will get the chance 
to do so once R3's user-defined datatypes are available. I like the 
way you think :)

I was not putting my name everywhere on those proposals. I only put 
my name on the proposals I came up with personally, including proposals 
from the REPs that I came up with during the conversations that led 
up to the REPs being collected. The issues that I say have been resolved 
were resolved in conversations with Carl earlier this week. We had 
already been discussing these problems for a couple days before you 
joined in.

ok it is only that the decision process seemed a bit opaque

Almost all of the proposals in the Parse Proposals page are derived 
from Gabriele's parse REPs page. Most of the subsequent requests 
were covered by one or more of those REPs. We had a pretty exhaustive 
discussion about the subject years ago and PARSE hasn't changed since, 
so its problems and limitations have been mostly the same.

I am not being pretentious - I really did come up with those proposals 
on my own before the first comment was made to the blog or here. 
I have been asking for more proposals but so far there haven't been 
that many that weren't already covered. And it is not a problem for 
me to reject proposals - it is my job. I've already pushed through 
more proposals than Carl is comfortable with, but I have hope that 
they will be accepted. Please give more suggestions, but consider 
that they will be debated before they will be accepted. Only the 
best would even be considered by Carl (he's got more stringent standards 
than mine).

The final decisions are made by Carl. He's the language director 
and he'll be implementing this stuff. If he say it can't happen, 
it can't happen. If I say that it can happen later when another feature 
is added, you can be sure that I have already figured out how to 
do so - I wouldn't say otherwise.

do you mean that only accepted proposals by Carl  are in the wiki 
? i tought that all the ideas could be inserted in the wiki not only 
those accepted

Even those haven't been accepted yet. He hasn't even accepted his 
own ideas - they need more work.

However, every proposal in the wiki through REVERSE has been reviewed 
and discussed by Carl and were only added after he liked them. The 
latter ones were added the next day, based on my own ideas and those 
of Peter Wood.

I have run out of ideas, and am asking for more. Through discussions 
with Carl I have a pretty good idea about what would be rejected, 
and what has already been rejected. If you want to make more suggestions, 
please review the proposals that have been made already in the Parse 
Proposals wiki and Gabriele's REPs. If your suggestion is covered 
by something suggested in one of those places you can be sure that 
they have already been debated to death. If not, I'd love to hear 
it :)

ok i try again a new proposal:
ALL [rule1 | rule2 | rule3] 

each rule must be fullfiled one time but in any order (combinatory).

it's equal to [[rule1 rule2 rule3] | [rule1 rule2 ruel3] | [rule2 
rule1 rule3] etc...]

it's not an abstract idea, i had the case in some srcipts

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.