Well, in the intervening years with new tech and revelations, I am reconciled to relinquish much of the space of WORD!-ish operators involving < and >.
One of the key driving realizations of "the power of TAG!" was motivated by something you did not like...which was my usage of <*> in tagged compose. It's not meant to be anything special, it could just as well have been <substitute-here>. But being able to have this inert type drawn out of thin air that has no evaluative meaning helped visually call out the places substitutions were happening.
That contrasts with my experience after clocking some time with Haskell. I've didn't end up as enamored with using operators like <*> or <$> vs words. I may still be envious of what the language does with these functions. But I think it's better when you can use these as structural markers for callouts that are specific to the code you are writing.
But a linchpin of being ready to lay down the limits was concluding that the only bindable "operators" with / in them are /, //, ///, etc. They present as PATH!s with BLANK!s in them, yet operate with the binding, storage characteristics, and behavior of a single aliased word. I believe this compromise is The Final Answer...and it will apply to ., .., ... etc. as well with a TUPLE! mechanic.
That same pattern can be used to solve the <> as TAG! and not-equal at the same time. Pretty awesome.
Furthermore...after working on making UTF-8 work well and compactly, it kind of seems a waste if nobody uses it. There's a bunch of arrows and symbols in there for anyone who has a special domain to attack, and feels stifled by the lack of operators. Install a keyboard mapping and use all the symbols you want.
The WORD!s with < and > Vision Statement
Here goes...
A WORD! which contains one or more > or < in it is referred to as an "arrow".
Arrows may start with
<or end with>, but cannot do both.
- Anything which does both is a TAG!, including
<>(which has special-case mechanics allowing it to be uniquely executable, while tags with content will never execute)All characters in an arrow (besides < and >) must come from a limited set of 4 other choices: =, -, +, and |.
These four are chosen for having a "liney" property making them suitable in drawing vertically symmetrical arrow-like things.
+as a cross is more complex than the "lines", but as a natural partner to-it seems weird to leave it out. You could more laboriously make a cross with<-|-that looks nicer as<+.Underscore is excluded, despite liney-ness and symmetry, because it's on the baseline and doesn't make anything good.
<__Only ASCII is considered, as higher codepoint unicode constructions basically can draw whatever they want already.
~is reserved as a possibility for future use
It has a wave in it and is thus is not vertically symmetrical and a little "unclean", plus a little hard to distinguish between
<-and<~It's not clear if ~ is necessarily even best used as a WORD! character at all.
Having a "story" is important for holding things in your mind. So the realization is that we're looking to draw nice symmetrical arrows, not make symbol soup, and using ASCII only. We can thus give HTML back its ugly <!-- and feel nothing of value was lost. We don't mourn the loss of <&* or other things of that nature, because that wasn't what we were going for here.
This gives everything I'd want, including basics non-negotiables like >>= and |>, as well as >< which I've become attached to. Like I say, I'm considering the loss of things like <$> or <*> a feature and not a bug. These are fun new labels you can use wherever tags are honored.
With <> the only executable tag-looking thing, this sacrifices something becoming popular in many languages which is <=>. They call it the "spaceship operator"...doing a comparison of two values and returning one of three states (equal, greater, lesser) in a single operation.
But no big loss. Call it >=< and problem solved.
switch a >=< b [
'= [print "A equal to B""]
'> [print "A greater than B"]
'< [print "A less tan B"]
]
The rules also allow a lot of things I'd probably not use. But some people like making fish ><>, and maybe long arrows have a point for someone =>=>>-. It's not contentious with tags, and it seems not worth the time or rule complexity to come up with ways of prohibiting it. We can't stop people from calling variables asldj323fjslsdf333ajsd-_-asdfafaa33afj either.
On the tag side, this permits a lot of ugliness. You can make ugly strings too. I guess I'm not really concerned about that...and just ask not to use <~ tildes ~> in case they wind up being desired in the arrows set. (My main reluctance to include it now is because I'm a bit reluctant about tildes in WORD! at all, and am wondering if they have some higher application...thinking on it.)
@rgchris can be the tag czar and cut down on problematic tags. Maybe experience would draw out what those are. Either way, things taken away from tag won't expand the set of things that are "legal arrow words".
What About HTML Comments?
The rules means <!-- isn't a WORD!, but --> is. Now when we look at:
<!--
a comment
that spans a bunch of lines
...
--> ; what are we looking at on the left, exactly?
I'd be comfortable letting this slide. Also, I'll mention that if you want to annotate --> as unambiguously a WORD! that you're executing or fetching, there's a new power in the toolbox:
-->/ ; terminal path means thing on the left is a function, run it
-->. ; terminal tuple means thing on the left is not a function, fetch it
I don't think anyone would care, but... it's there. The main point of "moving on" is just being willing to release <!-- from consideration. A lot of being more comfortable with that is being fully comfortable with <!> as not executable when <> is executable.
Anyway, this proposal should cover everything, and I'm feeling pretty satisfied with it.
What Tags Are Ruled Out?
<- This isn't a tag ->
<-But this is->
<& This is a tag &>
<|and so is this|>
<|this is also a tag |>
<|> ; this too
<& | > ; and this
<| But this isn't |>
<<this is a tag>>
<< but this isn't >>
<++ this isn't a tag >
<++but this is >
Space rules are really the big issue here, but it's not clear what help you're doing by prohibiting a space before the closing of a tag on the same line if you allow multi-line tags. But... like I say... not really something I feel compelled to worry about too much. Just good to have everything in word space basically pinned down.