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!:


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.