I have some code that defines the request variable req dynamically, so that instead of
(defop foo req
(pr (arg req "bar")))
I can say
(idefop foo
(pr (arg "bar")))
I found myself thinking in my own mind "OK, so here in this code I'm using req implicitly..."
Good names for concepts are always valuable, so paying attention to what my mind was calling this, I thought "Hmm, how about the name 'implicit variables'?"
GHC (the de facto standard Haskell compiler) uses "implicit parameters" as the name of an extension that is almost, but not quite, equivalent to dynamic binding. Namely, in Common Lisp, you have the following:
Prelude> :set -XImplicitParams
Prelude> let f = (let ?x = 0 in \() -> ?x) in let ?x = 1 in f ()
0
I think that, as "dynamic variables/binding" is the name that has always been used before, and "implicit variables/parameters" is a name used to refer to something subtly different, it might be better to use the former; but it doesn't really matter that much, and "implicit" does do a better job of getting across the purpose of dynamic binding than just calling it "dynamic".
That's interesting that Haskell also uses the term "implicit". The differences seem mostly related to the type system. For example, since the variables are statically typed, it's easy for them to overload "let" to do dynamic binding with implicit parameters. Is there some other subtle difference that I'm missing?
The "it's always been called X before" argument would prevent us from ever improving the language by coming up with better names; we'd still be calling anonymous functions "lambda" instead of "fn" etc.
Er, see the post you replied to: that code I gave is precisely the same modulo syntax, but in Common Lisp it evaluates to 1 and in Haskell to 0. Essentially, Haskell's implicit variables don't allow rebinding/shadowing. It's a bid hard to explain, but look at the example and play around a bit and you'll see what I mean.
