World: r3wp

hum but  in general you do your best to select the best 3D file format 
 to go with your custom made 3D engine to get the best rendering 
real time speed and that best quality compromise.

and that's exactly what an imposed Markup dialect forbids to you 
point.

more low level instruction to make y world easyer why not ? ...  
being tied by the neck and forbid from freedom no way !

maxim with an imposed close format and an imposed close black box 
called "doc"  what you gain in a hand you lost it on the other hand 
cause you still have to convert your raw data into the specifiq imposed 
markup language and if that markup language have limitations then 
you have find again new tricks to do what wasn't planned to be done... 
 that's not like choosing your own format and then your own rendering 
line. That's why i said in my example we impose to you the use oof 
XML  sheets to represent your 3D data (which is obviously far to 
be the most performant and the most suited to that use) and you are 
stuck to what the black box is able to do no way for you to directly 
have an impact on the rendering line.

but there is no link between make doc and rich text.

The rich text dialect is a data structure, not a markup language.

It seems insert (and maybe even change, remove) are already implemented 
for parse? At list this is how I read between the lines of Carl's 
blog reply in Either related blog ...

Yeah, though diifferently. I'll write up the changes in the parse 
proposals page.

it also seems Carl interprets 'either differently too ...

Differently every time you ask. I've requested that he respond to 
my comments.

'check seems to be implemented as 'if?

I've seen no indication that CHECK will be called IF, but given that 
my ? proposal will be called EITHER, it would probably be alright.

And it looks like it is the ? | model I put here :)

http://www.rebol.com/r3/docs/concepts/parsing-summary.html#section-3

look at the table - insert/change/remove is there, as well as 'if

hopefully I am not wrong?

'into does not seem to allow other types yet, we don't have multiple 
to/thru and 'use. Hopefully those get added in first iteration of 
parse rewrite ....

multiple to/thru  are near the top of the list... and Carl recognises 
their use... and probably they where the first requests, ever for 
parse.

they were long time dismissed by many, but I am glad the attitude 
changed :-)

yes... how many times I heard the term... it break's parse's "purity" 
 yerk...  it makes me loose money (cause I have to spend more time 
writting complex rules for simple tasks).

:-)

Updated the proposals page with the changed proposals (to the best 
that I can figure out).

Could someone decode how to read 'either parse syntax? I am still 
confused. The word is absolutly wrong, if infix, I can only imagine 
it, if prefix.

[parse "ab"      ["a" either "b" | "c" | "d"]]


How to read it, please? If "a" is being matched, then try to match 
"b", or try to match "c"?

Think of it as ?

My other word favorites are:

then (absolutly best imo)
try
only

did we ask for too much and unleashed a monster in Carl?  ;-)

also
 would work here. a also b | c

I'm thinking that giving too much fun stuff for Carl to do is scary... 
he should go back to extensions...  or maybe not... he might popup 
a full ANSI C parse rule,  in an hour, just to prove its easier than 
before ;-)

a 'WITH b | c

then , try (too much implies rebol's try?), also , next , with , 
only

but imo THEN makes the most sense ...

I agree... then is the most readable and is pretty close to the meaning, 
and especially since then is related to if then else.

brian - advanced stuff like [a 2 + b | c | d | e]  still possible?

well, 'still another name :-)

posted another bunch of favorites ...

Sorry, I find using words for infix operations to be confusing. Better 
to adopt two-char symbols.

There is some truth to it, Henrik. It took me some time to realise, 
why 'either looks weird. As you said - I tend to look at the right 
side of it = prefix, not as an infix.

I am against + sign though. I thought about equivalence of 'then, 
which is sometimes expressed as ==>, hence => or -> would be enough, 
although a bit cryptic. The word 'then is still my favorite ...

Brian: I can't see 'change implemented. Or is "change" done by 'insert?

... ah, 'change is planned, just not yet done or documented ...

hmm, 'and reads much worse in the example at the end of parse doc, 
than STAY or HOLD would read there ...

I suggest anyone interested, to read example at: http://www.rebol.net/wiki/Parse_Project#Examples
, to see, how it "feels". AND keyword is like an alien from the outer 
space there, and if there would not be comment at the and of the 
line, stating (after fixig a typo): "Back in the same position as 
before the AND.", you would hardly know, what does have AND (most 
often perceived as logical operation) in common to keeping the position 
at original series index? Why not STAY, KEEP, HOLD?

Or do I understand AND meaning incorrectly?

It is called AND because it means that something at this position 
has to match one rule *and* another.

Your other suggestions give too much unnecessary information about 
backtracking. Compare the | word (meaning OR), which doesn't mention 
backtracking.

OK, but - what happens after the match? (at the end of the block) 
- where is the position? At the end of currently matched rules, or 
at its beginning? Because my initial understanding was, that STAY 
was supposed to match the rule (look-ahead), but, it did not advance 
the positon. And if it is true for AND, it does more, than its name 
suggests, no?

As for EITHER/+, my favorite proposed name for that is now =>. We 
absolutely have to use '| for the second part, since => is *not* 
an infix operation, it just looks like one. Since we can't use 'else, 
'then looks a little silly, as do all alphabetic words when paired 
with a symbol like '|. We need another symbol, and => implies advancement 
without making it seem that the data position is being advanced like 
'next would.

If both rules of the AND succeed, then the ending position of the 
second rule is what you end up with. It's like shortcut boolean and.

I never perceived I as OR. I simply thought about it as about some 
wall, separating option slots :-)

Nope, it's an ordered OR.