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] |
Chris.Bitmead@misys.com.au writes: >> I'm just thinking from a CLOS point of view now... >> Shouldn't [(set! (PROC ARGS ...) RHS)] expand to something like... >> (setter RHS PROC ARGS ...) ? [rather than ((setter PROC) RHS ARGS ...)] >> Because if setter is a CLOS method, it would most likely want to dispatch > on >the type of ARGS, especially ARG1. Therefore shouldn't it be one of the > arguments >to allow dispatch? It also seems cleaner if the ARGS and PROC are > kept together. >Procedure and arguments evaluated the same way and all that. > >Perhaps, but I think expanding to ((setter PROC) RHS ARGS ...) is simpler. >Note there is nothing to prevent (setter PROC) from evaluating >to a generic function, which dispatches on RHS+ARGS to select the >correct method. So you have the flexibility you want, but separate >into two parts: (1) mapping from PRC to its setter (2) applying the >setter, which may involve multi-method dispatch [assuming you have multi-method >dispatch, of course]. Can you explain how you would implement (setter ...) ? I can't quite see how it works.