Howso?
It’d feel like a binding but be a container under the hood—like how boxed captures feel like a binding but are actually containers under the hood.
Don’t be silly, I’m not about try compiler edits for an idea I spent five minutes spitballing before I have an idea of its feasibility…
In that case, with and @with should be left in the ScopedValues namespace. I had assumed there was a good reason they were being brought into the global namespace, but maybe not.
From where it’s placed in the manual, ScopedValues are going into the Base namespace, so that’s where with and @with are going also.
Whether it will be ok to add with was discussed as well. It did strike me as pretty basic word to reserve for the default namespace, this frequency list has “with” as the 33rd most common word in English. Source code isn’t English though, and a survey of package code showed that it wasn’t likely to be disruptive. I’m pretty sure I’ve never named a function or variable with, despite that initial reaction.
There is an open PR to un-export with and @with:
I just read through the entire Scoped Values PR, and I dispute this claim:
There is some discussion of the name, but it is nowhere close to “an extensive analysis and bikeshedding”. Most of the commentary on the name comes from the author of the PR. There is very little discussion of other alternatives. There was reportedly a discussion on Slack,
but those discussions are inaccessible to those of us who don’t use Slack (and they’ve probably been lost to the slack-hole by now anyways).
It is odd that there is no discussion in the PR about using the word Context instead of Scope (except for a one sentence note about a triage call: “Triage: We remained split on Contextual vs ScopedValue.”). This is particularly odd considering that the precursor PR to the Scoped Values PR, PR #35833 mentions the use of the term “context” in four other language:
contextvarsExecutionContextCoroutineContextcontextJulia uses lexical scope, so I think we are begging for confusion by referring to this feature as dynamical scope. True dynamical scope would look like this:
a = 1
f() = a
function g()
a = 2
f()
end
g() # returns 2
But that’s not what the Scoped Values PR provides, so I don’t think the feature should be referred to as dynamic scope. I think it’s better to describe this feature with the word “context”. So, this feature in action could look something like this:
a = ContextValue(1)
f() = a[]
newcontext(a => 2) do
f() + 1
end
Of course the precise names of ContextValue and newcontext are debatable, but I think they should involve the word “context” rather than the word “scope”.
I opened a Github issue. It’s about more than just the name. I think it is misleading and confusing to describe the ScopedValue feature as a “dynamic scope” feature. I think it is more accurate and understandable to describe the feature as a “context” feature. This feature is described as a “context” feature in at least four other major programming languages.
Just because I started this thread, I’ll chime in and say that I find ContextValue clear and unobjectionable. ContextRef is maybe worth considering, to signal that access is refstyle[], but if I ran into ContextValue in the documentation right now I would consider it unremarkable.
Your first example looks like setting a global variable to me. Guess, one should be more precise in distinguishing between binding and assigning, i.e., in Common Lisp, let establishes a new binding – for lexical as well as dynamic variables – whereas setf is used for assignment. In that interpretation a = 2 simple sets the value (assuming it is already bound) whereas newcontext establishes a new binding. Unfortunately, the scoping rules of Julia with = sometimes establishing a new binding while assigning to an existing one in other cases can confuse here – especially in the context of contextual values.
I agree that scope is not the right term here and already in Common Lisp dynamic scope was considered a misnomer meaning indefinite scope and dynamic extent instead.