Dynamic binding

[Gyro@Reasoning.COM]

    Date: Mon, 11 Dec 89 18:15 EST
    From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>

    "Dynamic Binding" is not a problematic linguistic artifact which we
    can dispense with by voting it out.  Rather, it is a problematic 
    real-world artifact which cannot be eliminated by vote.

    The problems which lead to the use of dynamic binding are real.  They
    aren't just caused by someone misunderstanding the potential ill effects
    of dynamic binding.  If the issue were only "modules" or "lexical
    scoping", then people would just use those because they're already
    (effectively) in Scheme.  The problem isn't that we have a primitive
    sitting around which no one uses, but rather that there's a certain
    feature which whether we provide it or not, keeps coming up in
    discussion. There must be something more than mass ignorance which
    makes this happen.

I'm afraid I don't accept this argument.  As language designers, we all
know of features that users generally think they want, but which we know
they shouldn't have, because a) if they use them, they wind up writing
programs that are inefficient/ hard to compile/ poorly structured/
whatever, AND b) there are better ways to do the job.  (FEXPRs come
readily to mind as an example.)  (Clearly we require both (a) and (b) to
be true before we decline to provide some feature; when a feature is
dangerous but necessary, as of course often happens, we provide it and
try to teach people how to handle it.)

I believe that the apparent desirability of dynamic binding is a
concomitant of a particular way of organizing programs in the large, the
only way that mainstream Lisps (sans object-oriented extensions) have
historically provided, viz., as a homogeneous collection of definitions
in a single top-level environment.  I believe that if that is how one
thinks of a program, there are indeed certain problems that can be
conveniently solved only by having available, or simulating, dynamic
binding.  I think that that is an artifact of the program organization,
and not an essential property of any computation.  I believe that given
Scheme with a properly designed module facility, it would be possible to
write a complex software system, on the order e.g. of the Lisp Machine
system, and to do it quite elegantly and efficiently without once using
*or simulating* dynamic binding.

    As with the GOTO statement or an iteration facility, dynamic binding is
    a thing about which people like to speak and reason. Language designers
    may choose to support such speech at the languistic level or not, as
    they choose, but that only affects how concepts are expressed verbally--it
    does not dictate which concepts are permitted.

But we Schemers have abandoned GOTO in favor of the procedure call in
tail-recursive position, and rightly so, the idea being that we slightly
modify a familiar and well-liked concept, the procedure call, and
discover that lo and behold, we simply don't need GOTO anymore; we have
something which covers all the uses for which we would have wanted it,
and does many more things we couldn't do nearly so elegantly before.  I
believe this is a similar situation.

    No language can optimize all things.  A primary goal of a language
    should be to optimize those things which people often say.  Another 
    is to make the common things efficient.  If you optimize for the wrong
    set of commonly-used expressions, people will resent the fact that you have
    made their speech patterns too clumsy or their code too slow, and they will
    seek another language.

And another goal is to encourage good structure.  It's one that's less
widely appreciated, since a taste for it requires some experience with
large (or at least medium-large) programs, but for some of us it's very
important.

I hasten to add that I don't think the style I advocate will turn out to
be clumsy or convoluted; and I think it will bring a gain in efficiency,
not a loss.  There is no question that it is a different style from the
one Lisp programmers are used to, and that changing over to it will
initially require some mental gymnastics (not any greater than, and in
fact similar to, those required to learn object-oriented programming).
Whether we as the designers of Scheme want to force people to make that
leap is another question entirely (more on which below).

    I'm not definitely of the opinion that dynamic bind should be in scheme.
    But I'm definitely of the opinion that dynamic bind should definitely
    not definitely not be in scheme. [Yes, I double-checked, there are no
    spurious words in the previous sentence.]  That is, in Kripke's
    terminology, it may be "true" that dynamic bind doesn't belong in
    Scheme, but it is not "necessarily true" that it doesn't belong.  Any
    decision to leave it out must be done on the basis of reasoned debate,
    probably about statistical need, not on the basis of any claims of 
    inherent truth.

But as I point out, we omit FEXPRs and GOTO on the basis of analysis,
not statistics.

Listen, I don't want to sound rabid about this.  Let me add that I know
perfectly well that I'm leaning against the wind, that my viewpoint is
highly unorthodox within the Lisp community, and that I'm not
emotionally attached to swaying the opinion of the community on the
matter.  (I'm certainly not inclined to block consensus, should it come
to that.)  Nevertheless, you did ask my opinion; so I thought, What the
hell, I think I have an important point here, let's see if I can
communicate it.

I think the final resolution of the matter may be like this.  I am
absolutely convinced that for the purposes for which I want a
programming language, it shouldn't provide dynamic binding.  What is not
so clear is that my purposes and goals for a language are the same as
those of the Scheme community; in fact, they probably aren't.  So it
could conceivably come to pass that many or most of you understand the
point I am making without agreeing that it is applicable to Scheme in
particular.  Specifically, as I mentioned above, I would constrain
people's programming styles in a particular way (which I happen to think
leads to better programs and better thinking about programs).  The
community could well decide that it is more interested in supporting a
variety of programming styles, and not so interested in teaching
stylistics.  (I observe that good programmers-in-the-large are far rarer
and more valuable than good programmers-in-the-small, and think we
should do anything we can to encourage the latter to grow into the
former.)

 -- Scott