[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

``Update functions'' in Scheme.

> The key point here is that Scheme already has enough power to express
> the abstract relationship between accessors and mutators; there is no
> need to "extend" the language to provide this feature.

I'm not exactly sure what a language extension is.  I am pretty sure that
SETF in Lisp is a macro:
(SETF x y) expands to something depending on the structure of x:
    symbol      ==> (SETQ x y)
    (CAR x')    ==> (RPLACA x' y)
    (VREF v i)  ==> (WHATEVER-VECTOR-SET-IS v i y)

   (SETF (UNKNOWN-SETTER v) y) expands to something like Lyn's or T's method,
where the setter is looked up dynamically.

So, SETF is a smart macro that either knows a lot about built-in setters, or
at least does the lookup once at compile time rather than repeatedly.  It
*is* definable in T and presumably in LISP as well.  I wouldn't call it a
language extension; it doesn't let the language do anything it couldn't do

One thing that neither Lyn nor T can handle -- I don't know about Lisp -- is
function equality:




Now, MY-PERSONAL-IDENTITY is the car function, and lambda-calculus people
like me would like to have (CAR X) and (MY-PERSONAL-IDENTITY X) behave
precisely the same under all circumstances.  I'm willing to let the
programming-language people tell me that it'll run slower, it will show up in
backtraces, it may overflow the stack, and so forth.  I'm not so willing to
learn that it doesn't behave the same in a simple usage like this.

Another example:

(SET (CAAR X) Y)  works
(SET ((COMPOSE CAR CAR) X) Y) doesn't.

In particular, my high-order functional program can build up an accessor
function which ought to have a corresponding mutator, but the mutator can't
be found because the accessor we built isn't EQ? to the accessor in the

I'll stop being idiotic about programming languages now, and admit that the
table-lookup method is much simpler to implement that any ideas I have about
getting SET to work right with higher-order programming.  Still, there might
be some not-too-horrible way to get it to work better.  Any ideas?

-- Bard the (LAMBDA (X) GARGOYLE)