[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
From: firstname.lastname@example.org (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
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
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
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
(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.
- From: Bard Bloom <bard@THEORY.LCS.MIT.EDU>