home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / pop / 179 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  1.8 KB
  1. From: sfk@otter.hpl.hp.com (Steve Knight)
  2. Date: Fri, 1 Jan 1993 17:35:54 GMT
  3. Subject: Re: Dynamic List Implementation
  4. Message-ID: <116670042@otter.hpl.hp.com>
  5. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  6. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!col.hp.com!news.dtc.hp.com!hpscit.sc.hp.com!hplextra!otter.hpl.hp.com!otter!sfk
  7. Newsgroups: comp.lang.pop
  8. References: <116670038@otter.hpl.hp.com>
  9. Lines: 34
  10.  
  11. Thanks to Aaron Sloman for for the historical review of dynamic lists.
  12. It is always insightful to see how a language flows from equal 
  13. measures of design and experiment!
  14.  
  15. Aaron writes:
  16. > One problem with having a different record type for dynamic lists is
  17. > that if you expand a dynamic list you would then have to change the
  18. > type of the record, since lots of things can be pointing to that
  19. > list.
  20.  
  21. This isn't strictly necessary.  The DPAIR could be implemented exactly
  22. the way dynamic PAIRs are currently implemented.  In other words, they
  23. could have a procedure for their back if they were dynamic and false
  24. if they were an expanded null.
  25.  
  26. Aaron makes another point concerning the optimisation
  27.     unless null( x ) then ... destpair( x ) ... endunless
  28. to 
  29.     unless null( x ) then ... fast_destpair( x ) ... endunless
  30. and this point is preserved using the implementation suggested above.
  31.  
  32.  
  33. John Gibson's point, that the current implementation of dynamic
  34. pairs only costs another memory access is plainly true.  However,
  35. the performance different is measurable -- I wrote a note on this
  36. a while back I think.  
  37.  
  38. There can't be many programs that would be broken if we were to
  39. change the representation of dynamic lists.  (In fact, such programs
  40. are already broken by my way of thinking.)  The only examples I can
  41. think of are list operators such as expandlist which plainly have
  42. to change when one changes the representation.
  43.  
  44. Steve
  45.