PARSE Bootstrap Compatibility Strategy

Domains Parsing
1

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"...you 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"...so once I was convinced it is a good idea, the sooner the change starts the better.

2 Likes
2

Sometimes we make mistakes and realize there's better ideas... and this is one of those cases...

New plan: Compatibility PARSE2.

Since UPARSE is going to have the ability to use a set of combinators that make it act like Red or R3-Alpha (so-called UPARSE2) there's no good reason to be throwing in these hacks.

Instead I'm saying that PARSE2 is a mode of the old native parse codebase to act like it used to. If you want the old behavior (e.g. plain SET-WORD! marks location into a variable, no need for <here>) then use PARSE2.

So the bootstrap executable will just define PARSE2 as its PARSE.

Significantly less confusing, and this makes it easier to be aggressive in aligning the native PARSE with the superior designs that are coming out of UPARSE, as the codebases are merged.

But to make it easier to find these assignments and upgrading, I'm stylizing them.

; old bootstrap code might say this
parse "aaa" [pos: some "a"]

; new bootstrap code breaks these to their own line with comment
parse2 "aaa" [
    pos:  ; <here>
    some "a"
]

Then fix them up later.

1 Like