Skepticism of PARSE preserving *precise* input type

A thorn in the side of those parsing BINARY! in Rebol2 was that with COPY, PARSE forgot that it was parsing a binary...and gave back a STRING!:

rebol2>> parse #{AABBCC} [#{AA} copy data to end]
== true

rebol2>> data
== "»Ì"

A seemingly-plausible line of thinking would say that COPY (or position marking) should preserve whatever the type of the input was. That was done in R3-Alpha and Red. It fixes the BINARY! problem, but had other consequences...like that you'd capture a "PAREN!" and not a BLOCK! if your input was a "PAREN!":

red>> parse quote (aa bb cc) ['aa copy data to end]
== true

red>> data
== (bb cc)

As nice as that rule seems on the surface, it maybe doesn't make complete sense. PARSE doesn't heed delimiters, it's processing content.

red>> parse <abcd> ["a" copy data to "d" skip]
== true

red>> data
== <bc>

That's... a little bit sketchy in the sense that you're getting <bc> back out of something that never had < adjacent to b, or > adjacent to c. If you print it out, this has an air of fabricating something artificial... while a TEXT! string of "bc" would be more agnostic of a result, with no delimiter. (This raises some questions about the semantics of COPY on such types more generally, so it may be a bigger discussion than just PARSE.)

But what about PATH!?

red>> parse 'a/b/c [copy x some word!]
== true

red>> x
== a/b/c

red>> parse 'a/b/c [copy x [] 'a 'b 'c]
== true

red>> x
==

An empty path is an undesirable way to get a collection back (as is an element-1 path). So undesirable--in fact--that Ren-C has made construction of such paths illegal.

Were people really clamoring to parse TAG! and get TAG!-bits out of it, or to parse PATH! and get PATH!-bits? Are people having to take what they get and convert it to ordinary text strings or blocks anyway?

Is it perhaps the case that full type-preservation over-reached...when what was really needed was just to recognize BINARY! as its own category to be preserved?

I've wondered about the usefulness of this before and don't see the value in it.

1 Like

Wanting BINARY! seems very valid. The rest, it seems to me that it's break-even, at best.

How often do people capturing characters out of a tag want a TAG!?

I suppose it’s possible that someone starting with a tag would want a tag back, but it doesn’t seem that valuable. I’ve never liked the TAG! value much to begin with, so I generally avoid using it in the first place.

1 Like