PARSE Bootstrap Compatibility Strategy

Working with assignments in UPARSE via SET-WORD!s has convinced me that it's the right strategy.

I was a little hesitant before because it might make PARSE code "look too much like DO code". But the reality seems to suggest that's not so much of an issue. At least...if you have a problem with dialects looking "kind of like other Rebol code because it uses the same bricks" are kind of out of luck, because that reuse is the idea of the language.

I've gone ahead and made the changes to PARSE for capturing positions with POS: HERE and for seeking positions with SEEK POS.

For the moment, any other usage of a "lone" SET-WORD! will cause an error. It will be like that for a little while to help catch violations.

Note: HERE is more useful than just capturing with SET-WORD!. Because a rule which evaluates to the current position can be used in places that take more than one rule.

Imagine you wanted to use it with BETWEEN:

 parse "<<<stuff>>>" [
     left: copy some "<"
     (n: length of left)
     x: between here n ">"

So this wants to count the number of less-than signs, and then match an equal number of greater-than signs. HERE can serve as a rule for the left side of the capture, to say "just use the current position for the left rule".

How To Deal With Bootstrap?

For most people, the change should be easy, and make code look better. (Be sure to take the opportunity to see how much nicer COMMA! can make things.)

For bootstrap, it's trickier. What I have hacked up so far is that anywhere there is a :pos in the code, change that to seek :pos. Then, bootstrap code just has to define SEEK to a no-op rule. That way it will work in both old and new executables.

Similarly, HERE can be defined to a no-op rule in bootstrap. This way pos: here will behave as capturing the position under either behavior.

The bootstrap executable allows SET-WORD! to come after a SET. So during the compatibility period, we would just allow SET FOO: to act the same as FOO:.

I do not think PARSE COLLECT is used in bootstrap, so changing it from COLLECT DATA: to DATA: COLLECT shouldn't matter.

The tricky case is COPY. COPY X: would just have to stay a synonym for X: COPY. It's easy enough to recognize. The deal would be that you just have to use a SET-WORD! after copy in the bootstrap executable instead of a plain word which could be a rule in the new world.

Anyway, there's been a long uncertain period of "is changing the operators a good idea or not" once I was convinced it is a good idea, the sooner the change starts the better.