What Should "New Refinements" (e.g. :FOO) Evaluate To?

Development Datatypes
1

At one point I thought "new refinements" had a dialected purpose in APPLY to name the frame fields:

call:shell // [  ; infix APPLY
    [(system.options.boot) --suppress {"*"} print.reb 100]

    :input 'none      ; pipe input from /dev/null
    :output data: ""  ; write output to string
]

That's a bit contentious with other evaluative purposes.

But eventually I decided that was not as good as using plain SET-WORD. This requires you to put any random arbitrary assignments in GROUP!s, which is its own "contention", but not so much of a burden:

call:shell // [  ; infix APPLY
    [(system.options.boot) --suppress {"*"} print.reb 100]

    input: 'none      ; pipe input from /dev/null
    output: (data: "")  ; write output to string
]

It looks better, and fits with the already established modality of "assignment".

So :FOO Is Free For Other Meanings

What should those meanings be?

Ideally it would make some sense with the usage of leading colon for refinements.

In the past, :[...] was able to mean REDUCE. That was semi-useful, but it didn't get used as much as I might have thought.

Leaving these forms free and open for the user to redefine with RebindableSyntax is another possibility.

2

So I was considering that :foo could be a shorthand for try foo

:foo.bar would thus similarly be a way of asking for FOO.BAR and if it wasn't there, giving you back NULL.

Well it's an idea. I'm not going to run out and implement it immediately--many other things to look at.

4

As I found that folding TRY into OPT was likely a bad idea, that means when you want optionality of a potentially missing field you have to say:

opt try obj.field

Which could be more compact as:

opt :obj.field

Also, something to consider now, is that tuple-picking can give back an ERROR! as a value:

obj: make object! [
    try ^field: fail "you can do this"
]

This means that obj.^field can legitimately return an ERROR!. This calls into question my idea of using TRY on tuple picks to say "I want to get null if the field wasn't available".

So perhaps the leading colon could more narrowly mean "If the pick isn't there, give back null", so it doesn't wind up suppressing errors from meta-picks.

Narrowing it may be best, I don't know that I would want leading colon on function calls to mean "try". The history of leading colon as inert makes it feel like it should be inert, but beyond that it seems to me like a decoration like that wouldn't go with invocation.