The Great Divide: Troubles Assigning Slash

Domains Math
1

So I apologize to @giuliolunati for making him have to put up with the / is a 2-element path containing BLANK!s debacle back in 2018. :see_no_evil:

On the positive side of me being mired in the implementation, I can see when something creates dissonance and edge cases...and know that things need to be avoided before someone in userspace would even know they needed to worry. The compiler gives me type checking errors when things don't line up, and I try my best to leverage whatever tools to catch inconsistencies I can (as far as C building as C++ can do, anyway).

But on the negative side it means I might pick the wrong form of regularity to solve the problem. This was such a case. We simply needed rules at PATH! creation time that prohibit you from putting special-slash-words into a path... and that's that.

So Now / And . Are Words Again

It's still going to be slippery. There will be problems:

math-context: make object! [
    /+: enfix add.
    /-: enfix subtract.
    /.: enfix multiply.
    /: enfix divide.   ; ooops
 ]

You won't be able to say (/: enfix divide.) to assign your division operator to a slash word!, because that will execute the function in the colon word!. So if whatever the colon word does takes an action as an argument, you're going to take enfixed divide as a parameter to that function... not perform an assignment. The PATH! is above the WORD!.

But things like (.:) and (...:) should work as expected. The WORD! is below the CHAIN!.

Is /: Too Misleading to Execute?

It stands out a little as a mistake in the MATH-CONTEXT above next to the other assignments, when narrowly packed like that. Of course, it wouldn't be narrowly packed. And you could just be trying to assign an inert value and not a function:

What you wanted:

>> /: 10
== 10

>> /
== 10

What you'll likely get:

>> /: 10
** Error: Colon doesn't accept INTEGER! as its whatever argument

The evaluator could just refuse, and make you say run get $: or set get $/

I'm tempted to say that's the right answer, because it seems like this will just lead to too much confusion otherwise.

That Won't Help You In "SET-WORD!" Gathering

If you can't get a "SET-WORD!" form of the slash word, the object won't collect the member.

We could sacrifice something like SET-FENCE! for this purpose, and say that MAKE OBJECT! will treat the fence as its WORD! contents for gathering purposes:

math-context: make object! [
    /+: enfix add.
    /-: enfix subtract.
    /.: enfix multiply.
    /{/}: enfix divide.
 ]

That's a pretty substantial sacrifice, to give up the meanings of all SET-FENCE! just for this one thing.

I don't have the answers. If I had the answers I wouldn't have been trying to dodge it. But I think the die is cast, and this needs some kind of creative solution.

2

Quite a few languages have some kind of syntax for identifiers which would ordinarily be invalid. (IIRC, C# uses {}.) So I see nothing wrong with taking SET-FENCE! for this usecase.

EDIT: no, C# actually uses @.

Otherwise… well, why not reserve /: as a special case for setting slashes? It would be invalid otherwise, after all, and / is a useful word to have.

1 Like
3

Though inconsistent, nothing here is going to be perfect.

: is a WORD! hence will run antiform frames without complaint. If you plan to use it as an operator, /: is probably not what you wanted to look at.

It may be the best compromise... scan that as a WORD! under a CHAIN! even though it is irregular. Same for :/

Two exceptions. (Well, two exception families... //:, :///, etc.)

But then, e.g. :/: won't be irregular, that's a PATH!

Next problem is : and :: and ::: etc. but there's a lot less baggage there, as no one expects you to be able to assign those historically. And I don't think anyone is going to have any preconceptions about being able to turn those into "setlike" or "getlike" forms--the contradiction is obvious. Maybe you just can't assign them and they are inert dialecting parts only.

4

Hrmm. The irregularity would actually have to permit:

/: 10

//: enfix divide.

Now you have a conflict. Is the second an antiform tolerant assignment to /, or a plain assignment to //?

:face_with_head_bandage:

I'd imagine you could argue that because slash is itself... a slash... you presume antiform tolerance in all cases. It's never checked. Hence what's on the left of or right of the colon can be seen "as-is" as a slashy WORD!.

On the surface, that seems to tie it up. Just need to make sure the system knows to stop you from:

>> to path! [_ //:]
== ///:  ; no matter what this is, it would be the wrong answer

It needs to look a bit deeper than usual to catch that, because it's not expecting to find slashed words (or slashes of any sort) under CHAIN!s. Guess the chain just needs a flag on it to say "I am a slashy chain" and path creation can test for that.