Comments on: PARSE enhancements in progress
The next release (A83) will include many of the parse enhancements that have been suggested by the community (over several years) and listed in the PARSE Project.
To see what's been implemented so far, browse the R3 Changes page. It currently includes NOT, FAIL, STAY, and QUOTE features. These features will make parse more powerful, and there are more on the way. If there's a feature critical to your work, please be sure to let us know.
I would like to thank BrianH and Peta for organizing, prioritizing, editing, and maintaining the project document listed above, and the community-at-large for many of the suggestions.
14 Comments Comments:
shadwolf
19-Sep-2009 2:57:55 |
Parse is the core main feature in rebol and it has to be very pushed to the best possible of the concept.
I like the idea of the not instruction to disable parsing on spécial cases.
I was looking a way to do that for viva-rebol for example.
After well on parse i really have problems to understand how it works.
| Brett Handley
19-Sep-2009 10:25:17 |
Been a while since I've been here and good to see the improvements to parse.
Parse is great at translating data into actions, but not so great at translating data into blocks.
What I would have liked to have seen is a mode of Parse which emits a block result of tokens based upon the given data and rules.
From reading the proposals I'm not sure if this was considered and rejected or just not considered.
I made a stab at this idea years ago, and if I'm not clear above then have a look at the "tokenise-parse" function in this script:
http://www.rebol.org/documentation.r?script=parse-analysis.r
Cheers. | Ratio
21-Sep-2009 20:35:34 |
I probably will never use functions like PARSE.
Checked all that in LINUX.
It never works as expected. Much too complicated.
I feel much better of to write my own search functions. REPLACE is a very good basis to do all things normally needed.
REBOL is better off to care for BASIC functions normally needed by developers.
Ratio
| -pekr-
21-Sep-2009 21:12:14 |
Ratio - as for coding, I am an average user, yet I am able to use parse for the good. Parse is cool solution and not so complicated and I think that improving parse is a really good move. If you don't use it, fine for you, but other ppl might regard it being one of big REBOL advantages ... | Jerry Tsai
21-Sep-2009 22:34 |
I use PARSE all the time. I find it very easy and powerful. With Unicode support and the new enhancements, it will be even better than it is now. Anyone who has not used it yet should give it a try. | Henrik
22-Sep-2009 5:38:51 |
I agree that PARSE is extraordinarily powerful, but it must be excruciatingly well documented. Even kinks and weirdness must be in there. It has taken years for the public to notice most features in PARSE and I as recently as two days ago found a new thing, I hadn't seen before. | ingo
22-Sep-2009 7:36:01 |
set, copy, thru and to
should accept all possible rules, not like this. (I had to make up an example fast ...)
>> parse [a b c x y z][copy [to 'x]]
** Script Error: Invalid argument: to x
** Near: parse [a b c x y z] [copy [to 'x]]
| -pekr-
22-Sep-2009 8:34:51 |
Ingo,
you seem to miss your copy variable. Copy has different semantics in parse - it is not like in REBOL - copy value, but it reads - copy into-variable till-rule:
>> parse [a b c x y z][copy result to 'x to end]
== true
>> result
== [a b c]
You can look here - http://www.rebol.com/docs/core23/rebolcore-15.html#section-7.3 , but maybe you had something different in mind ... | Ingo
22-Sep-2009 10:42:35 |
Hi Pekr,
ok, my example was wrong, but I remember there are some problems with 'to and 'thru and sub-rules.
I'll try to find a correct example tomorrow (when I have access to a computer with rebol and internet again). | -pekr-
22-Sep-2009 11:03:17 |
Ingo,
no need to find an example. IIRC 'copy really does not work with rules - you can't do "copy result to rule" ... | Ladislav
22-Sep-2009 15:55:27 |
It is unbelievable, how careful Carl is, when picking the dialect keywords. In my opinion, both STAY and QUOTE will be more understandable for the uninitiated, thanks for taking care. | Ingo
23-Sep-2009 1:25:03 |
Actually, the problem is with 'to and 'thru.
>> parse [ a b c d e f g ] [ [to 'd | to 'f] a: to end]
== true
>> parse [ a b c d e f g ] [ to ['d | 'f] a: to end]
== false
| -pekr-
23-Sep-2009 7:29:25 |
Ladislav, how do you like the fact, that STAY might change its name to AND or & in fact? | -pekr-
23-Sep-2009 7:38:13 |
Ingo,
this is not the right place to talk more deeply about parse examples, I suggest ML or AltME channel, but to your example - what you are looking for is multiple to/thru, which is hopefully going to be added.
Your above rule might not be what you are looking for. Most usually we do want FIRST match. Imagine if 'd is at the very end of the input stream, whereas 'f is first. With your rule, 'd would be matched anyway, even if last in the input stream, and even if 'f is first in the input stream.
To give you a general idea:
>> parse [ a b c d e f g ] [any ['f (print "f") | 'b (print "b") | skip]]
b
f
== true
;-- whereas your aproach fails ...
>> parse [ a b c d e f g ] [[to 'f (print "f")| to 'd (print "d")] to end]
f
== true
Hopefully multiple to/thru proposal gets implemented, as it will surely make life of ocassional parse user easier ... |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
