World: r3wp

BrianH: Carl asked me, that if I want some of following implemented/noticed, 
we should put them to the parse document. I gathered them in R3 chat. 
So - I would like to open short discussion about following proposals:
------------------

I would like to ask, what will happen to proposals, which are not 
part of the do

cument? I mean - I do remember following kind of proposals, which 
are discussed
in parent thread:


1) make /all option be the default parse mode. If I want to get really 
reliable
results, I always use /all, to be safe


2) there was some proposal to add /space, or /ignore, to allow easier 
parsing of

 CSV, etc., but other proposal was, that it might be better to let 
 it to the enc
oder/decoder level


3) there was a proposal to allow quoting of "", to make parsing easier.

/all by default was generally agree on the blogs IIRC.

Carl calls for more opinions on parse, as we have just this week 
for changes ...

where?

Opinions about what ?

in R3 chat is there a way to read through the new posts sequentially? 
 its very tedious to access new stuff when its all spread around.

R3 Chat, type "n" for new messages, and "lm" to list the messages. 
It is generally enough to be able to participate. For reply, just 
type the msg number you want to reply to, and type "p" to post to 
the thread, or "r" to reply to such a message ...

you don't understand... I know that.  when the discussions is spread 
between 10 groups. its VERY tedious to read more than very few messages.


jumping around, hoping you don't miss posts, then listing again... 
over and over.   it would be nice if we could simply skim over the 
list of new posts in order of time.


then if we jump to a post we don't get the context, we just list 
that group... its easier this way.  but going to next mesage would 
still bring us to the "newer" message, not the next message in that 
group.


I'm not saying the current method isn't usefull, I'm just saying 
that another method would make it easier not to miss out on new posts, 
especially when there is a sudden flurry of posts all around the 
place.

It's very inefficient ...

If you read message, pressing enter continuously brings you next 
one in line ... other than that, this is not the topic. And even 
Carl asks, where the best discuss the Parse - blog, AltME, Chat?

But I would say it the other way - either you want to have some say 
into the topic, or not - decide for yourself.

Sometimes it is difficult for me to understand - most devs here are 
gurus being able to handle 100times more complex systems, yet they 
refuse to use Chat :-)

I think that we vote Carl to use blog - at least it is mine and now 
also Max's preference ...

pressing enter brings next message in a single group, until that 
group is at its end.. then you are at a loss in the new messages... 
which one did I see which ones did I miss?

I don't mind the text chat.  its just not really effective at handling 
large volumes of posts.

Don't worry - a chat GUI is planned.

ahah, good how we perceive stuff from different perspectives :-)


Carl's parse 'limit proposal:  Disadvantage - Could make some programmers 
lazy. 

BrianH's parse /ignore proposal: Advantage - It might allow programmers 
to be lazy.

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.