Comments on: PARSE: the DO keyword

The DO keyword requested by Gabriele has been added to parse in A91.

It is an advanced parse action that evaluates the input block as REBOL code then uses a rule to match the result.

For example:

>> parse [1 + 2] [do integer!]
== true

or, more specifically:

>> parse [1 + 2] [do quote 3]
== true

and:

>> parse [append "ab" "c"] [do "abc"]
== true

and it operates inline, as you can see from the literal word test used below:

>> parse [test append "ab" "c"] ['test do "abc"]
== true

The DO keyword only works with block inputs (not strings), and only specific match cases are valid: skip, none, end, quote, into, and a direct value.

More examples:

>> parse [] [do end]
== true

>> parse [none] [do none]
== true

>> parse ["abc"] [do none]
== false

>> parse [] [do none]
== false

>> parse ["abc"] [do "abc"]
== true

>> parse [append "ab" "c"] [do "abc"]
== true

>> parse [remove "abc"] [do "bc"]
== true

>> parse ['abc] [do 'abc]
== true

>> parse ['abc] [do 'a]
== false

>> parse ["abc"] [do ["a" "b" "c"]]
== false

>> parse ["abc"] [do string!]
== true

>> parse ["abc"] [do number!]
== false

>> parse ["abc"] [do series!]
== true

>> parse [1 + 2] [do quote 3]
== true

>> parse [1 + 2] [do quote (1 + 2)]
== true

>> parse [append [a] 'b] [do into ['a 'b]]
== true

>> parse [append "ab" "c"] [do into ["ab" "c"]]
== true

>> parse [num: 1 + 2] [
    set var set-word!
    do [set num integer!]
    (print [var num])
]
num: 3
== true

Note this final example. Prefix actions are not currently valid for DO. Here, the num is set within the DO match rule. That is, you must write:

do [set num integer!]

not:

set num do integer!

but, that may be added in a future release.

This feature was non-trivial to implement, and it is worth testing well to make sure that it's solid.

5 Comments

Comments:

Gabriele 17-Oct-2009 6:03:43	The only issue I see is that without causing an error when the rule does not match, unwanted side effects may happen in case of backtracking. This of course can also be solved by just telling users that DO should never be made to backtrack...
Brian Hawley 17-Oct-2009 7:53:03	If prefix actions aren't valid for do, does that include change? The change action could be used to do memoization when combined with do, which could be a solution to Gabriele's backtracking issue.
Ladislav 18-Oct-2009 7:34:09	I do not plan to use this feature at all.
Book Siberia 18-Oct-2009 10:34:57	(at)Ladislav: >> parse [test append "I do not plan to use this feature at all" "R U kidding me?"] ['test do tell!] == true
Carl Sassenrath 19-Oct-2009 16:33:35	Gabriele: somehow I missed that requirement about throwing error on non-match. However, any parse production can have side effects that are irreversible in the backtrack. So, do is not unique in that regard. We can warn users to take care in its usage. BrianH: yes, that use of change is not allowed either. If we want full support for all variations of do it's going to take rewrite. At the heart of the problem is the implicit switch of the input series in the middle of a parse phrase (it is parsing the output of the evaluator.) For example, if we use copy are we copying the unevaluated block or its evaluated result?

Post a Comment:

You can post a comment here. Keep it on-topic.