Re: setf.scm

[Mikael Djurfeldt <mdj@nada.kth.se>]

Per Bothner <bothner@cygnus.com> writes:

> > I don't like the idea of extending Scheme with the new mechanism of a
> > binding between procedure objects.  Of course you could look upon it
> > as a simple table lookup, but it is not good to encourage people to
> > use such a mechism for the elementary operation of storing a value in
> > a location.
> 
> You have the same issue whether you are talking about extended set!
> or "static" setf! or "dynamic" setf!

No.

The "static" setf! can be written as a macro using only the standard
mechanisms of the language.  setf! can be written in terms of setter,
as you described.  (setter accessor) can be expanded to an "extended
name", for example an invisible and/or unreadable symbol.  This means
1. that the table lookup (symbol->binding) will be made only the first
time the setter is used and 2. that techniques for inlining of code
will generalize automatically to setters.

With the "dynamic" setf! you need to do a table lookup for every
access unless you add special support for it in the interpreter, and
it will still be difficult to do the inlining (actually, I don't
currently see a way to do it without introducing strange new
conventions and/or declarations).

(The difference between the names set! and setf! depend on whether we
want to include it in the core language or whether it should be loaded
as a separate module.)

> So I take it you oppose setf!.

Yes.

I oppose "static" setf! because it leads to nonintuitive behaviour.  A
Scheme programmer would expect things like (Maciej's example):

  (define (swap data accessor1 accessor2)
    (let ((value1 (accessor1 data))
          (value2 (accessor2 data)))
      (setf! (accessor1 data) value2)
      (setf! (accessor2 data) value1)))

  or

  (setf! (setter car) set-car!)
  (set! first car)
  (setf! (first ls) x)

I oppose "dynamic" setf! because I don't like the combination of being
an elementary operation (storing a value in a location) and being hard
to compile to efficient code.

> > I would very much like Guile to be a Scheme interpreter + useful
> > libraries.  I'm much more afraid of language bloat than of code bloat.
> 
> But the libraries (with their associated names) are part of the
> language.  My preference is to avoid concept bloat, in terms of the
> number of different things a programmer needs to know.

What I meant was that I'd like us to be restrictive in extending the
core language.

If we add new libraries, the programmer doesn't need to know about
them.

If we add a library with a setf! form but don't distribute it in
guile-core, people can use it but can't rely on it being available
everywhere, so it won't be used everywhere, so a programmer doesn't
necessarily need to know about it.

If we extend the core language set! form, a programmer will need to
know about it.  For a language like C++, such an extension would make
much difference.  For a language as simple as Scheme, the addition of
a binding between procedure objects is a strange new concept.

> > I can see how read-only bindings
> > in the new module system can help the compiler to determine which
> > procedures can be inlined.  Should we now introduce
> > read-only-procedure-bindings so that the compiler can do the same
> > thing for setters?
> 
> Yes.

I suppose you use

  (set! (setter foo) foo-setter)

to set the setter of a procedure.

How do you propose that we tell the compiler that the binding between
foo and foo-setter hereafter is read-only?

/mdj