Could you post the most trivial possible example that manifests
your problem?
Actually, I had in mind something a little smaller. I have submitted the
following bug report to the S48 bugs.
I'm guessing that in the first SEARCH-STREAM definition below, the GC doesn't
realise the var S is dead in loop LP, so S continues to pin down the whole
lazy list.
By the way, Sean, the definition you are using for your stream datatype
seems off. You check for termination by seeing if (STREAM-CAR S) is
the empty stream, which isn't right. You may prefer the formulation I
use below.
-Olin
===============================================================================
To: scheme48-bugs@martigny.ai.mit.edu
Subject: GC problem
Reply-to: shivers@ai.mit.edu
A <lazy-list> is either
- (delay '())
- (delay (cons exp <lazy-list>))
Below, I define a function SEARCH-STREAM that loops over an infinite lazy
list, dropping the heads of sub-lists as we loop. With the first definition
of this function, we blow out the heap; with the second definition, the
GC is able to reclaim the freed storage.
It seems like a bug that the first definition doesn't work.
-Olin
-------------------------------------------------------------------------------
Scsh 0.4
> (define (counter i)
(delay (cons i (counter (+ i 1)))))
> (define (search-stream pred s)
(let lp ((lis (force s)))
(if (pred (car lis)) lis
(lp (force (cdr lis))))))
> (search-stream (lambda (n) (= n 50000)) (counter 0))
Interrupt: memory-shortage
1>
> (define (search-stream pred s)
(let ((lis (force s)))
(if (pred (car lis)) lis
(search-stream pred (cdr lis)))))
> (search-stream (lambda (n) (= n 50000)) (counter 0))
'(50000 . #{Procedure 299 (unnamed in make-promise)})
> ,exit
Process scheme finished
|