[Openmcl-devel] Compiler infinite loop

[Gary Byers]

Having a symbol-macro (or any other kind of macro) expand into itself
will obviously lead to infinite recursion.  The condition that gets
raised in some implementations is due to the fact that this infinite
recursion exhausts the stack (not because they've otherwise tried to
solve the halting probkem); in other implementations, tail-call
optimization makes it equivalent to an infinite loop.

I'm not really sympathetic to the notion that - all other things being
equal - symbol-macroxpansion should consume stack space unnecessarily,
so that someone who writes an infinitely recursive symbol macro won't
be "bitten" by that hanging instead of stack overflowing as they (for
some unknown reason) appear to expect.  I'm much more sympathetic to
the general idea that deeply recursive things should run in bounded
stack space if that's at all possible.






On Sun, 19 Sep 2010, Valentin Baciu wrote:

> I agree that this fits perfectly into the "code smell" category, but my initial example was something more complex and I
> manged to reduce it to that snippet. By the way, I have just tested my code in SBCL and CLISP: both implementations throw an
> error, without hanging.
> 
> On Sun, Sep 19, 2010 at 10:14 PM, Ron Garret <ron at flownet.com> wrote:
>       My thoughts: don't write code like that.  (Reminds me of the old aphorism: "Doctor, it hurts when I poke myself in
>       the eye.")
> 
> On Sep 19, 2010, at 12:08 PM, Valentin Baciu wrote:
> 
> > Hello,
> >
> > I ran into an infinite loop that keeps one out of two CPUs at 100% while compiling some piece of code reduced to this
> example:
> >
> > (defun keep-compiler-busy ()
> >   (let ((test nil))
> >     (symbol-macrolet ((test test))
> >       (pprint test))))
> >
> > I am not sure if this is a bug (maybe not according to CLHS) or if this could be a "missing" feature, but it bit me
> until I realized what happened. My guess is that the compiler keeps expanding the symbol 'test without exhausting the
> stack. Not a big problem from my point of view, but please let me know your thoughts on dealing with this kind of stuff.
> >
> > _______________________________________________
> > Openmcl-devel mailing list
> > Openmcl-devel at clozure.com
> > http://clozure.com/mailman/listinfo/openmcl-devel
> 
> 
> 
>