[iterate-devel] Macroexpansion, bindings and information flow (Iterate package)

[Hoehle, Joerg-Cyril]

Hi,

you're invited to look up comp.lang.lisp on this subject where I wrote:

"I believe in its over 10 years of existence, it's never been able to
correctly handle this form:
    (macrolet ((over(x) `(collect ,x)))
      (iterate
	(for n in '(1 2 3))
	(flet ((over(x)(declare (ignore x)) (collect 2)))
	  (over n)))) ; would yield (2 2 2) if correct
One reason is that it does not contain a code walker aware of lexical
bindings. ..."
[BTW, I added that to iterate-test.lisp :)]

I believe it's possible to add restricted support for macrolet. The restriction is that the macro expanders neither contain nor expand into iterate clauses (the body may contain clauses).
This would mean that Iterate would play nice with uses of macrolet which are independent on it, e.g. hashtable iterators.

Together with support for locally (and fixing some more subtle bugs I did not yet talk about), I believe Iterate would be more valuable if

a) it accepted macrolet instead of giving an error
b) there would be some restrictions
b2) Iterate would issue (warn ...) upon macrolet
c) the above shows that it is hard to have Iterate generate correct code in all cases, but users can hopefully live with that.

My fear is that the Iterate user may not realize that some situations are deadly. E.g. I've often thought about an implementation style as follows:
(defmacro loop-finish () (error "Use of LOOP-FINISH outside LOOP")
  ;; or `(error ...))
(defmacro loop (&body)
  `(macrolet (loop-finish () `(go loop-end))
     ...))
The idea is to provide both global and local macro definitions. The global one is solely to ease debugging.

Iterate would generate incorrect code when this loop definition would be used somewhere inside the iterate body. A real problem is that the user may not even notice that this situation arises.

What do you think?

Notice that correct macrolet handling requires correct lexical parsing. In my posting to comp.lang.lisp I'm asking how/whether this can be portably done.

Regards,
	Jörg Höhle.