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

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

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

I like this idea! 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>


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.

1 Like