[racket] struct-copy and custom-write bug?

One useful trick in these situations is to break the computation and then
you can sometimes get a stacktrace inside the infinite loop.

Robby


On Sat, Mar 1, 2014 at 6:40 AM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:

>
> On Mar 1, 2014, at 5:50 AM, Jon Stenerson wrote:
>
> > When I put the following in the DrRacket definitions window and then
> evaluate t, it works for a few seconds and runs out of memory. Anyone
> understand the problem?
> >
> > #lang racket
> >
> > (define (Print stx port mode)
> >  (if (Atom? stx)
> >      (write-string "ATOM " port)
> >      (Print (Pair-cdr stx) port mode)))
> >
> > (struct Base ()
> >  #:methods gen:custom-write
> >  [(define write-proc Print)])
> >
> > (struct Atom Base (datum))
> > (struct Pair Base (car cdr))
> >
> > (define t (struct-copy Base (Atom  3)))
>
>
> t is _not_ an instance of Atom but Base, which is what the struct-copy
> expression specifies. When you enter
>
>  > t
>
> Racket looks for a printer specification. It finds write-proc, which
> checks Atom? of stx and finds that t is not an Atom. Hence, it extracts
> Pair-cdr, but t is also not a Pair. Ergo, Pair-cdr raises an exception. The
> printer needs to print what it found in lieu of a Pair, so Racket looks for
> a printer specification. It finds write-proc, which ...
>
> Easiest fix: Change Base in the last line to Atom.
>
> -- Matthias
>
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140301/cfee0bf1/attachment.html>