home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / scheme / 2044 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  2.6 KB
  1. Path: sparky!uunet!psgrain!percy!data!kend
  2. From: kend@data.rain.com (Ken Dickey)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Re^2: random rant on random files
  5. Message-ID: <701@data.rain.com>
  6. Date: 17 Aug 92 23:00:56 GMT
  7. References: <9208130624.1.11214@cup.portal.com> <700@data.rain.com> <16ocv6INNl87@agate.berkeley.edu>
  8. Organization: Microtek DSD, Hillsboro, OR
  9. Lines: 61
  10.  
  11. bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
  12.  
  13. >I don't find this "store" idea obvious at all.  Does it live in memory
  14. >or on the disk?  If on the disk, does that mean there is a redundant
  15. >disk-to-disk copy when I finally use store->file?  If in memory, how
  16. >do you handle gigabyte stores?
  17.  
  18. Sorry.  Let me amplify a bit.
  19.  
  20. The creation operations return a "store" object.  All store objects
  21. are treated the same.  For files, the bits stay on the disk (mod
  22. buffering).  STORE->FILE writes the contents of a store (the bits)
  23. into a file.  If the store represents a file, then you are doing a
  24. file->file copy.  If the store represents a slice of memory, you are
  25. doing a memory->file copy.  You have full random, binary access to
  26. store objects, so (STORE-REF-BYTE aStore 37) reads a byte from a file
  27. or a memory location at "start"+ 37.
  28.  
  29. As stores are random, binary i/o, everything is mapped to positive
  30. integers.  If you want to write a Scheme object (e.g. a vector or a
  31. negative integer, etc.) it is up to you to do the representation
  32. mapping. 
  33.  
  34. To map memory to a store: (MAP-STORE 100 200) returns a store with
  35. a base address of 100.  (store-ref-byte thisStore 0) gives you the
  36. byte at address 100+0 in your memory space.  Thus you can build a
  37. structure mechanism on top of stores to get values of C structs,
  38. Pascal records, whatever, by name.
  39.  
  40. You can also use stores which are really vectors unscanned by the
  41. collector.  This is what MAKE-STORE returns.
  42.  
  43. If you have not guessed by now, stores are a pretty low-level
  44. interface.  If done portable, however, this just happens to be a
  45. higher-level interface than we have now.  I think that the abstraction
  46. is useful.
  47.  
  48.  
  49. So let me try again.
  50.  
  51. > Does it live in memory or on the disk? 
  52.  
  53. It does not matter to the user of the abstraction, but memory is
  54. probably in memory and files are probably on disk (mod buffering).
  55.  
  56.  
  57. > If on the disk, does that mean there is a redundant
  58. >disk-to-disk copy when I finally use store->file? 
  59.  
  60. If you are doing a copy, where is the redundancy?
  61.  
  62.  
  63. > If in memory, how do you handle gigabyte stores?
  64.  
  65. By doing *nothing* special {I assume bignums and linear addressing}.
  66. I am not copying anything to create a store (just as opening a file
  67. does not copy the file).
  68.  
  69.  
  70. Please ask more questions where confused.
  71. -Ken
  72.