Does SET/ANY, GET/ANY-thing matter anymore?

Development Naming
#1

One of the reasons I said I did not like /ANY on GET and SET is because it didn't seem a good match for OPT-ness. And ANY is a very common construct. So if people get in the habit of naming their refinements /ANY it would be kind of irritating. One doesn't want to set a bad precedent.

But for reasons that have been reasoned to death, SET-WORD! doesn't error on null assignments, it just clears the variable. That's firm now. Re-read the post if you need to.

It thus seems to make sense that SET of a WORD! would do what a SET-WORD! would do, and not error. And GET returning a null seems okay, since most routines don't take NULLs as input. If you really want to check something is not null you can do that on the result...e.g. non null get word.
(Still shopping for a single term for "non null".)

So there'd seem to be no need for a refinement... except...

...something has to be done about VOID!

VOID! assignments still cause errors on SET-WORD!:

>> x: print "still an error"
** Script Error: x: is VOID!

If you want to write truly generic code (like, say, a READ-EVAL-PRINT-LOOP), you want to really accept not just nulls, but also "ANY"-VALUE!...and that counts void.

So we have a situation where:

  1. This comes up nearly almost never.
  2. "ANY" actually sort of feels like it is sensible for the behavior you're expanding, since it's no longer talking about non-ANY-VALUE!d NULLs.

Hence I may be willing to bring GET/ANY and SET/ANY back, but under the new meaning applying to #[void].

But still, get/any 'some-unset-var will answer UNSET? back. Regular GET would have done so too...but what's the harm?

Afterthought...should plain GET-WORD! not get voids?

If SET-WORD! won't set voids, it seems that maybe GET-WORD! shouldn't get them. You really aren't supposed to be using them as values or signals or anything.

I think I'd be comfortable saying you had to use a special function to get a void out of a variable.

#3

This post asks about naming for refinements on GET and SET... but it predates isotopes and ^META operations by a long while.

It came out of the era of splitting NULL out into a "non-ornery nothing". At the time of the split, the "ornery nothing" state was called #[void]... an idea which has forked off into a whole family of QUASI! and isotopic states... where the quasi states are allowed in blocks, while the isotopic states are not.

And now isotopic states aren't allowed to be assigned through normal SET-WORD!, with the usual expectation being that you would be required to use ^META operations.

It doesn't come up all that often that you need to set a variable to an isotope. It's generally preferable for variables to hold the ^META state, to make them easier to work with. Isotopes usually are only RETURN'd by functions at the last step of a transformation

But it does come up! For example, with multi-returns. The caller of the multi-return has to use a ^META variable in the calling block to receive an additional return value:

>> [x y]: some-multi arg1 arg2
** Error: Result for Y is a BLOCK! isotope, use ^Y to receive it

>> [x ^y']: some-multi arg1 arg2
== 10

>> y'
== ~[a b c]~

But in the implementation of SOME-MULTI you need a way to assign such outputs, and a plain SET-WORD! won't let you do it.

This connection to ANY-VALUE! is no longer relevant.

You're just talking about setting something to a state that is potentially isotopic. But not necessarily.

set/isotope sounds like you're saying that you're guaranteeing it's an isotope, or that you want the value being passed in to be made isotopic if it wasn't already.

It's not the most important renaming in the world, but uses of ANY are now consolidating into meaning more like "pick any one of". When you see SET/ANY the rhythm kind of makes it read like SET ANY [...] where it feels like a choice is being made.

So it's more like set/lax or set/permissive. Maybe set/core.

Just wanted to kind of resurrect the thread as the refinement needs to make a comeback on SET. I've had a specialization as SET* to avoid using a name at all, and this fits a pattern of sort of naming the lower level or unchecked versions of things with asterisks.

1 Like