World: r3wp

Brian, do you think, that a more "seamless" way how to do the above 
in parse shall be considered, or that this approach is good enough 
as it stands now?

Reposting the link:

http://www.rebol.org/view-script.r?script=use-rule.r

Very useful ...

( that was a pun :) )

hmm, I thought that in R3, parse variables are safe for recursion 
rules?

ah, there was USE 1 (BrianH) and USE 2 proposal (Peta). USE 1 was 
assigned for implementation, but deferred along with LIMIT, OF, REVERSE 
and some other proposals ...

Pekr, there are no "parse variables", as far as I know. My above 
code was inspired by BrianH and USE2

I know, but I reacted upon Carl's recent blog, and if Carl dares 
to use the incorrect terminology, then I can too, no? :-)


This function is useful because PARSE rules often store data in variables 
which, depending on how you handle them, can be overwritten by rule 
recursion. (Which is done often in parsing.)

parse rules often store data in variables

 is fine, but that does not mean, that there are "parse variables", 
 those are just variables

ok, as for terminology, how do I refer to following:

start: copy user to "</user>" :end (temp: find blk user)


while the code is not real, I can see three different "variable types":

- start: :end markers
- user parse level variable?
- temp: rebol level word?

Thanks :-)

Sorry if you find it nitpicking, but I wanted to point out, that 
an assumption that "parse variables are safe for recursion rules" 
should be wrong exactly because there are only variables in REBOL, 
which the interpreter does not have any reason to make "recursion 
safe" unless you specifically do something about it.

Regarding the above "three different variable types" - as far as 
the interpreter is concerned, there is no difference between the 
'start 'end and 'copy variables. You used them in a specific way, 
but, later, you can very well use another expression, where you write:

user: copy start to "whatever" etc.


So, you can easily see, that neither the 'start nor the 'user variable 
has any "variable type" you could infer based upon their usage in 
one specific expression.

err, I meant the 'start 'end and 'user variables

if you call 'temp a "rebol level variable" in the above example expression, 
how would you call it in the expression below?

(temp: either 1 > 0 [none] [[end skip]]) temp

So, generally speaking, it may be useful for you to use some some 
variables only as "markers", but that "variable type" is something 
you impose just to make the things easy for you to handle. The interpreter 
does not (and should not) make such distinctions.

temp is "rebol level variable", whose value is bound to parse dialect 
:-)

Hmm, what does the "bound" word mean?

As I said, you can use some variables for specific purposes only, 
but that is your decision, and is not supported by any interpreter 
property, and certainly is not useful for all purposes. I may want 
to use some variables in more "roles" than you want to.

hmm, then maybe not. Temp following the paren simply refers to the 
rule, resulting from previous paren expression evaluation ....

and hence is probably a regular rebol level word, just used inside 
the parse dialect?

In my opinion, all of the above 'start 'end 'user and 'temp words 
are "regular" REBOL words, while e.g. the 'copy word above is actually 
a parse dialect keyword

corret ...

and - it was not nitpicking on your part - using the correct terminology 
where possible is important, as it helps to correctly interpret the 
way in which the language works. It is just lack of knowledge on 
my part, that I confuse the terms ... exactly because I often don't 
understand the internals ...

start: :end and temp: would just be called set-words and get-words, 
either within the Parse dialect or the Do dialect (Do dialect being 
"rebol level")

To be even more precise;

The 'copy word above is also a "regular" rebol word (it just happens, 
additionally, to be interpreted by PARSE as a keyword in the PARSE 
dialect).

Re start: and :start e.g. - they are values of different datatypes, 
but can be seen as just one variable.

http://www.rebol.org/view-script.r?script=use-rule.rupdated. Changes: 
now it implements both USE-RULE variants as described in http://www.rebol.net/wiki/Parse_Project
.

Hi, I rewrote http://www.fm.tul.cz/~ladislav/rebol/evaluate.rto 
contain slightly more comments and to use the USE-RULE function, 
so that it now became a more complex example of its usage.

I hope everyone struggling with local variables in PARSE to find 
this a much more comfortable way.

On the other hand, I expect the %evaluate.r to have a value of its 
own, since it shows how to handle expressions using PARSE, while 
being able to respect different priority/associativity rules sets.

The funny thing about it is, that just one local variable per parse 
rule was quite sufficient in this case, although the example isn't 
trivial in my opinion.

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse#Local_variables_in_parse_rules
, a new subsection in the REBOL Programming wikibook.

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse#Local_variables_in_parse_rules

a new section in the REBOL Programming wikibook

wowo, most awesome Ladislav!

Pekr, knowing that you were interested in the subject as well, I 
sincerely hope, that you read the wikibook subsection, run the examples, 
and let me know what you are missing in the doc and in the functionality.

thanks, Janko

hi, i would you to parse a string like this {number: 123456 name: 
abcd message: i like rebol}

i would like to use parse to do it

something like this way parse mystring ["number:" number: "name:" 
name: "message:" msg:]]

a get number, name and msg . is that possible ? and how ?

is the data guaranteed to be rebol compatible?  (you can use 'LOAD 
on it and it will never return an erro)

but mystring is like this {Number : 10017
Name       : Disable Message Partner
Application: MXS
Severity   : Info
Type       : Alarm Event
Date-Time  : 20/09/10 12:39:43
GMT        : Mon Sep 20 10:39:43 2010}

i start to use => parse mystring [thru "Number  :"  number: to end]

i would like to do => parse mystring [thru "Number :" number: to 
"Name    :" ] but this don't work !!!!]

using 'TO or THRU rules is garanteed to make you life a nightmare 
for arbitrary string parsing, unless its very linear in content.

isn't there a rebol string parser on rebol.org which has the basic 
parsing rules to filter out rebol data?

with a few search I didn't zero-in on it, but I seem to recall seeing 
that before.

otherwise, you can just do a line by line parsing, filtering out 
"keywords" at the start and then loading the data after the ":"

if i can't use parse i will do this

but it is very strange. i heard that parse is very powerfull. and 
now i can't use it because if to difficult !!!!