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] |
mdj@nada.kth.se writes: > Per Bothner suggests that setter argument order should be: > > (SETTER V A1 A2 ...) > > The motivation is that the number of arguments can vary. > E.g., the argument order > > (SETTER A1 A2 ... V) > > would be unfortunate for arrays, where the setter is > > (array-set! a V i1 i2 ...) > > When we have argument order mismatch we need to wrap the setter in a > closure which fix the arguments. > > The second convention means that the wrapper for array-set! will need > to do an explicit search in the argument list in order to locate V. > In this sense, the first convention is better than the second. > > What is not nice about the first convention is that it is incompatible > with *all* currently existing setters. > > Is there no other reasonable convention which would be compatible with > a larger set of currently existing setters? It would be nice if it > would be compatible with two-arg and/or three-arg setters of the > set-car! and slot-set! types... ? > > Example: > > It is common that the first argument is a data structure. Then one > could use the convention: > > (SETTER A1 V A2 ...) > > which would be compatible with set-car!, array-set! and Goops getters. > > Opinions? That would still be incompatible with `vector-set!' and `string-set!' from RnRS, `list-set!' from Olin Shivers' list-lib proposal, and many other Guile getter-setter pairs where the setter is typically called as (setter! data-structure field-specifier value) [such as hash-set!, set-object-property!, setters generated for record types, and I'm sure many others]. It seems a shame to require so many setters (including standard ones) to be wrapped in a closure just for the sake of supporting array-set!'s weird argument order efficiently. Indeed, I can't think of any case _but_ array-set! that needs this support. I'd rather see the argument order of array-set! get changed if it comes to that, although that probably just offloads the work of munging the rest argument from a setter wrapper to array-set! itself (depending on how those args get processed), either that or just live with the inefficient array-set! wrapper. Normal Scheme practice is to have a matching setter take the same args as the getter with the value tacked on at the end. - Maciej