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" == Per Bothner <bothner@cygnus.com> writes: Per> * The method precedence order is arbitrary, and (supposedly) "wrong". Supposed wrong by whom? And what do you mean by arbitrary? Anyway, one of the main points about having a MOP is precisely that it is possible to adjust such details. Per> * I'm not convinced that multi-methods are worth it. Being part of a project that tries to implement CMIP (ISOs alternative to SNMP) has convinced me that there is a time and place for even such esoteric stuff. Per> They are more difficult to implement efficiently, Perhaps, but if you feel you need a multimethod, you probably are ready to pay the price, and I do not believe that having the possibility of multimethods needs to penalize single-dispatch methods. Per> they make it more difficult to figure out what is going on, Perhaps, but it is also conceivable that multimethods could make it easier to express certain things. AMOP has a comment somewhere about multiple inheritance, stating that such a thing sometimes is necessary, and when it is, it is better to have it up front as a part of the language than requiring the programmer to go through all sorts of convoluted exercises to achieve the desired effect. Per> they remove the modularity advantage that conventional Per> object-oriented languages have (that methods are associated with Per> their classes). Well, I find the concept of generic functions to fit much better with a lisp (or scheme) environment and don't see any advantage to see methods as associated with or encapsulated in individual classes. Per> * I'm nervous about a "mostly-functional" language whose semantics Per> depend so much on global state and side-effects. I am not quite sure what this means wrt. to the contrast between scheme and CL. Obviously there are lots of details and differences in the mapping between names and what they mean, but other than that, where do you see the excessive dependencies in CLOS? Per> * I'm concerned that efficient compilation and static analysis Per> seem to be difficult. Do you think that CL is worse in this respect than scheme? Without being intimate with the Stalin compiler, I think that CMUCL does quite well, and I believe we have a long way to go before we can compete with the PCL implementation of CLOS. ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)