home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / scheme / 2073 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  16.4 KB

  1. Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!bloom-beacon!INTERNET!dont-send-mail-to-path-lines
  2. From: postmaster@tuva.saic.COM (SMTP MAILER)
  3. Newsgroups: comp.lang.scheme
  4. Subject: Mail not delivered yet, still trying
  5. Message-ID: <9208210755.aa08011@mc.lcs.mit.edu>
  6. Date: 21 Aug 92 12:17:07 GMT
  7. Sender: daemon@athena.mit.edu (Mr Background)
  8. Organization: The Internet
  9. Lines: 456
  10.  
  11.  
  12.  ----Mail status follows----
  13. Have been unable to send your mail to <pothiers@aries>,
  14. will keep trying for a total of three days.
  15. At that time your mail will be returned.
  16.  
  17.  ----Transcript of message follows----
  18. Date: 20 Aug 92 23:37:00 PST
  19. From: scheme@mc.lcs.mit.edu
  20. Subject: Scheme Digest V4 #222
  21. To: "pothiers" <pothiers@aries>
  22.  
  23. Return-Path: <scheme-request@mc.lcs.mit.edu>
  24. Received: from martigny.ai.mit.edu by tuva.saic.com with SMTP ; 
  25.           Thu, 20 Aug 92 23:37:16 PST
  26. Received: from MC.LCS.MIT.EDU by martigny.ai.mit.edu with SMTP
  27.     (16.7/15.6) id AA21779; Fri, 21 Aug 92 02:17:43 -0400
  28. Received: by mc.lcs.mit.edu id ac05650; 21 Aug 92 1:08 EDT
  29. Received: from MC.LCS.MIT.EDU by mc.lcs.mit.edu id aa05617; 21 Aug 92 1:00 EDT
  30. X-Digestifier-Version: 2.5 
  31. Message-Id: <dig-Scheme-4.222@mc.lcs.mit.edu>
  32. Date: Fri, 21 Aug 92 00:03:40 EDT
  33. From: Automatic Scheme Digestifier <@martigny.ai.mit.edu,@mc.lcs.mit.edu:scheme-request@mc.lcs.mit.edu>
  34. Reply-To: Scheme@mc.lcs.mit.edu
  35. Subject: Scheme Digest V4 #222
  36. To: Scheme@mc.lcs.mit.edu
  37.  
  38.  
  39. Scheme Digest               Fri, 21 Aug 92       Volume 4 : Issue 222 
  40.  
  41. Today's Topics:
  42.                         Binary representation
  43.            Common Lisp is a dpANS in Public Review (3 msgs)
  44.                  random rant on random files (5 msgs)
  45.                  Scheme introduction article (2 msgs)
  46.                             scheme update
  47.                         Small Language Wanted
  48. ----------------------------------------------------------------------
  49.  
  50. Date: Thu, 20 Aug 92 17:59:20 GMT
  51. From: Technically Sweet <thinman@netcom.com>
  52. Organization: International Foundation for Internal Freedom
  53. Subject: Binary representation
  54. Message-Id: <vy#nk3h.thinman@netcom.com>
  55. In-Reply-To: <TMB.92Aug20181314@arolla.idiap.ch>
  56. To: scheme@mc.lcs.mit.edu
  57.  
  58. tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  59.  
  60. >It is also trivial to build a store interface on top of binary
  61. >streams. One question is what the language should provide. I'd prefer
  62. >to see it provide binary streams, not stores, since I feel that binary
  63. >streams are more general.
  64.  
  65. The ASN.1 for binary stream representation of trees gives
  66. most of what is needed.  It's the inter-layer encoder (sort of)
  67. for the OSI suite, and thus has that meaningless aura of 
  68. standards legitimacy which helps in promoting something
  69. new as a standard.  "Look!  It builds on previous standards!"
  70.  
  71. ASN.1 represents trees according to a pre-specified tree grammar.
  72. A simple "reference leaf" would suffice to encode arbitrary di-graphs.
  73. I think all of the other basic types of Scheme are already
  74. supported directly; there's a compact encoding for small numbers.
  75.  
  76. All in all, adopting an ASN.1 representation for Scheme gives
  77. a handy binary stream format for files, persistent Scheme systems,
  78. and network I/O.
  79.  
  80.  
  81. -- 
  82.  
  83. Lance Norskog
  84.  
  85. Data is not information is not knowledge is not wisdom.
  86.  
  87. ------------------------------
  88.  
  89. Date: Thu, 20 Aug 1992 19:27:58 GMT
  90. From: Clinton Hyde <chyde@pecos.ads.com>
  91. Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
  92. Subject: Common Lisp is a dpANS in Public Review
  93. Message-Id: <CHYDE.92Aug20142758@pecos.ads.com>
  94. Newsgroups: comp.lang.lisp,comp.lang.clos,comp.lang.misc,comp.object,comp.std.misc,comp.lang.scheme,comp.ai
  95. In-Reply-To: <16u94iINNd4i@early-bird.think.com>
  96. To: scheme@mc.lcs.mit.edu
  97.  
  98. this is cool. how about if an electronic copy (which I understand to
  99. be both Tex and DVI versions) gets into an anon-ftp site?
  100.  
  101.  -- clint
  102. --
  103.  
  104. Clint Hyde              "Give me a LispM or give me death!" -- anonymous
  105.  
  106. Advanced Decision Systems       Internet:  chyde@chesapeake.ads.com
  107. 2111 Wilson Blvd #800
  108. Arlington, VA 22201             (703) 875-0327
  109.  
  110. ------------------------------
  111.  
  112. Date: Thu, 20 Aug 1992 19:34:36 GMT
  113. From: Chuck Fry <chucko@kronos.arc.nasa.gov>
  114. Organization: Recom Technologies, NASA Ames Research Center, Moffett Field, CA
  115. Subject: Common Lisp is a dpANS in Public Review
  116. Message-Id: <1992Aug20.193436.28044@kronos.arc.nasa.gov>
  117. Newsgroups: comp.lang.lisp,comp.lang.clos,comp.lang.misc,comp.object,comp.std.misc,comp.lang.scheme,comp.ai
  118. In-Reply-To: <CHYDE.92Aug20142758@pecos.ads.com>
  119. To: scheme@mc.lcs.mit.edu
  120.  
  121. In article <CHYDE.92Aug20142758@pecos.ads.com> chyde@pecos.ads.com (Clinton Hyde) writes:
  122. >this is cool. how about if an electronic copy (which I understand to
  123. >be both Tex and DVI versions) gets into an anon-ftp site?
  124.  
  125. I was just thinking that once it becomes a standard, it should be
  126. available on CD-ROM, preferably with a KWIC index and a (reasonably)
  127. portable accessor program written in CL, and tied to the DOCUMENTATION
  128. mechanism already in the language!  Any takers?
  129.  
  130.  -- Chuck Fry  Chucko@charon.arc.nasa.gov
  131.     Chair, Lisp Users and Vendors '93 conference
  132.  
  133. ------------------------------
  134.  
  135. Date: Thu, 20 Aug 1992 22:34:45 GMT
  136. From: Clinton Hyde <chyde@pecos.ads.com>
  137. Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
  138. Subject: Common Lisp is a dpANS in Public Review
  139. Message-Id: <CHYDE.92Aug20173445@pecos.ads.com>
  140. Newsgroups: comp.lang.lisp,comp.lang.clos,comp.lang.misc,comp.object,comp.std.misc,comp.lang.scheme,comp.ai
  141. In-Reply-To: <16u94iINNd4i@early-bird.think.com>
  142. To: scheme@mc.lcs.mit.edu
  143.  
  144. I don't know about the CD-ROM part, but the rest of the idea sounds
  145. good. 
  146.  
  147. if one were to do the CD-ROM part, it should probably include beaucoup
  148. other ANSI std dox also, for many other prog languages (none of which
  149. are even half as cool as Lisp, but there are masochists who use them
  150. anyway).
  151.  
  152. what would be WAY cool is if there were a gnu-emacs texinfo file of
  153. CLtL2, the ANSI std version, etc.
  154.  
  155.  -- clint
  156. --
  157.  
  158. Clint Hyde              "Give me a LispM or give me death!" -- anonymous
  159.  
  160. Advanced Decision Systems       Internet:  chyde@chesapeake.ads.com
  161. 2111 Wilson Blvd #800
  162. Arlington, VA 22201             (703) 875-0327
  163.  
  164. ------------------------------
  165.  
  166. Date: 19 Aug 92 16:56:19 GMT
  167. From: Ken Dickey <kend@data.rain.com>
  168. Organization: Microtek DSD, Hillsboro, OR
  169. Subject: random rant on random files
  170. Message-Id: <704@data.rain.com>
  171. In-Reply-To: <TMB.92Aug18171257@arolla.idiap.ch>
  172. To: scheme@mc.lcs.mit.edu
  173.  
  174. tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  175.  
  176.  
  177. >What is wrong with binary streams?
  178.  
  179. Nothing.  But Scheme is not a store description language (like C/C++),
  180. and does not have a binary interface defined.  I have no problems with
  181. making a "location pointer" and reading memory with a port interface.  
  182. I prefer not to have to reset such a pointer at every random i/o.
  183.  
  184. It is trivial to build a port interface on top of stores.
  185.  
  186.  
  187. -Ken
  188.  
  189. ------------------------------
  190.  
  191. Date: 19 Aug 92 16:48:54 GMT
  192. From: Ken Dickey <kend@data.rain.com>
  193. Organization: Microtek DSD, Hillsboro, OR
  194. Subject: random rant on random files
  195. Message-Id: <703@data.rain.com>
  196. In-Reply-To: <16r5n0INN4n2@agate.berkeley.edu>
  197. To: scheme@mc.lcs.mit.edu
  198.  
  199. bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
  200.  
  201.  
  202. >Okay, so what do I do if I want to write a new file from scratch?
  203.  
  204. The same old way.  Open a file, write to it (as a stream), close it.
  205. The current store proposal does not address file extension.
  206.  
  207. >The part about unsigned-integers-only seems a little user-unfriendly
  208. >to me.
  209.  
  210. This is a systems programming level.  An implementation can use it
  211. to build higher-level interfaces which do representation mapping
  212. (to/from binary) for you.
  213.  
  214. >I mean, how does someone write a bignum into a store?
  215.  
  216. Well you could do (number->string) and store the bytes.  I don't think
  217. that there will be standard binary exchange representations soon
  218. (although MIT Scheme seems to do a pretty good job here).  What I want
  219. is to be able to do representation mapping that **does not depend on
  220. the underlying Scheme's representations**.  [I also do low-level
  221. systems programming, where fixed buffers are very useful (e.g. for an
  222. I/O interrupt).]
  223.  
  224. >Alternatively, maybe every primitive type has to have an unambiguous
  225. >binary representation the same as it has a print form, and instead of
  226. >explicitly mentioning types you just leave that argument out and
  227. >Scheme figures it out.  That would mean, though, tagging everything
  228. >in the store with its type.
  229.  
  230. Again, the point is to have a baseline so that this can be done in a
  231. portable manner.
  232.  
  233. >I'm feeling a little disorganized about this message, but it's because
  234. >I'm really struggling to make sense of the whole idea.  I mean, files
  235. >just feel very different from memory to me.  I know that at some level
  236. >of abstraction they're the same, but they perform quite differently.
  237. >I don't understand [I'm not being sarcastic] the principle of language
  238. >design whereby symbols and strings are treated separately but files
  239. >and memory are treated the same.
  240.  
  241. Well, it is a abstraction.  Its a bit like thinking of indexes of disk
  242. storage blocks and the blocks they reference as a continuous stream of
  243. characters called a "file", which is certainly a useful abstraction.
  244. After all, why treat disk storage blocks differently?
  245.  
  246. -Ken
  247.  
  248. ------------------------------
  249.  
  250. Date: Thu, 20 Aug 1992 15:55:11 GMT
  251. From: Aubrey Jaffer <jaffer@zurich.ai.mit.edu>
  252. Organization: M.I.T. Artificial Intelligence Lab.
  253. Subject: random rant on random files
  254. Message-Id: <JAFFER.92Aug20105511@camelot.ai.mit.edu>
  255. In-Reply-To: <1992Aug17.100735.7594@physiol.su.OZ.AU>
  256. To: scheme@mc.lcs.mit.edu
  257.  
  258. In article <1992Aug17.100735.7594@physiol.su.OZ.AU> john@physiol.su.OZ.AU (John Mackin) writes:
  259.  
  260.    In article <9208130624.1.11214@cup.portal.com>,
  261.            vanMeule@cup.portal.COM writes:
  262.  
  263.    > I feel a little upset at Scheme for lack of direct support in 
  264.    > most Schemes for random files.
  265.  
  266.    Without in any way endorsing the original poster's desire to make
  267.    Scheme into the new COBOL :):), I too was surprised and disappointed
  268.    that R4RS Scheme doesn't have a seek function to apply to ports.  I
  269.    have an application where I need to read a (large) file line-wise
  270.    backwards, and the only Scheme I can code it in at the moment is
  271.    Scheme->C where I have access to libc.
  272.  
  273. scm4a10 offers:
  274.  
  275.   (file-position <port>)                                procedure
  276.  
  277. Returns the current position of the character in <port> which will
  278. next be read or written.  If <port> is not open to a file the result
  279. is unspecified.
  280.  
  281.   (file-set-position <port> <integer>)                  procedure
  282.  
  283. Sets the current position in <port> which will next be read or
  284. written.  If <port> is not open to a file the action of
  285. file-set-position is unspecified.  The result of file-set-position is
  286. unspecified.
  287.  
  288. ------------------------------
  289.  
  290. Date: 20 Aug 92 22:13:14 GMT
  291. From: "Thomas M. Breuel" <tmb@arolla.idiap.ch>
  292. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  293. Subject: random rant on random files
  294. Message-Id: <TMB.92Aug20181314@arolla.idiap.ch>
  295. In-Reply-To: <700@data.rain.com>
  296. To: scheme@mc.lcs.mit.edu
  297.  
  298. In article <704@data.rain.com> kend@data.rain.com (Ken Dickey) writes:
  299.  
  300.    tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  301.  
  302.    >What is wrong with binary streams?
  303.  
  304.    Nothing.  But Scheme is not a store description language (like C/C++),
  305.    and does not have a binary interface defined.  I have no problems with
  306.    making a "location pointer" and reading memory with a port interface.  
  307.    I prefer not to have to reset such a pointer at every random i/o.
  308.  
  309.    It is trivial to build a port interface on top of stores.
  310.  
  311. It is also trivial to build a store interface on top of binary
  312. streams. One question is what the language should provide. I'd prefer
  313. to see it provide binary streams, not stores, since I feel that binary
  314. streams are more general.
  315.  
  316.                                 Thomas.
  317.  
  318. ------------------------------
  319.  
  320. Date: Thu, 20 Aug 92 17:52:16 GMT
  321. From: Technically Sweet <thinman@netcom.com>
  322. Organization: International Foundation for Internal Freedom
  323. Subject: random rant on random files
  324. Message-Id: <my#njwg.thinman@netcom.com>
  325. In-Reply-To: <JAFFER.92Aug20105511@camelot.ai.mit.edu>
  326. To: scheme@mc.lcs.mit.edu
  327.  
  328. jaffer@zurich.ai.mit.edu (Aubrey Jaffer) writes:
  329. >scm4a10 offers:
  330.  
  331. >  (file-set-position <port> <integer>)                 procedure
  332.  
  333. Wouldn't that be (file-position! <port> <integer>)?
  334.  
  335. Mindless consistency is a virtue in this arena.
  336.  
  337. -- 
  338.  
  339. Lance Norskog
  340.  
  341. Data is not information is not knowledge is not wisdom.
  342.  
  343. ------------------------------
  344.  
  345. Date: Thu, 20 Aug 1992 15:52:09 GMT
  346. From: Robert Goldman <rpg@cs.tulane.edu>
  347. Organization: Department of Computer Science, Tulane University
  348. Subject: Scheme introduction article
  349. Message-Id: <RPG.92Aug20095209@clones.cs.tulane.edu>
  350. To: scheme@mc.lcs.mit.edu
  351.  
  352. I am going to be teaching our AI course this semester in Scheme.
  353. I would like to make available to my students (put on reserve at the
  354. library, probably) an article which gives a short, conceptual
  355. overview of Scheme.  Preferably this should be the kind of article
  356. that might appear in CACM or Byte:  not for the layman, but not an
  357. article which discusses denotational semantics, either.  If any of
  358. you know of such an article, I would appreciate any pointers you
  359. could offer.  The LISP FAQ file has a helpful list of texts, but no
  360. overview articles.
  361.  
  362. Thanks,
  363. R
  364.  
  365. ------------------------------
  366.  
  367. Date: 20 Aug 92 15:02:30 GMT
  368. From: Robert Goldman <rpg@cs.tulane.edu>
  369. Subject: Scheme introduction article
  370. Message-Id: <2675240@aplvax.msfc.nasa.gov>
  371. To: scheme@mc.lcs.mit.edu
  372.  
  373. Nntp-Posting-Host-[nntpd-15941]: clones
  374. Message-ID: <RPG.92Aug20095209@clones.cs.tulane.edu>
  375. Sender: news@cs.tulane.edu
  376. Reply-To: rpg@cs.tulane.edu (Robert Goldman)
  377. Organization: Department of Computer Science, Tulane University
  378. Distribution: comp
  379. Date: Thu, 20 Aug 1992 15:52:09 GMT
  380. Lines: 12
  381.  
  382. I am going to be teaching our AI course this semester in Scheme.
  383. I would like to make available to my students (put on reserve at the
  384. library, probably) an article which gives a short, conceptual
  385. overview of Scheme.  Preferably this should be the kind of article
  386. that might appear in CACM or Byte:  not for the layman, but not an
  387. article which discusses denotational semantics, either.  If any of
  388. you know of such an article, I would appreciate any pointers you
  389. could offer.  The LISP FAQ file has a helpful list of texts, but no
  390. overview articles.
  391.  
  392. Thanks,
  393. R
  394.  
  395. ------------------------------
  396.  
  397. Date: Thu, 20 Aug 1992 09:19 MET
  398. From: LKS@kunrc1.urc.kun.nl
  399. Subject: scheme update
  400. To: Scheme%mc.lcs.mit.edu@mintaka.lcs.mit.edu
  401. Message-id: <01GNSSI4BQCW90NGGW@KUNRC1.URC.KUN.NL>
  402.  
  403. anyone who can tell me about an update of macscheme 2.0 or can give me
  404. the address and tel of semantic microsystems ?
  405.  
  406. Thanks,
  407.  
  408. h. pinxteren
  409.  
  410. email: lks@kunrc1.urc.kun.nl
  411.  
  412. ------------------------------
  413.  
  414. Date: 20 Aug 92 08:05:07 GMT
  415. From: Greg Wilson <gvw@epcc.ed.ac.uk>
  416. Organization: Edinburgh Parallel Computing Centre
  417. Subject: Small Language Wanted
  418. Message-Id: <41910@skye.dcs.ed.ac.uk>
  419. Newsgroups: comp.lang.misc,comp.lang.logo,comp.lang.scheme,comp.lang.forth,comp.edu
  420. To: scheme@mc.lcs.mit.edu
  421.  
  422. [apologies if this is a re-post --- problems first time around]
  423.  
  424. Hello.  I am looking for a small language to use and modify for teaching
  425. purposes.  Features I want include:
  426.  
  427. * small, simple implementation in C (at most one week for a senior
  428.   student with a C/Unix background to read and understand source).
  429.  
  430. * very simple syntax --- preferably only a single syntactic form,
  431.   like Scheme, Logo, and Forth.
  432.  
  433. * textual scoping of variables (which (sigh) rules out Logo itself)
  434.  
  435. * logical, integer, floating-point, and string data types (I'm
  436.   happy to have single characters treated as 1-length strings)
  437.  
  438. Other features that would be nice include
  439.  
  440. * objects (something simple, like Object Logo, would do --- I
  441.   regularly lambast physicists for using "old" languages like Fortran,
  442.   so I feel I should set a good example for students by using some
  443.   modern ideas myself)
  444.  
  445. * a source-language debugger
  446.  
  447. * the ability to cross-call C
  448.  
  449. Note that a compiler is not needed; performance is not a primary
  450. concern, so interpretation would be fine. 
  451.  
  452. Any help would be much appreciated.
  453.  
  454. Thanks in advance,
  455.  
  456.  ========================================================================
  457.   Gregory V. Wilson                    ||  For in much wisdom is much
  458.   Technical Coordinator                ||  grief; and he that increaseth
  459.   Edinburgh Parallel Computing Centre  ||  knowledge, increaseth sorrow.
  460.   gvw@epcc.edinburgh.ac.uk             ||               - Ecclesiastes
  461.  ========================================================================
  462.  
  463. ------------------------------
  464.  
  465. End of Scheme Digest
  466. ******************************
  467.