AltME groups: search

at least that's my opinion ... I always delayed this kind of project 
I was expecting someone to do it 
But time passed and no complete documentation emerged.

i started writing the documentation and organising the plan of the 
document and how i see things organised.

all comments or adding to this document are welcome.

graham .. wiki is for R3 since R2 and R3  are not the same it's better 
to not mix them. We can build the  documentation prototype on french 
wiki and then upload it with adaptations to unicode and other R3 
parse new things... to R3 wiki.


I prefere using french wiki because it's wide open no need to fill 
a form and log to be granted as a reader and in my mind this have 
to be the most open wide possible.

but yes that will be a need to be on wiki R3 .. but before talking 
on what is not official can we talk about what is official and already 
wait for us to use it since so many years ?

graham even if from taht wor then you write a book on parse and become 
billionare I won't be annoyed by that hahaha (if that's the case 
I and the other writers would gladly appreciate you to send us a 
plane to ticket to visit you graham :P)

any people that want to explain what he understoud from parse should 
be able to write it somewhere and have other people contribute to 
it well in my particular case that will end fast lol i'm not a parse 
guru i'm just a rebol coder willing to understand parse and use it 
the more often possible in all my projects.

i recognise i have been lazy and skipping the pain to understand 
parse too much time...

we can live without parse yes .... but then we have post from Carl 
saying that the rebol community is coding in rebol like they could 
code in any other language and skippping the most part of interrest 
of coding in rebol... and yes i'm not against that remark that's 
completly true. what interrest me is how can we promote the use of 
parse and how can we give back to parse use and dialects conception 
the  central place they deserve ?

many answers to that goal can be provided, make parse more friendly 
? write documentation about parse ? providing other point of entry 
to parse comming from other more "fun" technologies like a VID face 
using parse rules to draw on screen ritch text ? 


And why not using all of those possible solutions to this problem 
?

Another thing that annoys me ... don't take it as a personal attack 
okay that's just what i saw in 6 years of being part of rebol community. 


We provide our community tools to exchange information (altme, chat, 
forums etc...) people come with their problems they obtain an answer 
and then what ? the answer is lost in the flaw of talking and no 
one remembers them. then time later another guy come with the same 
problem obtain the same reply and the reply again is lost in the 
wind. 


The purpose of documentation is offering a way to answer the most 
basic problems and for harder problems one never though about then 
we use forums, altme, chat etc  and then this problem is backuped 
cleaned and organised into a cookbook will say sunanda or a detailled 
any level documentation i would say.

yeah i'm ready it ..

that's complete but it's missing a human dimension to that documentation 
i mean i read it and i'm still not able to do what i want to do ....

good basis to start a true documentation will make people speak with 
parse and knows all about it

ok book marked and i will see what i can do with that

we should all be like the terminator and have a shielded nuclear 
power source ....

there is so many interresting aspect in rebol than focusing on only 
one and going to the extend of it is really hard ...

if you hit metal and shape it you are a blacksmith if you hit parse 
and shape your code you are a reboler :P

i like the idea of building a colaborativ editor around irc and vid 
i find the cross of both technologies reallly interresting...  but 
the bound to those technologies have to be parse parse parse and 
only parse

if i make another compse and if find based project steeve is going 
to kill me :P

maxim no i  called it the block rule and i made a section dedicated 
to dialect


So waht i will put in the block rule that  is different than a dialact 
...

in the block rule i will explain the big lines and then i will try 
to apply those consepts to build a simple dialect that i will comment 
.

and as that's the most difficult part i don't really undersand it 
 so we will see any help is welcome anyway.

for me and that's probably a noob though becasuse i'm not a guru... 
but none rule and string rule avec  almost the same effect isolating 
and spliting items of a string and arranging it into a returned block!


but yes the bigest part will be to explain the block rule the parse 
in a  block rule instructions
(copy at thru to etc...)

i will have to explain any some end newline all those kind of things 
that annimate parse and make it completly another thing compared 
to regular expression

Gregg well ... i'm not against contributing but I think one of the 
good way is for lower ranked programmer to express their problems 
and try to construct a doc helped by gurus to answers their ask then 
if it's readable and understandable by me I assum anyone could understand 
it 

My point is once people end rading the doc they will say "yeah i 
understoud what it's all about so now lets play with parse :P" if 
that only goal can be achieve I think a big step will be done.

and parse is something I really want to use in extensiv ways and 
if in the process i can acquiere enough knowledge and sahre it then 
we will all benefit from that

You should define a complement to spaces and then change the parse 
rule to copy the complementary characters.

no, I see it differently.

the problem is that spaces is  " [some spacer]" , and R2 does not 
allow  "to subrule".

Oh, and I see you gave a good reply in the stackoverflow.com site.

Hi All,  I'm new to PARSE, so I've come here to learn a little more. 
 I'm working on and off on a little testing project of my own for 
R3.

My goal is to navigate through some website(s), capture Rebol code, 
and the expeceted responses such as this page: 
http://rebol.com/r3/docs/functions/try.html

I'd like to capture the text inside a block like this:
[ "cmd" {if error? try [1 + "x"] [print "Did not work."]}
rsp
   {Did not work.} 
cmd
  {if error? try [load "$10,20,30"] [print "No good"]}
rsp
  {No good}]


Can anyone point me to some parse example code which can "tear apart" 
an HTTP page based on text and the type of text?

I realize I may be biting off a bit more than I can chew, but I'd 
still like to give it a try.
Thanks in advance.

You can just set your block that you want to parse to a word.  Such 
as:

blk: [ "cmd" {if error? try [1 + "x"] [print "Did not work."]}
rsp
   {Did not work.} 
cmd
  {if error? try [load "$10,20,30"] [print "No good"]}
rsp
  {No good}]

; and then do this:

>> parse blk [some [set s string! (print s)]]

Hi Paul,  I may have mis-stated what I'm after.  You see the site 
 http://rebol.com/r3/docs/functions/try.htmlhas displayable rebol 
code and responses within the html.  If you captured the html code 
you would find something like this:
<html>
<head>
...(additional html code and text)...

<title>REBOL 3   Functions: try</title>TRY returns an error value 
if an error happened,
otherwise it returns the normal result of the block.</p>

<pre>if error? try [1 + "x"] [print "Did not work."]             
                    <-- in this e.g. the tag <pre> will preceed the 
rebol command until the next tag

<span class="eval">Did not work.</span></pre>                    
      <-- the tag <span class="eval">  will preceed the response 

<pre>if error? try [load "$10,20,30"] [print "No good"]          
          <-- this is the next rebol command

<span class="eval">No good</span></pre>                          
       <-- this is the next response
<h2 id="section-3">Related</h2>


I want to be able to interrogate the html code, parse it and capture 
the rebol commands and responses (if any), then put that into your 
above block example.

more to what Graham is saying is, try...
>> load/markup http://rebol.com/r3/docs/functions/try.html


you will be returned a block of strings and tags, which you could 
use the tag? word to test if each element is a tag or not to seperate 
HTML from regular Strings.

if you want to capture multiple command and response blocks you wrap 
the parse block in...
any[ parse statements] 

.... excluding the to end statement which you would want to include 
only after   'any'   parse instances occured.

Excellent suggestions Brock and Graham -- That gives me a lot to 
play with!!  Thank you.

Yeah. If you pass a function as the replacement value, that function 
will be called with the series at the replacement position as a parameter, 
and its return value is used. ARRAY does something similar too. My 
changes.

Except your replacement code for those functions was wrong. And would 
be wrong in this case. Those inline operations were added to reduce 
common errors, not to provide missing functionality.

I am also concerned about the security implications of having PARSE 
call functions outside of parens. In parens you know what you're 
getting. This is why QUOTE and IF require parens for the REBOL code 
they execute.

All of the added operations could have been done before with code 
in parens and/or explicit position setting. It's easier this way.

I put a note up because of my silly misunderstanding of the intent 
of adding AND to PARSE.  But I get odd results with the likes of 
   parse "abeabd" [and [thru "e"] [thru "d'"]]  which behaves like 
ANY

OF course in STSC APL  "laod" was as good as "load" and in Smalltalk 
I still long for "slef" and "sefl" but I draw the line at "elfs" 
which is clearly unfit in the age of "octopuses"

And that doesn't even count the stuff not implemented yet.

I thought ONE (but no move) on the model of SOME and ANY when I was 
misunderstanding AND as "all"  as [ ONE [rule1 rule2 rule3 ] ]

Steeve - will better parse help with editor? IIRC it was you and 
Shadwolf, who did it?

With the PARSE changes, this puts us within the range of a parsing 
model with a reasonably solid theoretical foundation and a lot of 
experience with parser generators. We could compile PARSE rules into 
equivalent incremental rules.

I am still guessing at what is intended in R3-a84 but the first looks 
OK and the second looks like a bug                               
                                                                 
  >> parse "abad"  [thru "a" stay [to "b"] (print "at b") thru "d"]
at b
== true


>> parse "abad"  [stay thru "c" (print "at c")  [to "b"] thru "d"]
at c
== true    ;   BUT must still be a bug

STAY could be a by product by wrongly implemented AND.

I would like to say how the new parse is powerfull and light.
For example: 
I have a block which contains 1, 2, or 3 values

I have to insert something between 1 and 2, if there is at least 
2 values.
and something else between 2 and 3., if there is 3 values.

See:

parse block [
	skip
	not end
	insert [ _ ] skip
	not end
	insert [ . ]
]

Is that not marvelous ?

And we still don't have IF, USE, INTO string!

parse block [
	skip   ;** skip the first value

 not end   ;** check if the block have a second value (if not, then 
 stop)

 insert [ _ ] skip   ;** insert what is inside [ ] before the second 
 vlue , skip what it has been inserted, and skip one more time to 
 pass the second value.
	not end  ;** check if there is a third value (if not, then stop)
	insert [ . ]  ;** insert [.] before the third value 
]

STAY is only useful for rules with effect: modifiers, and rules containing 
productions. Sometimes you need to do stuff where necessary and not 
care whether they were necessary later.

I am of the opinion that STAY is of (very) limited but significant 
use, but that AND is of critical, everyday use, as much as NOT.

i agree for AND urgency

STAY is of use when combined with CHANGE or INSERT, when you want 
the parse position to be set to the position before the insert not 
after, and when the modification is optional, or otherwise doesn't 
need to be specially checked.

STAY is a more efficient shortcut for OPT AND.

Maxim, Steeve, I also prefer REMOVE 1 (my original proposal from 
November) and CHANGE 1. REMOVE 2 is too fiddly to satisfy the bug-reduction 
purpose of the CHANGE and REMOVE proposals.

Brian, you said: 

STAY is of use when combined with CHANGE or INSERT, when you want 
the parse position to be set to the position before the insert not 
after, and when the modification is optional, or otherwise doesn't 
need to be specially checked.

you mean something like:

parse [...][ STAY rule remove something]

but it's the same thing that:
parse [...] [remove something]

i don't see your point, give an example please.

No, that's AND. STAY is pos: opt [rule] :pos

STAY is equivalent to OPT AND or AND OPT.

Just like AND is the (much less annoying) equivalent of NOT NOT, 
in theory.

many of the parse rules are shorthands for already doable things 
(except 'NOT and to/thru multi)

moreover, the AND rule is usually what is desired, not the STAY rule, 
which is just a bug. I do not know any really meaningful use case 
for STAY; the above INSERT surely isn't one

remark could be rewriten using stay, and it would be much simpler 
to build/read.

That's why I put STAY so low on the priority list. Maxim, you are 
still confusing STAY and AND.

with inner parsing rules modifying the input and potentially triggering 
new parse matches.

and THRU multi is even simpler:

    a: [thru b]

is equivalent to

    a: [b | skip a]

yep... all hard to understand and code in real life.  which is why 
I say that the new keywords, just make it easier to parse stuff. 
 They aren't hacks or tricks anymore, they are supported directly 
by the parse dialect.


its like the stack handling... its just going to be MUCH simpler 
so use push, than tinker with your own stack.

I'm not saying STAY isn't useful, just that it is lower priority 
than AND because it's use is more limited.

you see the thru multi you show... is excessively hard to "see", 
even I look at it and have to wrap my brain against it, and its really 
not "obvious"

I like having STAY though, since I am one of the advanced parse users 
that would find use for it, like Maxim and Carl :)

I'm  looking at this.....    a: [b fail |]  and its totally obscure 
... I don't see it at all, I can study and eventually "understand" 
it, but within a 1000 line parse rule... <eek>. 

the way I see STAY is: [pos: b :pos]

Sorry, that's still AND. STAY is [pos: opt b :pos].

The fact is that all of these were added to make our lives easier. 
Now I don't think STAY is worth the effort to implement it, but given 
that Carl *already has* implemented it, it it worth removing? This 
is regardless of the merits of AND, which are unquestioned.

We could fix charsets too (add a complemented bit), and that would 
help too.

'NOT  and the 'TO/'THRU multi.  its just soooo much simpler to slice 
and dice text using it, which is a large percentage of what parse 
is used for.


I remember Carl's historical reason that it made us lazy... hehehe... 
his CR.LF stripping example shows that he is quite lazy himself  
;-)

Yes, Steeve, I used it just the recursive expression just for demonstration 
purposes (recursion can be even used to demonstrate how ANY works). 
OTOH, it is a problem to e.g. define a non-recursive rule to detect 
correctly parenthesized string containing just #"(" and #")"

ok, well that is a general problem of parse, (and of REBOL in general, 
I might add).

Yup, recursion is bounded and not tail-call optimized :(

I remember having requested 3 commands to speed up the management 
of  our own stack in the past [push, pop and rollback]

remark currently uses a stack and stores inner parsing explicitely, 
with offsets& stuff while flattening the inner-most tags first, this 
allows the whole engine to use a single flat 'ANY [ dozens | of | 
rules ].  it loads rebol dialect data within nested < > pairs in 
html ...  works well, but its pretty complex to setup.  would be 
nice to have something standard to code against.

push and pop would be the default accessors for set and get.  index 
being the rollback.

Assuming yo are using the PARSE stack and not rolling your own.

I wonder if a PARSE optimizer could be written, to reduce use of 
stack and other resources by automatically rewriting the rules.

brian, wait a few hours, Gabriele will pop up saying he has one, 
but unfinished and slightly buggy, somewhere on his HD   ;-D

Even, meaning the ( and ) are balanced. p starts as 0, and should 
end as 0.

[(p: 0) some [#"(" (++ p) | #")" if (1 <= -- p) then none | break] 
if (p = 0)]

Handles the empty string. Given the | break alternate, ANY and SOME 
are equivalent.

funny I suggested it 2 hours ago, and you guys end up with a path 
with a use case implementing a simple rule  :-)

Graham: your "plenty" and my "plenty" are not the same, as it looks 
;-)

Since A84, AND is even more broken:

>> parse "abc" [and "a"]
** Script error: PARSE - syntax error in rule: op!
** Where: parse
** Near: parse "abc" [and "a"]

From your example, it is not much obvisou, why you break/fail two 
levels? But - for more advanced parse gurus, n FAIL and n BREAK will 
surely be usefull ...

Ah, the above bug is not bug, I might know how it happened. I thought 
that we got STAY, and that AND is there too, albeit not working how 
we would like it to. But it seems that AND was just renamed to STAY, 
and so parser does not recognise AND keyword at all ...

pekr, parsing an xml file itself is quite easy.  


Actually, its converting and validating the xml schema or DTD which 
is complex because, basically you have to compile a new parse rule 
out of misaligned parsing concepts.  this will never be easier, until 
someone builds (and makes public) a simple to use, *complete* interpretation 
of each XML-based spec.  XML schema, xpath, etc.

re

    [...then none | break]

the "then none" part is unnecessary and can be safely omitted

one more note: in a rule like:

    any [... | break]


the "| break" part is totally unnecessary and can be safely removed

why do you repeat it? I try to point out, that it might share internal 
representation, and that might be buggy?

I have a headache to find out, how 'change behaves in REBOL itself. 
Now if the parse version is supposed to behave even differently, 
then I am completly lost without the trial and error aproach in console, 
and it totally sucks ...

And as such, is correct, no?

What a mess...

digit: charset "0123456789"
num: [some digit opt [#"." any digit]] 
term: [num | #"(" any lv1 term #")" | #"-" any lv3 term]
calc: [(expr: do expr) stay insert expr (probe e)]
lv4: [
	remove [copy expr [term change #"%" " // " term]] calc
]
lv3: [
	any lv4 
	remove [copy expr [term change #"^^" " ** "any lv4 term]] calc
]
lv2: [
	any lv3 
	remove [copy expr [term change #"*" " * " any lv3 term]] calc
	| remove [copy expr [term change #"/" " / " any lv3 term]] calc
]
lv1: [
	any lv2 
	remove [copy expr [term change #"+" " + " any lv2 term]] calc
	| remove [copy expr [term change #"-" " - " any lv2 term]] calc
]

>> parse probe e: "2+3*2-(-2^^4/6)/2" [some lv1]

2+3*2-(-2^^4/6)/2
2 + 6-(-2^^4/6)/2
8-(-2^^4/6)/2
8 - (-16.0/6)/2
8 - (-2.66666666666667)/2
8 - -1.33333333333334
9.33333333333334


I think i can make that more clean if only the commands AND, CHANGE 
(bugged)  was available.

steeve nice way to make a quick and fun use of parse ...
I never thought about it

i like this example it's short and has many of the parse  features. 
Even if I'm not able to precisely understand how it works i can sense 
globaly that he inserted in his main rule 4 depth parsing level using 
sub rules. He stores sub result of each depth. Each depth is then 
computed and it's result it's passed to the upper level. that's nice 
really ...

BrianH: has Carl noticed n BREAK? It is not in priority list, and 
it could escape Carl's radar, no?