Hi,
I was helping out a friend the other day with a cache implementation
in CL for his research. He had a large number of data files (images)
that he'd need to use. It turned out that given that he just used one
of the images, it was more likely to be used again in the near future
than one which was not recently used. These images were pretty large,
and so his computer could not handle keeping all in memory. I think
out of a few hundred, he could handle about 50 before his computer
started swapping heavily.
CL made it more than easy to only keep the last 50 used images in
memory. But what I was wondering is how many times did that code have
to re-source an image that was actually still in memory, but just
waiting to be collected? That's a shame. Of course, this is what
weak references are for. It's actually the first time I realized that
they were useful.
ACL made this easy, with their additional options on
#'make-hash-table. Would these (or similar) options be a poor choice
to add to CL's hashtables? Why? Of course, it might be better to
make a more general approach to weak references, but in general, I
wonder what the reasons are that weak refs are not part of the spec.
dave
* David Bakhash <·····@alum.mit.edu>
| but in general, I wonder what the reasons are that weak refs are not
| part of the spec.
It's important to realize that this is an invalid question, like any
other anachronistic question, because it assumes that what you know
now was known then. The appropriate questions in such a situation
include: "Were weak references considered for standardization?", the
answer to which is "no", thus there _are_ no reasons they are not
part of the spec.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.net> writes:
> * David Bakhash <·····@alum.mit.edu>
> | but in general, I wonder what the reasons are that weak refs are not
> | part of the spec.
>
> It's important to realize that this is an invalid question, like
> any other anachronistic question, because it assumes that what you
> know now was known then. The appropriate questions in such a
> situation include: "Were weak references considered for
> standardization?", the answer to which is "no", thus there _are_
> no reasons they are not part of the spec.
There was some guesswork on my part. That guesswork was that as long
as the ANSI spec even implied garbage collection, and when objects
were to be collected, that the possibility of reusing these objects
existed. If what you're saying is the case, then I would be
interested in a discussion considering the addition of such soft
references to the standard, or (if it's already been discussed) some
references to the past discussions.
dave
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * David Bakhash <·····@alum.mit.edu>
> | but in general, I wonder what the reasons are that weak refs are not
> | part of the spec.
>
> It's important to realize that this is an invalid question, like any
> other anachronistic question, because it assumes that what you know
> now was known then. The appropriate questions in such a situation
> include: "Were weak references considered for standardization?", the
> answer to which is "no", thus there _are_ no reasons they are not
> part of the spec.
Are you sure about this, Erik? Weak references have been around long enough
to have been available for consideration in the CL spec. I would have
guessed it was an issue of requiring certain features that many GC's would
have had trouble integrating without a major rewrite.
-- Harley
"Harley Davis" <·············@nospam.museprime.com> writes:
> "Erik Naggum" <····@naggum.net> wrote in message
> ·····················@naggum.net...
> > * David Bakhash <·····@alum.mit.edu>
> > | but in general, I wonder what the reasons are that weak refs are not
> > | part of the spec.
> >
> > It's important to realize that this is an invalid question, like any
> > other anachronistic question, because it assumes that what you know
> > now was known then. The appropriate questions in such a situation
> > include: "Were weak references considered for standardization?", the
> > answer to which is "no", thus there _are_ no reasons they are not
> > part of the spec.
>
> Are you sure about this, Erik? Weak references have been around long enough
> to have been available for consideration in the CL spec. I would have
> guessed it was an issue of requiring certain features that many GC's would
> have had trouble integrating without a major rewrite.
For CLTL1, the only prior experience I can think of is Maclisp
type-NIL arrays, wherein if an element was GC'd, you found NIL in the
array slot. The problem here was that the slot didn't (couldn't) go
away and the effect was just bizarre. I think mostly no one was clamoring
for these even though they were occasionally vaguely useful.
My recollection is that weak hash tables were just being experimented with
at the time of the second round feature freeze, and that either no one thought
of them or no one thought they were stable enough. I think maybe the latter.
I vaguely remember the issue coming up and people saying there wasn't enough
current practice.
The nice thing about weak hash tables is that as the values go away, so can
the whole entry. And there's a natural return value convention that
distinguishes "NIL was stored here" from "nothing was stored here".
Harder to do with arrays, which both can't remove elements and don't return
info about what's not present.
Just vague memories at this point, and I could be wrong. I don't think
there were specific proposals which were raised and rejected, but people can
browse the records on parcftp, I suppose, for a more authoritative record.
Still, reasons for not raising an issue are rarely as well documented as
reasons for raising it.