Lexical Conflicts Back To Bite Us: Dots In Tags

So I've been torn by the question of dots in tags, ever since the loss of <...> to mean variadics.

But that was how the scanner rules clanked together. And since < is a WORD!, if we assign that to an OBJECT! how do we get fields out of it?

>> <: make object! [x: 10]

>> <.x
== 10

But Something Has To Give

I've been convinced. Dots in tags have to win.

It's too useful to be able to say <../foo.r> as a file path. :frowning:

The state of the system is different now: PATH!s and TUPLE!s are immutable, so they can be checked for disallowed patterns. We can set a bit on the special-cased words that contain < or > and then quickly check at path creation time that they contain none of these "arrow words".

This means any < or > that you see in a path or tuple are guaranteed to be part of a TAG!.

You can still make some confusing-looking things:

..<..>..

But with the rule of "no < or > words inside a path or tuple", you can confidently read that as a 5-element TUPLE with a TAG! in the middle of it.

>> as block! ..<..>..
[_ _ <..> _ _]

How Will You Pick Fields Out of Objects In Arrow Words?

For purely evaluative purposes, you could just use a GROUP!:

('<).field

We could try and make some kind of escaping syntax so the literal value could actually be represented in the path. This would help generic code that took an ANY-WORD! and wanted to make a PATH! out of it:

#[word! "<"].field

But if we prohibited it, I'm not sure how bad that would be. It could be a "yagni" situation. :-/

For now, I'm just going to hack on the scanner and path mechanics a bit and get us the tags. This will please those who would like the idea of </> and <//> and <.> and <..> being a TAG!

I don't know whether this concession is going to wind up turning into backing off <: and >: or not. :frowning:

('<): does [print "Is this good enough, now?"]

It would open up <:> and <::> and <:/some/thing> and a lot more tags of that nature, for what may seem like a pretty negligible loss.

Has The History of This Topic Been Churn With No Benefit?

:no_entry: NO.

Because when you look systemically at all the parts, generic TUPLE! and generic PATH! are showing great promise. I think this world in which things like /foo are PATH! and a.(b).10 is a TUPLE! are really the right way to go.

For that matter, I don't actually think it's so crazy to put on the lenses where <../foo.r> is a PATH! containing two tuples.

Consider another very similar looking example of +../foo.r+. That's:

 as path! reduce [
     as tuple! [+ _ _]
     as tuple! [foo r+]
 ]

I actually think that line of thinking has a lot of interesting dialecting possibilities. The thing that makes the example with < and > in it trip up is that it treads on the usefulness of tags...and you wind up where r> isn't even a valid tuple component. More is being sacrificed and less is being gained.

All in all, it's progress.