World: r3wp

data
 in this case being C source.

my goal is to get the host code and OpenGL headers past the parsing 
phase.  once that is done, I'll start work on adding the production 
phase.


I still have to write the pre-processor, but that in fact is pretty 
straight forward.  there are little rules and they are much more 
static and well defined on the MS web site.

Well, good luck! :)

the funny thing is that the C language reference on the MSDN is actually 
pretty well done... there are a lot of evil C examples for some of 
the more obscure parts of  the language like pointers, structs and 
unions.


funny thing is that some of the most complex things to express where 
the litteral constants!  integers, with octal, hex notation... not 
as simple as some [digits]  ;-)

Maxim, maybe you thought I was kidding the other day... ;)

hehe

Looking at the new WHILE keyword and I was quite baffled by Carl's 
use of it in his latest blog example. Then I read the docs and it 
didn't get much better:

- WHILE is a variant of ANY
- ANY stops, if input does not change
- WHILE doesn't stop, even if input does not change

What does "input does not change" mean?

Is it about changing the parse series length during parse?

Is it actively moving the parse index back or forth using special 
commands?

Is it normal progression of parse index with each cycle of WHILE 
or ANY?

Is it alteration of the parse series content while maintaining length 
during parse?

Henrik - according to docs explanation, 'parse contains some internal 
protection for the case, when input stream does not advance its position. 
In R2, following code causes infinite loop, in R3, it returns false:

parse str [some [to "abc"]]


(I am not sure I like that it returns false - normally I expect it 
to cause infinite loop. This is imo overprotecting programmer, and 
you have to think, why your code returns false anyway, which for 
me is the same, as if it would cause an infinite loop)

Further from docs:


To avoid infinite looping, a special internal rule is triggered based 
on the fact that the rule did not change the input position.

However, this shows a problem with this rule:

parse str [some [to "a" remove thru "b"]]


Here the input did not appear to advance, but something useful happened. 
In such cases, the some word should not be used, and the while word 
is better:

parse str [while [to "a" remove thru "b"]]

I don't probably understand usefullness of 'while at all. Because 
now I have to think, if my code would cause infinite loop, or not, 
and use 'some or 'while accordingly ...

Running above examples, my opinion is, that in fact adding 'while 
was probably not a good decision. I can understand, that now we have 
more power - our code will not easily cause an infinite loops, but 
otoh you now have to think, if it can happen or not, and 'some becomes 
your enemy ...

I probably need more examples ..

The WHILE keyword is the simplest possible cycle. The rule:

    a: [while b]

is equivalent to recursive:

    a: [b a]

sorry, I meant a: [b a |]

More complicated rules can be easily simulated using the While keyword, 
the opposite isn't true. Carl's example just proves, why While is 
useful.

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

What's that "thte" thing?

?? 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.