This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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