World: r3wp

Now I don't understand once again - if you are suggesting just changing 
the name of STAY to &, then please DON't do it!

Maxim, the a's in Carl's examples aren't involved in the expression.

Pekr, no, Carl was thinking of changing AND to STAY, but decided 
against it when he figured out how to make it infix.

Maxim, "everything is already AND by default" is not true. Everything 
is "and then" by default, which is AND with moving forward. What 
we need is AND without moving forward. An infix & handles that nicely, 
and is the opposite of the infix | meaning OR.

Ladislav just cheared to how Carl is precious about naming, and he 
liked STAY and QUOTE. STAY imediatelly expresses its meaning. Changing 
to to AND makes the situation only worse ....

So you want to rename | too?

brian  yes... I am wrapping my head around this... but I have to 
re-read the STAY proposal before getting too vocal... I'ts been to 
long since I've read it.

I actually wouldn't mind it being 'OR

(bts... about the 'a yes I didn't use the same vars in sequence... 
sorry)

[+ a |  b | c] is equivalent to [a b | not a c] but without the overhead 
or side effects being executed.

So, do you have a name for that?

This is really just - EITHER A [b][c], no?

[a b | not a c]   actually it should say... [ [a b] | [not a c]] 
  sorry but the |  doesn't roll back the a it will only roll back 
the b... its bit me too many times

No, because the a is not a condition, it's a rule.

what brian means is that the rule is consumed.... its just something 
that has to be understood.

Maxim, the a is rolled back too.

COPY is not COPY too, so what? REBOL copy value - PARSE - copy variable 
to-rule

it shoudn't be called EITHER specifically for this reason.

Brian - this is not easy to name ...

not in my experience... really it says it should and it works.. . 
until something screws it up... its happened to me COUNTLESS times... 
I've always had to put my rules in blocks to make sure they don't 
get fucked up by "|"

btw - how will you explain it to the user? Maybe it is just too new, 
but unless you provided me with [a b | not a c], I was not able to 
depict [+ a | b | c]

OK, let's try an easy one. Try to explain + without usingh the word 
"addition". Symbols are sed for a reason.

but its just being picky... the real thing... is what is evil about 
blocks?

but you see its not an addition.  its "go-over-this-and-accumulate-failure-or-not"

here... we have the precise name... its over 30 chars long   ;-)

we went too far. We should accept Steeves proposal - allow EITHER 
to be embraced as using condition OR the rule. Single as that. You 
can't beat the EITHER name. Thinking here and there, I can't imagine 
how + could be named, with the used syntax ...

Alright, explain the arithmetical - without usoing the word "subtraction". 
I had switched subjects. Oh, and don't use "hyphen" either.

actually, I think there are better words than either.

Brian - not, it is you, who can't explain it in fact. You can come 
up with a sensible name for the pattern of usage, so you throw some 
obscure symbol at us :-)

you can = you can't

Symbols mean different things depending on context, and the context 
here is parsing, not arithmetic. We still need to use them.

Max already said it - here's the name :-) "go-over-this-and-accumulate-failure-or-not"

I'm thinking  about something along the lines of   subject-to

providing

I suggested to Carl kind of syntax for the equivalenc to CASE or 
SWITCH ... maybe one of those two?

I don't need to explain Carl's + semantics because Carl was quite 
explicit in his own explanation. It made sense if you know parse 
theory, and you won't use it if you don't know parse theory. Maxim's 
term was inaccurate, though he's getting better.

PARSE itself is equivalent to CASE, so no syntax needed.

BRANCH was the best term before Carl came up with +.

I do have the proper word for IF, semantically....  'DEPENDS.

Must be prefix.

as in this RULES depends on this RULE

Max - we have to stay with + or some other symbol. If you look at 
examples, there is stuff like [a 2 + b | c | d | e] and I don't think 
any name will fit all usage scenarios.

yes I know ... but we never had a single word which properly explained 
what is going on ... now we do.

(for if)

Only some words can be infix, depending on the semantics of the operation. 
& and | (whatever they are eventually called) can be infix. The rest 
have to be prefix.

I'm sorry, but the |  will just end up being


 [   complex rule with its own  "|" symbols ] | [   complex rule with 
 its own  "|" symbols] | [  complex rule with its own  "|" symbols 
  ]  so really the use of "|" jusy adds clutter and ambuiguity.

When you don't have a descriptive term that covers an idea, you use 
a symbol and tell someone to learn it.

but the idea about REBOL has always been to be anal about FINDING 
those terms... Carl himself has admitted to using up more time choosing 
mezz names than coding them.

PARSE already has a lot of | symbols, and the operation currently 
proposed to be named | actually ties intto the current semantics 
of those | operations.

currently proposed to be named +