Skepticism of PARSE preserving *precise* input type

Domains Parsing
1

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?

2

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

1 Like
3

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!?

4

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