home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / scheme / 2075 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  2.5 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!data.nas.nasa.gov!taligent!apple!voder!woodstock!news
  2. From: dyer@eagle.sharebase.com (Scot Dyer)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Re: random rant on random files
  5. Message-ID: <1992Aug21.225943.24842@sharebase.com>
  6. Date: 21 Aug 92 22:59:43 GMT
  7. References: <9208130624.1.11214@cup.portal.com> <700@data.rain.com> <TMB.92Aug18171257@arolla.idiap.ch> <704@data.rain.com> <TMB.92Aug20181314@arolla.idiap.ch>
  8. Reply-To: dyer@eagle.sharebase.com (Scot Dyer)
  9. Organization: NCR/ShareBase Corporation
  10. Lines: 47
  11. Nntp-Posting-Host: eagle
  12.  
  13. In Article 1737: (from Thomas M. Breuel)
  14. >   >What is wrong with binary streams?
  15. >
  16. >   Nothing.  But Scheme is not a store description language (like C/C++),
  17. >   and does not have a binary interface defined. [...]
  18.  
  19. >It is also trivial to build a store interface on top of binary
  20. >streams. One question is what the language should provide. I'd prefer
  21. >to see it provide binary streams, not stores, since I feel that binary
  22. >streams are more general.
  23.  
  24. In the intrest of generality, it might be a good idea to implement 'streams' as
  25. vectors of the code that should be used for various low-level operations, like
  26.         #( write-object-to-stream
  27.            read-object-from-stream
  28.            get-position
  29.            set-position
  30.            close-stream
  31.            user-slot )
  32.  
  33. On top of this 'stream' object could be built all of the functions being talked
  34. about.  I like this solution since it provides utmost generality.  A 'stream
  35. type' vector could be made to represent binary contents of memory*, another for
  36. a local file, another for a remote file, etc.  The difference would be in how
  37. the file was opened...
  38.  
  39. I'm sure that the fields listed above are incomplete and assume a more rigid
  40. model of streams than scheme really needs, but more fields could be added.
  41. Mostly this would mean adding to Scheme:
  42.  
  43.         1) A few 'open file' functions that provide the appropriate vectors.
  44.            (And therefore the low-level 'slots' or 'functions' required for
  45.            this, even if they're left anonymous)
  46.         2) An abstracted set of file manipulating functions that will work
  47.            with any of these files.
  48.         3) A constructor for new stream-type-vectors (perhaps
  49.            (stream-vector...)?)
  50.  
  51. Of course, any object-system added to scheme (if one ever comes along) should
  52. be used to implement files instead of a simple vector...
  53.  
  54. Anyway, just my $.02 cents worth.
  55.  
  56.         -- Scot
  57.  
  58. --
  59. * provided functions for converting from exprs to binary and vice versa...
  60.