home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group85.txt < prev    next >
Internet Message Format  |  1988-10-29  |  43KB

  1. From rad@MITRE-BEDFORD@UDel.CSNET  Thu Jan  3 08:40:08 1985
  2. From: rad@MITRE-BEDFORD.CSNET
  3. To: ralph%arizona.csnet@CSNET-RELAY.CSNET
  4. Cc: icon-group%arizona.csnet@CSNET-RELAY.CSNET
  5. Subject: Re: Icon Newsletter #16
  6. In-Reply-To: Your message of Thursday, 27 Dec 1984 17:00-EST.
  7.              <8412272200.AA03363@arizona.UUCP>
  8. Status: R
  9.  
  10.  
  11. >Icon Newsletter #16 was sent out several weeks ago (bulk rate in the United
  12. >States).  If you are on the mailing list but have not received your copy,
  13. >let me know (and provide a postal address).
  14.  
  15.   Nope, haven't seen one yet.  I would like to receive one, though.
  16. My mail address is:
  17.  
  18.     Dick Dramstad
  19.     c/o The MITRE Corp., M/S B065
  20.     Burlington Road
  21.     Bedford, MA  01730
  22.  
  23. Thanks,
  24. Dick D.
  25. rad@mitre-bedford.arpa
  26.  
  27. From rad@MITRE-BEDFORD@UDel.CSNET  Tue Jan 15 12:38:39 1985
  28. From: rad@MITRE-BEDFORD.CSNET
  29. To: info-pyramid@MARYLAND.CSNET, Icon-Group.Arizona@CSNET-RELAY.CSNET
  30. Sender: "Dick Dramstad"@MITRE-BEDFORD.CSNET
  31. Subject: Icon ported to Pyramid?
  32. Status: R
  33.  
  34.  
  35. I'm curious as to whether anyone has ported Icon to the Pyramid 90x
  36. Unix supermini yet.  Is anyone working on it?  I'd be glad to post a
  37. recap of replies if there's enough interest.
  38.  
  39. Dick Dramstad
  40. rad@mitre-bedford.arpa
  41.  
  42. From whm  Mon Jan 21 19:08:30 1985
  43. From: whm (Bill Mitchell)
  44. To: icon-group@arizona, sun-spots@rice.CSNET
  45. Subject: Icon for the Sun Workstation
  46. Status: R
  47.  
  48. We are pleased to announce the availability of Release 5.9 of the Icon
  49. programming language for the Sun workstation.  This release of Icon is
  50. known to work on Sun's Release 1.2.  Assuming the Sun documentation is
  51. correct, Icon should also work on releases dating back as far as 0.4, but
  52. this has not been substantiated.
  53.  
  54. The Sun-specific code is an addition to our current distribution for UNIX
  55. VAXs and split I/D PDP-11s with V7; the new distribution can be configured
  56. to run on any of these three types of systems.
  57.  
  58. Icon is entirely in the public domain and complete source code for all
  59. system components is included.
  60.  
  61. To get an Icon system, please t/nroff the form below with -ms, complete it,
  62. and send it in along with a 1/2" 9-track reel tape at least 600 feet long.
  63. All tapes are written in tar format.  Please note that the only available
  64. distribution media is 1/2" reel tape; we do not have facilities to write
  65. 1/4" tape cartridges.
  66.  
  67. The only up-to-date and complete documentation of Version 5 of Icon is
  68. contained in the following book (generally referred to as "the Icon book"):
  69.  
  70.    The Icon Programming Language, Ralph E. Griswold and Madge T. Griswold.
  71.    Prentice-Hall, Inc., Englewood Cliffs, NJ.  1983.  313 pages, paperback.
  72.  
  73. This book should be available through any seller of new books.  It is
  74. not available through the University of Arizona.
  75.  
  76. There is a brief (9-page) overview of Icon available as University of
  77. Arizona technical report TR 83-3a.  This report will be sent via the Postal
  78. Service, free of charge, to anyone who requests it.
  79.  
  80. The Icon run-time system has knowledge of C stack frames and thus this
  81. version may or may not work on other 68000 systems.  I'll be circulating
  82. around the UniForum vendor show to attempt to determine what other
  83. machines this version of Icon might work on if any.
  84.  
  85. Requests for further information about Icon should be directed to:
  86.  
  87.     icon-project.arizona@csnet-relay
  88. -or-
  89.     {noao,mcnc,purdue,utah-cs}!arizona!icon-project
  90.     
  91. We try to answer all mail promptly; if you do not receive a response to
  92. your letter in a day or two, it is quite possible that a letter was lost
  93. somewhere along the line.  In such cases, please try again.
  94.  
  95.                     Bill Mitchell
  96.  
  97. Request form:
  98. =============
  99. .nr LL 6.5i
  100. .ds CF
  101. .de LE
  102. \l'3.9i'
  103. .sp 1
  104. ..
  105. .de Ip
  106. .IP "\\$1" 25
  107. .LE
  108. ..
  109. .LP
  110. .ce 1
  111. \f3Version 5.9 UNIX Icon Distribution Request\fR
  112. .sp 2
  113. \fINote:\fR This system can be configured for PDP-11s with separate I and
  114. D spaces, VAX-11s, or Sun workstations.
  115. .sp 1.5
  116. Contact Information:
  117. .sp 1
  118. .Ip name
  119. .Ip address
  120. .LE
  121. .LE
  122. .LE
  123. .Ip telephone
  124. .Ip "electronic mail address"
  125. .sp 1
  126. .Ip computer
  127. .Ip "operating system"
  128. .sp 1
  129. .LP
  130. All tapes are written in 9-track \fItar\fR format.
  131. Preferred tape recording density:
  132. .sp 1
  133. \(sq   1600 bpi\h'|1.8i'\(sq   800 bpi
  134. .sp 1.2
  135. Return this form to:
  136. .DS
  137. Icon Project
  138. Department of Computer Science
  139. The University of Arizona
  140. Tucson, AZ   85721
  141. .DE
  142. Enclose a magnetic tape (at least 600\(fm) \fIor\fR a check for $15
  143. payable to the University of Arizona.
  144.  
  145. From whm  Sun Feb  3 04:14:37 1985
  146. From: whm (Bill Mitchell)
  147. To: rad@Mitre-Bedford.CSNET
  148. Subject: Re: Icon ported to Pyramid?
  149. Cc: icon-group@Arizona, info-pyramid@Maryland.CSNET
  150. Status: R
  151.  
  152. We've had a lot of interest in Icon for the Pyramid, but we think that
  153. the current implementation can't possibly work a Pyramid due to the way
  154. that the Pyramid stack is implemented.  The basic capability that the 
  155. current implementation of Icon needs is to be able to duplicate a portion
  156. of the stack in such a way that a piece of code such as:
  157.  
  158.     f(a,b,c)
  159.     {
  160.         dupframe();
  161.         printf("a = %d, b = %d, c = %d\n",a,b,c);
  162.         return;
  163.     }
  164.  
  165. Will execute the printf twice, dupframe having duplicated the top of
  166. the stack thus causing the return to be manifested as a return from
  167. dupframe rather than from f.  (Things are lots more complicated than
  168. this, but if the above could be done, then Icon could probably be made
  169. to work.)
  170.  
  171. We're in the process of obtaining a Pyramid architecture manual to see
  172. if we can settle this question once and for all.
  173.  
  174.                     Bill Mitchell
  175. p.s.
  176. Sorry to have not replied sooner; for some reason your mail didn't get
  177. redistributed to the local Icon-Group members here at Arizona and I
  178. just happened to stumble across your note a couple of days ago.
  179.  
  180. From whm  Thu Feb 14 07:40:53 1985
  181. From: whm (Bill Mitchell)
  182. To: icon-group@arizona
  183. Subject: Sorry about...
  184. Status: R
  185.  
  186. ...this test.  Looks like we're losing messages right and left somehow.
  187.  
  188. From whm  Thu Feb 14 08:04:42 1985
  189. From: whm (Bill Mitchell)
  190. To: icon-group
  191. Subject: More testing
  192. Status: R
  193.  
  194. Still looking for the problem...
  195.  
  196. From whm  Thu Feb 14 08:35:29 1985
  197. From: whm (Bill Mitchell)
  198. To: icon-group@arizona
  199. Subject: Icon-Group mail lossage?
  200. Status: R
  201.  
  202. It looks like we may be having some mail lossage in Icon-Group; I've heard
  203. some reports of mail that we don't have any evidence of locally.
  204.  
  205. According to our records, the last five messages were:
  206.  
  207.     Dec 27    ralph@Arizona        "Icon News Letter #16"
  208.     Jan  3    rad@Mitre-Bedford    "Re: Icon News Letter #16"
  209.     Jan 15  rad@Mitre-Bedford    "Icon Ported to Pyramid?"
  210.     Jan 21    whm@Arizona        "Icon for the Sun Workstation"
  211.     Feb  3    whm@Arizona        "Re: Icon Ported to Pyramid?"
  212.  
  213. If you've sent any other messages since Dec 27, please send them again
  214. if you would, and also send a copy to me personally.
  215.  
  216. Also, if you haven't seen all of the above messages, send me a note about
  217. that as well.
  218.  
  219.                         Thanks,
  220.                         Bill Mitchell
  221.  
  222. From icon%ucbmonet@UCB-VAX@UDel.CSNET  Fri Feb 15 08:12:50 1985
  223. From: "Icon (U of Arizona" <icon%ucbmonet@UCB-VAX.CSNET>
  224. Mmdf-Warning:  Parse error in preceding line at CSNET-RELAY.ARPA
  225. To: icon-group%arizona@CSNET-RELAY.CSNET
  226. Subject: Testing...
  227. Status: R
  228.  
  229. Sorry about this test.
  230.  
  231.                 Bill Mitchell
  232.  
  233. From whm@lectura  Fri Feb 15 08:42:44 1985
  234. From: whm@lectura (Bill Mitchell)
  235. To: icon-group@arizona
  236. Subject: Even more testing
  237. Status: R
  238.  
  239. What can I say?
  240.  
  241. From ucbvax!zehntel!zinfandel!ed  Sat Feb 23 04:02:49 1985
  242. From: ucbvax!zinfandel!ed (Ed Hirgelt)
  243. Subject: Dynamic loading for Icon
  244. To: zehntel!ucbvax!arizona!icon-group
  245. Status: R
  246.  
  247. An idea: Is it reasonable? Has someone done it?
  248.  
  249. The dynamic loading feature of ld (on 4.1 and 4.2) allows the program
  250. to load a function at run-time and execute it. It is possible to build
  251. up libraries of such run-time routines and call them as needed. This
  252. lets me build a general purpose system that a user can customize by
  253. specifying his own set of procedures. 
  254.  
  255. It seems that it should be straight-forward to do this with Icon. Has
  256. anyone done this? Is it as straight-forward as I think? What are the
  257. problems I can expect to run into if I attempt this?
  258.  
  259. Thanks,
  260. Ed
  261.  
  262. ----------------------------------------------------------------
  263. Ed Hirgelt
  264. Zehntel Automation Systems
  265. 2625 Shadelands Drive
  266. Walnut Creek, Ca 94598
  267.  
  268. ihnp4!zehntel!ed
  269. decvax!sytek!zehntel!ed
  270.  
  271.  
  272. From whm  Sun Feb 24 02:18:57 1985
  273. From: whm (Bill Mitchell)
  274. To: ihnp4!zenhtel!ed
  275. Subject: Re:  Dynamic loading for Icon
  276. Cc: icon-group
  277. Status: R
  278.  
  279. There are essentially two problems with dynamic loading:
  280.  
  281.     Where in memory are the functions going to go?  Icon uses a
  282.      compacting garbage collector and has no provision for non-
  283.      relocatable items in the heap.  A cheap way around this would
  284.      be to just grab a block of memory that lies before the
  285.      co-expression stacks.  A more elaborate scheme would involve
  286.      adding a general way to allocate non-relocatable memory at
  287.      run-time.
  288.  
  289.     How are the functions going to be invoked?  Currently, builtin
  290.      functions and Icon procedures are represented by global variables
  291.      which reference a procedure block that contains pertinent
  292.      information about the function.  The globals are stored in an
  293.      array, so adding a global would mean expanding the array.  Again,
  294.      this can be hacked by just having some extra space in the global
  295.      array.  An additional problem is actually referencing the global
  296.      variable that names a newly-loaded procedure.  The linker has
  297.      knowledge of all the possible function names, so it turns a
  298.      reference to a global variable into a reference into the global
  299.      variable array.  You'd need a way to reference newly-loaded
  300.      globals.
  301.      
  302. If you're willing to specify functions to load at translation time, the
  303. (now-defunct) compiler's "external" keyword could be reintroduced and you
  304. could load the functions and layout the global array as part of the
  305. initialization phase of the interpreter.
  306.  
  307. A project that I did about a year ago, which was the incorporation of Icon
  308. as a subsystem in Unipress Emacs as sort of a sibling of MLisp, solved
  309. the above problems and allowed one to load Icon procedures dynamically.
  310. I think it would be fairly trivial to augment this system to load C
  311. functions dynamically.
  312.  
  313. The current interface is via "load(f)", which loads the interpretable
  314. file named by f, incorporating the definitions f contains for globals,
  315. records, and Icon procedures.  To make this work for C, load could be
  316. modified to look at f and determine if it is an interpretable file or
  317. a C object file.  If a C object file, just link against the interpreter
  318. and load the result.  Hmmm, that sounds so easy I might just do it.
  319.  
  320. Report TR 84-8 describes the system alluded to above; we can send you
  321. a copy of the report if you'd like.
  322.  
  323.                     Bill Mitchell
  324. p.s. for everybody:
  325. It looks like I've fixed the distribution problems I mentioned several
  326. days ago.  If you *didn't* receive the message this note is a response
  327. to, please let me know.  Thanks.
  328.  
  329. From G.TI.DAK@UTEXAS-20@UDel.CSNET  Fri Mar  8 07:41:56 1985
  330. From: G.TI.DAK@UTEXAS-20.CSNET
  331. Subject: Please drop
  332. To: icon-group%arizona.csnet@CSNET-RELAY.CSNET
  333. Status: R
  334.  
  335.     Please drop G.TI.DAK@Utexas from you mail distribution
  336. -------
  337.  
  338. From ralph  Wed Mar 20 07:06:24 1985
  339. From: ralph (Ralph Griswold)
  340. To: icon-group@arizona
  341. Subject: Icon Newsletter #17
  342. Status: R
  343.  
  344.  
  345. Icon Newsletter #17 is in the mail.  Bulk rate is used for addresses in
  346. the United States, so it may take a couple of weeks to get to everyone.
  347.  
  348. There is an error on the form in the Newsletter for requesting Version
  349. 5.9 of Icon for VAX/VMS -- it says tapes are written in tar format.
  350. In fact, they are written in VMS COPY format.
  351.  
  352.  
  353. From ralph@bocklin  Wed Aug 21 21:01:24 1985
  354. From: ralph@bocklin (Ralph Griswold)
  355. To: icon-group@arizona
  356. Subject: Next Icon Newsletter
  357. Status: R
  358.  
  359. We are in the process of assembling the next Icon Newsletter.
  360.  
  361. If you have something to contribute, a suggestion, or whatever,
  362. let me know.  Possibilities are comments on language features,
  363. experiences using Icon, applications, suggestions for
  364. the Programming Corner, and such.
  365.  
  366.     ralph.arizona@csnet-relay
  367.  
  368. From gudeman@bocklin  Thu Aug 22 18:51:03 1985
  369. From: gudeman@bocklin (David Gudeman)
  370. To: icon-group@az
  371. Subject: condition-at-end loops
  372. Status: R
  373.  
  374. Many programming languages have loops which do the test at the
  375. end of the loop instead of the beginning (i.e., do-while loop
  376. in C, repeat-until loop in Pascal).  Although this structure is
  377. useful, (I won't argue *how* useful), it doesn't exist directly
  378. in Icon.  If the Icon programmer wants such a construction, there
  379. are two choices, the first one (boring) is to use a repeat loop
  380. and insert an if at the end
  381.  
  382.     repeat {
  383.         <body of loop>
  384.         if <condition> then break
  385.         }
  386.  
  387. The other possibility takes advantage of Icon's expression structure,
  388. specifically the fact that {expr1; ...; exprn} returns the result
  389. sequence of exprn as its value (see TIPL page 80), so you can write
  390.  
  391.     while {
  392.         <body of loop>
  393.         <condition>
  394.         }
  395.  
  396. Obviously, it would work just as well to write
  397.  
  398.     until {
  399.         <body of loop>
  400.         not <condition>
  401.         }
  402.  
  403. This suggests an expression of the form
  404.  
  405.     every {
  406.         <body of loop>
  407.         <generator>
  408.         }
  409.  
  410. in which the generator would produce some sequence of results,
  411. but before each result, the body is executed.  This does not
  412. work. (why not?)
  413.  
  414. What structure will do what I wanted this one to do?
  415.  
  416. From mark@bocklin  Fri Aug 23 11:57:13 1985
  417. From: mark@bocklin (Mark Langley)
  418. To: icon-group@arizona
  419. Subject: Controll Flow Discussion.
  420. Cc: icon@bocklin
  421. Status: R
  422.  
  423. This is the summary of a recent mail discussion on which
  424. we would like to get feedback from the outside world.  The
  425. subject is control flow.  
  426.  
  427. >From mark Wed Aug 21 15:53:00 1985
  428. Subject: Stumper...
  429.        
  430.        Here is a (broke) baroque program. It uses only backtracking
  431.        for control.  And was an experiment to see if you could actually
  432.     write a program which did something 'procedural' without
  433.     ALGOL like control structures.
  434.        
  435.        procedure main()
  436.        tab := "\t"
  437.        words := lines := chars := 0
  438.        alphas := blanks := 0
  439.        
  440.            (c := getc()) &                     (1)
  441.                (chars +:= 1) &                 (2)
  442.                (((c == "\n") & (lines +:= 1)) | 1) &        (3)
  443.            ((alpha(c) & (alphas +:= 1)) | 1) &        (4)
  444.            ((white(c) & (alphas := 0)) | 1) &        (5)
  445.            (((alphas = 1) & (words +:= 1)) \ 1 ) &        (6)
  446.            &fail
  447.        
  448.        end
  449.    
  450. (janalee)
  451.    the problem with using only backtracking is that what takes you
  452.    forward also takes you back. (?)
  453.    
  454.    well, to be specific, you have used alternation to drive expression
  455.    evaluation forward when necessary. for example, on the first letter
  456.    of a file, the part of the expression labeled (5) will fail in white(),
  457.    but the alternation takes evaluation forward to (6) and thus words
  458.    is incremented. now the whole thing is forced to fail, which drives
  459.    us back, but not back far enough.  note that since (4) succeeded in
  460.    alpha(), we still have the alternative of 1 left; so forward it
  461.    goes, through (5) again and unfortunately to (6). hence the double
  462.    word count.
  463.    
  464.    you used alternation in (4) because you need to go forward to
  465.    recognize white space when something is not an alpha.
  466.    maybe you chose the wrong alternative...
  467.    
  468.    
  469. (mark)
  470. Very Good.  So I need to limit the results of (4) and (5) (... \ 1)
  471. I forgot that it would just try again... I really 'meant' to say
  472. something like here is a side-effect, keep going, and don't interfere
  473. with the backtracker...
  474.  
  475.  
  476. I guess, with all the seque stuff, you have given a lot of thought
  477. to the sort of thing which motivated this in the first place.  Namely,
  478. what does one really *need* to make minimum control structures 
  479. which are both necessary and sufficient to express the algorithmic
  480. conception.  
  481.  
  482. The problem, as I see it, is what control should be imbedded in
  483. explicit syntax and what in mechanisms like goal direction.  I guess
  484. I am groping for a common denominator between the two...  The above
  485. kind of problem is inherent in a language like prolog where the
  486. backtracking semantics are really all you have...
  487.  
  488. Any thoughts?  Anyone?
  489.  
  490.     
  491. (sbw)
  492.  
  493. well, i know you can get by with:
  494.  
  495.    goal-directed evaluation, alternation, repeated evaluation, and
  496.    limitation, if you also have &fail, &null, and conjunction.
  497.    though it's a little like trying to do all math using only
  498.    Peano's Postulates.  (you might try to get an if-then-else
  499.    control structure out of the above).
  500.  
  501. (mark)
  502. Yea, you're right, it is a kind of Turing Tarpit, where everything
  503. is possible, but nothing easy.  I guess what I would like is for the
  504. language environment to try to figure out which expression it should
  505. evaluate next (!).  Namely, if it could figure out which expressions
  506. where *blocked* and which could possibly produce a result... Kind
  507. of like the way the UNIX kernel figures out which processes to schedule...
  508. First check to see if it is waiting for something, then try it.
  509.  
  510. It seems like it be kind of like the way backward chained rule
  511. systems work (Gag Ack)... Namely, you determine if there is a goal
  512. to be satisfied, and what states (recursively) must be satisfied 
  513. first.  There are a lot of analogs to reaching definitions in
  514. compiler theory, too...
  515.  
  516. The neat thing about this is that you wouldn't have to specify
  517. what order things get evaluated in, the language would figure that
  518. out.  All you have to specify is how to get back to a stable-state...
  519. As such this turns the notion of an algorithm on its head!  The
  520. way you would think about programming would be:
  521.     imagine a stable state.
  522.     How do you correct if you get away from it.
  523.  
  524. The looming problem with this is whether this makes the process
  525. harder or easier!  Namely, do you have to go back and think
  526. of a normal algorithm and then factor out the control, or
  527. do you think (really) in the two-stepper above.
  528.  
  529. This is kind of an hallucinogen.  Please kibitz!
  530.  
  531.         .
  532.         .
  533.     
  534.   (sbw)
  535.     Hey, this is neat stuff.  How about giving me an example of a
  536.   steady state program to mull over (i'm from the days when everyone
  537.   still liked von Neumann).  I've diddled with prolog a bit, so if
  538.   that's what you mean...  i've always wanted an icon machine where
  539.   every expression was on a separate processor, anyway.
  540.  
  541. (mark)
  542. Ok.  What I originally had in mind was those class of programs which
  543. are typically stated as an infinite loop.  Process control, operating
  544. system kernels etc.  What the task involves then is essentially
  545. handling exceptions.  Or, from another perspective, perhaps the
  546. loop-and-a-half problem, or the use of 'break' in C is not an
  547. artifact of sloppy coding, but is essential to algorithmic conception.
  548.  
  549. The particular program I had in mind was a rule based expert system
  550. which does airplane navigation.  What I would have *liked* it to
  551. look like was a series of exceptions which get called when they
  552. are needed.  For example
  553.     on time % 30 seconds == zero
  554.       do a navigation update
  555.     on A & B
  556.        ...
  557.       Assert C
  558.        ...
  559.     on C
  560.        ...
  561. Thus I could have a general method for scheduling tasks, some
  562. of which need to be done all the time, and some of which need only
  563. be done when something special happens.  
  564.  
  565. (Note that this looks a lot like a (Blech) Rule Base.)
  566.  
  567. One of the problems with the above beasts (Rule Bases) -- (Note
  568. how you want to touch them when they're safely behind parens)--
  569. is some kind of intuitive inference structure such that you 
  570. can specify what you want to do and determine the order it will
  571. get done in.  Namely, one is hard pressed to find a rule base
  572. which, by itself, has even the conceptual power of simple fortran.
  573. Furthermore, rules are 'write only.'  If the knowledge base does
  574. anything interesting, it becomes highly intractable.  Cf
  575. debugging a grammar to debugging a program...
  576.  
  577. And Presto, two problems (ie knowledge programming and
  578. control structures for programming language) are the same problem.
  579.  
  580. Yes?
  581.  
  582. PLEASE COMMENT!  -- Thanks -- mark
  583.  
  584. From rogerh  Fri Aug 23 13:47:48 1985
  585. From: rogerh (Roger Hayes)
  586. To: icon-group
  587. Subject: Re: Controll Flow Discussion.
  588. Newsgroups: fcs.icon-group
  589. In-Reply-To: <302@bocklin.UUCP>
  590. Organization: University of Arizona, Tucson
  591. Cc: 
  592. Status: R
  593.  
  594. Another neat way to think of specifying the behavior of a computer 
  595. is by using "constraint langauges".
  596.  
  597. The original of these was Sketchpad [Sutherland, mid-60's, not yet
  598. surpassed].  Another is Bertrand [Wm Leler, U. of N. Carolina + Tektronix --
  599. I have a report somewhere].  
  600.  
  601. The idea is that the programmer specifies what conditions are to
  602. be maintained, and the system figures out how to maintain them.
  603. The actual constraint satisfaction is a little like attribute
  604. computation in attribute grammars.  For example, you can tell 
  605. Bertrand
  606.     a = 4 + c
  607.     b = 2 * a
  608.     c = a + b
  609. and ask it for any of a, b, or c.  It actually precomputes how to
  610. satisfy constraints -- it doesn't do any backtracking; it just flows
  611. information forward as far as it can.  This works surprisingly well.
  612.  
  613. Things that (at last check) Wm Leler is still puzzling over are:
  614.     How to handle ephemeral data -- this ties in with Mark's 
  615. navagation problem, process control, graphics
  616.     How to make it an online system -- at present, it's static;
  617. you submit the constraints, they are compiled, and the result pops out.
  618.  
  619. From kwalker@bocklin  Fri Aug 23 15:21:12 1985
  620. From: kwalker@bocklin (Kenneth Walker)
  621. To: gudeman@bocklin
  622. Subject: Re:  condition-at-end loops
  623. Cc: icon-group@arizona
  624. Status: R
  625.  
  626.     From gudeman Fri Aug 23 15:02:29 1985
  627.     Received: by bocklin.arizona.uucp (4.12/3.14)
  628.         id AA24880; Fri, 23 Aug 85 15:02:26 mst
  629.     Date: Fri, 23 Aug 85 15:02:26 mst
  630.     From: gudeman (David Gudeman)
  631.     Message-Id: <8508232202.AA24880@bocklin.arizona.uucp>
  632.     To: kwalker
  633.     Subject: condition-at-end loops
  634.  
  635.         ...
  636.  
  637.     This suggests an expression of the form
  638.     
  639.         every {
  640.             <body of loop>
  641.             <generator>
  642.             }
  643.     
  644.     in which the generator would produce some sequence of results,
  645.     but before each result, the body is executed.  This does not
  646.     work. (why not?)
  647.     
  648.     What structure will do what I wanted this one to do?
  649.     
  650. This does not work because only the generator is resumed on each iteration.
  651. One solution is as follows:
  652.  
  653.     every (&null | <generator>) &
  654.       {<body of loop>; &null}
  655.  
  656. The generator is skipped on the first iteration so the body of the loop is
  657. executed fisrt. On resumption, the second &null fails to produce another 
  658. value, then the 1st &null fails to produce another value, so the generator is
  659. tried. If the generator succeeds, the body of the loop is evaluated again.
  660. The generator continues to be resumed and the body of the loop evaluated 
  661. until the generator fails.
  662.  
  663. Does anyone have a more elegant solution?
  664.  
  665. From sbw@bocklin  Mon Aug 26 10:13:25 1985
  666. From: sbw@bocklin (Steve Wampler)
  667. To: gudeman@bocklin, kwalker@bocklin
  668. Subject: Re:  condition-at-end loops
  669. Cc: icon-group@arizona
  670. Status: R
  671.  
  672.     From kwalker@bocklin Fri Aug 23 15:21:27 1985
  673.     Received: from arizona.uucp (arizona.ARPA) by bocklin.arizona.uucp (4.12/3.14)
  674.         id AA25464; Fri, 23 Aug 85 15:21:12 mst
  675.     Received: from bocklin.arizona.uucp (bocklin.ARPA) by arizona.uucp (4.12/3.14)
  676.         id AA04433; Fri, 23 Aug 85 15:22:14 mst
  677.     Received: by bocklin.arizona.uucp (4.12/3.14)
  678.         id AA25456; Fri, 23 Aug 85 15:21:02 mst
  679.     Date: Fri, 23 Aug 85 15:21:02 mst
  680.     From: kwalker@bocklin (Kenneth Walker)
  681.     Message-Id: <8508232221.AA25456@bocklin.arizona.uucp>
  682.     To: gudeman@bocklin
  683.     Subject: Re:  condition-at-end loops
  684.     Cc: icon-group@arizona
  685.     
  686.         From gudeman Fri Aug 23 15:02:29 1985
  687.         Received: by bocklin.arizona.uucp (4.12/3.14)
  688.             id AA24880; Fri, 23 Aug 85 15:02:26 mst
  689.         Date: Fri, 23 Aug 85 15:02:26 mst
  690.         From: gudeman (David Gudeman)
  691.         Message-Id: <8508232202.AA24880@bocklin.arizona.uucp>
  692.         To: kwalker
  693.         Subject: condition-at-end loops
  694.     
  695.             ...
  696.     
  697.         This suggests an expression of the form
  698.         
  699.             every {
  700.                 <body of loop>
  701.                 <generator>
  702.                 }
  703.         
  704.         in which the generator would produce some sequence of results,
  705.         but before each result, the body is executed.  This does not
  706.         work. (why not?)
  707.         
  708.         What structure will do what I wanted this one to do?
  709.         
  710.     This does not work because only the generator is resumed on each iteration.
  711.     One solution is as follows:
  712.     
  713.         every (&null | <generator>) &
  714.           {<body of loop>; &null}
  715.     
  716.     The generator is skipped on the first iteration so the body of the loop is
  717.     executed fisrt. On resumption, the second &null fails to produce another 
  718.     value, then the 1st &null fails to produce another value, so the generator is
  719.     tried. If the generator succeeds, the body of the loop is evaluated again.
  720.     The generator continues to be resumed and the body of the loop evaluated 
  721.     until the generator fails.
  722.     
  723.     Does anyone have a more elegant solution?
  724.     
  725. how about:
  726.  
  727.     every (&null | <generator>) & (<body of loop> \ 1)
  728.  
  729.  
  730. From gudeman@bocklin  Thu Aug 29 13:21:09 1985
  731. From: gudeman@bocklin (David Gudeman)
  732. To: icon-group@arizona
  733. Subject: Re: condition-at-end loops
  734. Status: R
  735.  
  736. >>>From gudeman Fri Aug 23 15:02:29 1985
  737. >>>    every {
  738. >>>        <body of loop>
  739. >>>        <generator>
  740. >>>        }
  741. >>>
  742. >>>What structure will do what I wanted this one to do?
  743.  
  744. >>From kwalker@bocklin Fri Aug 23 15:21:27 1985
  745. >>    every (&null | <generator>) &
  746. >>      {<body of loop>; &null}
  747.  
  748. >From sbw Mon Aug 26 10:13:17 1985
  749. >    every (&null | <generator>) & (<body of loop> \ 1)
  750.  
  751. What's wrong with "do"?  As long as you're going to cheat by
  752. having a fake value generated, you may as well use
  753.  
  754.     every &null | <generator> do <body of loop>
  755.  
  756. I don't want everyone to get the idea that I may be a little
  757. miffed about Ken Walker's solution, just because I thought
  758. co-expressions were needed.  Especially when he showed me
  759. his first draft of the solution, and I said it wouldn't work.
  760.  
  761.     (&null | <generator>) & {<body of loop>; &fail}
  762.  
  763. I chuckled knowingly and told him to try it, he did and it
  764. works.  But I can take it like a man.  The problem, as I
  765. saw it, was that you wanted parallel evaluation, which is
  766. hard to get in Icon.  Ken observed that there is no resumption
  767. of <body of program>, just re-evaluation.  Of course, by the
  768. very nature of Icon evaluation, the second argument is
  769. re-evaluated when the first is resumed.  Humph.  I still
  770. say it's cheating.<insert petulant scowl>
  771.  
  772.                     David Gudeman
  773.  
  774. From ralph@bocklin  Fri Sep 13 18:26:02 1985
  775. From: ralph@bocklin (Ralph Griswold)
  776. To: icon-group@arizona
  777. Subject: Version 5.10 of Icon for UNIX Systems
  778. Status: R
  779.  
  780. Version 5.10 of Icon for UNIX systems is now available for distribution.
  781. This distribution can be configured to run on the AT&T 3B20, the PDP-11,
  782. the Ridge 32, the Sun Workstation, and the VAX-11.
  783.  
  784. The main features of this version are:
  785.  
  786.         New options for sorting tables that require less space.
  787.  
  788.     Faster execution than Version 5.9.
  789.  
  790.     Several bug fixes.
  791.  
  792.     Reorganization of the code to make porting easier.
  793.  
  794. Version 5.10 of Icon is in the public domain.  Program material and
  795. documentation is provided without charge.  To obtain a copy, format the
  796. t/nroff text following the dashed line using -ms and mail it to us
  797. as indicated.
  798. --------------------------------------------------------------------
  799. .nr LL 6.5i
  800. .ds CF
  801. .de LE
  802. \l'3.9i'
  803. .sp 1
  804. ..
  805. .de Ip
  806. .sp -1
  807. .IP "\\$1" 25
  808. .LE
  809. ..
  810. .LP
  811. .ce 1
  812. \f3Request for Version 5.10 of Icon for UNIX\fR
  813. .sp 1
  814. .LP
  815. This implementation can be configured to run on the AT&T 3B20,
  816. the PDP-11, the Ridge 32, the Sun Workstation, and the VAX-11.
  817. The distribution package contains a brief description of Icon,
  818. installation instructions, and supporting documentation. Documentation
  819. regarding the porting of Icon to other computers is optional and
  820. is supplied only if requested below.
  821. .sp 1
  822. .Ip name
  823. .Ip address
  824. .LE
  825. .LE
  826. .LE
  827. .Ip telephone
  828. .Ip "electronic mail address"
  829. .sp 1
  830. .Ip computers
  831. .Ip "operating systems"
  832. .sp 1
  833. .LP
  834. Tapes are written in 9-track \fIcpio\fR or \fItar\fR format.
  835. Specify preferred format and tape recording density:
  836. .sp .8
  837. .in .5i
  838. \(sq   cpio\h'|1.5i'\(sq   tar
  839. .sp .5
  840. \(sq   6250 bpi\h'|1.5i'\(sq   1600 bpi\h'|3i'\(sq   800 bpi
  841. .sp .8
  842. .in 0
  843. \(sq   Enclose documentation on porting Icon to other computers.
  844. .sp .8
  845. Send this form, together with a magnetic tape (600\(fm is sufficient)
  846. \fIor\fR a check for $20 payable to the University of Arizona, to:
  847. .DS
  848. .ft R
  849. Icon Project
  850. Department of Computer Science
  851. The University of Arizona
  852. Tucson, AZ   85721
  853. .DE
  854.  
  855. From J.Dalton%edxa@UCL-CS@UDel  Tue Sep 24 18:37:30 1985
  856. From: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@UCL-CS>
  857. To: "icon-group.arizona" <icon-group.arizona%csnet-relay.arpa%cs.ucl.ac.uk@UCL-CS>,
  858.         J.Dalton%edxa@UCL-CS
  859. Subject:     address change
  860. Status: R
  861.  
  862. --------
  863.  
  864. Because of certain changes in Edinburgh, my network mail address
  865. will become invalid at the end of the week.  My new address is just
  866. like the old, except that "edxa" must be replaced by "uk.ac.edinburgh".
  867. Thus, my new address is
  868.     j.dalton%uk.ac.edinburgh@ucl-cs
  869.  
  870. Please change your address list; the new address should already
  871. be valid.
  872.  
  873. Cheers,
  874. Jeff Dalton, AIAI, University of Edinburgh
  875.  
  876. sent on 24 Sep 85
  877.  
  878.  
  879. --------
  880.  
  881.  
  882. From ralph@bocklin  Mon Sep 30 16:39:14 1985
  883. From: ralph@bocklin (Ralph Griswold)
  884. To: icon-group@arizona
  885. Subject: Version 5.9 of Icon for MS-DOS
  886. Status: R
  887.  
  888. An implementation of Version 5.9 of Icon for MS-DOS has been completed by
  889. Cheyenne Wills of Mechanicsburg, Pennsylvania.  This implementation requires
  890. MS- or PC-DOS Version 2.0 or higher and has been tested on a number of
  891. computers, including the IBM PC, XT, and AT.  It should run on any computer
  892. with an 8086/88/186/286-family processor; IBM hardware compatibility is not
  893. required.
  894.  
  895. This is a small memory model implementation, using only two segments.
  896. As a result, the amount of space for Icon programs and data is limited.
  897. Nevertheless, many useful programs run quite well and this implementation
  898. offers many persons the opportunity to use Icon who otherwise could not.
  899.  
  900. This implementation is in the public domain.  We are distributing copies
  901. for the cost of media, handling, and shipping. To obtain a copy, format
  902. the t/nroff text following the dashed line using -ms and mail it to us
  903. with payment as indicated.
  904. --------------------------------------------------------------------
  905. .nr LL 6.5i
  906. .ds CF
  907. .ds RF \s8\*(DY\s0
  908. .de LE
  909. \l'3.9i'
  910. .sp 1
  911. ..
  912. .de Ip
  913. .IP "\\$1" 25
  914. .LE
  915. ..
  916. .LP
  917. \0
  918. .br
  919. .sp 3
  920. .ce 1
  921. \f3Request for Version 5.9 of Icon for MS-DOS\fR
  922. .sp 2
  923. .LP
  924. This system is distributed on a 5-1/4\(fm\(fm 2S/2D diskette.
  925. Enclose a check for $15 payable to the University of Arizona to
  926. cover the costs of media, handling, and shipping.
  927. .sp 2
  928. Ship to:
  929. .sp 1
  930. .Ip name
  931. .Ip address
  932. .LE
  933. .LE
  934. .LE
  935. .Ip telephone
  936. .Ip "electronic mail address"
  937. .sp 3
  938. .LP
  939. Return this form with payment to:
  940. .DS
  941. Icon Project
  942. Department of Computer Science
  943. The University of Arizona
  944. Tucson, AZ   85721
  945. .DE
  946.  
  947. From ralph@bocklin  Sat Nov 30 06:35:40 1985
  948. From: ralph@bocklin (Ralph Griswold)
  949. To: icon-group@arizona
  950. Subject: Icon Newsletter #19
  951. Status: R
  952.  
  953.  
  954.  
  955. Icon Newsletter #19 was mailed (bulk rate in the U.S.) early
  956. in October.  If you haven't received your copy, presume it
  957. lost and send me a US mailing address for a replcement.
  958.  
  959.     Ralph Griswold
  960.     arizona%ralph@csnet-relay
  961.  
  962. From sbw@bocklin  Sun Dec 15 19:07:12 1985
  963. From: sbw@bocklin (Steve Wampler)
  964. To: icon-group@arizona
  965. Status: R
  966.  
  967. I came across the following little ditty while cleaning out my files
  968. and thought people might like to play with it...
  969.  
  970. The following is an Icon program to ngram analysis of text to develop
  971. a 'profile' of an author's style.  It then produces randomly generated
  972. text in the same style.  There are a number of sources of information
  973. on ngram analysis and the problem is well studied.  To my mind,
  974. no language offers a 'cleaner' solution than Icon.
  975.  
  976. ----ngrams.icn----
  977. # the old million monkeys problem...
  978. #
  979. #    the program uses ngram analysis to randomly generate text
  980. #    in the same 'style' as the input text.  arguments are:
  981. #
  982. #        -s      {show the input text}
  983. #        -n n    {use 'n' as the ngram size (default:4)}
  984. #        -l n    {output at most 'n' lines (default:10)}}
  985. #        -r n    {set random number seed to n}
  986.  
  987. global showtxt
  988.  
  989. procedure main(args)
  990.  
  991.    n := 4
  992.    linecount := 10
  993.  
  994.    nextarg := create !args
  995.    while arg := @nextarg do
  996.       case arg of {
  997.          "-s" : showtxt := "yes"
  998.          "-n" : n := integer(@nextarg)
  999.          "-l" : linecount := integer(@nextarg)
  1000.          "-r" : &random := integer(@nextarg)
  1001.          }
  1002.  
  1003.    ngrams := table()
  1004.  
  1005.    Show("Orginal Text is: \n\n")
  1006.  
  1007.    preline := ""
  1008.    every line := preline || !&input do {
  1009.       line ? {
  1010.             while ngram := move(n) & nextchar := move(1) do {
  1011.                /firstngram := Show(ngram)
  1012.                /ngrams[ngram] := ""
  1013.                ngrams[ngram] ||:= Show(nextchar)
  1014.                move(-n)
  1015.                }
  1016.             preline := tab(0) || "\n"
  1017.             }
  1018.       }
  1019.  
  1020.    Show("\n\nGenerating Sentences\n\n")
  1021.  
  1022.    ngram := writes(firstngram)
  1023.    while linecount > 0 do {
  1024.       if /ngrams[ngram] then
  1025.          stop()                 # if hit EOF ngram early
  1026.       ngram := ngram[2:0]||writes(nextchar:=?ngrams[ngram])
  1027.       if (nextchar == "\n") then
  1028.          linecount -:= 1
  1029.       }
  1030.  
  1031. end
  1032.  
  1033.  
  1034. procedure Show(text)
  1035.    if \showtxt then writes(text)
  1036.    return text
  1037. end
  1038. ----end of ngrams.icn----
  1039.  
  1040. sample output of the program follows.
  1041.  
  1042. First the source text:
  1043. ----ngram.dat-----
  1044. If Youth, throughout all history, had had a champion to
  1045. stand up for it; to show a doubting world that a child
  1046. can think; and, possibly, do it practically; you wouldn't
  1047. constantly run across folks today who claim that "a child
  1048. don't know anything."  A child's brain starts functioning
  1049. at birth; and has, amongst its many infant convolutions,
  1050. thousands of dormant atoms, into which God has put a mystic
  1051. possibility for noticing an adult's act, and figuring out
  1052. its purport.
  1053.  
  1054. Up to about its primary school days a child thinks, naturally,
  1055. only of play.  But many a form of play contains disciplinary
  1056. factors.  "You can't do this," or "that puts you out," shows
  1057. a child that it must think, practically, or fail.  Now, if,
  1058. throughout childhood, a brain has no opposition, it is plain
  1059. that it will attain a position of "status quo," as with our
  1060. ordinary animals.  Man knows not why a cow, dog or lion was not
  1061. born with a brain on a par with ours; why such animals cannot
  1062. add, subtract, or obtain from books and schooling, that paramount
  1063. position which Man holds today.
  1064.  
  1065.   -- The first two paragraphs of the novel "GADSBY", written
  1066.     by Ernest Wright (1939).  GADSBY is unique in that the
  1067.     story consists of over 50,000 words, yet never uses the
  1068.     letter 'E'.
  1069. ----end of ngram.dat---
  1070.  
  1071. Now, three different analyses, for 2grams, 4grams, and 7grams.
  1072.  
  1073. ---2 gram output---
  1074. If primanin at cals.  -- The
  1075.   links of You of the it pary
  1076. factionly,
  1077. ory runimannows this a folks a fol ding or was thatten
  1078. that playsticho obtractod toms, doughout
  1079. ad thaturs; a chin outs novel dongstichinstaing anythild's do ch of obtion't brampion wo cally; a plainfantand that th; wrinaturposs out," subticals nary Ernest pary sciplain whooks throssits nows
  1080. ad hatten
  1081.   "th of do ormally, whistat not
  1082. ithas an to a by suchinar 50,00 wildn't
  1083. add, plithinat Writ ching." sciplaim the
  1084. ---4 gram output---
  1085. If Youth, throughout a child thinks, naturally,
  1086. only of the novel "GADSBY is plain
  1087. that a mystic
  1088. possibility for it; to about childhood, a brain starts functions,
  1089. throughout child
  1090. can that a child
  1091. can that puts you wouldn't
  1092. consists of over uses the novel "GADSBY is play.  But many infant convolution was not
  1093. add, subtractically, dog or fail.  Now, dog or obtain has purport.
  1094.  
  1095. ---7 gram output---
  1096. If Youth, throughout childhood, a brain has no opposition of "status quo," as with ours; why such animals.  Man knows not why a cow, dog or lion was not
  1097. born with a brain has no opposition, it is plain
  1098. that it must think, practically; you wouldn't
  1099. constantly run across folks today who claim that "a child thinks, naturally,
  1100. only of play contains disciplinary
  1101. factors.  "You can't do this," or "that puts you out," shows
  1102. a child that it will attain a position, it is plain
  1103. that it will attain a position which Man holds today.
  1104.  
  1105.   -- The first two paragraphs of the novel "GADSBY", written
  1106. ---end of sample runs---
  1107.  
  1108.  
  1109. The program is fun to run on MS-DOS icon, as it becomes obvious
  1110. whenever the garbage collector kicks in.
  1111.  
  1112. Some open questions:
  1113.  
  1114.   The program is very memory intensive, can that be improved,
  1115.   or does the problem inherently require tons of memory?
  1116.  
  1117.   The program is very weak on handling the last few characters
  1118.   of the text file.  Can anyone suggest some improvements?
  1119.  
  1120.      -Steve Wampler
  1121.  
  1122. From root@arizona  Sun Dec 22 02:24:36 1985
  1123. From: root@arizona (Charlie Root)
  1124. To: icon-group@arizona, sbw@arizona
  1125. Subject: uucp mail delay at arizona
  1126. Status: R
  1127.  
  1128.  
  1129. During the period 12/15 to Dec. 12/21, a condition existed
  1130.  on the system 'arizona' that caused unreliable delivery of
  1131.  outgoing mail sent via uucp.  It is believed that, fortunately,
  1132.  all mail that was not delivered properly, in addition to some that
  1133.  was delivered properly, accumulated in one of the uucp spool
  1134.  directories.  Each of these such messages has been remailed
  1135.  to the intended recipient and the following message is one
  1136.  of them.
  1137.  
  1138. As mentioned above, it is believed that no mail was lost, but
  1139.  it is probably advisable to "resynchronize" with any
  1140.  correspondents that you have been communicating with via
  1141.  'arizona'.
  1142.  
  1143. We sincerely apologize for this problem.
  1144.  
  1145. Please mail to arizona!lab if you have any questions.
  1146.  
  1147.         Bill Mitchell
  1148.         UUCP Adminstrator
  1149.         Department of Computer Science
  1150.         The University of Arizona
  1151.  
  1152. ----------
  1153.     From sbw  Sun Dec 15 19:09:14 1985 remote from arizona
  1154.     Received: by arizona.uucp (5.15/3.14)
  1155.         id AA06119; Sun, 15 Dec 85 19:09:14 MST
  1156.     Received: from arizona.uucp (arizona.ARPA) by bocklin.arizona.uucp (4.12/3.14)
  1157.         id AA29027; Sun, 15 Dec 85 19:07:12 mst
  1158.     Received: by arizona.uucp (5.15/3.14)
  1159.         id AA06086; Sun, 15 Dec 85 19:07:58 MST
  1160.     Received: by bocklin.arizona.uucp (4.12/3.14)
  1161.         id AA29021; Sun, 15 Dec 85 19:07:04 mst
  1162.     Date: Sun, 15 Dec 85 19:07:04 mst
  1163.     From: arizona!sbw (Steve Wampler)
  1164.     Message-Id: <8512160207.AA29021@bocklin.arizona.uucp>
  1165.     To: arizona!icon-group
  1166.     
  1167.     I came across the following little ditty while cleaning out my files
  1168.     and thought people might like to play with it...
  1169.     
  1170.     The following is an Icon program to ngram analysis of text to develop
  1171.     a 'profile' of an author's style.  It then produces randomly generated
  1172.     text in the same style.  There are a number of sources of information
  1173.     on ngram analysis and the problem is well studied.  To my mind,
  1174.     no language offers a 'cleaner' solution than Icon.
  1175.     
  1176.     ----ngrams.icn----
  1177.     # the old million monkeys problem...
  1178.     #
  1179.     #    the program uses ngram analysis to randomly generate text
  1180.     #    in the same 'style' as the input text.  arguments are:
  1181.     #
  1182.     #        -s      {show the input text}
  1183.     #        -n n    {use 'n' as the ngram size (default:4)}
  1184.     #        -l n    {output at most 'n' lines (default:10)}}
  1185.     #        -r n    {set random number seed to n}
  1186.     
  1187.     global showtxt
  1188.     
  1189.     procedure main(args)
  1190.     
  1191.        n := 4
  1192.        linecount := 10
  1193.     
  1194.        nextarg := create !args
  1195.        while arg := @nextarg do
  1196.           case arg of {
  1197.              "-s" : showtxt := "yes"
  1198.              "-n" : n := integer(@nextarg)
  1199.              "-l" : linecount := integer(@nextarg)
  1200.              "-r" : &random := integer(@nextarg)
  1201.              }
  1202.     
  1203.        ngrams := table()
  1204.     
  1205.        Show("Orginal Text is: \n\n")
  1206.     
  1207.        preline := ""
  1208.        every line := preline || !&input do {
  1209.           line ? {
  1210.                 while ngram := move(n) & nextchar := move(1) do {
  1211.                    /firstngram := Show(ngram)
  1212.                    /ngrams[ngram] := ""
  1213.                    ngrams[ngram] ||:= Show(nextchar)
  1214.                    move(-n)
  1215.                    }
  1216.                 preline := tab(0) || "\n"
  1217.                 }
  1218.           }
  1219.     
  1220.        Show("\n\nGenerating Sentences\n\n")
  1221.     
  1222.        ngram := writes(firstngram)
  1223.        while linecount > 0 do {
  1224.           if /ngrams[ngram] then
  1225.              stop()                 # if hit EOF ngram early
  1226.           ngram := ngram[2:0]||writes(nextchar:=?ngrams[ngram])
  1227.           if (nextchar == "\n") then
  1228.              linecount -:= 1
  1229.           }
  1230.     
  1231.     end
  1232.     
  1233.     
  1234.     procedure Show(text)
  1235.        if \showtxt then writes(text)
  1236.        return text
  1237.     end
  1238.     ----end of ngrams.icn----
  1239.     
  1240.     sample output of the program follows.
  1241.     
  1242.     First the source text:
  1243.     ----ngram.dat-----
  1244.     If Youth, throughout all history, had had a champion to
  1245.     stand up for it; to show a doubting world that a child
  1246.     can think; and, possibly, do it practically; you wouldn't
  1247.     constantly run across folks today who claim that "a child
  1248.     don't know anything."  A child's brain starts functioning
  1249.     at birth; and has, amongst its many infant convolutions,
  1250.     thousands of dormant atoms, into which God has put a mystic
  1251.     possibility for noticing an adult's act, and figuring out
  1252.     its purport.
  1253.     
  1254.     Up to about its primary school days a child thinks, naturally,
  1255.     only of play.  But many a form of play contains disciplinary
  1256.     factors.  "You can't do this," or "that puts you out," shows
  1257.     a child that it must think, practically, or fail.  Now, if,
  1258.     throughout childhood, a brain has no opposition, it is plain
  1259.     that it will attain a position of "status quo," as with our
  1260.     ordinary animals.  Man knows not why a cow, dog or lion was not
  1261.     born with a brain on a par with ours; why such animals cannot
  1262.     add, subtract, or obtain from books and schooling, that paramount
  1263.     position which Man holds today.
  1264.     
  1265.       -- The first two paragraphs of the novel "GADSBY", written
  1266.         by Ernest Wright (1939).  GADSBY is unique in that the
  1267.         story consists of over 50,000 words, yet never uses the
  1268.         letter 'E'.
  1269.     ----end of ngram.dat---
  1270.     
  1271.     Now, three different analyses, for 2grams, 4grams, and 7grams.
  1272.     
  1273.     ---2 gram output---
  1274.     If primanin at cals.  -- The
  1275.       links of You of the it pary
  1276.     factionly,
  1277.     ory runimannows this a folks a fol ding or was thatten
  1278.     that playsticho obtractod toms, doughout
  1279.     ad thaturs; a chin outs novel dongstichinstaing anythild's do ch of obtion't brampion wo cally; a plainfantand that th; wrinaturposs out," subticals nary Ernest pary sciplain whooks throssits nows
  1280.     ad hatten
  1281.       "th of do ormally, whistat not
  1282.     ithas an to a by suchinar 50,00 wildn't
  1283.     add, plithinat Writ ching." sciplaim the
  1284.     ---4 gram output---
  1285.     If Youth, throughout a child thinks, naturally,
  1286.     only of the novel "GADSBY is plain
  1287.     that a mystic
  1288.     possibility for it; to about childhood, a brain starts functions,
  1289.     throughout child
  1290.     can that a child
  1291.     can that puts you wouldn't
  1292.     consists of over uses the novel "GADSBY is play.  But many infant convolution was not
  1293.     add, subtractically, dog or fail.  Now, dog or obtain has purport.
  1294.     
  1295.     ---7 gram output---
  1296.     If Youth, throughout childhood, a brain has no opposition of "status quo," as with ours; why such animals.  Man knows not why a cow, dog or lion was not
  1297.     born with a brain has no opposition, it is plain
  1298.     that it must think, practically; you wouldn't
  1299.     constantly run across folks today who claim that "a child thinks, naturally,
  1300.     only of play contains disciplinary
  1301.     factors.  "You can't do this," or "that puts you out," shows
  1302.     a child that it will attain a position, it is plain
  1303.     that it will attain a position which Man holds today.
  1304.     
  1305.       -- The first two paragraphs of the novel "GADSBY", written
  1306.     ---end of sample runs---
  1307.     
  1308.     
  1309.     The program is fun to run on MS-DOS icon, as it becomes obvious
  1310.     whenever the garbage collector kicks in.
  1311.     
  1312.     Some open questions:
  1313.     
  1314.       The program is very memory intensive, can that be improved,
  1315.       or does the problem inherently require tons of memory?
  1316.     
  1317.       The program is very weak on handling the last few characters
  1318.       of the text file.  Can anyone suggest some improvements?
  1319.     
  1320.          -Steve Wampler
  1321. ----------
  1322.  
  1323.