No, I didn't. Ever. I advocated for something called "arrow-words", which do not and can not and never should have letters.
Please reread lexer.reb (GitHub), noting in particular:
Maybe I'm misremembering... or you just drew my attention to some language that existed that allowed it, without actually advocating it.
(Note: GitHub allows you to freeze the version you are at in the URL to the currently viewed commit by pressing Y, and you can get lines or ranges in the link by clicking and ctrl-clicking the line numbers. I updated this to make the links easier)
Yep, reviewed. Your "arrows" definition predates what I've said and matches it. So that aspect is now officially your solution...that I perhaps got by osmosis. But to the extent I wound up at the same conclusion in my own head-space independently, that is doubly good because it makes it more likely to have some emergent rightness.
There are going to be a lot of interesting usages of arrow words. I'd been using => for lambda, but that gets us into debates about whether <= should be for some leftward pointing arrow or greater-or-equal. If we make lambda instead -> then => can just be a synonym for >= in the default configuration, and you can do with it what you like in your own dialects and time.
So having -> be lambda is lighter-weight and is in keeping with better company as matching Haskell and co, instead with JavaScript. Overrideable by anyone who disagrees.
That pushes the shove operators for making a PATH! (or any function) act as infix off to being something else. 10 >> lib/+ 20 and 10 << lib/+ 20 are one pairing of options, but I feel like >> should have a bigger and "heavier" purpose. >- and -< are still light-looking, so maybe 10 >- lib/+ 20 ? Or perhaps 10 >| lib/+ 20 so the whole family of operations is >|, |<, |>, and |<. I'll have to work through what exactly all these mean again (they're in the tests, thankfully, so I can look at all the edge cases that motivate why there are 4 and what they do).
Feeling more confident and stable about all of this, so that's good.
Good, indeed. And thanks for the edits/pointers.
There is only one thing left that needs a mention, and that's </>. Hopefully it will not screw up your pathing stuff. I had to put a special exception in lexer.reb to prioritise making it a tag. It should never be a word, of course.
If it's not a PATH!, otherwise you couldn't do this:
<: function [/>] [
; ... whatever you wanted this to do ...
]
The legality of < and > as WORD!s would suggest the legality of </ and /> as PATH!s, and so is </>.
That's not going to make everybody happy. I wanted it to be a path too. I think the most vocal advocate was @gchiu, but he certainly wasn't alone even if I'm wrong.
And remember, </abc> and its friends should be tags, they are the closing tags of HTML. They cannot be paths, so there has to be a way of making that / not indicate a path, so maybe that way could be used for </> as well?
In Red:
set '< function [/>] [
either > [print "refined"] [print "unrefined"]
]
red>> do reduce [to path! [< >]]
refined
So mechanically it works, but is an inconsistent mess getting there because the scanner is underthought. <: isn't a legal word for them, and </> scans as a TAG!...even though that tag aliases what they run as a legitimate PATH!. (But maybe their new lexer branch changes this, I dunno. Feel free to look into that.)
R3-Alpha is worse:
set '< function reduce [to refinement! '<] [
either > [print "refined"] [print "unrefined"]
]
r3-alpha>> do reduce [to path! [< >]]
** Script error: < has no refinement called >
I've gone ahead and put something in for arrow words. I was aiming for getting the right behavior without a tremendous concern for performance (the whole thing should be specified more declaratively, as we all know.)
But for whatever it's worth, here's the change. Note that writing the arrow word handling all in one big first step allowed a bunch of little weird patches down beneath to be deleted.
I'm not sure how many new arrows are going to be getting used. But an immediate application is just being able to get rid of all the janky workarounds that have existed in some form or another since R3-Alpha, to do the current set of useful arrows. This corrects their behavior with quoting, SET-WORD!, GET-WORD!, etc.