Letting Go of Enfix Path Dreams (but fixing it with "Magic")

[hostilefork]

Letting Go of Enfix Path Dreams

I had an idle curiosity of whether the New Semantics of PATH! and TUPLE! changes anything here.

@hostilefork

e: trap [do make block! ":a"] e/id = 'not-bound

Now imagine that you are the evaluator. You've got a SET-WORD! for E: pending on the stack, but haven't assigned it yet. You've also got a WORD! for invoking the trap action on the pending on the stack, but you haven't invoked that yet either. Instead you're gathering TRAP's argument to run.

You've just seen the BLOCK!. Now you notice a PATH! of e/id pending. What you want to know is if that's some kind of enfix operation that has an interest in influencing the operation. It might want to quote the block, or it might want to force some kind of completion of the left hand side.

But E could be anything, here. e could be a DATE!, a STRUCT!, an IMAGE! or other user defined type. Yet somehow we expect the path dispatch process to give back a meaningful answer about its interest in code to its left.

If written this way (which it wouldn't be, it would be e.id, but let's ignore that) e can no longer be just anything. It is an object. And ID is an action. Them's the rules.

So that's one small leg up. But the rest of it... still the same old story.

Why Not Some Kind of Decoration to Force Enfix?

The SHOVE operator has proven very difficult to write and debug.

What if there were some syntax that paths could have saying "I know this is infix, treat it as such?" The person writing the code had to know it was infix, and the SHOVE operator makes them say it, but maybe there's some pattern...

>> 10 ::/lib.+ 20
== 30

:: is a WORD! but because it is something you can't put in a chain that means you can't assign it normally. So I've proposed it being evaluator neutral. Could be used here. (Plain : makes things inert, but probably not paths.)

Would be a simple solution to the currently over-engineered mess! But maybe :: is too valuable for this weird purpose. And if you're allowed to say:

set $:: make object! [lib: does [print "boo"]]

Then you'd be losing the lookup ability. Is there anything you can't look up that could go there?