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] |
Maciej Stachowiak <mstachow@mit.edu> writes: > bothner@cygnus.com writes: > > > However, it would please me (if it's not too deadly to implement) to > > > see functions allowed to return set!-able references: > > > > > (set! (my-prop) 17) > > > (my-prop) => 17 > > > > Kawa supports this (for some primitive functions - I haven't decided > > yet how to define such functions in Scheme). > > > > Note that having functions "return set!-able references" is > > probably not the way to do it, since we want a normal call (not in a > > set! context) to return plain value, not a reference. Instead, > > we allow functions to have "attributes", and one attribute is a > > functions setter function. Then we define: > > (set! (f . args) value) > > as being syntactic sugar for: > > ((setter f) value . args) > > I think this interface is a good thing. In fact, I wrote something > similar for Guile purely in Scheme (it defined a new setf! syntactic > form instead of overloading set!, but was based on a property of the > procedure, not the symbol). I think the interface for setting the > setter of an ordinary Scheme procedure should be: > > procedure: (set-setter! PROC SETTER-PROC) > > with `set-setter!' defined as the setter of `setter', so the user can > do (purely for example purposes, this particular setter should be > predefined): > > (set! (setter car) set-car!) > > Is there any reason why that would be a bad interface? Are you proposing this as an alternative to variable tracing? If so, them I'm confused, because it seems to have the same problem that setter and getter functions have: the syntax is not identical to that of an ordinary variable assignment. So the (quite persuasive) objections you made to ordinary getter and setter functions still apply here. Because the user needs to say (set! (parameter) ...) instead of (set! parameter), the below objections would still seem to apply. You wrote: * For a program with many configurable settings, the user should not have to know, care or remember which parameters, when set, will trigger extra processing immediately. It's often not even intuitively obvious which will and which won't. * Many configurable settings are done just plain wrong because it would be more of a pain for the implementor as well as the user to write to procedures rather than define one variable. For example, hooks are implemented as variables expected to contain lists of procedures, in Guile as well as in Scwm (for consistency). As another example, paths "%load-path", e.g. are implemented as variables that contain lists of strings, forcing any path-searching code to scan the list twice on each path search, first to make sure it really is a list of strings (and save their lenghts), and then to do the real work. In both of these cases, it would be nice for the variables in question to get typechecked when assigned, rather than on each use. Separate setter and getter procedures might be better from a language cleanliness point of view, but they are not really being used, even by guile core, when they should be. * Macros exist which do interesting manipulations of variables; they are unusable on getter-setter pairs (unless Guile gets a generic setter facility like Common Lisp's setf and starts using it, which I think is also a good idea. In fact, I wrote one in Guile Scheme a while back, but I'm not sure if anyone is interested). Per's idea does solve the macro issue, though.