home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / scheme / 2040 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.3 KB  |  50 lines
  1. Newsgroups: comp.lang.scheme
  2. Path: sparky!uunet!cs.utexas.edu!usc!wupost!udel!louie!hercules.cis.udel.edu!carroll
  3. From: carroll@hercules.cis.udel.edu (Mark C. Carroll)
  4. Subject: Re: random rant on random files
  5. Message-ID: <1992Aug17.180904.21548@udel.edu>
  6. Sender: usenet@udel.edu (USENET News Service)
  7. Nntp-Posting-Host: hercules.cis.udel.edu
  8. Organization: University of Delaware, Newark
  9. References: <9208130624.1.11214@cup.portal.com> <700@data.rain.com> <16ocv6INNl87@agate.berkeley.edu>
  10. Date: Mon, 17 Aug 1992 18:09:04 GMT
  11. Lines: 37
  12.  
  13. In article <16ocv6INNl87@agate.berkeley.edu> bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
  14. >I don't find this "store" idea obvious at all.  Does it live in memory
  15. >or on the disk?  If on the disk, does that mean there is a redundant
  16. >disk-to-disk copy when I finally use store->file?  If in memory, how
  17. >do you handle gigabyte stores?
  18. >
  19.  
  20. I think that the point of it is to _deliberate_ fuzz the issue of
  21. where the store is located. It doesn't matter! All that matters is the
  22. behavior of a store when you use it - the rest is implementation
  23. details.
  24.  
  25. Given a system like a store, what's great about it is that it can
  26. provide read/write access to _anything_: a store can be in memory, on
  27. a disk, a combination... it can be anything at all that behaves the
  28. correct way, and the implementation of stores is responsible for
  29. providing an appropriate low-level implementation.
  30.  
  31. (For an example of how well ideas like this can work, take a look at
  32. the Modula-3 I/O streams system. It provides perfectly flexible,
  33. general access to _anything_ that can be read or written.)
  34.  
  35. >I'm not necessarily objecting to the idea.  I just need to see more
  36. >discussion than was posted about why this is thought preferable to
  37. >just adding seek, binary-read, and binary-write to the port mechanism.
  38.  
  39. It's preferable because it doesn't rely on the filesystem, and it
  40. isn't specific to disks. A store can be used to read/write a section
  41. of memory, or a file on disk, or a screen display, or... 
  42.  
  43.     <MC>
  44.  
  45. -- 
  46. || Mark Craig Carroll: <MC>     || "There is no such thing as a problem 
  47. || Univ of Delaware, Dept of CIS||  without a gift for you in its hands. You
  48. || Grad Student/Labstaff Hacker ||  seek problems because you need their 
  49. || carroll@udel.edu             ||  gifts" - _Illusions_, by Richard Bach
  50.