![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
are semiglobals like these?: http://docs.racket-lang.org/srfi-std/srfi-39.html
---
in order to make semiglobals a little more controlled than just dynamic scope, mb require functions that read from them to specify as much in their function signature, and in order to write from them, you don't just assign to that variable, you write to a semiglobal object (should we use the word 'parameter object' so schemeheads will recognize it? probably not, it's too confusable).
so e.g.
def f1(x): semiglobal q;
g(4) == 20 q.z = 3 g(4) == 12
def g(y, semiglobal q = 5):
return y * z
note that we have lost referential transparency in g, unless we consider the invocations g(4) and g(4) to be shorthand for g(4) and g(4, q.z).
this suggests that in fact, we should require to explicitly pass the semiglobal the first time.
they are still useful, for the purpose of refactoring something that was in one function, which first set a local variable and then later used it, into something where the setting of the local var and the usage are separated by a tower of descending function calls. e.g. the new requirement is:
def f1(x):
g(4) == 20 z = 3 g(4, semiglobal z) == 12
def g(y, semiglobal z = 5):
return y * z
and the reason it's useful is when you start with:
def f(x): z = 5
y = 4 ... do some other stuff ... y * z == 20 z = 3 ... do some other stuff ... y * z == 12
and then refactor into:
def f1(x):
f2(4) == 20 z = 3 f2(4, semiglobal z) == 12
def f2(y): ... do some other stuff ... return f3(y)
def f3(y): ... do some other stuff ... return f4(y)
def f4(y): ... do some other stuff ... return g(y)
def g(y, semiglobal z = 5):
return y * z
because this allows you to add new parameters for g which are set at f and then 'passed thru' f1, f2, f3, f4 without having to make f1, f2, f3, f4 aware of them.
Note that we are requiring semiglobals to have default arguments and to be keyword arguments.
---
PJ Eby's Contextual seems similar, and also has some stuff regarding factories and dependency injection. Should take a closer look at it.
https://pypi.python.org/pypi/Contextual/0.7a1.dev
---
https://www.gnu.org/software/emacs/emacs-paper.html#SEC17 presents an argument for the need for (possibly optional) dynamic scope (so u can rebind configuration such as keymaps) (which sounds similar to my arguments for 'semiglobals' and similar to their functionality (so u can rebind stdout or float-to-string formatting defaults); maybe i should just call semiglobals 'optional dynamic scope')
---
stallman's reason/example for why dynamic binding in elisp,
" Dynamic scope is useful. Consider the function Edit Picture, which is used to change certain editing commands slightly, temporarily, so that they are more convenient for editing text which is arranged into two-dimensional pictures. For example, printing characters are changed to replace existing text instead of shoving it over to the right. Edit Picture works by binding the values of parameter variables dynamically, and then calling the editor as a subroutine. The editor `exit' command causes a return to the Edit Picture subroutine, which returns immediately to the outer invocation of the editor. In the process, the dynamic variable bindings are unmade.
Dynamic binding is especially useful for elements of the command dispatch table. For example, the RMAIL command for composing a reply to a message temporarily defines the character Control--Meta--Y to insert the text of the original message into the reply. The function which implements this command is always defined, but Control--Meta--Y does not call that function except while a reply is being edited. The reply command does this by dynamically binding the dispatch table entry for Control--Meta--Y and then calling the editor as a subroutine. When the recursive invocation of the editor returns, the text as edited by the user is sent as a reply.
It is not necessary for dynamic scope to be the only scope rule provided, just useful for it to be available. " -- https://www.gnu.org/software/emacs/emacs-paper.html#SEC17
" Advantages of dynamic binding
Dynamic bindings are great for modifying the behaviour of subsystems. Suppose you are using a function ‘foo’ that generates output using ‘print’. But sometimes you would like to capture the output in a buffer of your choosing. With dynamic binding, it’s easy:
(let ((b (get-buffer-create " *string-output*")))
(let ((standard-output b))
(print "foo"))
(set-buffer b)
;; do stuff with the output of foo
(insert "bar")
(buffer-string))(And if you used this kind of thing a lot, you’d encapsulate it in a macro – but luckily it’s already been done as ‘with-output-to-temp-buffer’.)
This works because ‘foo’ uses the dynamic binding of the name ‘standard-output’, so you can substitute your own binding for that name to modify the behaviour of ‘foo’ – and of all the functions that ‘foo’ calls.
In a language without dynamic binding, you’d probably add an optional argument to ‘foo’ to specify a buffer and then ‘foo’ would pass that to any calls to ‘print’. But if ‘foo’ calls other functions which themselves call ‘print’ you’ll have to alter those functions as well. And if ‘print’ had another option, say ‘print-level’, you’d have to add that as an optional argument as well… Alternatively, you could remember the old value of ‘standard-output’, substitute your new value, call ‘foo’ and then restore the old value. And remember to handle non-local exits using ‘throw’. When you’re through with this, you’ll see that you’ve implemented dynamic binding!
RichardStallman? explains the advantages of dynamic binding in the context of EmacsLisp?: http://www.gnu.org/software/emacs/emacs-paper.html#SEC17. See also the article Dynamic vs. Static Typing — A Pattern-Based Analysis by Pascal Costanza, http://www.p-cos.net/documents/dynatype.pdf.
" -- http://emacswiki.org/emacs/DynamicBindingVsLexicalBinding
---
i dont really see why we'd need module-level globals (in addition to just semiglobals, ie (i think) dynamic scoping), but come to think of it, i guess linked functions from other modules are module-level globals (although possibly immutable ones, mb that's not so bad)
---
so do our dynamically scoped variables (semiglobals) use shallow binding or deep binding? i'm guessing shallow binding?
---
i dont see why our lexically scoped vars wouldn't be block-scoped, like js ES6's let (see http://rauchg.com/2015/ecmascript-6/#let-and-const-over-var ), rather than function scoped or something else less granular
i guess ppl might be confused for a minute why:
for i in 1..10 { print i } print i
would give an error; but it's worth it. If they want i to be saved, they just have to do:
i = 0 for i in 1..10 { print i } print i
unlike js, we don't need variable decls by default
(and instead of distinguishing dyn and lex-scoped vars by declaration (decl), we might want to have a special sigil for dynamically scoped ones)
---
unify scoped lookup in:
