CL supports multiple dispatch in its generic functions.
Multiple dispatch leads to ambiguities. If we call (fun derived-obj derived-obj) and the two available methods are (fun base derived) and (fun derived base), which one is called?
Now here is the irony: CL will decide this for you, rather than throw an error. However, if you use multiple packages with same-named symbols, you get annoying errors in your face.
That's a philosophical inconsistency pointing at too many chefs in the kitchen. It can't be the work of a single designer that reflects properly on what he or she is doing and has a clearly defined attitude about ambiguous situations in programming.
What happens is well specified, see [1] and more specifically [2].
I don't understand where packages even enter the picture though. Symbols/packages and method dispatch are entirely separate concepts that are hardly related. You certainly won't get any weird errors from one in relation to the other. Furthermore, same-named symbols in different packages are just different symbols. The fact that their name is the same is irrelevant.
> Symbols/packages and method dispatch are entirely separate concepts
They are examples of different domains which have referential ambiguities. The object system resolves them. For instance, given (defclass base (d1 d2 ..) ...), base is considered slightly more of a d1 than a d2 in situations where this causes an ambiguity. The tie is resolved and life moves on.
Multiple package use is also a kind of "inheritance", yet it blows up in your face when there are ambiguities caused by clashes (which "FOO" symbol do you want? The one from package "A" or "B"?)
All these behaviors are specified, but according to different philosophy: just resolve things with a documented tie breaker, versus diagnose the situation.
If it's OK for base to be considered slighly more of a d1 than a d2, why isn't it OK for, say, a later package use to just shadow an earlier one?
Multiple dispatch leads to ambiguities. If we call (fun derived-obj derived-obj) and the two available methods are (fun base derived) and (fun derived base), which one is called?
Now here is the irony: CL will decide this for you, rather than throw an error. However, if you use multiple packages with same-named symbols, you get annoying errors in your face.
That's a philosophical inconsistency pointing at too many chefs in the kitchen. It can't be the work of a single designer that reflects properly on what he or she is doing and has a clearly defined attitude about ambiguous situations in programming.