allow for multiple pre- and postcondition checks at same level

[sellout]

Currently, if there are multiple conditions at the same level, we end up doing something like this:

(defmethod put :ensure "stack not empty & ITEM added to top" (item (object stack))
  (and (not (emptyp object))
       (eq (item object) item)))

However, this leads to less-specific than ideal condition reports. Something like either

(defmethod put :ensure "stack not empty" (item (object stack))
  (not (emptyp object)))
(defmethod put :ensure "ITEM added to top" (item (object stack))
  (eq (item object) item))

or

(defmethod put :ensure (item (object stack))
  (contract-check (not (emptyp object)) "stack not empty")
  (contract-check (eq (item object) item) "ITEM added to top"))

would allow us to give more specific condition reports.

[kisp]

I was going to report this issue myself. :)

The second option, using contract-check is of course doable. The first one looks more composable, though. But how exactly would it work that CLOS does not interpret the second method as a redefiniton of the first?

[sellout]

Well, if I knew how to implement the first one, it’d already be done 😉

But … just as we can distinguish between :ensure and :guarantee with the same specializers, it seems like we should be able to distinguish between different string qualifiers. But (and it’s been ages since I’ve looked at this) I think that compute-applicable-methods is called on each method group and errors if it finds methods with the same specializers. In which case, either

1. different strings need to end up in different method groups (which I have some ideas about, but all of them expose some hackiness to the user); or
2. we go full MOP, subclassing standard-generic-function and overriding compute-applicable-methods for it to allow for multiple methods with the same specializers.

The problem with number two is that it won’t play nicely with other people’s standard-generic-function subclasses. But that might only affect @edicl 😉