time to scrap sll?
Matthias Radestock <[email protected]>
| Newsgroups | gmane.comp.java.sisc.devel |
|---|---|
| Message-ID | <[email protected]> |
I found yet another problem with loadable libraries: objects from the
heap or other slls may get included in the the sll, breaking object
identity when the sll is loaded.
Example:
;;put this in the SISC heap
(define foo
(let ([x (list 1)])
(vector x (lambda (y) (eq? x y)))))
(define foo-thing (vector-ref foo 0))
(define foo-proc (vector-ref foo 1))
;;start SISC and do the following
(module baz
(bar)
(define bar
(let ([f foo-thing])
(lambda () (foo-proc f)))))
(import baz)
(bar) ;=> #t
(import compiled-libraries)
(create-library-from-module 'baz "/tmp/baz.sll")
;;restart SISC and do the following
(load "/tmp/baz.sll")
(import baz)
(bar) ;=> #f
One place where this breaks things is when the heap defines a record
type for which record instances are included in an sll. The sll will
include its own version of the record type. When the sll is loaded, the
instances are no longer of the correct record type since the type has
been duplicated.
So I think it's time to scrap sll and replace it with the less efficient
and space-conserving, but *working* thunk libraries proposed a while ago.
Matthias
-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5