Should "Arity-2 INTO" in UPARSE actually just be... PARSE?

There's a cool feature that UPARSE's INTO is willing to take a rule that gives the boundaries of the data you want to copy, and will make the copy for you:

>> uparse "(1 1 1)" [
    into [between "(" ")"] [data: <here> (print mold data) some integer!]

That will give you:

"1 1 1"  ; notice no ")" because the INTO copied the data spanning the rule
== 1

(I threw in the INTEGER! transcode for fun there. Note that Red allows the transcoding rules for datatypes as well, but only on BINARY! input series. It's because they don't have UTF-8 everywhere, they'd have to rewrite their scanner to process variable-width strings. One of the uncountable Ren-C design advantages...)

More generally, you can pass any variable you want to INTO.

>> uparse [1 2 3] [some integer! into ("aaa") some "a"]
== "a"

But... Couldn't We Just Call That PARSE?

This arity-2 INTO takes an input, and rules. Why isn't that just PARSE?

Difference is that since it's inside a parse already, its first parameter will be treated as a rule and use the synthesized result...unless you put it in a GROUP!. But that's implicit. Maybe call it SUBPARSE to be clear?

It would free up the keyword INTO, maybe to be compatible with historical single-arity version, for cases that have already figured out they're at a series value and don't want to repeat themselves by giving a rule that matches where they know they are.


I would just call it parse. We're in a different dialect there, so one has to be aware of that anyway.

Dialects all the way down.

I think SUBPARSE makes it more clear what's happening here. I think there's potential for confusion if it's just called PARSE.

Another argument for why to call it SUBPARSE is my proposal for functions automatically becoming combinators if they fit a certain pattern.

That pattern is to take an INPUT and then have on their return results something indicating progress.

What would happen then would be the function would act like a combinator...having one less parameter than usual (e.g. the INPUT is now implicit, from the data being parsed).

This would make PARSE an arity-1 synonym for SUBPARSE <HERE>, not plain SUBPARSE.

Whether UPARSE actually chooses to bend its interface to be willing to act as that combinator or not, it's still a point of coherence. I'd say that pushes it over the edge to say it shouldn't be called just PARSE. SUBPARSE seems good.

1 Like