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] |
jimb@red-bean.com writes: > > > 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. I'm not proposing it as anything. I was just commenting on Per's suggestion in a general way. He said he hadn't thought of a way to allow setters to be set for user-defined procedures, so I suggested one. IMO it is a mostly orthoginal feature to variable tracing and only allows you to achieve a few things that superficially look the same. The only problem it solves of the ones I mentioned is to make read-modify-write macros work, as you mention below. But I think it is an elegant and useful syntax in it's own right. > > 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. Well, it could also solve point 2 if it resulted in people getting motivated to change the relevant bits of code. - Maciej