Separating Parse rules across contexts

[hostilefork]

@Brett

Haven't got a great suggestion nor will comment on catch/throw due to lack of understanding, but I wonder if parse needs some some sort of built-in output channel (stack) that collects declaratively marked emit events - firing them according to some user defined policy (backtracking will not cause multiple of the same event).

I'm entertaining the notion that maybe PARSE rules when used in assignments act like DO, in terms of "evaluates to the last result".

This becomes more flexible with (...) rules becoming value-bearing evaluations (not inlined rules):

>> parse ["hello"] [num: [integer! elide (print "got here") | (0)], id: text!]

>> num
== 0

>> id
== "hello"

The existence of ELIDE allows the feature of not mucking with the results:

>> parse [3 "hello"] [num: [integer! elide (print "got here") | (0)], id: text!]
got here

>> num
== 3

>> id
== "hello"

Thoughts leading up to this from this thread:

https://forum.rebol.info/t/toward-reusable-rules-set-of-a-block-in-parse/1579

I talk about THROW and CATCH in that post as well. Maybe that's important to add too. But something about formulating a BLOCK! rule to return a result is interesting, as being more lightweight...and it would provide a sensible reason for why x: [integer! | text!] should work.

Anyway, the "big" proposal question is whether rules should evaluate to their last result...and if using that natural benefit of position has a good relation to how the evaluator works to use that as an advantage... it looks from where I'm standing this is a good move.