(Note: I have been calling /FOO/BAR a "refinement", so refinement? '/foo/bar is true)
For a long while, I was hesitant to commit /foo to being inert, because I wondered if there was some greater meaning for it in binding.
But now I'm resigned to it. Which gives a somewhat interesting result: a whole category of bound dialecting parts that you know aren't meant as variable references.
We already see how well this works with TUPLE! and predicates. If they weren't inert, you'd have to worry that until .not.even? [...] should be interpreted as (until .not.even?), ([...])
What Cool Role Could Refinements Have?
The original suggestion for predicates actually used refinements. But until /not/even? [...] didn't seem to be as good, so tuple was used.
But is there a good use at callsites?
Something I observed today was that /(...) and /[...] open up a new GROUP! and BLOCK! type, at the very least. What might this mean in PARSE, and could it be connected to a meaning for words like /rule or /obj/member ?
The only connotation refinements have right now is "optionality" and...parameter-ness? The optionality could be one focus:
>> did parse [a c] ['a /['b] 'c] ; synonym for `opt ['b]`
== #[true]
rule: ['b]
>> did parse [a c] ['a /rule 'c] ; synonym for `opt rule`
== #[true]
That's not compelling, clearly. But I'm just trying to stimulate thoughts on what it might be used for.
Perhaps it could be the "matches literally, not as a rule" concept?
>> data: [some integer!]
>> parse [[some integer!] [some integer!]] [2 /data]
== [[some integer!] [some integer!]]
This could build conceptually on the "more inert" form (as opposed to an active rule). Though I kind of liked the "as-is" connotation of @data. But perhaps this would be easier on the eyes.
This points out something I hadn't thought about... that refinements could have been used for other signals:
>> append [a b c] [d e]
== [a b c d e]
>> append [a b c] /[d e]
== [a b c [d e]]
>> append [a b c] '/[d e]
== [a b c /[d e]]
>> data: [d e]
>> append [a b c] /data
== [a b c [d e]]
I had a vague inkling that it might be used in blaming function parameters:
>> foo: func [x] [fail /x "Pointing at problem"]
>> foo 10
** Error: Pointing at problem
** Where: foo console
** Near: [foo 10 **] ; note it indicates callsite, not the FAIL site
That sort of makes sense, because /FOO is likely to be used in the apply dialect to name parameters. So this could be seen as better than fail @foo. What makes me a little uncomfortable with it is that paths and URLs will be legal as the error ID, so having a "slashed thing" might seem repetitive in a way that the @ would not.
This is just a brainstorm pointing out the existence of an available new-old-type. I'd be interested to hear any ideas or feelings on what PARSE might do with it...
Then...What About GET and SET Forms?
There's four assignment forms to deal with:
.foo.bar::.foo.bar/foo/bar::/foo/bar
What would these be for?
I've proposed terminal slash and dot be a commentary on whether the thing being gotten or assigned is allowed to be an action or not. Though that seems to make :foo.bar. and foo.bar. synonymous, as the GET only has impact on actions...and you're assuring it's not one.
Just more stuff to think about. My suggestion for anything that doesn't have an interesting novel answer yet is to just make it error...to save it for meaning something in the future.