Contemplating UPARSE-VALUE

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>]
== 3

>> uparse-value "foo" [integer! (print "int") | text! (print "text") || <input>]
== "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.


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