[Prev][Next][Index][Thread]

Re: What are weak-cons?



"Reinhard Häring-Oldenburg" wrote:
> 
> I wonder what weak-cons are precisely. 

   I imagine it means... 
   A CONS which won't keep the refered to  CAR element from 
   being garbage collected. 

   I'm certain what makes weak cons/tables almost a necessity. 
   They definately are exteremely convenient to have when your 
   problem calls for them. [ One of the few annoying interactions
   you can have with the garbage collector. ] 


> the file DYLAN.TXT on
> http://www.cs.indiana.edu/scheme-repository/doc.standards.html

   That document dates from a time when Dylan and Scheme had 
   approximately the same syntax and few, if any, of the "sealed" 
   attributes the language currently supports. Not that you couldn't
   implement a modern Dylan runtime on top of Scheme.  I think the 
   authors here were looking for a common substrate for both. 
   With enough sweat you can implement almost any language in any
   other language.  It just may not be pretty. :-)

> Moreover, how would the "(reasonable) portable implementation" look
> like.

  You need to make your garbage collector "aware" that some references 
  don't require that something shouldn't be collected.  I think the
  "make it visible to the user" in the passage refers to making 
  a "weak" datastructure available to users.   I think that had
  more to do with the "minimalistic required standard classes" approach more 
  so than what each implementation would pragmatically provide. 


> Can anybody provide explanantion or further refernces?

   Go to   www.google.com   and enter the search string "weak hash table" 

   Apparently,  Guile has added the concept. So did XEmacs.... 

  http://www.fnal.gov/docs/products/xemacs/v21_1/lispref.info,.WeakHashTables.html

    " Weak hash tables are useful for keeping track of information in a
      non-obtrusive way, for example to implement caching."  


P.S.  From the above passage.....
      I would suspect that the generic function dispatch might
      make use of weak tables if one had to implement them "on top of" a
      language.  If dispatching can't be resolved statically (or optimized
      to some compact representation) you typically want to dynamically cache 
      a couple of the previous dispatches to perhaps resolve which method without 
      engaginng in much substantial overhead. 


Lyman



References: