home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / scheme / 2054 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.4 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^4: random rant on random files
  5. Message-ID: <703@data.rain.com>
  6. Date: 19 Aug 92 16:48:54 GMT
  7. References: <700@data.rain.com> <16ocv6INNl87@agate.berkeley.edu> <701@data.rain.com> <16r5n0INN4n2@agate.berkeley.edu>
  8. Organization: Microtek DSD, Hillsboro, OR
  9. Lines: 48
  10.  
  11. bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
  12.  
  13.  
  14. >Okay, so what do I do if I want to write a new file from scratch?
  15.  
  16. The same old way.  Open a file, write to it (as a stream), close it.
  17. The current store proposal does not address file extension.
  18.  
  19. >The part about unsigned-integers-only seems a little user-unfriendly
  20. >to me.
  21.  
  22. This is a systems programming level.  An implementation can use it
  23. to build higher-level interfaces which do representation mapping
  24. (to/from binary) for you.
  25.  
  26. >I mean, how does someone write a bignum into a store?
  27.  
  28. Well you could do (number->string) and store the bytes.  I don't think
  29. that there will be standard binary exchange representations soon
  30. (although MIT Scheme seems to do a pretty good job here).  What I want
  31. is to be able to do representation mapping that **does not depend on
  32. the underlying Scheme's representations**.  [I also do low-level
  33. systems programming, where fixed buffers are very useful (e.g. for an
  34. I/O interrupt).]
  35.  
  36. >Alternatively, maybe every primitive type has to have an unambiguous
  37. >binary representation the same as it has a print form, and instead of
  38. >explicitly mentioning types you just leave that argument out and
  39. >Scheme figures it out.  That would mean, though, tagging everything
  40. >in the store with its type.
  41.  
  42. Again, the point is to have a baseline so that this can be done in a
  43. portable manner.
  44.  
  45. >I'm feeling a little disorganized about this message, but it's because
  46. >I'm really struggling to make sense of the whole idea.  I mean, files
  47. >just feel very different from memory to me.  I know that at some level
  48. >of abstraction they're the same, but they perform quite differently.
  49. >I don't understand [I'm not being sarcastic] the principle of language
  50. >design whereby symbols and strings are treated separately but files
  51. >and memory are treated the same.
  52.  
  53. Well, it is a abstraction.  Its a bit like thinking of indexes of disk
  54. storage blocks and the blocks they reference as a continuous stream of
  55. characters called a "file", which is certainly a useful abstraction.
  56. After all, why treat disk storage blocks differently?
  57.  
  58. -Ken
  59.