World: r3wp

I just want parse to stay readable for average man. The more symbols 
we add, the less readable the code might be at first sight. We should 
be carefull, or Larry Wall steps-in commenting R3 arrival, stating 
that R3 added even more punctuation :-)

although for "&" I agree, it really is just a single letter symbol 
which means AND, which in this case is right.

especially if the rule is infix (which it seems it will be  :-)

Perl 6 has already surpassed PARSE in its own category: their "regex" 
engine is a PEG parser, and has useful stuff we're adding now.

parse hasn't really evolved for what... 10 years?

PARSE was unique, but is becoming less so.

I always thought it would be one of the first thing R3 would work 
on.

PARSE added OPT and BREAK more recently than 10 years ago, and bugs 
were fixed, but otherwise unchanged.

I do thing BRANCH is the better term for the either / + keyword

thing = think

or  BASED-ON    :-)

This seems like a really good candidate for a symbol, but finding 
a prefix one is tough. If it could be postfix we could use ?, or 
even +. Postfix would look like infix, or rather like C's ?: when 
combined visually with the next | character.

I saw BASED-ON as a prefix symbol.

based-on rule | yay | nay

Then [a ? b | c] would be equivalent to [a b | not a c].

possible name for +  might be: ELSE or OTHERWISE :-)

Not in prefix it wouldn't be.

brian:   post fix ? is  actually not bad... and since condition rule 
is traversed anyways (either its true or false) .... it probably 
doable...

yeah so far, the only prefix term which reads well IMHO is BASED-ON

What I don't know is whether it is possible to do postfix anything 
- failure might cause backtracking before the ? is reached.

I really like, like in the end we are going to decode it for the 
users in documentation - "Now, you parse user, please read following 
syntax as - EITHER rule A is matched, THEN B is evaluated ELSE C 
is valuate" ... yet we will pretend, that we came up with some cool 
symbol to express what we just had to explain in human words :-)

no we won't use either... cause that is not what is happeneing.

;-)

attempts to match a rule, AND runs first rule if it matched OR second 
rule if it did not.

no? how do you explain [a b | not a c] then? I thought that - EITHER 
(IF) A is mathed, then B is being matched, or C is being matched 
(by being matched I mean - evaluated, hence might fail)

Max - who decides, what EITHER mean in parse context? We do. I can 
say - don't use COPY, as this is not what is happening (in REBOL's 
copy function semantics equivalence)

but copy actually does copy what is being parsed.  either isn't comparing 
a value like the if PARSE statement.

Max - you are NOT in REBOL level, so free yourself from pedantic 
"EITHER uses this syntax" equivalence, or dismiss COPY keyword too 
- it absolutly does not fit REBOL and even today on blog I had to 
fix Ingo's type, where he ommited to provide parse COPY with word 
to copy to ;-)

but in the end,  I just dont want it to be +  which is the worst... 
 even  "?"  prefix is better

Once again - free yourself from REBOL, gee. Who said said EITHER 
should compare anything? Copy breaks normal copy rebol logic. VID 
'at command is completly different in semantic meaning to REBOL 'AT. 
So - how is that that for EITHER we do care about what it means in 
REBOL? The word EXACTLY expresses what you are doing ...

If you want to be so pedantic, let's exclude all word from parse, 
which have different meaning in REBOL. It means COPY, TO ... any 
other candidate? ;-)

Today I posted more philosophical topic, and Carl noticed it - we 
ares shooting ourselves in the foot. Here's what I posted:
-------------------

There will always be problem with dialects, if they contain the same 
keyword names as REBOL functions. So we have to somehow live with 
that.


So the question is, where to introduce new name and why, just to 
be different, and where to not. E.g. parse 'copy keyword has already 
different semantics to REBOL's one, or VID's 'at has different semantics 
to REBOL's one. Now can users be confused? It depends.


I try to think about each dialect in the context of the dialect itself 
- so the only measure for me actually is, when reading the source 
code (or trying to understand one's), how quickly I am able to understand, 
what is going on?


But then we could as well replace 'stay by 'save-position, 'of by 
'any-of, 'if by 'only-if, etc., which would imediatelly map the meaning 
to what the keywords are really doing. But we are somehow mysteriosly 
looking for one-word-only-mantra naming convention, and I suppose 
it is already our style, and we will not change it :-)


... so, the topic is a little bit more abstract - it is about contexts, 
and user/programmer switching between contexts, and his/her ease 
of understanding of the code.


In above case, all 'if, 'check, 'either are OK, even if their semantics 
is a bit different to their REBOL counterparts.

I do agree

your rant towards EITHER not fitting anything breaks the initial 
purpse dialecting was brought to REBOL! And the meaning is - the 
same word, might mean different things in various contexts. We don't 
care for VID to use potentially the same keywords to REBOL functions, 
let we do care somehow mysteriously about PARSE to NOT use the same 
keyword naming as REBOL functions. Let's judge EITHER by its name, 
not by its REBOL level meaning.

Yeah, the name EITHER, exactly the reason I've had a problem that 
proposal since it was proposed in December.

The name EITHER was why I put "maybe" on the proposal.

If the english meaning of EITHER does not describe well what is intended, 
then let's not use it, otherwise let's use it. I noticed Carl created 
scenario, which allows to be really flexible. If no word can fit 
its meaning properly, then let's use the symbol. If we can find word 
for it, which will help users to imediatelly see, what the code does, 
let's use the name with no prejudices ...

It doesn't.

not with carl's last  example and syntax, but using blocks it would... 
without any lost in capabilities.

I might agree with Max here -sometimes I prefer already existing 
syntax being reused, instead of coming-up with additional semantic 
jumbo-mumbo :-)

It definitely is not an easy decision. I would proceed as following 
- take Carl's examples, and try to express/describe them in human 
words - simply how you would write a manual for them. The look at 
what you wrote once again, and if you find there is plenty of "either" 
words, then use it :-)

my point is just that blocks will be used so often anyways, because 
of recursive rules, that I see no point in using "|"  as I say, in 
every complex parse I've done,  I have to separate the "|" by blocks 
anyways... they just don't roll-back very well in practice.

ah, you are a purist, you would remove even | ? :-)

Not in R3, they work fine. And any bugs will be fixed.

pekr, not in the general rule, cause otherwise we'd need some new 
word to say "OR" these blocks.

The only problem I have with | is where to put it in multi-line rules 
- end of line, or new line? :-)

but brian... ALL real parse rules are so complext that we need to 
properly define the groups of "|" between them... so the point is 
moot even if they do work better now.

we still need to put rules in blocks, just about all the time.

and now with carl's example this will be even more so.

Max - we want to sensibly extend/fix parse, not to break what we 
are already used to, no?:-)

5:16 here ... should continue my sleep, I woke up at 3:00, or I will 
look drunk at work :-) ....