Role of @(xxx) in PARSE

I'm trying something different now, with @[...] => ACROSS [...]

This helps keep BLOCK!-like things meaning "rule" in PARSE's dialect.

UPDATE: I have changed my mind back on the following, but putting it here for historical reference. See post below.

Consequently, if you wanted to keep a BLOCK! of material you'd have to use a SET-GROUP! with a BLOCK! in it:

 keep @([some integer])

I think this makes more sense when you look at it from all the angles.

I've changed my mind on this with what "@" means, just generally. This seems like a job for QUOTE.

data: [some rule]
parse [[some rule]] [quote @data]

QUOTE would say you're looking to turn the argument into a rule to use literally, as if you had written:

parse [[some rule]] ['[some rule]]

We might call this LIT/LITERAL/LITERALLY because that's what it means. But I think that it will also evaluate to the quoted rule, so QUOTE might not be a bad name for it. We're currently allowing matched tokens to evaluate to themselves:

>> parse "ab" ["a" x: "b"]
== "ab"  ; e.g. matched.

>> x
== "b"

It's not as useless as it seems. You might want to match something -and- know what matched. The identity of the thing you matched can be a convenient macro for that.

>> parse "ab" ["a" x: ["b" | "c"]]
== "ab"

>> x
== "b"

See what I mean? So, in the case of this QUOTE operation, evaluating to the quoted rule has the advantage of communicating the match just as you would with other material.

>> r1: first [b]
>> r2: first [c]

 >> parse [a b] ['a x: [quote @r1 | quote @r2]] 
 == [a b]

 >> x
 == 'b

Nothing had to be synthesized, because you're using the rule itself as the identity of the result. So it's cheap.

Anyway, this is just me trying to justify why giving the operation the somewhat mechanical name of "QUOTE" could be savvier than trying to dissociate from the idea of quoting when doing a literal match.

2 Likes

I wanted to preserve the bit of what I describe above about the usefulness of having a parse rule that is for explicit matching "evaluate to" ("bear a value") that is the matched thing. Because that is certainly an eye-opener for being able to apply it.

But I think I've convinced myself that @rgchris had the right instincts on making it possible for undecorated value-bearing GROUP!s to be arguments to things like KEEP. It's just that prior to UPARSE we didn't really have an explanation for what about the character of KEEP's argument made it a sensible candidate to take either a rule or a value.

The best explanation I've written so far of what PARSE was missing is when I talk about lessons learned from binary parsing in ENCAP. When we more closely parallel the design of parser combinators... to think more simply in terms of advancement on input (or "remainder") as a separate data channel from the synthesized value... it becomes clear. KEEP wants rules that synthesize values, and not all rules do this. But GROUP!s synthesize by running DO code, and they leave the input exactly where it was.

I feel a bit dumb for not having the words to say this previously, but the code for parse just wasn't set up to very conveniently say it. Because everything was being done strictly in terms of the advancement of input.

Anyhow, I think Chris can be pleased with the outcome. But this means that SYM-GROUP!, SYM-WORD!, and SYM-PATH! can act as the "match this literally" that I was looking for at the outset. It's even better.

Thinking of the last value-bearing result "falling out" of a BLOCK! parse rule is looking to be something of a watershed change.

:partying_face:

1 Like