Binding Without $ Signs... What's The Operator?

Development Naming
1

The modern world of binding means this is the true and correct behavior:

>> x: 10 y: 20

>> eval collect [keep 'x keep '+ keep 'y]
** PANIC: no binding for x

If you want that to run, you can either bind the container so that it has a context to trickle down to the unbound elements:

>> eval $ collect [keep 'x keep '+ keep 'y]
== 30

Or you can leave the container unbound and put bindings on the individual elements.

>> eval collect [keep $ 'x, keep $ '+, keep $ 'y]
== 30

If you're dealing with a bindable non-quoted thing, then you can use a $ that is "tied" directly onto the element... a "binding quote":

>> eval collect [keep $x, keep $+, keep $y]
== 30

BUT Should We Have An English WORD! For "Bind Here"?

I have previously remarked that if $ didn't exist, this operation is so critical that it would deserve the name BIND as an arity-1 intrinsic:

>> eval bind collect [keep 'x keep '+ keep 'y]
== 30

>> eval collect [keep bind 'x, keep bind '+, keep bind 'y]
== 30

But that feels like it squanders the word, when a BIND dialect can do so much more.

Or Is It Not Squandering, but Tactical Marketing?

Perhaps having an arity-1 BIND meaning "bind here" as a complement to an arity-1 UNBIND can help make this more palatable in the English-like world?

:man_shrugging:

Other Words For Arity-2 BINDing?

arity-2 BIND could be WITH as in @hiiamboris's proposal, and BIND could be arity-1 for this "clean" look, but I dunno.

Alternate Modality Of Arity-2 BIND?

I've suggested maybe a parameter to the arity-2 bind for the functionality:

>> make-bound: func [x] [return bind <here> '(x)]

But it would be a bit cluttered and couldn't be an intrinsic... so the benefits kind of drop off. I don't think it would make anyone who didn't like $ happy enough.

The Great THE Operator!
Should sequences permit non-head SIGILs?
Displaying Prime Factors
Rebol's Target Market: Newbies, Experts, or Other?
3

I have deemed it to be the case, that arity-1 BIND...as a complement to arity-1 UNBIND...is the right choice.

This means we're now in the tricky situation of what to call the other binding operations.

WITH isn't terrible.

USING is kind of okay.

obj: make object! [field: 10]

eval using obj [field + 20]

Like WITH, I think there's sort of an "arity-2-ness" to using. It's an incomplete thought without another word. You wouldn't end a sentence with "Using X".

(You'd write "Using your right hand, turn the crank." Not "Using your right hand. (period).")

Because I don't know yet, I'm calling arity-1 bind BIND1 for now, and I'm not going to do the rename until I have good names picked.

4

I haven't pulled the trigger on this, and so it seems like I'm a bit unconvinced that arity-1 BIND is worth sacrificing its arity-2 usage.

The somewhat obvious idea of a hyphenated arity-1 operation, bind-here, hasn't been mentioned.

It might be that HERE could be able to give you a "context" of some kind, so BIND-HERE could be a synonym for bind here, just optimized as an intrinsic.

Given that I've had cold feet on the renaming, and $ is available as a shorthand once you know what you're doing, I think I favor this.

This does raise a question about the <here> tag that has been used in UPARSE to indicate the current parse position. Because UPARSE has to talk about both parse positions and bindings, it could be confusing if "here" is becomes associated with the binding concept.

I'm thinking that "AT" is an iterator dereferencer as arity-1, so it kind of is starting to make more sense that AT would give you the single item where you are. (Okay, that is now seeming extremely obvious.)

The tag could be <position> with <pos> as a shorthand. Might look a litlte weird when you put it in a variable named "pos"

all [
    let pos

    "b" = parse "aaabbb" [some "a", pos: <position>, some "b"]
    pos = "bbb"

    "b" = parse "aaabbb" [some "a", pos: <pos>, some "b"]
    pos = "bbb"
]

I don't hate that as much as I thought I would.