World: r3wp

Laziness is a virtue. Creative laziness is the best optimization 
strategy in the world.

The perspective probably also comes from who knows the implementation 
of PARSE (Carl), and therefore is less forgivable about usage.

I actually don't know why he said that comment at all. I can see 
the disadvantage of laziness in some cases, but I don't get how that 
particuular proposal can lead to it. Any ideas?

If used wrong, could it cause a performance issue?

Hmm, so good proposals are down the list ... e.g. of (I would call 
it any-of), do, reverse. Brian - what you think we get for the parse 
update for 3.0? Carl mentioned, that some proposals would require 
some big changes to underlying parse function. I was surprised,e 
.g. 'of being one of them ....

Henrik - in Carl's proposal, imo no performance hit. It simply tells 
parse that new limit for next rule evaluation is XY chars/bytes? 
It just could make you lazy in that manner, that you will not construct 
proper rules, but e.g. knowing that your tel-number is 8 chars long, 
you just limit it, as you can be sure about it.

DO is down the list because it's scary. The number of people who 
could use it without code injection security problems is small.

I proposed adding 'limit keyword to the secure dialect too. It will 
have to come one day anyway :-)

yes, I am worried about the security too, but I know that you discussed 
it with Gabriele extensively, so I don't want to reopen the discussion 
...

REVERSE rule is really cool, but of relatively limited use compared 
to the rest. And Carl says it is *really hard*.

I worked out how to make it possible to use DO at all without it 
being a security disaster. Possible doesn't mean easy though.

How is 'limit used? I set it once, as like we set spacing in VID 
once, and then I have to reset it? Or does it apply only for one 
following argument? I can imagine using limit with multiple to/thru 
...

Brian - what is your "parse ports" proposal like? I noticed you mentioned 
it in one Chat reply, that you might know, how to parse ports in 
future?

btw - will /case refinement stay?

LIMIT would apply to the next rule, but that could be a block of 
rules.

... sorry for having many questions, I am just interested in the 
topic. Although I am lame parse user, I managed to already parse 
several cute challenges here = I will never agree, that parse is 
just only for gurus :-)

/case will likely stay, though case insensitivity in general in R3 
needs some Unicode-related tweaking.

As for PARSE of ports, it's too ambitious for this round. Wait for 
the rewrite - we're just tweaking right now.

you think rewrite will happen? It is in closed-source part of REBOL, 
no?

Even REVERSE is probably too ambitious for this round.

I think the rewrite will happen after 3.0 comes out. The most important 
stuff is done already: NOT, STAY, QUOTE, FAIL. Those open up a world 
of theoretical possibilities, as Peta has pointed out in great detail.

do you think direct usage of PEG expressions? Well, I am waiting 
for "my" proposal - multiple to/thru :-)

That would be great, but it is likely difficult. We'll see.

I wonder why I never saw any dialect using paths. Is there any difficulcy 
in parsing them? E.g. let's say you would like to create REBOL-like 
language. So you want your 'open command to be treated the same way 
as open/direct/binary ...

btw - what happens to DELECT. Is is still usefull, after we enhance 
parse?

The parse enhancements, particularly OF, were prompted by the failure 
of DELECT to simplify the new VID.

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? :-)