World: r3wp

?? not initialized after first match?  And secondly, how do I match 
thru a series of things (e.g. integer! integer!, but just wondering 
about the thte.  ?? problem before the first match?)

>> parse [1 2 3][?? thru [integer! string!] ?? integer!]
thru: [1 2 3]
integer!: [2 3]
== false

what do you mean by "match thru a series of things"?

Hm.  Version:   2.100.96.2.5  I quit and restarted.

And it stopped doing that.  I'll see if I can get it to do it again.

Is a sequence of things one of the complex rules that you can't use 
in a thru?

Yes. You can express a sequence of characters in a string as a string 
literal, but not a sequence of types in a block. You are going to 
need first sets and the other LL tricks for that.

Fortunately typesets work for block parsing like bitsets do for string 
parsing, so first sets are easy.

>> parse [a b c] [(value: none) copy value to 3 skip to end (probe 
value)] 
[a b]
== true


>> parse [a b c] [(value: none) copy value thru 3 skip to end (probe 
value)]
[a b]
== true

brian - so we can use things like any-string! or other typesets to 
match?

Should the latter be [a b c] ?

I would expect that ...

>> parse [a b c][?? 3 skip ??]
3: [a b c]
end!: []
== true

to/thru were reimplemented to allow multiple options. There are cases, 
where they are not supposed to work, but in above case I would regard 
it being a bug .... unless some guru finds a theory showing us why 
it should be regarded being a correct result :-)

Fork, the fact that both of those examples work incorrectly instead 
of throwing an error is a bug in PARSE. It should be CureCoded.

FYI still seeing some erratic behavior with ?? at head of the parse 
rule

>> parse [a b c] [?? copy value thru 1 skip to end]              
            
co? : [a b c]
== true

(That question mark not visible in the terminal, showed up when I 
pasted here)

Seems like a Unicode to ANSI translation error.

Indeterminate, e.g. just ran it again and:

But no such characters should be output by ??

>> parse [a b c] [?? copy value thru 1 skip to end]              
            
coo:: [a b c]
== true

Definitely another bug. CureCode it.

Well, I should find a way to reproduce it before doing that.  Left 
a note about how getting a CureCode account didn't work the other 
day.

Fork, are you seeing these outputs "coo", "thte", etc. on a Linux 
build of R3? I have seen similar corrupted output with Linux R3 when 
testing TCP client code, as documented in Curecode #1322.

Regarding the QUOTE keyword: the original proposal was to treat blocks 
as in quote [1 2] as sequences of elements, not as embedded blocks, 
wouldn't you prefer that behaviour?

Re the THRU problem: you can use


    parse [1 2 3] [?? while [integer! block! accept | skip | reject] 
    ?? integer!]

I overlooked, that you used the STRING! datatype:


    parse [1 2 3] [?? while [integer! string! accept | skip | reject] 
    ?? integer!]

Ladislav: I didn't realize you could use "while" as the second argument 
to copy, I thought it only worked with to and thru...

kcollins: I'm using OS/X, I still haven't found a way to reproduce 
it.  Comes and goes.

COPY should accept any rule, not just the ones you mentioned

e.g. 

    parse [a b c] [?? copy value thru 1 skip to end]   

should have preferably been

    parse [a b c] [?? copy value 1 skip to end]

What is the difference between BREAK and ACCEPT? Both "break" out 
of the rule, both with success (IMO).

Carl made a distinction in R3 blog, but they currently work the same, 
as far as I can tell, so, the only difference I see is, that ACCEPT 
is more self-explanatory.

Right: synonyms.

I'm still running into some problems with PARSE... mainly from the 
expectation of what ANY and SOME should do.

For example:
>> parse "" [any [copy tmp to end]]
>> tmp
== ""

what do you expect in this case ?

In the rewrite of DECODE-CGI, that behavior of ANY forces me to write:

parse "" [any [end break | copy tmp to end]]


This seems wrong to me if we define ANY as a MATCHing function, not 
as a LOOP function. This topic has been debated a bit between a few 
of us, but I think it deserves more attention.

In other words, is ANY smart about the input?  If there is no input, 
why should it even try?


Of course, in the past we've used ANY a bit like WHILE -- as a LOOPing 
method, not really as a MATCHing method.

It's a small thing, and maybe too late to change. I wanted to point 
it out.

We have so much alternatives that i don't see this as a burden

any [and skip copy tmp to end]
any [copy tmp [skip to end]]
etc...

There are a few ways to do it, but that is not my point.

I see your point, but what if the ANY block contains production rules 
?

parse "" [any [and skip copy tmp to end break | insert "1" and insert 
"2"]]

(i know, stupid example)

We have some cool new parse enhancements; really, really nice some 
of them. What I think will add the most value to PARSE--and maybe 
this is just me--are practical examples, idioms, and best practices.

For example


- Parsing an input that has nested structures, and how to collect 
the values you want.
- Showing the user where the parse failed.
- How to avoid infinite parse loops.
- How to safely modify the input stream.

More advanced examples would be great too of course.

Carl - first "error" in parse rewrite with some/any is the auto protection 
for non advancing input. It is like writting in BASIC

10 Print "Hello"
20 goto 10


... and not expecting it to run forever, because some magical internal 
mechanism kicks-in. If I write the code which could cause infinite 
loop, then be it. For me it causes the opposite reaction - some/any 
are not safe to use, let us use while instead ....


something like: parse str [some [to "abc"]] is so obvious and self 
explanatory, that actually not looping forever almost feels like 
parse error. But - even if I don't like it, maybe most such infinite 
loop hits are more difficult to notice, so that actually the prevention 
might be ok, I don't know. As for me though, I would probably prefer 
some internal capability to detect such case, and some debug option 
to show last rule/position, where it happens ...


I am not fluent enough with parse theory, but maybe it also relates 
to your loop vs matching note above ...

BenBran:
Not sure where to put this so asking here:


I downloaded a web script and it has a  snippet I don't understand:
buffer: make string! 1024         ;; contains the browser request
file: "index.html"
parse buffer ["get" ["http"  |   "/ "  |  copy file to " " ]]

what does:

copy file to " "

mean or do?
tia

The copy and to are parse operations. COPY copies the data covered 
by the next operation, the TO. TO covers the data from the current 
parse position until the first instance it can find of its argument.

So, copy file to " " is the equivalent of this regular REBOL code:
file: if find data " " [copy/part data find data " "]