Cells

[Rishiyur S. Nikhil <NIKHIL@XX.LCS.MIT.EDU>]

    From: umb!gerald@husc6.harvard.edu  (Gerald Ostheimer)

    *** Why didn't the designers of Scheme include locations (~anonymous
    variables) as first-class values in the language? ***

    From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>

    Plenty, including the designers of Algol 68, PLASMA, and ML.  If you did
    this to Scheme I think you'd have quite a different language, different
    enough that it would require significant changes to implementation
    strategies.

    From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>


    ...  There's no choice but to use mutator procedures.
    Since we have to use them anyways, why not be clean and not bother with
    locations?  Do you really want to imitate BLISS and require explicit
    dereferencing for every mutable variable?

I don't understand why the introduction of locations in the sense that
Gerald Ostheimer suggested would make Scheme such a different or
unclean language.

I don't have his original message, but his proposal was something like
this (ala ML): The expression ``(VAR E1)'' would allocate a cell
containing the value of E1, and return a reference to it.  If X is
bound to such a reference, then ``(GET-VAR X)'' returns the value in the cell,
and ``(SET-VAR! X E2)'' replaces the value in the cell with the value of E2.

Now, VAR is nothing more than a ``one-slot CONS''.  GET-VAR is the
one-slot version of CAR/CDR, and SET-VAR! is the one-slot version of
SET-CAR!/SET-CDR!.  So, why does it make the language so
different/unclean?

Such cells normally must be heap-allocated, so this may seem like
extra cost.  But this is not obvious: A) Lifetime analysis could move
them to stack frames, and B) in many situations where one currently
must use a frame-variable in the heap, the one-slot cell may be a
cheaper alternative.

Nikhil

(I agree that arbitrary locatives, e.g. pointers to the middle of cons-cells,
would make things very unclean, but I don't think that was what Gerald O.
was proposing).
-------