Topes, again..

["J. A. Durieux" <xerox@cs.vu.nl>]

I> Date:     Fri, 7 May 93 11:26:27 MET DST
I> From: "J. A. Durieux" <xerox@cs.vu.nl>

I> What I'm really curious about, is arguments not to add topes to Scheme.
I> I know one: it's a change.  Are there others?

U> From: Jonathan Rees <jar@cs.cornell.edu>
U> Date: Fri, 7 May 93 10:42:12 -0400

U> It would make the language much more complicated and confusing.  Sure,
U> if you started with references and designed the language with them as
U> a given, you might get something very nice, like Algol 68.  Paste them
U> on afterwards and you get a split-personality mess.  Twice as much
U> intellectual baggage, twice as many stylistic decisions to make for
U> every program you write, twice as many ways for a beginner to get
U> confused.
U> I don't think anyone is against change per se.

If this is the common impression, then either I am thoroughly confused, or
I am a very bad explanator (or both) [[In both cases I propose not to
bother the whole list with it, but discuss it privately, if you (or anybody
else, for that matter) are willing to.]], since I disagree completely.

[[I just saw Aubrey's post, and it seems it is at least partly the fault of
my lack of explanation ability.  I will react to your post later, Aubrey.]]

As far as I can see, the language becomes less complicated (both the model
and the straight-forward implementation become smaller), richer, and more
orthogonal (OK, these aren't independent aspects).

Smaller:
  - the special form "set!" goes away.  
  - the primitive functions set-car!, set-cdr!, vector-set! and
    string-set! go away.  (set! (car ..) ..) and friends take
    their place, at no cost.
  - The model moves from an environment model to a substitution
    model with one global environment of topes (implementations
    may stick with environments, of course).
  + topes are added, being a disjoint data type with
    tope, untope, tope? and set!
  + a few special forms (lambda, define) become syntax, defined
    in terms of new, less complex, special forms.  The same holds
    for a few syntax forms (let, letrec).
    [[One could count this as a "-" as well, since the new forms
    are simpler, such as defconstant vs. define.]]
  - Syntax due to the specialness of set! may become procedure,
    like e.g. push, pop, and like constructions.

Is this so much intellectual baggage?

Less error-prone:
  - Freshmen (not yet using non-functional things) won't see a
    difference.
  - Sophomores (using set! and the set!-procedures) have fewer
    procedures to learn, since they can use (set! (cdr ..) ..), etc.
  - Juniors (having had some software engineering, too) can define
    constants, unalterable half-cells, vector and string elements.
    They are the first ones that need to learn about explicit topes
    (or at least some constructs defined in terms of them).
    This makes code more self-documenting, and catches inadvertant
    mutations.
  - Seniors (power programmers) have access to all the tricks
    feasible with topes (like with call/cc): nested topes, sharing
    topes, etc.

Also, typical confusion as caused by last-pair, member, assoc (returning
more than one expects) will cease to exist, since the relevant tope can
simply be returned, allowing things like
(set! (assoc 'key alist) new-value).
[There is the issue of finding #f vs. not finding anything, too, but that
is another issue]

It is also the professed Scheme way to do, since having zillions (OK, five)
mutable constructs is more "featureism" than one type to represent
mutability.

And it is a simple change: in my interpreter, it took the following:

- define "detope" (two lines, and it should have been the non-recursive
"untope1").
- twice wrap "detope" around an expression.
- take out the code for "set!".
- add the primitive procedures "set!", "tope", "untope" and "tope?".

This cannot be compared, of course, with changing a real interpreter or
compiler, but is a measure for the amount of change that occurs in the idea
of what Scheme is.

Well, if anybody cares to discuss this with me (or if y'all beg me to keep
this on the list :-), I'll read it in my mail.

Thanks for bearing with me for so long,

                               J. A. "Biep" Durieux.