A New, More Limited "Word" Type: SYMBOL! ?

Recently I decided it was more important to let TAG! have dots and slashes in it, than it was to let "arrow words" be in paths or tuples.

This felt a bit uncomfortable because it's creating a second-class citizen of WORD!... things like < and > and >>= and all their bretheren don't have the same abilities.

Maybe it just feels uncomfortable because it isn't being done more decisively...

What If They Weren't WORD!s?

If these were in a different category, like SYMBOL!, we could just say that they don't come in GET-WORD! or SET-WORD! or META-WORD! or THE-WORD! variations. They don't go in TUPLE! and they don't go in PATH!.

They could still dispatch like WORD!s in the evaluator. And they'd come in QUOTED! forms, so you could SET and GET them. But also... look, multi-return can help, with single return!

[::]: enfix :join

Put it in a SET-BLOCK! and there you go. GET doesn't really have a parallel, but it's done more rarely and so things like get ':: seems it's good enough.

Opening Things Up

With this new category, it seems like the doors are open to picking things that just don't play well with colons, slashes, or dots. It wouldn't matter because they wouldn't have to.

I've been wanting : and :: for a while now. If they didn't have the burden of being WORD!s, then no one would ask questions like "what does the SET-WORD! form of those things look like?"

It would mean that @ and ^ could free up from being their own types, and just be symbols.

We wouldn't need to worry about the ambiguity of %, and it could be used to make paths...if that seemed like a good idea:

>> % /some/(reverse "htap")
== %/some/path

I don't know if bringing / and // and . and ... in as symbols vs paths/tuples is ideal. Maybe there's some duality between them, where they're both somehow? I'd have to think about it.

What Should Be A Symbol? = + - ?

The "arrow words" came out of a mixture of < and > with characters that could be put into WORD!s, like - and + and | and =.

So if we're contemplating ::, does that open up things like :-: It certainly seems like maybe := would be more useful as a symbol than as the GET variation of equals.

But here are some thoughts:

  • When it comes to mixing with words... I'll say that I've actually found that + in words can be useful, like file+extension to name a variable that is composed of more than one part.

    • I've never felt tempted to do anything similar with =
  • I have valued being able to put + and - in PATH!. I used it for +/- to denote "signed" in ENBIN and DEBIN.

    • Some similar situation might apply with =/=
  • Anything demoted to symbol status couldn't be used as a refinement either. So there'd not eb any foo/= refinements

Conservatively I'd imagine we wouldn't be seeing any mixing of + or - with : to make a symbol. But I might leave := on the table, partially because I feel = is less of a natural fit for being in words in the first place.

Then there's more to think about with whether <:> is valuable enough as an operator to outweigh being able to make a TAG! like <:foo> (if those things are truly in contention)

But SYMBOL! Functions Can't Have Refinements...

Can't be in paths means they can't have things after them to be refinements.

Oh well. Tough luck.

As it happens they kind of couldn't have refinements anyway, because most symbols were winding up as infix functions.

No Matter What, There's Only So Many Keys

It may sound like a big deal, but there's only so many symbols on the keyboard. This will bring in a few symbols, but if anyone wants a lot more they'll have to go to unicode.


Lot to wrap my head around here. I don't have much of a reaction yet... I need to spend more time absorbing this proposal.