World: r3wp

That and NOT, needed for Unicode at first.

I never got a good handle on DELECT, so I can't judge it too well. 
It seemed like the JIT binding of rebcode, but without the accellerated 
dispatch model. I wasn't clear on how DELECT dialects could be efficiently 
implemented.

The USE proposal intrigues me. I've often had issues with how some 
set words would appear to be in their own context, if set, deep inside 
a parse block. I can't come up with an example right now, though. 
Will all words be in a global context by default now?

No, words are still unbound by default. The miscellaneous loading 
mezzanine code binds the words to the appropriate contexts. PARSE 
won't do any binding, except probably to the keywords. The USE operation 
would be the only binding operation.

In other words (heh), USE gives us total and explicit control over 
that, which is good. I hate that in R2 parse.

Dunno if related, but I did recursive parsing with backtracking, 
and I needed to store stuff at each nesting, and it took me some 
time to find out, how to isolate the stuff. If I can have control 
upon what is local for my purposes, then it is very welcomed feature 
...

The USE operation was my best guess at a solution to that problem 
4 years ago, but I'm still hopinng that Carl comes up with something 
better sing some magic R3 trick.

what implementation of proposed USE is done?  use-1   or  use-2?

I really wish OF  was implemented for 3.0


this single rule makes SOOOOO  MAAANNNNYYYY   parse rules simpler 
for beginners.  even if its slow, its like the entry-point to parse... 
If you can make make it work with this, at least you get people into 
the band wagon, and then they will get better at it.

Max - what is it good for? It only works with block parsing, no? 
Most beginners start with parse to parse some strings from outer 
systems, not to build own dialects :-)

it should work with strings too.  but it allows very easy dialecting 
as it is now anyways.

(I mean it should be expanded to work with strings too)

but I can see how its complex to implement.

are the TO and THRU with multiple values on the table for 3.0  ?

yes it seems they are, cool, 


with conditionals also making the cut, I believe, 3.0 parse will 
be a hell of a mean monster for data crunching.

damn, the blog is giving me abuse notifications.  :-(

you can't poste way too frequently :-)

does anyone have trouble escaping from a long operation in the R3 
console?

hmm... I guess you use Ctrl-C, but that doesn't seem to be correct 
signalling in the OSX console. I would expect R3 to quit. Then again, 
the Python console does the same.

R3 console is substandard, at least under Window. Dunno what you 
mean, but I have some problems when I start it - sometimes there 
is busy indicator long time even after console is launched, sometimes 
it starts and does not get its focus ....

There is also bug that it's not escape from WAIT.

yes, you can't ESC from wait .... what a let-down :-)

http://www.rebol.net/r3blogs/0248.html

Oh, now this is fun.

... getting better and better, heh? :-)

this is probably the best part

its definitely going to make it easier for people to learn it and 
for advanced users to debug complex rules  :-)

USE 2 won't work - see the editor's notes (I was the editor).

k

I think I don't understand the outcome of EITHER parse blog.  don't 
like + sign, as I immediatelly think in math terms ...

Parse theory is a branch of math.

I don't care of theory. If I want to be like others, I go for (for 
me) totally unreadable regular expressions ...

We're talking about having STAY be changed to infix &. It's cool 
to hear that infix is possible (according to Carl).

When I read initial EITHER proposal, it was imediatelly clear, what 
it does. Whereas I am looking at following code, not being able to 
gues, what it is about. It way too much implies math operation, not 
some lexical thing:

[a + b | c | d]
[a + 2 b | c | d]
[a + not b | some c | d]

why not use ! instead of word NOT then?

When I read the initial EITHER proposal, I gave it a maybe. It didn't 
act like the EITHER function, and that would be confusing.

I REALLY don't like where this is headed...  :-(

sorry... we clamour about parse not being RE and here we are making 
it possibly even more obscure... with implied branches... by using 
a "+" no less.... sorry.

[a 2 + b | c | d | e]   is   beyond obscure.

I don't like ! instead of NOT, siince it's too hard to distinguish 
visually from |.

I don't clamor about parse not being like RE - that is its strength. 
I've never considered that difference a problem.

parse is readable, I'd rather have EITHER with blocks than some infix 
operators which loose the sense of PARSE...

sorry I mis-interpreted that word as a loud bragging.

(clamor)

And they're not implied branches - it's an explicit statement. If 
you don't like the name + that's fine, it's the changed semantics 
I like.

The only problem that I have with + is  that it's *not* an infix 
operator, it's prefix.

this is really - WTF for me. It turns parse into unreadable guru 
stuff with such a semantics ...

& would be infix, a replacement for STAY (originally called AND, 
then AT).

just don't replace STAY word with &, if you don't want to make situation 
even worse ...

its like saying 


when I say implied, I really mean that you cannot just look at rules 
like they are now with a single use bblocks for many rules.  it terminates 
 somewhere later ... you must find an  | statement....  which doesn't 
properly map to open or close something... its implied based on something 
else before it...  [ ]  are explicit.

STAY was a bad choice. AND was better - the only reason I picked 
AT is because I thought infix was impossible.

its like saying
  sorry... don't know where that came from... ignore