World: r3wp

you need to maintain a map of keywords and codes   to that  in its 
own file and read it in to build your rules

sort it by keyword length  longest first

before building the rules 
then when codes change or mor are added you just update your map

basically what  ended up doing  :)

I'm puzzled about the difference result when using [to end end] and 
[thru end}. Anybody know why?

 >> parse "123456789" [to end end]
== true


>> parse "123456789" [thru end]

== false

note: 

parse "123456789" [to end]
== true

this has also puzzled me, since:

>> parse "123456789" [thru end here:] index? here
== 10
>> parse "123456789" [to end here:] index? here
== 10

maybe the rule thru fails because you can't actually go past the 
end.

just like this fails too. even though we are at the end:

>> print parse "123456789" [9 skip here:] index? here
true
== 10
>> print parse "123456789" [10 skip here:] index? here
false
== 10

it does make sense, and its consistent with parse... it only returns 
true when the last rule ends Exactly AT the end.

maybe the rule thru fails because you can't actually go past the 
end
 - but does [thru end] go past the end?

yes it goes one past the end. it does not stop AT the end.

end has no length, so to end and thru end mean the same thing.

I guess you could answer that end is past the end of the input. But 
the behavior seems inconsistent:

>> parse "123456789" [thru "8" "9" end
]
== true

>> parse "123456789" [thru "9" end]
  
== true
>> parse "123456789" [thru end]
        
== false

but brian, skipping past the end, still puts you at the end of the 
series, but the parser know you tried to go beyond the end... ITs 
the thru wich is failing, cause it knows you are trying to go beyond 
the end.

It's different in R3 :-)

>> parse "123456789" [thru end]

== true

thru consumes the end word, and then detects that, as a result, it 
would put you beyond the end.  
really, its quite logical.  


but in practically, thru shouldn't complain.... cause as you say, 
in this specific context, thru and to really do mean the same end.

I prefer the R3 behaviour. I really hope that it doesn't change.

I'll make sure of that, Peter.

Thanks.

yes, Peter, I am sure R3 behaviour is correct

In R2:

>> parse/all { X X  XX X X} [(prin 'a) some [(prin 'b) "X" (prin 
'c) [(prin 'd) "X" (prin 'e) | (prin 'f) skip (prin 'g)] (prin 'h) 
| (prin 'i) skip (prin 'j)] (prin 'k)]
abijbcdfghbcdfghbijbcdehbijbcdfghbcdfijbik== true

In R3:

>> parse/all { X X  XX X X} [(prin 'a) some [(prin 'b) "X" (prin 
'c) [(prin 'd) "X" (prin 'e) | (prin 'f) skip (prin 'g)] (prin 'h) 
| (prin 'i) skip (prin 'j)] (prin 'k)]
abijbcdfghbcdfghbijbcdehbijbcdfghbcdfijk== true


In both cases the fij near the end should should be fgh - a bug in 
PARSE.

Never mind, I missed that the last X is at the end of the string. 
No bugs.

the more i try to understand parse the less i understand it

i want to try to make a tutorial about parse but my knowledge of 
it is poor 

 so as we have a wiki we could start a project to write a documentation 
  with the goal to make people understand what is the interrest of 
 parse

Parse question on stackoverflow (unanswered as yet:)

http://stackoverflow.com/questions/1060727/rebol-parse-dealing-with-whitespace-and-copy-var

Answered :)

Fast!

http://www.rebolfrance.info/articles/allaboutparse
documentation to put all what we want to now about parse

There's also a lot of documentation about parse's behavior (in theory) 
at the beginning of the Parse Proposals page on DocBase.

BrianH yea but that's really too light you can't expect people gaining 
Guru level in parse with so poor documentation ... I want to know 
all about parse and i want that knowledge to be sahred

Alas, to know all about parse you have to go to the guru level. To 
know enough to get by, you don't :)

Code like that example above with all the (prin) calls can help a 
lot wiith understanding parse though.

What would be useful would be a parse cookbook.....HowTo questions 
with sample answers.

That way, we could build up a set of carefully graded examples of 
putting parse to work.

sunanda that's what i have in mind

but not only ...

first you give the basic you say what is parse you eplain how you 
can use it and then for the very hl part of the documentation you 
have examples working or not and answers from gurus explaining what 
 you missed in your implementation

sunanda look the page i submited if you have any comments

parse is a part of rebol which needs a complete book to be written 
about it.   To go from zero to hero it could easily span 100 or more 
pages.

Maxim i agree lets do it :P

to me parse is something that is useless until you understand it.... 
at which point, you are a guru.   There is no real middle ground, 
which is the problem.

but really i have a thousand projects in mind and i'm locked because 
of  my parse low knowlege i can add things to existing parse rules 
 but building a rule or a dialect from scratch is impossible for 
me

parse just needs to implement suggested refinements to make it more 
easy to use ...

I am able to parse what I need, am far from guru, but I still find 
parse usefull. I would not be able to write single regexp line ....

Maxim if people will know how to explain parse in ten years of existance 
it will be done already but nothing goes against trying and in the 
end the result can be surprising

One of the best ways to learn is to try to figure out enough to teach 
others :)

Pekr if you saw viva-rebol code you could see parse will be usefull 
for the function click and go  part

instead of the weak actual solution base  on  either any [ find ...] 
]

as area-tc is base on parse to draw on screen having a better understanding 
of parse would lead to the creation of a all purpose ritch text rendering 
widget using an adapated dialect

but i'm amased  some years ago rebol was all about eep computing 
simple by creating dialects addapted to your needs. But in reality 
parse is so compexe that this aspect of rebol is from far one of 
the less used ....

and in my opinion we are missing really something ... That's the 
kind of thing carl found so easy to use that he never though about 
creating a complete documentaton on it