World: r3wp

btw - remember we have deline/enlice natives in R3 now ...

enline

those should replace read/lines iirc

the advantage would be to avoid skipping newlines. now that I think 
of it, you don't want it if you want to parse across a newline, but 
you wouldn't do that for CSV parsing.

enline and deline will help somewhat.

well, my argument seems to be weak. but now the idea is there for 
further study. :-)

Ladislav - in comment to ticket #1248, you write:


According to the documentation, that can be found in http://www.rebol.net/wiki/Parse_Project

parse "b" [not #"a"]


yields FALSE correctly. If you want to obtain TRUE, you can try e.g.:

parse "b" [not #"a" to end] 


My question is - what it the advantage to actually not advance the 
input on the rule match? It does not look natural and I would expect 
it to match the rule and hence move past it:

>> parse "b" [not #"a" ??]
end!: "b"
== false

... as can be seen, it does not advance ...

i see, but it's impossible to advance i guess.

NOT (as a pre-rule) is applied on the result of the following rule.
So, #"a" failed (it's not advancing at all).
Then, NOT #"a", reverse the state result.
FAIL become MATCH. That's all

What is the advantage?:


1) by not consuming input this would be a direct inversion of the 
rule. Example:

    parse ""a" [not end ...]


is a meaningful rule, and it is quite trivial to see, that any rule 
consuming input would not be a direct inversion of this rule.


NOT SOMETHING actually means, that at the current input position 
the SOMETHING rule shall not match. That does not give us any information, 
that NOT should skip any input (how far should it?).

2) This version of NOT is compatible with PEG

3) It is consistent with the AND operation:

   [AND rule] is equivalent to [NOT [NOT rule]]

Yet another example:


    [NOT skip] is equivalent to the [END] rule and is meaningful only, 
    when NOT does not skip any input

...I would expect it to match the rule and hence move past it...

 - that is trivially wrong. If the RULE matches, the [NOT RULE] cannot 
 match, therefore it cannot even advance. The only case, when (theoretically) 
 we could think of advancing is, when the rule does not match. But 
 then, it is not known, how far.

Some may prefer Steeve's explanation, which looks very good to me.

pekr, I had the same initial reaction, then realized that it would 
not be consistent wrt fail or no fail... when NOT would succeed a 
match (and fail the rule), the input would be beyond what the not 
is usefull for.


when I started thinking about it,  if you really want you can simply 
use a set word/get word pair to advance when the not finds a match 
to ignore a rule, but then its like not using 'NOT in the first place, 
so its pointless  :-)

not advancing NOT is not that much useful imo. I know that it can't 
be technically done, but anyway ...

Guys, i think your opinion about NOT is a little harsh.

In the case of complementing  a charset, you just have to SKIP after 
the NOT rule.
In the other cases, not advancing is of better use. 

At least that's what I see while rewriting some scripts as I do now.

The case is, that advancing can't be done in fact. It is just some 
psychological apsect, which leads some of us to think, that the output 
should be advanced, because we are looking for the complementing 
feature ...

Ok but could you give a case (other than complemented charsets which 
can be easly skiped) where you found that advancing is more convenient 
with a complemented rule.

I mean, i can't conceive that such complemented rule would be actually 
easier to read.

Or easier to write...

Skip is very slow compared with complemented charsets.

If you are parsing a string skip only advances one character at a 
time. When I wrote make-word-list for rebol.org using a complemented 
charset gave a big performance improvement.


Though you may be able to suggest better ways to optimise it - http://www.rebol.org/view-script.r?script=make-word-list.r

I can have a look, but the purpose of NOT is not to have better perfs 
than complemented charset, but to allow some simplification when 
writing rules.

Actually, It's the case of most other improvements, easier to write, 
not inevitably faster.

And don't forget that safe complemented charset in R3 are a pain 
in the ass to construct, because of UTF-8

Which is why I was dissapointed that I apparently misunderstood from 
Carl's blog:


Changes that are critical, but not highly complicated. For example, 
providing a NOT command seems easy enough, and it is now critical 
because using complemented charsets is problematic (due to the Unicode 
enhancements). 

This is the link to the blog - http://www.rebol.net/r3blogs/0155.html

Well, i saw your script, i don't know if it can be faster, i only 
can say I would have written it differently.
Probaby, using parse and load/next for all normal rebol values.

I can see that your rule about matching binaries are false. Cause 
[#{" thru #"}"] is wrong (what if the the binary contains the #"^}" 
char ?)

Forget my last remark, a binary can't contain #"^}" but a multi string 
yes

Peter, Steeve, the original problem that started the parse proposals 
was the problem of complimenting charsets. However, it quickly changed 
to improving PARSE in general. Then, while we were waiting for the 
parse proposals to come up on the todo list, we came up with a better 
solution to complimenting charsets, which is not yet implemented 
and which is not limited to PARSE.

Or maybe it's complementing? How would you compliment a charset? 
Say it has good coverage?

BrainH: what is the method to get complementing like feature back? 
I havent seen anything discussed in that manner yet ...

Using a bit in the charset that would mark it as "complemented", 
and then all of its matching algorithms would do an internal not.

The discussion was primarily in the comments of the relevant tickets 
in CureCode, though there was some in R3 chat. Not recently.

If parse was already rewritten from the ground-up, couldn't it be 
directly adapted to allow streamed parsing? :-) You said it could 
be added later, when rewrite happens, so ...

Yeah, but by "later" I meant after 3.0 comes out. I haven't even 
discussed with Carl what would be involved yet.

ok

I want to write more port code first and refine the model based on 
what I learn.

Plus, Carl's rewrite didn't change the basic algorithm of PARSE, 
just some details. I don't yet know whether my port PARSE is that 
easy.

even with a complement bit, if you use a few chained union's & complements, 
etc, you'll eventually need to bake it... in the end, all the complement 
bit is usefull for is to keep the charset to below half the maximum 
size of the complete encoding.

(which is still pretty big AFAICT)

Behavior of BREAK, ANY and SOME decided, finally: http://www.rebol.net/r3blogs/0270.html

Yesssss, the return of BREAK !!!!

i definitly  didn't love the previous way to exit from a loop

And it's finally break from a loop, rather than break from a block 
(supposedly).

is it just me or Carl is sidestepping the n BREAK proposal?

or BREAK/depth n  in case of a call within a loop.

(loop in a function, not parse)

Yes, that's unlikely to be implemented. He says it doesn't fit in 
with the rest. Same with n FAIL.

but its a hell of a powerfull addition to parse and to general code 
control.  I don't see why Carl can't see any use for it.

being able to drop from foreach [foreach [foreach [....]]] in one 
call is sooo usefull soo often.

That proposal was only for PARSE, not for function loops.

I know, but its as usefull within code.

within parse its a great optimisation for in-line parsing.