Evaluator Hooking ("RebindableSyntax")

[hostilefork]

@bradrn

This reminds me strongly of RebindableSyntax in Haskell.

That does indeed look to be very much in the same spirit:

• "So the RebindableSyntax extension causes the following pieces of built-in syntax to refer to whatever is in scope, not the Prelude versions"

• "An integer literal 368 means fromInteger (368::Integer), rather than Prelude.fromInteger (368::Integer)".

(Perhaps similar enough that calling it "Rebindable Syntax" might be a good idea. I hate making up new names for things that already have serviceable names.)

@hostilefork

And if there's only hookpoints for BLOCK!, FENCE! and GROUP!... but not their variations.. you'll always have quoted '[blocks] and $(groups) etc to fall back on if necessary.

So I called the FENCE! hook "fence!-EVAL" based on the idea that you wouldn't want to redefine the natives that perform the actions. But given that you can call LIB/XXX versions, maybe you do want to redefine the natives?

e.g. perhaps it should have been CONSTRUCT instead. "Want to redefine FENCE!'s behavior? Redefine CONSTRUCT."

If that pattern extended, quoted things would run UNQUOTE, I guess?

>> unquote: func [x] [reduce [lib/unquote x]]

>> 'x
== [x]

>> '''{a}
== [''{a}]

GROUP!s could run EVALUATE. EVAL might be rethought as an alias for EVALUATE, e.g. look up whatever EVALUATE is defined as in the current context and run that, vs. a hard reference to LIB.EVALUATE. Although you'd want LIB/EVAL to run LIB/EVALUATE, I guess the aliasing would need to take where it was being run from into account.

BLOCK!s could run... uh... I dunno. What does the [] say?

Er, Nevermind... xxx!-EVAL is Better

Not knowing what the BLOCK!'s corresponding native is kind of drives that home.

And think I like that fence!-EVAL stands out enough to make people go "something weird is going on here", and you don't have to corrupt the meanings of natives to get it. You can call CONSTRUCT from inside your fence!-EVAL instead of having to call LIB/CONSTRUCT.

But I got on this track when crossed my mind that the hooking could call regular looking functions... this was particularly because I'm thinking about being able to redefine SET and GET.

>> set-EVAL: func [var ^value] [print ["var is" mold var "value is" value]]

>> x: 1000 + 20
var is x value is '1020

But it's probably for the best you have to say something like set-EVAL instead of requiring you to override set. Again: probably the first thing you're going to be reaching for in implementing your SET customization is... SET.

@bradrn

[RebindableSyntax in Haskell is] not used very much, because Haskellers prefer other means for extending the language, plus variable shadowing is frowned upon. In Ren-C, of course, those aren’t problems — and, besides, this feels like the natural conclusion of dialecting as a paradigm.

It does seem that if you buy into Rebol's odd bargain enough to use the language in the first place, then this shouldn't raise eyebrows. You'd be doing these alterations of behavior anyway in a dialect. So why not make it easier to bind a block to some altered evaluators and just run it, vs. accomplishing the same goal with FOR-EACH or PARSE and having to worry about all the binding manually?

Not fit for all purposes. But when every invocation of something like IF is making a function call... well, you might as well be getting something for your money.