home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!stanford.edu!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
- From: tmb@arolla.idiap.ch (Thomas M. Breuel)
- Newsgroups: comp.lang.scheme
- Subject: Re: random rant on random files
- Message-ID: <TMB.92Aug18171257@arolla.idiap.ch>
- Date: 18 Aug 92 21:12:57 GMT
- References: <9208130624.1.11214@cup.portal.com> <700@data.rain.com>
- <16ocv6INNl87@agate.berkeley.edu> <701@data.rain.com>
- Sender: news@ai.mit.edu
- Reply-To: tmb@idiap.ch
- Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
- Perceptive)
- Lines: 23
- In-reply-to: kend@data.rain.com's message of 17 Aug 92 23:00:56 GMT
-
- In article <701@data.rain.com> kend@data.rain.com (Ken Dickey) writes:
-
- The creation operations return a "store" object. All store objects
- are treated the same. For files, the bits stay on the disk (mod
- buffering). STORE->FILE writes the contents of a store (the bits)
- into a file. [...] As stores are random, binary i/o, everything is
- mapped to positive integers. If you want to write a Scheme object
- (e.g. a vector or a negative integer, etc.) it is up to you to do
- the representation mapping.
-
- It seems to me that stores are the usual binary streams, but that you
- are required to give an offset (a "seek" address) with every
- read/write operation.
-
- Personally, I prefer the old-fashioned binary stream interface; it is
- the natural interface to things that may or may not be random access
- and that may or may not be bidirectional. Stores look too much like
- binary arrays, and, to me, the interface does not clearly reflect the
- costs of the underlying operations.
-
- What is wrong with binary streams?
-
- Thomas.
-