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)