Contemplating UPARSE-VALUE

Domains Parsing
1

Once upon a time, PARSE was willing to take rules that were not BLOCK! and do "simple parsing". Ultimately this was thought better of and became SPLIT...because that wasn't a very interesting polymorphism.

But... since PARSE is at heart a matching task, it seems there might be more accommodation when the input value is not a block... and you want to do some top level pattern matching. Consider something like this:

case [
     integer? item [
         print "Not a series, so, have to write handling code here"
     ]
     text? item [
         print "A series, but maybe we want to do something else"
     ]
     block? item [
         print "Okay finally we can use the parse we mean..."
         uparse item [...rules...]
     ]
] else [
   fail "Whatever"
]

It's something of a missed opportunity, and when I see this I start thinking along these lines:

uparse reduce [item] [
     integer! (print "More convenient, perhaps...")
         |
     text! (print "Depends on the use case...")
         |
     into block! [
        (print "Your rules here I guess...")
     ]
] else [
    fail "Whatever"
]

Now imagine that being something like UPARSE-VALUE instead of UPARSE REDUCE [ITEM]...but with additional cleverness.

One aspect of being better would be that if your input was calculated, you could still call it up with <input> ... although that wouldn't be available to the code in groups automatically:

>> uparse-value 1 + 2 [integer! (print "int") | text! (print "text") || <input>]
int
== 3

>> uparse-value "foo" [integer! (print "int") | text! (print "text") || <input>]
text
== "foo"

But you're no worse off than in a switch statement that doesn't have calculated input captured under a name. (Slightly better, in fact, since you have a means of calling up the calculated input.)

It's just a thought, because I've seen this pattern several times: "I have a decision tree but I can't start doing parsing until I have a series". This is just an idea about stretching all the matching and extraction logic that is going to be needed in UPARSE anyway to apply to single values.

UPARSE-VALUE or UPARSE/VALUE

This strongly parallels the LOAD-VALUE vs. LOAD issue. It seemed to make more sense in that case to separate it out so LOAD was fully generic and unconcerned with the /VALUE aspect. This might or might not have the same rationale as to why UPARSE shouldn't internally be concerned with the behavior.

1 Like