#+TITLE: Why we still need dynamic variables
#+AUTHOR: screwlisp, originally Goodwin
#+BEGIN_QUOTE
The toplevel structure of all these actvities is not usefully
characterized as an algorithm
#+END_QUOTE
* Programming environments
are the most applicable unit of what people seem to be talking about
when the word program comes up, even if particular small units of
functionality get vomited into whatever production is. Even then, they
are still an appendage of a development environment. In particular
Goodwin highlights that programming environments are on the scale of
the places passenger aircraft are constructed, not one workbench but a
garage. Hence, and also anyway compilation is incremental and
modification of code and compilation happen incrementally and in the
runtime of other pieces of the programming environment. The idea of a
straight-line uni-directional
| specification | -> | write code | -> | compile | -> | run |
is both wrong and fundamentally undesirable in any meaningful
sense. Since the environment itself as well as any particular part are
evolving through time together, it's not possible to know how much
memory will be needed for all variables in advance and this is
obvious.

* What about dynamic variables though
Imagine this use of tables. I'm going to write common lisp, but feel
free to imagine both strongly typed languages and the use of json.
#+begin_src lisp
  (defvar *table*
    '((foo . (bar baz buz))
      (frob . #(#\u #\l #\o #\u #\s))))
#+end_src
I have associated with the key foo both the type
#+begin_src lisp
  (defun is-length-3 (l) (= 3 (length l)))
  (deftype foo-implicit-type () `(and cons (satisfies is-length-3)))
#+end_src
as well as the values, bar baz buz inhabiting this type. Similar for
the (simple-array character 5).

It's obviously possible to represent any kind of type as an entry in a
table like this or an array. Goodwin is interested in using the
language's own type system and not bootstrapping a new one for any
particular case.  Subjects of the language's intrinsic typing are its
nominal types. Types created by deftype (or defclass/defstruct) are
nominal types. Something created out of conses is not a nominal type
of the language though cons is a nominal type of lisp.

* Original thoughts

Thinking about verisimilitude's theory that programs can perfectly
embody their specification: Firstly, Goodwin doesn't consider this
sort of isolated program the correct unit of consideration. Secondly,
I think that specifications are kind of random. I doubt the same
person will repeat a nontrivial program specification on different
encounters, like a stochastic process. No particular random sample is
the true sample. Stochastic calculus simply isn't differentiable like
Newton's calculus is.  This is not decay of a true value. I think
specifications of a unit of functionality are just like this. Instead
it's the environment capable of fulfilling a space of specifications
within reasonable calibration intervals that is desirable though hard
to call perfect.

* An orgmode link, much to mdhughes' chagrin
[[gopher://verisimilitudes.net/02024-02-02]]

* Optimism
Goodwin encourages creation and use of types at runtime. In later
common lisp, deftype, defclass, defstruct and typecase for example.