Antiform TAG! As "Triggers an Error On Access" Type

[hostilefork]

In the post "Shades of Distinction In Non-Valued Intents", I had originally written:

@hostilefork

Eventually the NULL state became the isotopic status of the WORD! null, so a ~null~ antiform.

It joined ~true~ and ~false~ as being antiforms you could test for truthiness and falseyness. But if you were okay with getting an error on conditional testing, any other word could be used:

  config: ~initialize-system-not-called~

  initialize-system: func [
      {Let's say this function reads the config file}
  ][
      ...
      config: [...]
  ]

This usually causes a nice labeled message anytime someone tries to use CONFIG:

Going this route would create a pain point for anyone who thought they were going to test for whether you had a config initialized by testing if config [...]. So that has to be considered as whether it's what you want.

I've come to question this as things have gone on, to where I'm wondering if all antiform words should be reserved by the system (there are system purposes for the ~end~ antiform, for instance).

A generic "error trigger" might come from something like antiform TAG!, permitting spaces:

config: ~<INITIALIZE-SYSTEM not called>~

initialize-system: func [
    {Let's say this function reads the config file}
][
    ...
    config: [...]
]

>> config
** Error: INITIALIZE-SYSTEM not called

[bradrn]

@hostilefork

I've come to question this as things have gone on, to where I'm wondering if all antiform words should be reserved by the system (there are system purposes for the ~end~ antiform, for instance).

A generic "error trigger" might come from something like antiform TAG!, permitting spaces

I like this idea! TAG! does feel like the right type for this.

[hostilefork]

@bradrn

TAG! does feel like the right type for this.

I actually got the original idea for having "named trash" from some scripts @rgchris had where he had configuration in the header of a script, something in the spirit of:

Rebol [
    Title: "Configurable Foo Interface Script"
    DLL-Directory: <directory where FOO.DLL lives>
]

...stuff...

if tag? system.script.header.DLL-Directory [
    fail "Set the DLL-Directory in the header to where FOO.DLL lives"
]
libfoo: make library! system.script.header.DLL-Directory

I thought "hm, that's an interesting idea, a sort of placeholder...would be better if it errored on accidental access".

So when TRASH! was initially conceived--prior to isotopes--it was a reified type that started and ended with tilde (actually called BAD-WORD!)

 DLL-Directory: ~directory-where-FOO-DLL-lives~

That does show weaknesses in having to convert the dots and spaces to dashes. So going back to the original placeholder type of TAG! is an interesting move.

It's tempting to say that the whole category would be called TRASH! and take over that role. But unfortunately <> is a WORD!, so there'd be no slight-looking ~<>~ trash for unset variables. It would have to be ~<unset>~ or something like that, which doesn't have the brevity of ~ that I am very attached to now... though there is a slightness to it which can sometimes be undesirable.

It seems to me that DEFAULT should treat these as unassigned:

>> x: ~<some placeholder>~
== ~<some placeholder>~  ; anti

>> x: default [10 + 20]
== 30

>> x
== 30

>> x: default [3 + 4]
== 30

But does that mean UNSET? should return true, had you asked unset? 'x ?

So some issues to sort through here regarding what to call it and how it acts.