MacIvory conversion experience

[Michael Greenwald <Greenwald@SCRC-STONY-BROOK.ARPA>]

    Date: Tue, 21 Feb 89 17:12 EST
    From: Barry Margolin <barmar@Think.COM>

	Date: Tue, 21 Feb 89 15:32 EST
	From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>

	A second flaw, too.  What if you redefine the function to have a
	different arglist?  HIDDEN-ADVISE won't be up-to-date, and, in fact,
	might raise an error.  ADVISE (actually all forms of encapsulation) is
	(are) supposed to work across redefinition of the function.

    I thought about that, and decided that it isn't really a problem.  If
    the argument order changes, a piece of advice that is using CAR, etc.
    and hasn't been updated would also be incorrect, so it's no worse than
    the current situation.  

I disagree (mildly).  There are two differences.  In the CAR case (or if
the ADVISE form explicitly uses (destructuring-bind arglist ..)) then the
bug is in the user code, not in the system utility.  Second, if ADVISE did
the destructuring-bind itself, then it would raise an error even if the
user >didn't< use the feature explicitly.

How about a compromise: we document the trick of using DESTRUCTURING-BIND
of the ARGLIST, and warn that if you redefine the arglist you'd better
redefine the advice, too.  Maybe we even provide a macro you can use
inside the body of your advice.

I don't know if this would get into the system in the near future, either.

			But it's actually better, because advice that
    uses CAR would need to be edited, while something that snarfs the
    current arglist would only need to be re-executed.

	A minor third flaw is that it will be fooled by (DECLARE (ARGLIST ...)).
	It should get REAL-ARGLIST.

    That's only really important in the cases where DECLARE ARGLIST has been
    used to put in "comments" (I think there's a function with an "optional"
    first argument, with a (DECLARE (ARGLIST [OPTIONAL] ...))).

Whatever.  I said it was minor, but it >is< a bug.

						    barmar