[iterate-devel] Iterate error with multiple-value-setq

[Hoehle, Joerg-Cyril]

Stonewall,

Thanks for the traces and your efforts.

The following trace is really what makes me wonder.
Inside Iterate, my patch should not expand m-v-b anymore and call walk-m-v-b instead.
      ((special-form? (car form)) ; handle known special operators first
       (walk-special-form form))
      ((macro-function (car form) *env*)
       (walk (macroexpand form *env*)))
      ((special-operator-p (car form))
Yet both macroexpand and macroexpand-1 show that they are called upon m-v-b. So far, I don't understand where this comes from.

0 MACROEXPAND > ...
   >> SYSTEM::FORM : (MULTIPLE-VALUE-BIND (#:G831 #:G832) (FOO) (LET* 
NIL (VALUES (SETQ A #:G831) (SETQ B #:G832))))
   >> SYSTEM::ENV  : #<Environment venv (#<Venv 269101724  B> #<Venv 
269101828  A>)  fenv NIL benv ((TEST-ITER . #<Block TEST-ITER>)) tenv 
NIL>
0 MACROEXPAND < ...
   << VALUE-0 : (SYSTEM::MULTIPLE-VALUE-BIND-CALL (FUNCTION (LAMBDA 
(&OPTIONAL #:G831 #:G832 &REST #:EXTRA-VALS833) (DECLARE (IGNORE 
#:EXTRA-VALS833) (COMPILER::WEAK-LAMBDA-NAME COMPILER::DUMMY-LAMBDA)) 
(LET* NIL (VALUES # #)))) (FOO))
   << VALUE-1 : T

There are 3 things worth trying
(declaim (notinline walk)) before definition or use
  (declare (optimize debug)) inside walk
replace macroexpand in walk with macroexpand-1

>It's interesting that this expansion turns M-V-BIND into M-V-CALL, 
>while the first two traces above produced a M-V-BIND-CALL.
Indeed.


>I'm also a little suspicious of your revised definition:
>>   (or (assoc symbol *special-form-alist*)))
>since it has a superfluous OR. I dropped the OR.
I'm sorry that my saving a little time and typing caused even more loss of time and typing to you and me. I should have simplified the form after dropping the second or clause.


>You can get the package from 
><http://www.lispworks.com/downloads/lw-personal-edition.html>. I 
>imagine that the same error occurs on all the supported platforms.
Installing packages cost me a lot of work. I can make no promise as to when I'll be able to do that. But it would be reasonable to install a collection of Lisps here so I can play with comparisons and code that does not work with either CLISP or Corman, when time becomes available.

Regards,
	Jorg.