Uses of FENCE! In Dialecting

Domains Dialects/DSLs
1

I'm now committed to make braces a new array type. Rebol has put itself in a bad position by using that particularly valuable piece of keyboard real-estate for something "superficial" like making strings a little cleaner, sometimes. :-/

[block] • (group) • {fence}

It's likely (though not 100% set in stone) that FENCE! will evaluate by running MAKE OBJECT!. But what might it do in other dialects?

  • "If there's an integer inside of a pair of fences, such as {{10}}, then that represents a citation. Citations can appear at either the beginning or end of a reference block."

  • "In the PARSE dialect, blocks are used to represent subrules. Groups switch over to running ordinary code as with DO. While fences are used to... (insert your active imagination here)"

If FENCE! Were Inert, That Would Change Dialecting Possibilities

Fences don't necessarily have to produce an object under evaluation. If it wasn't, you could do things like pass it to an arity-1 MAKE:

>> obj: make {x: 10 y: 20}
== ...object x: 10 y: 20...  ; whatever literals look like

Switching to an arity-1 MAKE could be dialected, if you needed to slip things like a parent object in:

>> obj2: make {<parent> obj, x: 30}  ; potential dialect for mentioning parent
== ...object x: 30 y: 20....

>> obj3: make {{obj} x: 30}  ; weirder but more succinct dialect parent concept
== ...object x: 30 y: 20...

Less disruptive, we could just say it reduces:

>> reduce {x: 10 y: 20}
== make object! [x: 10 y: 20]  ; or whatever

Then GET-FENCE! could do the same:

>> :{x: 10 y: 20}
== make object! [x: 10 y: 20]  ; or whatever
1 Like
4

I've taken my time to mull over this question, and not assume too much. I wanted to look at all the angles.

Having looked at those angles, I've reached a conclusion (which I suspected all along...)

IT WOULD BE A PHENOMENALLY INSANE WASTE OF AN OPPORTUNITY TO MAKE FENCE! (UNCONDITIONALLY) INERT IN THE EVALUATOR.

:wastebasket:

If you want an inert FENCE!, you can make one.

>> '{a b c}
== {a b c}  ; unbound

>> ${a b c}
== {a b c}  ; bound

>> @{a b c}
== @{a b c}  ; bound

>> ^{a b c}
== ... ; I have no clue, yet

It's a golden opportunity to give people a surprising artifact, that does something "familiar" but is much more than meets the eye...

>> z: <outside>

>> obj: {x: 10, print "Hello" print "World", y: null, z: z}
Hello
World
== #[...object...]

>> obj.x
== 10

>> obj.y
== 20

>> obj.z
== <outside>

>> for-each [key val] obj [probe key probe val]
x
10
y 
~null~  ; anti
z
<outside>

You've transitioned from a FENCE! ... which is a list structure that can only hold reified elements... to a key/value structure whose slots can hold stable antiforms.

Besides just plain assignments, you're allowed to run code. But the default construction should not assume WORD! references resolve inside the object as its being generated. There should be a way to get at those internal references if you need them, but I'm kind of opposed to defining any sort of THIS or SELF word in an evaluator primitive.

1 Like
5

4 posts were split to a new topic: Evaluator Hooking ("RebindableSyntax")