r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Parse] Discussion of PARSE dialect

BrianH
28-Sep-2009
[4071x3]
Sorry, that would be a different operation.
Shorter than FROM or GATHER though.
Wait, ONE wouldn't work, since you actually get all of the rules, 
just not in order.
Steeve
29-Sep-2009
[4074]
I posted examples to show why a84 is more rebolish. http://www.rebol.net/cgi-bin/r3blog.r?view=0255#comments
Pekr
29-Sep-2009
[4075x2]
looks good ...
Steeve - will better parse help with editor? IIRC it was you and 
Shadwolf, who did it?
Steeve
29-Sep-2009
[4077]
A little, but the main drawback i have with parsing in editor is 
that parse doesn't handle incremental parsing.

Because i do parsing line by line to be able to parse only modified 
lines.

So that, i have to rewrite all the rules (describing the document) 
in an obfuscated way to deal with incremental parsing.
Pekr
29-Sep-2009
[4078]
BrianH has some plans towards "streamed" parsing. Hopefully it can 
be done over ports in the future ...
Steeve
29-Sep-2009
[4079]
Actually, we can simulate streamed/incremental parsing. But we need 
to transform all the input rules (it can be automatized).
I would prefer an inlined behavior of parse for such purpose.

It's why i asked to Carl if we could return the rule stack during 
parsing (i.e. with a special command).
Pekr
29-Sep-2009
[4080]
What was the answer? I missed your request during yesterday's chat 
probably ...
Steeve
29-Sep-2009
[4081]
Request delayed for R3.1
Pekr
29-Sep-2009
[4082]
3.1 - that will be in Spring, so I think that we can wait ...
Steeve
29-Sep-2009
[4083x3]
it seems
parse is in mode parse/all by default now, but we can remove the 
option, a bug ?
*we can't
BrianH
29-Sep-2009
[4086x2]
/all still affects simple parse (splitting instead of rules).
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.
Steeve
29-Sep-2009
[4088x2]
yep we could start by building a compiler of rules into  incremental 
ones (with rebol i mean)
i made some tests in the past
Steeve
30-Sep-2009
[4090x2]
About STAY, i don't see the interest to continue even if the following 
rule is not matched . Can someone give an use case ?

because when i  do this:

>> parse [1] [stay skip ?? to end]
to: [1]
== true

or

>> parse [ ] [stay skip ?? to end]
to: [ ]
== true

it's like doing:
>> parse [ ...] [?? to end]

STAY have no purpose to my mind...
It's just a little annoying, see:

>> parse a: "12" [remove copy val skip] print [a val]
==2 none


So, the [remove] treats well the [skip], but discard the content 
of [copy val]

Now, see:

>> parse a: "12" [remove [copy val skip]] print [a val]
== 2 1


The content of [val] is preserved in that case, don't know why here, 
but not above...
Pekr
30-Sep-2009
[4092x2]
I would expect 'val being 1 in both cases .....
But maybe reading the "expression" the REBOL way - from left to right, 
is not correct?
Steeve
30-Sep-2009
[4094]
i rather think it's a bug
Anton
30-Sep-2009
[4095]
Is it that REMOVE takes one argument?
Pekr
30-Sep-2009
[4096]
Yes, it takes on argument - the rule ...
Anton
30-Sep-2009
[4097]
(I'm just reading that new blog article about it... Sorry for adding 
new ignorant question before doing anything to alleviate my ignorance.)
Pekr
30-Sep-2009
[4098]
sometimes getting reply here on altme is faster than reading corresponding 
article :-)
Steeve
30-Sep-2009
[4099]
That's not the problem, SET VAR ot COPY VAR are not rules, they should 
not be "viewed" by REMOVE
RobertS
30-Sep-2009
[4100]
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
Steeve
30-Sep-2009
[4101]
It's not a bug, it's behaving like Carl wanted. 
The final question is:  To do what ?
Pekr
30-Sep-2009
[4102]
STAY could be a by product by wrongly implemented AND.
Steeve
30-Sep-2009
[4103]
Yep, a bye bye product
Pekr
30-Sep-2009
[4104]
express yourself via channels Carl listens to - blog, chat, or even 
better - CureCode ... :-)
Steeve
30-Sep-2009
[4105]
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 ?
Pekr
30-Sep-2009
[4106x2]
this is how it works in A84?
And we still don't have IF, USE, INTO string!
Steeve
30-Sep-2009
[4108]
just think how you would do my example with standard code, it would 
be more verbose.
Henrik
30-Sep-2009
[4109]
how does skip not end work? I don't get it.
Pekr
30-Sep-2009
[4110x3]
skip is skip,no?
not end means, that the rule is matched as true, if not at end ...
it is kind of check
Henrik
30-Sep-2009
[4113]
does skip mean, skip 1 element?
Pekr
30-Sep-2009
[4114x3]
if not at end, insert [.]
yes, skip is skip 1 by default ...
not skip 1, but 1 skip ....
Henrik
30-Sep-2009
[4117x2]
ah, forgot that the block is only of max. three values
BTW, why are we saying END instead of TAIL ?
Steeve
30-Sep-2009
[4119]
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 
]
Henrik
30-Sep-2009
[4120]
I think I get it now, thanks.