\section{Interface of a function}

Let's assume we have a (non-generic) function 
{\tt op-res} which takes as 
first argument an operator of type

\bv
  Operator : AddSym | MulSym.
\end{verbatim}

plus two other arguments which are numbers.
Function {\tt op-res} returns the value of applying the operator to the
two numbers.  We have provided this function to our users and 
given them the interface for the function.

Some time later, we decide to make the function generic in its first
argument. Should we inform the users about this change? (By the way,
in CLOS we are forced to make the function generic in all three arguments since
all three are required.) The users might have used this function {\tt op-res}
inside other methods and if we make now the first argument generic
the user's code might suddenly violate the Law. Why should the user
know about the fact that the first argument is generic now? The reason
is extensibility! The user has now an easy way to extend the {\tt op-res}
function to other types and that is very useful knowledge for the
future modification of the user's program. 

When the function is generic in its first argument, its implementation must
look like: (pardon the new Flavors notation; this discussion is relevant
not only to CLOS but also to generic function
systems with only one dynamic method-selection argument (such as new Flavors)):
\bv
  (defmethod (AddSym op-res) (e1 e2) ... )
  (defmethod (MulSym op-res) (e1 e2) ... )
\end{verbatim}
If the user wants to extend the domain of {\tt op-res}, he/she just adds
another method. If the function is not generic, this won't work.

{\em Therefore, we view the number of method selection arguments of a function
as part of the interface of that function along with the typing information
and a formal or informal specification.}

HERE WE CLASH WITH THE VIEW OF THE CLOS INVENTORS. They view the syntactic
non-distinction as a contribution of CLOS, while we view the fact that
we can have several method selection arguments as one (among many) contributions
of CLOS. 

What about the violation of the Law when we go from non-generic to
generic? Lets consider the following classes:
\bv
  A = <x> Compound.
  Compound = "(" <op> Operator <args> List(PrefixExp) ")".
\end{verbatim}
Consider the method:
\bv
  (defmethod (A bad-style) (e1 e2) (op-res (op x) e1 e2))
\end{verbatim}
which is identical before and after the transition from non-generic to generic.

Why is method "bad-style" in bad-style after the transition? 
Since it is attached to class {\tt A} AND 
since it contains a dependency on the subparts of the {\tt Compound} class.
If {\tt Compound} changes to

\bv
  Compound = "(" <additive-op> Operator <args> List(PrefixExp) ")".
\end{verbatim}

we have to modify the semantics of class {\tt A}, 
although class {\tt A} did not change:

\bv
  (defmethod (A :bad-style) (e1 e2) (op-res (additive-op x) e1 e2))
\end{verbatim}

This violates the principle of modularity.
Why is "bad-style" in good-style before the transition? 
It is the prerogative of the Law that
it can accept certain constructs which are in bad shape. We want to
have a Law without exceptions which is easy to remember and to follow.
We don't want to restrict non generic function  calls since 
we don't want to upset the Lisp or C programmers.