home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group88b.txt < prev    next >
Text File  |  1989-01-01  |  286KB  |  7,466 lines

  1.  
  2. From icon-group-request  Fri Jun  3 04:00:30 1988
  3. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 04:00:30 MST
  4. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Fri, 3 Jun 88 04:00:21 MST
  5. Received: by ucbvax.Berkeley.EDU (5.59/1.28)
  6.     id AA05804; Fri, 3 Jun 88 02:52:02 PDT
  7. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  8.     for icon-group@arizona.edu (icon-group@arizona.edu)
  9.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  10. Date: 2 Jun 88 22:11:22 GMT
  11. From: ncc!lyndon@uunet.uu.net  (Lyndon Nerenberg)
  12. Organization: Nexus Computing Inc.
  13. Subject: Address for ordering Icon tape wanted
  14. Message-Id: <10263@ncc.Nexus.CA>
  15. Sender: icon-group-request@arizona.edu
  16. To: icon-group@arizona.edu
  17.  
  18. Could someone at Arizona please email me the address (and prices
  19. if you have them) for ordering the Icon tape? Thanks.
  20. -- 
  21. {alberta,utzoo,uunet}!ncc!lyndon  lyndon@Nexus.CA
  22.  
  23. From DSCARGO@CIM-VAX.HONEYWELL.COM  Fri Jun  3 06:48:57 1988
  24. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 06:48:57 MST
  25. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu; Fri, 3 Jun 88 06:48:51 MST
  26. Received: by CIM-VAX id <0000161E071@CIM-VAX.HONEYWELL.COM> ;
  27.        Fri,  3 Jun 88 08:47:04 CDT
  28. Date: Fri,  3 Jun 88 08:43:11 CDT
  29. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@CIM-VAX.HONEYWELL.COM>
  30. Subject: Macintosh version of Icon
  31. To: icon-group@arizona.edu
  32. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  33. Message-Id: <880603084311.0000161E071@CIM-VAX.HONEYWELL.COM>
  34.  
  35. Is there a Macintosh version of Icon?  If there is, where can I get it?
  36.  
  37. I'm doing some stuff the non-WYSIWYG text processing.  I'm looking at some
  38. software that provides a split-screen psuedo-WYSIWYG interface and produces
  39. Standardized Generalized Markup Language (SGML) output.  I'm also using
  40. Textures, the TeX implementation for the Mac from Addison-Wesley and Kellerman
  41. & Smith.  I'd like to investigate translating SGML to TeX for actual
  42. formatting, and Icon seems like it would be a good tool to use to do it.
  43.  
  44. dsc (DSCARGO@CIM-VAX.HONEYWELL.COM)
  45.  
  46. From sboisen@REGULUS.BBN.COM  Fri Jun  3 07:19:31 1988
  47. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 07:19:31 MST
  48. Message-Id: <8806031419.AA08135@megaron.arizona.edu>
  49. Received: from REGULUS.BBN.COM by megaron.arizona.edu; Fri, 3 Jun 88 07:19:27 MST
  50. To: icon-group@arizona.edu
  51. Subject: icon-mode for GNU Emacs?
  52. Date: Fri, 3 Jun 88 10:11:18 EDT
  53. From: sboisen@REGULUS.BBN.COM
  54. Sender: sboisen@REGULUS.BBN.COM
  55.  
  56. Does anybody have a functional icon-mode for GNU Emacs? I'm thoroughly
  57. addicted to indentation helps and all the rest, but hacking c-mode to
  58. do Icon hasn't turned out to be as easy as i thought it might. Any
  59. help appreciated..
  60.  
  61. ........................................
  62. Sean Boisen -- sboisen@bbn.com
  63. BBN Labs, Inc.
  64. Disclaimer: these opinions void where prohibited by lawyers.
  65.  
  66. From sunquest!whm  Fri Jun  3 17:44:50 1988
  67. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 17:44:50 MST
  68. Received: by megaron.arizona.edu; Fri, 3 Jun 88 16:49:39 MST
  69. Date: Fri, 3 Jun 88 16:39:58 MST
  70. From: "Bill Mitchell" <sunquest!whm>
  71. Message-Id: <8806032339.AA12639@sunquest>
  72. Received: by sunquest; Fri, 3 Jun 88 16:39:58 MST
  73. To: arizona!icon-group
  74. Subject: Unofficial Sun-4 Icon fixes
  75.  
  76. A little twiddling is needed to make Icon 7.0 work on a Sun-4.  Cut on the
  77. indicated line below and put the contents in a script in the top-level Icon
  78. directory (/usr/icon or whatever) and run it.  It creates a sun4 config from
  79. the sun3 config.
  80.  
  81. Once you've run the script, type "make Configure name=sun4" and you should
  82. be ready to go.  You can read the details below on the state of things or
  83. "make Status name=sun4" after you've run the script.
  84.  
  85.                     Bill Mitchell
  86.  
  87. ------ cut here ------ 
  88. #!/bin/csh -f
  89. cd config/unix
  90. rm -rf sun4
  91. echo Removing old sun4 config...
  92. mkdir sun4
  93. cd sun3
  94. echo Copying sun3 config to sun4...
  95. tar crf - . | (cd ../sun4; tar xf -)
  96. cd ../sun4
  97. echo Editing files...
  98. cp ../Common/rswitch.c .
  99. ed - iconx.hdr <<XXX
  100. /ROVER/s/rover.s/rover.c/
  101. w
  102. q
  103. XXX
  104. ed - define.h <<XXX
  105. \$a
  106. #define NoOver 1
  107. .
  108. /MaxHdr/s/2000/2560/
  109. w
  110. q
  111. XXX
  112. cat >status <<XXX
  113. Last update: Fri Jun  3 16:18:50 MST 1988
  114.  
  115. Current
  116. -------
  117.  
  118. Built and tested on a Sun-4/280 running Sys4-3.2.
  119.  
  120. Co-expressions and overflow checking aren't implemented.  (N.B.: If NoCoexpr
  121. is defined, the value of MaxStatSize that is used (500) is too small and
  122. core dumps during startup result.  Since there's no easy way to specify a
  123. smaller MaxStatSize via the config stuff, the simplest solution is to let the
  124. co-expression code be compiled in: it results in a sufficiently large value
  125. of MaxStatSize.)
  126.  
  127. There's some sort of floating point problem, apparently related to output
  128. formatting, but it hasn't been investigated.  (Values like 2.0 often come out
  129. as 2.93434e-323, as if the integer part is correct, but the fraction is thought
  130. to be a very small, but non-zero number.)
  131.  
  132. Personalized interpreters and the Icon Program Library pass their tests.
  133.  
  134. Variant translators core dump immediately; this has not been investigated.
  135.  
  136. The tests for the save() function were missing from the distribution, but
  137. a simple test of save() worked.
  138.  
  139. -O4 optimization has been seen to work, but currently -O is used.  (Note that
  140. with itran/code.c, -O4 will produce a 10Mb core dump; -O2 works for it.)  On
  141. a single measured case, -O4 produced a 10% speedup over -O.
  142.  
  143. Future
  144. ------
  145.  
  146. Historically speaking, I've always been unable to leave stuff like this alone
  147. until it's completely working, so fixes for the floating point, co-expressions,
  148. overflow checking, and the variant translators  will probably appear sooner or
  149. later, but not necessarily in that order.  However, don't hold your breath.
  150.  
  151. Bill Mitchell
  152. Sunquest Information Systems
  153. Tucson AZ
  154. arizona!sunquest!whm
  155. XXX
  156. echo Done!
  157.  
  158. From sunquest!whm  Fri Jun  3 18:07:42 1988
  159. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 3 Jun 88 18:07:42 MST
  160. Received: by megaron.arizona.edu; Fri, 3 Jun 88 18:07:40 MST
  161. Date: Fri, 3 Jun 88 18:01:14 MST
  162. From: "Bill Mitchell" <sunquest!whm>
  163. Message-Id: <8806040101.AA12928@sunquest>
  164. Received: by sunquest; Fri, 3 Jun 88 18:01:14 MST
  165. To: arizona!icon-group
  166. Subject: Unofficial Sun-4 Icon fixes
  167.  
  168. A little twiddling is needed to make Icon 7.0 work on a Sun-4.  Cut on the
  169. indicated line below, remove the leading Xs, and put the contents in a
  170. script in the top-level Icon directory (/usr/icon or whatever) and run it.
  171. It creates a sun4 config from the sun3 config.
  172.  
  173. Once you've run the script, type "make Configure name=sun4" and you should
  174. be ready to go.  You can read the details below on the state of things or
  175. "make Status name=sun4" after you've run the script.
  176.  
  177.                     Bill Mitchell
  178.  
  179. p.s.
  180. Sorry about the repeat, the first message got truncated by a bogus mailer.
  181. ------ cut here ------ 
  182. X#!/bin/csh -f
  183. Xcd config/unix
  184. Xrm -rf sun4
  185. Xecho Removing old sun4 config...
  186. Xmkdir sun4
  187. Xcd sun3
  188. Xecho Copying sun3 config to sun4...
  189. Xtar crf - . | (cd ../sun4; tar xf -)
  190. Xcd ../sun4
  191. Xecho Editing files...
  192. Xcp ../Common/rswitch.c .
  193. Xed - iconx.hdr <<XXX
  194. X/ROVER/s/rover.s/rover.c/
  195. Xw
  196. Xq
  197. XXXX
  198. Xed - define.h <<XXX
  199. X\$a
  200. X#define NoOver 1
  201. X.
  202. X/MaxHdr/s/2000/2560/
  203. Xw
  204. Xq
  205. XXXX
  206. Xcat >status <<XXX
  207. XLast update: Fri Jun  3 16:18:50 MST 1988
  208. X
  209. XCurrent
  210. X-------
  211. X
  212. XBuilt and tested on a Sun-4/280 running Sys4-3.2.
  213. X
  214. XCo-expressions and overflow checking aren't implemented.  (N.B.: If NoCoexpr
  215. Xis defined, the value of MaxStatSize that is used (500) is too small and
  216. Xcore dumps during startup result.  Since there's no easy way to specify a
  217. Xsmaller MaxStatSize via the config stuff, the simplest solution is to let the
  218. Xco-expression code be compiled in: it results in a sufficiently large value
  219. Xof MaxStatSize.)
  220. X
  221. XThere's some sort of floating point problem, apparently related to output
  222. Xformatting, but it hasn't been investigated.  (Values like 2.0 often come out
  223. Xas 2.93434e-323, as if the integer part is correct, but the fraction is thought
  224. Xto be a very small, but non-zero number.)
  225. X
  226. XPersonalized interpreters and the Icon Program Library pass their tests.
  227. X
  228. XVariant translators core dump immediately; this has not been investigated.
  229. X
  230. XThe tests for the save() function were missing from the distribution, but
  231. Xa simple test of save() worked.
  232. X
  233. X-O4 optimization has been seen to work, but currently -O is used.  (Note that
  234. Xwith itran/code.c, -O4 will produce a 10Mb core dump; -O2 works for it.)  On
  235. Xa single measured case, -O4 produced a 10% speedup over -O.
  236. X
  237. XFuture
  238. X------
  239. X
  240. XHistorically speaking, I've always been unable to leave stuff like this alone
  241. Xuntil it's completely working, so fixes for the floating point, co-expressions,
  242. Xoverflow checking, and the variant translators  will probably appear sooner or
  243. Xlater, but not necessarily in that order.  However, don't hold your breath.
  244. X
  245. XBill Mitchell
  246. XSunquest Information Systems
  247. XTucson AZ
  248. Xarizona!sunquest!whm
  249. XXXX
  250. Xecho Done!
  251. ---- the end ----
  252.  
  253. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Sun Jun  5 10:03:40 1988
  254. Received: from megaron.arizona.edu by bocklin.arizona.edu; Sun, 5 Jun 88 10:03:40 MST
  255. Received: from [128.135.12.98] by megaron.arizona.edu; Sun, 5 Jun 88 10:03:22 MST
  256. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  257.     id AA22531; Sun, 5 Jun 88 12:07:43 CDT
  258. Return-Path: <goer@sophist.uchicago.edu>
  259. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  260.     id AA15971; Sun, 5 Jun 88 11:56:37 CDT
  261. Date: Sun, 5 Jun 88 11:56:37 CDT
  262. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  263. Message-Id: <8806051656.AA15971@sophist.uchicago.edu>
  264. To: icon-group@arizona.edu
  265. Subject: coroutines
  266.  
  267. I have a strange situation come up where I can't seem to stop a string of
  268. filters from resuming.
  269.  
  270. What I am doing is reading the standard input, and then doing various things
  271. to it that aren't necessary to enumerate.  The general form of my program is:
  272.  
  273.       global Filter2, Filter3
  274.       procedure main()
  275.  
  276.         Filter1 := create filterit1(create trim(!&input),Filter2)
  277.         Filter2 := create filterit2(Filter1,Filter3)
  278.         Filter3 := create filterit3(Filter2,&main)
  279.  
  280.         while write(@Filter3)
  281.  
  282.       end
  283.  
  284.  
  285.       procedure filterit1(in,out)
  286.  
  287.         while line := @in do {
  288.          # do something to line
  289.          line @ out
  290.          }
  291.  
  292.       end
  293.  
  294.  
  295.       etc....
  296.  
  297. This all worked fine - until I wanted Filter2 to stop program execution when
  298. a certain string was found.  Maybe it was silly, but I thought that simply
  299. having the procedure filterit2 fail when it encountered that string would be
  300. sufficient.  The trouble is that the program then went into a loop, with
  301. filterit1() being repeatedly resumed.  The program didn't want to terminate
  302. until the standard input was exhausted.  To put it differently, filterit2
  303. failed, hence Filter2 failed with respect to the next filter.  Somehow, though,
  304. the first filter kept getting activated.  Gads!  What am I doing wrong.
  305.  
  306. I tried to use a simply return to &source, but this didn't work, either.  What
  307. am I misunderstanding?
  308.  
  309.                                                   -Richard L. Goerwitz
  310.                                                   goer@sophist.uchicago.edu
  311.                                                   !ihnp4!gargoyle!sophist!goer
  312.  
  313. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Sun Jun  5 14:56:38 1988
  314. Received: from megaron.arizona.edu by bocklin.arizona.edu; Sun, 5 Jun 88 14:56:38 MST
  315. Received: from sphinx.uchicago.edu by megaron.arizona.edu; Sun, 5 Jun 88 14:56:30 MST
  316. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  317.     id AA24614; Sun, 5 Jun 88 17:01:08 CDT
  318. Return-Path: <goer@sophist.uchicago.edu>
  319. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  320.     id AA16346; Sun, 5 Jun 88 16:49:57 CDT
  321. Date: Sun, 5 Jun 88 16:49:57 CDT
  322. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  323. Message-Id: <8806052149.AA16346@sophist.uchicago.edu>
  324. To: icon-group@arizona.edu
  325. Subject: coroutines
  326.  
  327. Re my query about how to cut out of a series of coexpressions daisy chained
  328. together as filters, Steve Wampler wrote:
  329.  
  330.     To stop the program, you could just issue a stop() call, but I suspect
  331.     you might want to do an @&main.  The problem you're having has to
  332.     do with the control flow sequence through the co-expressions.  Briefly
  333.     put, I suspect that the source for Filter2 is Filter1, and the source
  334.     for Filter1 is Filter2 (or something similar).  Thus there is no
  335.     direct way out of the cycle out of the control flow.  I'd have to see
  336.     more of the actual code to be of much help on this, however.
  337.  
  338. The code I posted actually summarizes the 1000-line program quite well.  It's
  339. like the example given in Griswold & Griswold of coroutine programming, except
  340. that there are more filters.
  341.  
  342. The trouble is that I don't want to swing back to &main.  Nor do I want to
  343. simply quit the program. 
  344.  
  345.   global Filter2, Filter3
  346.   procedure main()
  347.     Filter1 := create filterit1(create trim(!&input),Filter2)
  348.     Filter2 := create filterit2(Filter1,Filter3)
  349.     Filter3 := create filterit3(Filter2,&main)
  350.     while write(@Filter3)
  351.   end
  352.  
  353.   procedure filterit1(in,out)
  354.     while ( @in @ out )
  355.   end
  356.  
  357.   procedure filterit2(in,out)
  358.     while line := @in do {
  359.       if match("end",line) then fail
  360.       line @ out 
  361.       }
  362.   end
  363.  
  364.   procedure filterit3(in,out)
  365.     while ( @in @ out )
  366.     "EOF" @ out
  367.   end
  368.  
  369. This is an absurdly honed-down version.  But what I want it to do is break
  370. the coroutine chain when a line beginning with the word "end" is found.
  371. I want it to translate into failure of "@in" in filterit3(in,out).  So I
  372. don't want to do either of the things suggested above, namely 1) stop exe-
  373. cution, or 2) return immediately to &main.  You'll notice that this pro-
  374. gram does what you might expect it to; at least its output is correct.  The
  375. problem is that it reads everything on the standard input, even after I've
  376. found my "end".  Sure, I can replace "...then fail" above with "then stop(
  377. "EOF")" and all will be well.  This isn't terribly symmetrical, though, and
  378. in the larger program I'm working on, it actually ends up being quite opaque.
  379.  
  380. Is there a better way to do this?
  381.  
  382.                                                   -Richard L. Goerwitz
  383.                                                   goer@sophist.uchicago.edu
  384.                                                   !ihnp4!gargoyle!sophist!goer
  385.  
  386. From naucse!sbw  Mon Jun  6 07:35:01 1988
  387. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 6 Jun 88 07:35:01 MST
  388. Received: by megaron.arizona.edu; Mon, 6 Jun 88 07:34:59 MST
  389. Date: Mon, 6 Jun 88 07:20:09 mst
  390. From: naucse!sbw (Steve Wampler)
  391. Message-Id: <8806061420.AA06973@naucse>
  392. To: arizona!goer@sophist.uchicago.edu
  393. Subject: Re:  coroutines
  394. Cc: arizona!icon-group
  395.  
  396. Hmmm, now I'm confused.  What version of Icon are you running?  Under
  397. v7, the latest program you sent (with the 'fail' in filterit2()) seems
  398. to work the way you say you want it to.  In particular, the input file:
  399.  
  400.     this is
  401.     a
  402.     test
  403.     end
  404.     of
  405.     the
  406.     world
  407.  
  408. produces the output file:
  409.  
  410.     this is
  411.     a
  412.     test
  413.     EOF
  414.  
  415. To show that it isn't reading any more input after encountering a
  416. line beginning with 'end', here is the same output, run with &trace
  417. set:
  418.  
  419.         main()
  420. co.icn: 6    | main; #1 : &null @ #4
  421. co.icn: 5    | filterit3(co-expression #3,co-expression #1)
  422. co.icn: 21    | | filterit3; #4 : &null @ #3
  423. co.icn: 4    | | filterit2(co-expression #2,co-expression #4)
  424. co.icn: 14    | | | filterit2; #3 : &null @ #2
  425. co.icn: 3    | | | filterit1(co-expression #5,co-expression #3)
  426. co.icn: 10    | | | | filterit1; #2 : &null @ #5
  427. co.icn: 3    | | | | main; #5 returned "this is" to #2
  428. co.icn: 10    | | | | filterit1; #2 : "this is" @ #3
  429. co.icn: 16    | | | | filterit2; #3 : (variable = "this is") @ #4
  430. co.icn: 21    | | | | filterit3; #4 : "this is" @ #1
  431. this is
  432. co.icn: 6    | | | | main; #1 : &null @ #4
  433. co.icn: 21    | | | | filterit3; #4 : &null @ #3
  434. co.icn: 14    | | | | filterit2; #3 : &null @ #2
  435. co.icn: 10    | | | | filterit1; #2 : &null @ #5
  436. co.icn: 3    | | | | main; #5 returned "a" to #2
  437. co.icn: 10    | | | | filterit1; #2 : "a" @ #3
  438. co.icn: 16    | | | | filterit2; #3 : (variable = "a") @ #4
  439. co.icn: 21    | | | | filterit3; #4 : "a" @ #1
  440. a
  441. co.icn: 6    | | | | main; #1 : &null @ #4
  442. co.icn: 21    | | | | filterit3; #4 : &null @ #3
  443. co.icn: 14    | | | | filterit2; #3 : &null @ #2
  444. co.icn: 10    | | | | filterit1; #2 : &null @ #5
  445. co.icn: 3    | | | | main; #5 returned "test" to #2
  446. co.icn: 10    | | | | filterit1; #2 : "test" @ #3
  447. co.icn: 16    | | | | filterit2; #3 : (variable = "test") @ #4
  448. co.icn: 21    | | | | filterit3; #4 : "test" @ #1
  449. test
  450. co.icn: 6    | | | | main; #1 : &null @ #4
  451. co.icn: 21    | | | | filterit3; #4 : &null @ #3
  452. co.icn: 14    | | | | filterit2; #3 : &null @ #2
  453. co.icn: 10    | | | | filterit1; #2 : &null @ #5
  454. co.icn: 3    | | | | main; #5 returned "end" to #2
  455. co.icn: 10    | | | | filterit1; #2 : "end" @ #3
  456. co.icn: 15    | | | filterit2 failed
  457. co.icn: 4    | | | main; #3 failed to #2
  458. co.icn: 11    | | filterit1 failed
  459. co.icn: 3    | | main; #2 failed to #3
  460. co.icn: 4    | | main; #3 failed to #4
  461. co.icn: 22    | | filterit3; #4 : "EOF" @ #1
  462. EOF
  463. co.icn: 6    | | main; #1 : &null @ #4
  464. co.icn: 23    | filterit3 failed
  465. co.icn: 5    | main; #4 failed to #1
  466. co.icn: 7    main failed
  467.  
  468. Finally, as a reference aid, here is the source code, annotated with
  469. line numbers:
  470.  
  471.     1     global Filter2, Filter3
  472.     2     procedure main()
  473.     3       Filter1 := create filterit1(create trim(!&input),Filter2)
  474.     4       Filter2 := create filterit2(Filter1,Filter3)
  475.     5       Filter3 := create filterit3(Filter2,&main)
  476.     6       while write(@Filter3)
  477.     7     end
  478.     8   
  479.     9     procedure filterit1(in,out)
  480.    10       while ( @in @ out )
  481.    11     end
  482.    12   
  483.    13     procedure filterit2(in,out)
  484.    14       while line := @in do {
  485.    15         if match("end",line) then fail
  486.    16         line @ out 
  487.    17         }
  488.    18     end
  489.    19   
  490.    20     procedure filterit3(in,out)
  491.    21       while ( @in @ out )
  492.    22       "EOF" @ out
  493.    23     end
  494.  
  495. Perhaps this short program doesn't accurately model the behavior of
  496. the big one?  If the short program doesn't work for you as it does
  497. for me, could you send me the output of the program:
  498.  
  499.     procedure main()
  500.        write(&version)
  501.     end
  502.  
  503. Thanks.
  504.  
  505. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Mon Jun  6 15:19:18 1988
  506. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 6 Jun 88 15:19:18 MST
  507. Received: from sphinx.uchicago.edu by megaron.arizona.edu; Mon, 6 Jun 88 15:19:10 MST
  508. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  509.     id AA17735; Mon, 6 Jun 88 16:46:55 CDT
  510. Return-Path: <goer@sophist.uchicago.edu>
  511. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  512.     id AA18422; Mon, 6 Jun 88 16:35:21 CDT
  513. Date: Mon, 6 Jun 88 16:35:21 CDT
  514. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  515. Message-Id: <8806062135.AA18422@sophist.uchicago.edu>
  516. To: icon-group@arizona.edu
  517. Subject: better model
  518.  
  519. Here is a real model of the program I've been using.  Some have been confused
  520. by the inaccurate model I posted earlier.  It worked.  So does this one.  I.e.
  521. it works as expected, at least from the standpoint of its output.  However, it
  522. doesn't behave as I might expect (granted, I am not an expert).
  523.  
  524. global Filter2, Filter3
  525. procedure main()
  526.   Filter1 := create filterit1(create !&input,Filter2)
  527.   Filter2 := create filterit2(Filter1,Filter3)
  528.   Filter3 := create filterit3(Filter2,&main)
  529.   while write(@Filter3)
  530. end
  531.  
  532. procedure filterit1(in,out)
  533.   every ( GetLines(in) @ out )
  534. end
  535.  
  536. procedure GetLines(in)
  537.   while line := @in
  538.   do suspend line
  539. end
  540.  
  541. procedure filterit2(in,out)
  542.   while line := @in do {
  543.    CheckIfEnd(line) | fail
  544.    writeout(line,out)
  545.    }
  546. end
  547.  
  548. procedure CheckIfEnd(s)
  549.   s == "end" & fail
  550.   return
  551. end
  552.  
  553. procedure filterit3(in,out)
  554.   while ( @in @ out )
  555. end
  556.  
  557. procedure writeout(line,out)
  558.   line @ out
  559. end
  560.  
  561.  
  562. Try running this through
  563.  
  564. this is a test
  565. testing...
  566. testing...
  567. end
  568. done testing!!!
  569. done testing!!!
  570. done.
  571.  
  572. Like I said before, it doesn't fail when or how I "expect" it to....
  573.  
  574.                                                   -Richard L. Goerwitz
  575.                                                   goer@sophist.uchicago.edu
  576.                                                   !ihnp4!gargoyle!sophist!goer
  577.  
  578. From mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET  Tue Jun  7 03:41:23 1988
  579. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 7 Jun 88 03:41:23 MST
  580. Received: from [192.12.141.129] by megaron.arizona.edu; Tue, 7 Jun 88 03:41:15 MST
  581. Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP 
  582.     id AA21227; Tue, 7 Jun 88 06:39:14 EDT
  583. Received: by mcvax.cwi.nl; Tue, 7 Jun 88 11:43:27 +0200 (MET)
  584. Received: from mirsa.inria.Fr by inria.inria.fr; Tue, 7 Jun 88 10:45:58 +0200 (MET)
  585. Message-Id: <8806070845.AA01433@inria.inria.fr>
  586. Posted: Tue, 7 Jun 88 10:44:37 -0100
  587. Date: Tue, 7 Jun 88 10:44:37 -0100
  588. Posted-Date: Tue, 7 Jun 88 10:44:37 -0100
  589. From: olivier lecarme <mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET>
  590. To: sboisen@regulus.bbn.com
  591. Cc: icon-group@arizona.edu
  592. In-Reply-To: sboisen@REGULUS.BBN.COM's message of Fri, 3 Jun 88 10:11:18 EDT <8806031419.AA08135@megaron.arizona.edu>
  593. Subject: icon-mode for GNU Emacs?
  594.  
  595. I have exactly the same need as you, and the same difficulties (disgust
  596. ?) with C programming...
  597.  
  598. From mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET  Tue Jun  7 04:01:09 1988
  599. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 7 Jun 88 04:01:09 MST
  600. Received: from uunet.UU.NET by megaron.arizona.edu; Tue, 7 Jun 88 04:01:02 MST
  601. Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP 
  602.     id AA19266; Tue, 7 Jun 88 05:46:38 EDT
  603. Received: by mcvax.cwi.nl; Tue, 7 Jun 88 01:31:50 +0200 (MET)
  604. Received: from mirsa.inria.Fr by inria.inria.fr; Mon, 6 Jun 88 11:32:42 +0200 (MET)
  605. Message-Id: <8806060932.AA20441@inria.inria.fr>
  606. Posted: Mon, 6 Jun 88 10:22:23 -0100
  607. Date: Mon, 6 Jun 88 10:22:23 -0100
  608. Posted-Date: Mon, 6 Jun 88 10:22:23 -0100
  609. From: olivier lecarme <mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET>
  610. To: icon-group@arizona.edu
  611. Subject: Icon pretty-printer
  612.  
  613. Several persons asked me for the Icon pretty-printer. Since it will be
  614. the result of a student project, it is not yet completed, and maybe it
  615. will have to be somewhat improved after the students departure. I will
  616. take the Icon community informed about the progression of this project.
  617.  
  618. Olivier Lecarme / University of Nice
  619.  
  620. From sboisen@RIGEL.BBN.COM  Tue Jun  7 05:29:32 1988
  621. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 7 Jun 88 05:29:32 MST
  622. Message-Id: <8806071228.AA01615@megaron.arizona.edu>
  623. Received: from RIGEL.BBN.COM by megaron.arizona.edu; Tue, 7 Jun 88 05:28:58 MST
  624. To: icon-group@arizona.edu
  625. Subject: Icon mode for GNU
  626. Date: Tue, 7 Jun 88 8:22:37 EDT
  627. From: sboisen@RIGEL.BBN.COM
  628. Sender: sboisen@RIGEL.BBN.COM
  629.  
  630. Thanks to Steve Wampler for sending this along to me: a few others
  631. have asked if i got any response, so here it is. The only bug i've
  632. found so far is admittedly minor: indent-new-comment-line adds an
  633. extra space at the left (in contrast to the behavior of the same in
  634. Lisp mode, at least on my system). Otherwise it looks great.
  635.  
  636. ........................................
  637. Sean Boisen -- sboisen@bbn.com
  638. BBN Labs, Inc.
  639. Disclaimer: these opinions void where prohibited by lawyers.
  640.  
  641.  
  642. ---------- cut here ----------
  643. ;; Icon code editing commands for Emacs
  644. ;; Derived from c-mode.el  15-Apr-88  Chris Smith  convex!csmith
  645. ;; Copyright (C) 1988 Free Software Foundation, Inc.
  646.  
  647. ;; This file is part of GNU Emacs.
  648.  
  649. ;; GNU Emacs is distributed in the hope that it will be useful,
  650. ;; but WITHOUT ANY WARRANTY.  No author or distributor
  651. ;; accepts responsibility to anyone for the consequences of using it
  652. ;; or for whether it serves any particular purpose or works at all,
  653. ;; unless he says so in writing.  Refer to the GNU Emacs General Public
  654. ;; License for full details.
  655.  
  656. ;; Everyone is granted permission to copy, modify and redistribute
  657. ;; GNU Emacs, but only under the conditions described in the
  658. ;; GNU Emacs General Public License.   A copy of this license is
  659. ;; supposed to have been given to you along with GNU Emacs so you
  660. ;; can know your rights and responsibilities.  It should be in a
  661. ;; file named COPYING.  Among other things, the copyright notice
  662. ;; and this notice must be preserved on all copies.
  663.  
  664.  
  665. (defvar icon-mode-abbrev-table nil
  666.   "Abbrev table in use in Icon-mode buffers.")
  667. (define-abbrev-table 'icon-mode-abbrev-table ())
  668.  
  669. (defvar icon-mode-map ()
  670.   "Keymap used in Icon mode.")
  671. (if icon-mode-map
  672.     ()
  673.   (setq icon-mode-map (make-sparse-keymap))
  674.   (define-key icon-mode-map "{" 'electric-icon-brace)
  675.   (define-key icon-mode-map "}" 'electric-icon-brace)
  676.   (define-key icon-mode-map "\e\C-h" 'mark-icon-function)
  677.   (define-key icon-mode-map "\e\C-a" 'beginning-of-icon-defun)
  678.   (define-key icon-mode-map "\e\C-e" 'end-of-icon-defun)
  679.   (define-key icon-mode-map "\e\C-q" 'indent-icon-exp)
  680.   (define-key icon-mode-map "\177" 'backward-delete-char-untabify)
  681.   (define-key icon-mode-map "\t" 'icon-indent-command))
  682.  
  683. (defvar icon-mode-syntax-table nil
  684.   "Syntax table in use in Icon-mode buffers.")
  685.  
  686. (if icon-mode-syntax-table
  687.     ()
  688.   (setq icon-mode-syntax-table (make-syntax-table))
  689.   (modify-syntax-entry ?\\ "\\" icon-mode-syntax-table)
  690.   (modify-syntax-entry ?# "<" icon-mode-syntax-table)
  691.   (modify-syntax-entry ?\n ">" icon-mode-syntax-table)
  692.   (modify-syntax-entry ?$ "." icon-mode-syntax-table)
  693.   (modify-syntax-entry ?/ "." icon-mode-syntax-table)
  694.   (modify-syntax-entry ?* "." icon-mode-syntax-table)
  695.   (modify-syntax-entry ?+ "." icon-mode-syntax-table)
  696.   (modify-syntax-entry ?- "." icon-mode-syntax-table)
  697.   (modify-syntax-entry ?= "." icon-mode-syntax-table)
  698.   (modify-syntax-entry ?% "." icon-mode-syntax-table)
  699.   (modify-syntax-entry ?< "." icon-mode-syntax-table)
  700.   (modify-syntax-entry ?> "." icon-mode-syntax-table)
  701.   (modify-syntax-entry ?& "." icon-mode-syntax-table)
  702.   (modify-syntax-entry ?| "." icon-mode-syntax-table)
  703.   (modify-syntax-entry ?\' "\"" icon-mode-syntax-table))
  704.  
  705. (defconst icon-indent-level 4
  706.   "*Indentation of Icon statements with respect to containing block.")
  707. (defconst icon-brace-imaginary-offset 0
  708.   "*Imagined indentation of a Icon open brace that actually follows a statement.")
  709. (defconst icon-brace-offset 0
  710.   "*Extra indentation for braces, compared with other text in same context.")
  711. (defconst icon-continued-statement-offset 4
  712.   "*Extra indent for lines not starting new statements.")
  713. (defconst icon-continued-brace-offset 0
  714.   "*Extra indent for substatements that start with open-braces.
  715. This is in addition to icon-continued-statement-offset.")
  716.  
  717. (defconst icon-auto-newline nil
  718.   "*Non-nil means automatically newline before and after braces,
  719. and after colons and semicolons, inserted in C code.")
  720.  
  721. (defconst icon-tab-always-indent t
  722.   "*Non-nil means TAB in Icon mode should always reindent the current line,
  723. regardless of where in the line point is when the TAB command is used.")
  724.  
  725. (defun icon-mode ()
  726.   "Major mode for editing Icon code.
  727. Expression and list commands understand all Icon brackets.
  728. Tab indents for Icon code.
  729. Paragraphs are separated by blank lines only.
  730. Delete converts tabs to spaces as it moves back.
  731. \\{icon-mode-map}
  732. Variables controlling indentation style:
  733.  icon-tab-always-indent
  734.     Non-nil means TAB in Icon mode should always reindent the current line,
  735.     regardless of where in the line point is when the TAB command is used.
  736.  icon-auto-newline
  737.     Non-nil means automatically newline before and after braces
  738.     inserted in Icon code.
  739.  icon-indent-level
  740.     Indentation of Icon statements within surrounding block.
  741.     The surrounding block's indentation is the indentation
  742.     of the line on which the open-brace appears.
  743.  icon-continued-statement-offset
  744.     Extra indentation given to a substatement, such as the
  745.     then-clause of an if or body of a while.
  746.  icon-continued-brace-offset
  747.     Extra indentation given to a brace that starts a substatement.
  748.     This is in addition to icon-continued-statement-offset.
  749.  icon-brace-offset
  750.     Extra indentation for line if it starts with an open brace.
  751.  icon-brace-imaginary-offset
  752.     An open brace following other text is treated as if it were
  753.     this far to the right of the start of its line.
  754.  
  755. Turning on Icon mode calls the value of the variable icon-mode-hook with no args,
  756. if that value is non-nil."
  757.   (interactive)
  758.   (kill-all-local-variables)
  759.   (use-local-map icon-mode-map)
  760.   (setq major-mode 'icon-mode)
  761.   (setq mode-name "Icon")
  762.   (setq local-abbrev-table icon-mode-abbrev-table)
  763.   (set-syntax-table icon-mode-syntax-table)
  764.   (make-local-variable 'paragraph-start)
  765.   (setq paragraph-start (concat "^$\\|" page-delimiter))
  766.   (make-local-variable 'paragraph-separate)
  767.   (setq paragraph-separate paragraph-start)
  768.   (make-local-variable 'indent-line-function)
  769.   (setq indent-line-function 'icon-indent-line)
  770.   (make-local-variable 'require-final-newline)
  771.   (setq require-final-newline t)
  772.   (make-local-variable 'comment-start)
  773.   (setq comment-start "# ")
  774.   (make-local-variable 'comment-end)
  775.   (setq comment-end "")
  776.   (make-local-variable 'comment-column)
  777.   (setq comment-column 32)
  778.   (make-local-variable 'comment-start-skip)
  779.   (setq comment-start-skip "# *")
  780.   (make-local-variable 'comment-indent-hook)
  781.   (setq comment-indent-hook 'icon-comment-indent)
  782.   (run-hooks 'icon-mode-hook))
  783.  
  784. ;; This is used by indent-for-comment
  785. ;; to decide how much to indent a comment in Icon code
  786. ;; based on its context.
  787. (defun icon-comment-indent ()
  788.   (if (looking-at "^#")
  789.       0                ;Existing comment at bol stays there.
  790.     (save-excursion
  791.       (skip-chars-backward " \t")
  792.       (max (1+ (current-column))    ;Else indent at comment column
  793.        comment-column))))    ; except leave at least one space.
  794.  
  795. (defun electric-icon-brace (arg)
  796.   "Insert character and correct line's indentation."
  797.   (interactive "P")
  798.   (let (insertpos)
  799.     (if (and (not arg)
  800.          (eolp)
  801.          (or (save-excursion
  802.            (skip-chars-backward " \t")
  803.            (bolp))
  804.          (if icon-auto-newline
  805.              (progn (icon-indent-line) (newline) t)
  806.            nil)))
  807.     (progn
  808.       (insert last-command-char)
  809.       (icon-indent-line)
  810.       (if icon-auto-newline
  811.           (progn
  812.         (newline)
  813.         ;; (newline) may have done auto-fill
  814.         (setq insertpos (- (point) 2))
  815.         (icon-indent-line)))
  816.       (save-excursion
  817.         (if insertpos (goto-char (1+ insertpos)))
  818.         (delete-char -1))))
  819.     (if insertpos
  820.     (save-excursion
  821.       (goto-char insertpos)
  822.       (self-insert-command (prefix-numeric-value arg)))
  823.       (self-insert-command (prefix-numeric-value arg)))))
  824.  
  825. (defun icon-indent-command (&optional whole-exp)
  826.   (interactive "P")
  827.   "Indent current line as Icon code, or in some cases insert a tab character.
  828. If icon-tab-always-indent is non-nil (the default), always indent current line.
  829. Otherwise, indent the current line only if point is at the left margin
  830. or in the line's indentation; otherwise insert a tab.
  831.  
  832. A numeric argument, regardless of its value,
  833. means indent rigidly all the lines of the expression starting after point
  834. so that this line becomes properly indented.
  835. The relative indentation among the lines of the expression are preserved."
  836.   (if whole-exp
  837.       ;; If arg, always indent this line as Icon
  838.       ;; and shift remaining lines of expression the same amount.
  839.       (let ((shift-amt (icon-indent-line))
  840.         beg end)
  841.     (save-excursion
  842.       (if icon-tab-always-indent
  843.           (beginning-of-line))
  844.       (setq beg (point))
  845.       (forward-sexp 1)
  846.       (setq end (point))
  847.       (goto-char beg)
  848.       (forward-line 1)
  849.       (setq beg (point)))
  850.     (if (> end beg)
  851.         (indent-code-rigidly beg end shift-amt "#")))
  852.     (if (and (not icon-tab-always-indent)
  853.          (save-excursion
  854.            (skip-chars-backward " \t")
  855.            (not (bolp))))
  856.     (insert-tab)
  857.       (icon-indent-line))))
  858.  
  859. (defun icon-indent-line ()
  860.   "Indent current line as Icon code.
  861. Return the amount the indentation changed by."
  862.   (let ((indent (calculate-icon-indent nil))
  863.     beg shift-amt
  864.     (case-fold-search nil)
  865.     (pos (- (point-max) (point))))
  866.     (beginning-of-line)
  867.     (setq beg (point))
  868.     (cond ((eq indent nil)
  869.        (setq indent (current-indentation)))
  870.       ((eq indent t)
  871.        (setq indent (calculate-icon-indent-within-comment)))
  872.       ((looking-at "[ \t]*#")
  873.        (setq indent 0))
  874.       (t
  875.        (skip-chars-forward " \t")
  876.        (if (listp indent) (setq indent (car indent)))
  877.        (cond ((and (looking-at "else\\b")
  878.                (not (looking-at "else\\s_")))
  879.           (setq indent (save-excursion
  880.                  (icon-backward-to-start-of-if)
  881.                  (current-indentation))))
  882.          ((or (= (following-char) ?})
  883.               (looking-at "end\\b"))
  884.           (setq indent (- indent icon-indent-level)))
  885.          ((= (following-char) ?{)
  886.           (setq indent (+ indent icon-brace-offset))))))
  887.     (skip-chars-forward " \t")
  888.     (setq shift-amt (- indent (current-column)))
  889.     (if (zerop shift-amt)
  890.     (if (> (- (point-max) pos) (point))
  891.         (goto-char (- (point-max) pos)))
  892.       (delete-region beg (point))
  893.       (indent-to indent)
  894.       ;; If initial point was within line's indentation,
  895.       ;; position after the indentation.  Else stay at same point in text.
  896.       (if (> (- (point-max) pos) (point))
  897.       (goto-char (- (point-max) pos))))
  898.     shift-amt))
  899.  
  900. (defun calculate-icon-indent (&optional parse-start)
  901.   "Return appropriate indentation for current line as Icon code.
  902. In usual case returns an integer: the column to indent to.
  903. Returns nil if line starts inside a string, t if in a comment."
  904.   (save-excursion
  905.     (beginning-of-line)
  906.     (let ((indent-point (point))
  907.       (case-fold-search nil)
  908.       state
  909.       containing-sexp
  910.       toplevel)
  911.       (if parse-start
  912.       (goto-char parse-start)
  913.     (setq toplevel (beginning-of-icon-defun)))
  914.       (while (< (point) indent-point)
  915.     (setq parse-start (point))
  916.     (setq state (parse-partial-sexp (point) indent-point 0))
  917.     (setq containing-sexp (car (cdr state))))
  918.       (cond ((or (nth 3 state) (nth 4 state))
  919.          ;; return nil or t if should not change this line
  920.          (nth 4 state))
  921.         ((and containing-sexp
  922.           (/= (char-after containing-sexp) ?{))
  923.          ;; line is expression, not statement:
  924.          ;; indent to just after the surrounding open.
  925.          (goto-char (1+ containing-sexp))
  926.          (current-column))
  927.         (t
  928.           ;; Statement level.  Is it a continuation or a new statement?
  929.           ;; Find previous non-comment character.
  930.           (if toplevel
  931.           (progn (icon-backward-to-noncomment (point-min))
  932.              (if (icon-is-continuation-line)
  933.                  icon-continued-statement-offset 0))
  934.         (if (null containing-sexp)
  935.             (progn (beginning-of-icon-defun)
  936.                (setq containing-sexp (point))))
  937.         (goto-char indent-point)
  938.         (icon-backward-to-noncomment containing-sexp)
  939.         ;; Now we get the answer.
  940.         (if (icon-is-continuation-line)
  941.             ;; This line is continuation of preceding line's statement;
  942.             ;; indent  icon-continued-statement-offset  more than the
  943.             ;; first line of the statement.
  944.             (progn
  945.               (icon-backward-to-start-of-continued-exp containing-sexp)
  946.               (+ icon-continued-statement-offset (current-column)
  947.              (if (save-excursion (goto-char indent-point)
  948.                          (skip-chars-forward " \t")
  949.                          (eq (following-char) ?{))
  950.                  icon-continued-brace-offset 0)))
  951.           ;; This line starts a new statement.
  952.           ;; Position following last unclosed open.
  953.           (goto-char containing-sexp)
  954.           ;; Is line first statement after an open-brace?
  955.           (or
  956.             ;; If no, find that first statement and indent like it.
  957.             (save-excursion
  958.               (if (looking-at "procedure\\s ")
  959.               (forward-sexp 3)
  960.             (forward-char 1))
  961.               (while (progn (skip-chars-forward " \t\n")
  962.                     (looking-at "#"))
  963.             ;; Skip over comments following openbrace.
  964.             (forward-line 1))
  965.               ;; The first following code counts
  966.               ;; if it is before the line we want to indent.
  967.               (and (< (point) indent-point)
  968.                (current-column)))
  969.             ;; If no previous statement,
  970.             ;; indent it relative to line brace is on.
  971.             ;; For open brace in column zero, don't let statement
  972.             ;; start there too.  If icon-indent-level is zero,
  973.             ;; use icon-brace-offset + icon-continued-statement-offset instead.
  974.             ;; For open-braces not the first thing in a line,
  975.             ;; add in icon-brace-imaginary-offset.
  976.             (+ (if (and (bolp) (zerop icon-indent-level))
  977.                (+ icon-brace-offset icon-continued-statement-offset)
  978.              icon-indent-level)
  979.                ;; Move back over whitespace before the openbrace.
  980.                ;; If openbrace is not first nonwhite thing on the line,
  981.                ;; add the icon-brace-imaginary-offset.
  982.                (progn (skip-chars-backward " \t")
  983.                   (if (bolp) 0 icon-brace-imaginary-offset))
  984.                ;; here we are
  985.                (current-indentation))))))))))
  986.  
  987. (defun icon-is-continuation-line ()
  988.   (let* ((ch (preceding-char))
  989.      (ch-syntax (char-syntax ch)))
  990.     (if (eq ch-syntax ?w)
  991.     (assoc (buffer-substring
  992.          (progn (forward-word -1) (point))
  993.          (progn (forward-word 1) (point)))
  994.            '(("do") ("dynamic") ("else") ("initial") ("link")
  995.          ("local") ("of") ("static") ("then")))
  996.       (not (memq ch '(0 ?\; ?\} ?\{ ?\) ?\] ?\" ?\' ?\n))))))
  997.  
  998. (defun icon-backward-to-noncomment (lim)
  999.   (let (opoint stop)
  1000.     (while (not stop)
  1001.       (skip-chars-backward " \t\n\f" lim)
  1002.       (setq opoint (point))
  1003.       (beginning-of-line)
  1004.       (if (and (search-forward "#" opoint 'move)
  1005.            (< lim (point)))
  1006.       (forward-char -1)
  1007.     (setq stop t)))))
  1008.  
  1009. (defun icon-backward-to-start-of-continued-exp (lim)
  1010.   (if (memq (preceding-char) '(?\) ?\]))
  1011.       (forward-sexp -1))
  1012.   (while (icon-is-continued-line)
  1013.     (end-of-line 0))
  1014.   (beginning-of-line)
  1015.   (if (<= (point) lim)
  1016.       (goto-char (1+ lim)))
  1017.   (skip-chars-forward " \t"))
  1018.  
  1019. (defun icon-is-continued-line ()
  1020.   (save-excursion
  1021.     (end-of-line 0)
  1022.     (icon-is-continuation-line)))
  1023.  
  1024. (defun icon-backward-to-start-of-if (&optional limit)
  1025.   "Move to the start of the last ``unbalanced'' if."
  1026.   (or limit (setq limit (save-excursion (beginning-of-icon-defun) (point))))
  1027.   (let ((if-level 1)
  1028.     (case-fold-search nil))
  1029.     (while (not (zerop if-level))
  1030.       (backward-sexp 1)
  1031.       (cond ((looking-at "else\\b")
  1032.          (setq if-level (1+ if-level)))
  1033.         ((looking-at "if\\b")
  1034.          (setq if-level (1- if-level)))
  1035.         ((< (point) limit)
  1036.          (setq if-level 0)
  1037.          (goto-char limit))))))
  1038.  
  1039. (defun mark-icon-function ()
  1040.   "Put mark at end of Icon function, point at beginning."
  1041.   (interactive)
  1042.   (push-mark (point))
  1043.   (end-of-icon-defun)
  1044.   (push-mark (point))
  1045.   (beginning-of-line 0)
  1046.   (beginning-of-icon-defun))
  1047.  
  1048. (defun beginning-of-icon-defun ()
  1049.   "Go to the start of the enclosing procedure; return t if at top level."
  1050.   (interactive)
  1051.   (if (re-search-backward "^procedure\\s \\|^end[ \t\n]" (point-min) 'move)
  1052.       (looking-at "e")
  1053.     t))
  1054.  
  1055. (defun end-of-icon-defun ()
  1056.   (interactive)
  1057.   (if (not (bobp)) (forward-char -1))
  1058.   (re-search-forward "\\(\\s \\|^\\)end\\(\\s \\|$\\)" (point-max) 'move)
  1059.   (forward-word -1)
  1060.   (forward-line 1))
  1061.  
  1062. (defun indent-icon-exp ()
  1063.   "Indent each line of the Icon grouping following point."
  1064.   (interactive)
  1065.   (let ((indent-stack (list nil))
  1066.     (contain-stack (list (point)))
  1067.     (case-fold-search nil)
  1068.     restart outer-loop-done inner-loop-done state ostate
  1069.     this-indent last-sexp
  1070.     at-else at-brace at-do
  1071.     (opoint (point))
  1072.     (next-depth 0))
  1073.     (save-excursion
  1074.       (forward-sexp 1))
  1075.     (save-excursion
  1076.       (setq outer-loop-done nil)
  1077.       (while (and (not (eobp)) (not outer-loop-done))
  1078.     (setq last-depth next-depth)
  1079.     ;; Compute how depth changes over this line
  1080.     ;; plus enough other lines to get to one that
  1081.     ;; does not end inside a comment or string.
  1082.     ;; Meanwhile, do appropriate indentation on comment lines.
  1083.     (setq innerloop-done nil)
  1084.     (while (and (not innerloop-done)
  1085.             (not (and (eobp) (setq outer-loop-done t))))
  1086.       (setq ostate state)
  1087.       (setq state (parse-partial-sexp (point) (progn (end-of-line) (point))
  1088.                       nil nil state))
  1089.       (setq next-depth (car state))
  1090.       (if (and (car (cdr (cdr state)))
  1091.            (>= (car (cdr (cdr state))) 0))
  1092.           (setq last-sexp (car (cdr (cdr state)))))
  1093.       (if (or (nth 4 ostate))
  1094.           (icon-indent-line))
  1095.       (if (or (nth 3 state))
  1096.           (forward-line 1)
  1097.         (setq innerloop-done t)))
  1098.     (if (<= next-depth 0)
  1099.         (setq outer-loop-done t))
  1100.     (if outer-loop-done
  1101.         nil
  1102.       (if (/= last-depth next-depth)
  1103.           (setq last-sexp nil))
  1104.       (while (> last-depth next-depth)
  1105.         (setq indent-stack (cdr indent-stack)
  1106.           contain-stack (cdr contain-stack)
  1107.           last-depth (1- last-depth)))
  1108.       (while (< last-depth next-depth)
  1109.         (setq indent-stack (cons nil indent-stack)
  1110.           contain-stack (cons nil contain-stack)
  1111.           last-depth (1+ last-depth)))
  1112.       (if (null (car contain-stack))
  1113.           (setcar contain-stack (or (car (cdr state))
  1114.                     (save-excursion (forward-sexp -1)
  1115.                             (point)))))
  1116.       (forward-line 1)
  1117.       (skip-chars-forward " \t")
  1118.       (if (eolp)
  1119.           nil
  1120.         (if (and (car indent-stack)
  1121.              (>= (car indent-stack) 0))
  1122.         ;; Line is on an existing nesting level.
  1123.         ;; Lines inside parens are handled specially.
  1124.         (if (/= (char-after (car contain-stack)) ?{)
  1125.             (setq this-indent (car indent-stack))
  1126.           ;; Line is at statement level.
  1127.           ;; Is it a new statement?  Is it an else?
  1128.           ;; Find last non-comment character before this line
  1129.           (save-excursion
  1130.             (setq at-else (looking-at "else\\W"))
  1131.             (setq at-brace (= (following-char) ?{))
  1132.             (icon-backward-to-noncomment opoint)
  1133.             (if (icon-is-continuation-line)
  1134.             ;; Preceding line did not end in comma or semi;
  1135.             ;; indent this line  icon-continued-statement-offset
  1136.             ;; more than previous.
  1137.             (progn
  1138.               (icon-backward-to-start-of-continued-exp (car contain-stack))
  1139.               (setq this-indent
  1140.                 (+ icon-continued-statement-offset (current-column)
  1141.                    (if at-brace icon-continued-brace-offset 0))))
  1142.               ;; Preceding line ended in comma or semi;
  1143.               ;; use the standard indent for this level.
  1144.               (if at-else
  1145.               (progn (icon-backward-to-start-of-if opoint)
  1146.                  (setq this-indent (current-indentation)))
  1147.             (setq this-indent (car indent-stack))))))
  1148.           ;; Just started a new nesting level.
  1149.           ;; Compute the standard indent for this level.
  1150.           (let ((val (calculate-icon-indent
  1151.                (if (car indent-stack)
  1152.                    (- (car indent-stack))))))
  1153.         (setcar indent-stack
  1154.             (setq this-indent val))))
  1155.         ;; Adjust line indentation according to its contents
  1156.         (if (or (= (following-char) ?})
  1157.             (looking-at "end\\b"))
  1158.         (setq this-indent (- this-indent icon-indent-level)))
  1159.         (if (= (following-char) ?{)
  1160.         (setq this-indent (+ this-indent icon-brace-offset)))
  1161.         ;; Put chosen indentation into effect.
  1162.         (or (= (current-column) this-indent)
  1163.         (progn
  1164.           (delete-region (point) (progn (beginning-of-line) (point)))
  1165.           (indent-to this-indent)))
  1166.         ;; Indent any comment following the text.
  1167.         (or (looking-at comment-start-skip)
  1168.         (if (re-search-forward comment-start-skip (save-excursion (end-of-line) (point)) t)
  1169.             (progn (indent-for-comment) (beginning-of-line))))))))))
  1170.  
  1171.  
  1172. From ihnp4!ihuxy!nowlin  Tue Jun  7 14:41:36 1988
  1173. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 7 Jun 88 14:41:36 MST
  1174. From: ihnp4!ihuxy!nowlin
  1175. Message-Id: <8806072141.AA04747@megaron.arizona.edu>
  1176. Received: by megaron.arizona.edu; Tue, 7 Jun 88 14:41:35 MST
  1177. Received: by ihnp4.ATT.COM id AA24607; 7 Jun 88 09:23:16 CDT (Tue)
  1178. Message-Version: 2
  1179. >To: /addr=ihnp4!arizona!icon-group
  1180. Date: Tue 07 Jun 1988 09:18 CDT
  1181. End-Of-Header: 
  1182. Email-Version: 2
  1183. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  1184. To: arizona!icon-group
  1185. Subject: Icon has its place
  1186. Ua-Message-Id: <post.nowlin.Tue 07 Jun 1988 08:25 CDT>
  1187. End-Of-Protocol: 
  1188. Content-Length: 1668
  1189.  
  1190. I noticed this little message fly by this morning and couldn't let it go
  1191. without comment.
  1192.  
  1193. > From: olivier lecarme <ihnp4!arizona!mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET>
  1194. > Subject: icon-mode for GNU Emacs?
  1195. > I have exactly the same need as you, and the same difficulties (disgust
  1196. > ?) with C programming...
  1197.  
  1198. Icon is just one of many programming languages.  It is by far my favorite.
  1199. Any new projects I start I try to do in Icon, but Icon is not suited for
  1200. some projects.  If Icon could do everything Icon would be written in Icon. 
  1201. It's written in C.  Don't disparage other languages because they aren't as
  1202. easy to program in as Icon.
  1203.  
  1204. Computer languages have their niches just like living things.  As the
  1205. natural environment changes new niches are created and new species evolve
  1206. to fill those niches.  Todays computing environments are changing and the
  1207. need for a language like Icon is obvious.  That won't make other languages
  1208. extinct.  Their niches still exist and Icon can't compete with them in
  1209. their niches for a number of reasons.
  1210.  
  1211. I see the main niche for Icon as a UNIX language that falls between shell
  1212. and C in terms of power and ease of use.  It's string handling capabilities
  1213. make it a good candidate for the kinds of work that are frequently done
  1214. with UNIX tools like sed and grep and with some of the more arcane UNIX
  1215. languages like awk, lex and yacc.  The main concern over using Icon in some
  1216. of these applications is its execution speed.  It's a valid concern.
  1217.  
  1218. How about some comments from others on areas where Icon can hold its own
  1219. with more traditional languages and areas where Icon just can't compete.
  1220.  
  1221. Jerry Nowlin
  1222. (...!ihnp4!ihuxy!nowlin)
  1223.  
  1224. From R.J.Hare@EDINBURGH.AC.UK  Tue Jun 14 13:05:14 1988
  1225. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 14 Jun 88 13:05:14 MST
  1226. Message-Id: <8806142005.AA19540@megaron.arizona.edu>
  1227. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu; Tue, 14 Jun 88 13:05:11 MST
  1228. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Tue, 14 Jun 88 12:56 MST
  1229. Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 6009; Tue,
  1230.  14 Jun 88 16:10:18 BST
  1231. Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 6003; Tue, 14
  1232.  Jun 88 16:10:12 BS
  1233. Date: 14 Jun 88  16:09:12 bst
  1234. From: R.J.Hare@EDINBURGH.AC.UK
  1235. Subject: Icon V7
  1236. To: icon-group@arizona.edu
  1237. Via:      UK.AC.ED.EMAS-C; 14 JUN 88 16:10:09 BST
  1238. Comments: This one seems to have fallen down a black hole somewhere, so I'll
  1239.  try again
  1240.  
  1241.  Roger Hare.
  1242. Message-ID: <14 Jun 88  16:09:12 bst  340171@EMAS-C>
  1243.  
  1244. --- Forwarded message:
  1245.  
  1246. Subject:  Icon V7
  1247. From:     R.J.Hare <ERCY02@uk.ac.edinburgh.emas-c>
  1248. Date:     19 May 88  11:38:42 bst
  1249. To:       icon-group%edu.arizona@rl.earn
  1250. Msg ID:   <19 May 88  11:38:42 bst  340257@EMAS-C>
  1251.  
  1252. A few observations/queries re Icon V7 if I may:
  1253.  
  1254. 1) DOS version works fine
  1255.  
  1256. 2) VMS version - tape was v difficult to read but we managed eventually
  1257.  
  1258. 3) DOS version behaves as V6 when using ICONT, namely routine names and sizes
  1259.    are displayed at the terminalas they are translated, VMS version does not
  1260.    appear to do this, which is a bit disconcerting (it took me a couple of
  1261.    hours digging and delving - see below) before I realised that the brute
  1262.    actually *was* working. Is there any way of switching on this informative
  1263.    monologue when using ICONT on VMS? (I have read the instructions, but
  1264.    couldn't find anything about this - maybe I missed it?)
  1265.  
  1266. 4) As a result of V7 (apparently) not working, I first tried to re-link the
  1267.    whole system as described in the docs, and got a message relating to VMS's
  1268.    inability to find file RROOT:[V33]RSWITCH.OBJ, which in fact was present
  1269.    (as far as I could see) as file [ERCY02.ICON.V7.SRC.ICONX]RSWITCH.OBJ (I
  1270.    have my Icon material in the directory [ERCY02.ICON]. When I tried to
  1271.    rebuild from scratch using @MAKE, I got a message relating to the inability
  1272.    of the system to find file RROOT:[V33]INPUTFILE.C, which also seemed to be
  1273.    present as [ERCY02.ICON.V7.SRC.ICONX]INPUTFILE.C. Subsequent to this, of
  1274.    course, I discovered that the system was working albeit silently, but it
  1275.    would be nice to know what is happening here?
  1276.  
  1277. 5) Once I discovered that V7 was working, I did the tests (maybe I should have
  1278.    done those first!) @TEST and @IPLTEST and both worked.
  1279.  
  1280. Any comments/advice about the 'silence' of ICONT on VMS would be appreciated.
  1281.  
  1282. Many thanks, and apologies in advance, if all this is in the documentation and
  1283. I just missed it.
  1284.  
  1285. Roger Hare
  1286.  
  1287. --- End of forwarded message
  1288.  
  1289. From gmt  Tue Jun 14 16:16:09 1988
  1290. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 14 Jun 88 16:16:09 MST
  1291. Date: Tue, 14 Jun 88 16:16:07 MST
  1292. From: "Gregg Townsend" <gmt>
  1293. Message-Id: <8806142316.AA07367@megaron.arizona.edu>
  1294. Received: by megaron.arizona.edu; Tue, 14 Jun 88 16:16:07 MST
  1295. In-Reply-To: <8806142005.AA19540@megaron.arizona.edu>
  1296. To: icon-group
  1297. Subject: Silent translation under VMS
  1298.  
  1299. [ R. J. Hare wonders why Icon V7 under VMS doesn't display a commentary while
  1300.   translating, as does DOS Icon and as did V6 under VMS. ]
  1301.  
  1302. Actually, I didn't realize that it didn't.  It's supposed to, and we didn't
  1303. make any deliberate changes there.  I logged into the nearest VMS machine,
  1304. typed "icont file.icn", and got the commentary as expected.
  1305.  
  1306. So then I tried some other experiments and found out a couple of ways to
  1307. lose the commentary:
  1308.  
  1309. (1)  If you "DEFINE/USER SYS$ERROR filename", the file gets only the 
  1310.      "Translating:" and "Linking:" messages;  the detailed commentary
  1311.      giving procedure names is lost.  Those two messages aren't issued
  1312.      for "icont -c", so you don't see anything in that case.  This probably
  1313.      has something to do with the C library's implementation of vfork.
  1314.  
  1315. (2)  If you give a flag such as "-Sg100", and forget to quote it, it's
  1316.      interpreted as "-s" which silences the commentary.  The "g100"
  1317.      part is ignored (yes, that's a bug).
  1318.  
  1319. To summarize: the commentary is supposed to be there, but there are at
  1320. least two simple ways to lose it inadvertently.
  1321.  
  1322. As for the build problems referencing RROOT:[V33], I'm at a loss to explain
  1323. those.  The default directory is supposed to be [...V7.SRC.ICONX] at the
  1324. time RSWITCH.OBJ is used, and it's referenced without a directory spec.
  1325. [If you're interested in pursuing this further I'll try to help;  but I'd
  1326. suggest mailing to icon-project instead of icon-group, because the whole
  1327. mailing list probably doesn't want to hear all the gory details.]
  1328.  
  1329.      Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  1330.      +1 602 621 4325      gmt@Arizona.EDU       110 57 16 W / 32 13 45 N / +758m
  1331.  
  1332. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Fri Jun 24 19:18:58 1988
  1333. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 24 Jun 88 19:18:58 MST
  1334. Received: from sphinx.uchicago.edu by megaron.arizona.edu; Fri, 24 Jun 88 19:18:47 MST
  1335. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  1336.     id AA00973; Fri, 24 Jun 88 21:13:48 CDT
  1337. Return-Path: <goer@sophist.uchicago.edu>
  1338. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  1339.     id AA04660; Fri, 24 Jun 88 21:11:48 CDT
  1340. Date: Fri, 24 Jun 88 21:11:48 CDT
  1341. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  1342. Message-Id: <8806250211.AA04660@sophist.uchicago.edu>
  1343. To: icon-group@arizona.edu
  1344. Subject: Snobol vs. Icon
  1345.  
  1346. I keep hearing about the wonderful translation, parsing, and concording
  1347. programs that can be done using Snobol4.  Is anyone doing this sort of
  1348. thing in Icon yet?  Planning to?
  1349.  
  1350. In my case, Icon has become my natural language processing tool *par
  1351. excellance*.  Usually, I use it to normalize and parse biblical Hebrew.
  1352. I also use it for complicated searches - ones that are difficult to do
  1353. using regular expressions.
  1354.  
  1355. I am just curious about whether anyone else is doing this sort of thing.
  1356. As I mentioned, most folks that I know in the Humanities don't know about
  1357. Icon.  Some know/use Snobol.  I want to find out if anyone out there
  1358. is doing things in Icon.
  1359.  
  1360.                                                   -Richard L. Goerwitz
  1361.                                                   goer@sophist.uchicago.edu
  1362.                                                   !ihnp4!gargoyle!sophist!goer
  1363.  
  1364. From icon-group-request  Fri Jun 24 23:43:41 1988
  1365. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 24 Jun 88 23:43:41 MST
  1366. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Fri, 24 Jun 88 23:43:31 MST
  1367. Received: by ucbvax.Berkeley.EDU (5.59/1.28)
  1368.     id AA13125; Fri, 24 Jun 88 10:45:39 PDT
  1369. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1370.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1371.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1372. Date: 24 Jun 88 17:05:28 GMT
  1373. From: orion!ics.uci.edu!nagel@ucsd.edu  (Mark Nagel)
  1374. Organization: University of California, Irvine - Dept. of ICS
  1375. Subject: need sun4 rswitch.c help
  1376. Message-Id: <723@orion.cf.uci.edu>
  1377. Sender: icon-group-request@arizona.edu
  1378. To: icon-group@arizona.edu
  1379.  
  1380. Hi there.  I am attempting to create the config directory for v7 Icon for the
  1381. Sun 4 SPARC architecture.  I have gotten almost everything to work including
  1382. overflow detection, but I can't seem to get the coexpression stuff to work
  1383. correctly.  Is there anyone out there who has done this?  Maybe someone out
  1384. there can tell me I'm wasting my time and that you can't move the stack 
  1385. around on the SPARC?  Anyway, please email me any suggestions/answers if
  1386. you can.
  1387.  
  1388. --
  1389. Mark D. Nagel
  1390. Department of Information and Computer Science, UC Irvine
  1391. nagel@ics.uci.edu             (ARPA)                I'm not a graduate student,
  1392. {sdcsvax|ucbvax}!ucivax!nagel (UUCP)                but I play one on TV...
  1393.  
  1394. From GGRCS@UNO.BITNET  Mon Jun 27 02:32:31 1988
  1395. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 27 Jun 88 02:32:31 MST
  1396. Message-Id: <8806270932.AA26548@megaron.arizona.edu>
  1397. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu; Mon, 27 Jun 88 02:32:29 MST
  1398. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Mon, 27 Jun 88 02:28 MST
  1399. Date: Mon, 27 Jun 88 04:12 CDT
  1400. From: GGRCS@UNO.BITNET
  1401. Subject: ICON group subscription
  1402. To: icon-group@arizona.edu
  1403. X-Original-To:  icon-group@arizona.edu
  1404.  
  1405. Dear Sirs,
  1406.  
  1407.         I would like to become a member of any ICON-related user/discussion
  1408. groups that are available.
  1409.  
  1410.  
  1411.                                         Thanks,
  1412.                                         Golden Richard III
  1413.                                         CS Dept. @ University of New Orleans
  1414.  
  1415.  
  1416.  
  1417. Net address:  GGRCS @ UNO.BITNET
  1418.  
  1419.  
  1420.  
  1421.  
  1422. From UNOCC07%zeus@crcvms.unl.edu  Tue Jul  5 12:25:54 1988
  1423. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 5 Jul 88 12:25:54 MST
  1424. Message-Id: <8807051504.AA13951@megaron.arizona.edu>
  1425. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59/MRM1.3) via SMTP
  1426.     id AA13951; Tue, 5 Jul 88 08:04:12 MST
  1427. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Tue, 5 Jul 88 07:52 MST
  1428. Date: Sun, 3 Jul 88 18:53 CDT
  1429. From: "Many people would rather die than think; in fact, most do."
  1430.  <UNOCC07%zeus@crcvms.unl.edu>
  1431. Subject: Tables referenced by lists
  1432. To: icon-group@arizona.edu
  1433. X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
  1434.  
  1435. Consider the following (very) short program:
  1436.  
  1437. procedure main()
  1438.   t := table()
  1439.   t[[2,3]] := "Hi there"
  1440.   write("this is it :",t[[2,3]],".")
  1441. end
  1442.  
  1443. It's output is:
  1444.  
  1445. this is it :.
  1446.  
  1447. Why?  [2,3] is not the same list as [2,3] in the 4th line?  If not, what can
  1448. I do about it?  I suppose I could convert it to a string... that would work,
  1449. but I'm not sure I understand why indexing the table by a string would
  1450. work (in the case of literals) but not a list...?
  1451.  
  1452. I'm confused, I guess. :-)
  1453.  
  1454. -/ Dave Caplinger /---------------+--------------------------------------------
  1455.   Microcomputer Specialist        | Internet: unocc07%zeus.dnet@fergvax.unl.edu
  1456.   Campus Computing                | uucp:     uunet!mcmi!unocss!dent
  1457.   University of Nebraska at Omaha | Bitnet:   UNOCC07@UNOMA1
  1458.   Omaha, NE 68182                 | (Last Resort: dc3a+@andrew.cmu.edu)
  1459.  
  1460.  
  1461. From gudeman  Thu Jul  7 10:20:37 1988
  1462. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 7 Jul 88 10:20:37 MST
  1463. Date: Thu, 7 Jul 88 10:18:02 MST
  1464. From: "David Gudeman" <gudeman>
  1465. Message-Id: <8807071718.AA27618@megaron.arizona.edu>
  1466. Received: by megaron.arizona.edu (5.59/MRM1.4)
  1467.     id AA27618; Thu, 7 Jul 88 10:18:02 MST
  1468. To: UNOCC07%zeus@crcvms.unl.edu
  1469. Cc: icon-group@arizona.edu
  1470. In-Reply-To: <8807051504.AA13951@megaron.arizona.edu>
  1471. Subject: Tables referenced by lists
  1472.  
  1473. >Date: Sun, 3 Jul 88 18:53 CDT
  1474. >From: <UNOCC07%zeus@crcvms.unl.edu>
  1475. >
  1476. >Consider the following (very) short program:
  1477. >
  1478. >procedure main()
  1479. >  t := table()
  1480. >  t[[2,3]] := "Hi there"
  1481. >  write("this is it :",t[[2,3]],".")
  1482. >end
  1483. >
  1484. >It's output is:
  1485. >
  1486. >this is it :.
  1487. >
  1488. >Why?  [2,3] is not the same list as [2,3] in the 4th line?...
  1489.  
  1490. That's a fun one isn't it?  The problem is that Icon treats strings
  1491. and lists differently.  A string in Icon is a fixed object.  For
  1492. example:
  1493.  
  1494.     s1 := "abc"
  1495.     s2 := s1
  1496.     s1[1] := "x"
  1497.     write(s1,s2)
  1498.  
  1499. writes out `xbcabc'.  When you executed s1[1] := "x", you didn't
  1500. actually change the string "abc" into the string "xbc", what you
  1501. really did was create a new string "xbc" and assign that string to s1.
  1502. Other variables that have the value "abc" are not changed.  Since
  1503. strings are fixed in Icon, we also say that all strings that look the
  1504. same _are_ the same.  So it is always true that "abc" === "abc".
  1505.  
  1506. Lists are not fixed.  For example:
  1507.  
  1508.     L1 := [1,2,3]
  1509.     L2 := L1
  1510.     L1[1] := 9
  1511.     every writes(!L1)
  1512.     every writes(!L2)
  1513.  
  1514. writes out `923932'.  The execution of L1[1] := 9 changed both L1 and
  1515. L2 because it actually changed the list [1,2,3] into the list [9,2,3].
  1516. But if you had written:
  1517.  
  1518.     L1 := [1,2,3]
  1519.     L2 := [1,2,3]
  1520.  
  1521. you certainly don't want the expression L1[1] := 9 to change L2!  L1
  1522. and L2 are two _different_ lists that just happen to contain the same
  1523. elements.  So that's the difference that causes problems with table
  1524. references, whenever you write "abc" you always get the same string,
  1525. but whenever you write [1,2,3] you always get a _different_ list.  So
  1526. change your example to
  1527.  
  1528.       procedure main()
  1529.     t := table()
  1530.     L := [2,3]
  1531.     t[L] := "Hi there"
  1532.     write("this is it :",t[L],".")
  1533.       end
  1534.  
  1535. And you will get the output `this is it :Hi there.' as you expected.
  1536. Since I only wrote [2,3] once, there is only one list [2,3] so the
  1537. table reference works.  What was happening before was that you were
  1538. putting the string "Hi there" into the table with the key [2,3], and
  1539. then trying to access it with a _different_ list that also happened to
  1540. look like [2,3].
  1541.  
  1542. One more thing, I sort of lied when I said that every time you write
  1543. [1,2,3] you get a new list.  If you write an expression like:
  1544.  
  1545.     repeat {
  1546.         x := [1,2]
  1547.         <do something with x>
  1548.         }
  1549.  
  1550. x will be a new list every time through the loop.  The truth is that
  1551. every time an expression like [1,2] is _executed_ you get a new list.
  1552.  
  1553. From UNOCC07%zeus@crcvms.unl.edu  Wed Jul 13 15:49:27 1988
  1554. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 13 Jul 88 15:49:27 MST
  1555. Message-Id: <8807132249.AA14193@megaron.arizona.edu>
  1556. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59/MRM1.4) via SMTP
  1557.     id AA14193; Wed, 13 Jul 88 15:49:24 MST
  1558. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 13 Jul 88 14:30 MST
  1559. Date: Wed, 13 Jul 88 15:36 CDT
  1560. From: "Many people would rather die than think; in fact, most do."
  1561.  <UNOCC07%zeus@crcvms.unl.edu>
  1562. Subject: Some idle speculation...
  1563. To: icon-group@arizona.edu
  1564. X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
  1565.  
  1566. An idle speculation...
  1567.  
  1568. -- Fair Warning: This is entirely speculation, is not necessarily
  1569.    intended to resemble anything, etc etc.  Laugh if you wish. :-)
  1570.  
  1571. If Icon were to operating system "x" as C is to UNIX, what would operating
  1572. system "x" be like?  Would it be worth it?  Regardless of my meager knowledge
  1573. of Icon, let me speculate "just for laughs".  There isn't much traffic in
  1574. the icon group now anyway. :-)
  1575.  
  1576. Icon for Systems Programming:
  1577.  
  1578.         Since I don't do systems programming, it's hard for me to say
  1579.         just what is and isn't necessary (or simply convenient) to
  1580.         accomplish any system programming "goals" effectively, but I'd
  1581.         hazard a guess that Icon can indeed accomplish a large subset
  1582.         of what C can do, excluding bitfields and unions.  Should Icon
  1583.         have these types of functions?  But then, the Macintosh (shudder!)
  1584.         operating system was originally written entirely in Pascal of
  1585.         all things, and Icon can certainly accomplish anything Pascal
  1586.         can.  So, let's assume that using Icon for operating system
  1587.         development is at least feasible.  Let us also assume for simplicity
  1588.         that we have a machine that will run icode directly, analogous to
  1589.         Wirth's Lilith (sp?) machine (which runs either Pascal or Modula 2,
  1590.         I don't remember).
  1591.  
  1592. Hypothetical Operating System (HOS):
  1593.  
  1594.         I would assume that the primary purpose of an operating system
  1595.         would be (at it's simplest) a file structure and control
  1596.         operations for manipulating "files", and (more complex)
  1597.         process structure and control.  (But since I haven't actually
  1598.         designed my own operating system, etc etc. :-)
  1599.  
  1600.         Some basic file manipulation examples for HOS might be:
  1601.  
  1602.         copy file1[4:-4] ||file2
  1603.  
  1604.         Which, I suppose, might take everything in file1 starting at
  1605.         the 4th line/record until the 4th line/record from the end and
  1606.         append it to file2.  Syntax of course is negotiable. :-)
  1607.  
  1608.         print (file1 | defaultfile)
  1609.  
  1610.         Which might print file1 or the defualt file, as you might expect.
  1611.  
  1612. What Conclusion? :
  1613.  
  1614.         Anyway, I haven't really thought about it much, but figured it
  1615.         might be entertaining to ponder this for a while.  I think it all
  1616.         started when I was sitting in CS-2980, "C Programming" when I
  1617.         was regretting knowning Icon already :-) because of things like
  1618.         C's " b = 4 " returning 1 instead of 4 when used in a test...
  1619.  
  1620. But anyway... what do you think?  Ponder, duscuss, ignore, flame, etc...
  1621.  
  1622. -/ Dave Caplinger /---------------+--------------------------------------------
  1623.   Microcomputer Specialist        | Internet: unocc07%zeus.dnet@fergvax.unl.edu
  1624.   Campus Computing                | uucp:     uunet!mcmi!unocss!dent
  1625.   University of Nebraska at Omaha | Bitnet:   UNOCC07@UNOMA1
  1626.   Omaha, NE 68182                 | (Last Resort: dc3a+@andrew.cmu.edu)
  1627.  
  1628.  
  1629. From UNOCC07%zeus@crcvms.unl.edu  Wed Jul 13 17:50:35 1988
  1630. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 13 Jul 88 17:50:35 MST
  1631. Message-Id: <8807140050.AA21092@megaron.arizona.edu>
  1632. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59/MRM1.4) via SMTP
  1633.     id AA21092; Wed, 13 Jul 88 17:50:33 MST
  1634. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 13 Jul 88 16:38 MST
  1635. Date: Wed, 13 Jul 88 17:52 CDT
  1636. From: "Many people would rather die than think; in fact, most do."
  1637.  <UNOCC07%zeus@crcvms.unl.edu>
  1638. Subject: Possible Icon Addition?
  1639. To: icon-group@arizona.edu
  1640. X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
  1641.  
  1642. This is in no way related to that last posting...
  1643.  
  1644. I was wondering, would it be reasonable to want a facility in Icon for
  1645. sharing variables between two or more procedures?  I'm thinking of something
  1646. like:
  1647.  
  1648. procedure something()
  1649. local x,y
  1650. static x
  1651. common y with other1,other2
  1652. ...
  1653. end
  1654.  
  1655. where "other1", and "other2" are procedures elsewhere in either the same
  1656. file or a file linked in via "link ufile".
  1657.  
  1658. I suppose that "other1" and "other2" would have to have similar statements
  1659. specifying a variable "y" shared with the other two routines...  But there's
  1660. no reason that "x" can't be a static variable common to four routines that
  1661. all might need to see it but without the calling routine having to set up
  1662. co-routines, global variables, etc.
  1663.  
  1664. No, no, don't tell me... is this similar to "Object-Oriented", or even just
  1665. a facet of it?  Either way, I certainly think it would be usefull.
  1666.  
  1667. -/ Dave Caplinger /---------------+--------------------------------------------
  1668.   Microcomputer Specialist        | Internet: unocc07%zeus.dnet@fergvax.unl.edu
  1669.   Campus Computing                | uucp:     uunet!mcmi!unocss!dent
  1670.   University of Nebraska at Omaha | Bitnet:   UNOCC07@UNOMA1
  1671.   Omaha, NE 68182                 | (Last Resort: dc3a+@andrew.cmu.edu)
  1672.  
  1673.  
  1674. From sunquest!whm  Wed Jul 13 18:46:48 1988
  1675. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 13 Jul 88 18:46:48 MST
  1676. Received: by megaron.arizona.edu (5.59/MRM1.4)
  1677.     id AA24787; Wed, 13 Jul 88 18:46:47 MST
  1678. Date: Wed, 13 Jul 88 18:41:59 MST
  1679. From: "Bill Mitchell" <sunquest!whm>
  1680. Message-Id: <8807140141.AA23718@sunquest>
  1681. Received: by sunquest; Wed, 13 Jul 88 18:41:59 MST
  1682. To: arizona!icon-group
  1683. Subject: Re:  Possible Icon Addition?
  1684.  
  1685. It looks like what you're wanting is a way to have several procedures share
  1686. data, but you don't want to clutter up the name space with more global
  1687. variables.
  1688.  
  1689. There's been talk in the past about ways to do this, including something
  1690. like C's "static" globals, which are only known in the current file, but
  1691. although C's facility works ok in practice, some persons would prefer a
  1692. solution that isn't based on files.
  1693.  
  1694. I think it would be pretty simple to implement a C-like solution (I'd guess
  1695. 2-3 man days counting ground work, implementation, and documentation), but I
  1696. don't know that there's much Icon Project time for such excursions.  I'd rather
  1697. have a simple-minded facility to use now and then possibly convert to a more
  1698. robust facility at some point in the future than to have no facility at all.
  1699.  
  1700.                 Bill Mitchell
  1701.                 Sunquest Information Systems, Tucson, AZ
  1702.                 sunquest!whm@arizona.edu
  1703.                 uunet!sunquest!whm
  1704.                 {allegra,cmcl2,noao}!arizona!sunquest!whm
  1705.  
  1706. From icon-group-request  Thu Jul 14 22:38:05 1988
  1707. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 14 Jul 88 22:38:05 MST
  1708. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59/MRM1.4) via SMTP
  1709.     id AA15717; Thu, 14 Jul 88 22:37:51 MST
  1710. Received: by ucbvax.Berkeley.EDU (5.59/1.28)
  1711.     id AA27445; Thu, 14 Jul 88 21:36:53 PDT
  1712. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1713.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1714.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1715. Date: 14 Jul 88 23:07:22 GMT
  1716. From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU  (00704a-Liber)
  1717. Organization: AT&T Bell Laboratories - Naperville, Illinois
  1718. Subject: Re: Possible Icon Addition?
  1719. Message-Id: <5295@ihlpf.ATT.COM>
  1720. References: <8807140050.AA21092@megaron.arizona.edu>
  1721. Sender: icon-group-request@arizona.edu
  1722. To: icon-group@arizona.edu
  1723.  
  1724. In article <8807140050.AA21092@megaron.arizona.edu> UNOCC07%zeus@crcvms.unl.EDU ("Many people would rather die than think; in fact, most do.") writes:
  1725.  
  1726. >I was wondering, would it be reasonable to want a facility in Icon for
  1727. >sharing variables between two or more procedures?
  1728.  
  1729. This is definitely something that would be handy!  All too often I either
  1730. have to use a lot of globals or pass a list of the stuff I want a few
  1731. procedures to share.
  1732.  
  1733. The 'C' mechanism (variables declared 'static' in a file but not inside a
  1734. function declaration can only be seen within that file) would be an
  1735. adequate way of doing this, but I would prefer one which wasn't based on
  1736. files and one that looks a little more like it fits in Icon (although I
  1737. can't think of a better way right now).
  1738. -- 
  1739.  _ __            NEVIN J. LIBER    ..!att!ihlpf!nevin1    (312) 979-????
  1740. ' )  )                You are in a little maze of twisty
  1741.  /  / _ , __o  ____         email paths, all different.
  1742. /  (_</_\/ <__/ / <_    These are solely MY opinions, not AT&T's, blah blah blah
  1743.  
  1744. From icon-group-request  Thu Jul 14 22:39:21 1988
  1745. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 14 Jul 88 22:39:21 MST
  1746. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59/MRM1.4) via SMTP
  1747.     id AA15861; Thu, 14 Jul 88 22:39:05 MST
  1748. Received: by ucbvax.Berkeley.EDU (5.59/1.28)
  1749.     id AA27377; Thu, 14 Jul 88 21:33:52 PDT
  1750. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1751.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1752.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1753. Date: 14 Jul 88 23:02:16 GMT
  1754. From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU  (00704a-Liber)
  1755. Organization: AT&T Bell Laboratories - Naperville, Illinois
  1756. Subject: Re: Some idle speculation...
  1757. Message-Id: <5294@ihlpf.ATT.COM>
  1758. References: <8807132249.AA14193@megaron.arizona.edu>
  1759. Sender: icon-group-request@arizona.edu
  1760. To: icon-group@arizona.edu
  1761.  
  1762. In article <8807132249.AA14193@megaron.arizona.edu> UNOCC07%zeus@crcvms.unl.EDU ("Many people would rather die than think; in fact, most do.") writes:
  1763. |Icon for Systems Programming:
  1764.  
  1765. |        Since I don't do systems programming, it's hard for me to say
  1766. |        just what is and isn't necessary (or simply convenient) to
  1767. |        accomplish any system programming "goals" effectively, but I'd
  1768. |        hazard a guess that Icon can indeed accomplish a large subset
  1769. |        of what C can do, excluding bitfields and unions.
  1770.  
  1771. There is no need to have unions in Icon, since variables are allowed to
  1772. take on any value.  And you can do bitfields if you're clever. :-)
  1773.  
  1774. |        But then, the Macintosh (shudder!)
  1775. |        operating system was originally written entirely in Pascal of
  1776. |        all things, and Icon can certainly accomplish anything Pascal
  1777. |        can.
  1778.  
  1779. Wasn't it done in an object-oriented version of Pascal (help, Darin :-))?
  1780. Icon does not (yet) have object-oriented extensions.
  1781.  
  1782. |Hypothetical Operating System (HOS):
  1783.  
  1784. |        Some basic file manipulation examples for HOS might be:
  1785.  
  1786. |        copy file1[4:-4] ||file2
  1787.  
  1788. |        Which, I suppose, might take everything in file1 starting at
  1789. |        the 4th line/record until the 4th line/record from the end and
  1790. |        append it to file2.  Syntax of course is negotiable. :-)
  1791.  
  1792. |        print (file1 | defaultfile)
  1793.  
  1794. |        Which might print file1 or the defualt file, as you might expect.
  1795.  
  1796. It seems to me that you would like to use Icon as a shell-type language.
  1797. For me, most of the stuff I use to write in sh I now right in Icon because
  1798. it is a LOT easier.
  1799.  
  1800. |What Conclusion? :
  1801.  
  1802. |        I think it all
  1803. |        started when I was sitting in CS-2980, "C Programming" when I
  1804. |        was regretting knowning Icon already :-) because of things like
  1805. |        C's " b = 4 " returning 1 instead of 4 when used in a test...
  1806.  
  1807. C's " b = 4" returns 4, not 1, when used as a test (in an 'if' statement).
  1808. Did you mean the '==' operator (and I thought Icon's operators were
  1809. confusing :-))?
  1810.  
  1811. |But anyway... what do you think?  Ponder, duscuss, ignore, flame, etc...
  1812.  
  1813. As a shell language, Icon is preferable to anything else I use now.  But
  1814. until some object-oriented extensions come along for Icon, I would prefer
  1815. to use a language like C++ for systems programming.  (But for everything
  1816. else, Icon all the way! :-) :-))
  1817. -- 
  1818.  _ __            NEVIN J. LIBER    ..!att!ihlpf!nevin1    (312) 979-????
  1819. ' )  )                You are in a twisty little maze of
  1820.  /  / _ , __o  ____         email paths, all different.
  1821. /  (_</_\/ <__/ / <_    These are solely MY opinions, not AT&T's, blah blah blah
  1822.  
  1823. From rich%sendai.uucp@umix.cc.umich.edu  Thu Jul 14 23:03:07 1988
  1824. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 14 Jul 88 23:03:07 MST
  1825. Received: from a.cc.umich.edu by megaron.arizona.edu (5.59/MRM1.4) via SMTP
  1826.     id AA17225; Thu, 14 Jul 88 23:03:01 MST
  1827. Received: from umix.cc.umich.edu by a.cc.umich.edu (5.59/1.0)
  1828.     id AA18189; Fri, 15 Jul 88 02:00:02 EDT
  1829. Received: by umix.cc.umich.edu (5.54/umix-2.0)
  1830.     id AA19640; Fri, 15 Jul 88 02:11:44 EDT
  1831. Date: Fri, 15 Jul 88 02:11:44 EDT
  1832. From: rich%sendai.uucp@umix.cc.umich.edu
  1833. Message-Id: <8807150611.AA19640@umix.cc.umich.edu>
  1834. To: UNOCC07%zeus%crcvms.unl.edu%umix.uucp@umix.cc.umich.edu
  1835. Cc: icon-group%arizona.edu%umix.uucp@umix.cc.umich.edu
  1836. In-Reply-To: "Many people would rather die than think; in fact, most do."
  1837.  
  1838. 's message of Wed, 13 Jul 88 17:52 CDT <8807140050.AA21092@megaron.arizona.edu>
  1839. Subject: Possible Icon Addition?
  1840. Reply-to: rich@sendai.UUCP
  1841.  
  1842.    >From arizona.edu!icon-group-sender  Wed Jul 13 21:01:54 1988 remote from umix
  1843.    Date: Wed, 13 Jul 88 17:52 CDT
  1844.    From: "Many people would rather die than think; in fact, most do."
  1845.     <umix!crcvms.unl.edu!zeus!UNOCC07>
  1846.    X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
  1847.  
  1848.    This is in no way related to that last posting...
  1849.  
  1850.    I was wondering, would it be reasonable to want a facility in Icon for
  1851.    sharing variables between two or more procedures?  I'm thinking of something
  1852.    like:
  1853.  
  1854. Well...
  1855.  
  1856. Common blocks seem pretty unstructured and counter intuitive.
  1857.  
  1858. But if you want a useful speculation, consider how you'd modify the
  1859. language to take into account symmetric parallel processors.  Do you
  1860. program at the processor level and pass messages?  Or pipeline the
  1861. interpreter?  Or can you find a way to really co- the co-expressions?
  1862. Or something else I haven't thought of?
  1863.  
  1864. xoxorich.
  1865.  
  1866.  
  1867. From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS  Fri Jul 15 11:12:43 1988
  1868. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 15 Jul 88 11:12:43 MST
  1869. Received: from a.cc.umich.edu by megaron.arizona.edu (5.59-1.5) via SMTP
  1870.     id AA27147; Fri, 15 Jul 88 11:12:11 MST
  1871. Received: from umix.cc.umich.edu by a.cc.umich.edu (5.59/1.0)
  1872.     id AA19914; Fri, 15 Jul 88 14:08:35 EDT
  1873. Received: by umix.cc.umich.edu (5.54/umix-2.0)
  1874.     id AA03414; Fri, 15 Jul 88 14:20:28 EDT
  1875. Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Fri, 15 Jul 88 14:04:58 EDT
  1876. Date: Fri, 15 Jul 88 12:25:42 EDT
  1877. From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
  1878. To: icon-group@arizona.edu
  1879. Message-Id: <70024@Wayne-MTS>
  1880. Subject: Error in V7 MS-DOS documentation
  1881.  
  1882. Note, friends: the "line number table" parameter in Sec. 6.2 of the Icon
  1883. MS-DOS V7 documentation is erroneously printed as "l" when it should
  1884. be "n".  That's one of the parameters used with "-S" to set table sizes during
  1885. compilation and linking.
  1886.  
  1887. Paul Abrahams
  1888.  
  1889. From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS  Fri Jul 15 11:12:44 1988
  1890. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 15 Jul 88 11:12:44 MST
  1891. Received: from a.cc.umich.edu by megaron.arizona.edu (5.59-1.5) via SMTP
  1892.     id AA27148; Fri, 15 Jul 88 11:12:17 MST
  1893. Received: from umix.cc.umich.edu by a.cc.umich.edu (5.59/1.0)
  1894.     id AA19910; Fri, 15 Jul 88 14:08:16 EDT
  1895. Received: by umix.cc.umich.edu (5.54/umix-2.0)
  1896.     id AA03404; Fri, 15 Jul 88 14:20:10 EDT
  1897. Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Fri, 15 Jul 88 14:04:40 EDT
  1898. Date: Fri, 15 Jul 88 12:24:12 EDT
  1899. From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
  1900. To: icon-group@arizona.edu
  1901. Message-Id: <70022@Wayne-MTS>
  1902. Subject: Sharing variables among procedures
  1903.  
  1904. The C scheme is really not adequate for sharing variables among procedures,
  1905. at least when those procedures are being used as coexpressions and more than
  1906. one activation of a particular coexpression can exist at once.  This is not
  1907. just theory; it occurred in a rather complex Icon program that I wrote to do a
  1908. real, useful task (a prototype document formatter).
  1909.  
  1910. Paul Abrahams
  1911.  
  1912. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Fri Jul 15 15:36:33 1988
  1913. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 15 Jul 88 15:36:33 MST
  1914. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.5) via SMTP
  1915.     id AA17760; Fri, 15 Jul 88 15:36:25 MST
  1916. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  1917.     id AA27659; Fri, 15 Jul 88 17:35:23 CDT
  1918. Return-Path: <goer@sophist.uchicago.edu>
  1919. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  1920.     id AA08268; Fri, 15 Jul 88 17:28:59 CDT
  1921. Date: Fri, 15 Jul 88 17:28:59 CDT
  1922. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  1923. Message-Id: <8807152228.AA08268@sophist.uchicago.edu>
  1924. To: icon-group@arizona.edu
  1925. Subject: object-oriented extensions, variable scoping
  1926.  
  1927. I'd love to have some message-passing capability in Icon.  But someone is
  1928. going to have to do some very careful thinking as to how this could be done
  1929. in a distinctly Iconish manner.  Then someone is going to have to do a lot
  1930. of work incorporating it into the existing (already quite large) framework.
  1931. If we don't watch out, we'll have a monster on our hands, like Common Lisp.
  1932.  
  1933. As for variables, and sharing them among procedures:  My hope is that we
  1934. introduce dynamic variables based on the current &level of the current acti-
  1935. vation branch.  That way procedure X and all procedures called by X would
  1936. automatically have access to variables defined as "dynamic" in procedure
  1937. X.  Yes, I know that this might introduce bad side-effects, and encourage slop-
  1938. py programming.  But heh, the more tightly controlled a programmer is by
  1939. the lang., the less clever, and at times clear, he/she can be.  At some point,
  1940. you gotta put the discipline in the programmer's head, rather than ram it
  1941. down his throat by introducing pedantic restraints in the programming language
  1942. itself.
  1943.  
  1944. One other thing I'd love is the ability to specify static typing of variables.
  1945. Wouldn't it be nice to be able to tell Icon that a certain variable is/will
  1946. always be an integer.  This could lead to some useful error-checking.  But
  1947. better than this, it would allow increased speed, and better handling of
  1948. storage.  Just a thought.  I wouldn't consider this feature necessary.  Really
  1949. it's the message-passing and dynamic variables that would be nice.
  1950.  
  1951.                                                   -Richard L. Goerwitz
  1952.                                                   goer@sophist.uchicago.edu
  1953.                                                   !ihnp4!gargoyle!sophist!goer
  1954.  
  1955. From icon-group-request  Fri Jul 15 17:41:48 1988
  1956. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 15 Jul 88 17:41:48 MST
  1957. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.5) via SMTP
  1958.     id AA27130; Fri, 15 Jul 88 17:41:33 MST
  1959. Received: by ucbvax.berkeley.edu (5.59/1.28)
  1960.     id AA17940; Fri, 15 Jul 88 17:20:33 PDT
  1961. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1962.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1963.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1964. Date: 15 Jul 88 22:11:53 GMT
  1965. From: cjeffery@arizona.edu  (Clinton Jeffery)
  1966. Organization: U of Arizona CS Dept, Tucson
  1967. Subject: Re: Sharing variables among procedures
  1968. Message-Id: <6274@megaron.arizona.edu>
  1969. References: <70022@Wayne-MTS>
  1970. Sender: icon-group-request@arizona.edu
  1971. To: icon-group@arizona.edu
  1972.  
  1973. From article <70022@Wayne-MTS>, by Paul_Abrahams%Wayne-MTS@um.cc.umich.EDU:
  1974. > The C scheme is really not adequate for sharing variables among procedures,
  1975. > at least when those procedures are being used as coexpressions and more than
  1976. > one activation of a particular coexpression can exist at once.
  1977.  
  1978. For what its worth, I concur.  However, instead of just knocking an inadequate
  1979. idea, I would appreciate it if Paul would give us a feel for what kind of
  1980. scoping mechanism it would take to make him happy (leaving feasibility aside
  1981. for a moment).  My own gut feeling is that coexpressions need a *different*
  1982. mechanism for sharing data than the more mundane case, and maybe if the C
  1983. scheme would be adequate 98% of the time, and only take a day or so,
  1984. it would be worth doing.  Maybe.
  1985. -- 
  1986. | Clint Jeffery, University of Arizona Department of Computer Science
  1987. | cjeffery@arizona.edu -or- {ihnp4 noao allegra cmcl2}!arizona!cjeffery
  1988. --
  1989.  
  1990. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Sun Jul 17 19:04:38 1988
  1991. Received: from megaron.arizona.edu by bocklin.arizona.edu; Sun, 17 Jul 88 19:04:38 MST
  1992. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.5) via SMTP
  1993.     id AA28479; Sun, 17 Jul 88 19:04:31 MST
  1994. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  1995.     id AA28625; Sun, 17 Jul 88 21:03:33 CDT
  1996. Return-Path: <goer@sophist.uchicago.edu>
  1997. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  1998.     id AA11542; Sun, 17 Jul 88 20:57:03 CDT
  1999. Date: Sun, 17 Jul 88 20:57:03 CDT
  2000. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  2001. Message-Id: <8807180157.AA11542@sophist.uchicago.edu>
  2002. To: icon-group@arizona.edu
  2003. Subject: scoping
  2004.  
  2005. I quote Clint Jeffery:
  2006.  
  2007.     Maybe if the C scheme would be adequate 98% of the time,
  2008.         and only take a day or so, it would be worth doing.  Maybe.
  2009.  
  2010. Underscore the maybe?  After all, by the time the ball gets rolling,
  2011. and people have set up all their libraries and programs according to a
  2012. new scheme, we will have built up a tremendous amount of inertia.
  2013. Then, when a new, better scheme is introduced, it will have to be
  2014. back-compatible (thus adding to the size of Icon), and any problems
  2015. that existed with the first scheme will become all the more in-
  2016. grained.  Better to think things through from the ground up, and
  2017. implement when a clean, Iconish scheme has been worked out.  (Easy
  2018. for me to say, huh...).
  2019.  
  2020. Or is this silly?  Is the partial, immediate solution better?
  2021.  
  2022.                                                   -Richard L. Goerwitz
  2023.                                                   goer@sophist.uchicago.edu
  2024.                                                   !ihnp4!gargoyle!sophist!goer
  2025.  
  2026. From @NSS.Cs.Ucl.AC.UK,@cs.qmc.ac.uk:gcj@maths.qmc.ac.uk  Mon Jul 18 08:25:53 1988
  2027. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 18 Jul 88 08:25:53 MST
  2028. Received: from NSS.CS.UCL.AC.UK by megaron.arizona.edu (5.59-1.5) via SMTP
  2029.     id AA24706; Mon, 18 Jul 88 08:25:29 MST
  2030. Received: from cs.qmc.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
  2031.            id aa04113; 18 Jul 88 15:53 BST
  2032. Received: from qmcms.maths.qmc.ac.uk by csvax.cs.qmc.ac.uk id a019008;
  2033.           18 Jul 88 16:22 BST
  2034. From: Gordon Joly <gcj%maths.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
  2035. Date: Mon, 18 Jul 88 16:16:06 BST
  2036. Message-Id: <10235.8807181516@qmcms.maths.qmc.ac.uk>
  2037. To: icon-group@arizona.edu
  2038. Subject: ICON Logo.
  2039.  
  2040. Liked the new ICON logo in the newsletter; had the "look and
  2041. feel" of the SUN Microsystems logo. C u in court;--) !!
  2042.  
  2043.  
  2044. From wunder@sde.hp.com  Mon Jul 18 13:33:33 1988
  2045. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 18 Jul 88 13:33:33 MST
  2046. Received: from hp-sde.sde.hp.com by megaron.arizona.edu (5.59-1.5) via SMTP
  2047.     id AA10617; Mon, 18 Jul 88 13:33:22 MST
  2048. Received: from liberator.sde.hp.com (orac) by hp-sde ; Mon, 18 Jul 88 13:33:08 pdt
  2049. Received: by hpsdel ; Mon, 18 Jul 88 13:30:55 pdt
  2050. Date: Mon, 18 Jul 88 13:30:55 pdt
  2051. From: Walter Underwood <wunder@sde.hp.com>
  2052. Message-Id: <8807182030.AA01512@liberator.sde.hp.com>
  2053. To: icon-group@arizona.edu
  2054. In-Reply-To: Richard Goerwitz's message of Sun, 17 Jul 88 20:57:03 CDT <8807180157.AA11542@sophist.uchicago.edu>
  2055. Subject: scoping
  2056.  
  2057. This is a shot inthe dark, but ...
  2058.  
  2059. Co-expressions seem very similar to the delay and force constructs in
  2060. Scheme.  Scheme is lexically scoped and seems to deal well with delay
  2061. and force.  Perhaps we can learn something there?
  2062.  
  2063. wunder
  2064.  
  2065.  
  2066. From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS  Wed Jul 20 11:08:03 1988
  2067. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 20 Jul 88 11:08:03 MST
  2068. Received: from [35.1.1.10] by megaron.arizona.edu (5.59-1.5) via SMTP
  2069.     id AA20505; Wed, 20 Jul 88 11:07:53 MST
  2070. Received: by umix.cc.umich.edu (5.54/umix-2.0)
  2071.     id AA17878; Wed, 20 Jul 88 14:17:07 EDT
  2072. Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Wed, 20 Jul 88 14:02:15 EDT
  2073. Date: Wed, 20 Jul 88 12:39:40 EDT
  2074. From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
  2075. To: icon-group@arizona.edu
  2076. Message-Id: <71102@Wayne-MTS>
  2077. Subject: Sharing variables among procedures
  2078.  
  2079. Here is a sketch of a powerful yet simple scheme of sharing variables
  2080. among procedures (maybe it's nothing more than abstract data types under a
  2081. different name).
  2082.  
  2083. A module consists of a collection of named variables, a collection of
  2084. procedures, and some startup code (no nesting of modules allowed, at least for
  2085. now).  An Icon program consists of a collection of modules, procedures, and
  2086. global variables.  A module, like an expression, can be subjected to the @
  2087. operator, producing an instantiated module.  When a module is instantiated,
  2088. its startup code is executed.  Procedure p of instantiated module m is
  2089. referred to as m.p.  The procedures within a module can refer to the variables
  2090. of that module.
  2091.  
  2092. The degenerate case is where each module is instantiated exactly once, at the
  2093. start of the program, and no module has any startup code.  In this case each
  2094. module is much like a C file, except that references to its procedures require
  2095. name qualification.
  2096.  
  2097. An instantiated module is destroyed when it becomes inaccessible, according to
  2098. the general principles of garbage collection.
  2099.  
  2100. I assume that the variables of a module are inaccessible outside of that
  2101. module, but it is just as easy to make them accessible if that is preferred.
  2102.  
  2103. The internal representation of a module is (obviously) a record containing the
  2104. values of its variables.
  2105.  
  2106. I hope to talk about some ideas relating to this at the workshop next week.
  2107.  
  2108. Paul Abrahams
  2109.  
  2110. From icon-group-request  Wed Jul 20 23:14:44 1988
  2111. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 20 Jul 88 23:14:44 MST
  2112. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.5) via SMTP
  2113.     id AA27332; Wed, 20 Jul 88 23:14:29 MST
  2114. Received: by ucbvax.berkeley.edu (5.59/1.28)
  2115.     id AA06673; Wed, 20 Jul 88 22:11:52 PDT
  2116. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2117.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2118.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2119. Date: 20 Jul 88 22:44:57 GMT
  2120. From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU  (00704a-Liber)
  2121. Organization: AT&T Bell Laboratories - Naperville, Illinois
  2122. Subject: Re: Sharing variables among procedures
  2123. Message-Id: <5359@ihlpf.ATT.COM>
  2124. References: <70022@Wayne-MTS>
  2125. Sender: icon-group-request@arizona.edu
  2126. To: icon-group@arizona.edu
  2127.  
  2128. In article <70022@Wayne-MTS> Paul_Abrahams%Wayne-MTS@um.cc.umich.EDU writes:
  2129. >The C scheme is really not adequate for sharing variables among procedures,
  2130.  
  2131. Just wondering:  what was it about the C scheme that made it inadequate for Icon
  2132. (I know that it doesn't really fit in with the Icon way of things but it seems to
  2133. me that you could get by with the C scheme)?
  2134.  
  2135. >at least when those procedures are being used as coexpressions and more than
  2136. >one activation of a particular coexpression can exist at once.
  2137.  
  2138. Using the C scheme, the shared variables should appear to be globals for the
  2139. coexpression.  Or did you want a new set of shared variables for each activation
  2140. of a coexpression?
  2141. -- 
  2142.  _ __            NEVIN J. LIBER    ..!att!ihlpf!nevin1    (312) 979-????
  2143. ' )  )                You are in a twisty maze of little
  2144.  /  / _ , __o  ____         email paths, all different.
  2145. /  (_</_\/ <__/ / <_    These are solely MY opinions, not AT&T's, blah blah blah
  2146.  
  2147. From icon-group-request  Wed Jul 20 23:22:38 1988
  2148. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 20 Jul 88 23:22:38 MST
  2149. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.5) via SMTP
  2150.     id AA27782; Wed, 20 Jul 88 23:21:58 MST
  2151. Received: by ucbvax.berkeley.edu (5.59/1.28)
  2152.     id AA06729; Wed, 20 Jul 88 22:13:41 PDT
  2153. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2154.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2155.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2156. Date: 20 Jul 88 23:05:33 GMT
  2157. From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU  (00704a-Liber)
  2158. Organization: AT&T Bell Laboratories - Naperville, Illinois
  2159. Subject: Re: object-oriented extensions, variable scoping
  2160. Message-Id: <5363@ihlpf.ATT.COM>
  2161. References: <8807152228.AA08268@sophist.uchicago.edu>
  2162. Sender: icon-group-request@arizona.edu
  2163. To: icon-group@arizona.edu
  2164.  
  2165. In article <8807152228.AA08268@sophist.uchicago.edu> goer@SOPHIST.UCHICAGO.EDU (Richard Goerwitz) writes:
  2166.  
  2167. >As for variables, and sharing them among procedures:  My hope is that we
  2168. >introduce dynamic variables based on the current &level of the current acti-
  2169. >vation branch.  That way procedure X and all procedures called by X would
  2170. >automatically have access to variables defined as "dynamic" in procedure
  2171. >X.
  2172.  
  2173. I don't know about this.  This is only good in languages like Pascal and Modula-2
  2174. where the scope of a variable can be determined by just looking at the source for
  2175. a program.  I also think that this might be signifcantly slower than the current
  2176. mechanism (no dynamic variables), since a lookup in a symbol table would be
  2177. required for all variables not declared as local, and symbol table maintenance
  2178. would need to be done on each call/suspend/return.  I think that, due to
  2179. generators, the symbol table might need to be part of the frame.
  2180.  
  2181. >Yes, I know that this might introduce bad side-effects, and encourage slop-
  2182. >py programming.
  2183.  
  2184. One of the side effects is that routine A could declare a dynamic variable X, and
  2185. a routine B could also declare a dynamic variable X, and if they both call C
  2186. which uses a dynamic variable X, trace back is very difficult.
  2187.  
  2188. This type of scoping mechanism (dynamic variables with automatic access by called
  2189. routines) would lead to very hard to follow code; I don't think it would be
  2190. suitable for Icon.
  2191.  
  2192.  
  2193. >One other thing I'd love is the ability to specify static typing of variables.
  2194. >Wouldn't it be nice to be able to tell Icon that a certain variable is/will
  2195. >always be an integer.  This could lead to some useful error-checking.  But
  2196. >better than this, it would allow increased speed, and better handling of
  2197. >storage.
  2198.  
  2199. I don't think it would lead to increased speed (unless you're talking about
  2200. adding some 'optimized' opcodes to the icode language).  From an implementation
  2201. point of view, however, this does not seem very difficult to implement.  All that
  2202. would need to be done (I think) is to add another flag to the variable descriptor
  2203. which, if set, means that the type of the variable cannot be changed.  The flag
  2204. need only be checked during an assignment operation.
  2205.  
  2206. The only thing is, I would want to have the &null value to be part of every type
  2207. (not easy to implement), since most of the time I use &null to indicate that a
  2208. variable has not been used yet or that it contains no useful data.
  2209. -- 
  2210.  _ __            NEVIN J. LIBER    ..!att!ihlpf!nevin1    (312) 979-????
  2211. ' )  )                You are in a twisty maze of little
  2212.  /  / _ , __o  ____         email paths, all different.
  2213. /  (_</_\/ <__/ / <_    These are solely MY opinions, not AT&T's, blah blah blah
  2214.  
  2215. From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS  Thu Jul 21 15:21:32 1988
  2216. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 21 Jul 88 15:21:32 MST
  2217. Received: from umix.cc.umich.edu by megaron.arizona.edu (5.59-1.5) via SMTP
  2218.     id AA10259; Thu, 21 Jul 88 15:21:23 MST
  2219. Received: by umix.cc.umich.edu (5.54/umix-2.0)
  2220.     id AA09335; Thu, 21 Jul 88 17:06:12 EDT
  2221. Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Thu, 21 Jul 88 14:02:03 EDT
  2222. Date: Thu, 21 Jul 88 12:49:34 EDT
  2223. From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
  2224. To: icon-group@arizona.edu
  2225. Message-Id: <71410@Wayne-MTS>
  2226. Subject: Modules versus C scoping
  2227.  
  2228. There are several reasons why I would not want to see the C scoping rules
  2229. incorporated into Icon:
  2230.  
  2231. (1) The rules themselves are awkward even in C.  The C Standards Committee had
  2232. a hard time figuring out what the rules for externs really ought to be.  There
  2233. are several odd, nasty cases that were treated differently by different
  2234. implementors.
  2235.  
  2236. (2) The notion of a file as a scoping unit might make sense in the Unix
  2237. environment, although I'm not convinced even of that.  Outside of Unix, it
  2238. makes hardly any sense at all.  Files are really an operating system concept,
  2239. not a programming language concept.
  2240.  
  2241. (3) The notion of naming modules when you reference their entities, as you do
  2242. in my module scheme, clearly establishes the owner of a variable.  Confusion
  2243. about such ownership is one of the problems that C has with its scoping rules
  2244. for globals.
  2245.  
  2246. (4) I have found it useful to have multiple activations of a procedure
  2247. that shares variables with other procedures, implying one set of shared
  2248. variables per activation.  The module scheme handles this nicely; the C scheme
  2249. doesn't handle it at all.  Interestingly, allowing nested procedures also
  2250. achieves sharing as long as there is only one active process.  Nested
  2251. procedures work even in the presence of recursion.  They don't exist in either
  2252. Icon or C, but they do exist in Pascal and in most Algol 60 descendants.
  2253.  
  2254. (5) Using the C scheme as a stopgap will preclude doing something better later
  2255. on, as others have pointed out.
  2256.  
  2257. Paul Abrahams
  2258.  
  2259. From kwalker  Thu Jul 21 15:29:08 1988
  2260. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 21 Jul 88 15:29:08 MST
  2261. Date: Thu, 21 Jul 88 15:29:05 MST
  2262. From: "Kenneth Walker" <kwalker>
  2263. Message-Id: <8807212229.AA10902@megaron.arizona.edu>
  2264. Received: by megaron.arizona.edu (5.59-1.5)
  2265.     id AA10902; Thu, 21 Jul 88 15:29:05 MST
  2266. In-Reply-To: <5363@ihlpf.ATT.COM>
  2267. To: icon-group
  2268. Subject: Re: object-oriented extensions, variable scoping
  2269.  
  2270. > Date: 20 Jul 88 23:05:33 GMT
  2271. > From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU  (00704a-Liber)
  2272. > In article <8807152228.AA08268@sophist.uchicago.edu>
  2273. >    goer@SOPHIST.UCHICAGO.EDU (Richard Goerwitz) writes:
  2274. > >As for variables, and sharing them among procedures:  My hope is that we
  2275. > >introduce dynamic variables ...
  2276. > ...
  2277. >
  2278. > I also think that this might be signifcantly slower than the current
  2279. > mechanism (no dynamic variables), since a lookup in a symbol table would be
  2280. > required for all variables not declared as local, and symbol table maintenance
  2281. > would need to be done on each call/suspend/return.  I think that, due to
  2282. > generators, the symbol table might need to be part of the frame.
  2283.  
  2284. I think you can get by without a real symbol table. By link time you
  2285. should be able to identify all dynamic variables. You can allocate and
  2286. access them like global variables, with maintenance done at each
  2287. call/suspend/return as you suggest. This maintenance consists of saving
  2288. the old value upon entering a procedure and supplying the appropriate new
  2289. value, and then the reversing the processs upon leaving a procedure (with
  2290. a suspend you have to save the new value in case of a resumption).
  2291.  
  2292. This is similar to what is done in SNOBOL4 (and some Lisps, where it is
  2293. call "shallow binding"), though SNOBOL4 needs a real symbol table but does
  2294. not have to deal with generators. It is also similar to what is done with
  2295. &subject and &pos in string scanning.
  2296.  
  2297. You can also do a form of "deap binding" where you do put a symbol table
  2298. in each procedure frame and search backwards through the frames until you
  2299. find the variable you what. However, that would be rather expensive.
  2300.  
  2301. > >One other thing I'd love is the ability to specify static typing of
  2302. > >variables.
  2303. > >Wouldn't it be nice to be able to tell Icon that a certain variable is/will
  2304. > >always be an integer.  This could lead to some useful error-checking.  But
  2305. > >better than this, it would allow increased speed, and better handling of
  2306. > >storage.
  2307. > I don't think it would lead to increased speed (unless you're talking about
  2308. > adding some 'optimized' opcodes to the icode language). 
  2309.  
  2310. More likely you would want to do it in a compiler to get speed advantages.
  2311.  
  2312. > The only thing is, I would want to have the &null value to be part of every
  2313. > type
  2314. > (not easy to implement), since most of the time I use &null to indicate that a
  2315. > variable has not been used yet or that it contains no useful data.
  2316.  
  2317. Good point! You would definitly have to deal with the initial value
  2318. problem.
  2319.  
  2320.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  2321.    +1 602 621 2858  kwalker@Arizona.EDU   {allegra|noao}!arizona!kwalker
  2322.  
  2323. From DSCARGO@cim-vax.HONEYWELL.COM  Mon Jul 25 06:34:21 1988
  2324. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 25 Jul 88 06:34:21 MST
  2325. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5) via SMTP
  2326.     id AA15439; Mon, 25 Jul 88 06:34:13 MST
  2327. Received: by cim-vax id <0000021E081@cim-vax.HONEYWELL.COM> ;
  2328.        Mon, 25 Jul 88 08:32:51 CDT
  2329. Date: Mon, 25 Jul 88 08:19:01 CDT
  2330. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  2331. Subject: Piping between Icon routines
  2332. To: icon-group@arizona.edu
  2333. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  2334. Message-Id: <880725081901.0000021E081@cim-vax.HONEYWELL.COM>
  2335.  
  2336. Someone earlier asked the question about what an operating system based on
  2337. Icon would be like; likewise the question of encapsulation arose.  I was
  2338. thinking about MS-DOS command interpreters recently; I occurred to me to
  2339. wonder how hard it would be for the Icon interpreter to handle command lines
  2340. where Icon programs were connected by their own pipe operations.
  2341.   In other words, the Icon interpreter would get a command like
  2342.  
  2343.   "a | b | c" <in >out
  2344.  
  2345.   with the requirement that a, b, and c are Icon programs that would be
  2346. communicating via a pipe style mechanism.  The communication would be one
  2347. directional.  While parallelism might be possible (if the interpreter were
  2348. upgraded to handle simultaneous processes?), sequential operation would be
  2349. OK for most things.
  2350.  
  2351.   This gives a certain amount of encapsulation; programs compiled and linked
  2352. separately are indeed still separate.  I could see adding an EXPORTED or
  2353. EXTERNAL or COMMON data type that would survive between programs (for strictly
  2354. sequential operation) or be dynamically shared (for concurrent operation).
  2355.  
  2356.   The weaknesses of this are many.  My main reason for wanting it would be to
  2357. exploit the similarity to UNIX pipes:  the ability to construct new tools by
  2358. composing sequences of simpler tools.  It also avoids (potentially) the
  2359. overhead of loading the Icon interpreter repeated in order to run a sequence
  2360. of Icon progams.
  2361.  
  2362.   The restriction to strictly sequential operations is a large one, but it
  2363. might provide a way to experiment until something more general evolves.  As
  2364. long as shared variable symantics are NOT introduced, it doesn't introduce
  2365. any radical features (at least that I can see).
  2366.  
  2367. David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
  2368.  
  2369. From DSCARGO@cim-vax.HONEYWELL.COM  Fri Jul 29 14:36:25 1988
  2370. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 29 Jul 88 14:36:25 MST
  2371. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5) via SMTP
  2372.     id AA12189; Fri, 29 Jul 88 14:36:17 MST
  2373. Received: by cim-vax id <00000E5D0B1@cim-vax.HONEYWELL.COM> ;
  2374.        Fri, 29 Jul 88 16:34:35 CDT
  2375. Date: Fri, 29 Jul 88 16:34:04 CDT
  2376. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  2377. Subject: Icon teaching aids
  2378. To: icon-group@arizona.edu
  2379. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  2380. Message-Id: <880729163404.00000E5D0B1@cim-vax.HONEYWELL.COM>
  2381.  
  2382. I'm going to be presenting an Icon overview and extremely short course
  2383. (1 hour overview, 1-2 hours basics) to a group of already skilled programmers.
  2384. I was wondering if anybody had suggestions for what material to cover, in
  2385. what order.  Also, if anybody had any training experiences they are willing
  2386. to relate, or training materials they are willing to share, I'd like to hear
  2387. what they have to say.
  2388.  
  2389. We are going to be using the VAX/VMS implementation.  We will largely be using
  2390. Icon for "data laundry" applications, as well a program analysis.
  2391.  
  2392. David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
  2393.  
  2394. From DSCARGO@cim-vax.HONEYWELL.COM  Fri Aug  5 13:23:58 1988
  2395. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 5 Aug 88 13:23:58 MST
  2396. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5/6) via SMTP
  2397.     id AA06863; Fri, 5 Aug 88 13:23:41 MST
  2398. Received: by cim-vax id <00001B55071@cim-vax.HONEYWELL.COM> ;
  2399.        Fri,  5 Aug 88 15:22:07 CDT
  2400. Date: Fri,  5 Aug 88 15:14:22 CDT
  2401. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  2402. Subject: table entry value list
  2403. To: icon-group@arizona.edu
  2404. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  2405. Message-Id: <880805151422.00001B55071@cim-vax.HONEYWELL.COM>
  2406.  
  2407. One of the Icon users at my site asked me for the best way to get the
  2408. list of entry values associated with a table.  !t will return the list
  2409. of assigned values.  Sorting will create a list (or lists) containing
  2410. entry and assigned values.  What's the best way to get the list (or set)
  2411. of entry values?   (An extension allowing conversion of a table to a set
  2412. might be useful.  Such as s:= domain(t) returns the set of entry values
  2413. and s := range(t) returns the set of assigned values.  Does that sound
  2414. useful?)
  2415.  
  2416. From kwalker  Fri Aug  5 15:29:52 1988
  2417. Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 5 Aug 88 15:29:52 MST
  2418. Date: Fri, 5 Aug 88 15:27:36 MST
  2419. From: "Kenneth Walker" <kwalker>
  2420. Message-Id: <8808052227.AA13363@megaron.arizona.edu>
  2421. Received: by megaron.arizona.edu (5.59-1.5/6)
  2422.     id AA13363; Fri, 5 Aug 88 15:27:36 MST
  2423. In-Reply-To: <880805151422.00001B55071@cim-vax.HONEYWELL.COM>
  2424. To: DSCARGO@cim-vax.HONEYWELL.COM, icon-group@arizona.edu
  2425. Subject: Re:  table entry value list
  2426.  
  2427. At present, the only way to get the entry values of a table
  2428. is to sort the table and extract them from the resulting list.
  2429.  
  2430. We recognize that a better way would be useful. There are several
  2431. possible approaches and we haven't decided which is best. Thanks
  2432. for your suggestion.
  2433.  
  2434.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  2435.    +1 602 621 2858  kwalker@Arizona.EDU   {allegra|noao}!arizona!kwalker
  2436.  
  2437. From DSCARGO@cim-vax.HONEYWELL.COM  Mon Aug  8 06:51:31 1988
  2438. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 8 Aug 88 06:51:31 MST
  2439. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5/6) via SMTP
  2440.     id AA16936; Mon, 8 Aug 88 06:51:23 MST
  2441. Received: by cim-vax id <00000267071@cim-vax.HONEYWELL.COM> ;
  2442.        Mon,  8 Aug 88 08:50:00 CDT
  2443. Date: Mon,  8 Aug 88 08:41:25 CDT
  2444. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  2445. Subject: Most thoughts on tables
  2446. To: icon-group@arizona.edu
  2447. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  2448. Message-Id: <880808084125.00000267071@cim-vax.HONEYWELL.COM>
  2449.  
  2450. While thinking over the problem of getting the list of entry values for a
  2451. table, it occurred to me to wonder if you had considered implementing bags.
  2452. (Bags are like sets except they all multiple instances of the same value.)
  2453. Tables could then be considered as a  mapping from a set to a bag; it would
  2454. then be natural to be able to look at them separately by mapping the domain
  2455. of the table into a set and the range of a table into a bag.  A bag should
  2456. also be relatively easy to map into a set if unique values are required.
  2457. Syntactically, bags could be made identical to sets (provided the operators
  2458. don't get too overloaded in the process).
  2459.  
  2460. I was also wondering about the unary ? operator.  This is the equivalent of
  2461. "drawing (a random element) with replacement."  Is there an easy way to do
  2462. drawing without replacement?  There a classes of probability problems that
  2463. would be much easier to code if drawing without replacement was simple.  I
  2464. suppose in most cases, shuffling a list and then "getting" elements off  the
  2465. front of it is equivalent, but I wasn't sure.
  2466.  
  2467. David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
  2468.  
  2469. From sboisen@PEBBLES.BBN.COM  Mon Aug  8 08:42:09 1988
  2470. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 8 Aug 88 08:42:09 MST
  2471. Message-Id: <8808081541.AA21970@megaron.arizona.edu>
  2472. Received: from PEBBLES.BBN.COM by megaron.arizona.edu (5.59-1.5/6) via SMTP
  2473.     id AA21970; Mon, 8 Aug 88 08:41:56 MST
  2474. To: icon-group@arizona.edu
  2475. Date: Mon, 8 Aug 88 11:30:30 EDT
  2476. From: sboisen@PEBBLES.BBN.COM
  2477. Sender: sboisen@PEBBLES.BBN.COM
  2478.  
  2479. I though i'd pass along the following for those of you who don't
  2480. follow these newsgroups. Richard O'Keefe is, by the way, very highly
  2481. respected in Prolog circles (rightly so in my opinion), so at least
  2482. with respect to Prolog he almost certainly knows what he's talking about.
  2483. ----------------------------------------------------------------------
  2484. From: ok@quintus
  2485. Newsgroups: comp.lang.prolog,comp.lang.misc
  2486. Subject: Is ICON higher level than Prolog?
  2487. Date: 8 Aug 88 03:23:37 GMT
  2488. Reply-To: ok@quintus ()
  2489. Organization: Quintus Computer Systems, Inc.
  2490.  
  2491. ICON (described in "The ICON Programming Language", Griswold & Griswold,
  2492. Prentice-Hall, 1983) is a descendant of SNOBOL.  It has a fairly
  2493. conventional syntax, but adds backtracking, strings, hash tables,
  2494. and pattern-matching (patterns are not a data type as in SNOBOL, but
  2495. you can do most of the same sorts of things).
  2496.  
  2497. Version 7 of ICON (the current one) is implemented (in C and YACC) as
  2498. a compiler which produces abstract instructions which are then interpreted
  2499. by another C program.  This is rather like the Berkeley Pascal "pi"
  2500. compiler and "px" interpreter.
  2501.  
  2502. Version 5 of ICON (the one described in the book) had two implementations
  2503. sharing a common front end: an "abstract instruction" version, and one
  2504. which produced native code.  However, the book says that "a difference of
  2505. 5% to 10%" in speed between "compiled" and "interpreted" versions was
  2506. typical.  So the ICON group decided that it wasn't worth maintaining the
  2507. native-code version any longer.
  2508.  
  2509. What I'd like to understand is why the difference was so slight.
  2510. Let's put it in context (bigger numbers mean faster, each language's
  2511. C-coded interpreter set to 1):
  2512.  
  2513.  1   Pascal, Berkeley "pi" + "px"
  2514. 36   Pascal, Berkeley "pc"        -- my measurement on a SUN-3
  2515.  
  2516.  1   Prolog, WAM emulated in C
  2517.  2   Prolog, WAM emulated in assembly code
  2518.  4   Prolog, WAM macro-expanded and peephole-optimised to native code
  2519.  
  2520.  1.0 ICON, Version 5 "icont" + "iconx"
  2521.  1.1 ICON, Version 5 "iconc"
  2522.  
  2523. It's a long time since I was sure of my facts about Berkeley Pascal, but
  2524. I don't recall the abstract instructions as being designed for particularly
  2525. fast emulation, or the compiler as doing much optimisation.  I suspect that
  2526. a ratio of 4 to 10 for "simple-minded native code" -vs- "good C emulator"
  2527. should be more typical of Pascal.
  2528.  
  2529. So why is the ICON ratio so low?
  2530.  
  2531. It could be that the emulator was unusually good, or the compiler unusually
  2532. bad, or it could be something about the language.  To put _that_ in
  2533. context, I decided to take a Prolog program and recode it in ICON.  Since
  2534. I happened to have it handy, I used the "darlington-to-workington" example
  2535. on page 163 of the 3rd edition of Clocksin & Mellish (section 7.9).
  2536. The total times to find all shortest paths from each town were
  2537.     original Prolog version    4.8 seconds
  2538.     ICON version        6.2 seconds
  2539.     comparable Prolog version   0.5 seconds
  2540.  
  2541. ohe original Prolog version is the one which appears in Clocksin & Mellish.
  2542. It uses "findall", which is a fairly expensive operation, and uses a
  2543. quadratic algorithm for finding the shortest element of a list.
  2544. The ICON version, not being able to backtrack over a Prolog-like data base,
  2545. backtracks over a vector of triples, but is otherwise determinate.
  2546. The second Prolog version is much closer to the ICON version in structure.
  2547.  
  2548. The ICON version suffers from not having lists (in the sense of Prolog and
  2549. Lisp).  Instead it has extensible vectors (and calls them lists).  This is
  2550. a neat idea, but the overheads of the ICON implementation are high.  So I
  2551. declared a "pair" record type (pair(Cost,Path) in ICON corresponding to
  2552. Cost-Path in Prolog) and a "cons" record type (cons(Head,Tail) in ICON
  2553. corresponding to [Head|Tail]) in Prolog.  Allow a factor of 3 for the
  2554. size of the data structures (ICON data structures taking up a lot of
  2555. memory), and a factor of 2 to allow for the fact that the ICON emulator
  2556. is coded in C and the Quintus Prolog emulator isn't, and we're looking
  2557. at a ratio of about 2 to 1 between ICON and Prolog [on _this_ task, as
  2558. coded by me, running on a Sun-3/50, & other context].
  2559.  
  2560. The bottom line of this comparison is that the ICON interpreter doesn't seem
  2561. to be especially good or especially bad.  If ICON were like Prolog, we
  2562. would expect about a factor of 4 between the speed of interpreted code and
  2563. the speed of native code.  That fact that this was _not_ observed suggests
  2564. that either the compiler or the language was the problem.
  2565.  
  2566. It's worth drawing a distinction between polymorphic languages like ML
  2567. and typed Prolog, and languages with overloading, like PL/I and ICON.
  2568. An example of a polymorphic operation is:
  2569.     -- len: * list -> int
  2570.     ++ len nil = 0
  2571.     ++ len H.T = 1 + len T
  2572. which computes the length of a list, be the type of the elements what it may.
  2573. An example of an overloaded operation is:
  2574.     *X
  2575. which yields: the cardinality of a character set, the cardinality of a
  2576. (general) set, the length of a string, the length of a vector, the
  2577. number of fields in a record, &c, each of which is a different machine-
  2578. level operation.  Similarly (courtesy of automatic run-time coercion),
  2579. X||Y (string concatenation) does not correspond to a single operation either.
  2580.  
  2581. So I _think_ the low ratio for ICON wasn't do to the compiler either, but 
  2582. to the fact that there is so little that the compiler can do.
  2583.  
  2584. Would anyone who understands (I have the ICON Implementation book, but have
  2585. not finished it yet and still can't pretend to understand) the ICON
  2586. implementation care to comment on this?
  2587.  
  2588. [I'm quite happy with ICON's speed: it's quite a bit faster than AWK....]
  2589.  
  2590. ........................................
  2591. Sean Boisen -- sboisen@bbn.com
  2592. BBN Systems and Technologies Corporation, Cambridge MA
  2593. Disclaimer: these opinions void where prohibited by lawyers.
  2594.  
  2595. From ralph  Mon Aug  8 08:59:41 1988
  2596. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 8 Aug 88 08:59:41 MST
  2597. Date: Mon, 8 Aug 88 08:59:38 MST
  2598. From: "Ralph Griswold" <ralph>
  2599. Message-Id: <8808081559.AA22804@megaron.arizona.edu>
  2600. Received: by megaron.arizona.edu (5.59-1.5/6)
  2601.     id AA22804; Mon, 8 Aug 88 08:59:38 MST
  2602. To: icon-group@arizona.edu, sboisen@PEBBLES.BBN.COM
  2603. Subject: Speed of the Icon compiler and interpreter
  2604. In-Reply-To: <8808081541.AA21970@megaron.arizona.edu>
  2605.  
  2606. The small amount of difference in speed between the Version 5 Icon
  2607. interpreter and compiler is largely due to the fact that Icon programs
  2608. spend most of their time in the run-time system ("library routines")
  2609. rather than in the code generated for the program itself.
  2610.  
  2611. That is, the code generated for an Icon program consists mostly of
  2612. calls of library routines.  This includes time consuming high-level
  2613. operations like table look-up.  A significant amount of time also
  2614. is spent in storage management, which again is not done directly in the
  2615. generated code.
  2616.  
  2617. There's also a semantic trap here.  Folks tend to take the words
  2618. "compiler" and "interpreter" in a naive way.  Note that in both the
  2619. Version 5 compiler and interpreter, a lot of time is spent in compiled
  2620. code -- not code generated by the program, but code in the run-time system.
  2621. In fact, the "compiler" just maps the virtual-machine instructions
  2622. generated from the source program into naive assembly-langeuage code that
  2623. mirrors the code interpreted in the interpreter.  So what you save by compiling
  2624. is mostly the instruction decoding that the interpreter performs.
  2625.  
  2626. A lot of implementations of high-level languages really are hybrids.  For
  2627. example, the SPITBOL implementation of SNOBOL4 generates fast, compiled
  2628. code.  However, some sophisticated operations are implemented by modifying
  2629. the in-memory code.  It's hard to know how to characterize such an
  2630. implementation in the simple compiler/interpreter view.
  2631.  
  2632. From R.J.Hare@EDINBURGH.AC.UK  Mon Aug  8 19:31:38 1988
  2633. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 8 Aug 88 19:31:38 MST
  2634. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.5/6) via SMTP
  2635.     id AA23532; Mon, 8 Aug 88 19:31:37 MST
  2636. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Mon, 8 Aug 88 19:09 MST
  2637. Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1430; Mon,
  2638.  08 Aug 88 14:25:40 BST
  2639. Date: 08 Aug 88  14:26:04 bst
  2640. From: R.J.Hare@EDINBURGH.AC.UK
  2641. Subject: Sorting
  2642. To: icon-group@arizona.edu
  2643. Via:        000015001003.FTP.MAIL;  8 AUG 88 14:25:33 BST
  2644. Message-Id: <08 Aug 88  14:26:04 bst  340343@EMAS-A>
  2645.  
  2646. This may be a silly question, but at the moment I can't think of a simple
  2647. answer.
  2648.  
  2649. How do I sort using two keys with Icon? I want to sort a word list by
  2650. frequency, and, within groups of words with the same frequency of occurrence,
  2651. sort the words alphabetically - a standard word list in fact. Is it possible
  2652. to do this using the Icon 'sort' function?
  2653.  
  2654. Thanks
  2655.  
  2656. Roger Hare.
  2657.  
  2658. From DSCARGO@cim-vax.HONEYWELL.COM  Tue Aug  9 06:45:35 1988
  2659. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 9 Aug 88 06:45:35 MST
  2660. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.5/6) via SMTP
  2661.     id AA17256; Tue, 9 Aug 88 06:45:28 MST
  2662. Received: by cim-vax id <0000083F071@cim-vax.HONEYWELL.COM> ;
  2663.        Tue,  9 Aug 88 08:43:36 CDT
  2664. Date: Tue,  9 Aug 88 08:41:03 CDT
  2665. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  2666. Subject: Sorting on two keys
  2667. To: icon-group@arizona.edu
  2668. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  2669. Message-Id: <880809084103.0000083F071@cim-vax.HONEYWELL.COM>
  2670.  
  2671. I guess I'd attack your two key sorting problem by creating a temporary
  2672. list made by converting your counts to strings, right justifying them so
  2673. that they sort properly into lexical order, append the words left justified
  2674. so that THEY sort properly into lexical order, and the sort the result.
  2675. Your keys would be of fixed width, so it would be easy to slice them back
  2676. off again.
  2677.  
  2678. dsc
  2679.  
  2680. From icon-group-request  Wed Aug 10 04:51:25 1988
  2681. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 04:51:25 MST
  2682. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.5/6) via SMTP
  2683.     id AA13281; Wed, 10 Aug 88 04:51:12 MST
  2684. Received: by ucbvax.Berkeley.EDU (5.59/1.30)
  2685.     id AA22179; Wed, 10 Aug 88 04:14:28 PDT
  2686. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2687.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2688.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2689. Date: 9 Aug 88 22:40:52 GMT
  2690. From: hall!pmk@umn-cs.arpa  (Peter Klausler)
  2691. Organization: Cray Research, Inc., Mendota Heights, MN
  2692. Subject: Acquiring icon for Sun-3
  2693. Message-Id: <8421@hall.cray.com>
  2694. Sender: icon-group-request@arizona.edu
  2695. To: icon-group@arizona.edu
  2696.  
  2697. I would like to use icon for some rapid prototyping work on a Sun-3/50
  2698. workstation. My systems adminstrator has promised to bring icon up
  2699. on our machines if I can tell him where he can get it, preferably
  2700. via anonymous FTP.
  2701.  
  2702. Any information regarding availability of icon for the Sun would be
  2703. greatly appreciated. Please respond by mail; I'm sure that this group
  2704. gets more than enough postings like this one.
  2705.  
  2706. - Peter Klausler @ Cray Research compiler development (612) 681-5828
  2707.  
  2708. From kwalker  Wed Aug 10 09:27:51 1988
  2709. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 09:27:51 MST
  2710. Date: Wed, 10 Aug 88 09:27:47 MST
  2711. From: "Kenneth Walker" <kwalker>
  2712. Message-Id: <8808101627.AA04281@megaron.arizona.edu>
  2713. Received: by megaron.arizona.edu (5.59-1.5/6)
  2714.     id AA04281; Wed, 10 Aug 88 09:27:47 MST
  2715. In-Reply-To: <880808084125.00000267071@cim-vax.HONEYWELL.COM>
  2716. To: icon-group@arizona.edu
  2717. Subject: Re:  Most thoughts on tables
  2718.  
  2719. > Date: Mon,  8 Aug 88 08:41:25 CDT
  2720. > From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  2721. > While thinking over the problem of getting the list of entry values for a
  2722. > table, it occurred to me to wonder if you had considered implementing bags.
  2723.  
  2724. A list can be thought of as a bag with ordering. Are there operations
  2725. missing from lists that should be included with bags?
  2726.  
  2727. > I was also wondering about the unary ? operator.  This is the equivalent of
  2728. > "drawing (a random element) with replacement."  Is there an easy way to do
  2729. > drawing without replacement?  
  2730.  
  2731. Here is a procedure that does drawing without replacement on sets:
  2732.  
  2733. procedure draw_from_set(s)
  2734.    local elem
  2735.  
  2736.    elem := ?s | fail
  2737.    delete(s, elem)
  2738.    return elem
  2739. end
  2740.  
  2741. Of course it doesn't work if you need multiple occurances of a value. You
  2742. could put the values in records to make each occurance "unique":
  2743.  
  2744. record bucket(value)
  2745.  
  2746. procedure rand(s)
  2747.    local elem
  2748.  
  2749.    elem := ?s | fail
  2750.    delete(s, elem)
  2751.    return elem.value
  2752. end
  2753.  
  2754. Though this is prehaps getting awkward.
  2755.  
  2756.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  2757.    +1 602 621 2858  kwalker@Arizona.EDU   {allegra|noao}!arizona!kwalker
  2758.  
  2759. From andrey  Wed Aug 10 14:01:24 1988
  2760. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 14:01:24 MST
  2761. Date: Wed, 10 Aug 88 14:01:21 MST
  2762. From: "Andrey K. Yeatts" <andrey>
  2763. Message-Id: <8808102101.AA16422@megaron.arizona.edu>
  2764. Received: by megaron.arizona.edu (5.59-1.5/6)
  2765.     id AA16422; Wed, 10 Aug 88 14:01:21 MST
  2766. To: icon-group
  2767. Subject: ordering info
  2768.  
  2769. Here's one for the icon-project. I thought you folks also
  2770. saw icon-group-requests.
  2771.  
  2772.     From sendai!rich@umix.cc.umich.edu Thu Jul 28 02:14:53 1988
  2773.     Date: Thu, 28 Jul 88 04:43:09 edt
  2774.     From: sendai!rich@umix.cc.umich.edu
  2775.     Message-Id: <8807280843.AA04436@oxtrap.UUCP>
  2776.     To: oxtrap!icon-group-request@arizona.edu
  2777.     Subject: tape ordering info
  2778.     Reply-To: oxtrap!rich@umix.cc.umich.edu
  2779.     Status: RO
  2780.     
  2781.     What was that address and price again for the current Icon tape?  And
  2782.     can you tell me the current list of machines believed to work?  I'm
  2783.     interested in sun3's (and which os version), general berkeley (really
  2784.     sequent dynix), mips, for starters.  (I *will* order a tape.  I just
  2785.     want to know how much and where to send my check.)
  2786.     
  2787.     
  2788.  
  2789. From @CUNYVM.CUNY.EDU:NETWORK@FRSAC11.BITNET  Wed Aug 10 14:49:17 1988
  2790. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 14:49:17 MST
  2791. Message-Id: <8808102148.AA19115@megaron.arizona.edu>
  2792. Received: from cunyvm.cuny.edu by megaron.arizona.edu (5.59-1.5/6) via SMTP
  2793.     id AA19115; Wed, 10 Aug 88 14:48:26 MST
  2794. Received: from FRSAC11.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 5548; Wed, 10 Aug 88 12:13:11 EDT
  2795. Date: Wed, 10 Aug 88 18:12:50 GMT
  2796. To: icon-group@arizona.edu
  2797. From: NETWORK%FRSAC11.BITNET@CUNYVM.CUNY.EDU
  2798. Comment: CROSSNET mail via SMTP@INTERBIT
  2799. Subject: Icon's lack of speed
  2800.  
  2801. I may be wrong, but this is what I think.
  2802.  
  2803. About Icon's execution speed:
  2804.  
  2805. Fact #1:Icon is written in a highly portable fashion.
  2806. Fact #2:Icon is an experimental language, subject to quite fast evolution.
  2807.  
  2808. From #1 and #2, plus reading the book on Icon implementation, one can
  2809. deduce a few other:
  2810. Fact #3.1 The Virtual Machine instruction set is of the high level type.
  2811. (Type checking, etc are done at run time, and do not appear explicitly
  2812. in VM instructions)
  2813. Fact #3.2 Itran is very simple, translating Icon source statement into
  2814. VM instructions in a very straight forward way. No optimisations.
  2815. Fact #3.3 The VM is a pure stack machine, no register.
  2816. Fact #3.4 There is no immediate operand to the VM instructions.
  2817. Fact #3.5 The internal data representation is not optimal in space
  2818. or time, but is portability oriented.
  2819.  
  2820. All the above are allowing the success of the facts #1 and #2:
  2821. 1. The portability. (Icon's implementation is relying on the bare minimum
  2822.    from a particular type of CPU, word representation, etc)
  2823. 2. The ease of evolution of the language. (Itran and the VM instruction
  2824.    set are indeed very simple.)
  2825.  
  2826. I have been looking at Lisp interpreters and compilers for quite some years
  2827. now, and in this particular domain we know:
  2828. 1. Very efficient compilers do exist now. (Orbit, sometime faster than
  2829.    C, on a Sun (The quality of C on a Sun is an other problem...))
  2830. 2. Type inferencing is important for the above.
  2831. 3. The evaluator MUST NOT generate memory allocations and garbage collections
  2832.     for its own use.
  2833.     (Lisp's Eval used to "cons" a lot for its own use, to manage variable
  2834.     binding, lexical environment, etc. It is not true of modern Lisps)
  2835.     (In my benchmark of a Scheme interpreter lately, the execution profile
  2836.     was showing 50% of the runt time spent in memeory management, just
  2837.     because this Scheme used A-List to store lexical environment...)
  2838. 4. Operand and function call's parameter passing is a lot more efficient
  2839.    if done through "registers" than on a stack.
  2840. 5. Internal data representations have a great influence on the speed.
  2841.  
  2842. What I think about all this applied to Icon:
  2843. 1. Without lowering the level of the VM instructions set it will be
  2844.    difficult to improve the execution speed.
  2845.    (To have type checking at compile time rather than
  2846.    execution time, when possible)
  2847. 2. Either Itran must be brought up to date, in term of compilation
  2848.    and optimization craft, or an optimizing phase must follow it, with
  2849.    the VM instruction set suitably modified.
  2850. 3. The need to call runtime routines is the same in Icon and Lisp,
  2851.    Lisp succeeded in improving dramatically the speed, I see no reason
  2852.    for Icon to fail there, but as far as I know no real effort have been
  2853.    put in this direction, human ressources are limited, and are currently
  2854.    used on other aspect of the Icon project. This is a legitimate
  2855.    choice made by the Icon devellopers.
  2856.    I strongly support my opinion that lack of speed is not a fate of the
  2857.    Icon language itself, but only of this current implementation.
  2858. 4. an immediate speed increase may be obtained by implementing immediate
  2859.    operand in most arithmetic oerations. (removal of one type checking,
  2860.    removal of the memory allocation for the "int n" VM instruction,
  2861.    removal of some garbage collection burdain, etc.)
  2862.    This can be done by:
  2863.    1- Adding new VM instructions for integer arithmetics and comparisons.
  2864.       (No big deal to add instructions in Ilink and Iconx)
  2865.    2- Without modifying Itran, make a filter on the Icode that generate
  2866.       new instructions, when immediate operands are present.
  2867.       (No big deal either, in Icon or C)
  2868. 5. Further speed increased will be gained by making a separation
  2869.    between type checking, type coercion and operations; implying
  2870.    a "smart" Itran, with flow analysis and type inferencing, among
  2871.    other... Adding registers to the VM, and using them. (algorithms
  2872.    to have an optimal use of machine registers are now in common use)
  2873.    This would be a major undertaking, a LOT of work, looking at what
  2874.    has been done with Lisp/Scheme, we are talking about years of work...
  2875.  
  2876. Sorry for my poor English wording, my mother language is still French.
  2877.  
  2878. Jean-Pierre H. Dumas
  2879.  
  2880. network@frsac11 (bitnet)
  2881. network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
  2882. dumas@sumex-aim.stanford.edu (arpanet)
  2883.  
  2884. From gudeman  Wed Aug 10 18:46:42 1988
  2885. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Aug 88 18:46:42 MST
  2886. Date: Wed, 10 Aug 88 18:46:40 MST
  2887. From: "David Gudeman" <gudeman>
  2888. Message-Id: <8808110146.AA29744@megaron.arizona.edu>
  2889. Received: by megaron.arizona.edu (5.59-1.5/6)
  2890.     id AA29744; Wed, 10 Aug 88 18:46:40 MST
  2891. To: icon-group
  2892. In-Reply-To: <8808101627.AA04281@megaron.arizona.edu>
  2893. Subject:  Bags in Icon
  2894.  
  2895. Tables lend themselves to a convenient representation for bags.  Use
  2896. the following translation:
  2897.  
  2898.     b := new_bag  -->  b := table(0)
  2899.     add x to b  -->  b[x] +:= 1
  2900.     remove one x from b  -->  if b[x] > 0 then b[x] -:= 1
  2901.             # here is a place where it would be nice if
  2902.             # Icon comparisons produced variables.  Then
  2903.             # you could write (0 < b[x]) -:= 1
  2904.     remove all x from b  -->  b[x] := 0
  2905.     is x a member of b?  -->  b[x] > 0
  2906.     how many x in b?  -->  b[x]
  2907.  
  2908. This isn't as good as having real bags, but it works.
  2909.  
  2910. From kwalker  Thu Aug 11 13:40:41 1988
  2911. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 11 Aug 88 13:40:41 MST
  2912. Date: Thu, 11 Aug 88 13:40:39 MST
  2913. From: "Kenneth Walker" <kwalker>
  2914. Message-Id: <8808112040.AA10703@megaron.arizona.edu>
  2915. Received: by megaron.arizona.edu (5.59-1.5/6)
  2916.     id AA10703; Thu, 11 Aug 88 13:40:39 MST
  2917. To: icon-group
  2918. Subject: Re:  Icon's lack of speed
  2919.  
  2920. I find Jean-Pierre Dumas's analysis of Icon's lack of speed interesting
  2921. and tend to agree with his conclusions. Some of the current research
  2922. here at the Icon Project is attacking several of the points he brings up.
  2923.  
  2924. Rather than increase the opportunity for optimization by lowering the
  2925. level of a Virtual Maching instruction set implemented by an
  2926. interpreter, we are producing executable code (there are currently some
  2927. prototype compilers written mostly in Icon that are producing code). This
  2928. eliminates the overhead of interpreting operation codes; this overhead
  2929. is not large, but could increase with a lower level instruction set where
  2930. more operations are needed to accomplish the same thing. We are producing
  2931. C code. C is in fact a much lower level instruction set than the current
  2932. i-code, and gives us lots of opportunities for optimization. Assembler
  2933. code would give us several more opportunities for optimization (for
  2934. example in the area of call stack manipulation), but is more work
  2935. to deal with and is not very portable. The model for code generation
  2936. is based on work that Janalee O'Bagy has done for her Ph.D dissertation.
  2937.  
  2938. My main area of research has been type inference in Icon with the
  2939. goal of eliminating most of the run-time type checking. There is
  2940. a prototype inferencing system, but it is not yet being used in a
  2941. compiler.
  2942.  
  2943. Developing a "register" based execution model turns out to be a
  2944. little trickier than one might expect. Because of failure and
  2945. resumption, intermediate values may be reused several times. It
  2946. requires some analysis to determine their maximum lifetime (in
  2947. the stack model their lifetime is extended by copying portions of
  2948. the stack when the values need to be preserved). I have solved this
  2949. problem and we do plan to use such a model. However, the "registers"
  2950. are temporary variables rather than real machine registers. We
  2951. would have to produce assembler code to use machine registers and
  2952. we might have to change the representation of values. The work I
  2953. have done is only the first step in the area of register allocation.
  2954.  
  2955. The point about generating code to use an "immediate operand" is a
  2956. good one! I'll have to think about how that fits into the code
  2957. generation scheme we are devising.
  2958.  
  2959. It looks like the main area we are not addressing is the internal
  2960. representation of data structures. We have discussed this some, but
  2961. so far not much concrete work has been done on it. A major problem
  2962. with producing efficient representations is the generality of
  2963. Icon's data structures. The information from type inferencing could
  2964. be used to tailor data representations to particular uses. This has
  2965. been done for SETL (is it done for Lisp?), but is definitely "future
  2966. work" for Icon.
  2967.  
  2968. There is one area for optimization of Icon that Jean-Pierre Dumas 
  2969. missed, though a person familiar with Prolog optimizations might
  2970. have guessed it. That has to do with recognizing "deterministic"
  2971. expressions, that is ones that never generate values, and eliminating
  2972. the overhead associated with maintaining the state of goad-directed
  2973. evaluation in those places. Janalee has investigated these optimizations.
  2974. Because of Icon's generators and its unique control structures these
  2975. turn out to be quite different from Prolog optimizations. Most Icon
  2976. programs have lots of these deterministic expressions and Janalee has
  2977. been able to significantly reduce the overhead associated with control
  2978. flow in Icon.
  2979.  
  2980.  
  2981. Note: 
  2982.  
  2983.    The primary motivation for developing a compiler is research. It
  2984.    is much too early to know whether this research will produce
  2985.    anything that is distributable. Those of you waiting for such
  2986.    a compiler shouldn't hold your breath.
  2987.  
  2988.  
  2989.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  2990.    +1 602 621 2858  kwalker@Arizona.EDU   {allegra|noao}!arizona!kwalker
  2991.  
  2992. From icon-group-request  Mon Aug 22 12:39:23 1988
  2993. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 22 Aug 88 12:39:23 MST
  2994. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.6/8) via SMTP
  2995.     id AA00674; Mon, 22 Aug 88 12:38:05 MST
  2996. Received: by ucbvax.Berkeley.EDU (5.59/1.30)
  2997.     id AA24854; Sun, 21 Aug 88 21:26:01 PDT
  2998. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2999.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3000.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3001. Date: 22 Aug 88 03:11:41 GMT
  3002. From: cs.utexas.edu!ut-emx!mic@husc6.harvard.edu  (Mic (... K[a-z]+) Kaczmarczik)
  3003. Organization: UT Austin Computation Center, User Services Unix Support Group
  3004. Subject: Icon version 7 for an Encore running UMAX 4.2?
  3005. Message-Id: <5270@ut-emx.UUCP>
  3006. Sender: icon-group-request@arizona.edu
  3007. To: icon-group@arizona.edu
  3008.  
  3009.  
  3010. I'm thinking of trying to build Icon version 7 on an Encore Multimax
  3011. running UMAX 4.2, a variant of 4.2 BSD.  Has anyone out there tried
  3012. this?
  3013.  
  3014. Thanks in advance,
  3015.  
  3016. Mic Kaczmarczik                        mic@emx.utexas.edu
  3017. UT Austin Computation Center                MIC@UTAIVC.BITNET
  3018.  
  3019. -- 
  3020. Mic Kaczmarczik            If you drink, don't drill.
  3021. UT Austin Computation Center            -- Matt Groening
  3022. mic@emx.utexas.edu    
  3023. MIC@UTAIVC.BITNET
  3024.  
  3025. From icon-group-request  Mon Aug 22 13:54:05 1988
  3026. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 22 Aug 88 13:54:05 MST
  3027. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.6/8) via SMTP
  3028.     id AA04547; Mon, 22 Aug 88 13:53:42 MST
  3029. Received: by ucbvax.Berkeley.EDU (5.59/1.30)
  3030.     id AA08556; Mon, 22 Aug 88 13:24:18 PDT
  3031. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3032.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3033.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3034. Date: 22 Aug 88 19:39:46 GMT
  3035. From: mccarrol@topaz.rutgers.edu  (Mark C. Carroll <mccarrol@topaz.rutgers.edu>)
  3036. Organization: Rutgers Univ., New Brunswick, N.J.
  3037. Subject: Logical Expressions
  3038. Message-Id: <Aug.22.15.39.41.1988.5141@topaz.rutgers.edu>
  3039. Sender: icon-group-request@arizona.edu
  3040. To: icon-group@arizona.edu
  3041.  
  3042.  
  3043. I have a problem that I think is probably due to a misunderstanding of
  3044. something simple in Icon, and I'd appreciate any help anyone could
  3045. give me.
  3046.  
  3047. What I'm trying to do is locate an instance of a structure in a list.
  3048. The structure is a record, with 7 fields. I know 4 of the fields,
  3049. and I need to find the structure which matches the 4 fields I know.
  3050.  
  3051. I can't figure out how to write a simple compare that will success
  3052. if and only if those four fields match. I can't find any way to do
  3053. a simple "If this AND this then ...". I don't have a copy of the
  3054. Icon book, and the overview and source code that I have don't mention
  3055. anything like this. 
  3056.  
  3057. Also, if anyone can give me information on a good book about icon,
  3058. I'd appreciate it. I need enough info to get a bookstore to orderit..
  3059.  
  3060.     Thanks,
  3061.  
  3062.         -Mark
  3063. -- 
  3064.  /   <MC>=Mark Craig Carroll          || "Old Soldiers never die            \
  3065. |  **Temporary Hippy for August**     \/                                     |
  3066. |     mccarrol@topaz.rutgers.edu      /\   Young ones do"                    |
  3067.  \ ...backbone!rutgers!topaz!mccarrol ||                 -unknown           /
  3068.  
  3069. From att!ihnp4!ihuxy!nowlin  Mon Aug 22 15:14:30 1988
  3070. Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 22 Aug 88 15:14:30 MST
  3071. Message-Id: <8808222214.AA08523@megaron.arizona.edu>
  3072. Received: by megaron.arizona.edu (5.59-1.6/8)
  3073.     id AA08523; Mon, 22 Aug 88 15:14:28 MST
  3074. Received: by att.ATT.COM (smail2.5 - att-ih)
  3075.     id AA07608; 22 Aug 88 16:35:35 CDT (Mon)
  3076. From: ihnp4!ihuxy!nowlin
  3077. Received: by ihnp4.ATT.COM id AA21462; 22 Aug 88 16:35:16 CDT (Mon)
  3078. Message-Version: 2
  3079. >To: /addr=ihnp4!arizona!icon-group
  3080. Date: Mon 22 Aug 1988 16:35 CDT
  3081. End-Of-Header: 
  3082. Email-Version: 2
  3083. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  3084. To: arizona!icon-group
  3085. Subject: Re: Logical Expressions
  3086. Ua-Message-Id: <post.nowlin.Mon 22 Aug 1988 16:14 CDT>
  3087. End-Of-Protocol: 
  3088. Content-Length: 2170
  3089.  
  3090. > What I'm trying to do is locate an instance of a structure in a list.
  3091. > The structure is a record, with 7 fields. I know 4 of the fields,
  3092. > and I need to find the structure which matches the 4 fields I know.
  3093. > I can't figure out how to write a simple compare that will success
  3094. > if and only if those four fields match. I can't find any way to do
  3095. > a simple "If this AND this then ...". I don't have a copy of the
  3096. > Icon book, and the overview and source code that I have don't mention
  3097. > anything like this. 
  3098. > -- 
  3099. >  /   <MC>=Mark Craig Carroll          || "Old Soldiers never die            \
  3100. > |  **Temporary Hippy for August**     \/                                     |
  3101. > |     mccarrol@topaz.rutgers.edu      /\   Young ones do"                    |
  3102. >  \ ...backbone!rutgers!topaz!mccarrol ||                 -unknown           /
  3103.  
  3104. Given the lack of a real example I took a shot at this anyway.  Try this
  3105. little program which contains an example list of records and a simple "if"
  3106. statement to test the first four fields against constant values.  It uses
  3107. goal directed evaluation to do so.  The key is the initial assignment
  3108. statement inside the logical expression.
  3109.  
  3110. ##########################################################################
  3111.  
  3112. record voter(rep,dem,lib,con,name,j2,j3)
  3113.  
  3114. procedure main()
  3115.  
  3116.     l1 := []
  3117.     put(l1,voter("yes","no","maybe","maybe","Lynn","?","?"))
  3118.     put(l1,voter("no","no","maybe","maybe","Rose","?","?"))
  3119.     put(l1,voter("no","no","no","yes","John","?","?"))
  3120.     put(l1,voter("maybe","maybe","maybe","maybe","Joe","?","?"))
  3121.     put(l1,voter("no","yes","yes","no","Sue","?","?"))
  3122.     put(l1,voter("yes","no","no","yes","Hank","?","?"))
  3123.  
  3124.     if v := !l1 &
  3125.        v.rep == "maybe" &
  3126.        v.dem == "maybe" &
  3127.        v.lib == "maybe" &
  3128.        v.con == "maybe" then
  3129.         write("It looks like ",v.name," is undecided.")
  3130.     else
  3131.         write("It looks like nobody is undecided.")
  3132. end
  3133.  
  3134. ##########################################################################
  3135.  
  3136. Notice that since this is an "if" it will only find the first record with
  3137. four initial matching fields.  This expression could be written to find
  3138. all of the matches with an "every".
  3139.  
  3140. Jerry Nowlin
  3141. (...!att!ihuxy!nowlin)
  3142.  
  3143. From DSCARGO@cim-vax.HONEYWELL.COM  Tue Aug 23 09:28:20 1988
  3144. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 23 Aug 88 09:28:20 MST
  3145. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.6/8) via SMTP
  3146.     id AA17916; Tue, 23 Aug 88 09:28:08 MST
  3147. Received: by cim-vax id <0000082D081@cim-vax.HONEYWELL.COM> ;
  3148.        Tue, 23 Aug 88 11:26:52 CDT
  3149. Date: Tue, 23 Aug 88 11:03:24 CDT
  3150. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  3151. Subject: Mouse Interface of MS-DOS using Int86(a)
  3152. To: icon-group@arizona.edu
  3153. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  3154. Message-Id: <880823110324.0000082D081@cim-vax.HONEYWELL.COM>
  3155.  
  3156. Has anybody built a Microsoft Mouse interface using the Int86(a) function
  3157. covered under IPD32a, Additional Functions for MS-DOS Icon?  The C Users
  3158. Journal, Sept/Oct 1988, pages 88-90 has a mouse interface using Turbo C.
  3159. The tricky parts appear to be getting values of the segment registers
  3160. (so that valid inputs can be provided to Int86) and mapping a new graphics
  3161. image onto the mouse cursor, which requires putting the address of an
  3162. array in DX and the data segment address in ES.
  3163.  
  3164. Icon is high level enough to make handling some structures straight
  3165. forward, but arranging for bit map images to be in exactly the right
  3166. places and pointed to the right way looks tricky (and perhaps not possible).
  3167. GetSpace, Peek, and Poke are probably adequate for putting values into
  3168. known locations, but it's not clear that the address returned by GetSpace
  3169. is compatible with DX.
  3170.  
  3171. This is probably bending what Icon and the Additional Functions were intended
  3172. for, but as long as it looked possible, I thought it can't hurt to ask.
  3173.  
  3174. David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
  3175.  
  3176. From ralph  Tue Aug 23 09:54:22 1988
  3177. Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 23 Aug 88 09:54:22 MST
  3178. Date: Tue, 23 Aug 88 09:52:30 MST
  3179. From: "Ralph Griswold" <ralph>
  3180. Message-Id: <8808231652.AA19007@megaron.arizona.edu>
  3181. Received: by megaron.arizona.edu (5.59-1.6/8)
  3182.     id AA19007; Tue, 23 Aug 88 09:52:30 MST
  3183. To: DSCARGO@cim-vax.HONEYWELL.COM, icon-group@arizona.edu
  3184. Subject: Re:  Mouse Interface of MS-DOS using Int86(a)
  3185. In-Reply-To: <880823110324.0000082D081@cim-vax.HONEYWELL.COM>
  3186.  
  3187. We have some screen/window functions for MS-DOS Icon, but no mouse
  3188. interface that I know of.  What we have consists of contributions
  3189. to the Icon program library and will be included in the next
  3190. release of the library.
  3191.  
  3192. However, the design of Int86 isn't really satisfactory.  It takes a
  3193. 9-element list as its argument and returns another 9-element list.
  3194. Constructing two lists for every call of Int86 causes heavy memory
  3195. throughput and it's slow.
  3196.  
  3197.  
  3198.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  3199.    +1 602 621 6609   ralph@Arizona.EDU     {allegra|noao|ihnp4}!arizona!ralph
  3200.  
  3201.  
  3202. From icon-group-request  Thu Aug 25 10:37:19 1988
  3203. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 25 Aug 88 10:37:19 MST
  3204. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.6/8) via SMTP
  3205.     id AA12008; Thu, 25 Aug 88 10:36:57 MST
  3206. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  3207.     id AA19304; Thu, 25 Aug 88 09:37:15 PDT
  3208. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3209.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3210.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3211. Date: 25 Aug 88 13:01:33 GMT
  3212. From: astroatc!tenaglia@speedy.cs.wisc.edu  (Chris Tenaglia)
  3213. Organization: Astronautics Technology Cntr, Madison, WI
  3214. Subject: Re: Logical Expressions
  3215. Message-Id: <1163@astroatc.UUCP>
  3216. References: <Aug.22.15.39.41.1988.5141@topaz.rutgers.edu>
  3217. Sender: icon-group-request@arizona.edu
  3218. To: icon-group@arizona.edu
  3219.  
  3220.  
  3221.  
  3222. I  am  a  heavy  user of ICON, and I've tried just about everything
  3223. once.  The  ICON  PROGRAMMING  LANGUAGE  does  a fairly good job of
  3224. describing  the  language to a programmer type person. I have heard
  3225. of  other  books in the making that may cater more to people in the
  3226. humanities.
  3227.  
  3228. I  use  ICON  on  VAX  VMS  and  MS-DOS.  If care is taken, totally
  3229. portable programs can be written.
  3230.  
  3231. In response to an article concerning the use of records I'd like to
  3232. offer a few tips. ICON records are a little tricky. I think of them
  3233. as a means of declaring user define data types. They must always be
  3234. declared  near  the  beginning  of  a  file. Usually before for the
  3235. globals.  They  are global in scope and external to all procedures.
  3236. Here's a sample declaration...
  3237.  
  3238.    #BEGINNING OF FILE
  3239.    record article(name,date,title,desc,page)
  3240.    global this,that,etc,...
  3241.    procedure main(param)
  3242.    ...
  3243.  
  3244. To  store a bunch of records for use, I prefer a list. The database
  3245. is  stored  in a file. A non-printing character is used delimit the
  3246. individual  fields. The fields are loaded into the database using a
  3247. technique something like the following...
  3248.  
  3249.    database := list()
  3250.    temp     := list()
  3251.    chars    := &cset -- '\377'
  3252.    in       := open("zine.dat")
  3253.    every line := !in do
  3254.     {
  3255.     temp := []
  3256.     line ? while tab(upto(chars)) do put(temp,tab(many(chars)))
  3257.     put(database,article(temp[1],temp[2],temp[3],temp[4],temp[5]))
  3258.     }
  3259.  
  3260. The  list  database  is  filled with elements of type article. Each
  3261. field  of  the  record is filled with a string. The article records
  3262. can  be  walked through with a generator. Therefore to illustrate a
  3263. multifield  lookup  on a list of records here's a sample that might
  3264. get you started in the right direction.
  3265.  
  3266.     every tuple := !database do
  3267.       {
  3268.       if (tuple.name == field1) &
  3269.          (tuple.date == field2) &
  3270.          (find(field3,tuple.desc)) then found(tuple)
  3271.       ...
  3272.       }
  3273.  
  3274. Notice the use of & for a logical and. Likewise | would be used for
  3275. logical or. Both ~ and not can be used for negation.
  3276.  
  3277. Here   tuple   gets  loaded with article records from database. The
  3278. type  of tuple I think is "record" or "article". The type of a data
  3279. element  such as tuple.name is string. To rewrite the database to a
  3280. file I might use a routine something like ...
  3281.  
  3282.   if changes = 0 then stop("Exit. No changes made.")
  3283.   out   := open("zine.dat","w")
  3284.   a     := "\377"
  3285.   count := 0
  3286.   while items := pop(database) do
  3287.     {
  3288.     write(out,items.name,a,items.date,a,items.title,a,
  3289.               items.desc,a,items.page)
  3290.     count +:= 1
  3291.     }
  3292.   close(out)
  3293.   write("\n",count," records stored.")
  3294.  
  3295. I  hope  this may be of use. I'm looking for easy graphics routines
  3296. that  do TEKTRONIX 4014 or 4105 protocols or REGIS graphics. Anyone
  3297. care  to  post anything? I'm mostly interested in simple primitives
  3298. such  as  line(x1,y1,x2,y2,b),  dot(x,y),  color(c), circle(x,y,r),
  3299. fill(x,y).  Thanx loads...
  3300.  
  3301. Yours truly,
  3302.  
  3303. Chris Tenaglia
  3304. Astronautics Corporation of America
  3305. 4115 N. Teutonia Avenue
  3306. Milwaukee, Wi 53209 USA
  3307. (414) 447-8200 X-450
  3308.  
  3309. From kwalker  Thu Aug 25 12:05:52 1988
  3310. Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 25 Aug 88 12:05:52 MST
  3311. Date: Thu, 25 Aug 88 12:05:47 MST
  3312. From: "Kenneth Walker" <kwalker>
  3313. Message-Id: <8808251905.AA20784@megaron.arizona.edu>
  3314. Received: by megaron.arizona.edu (5.59-1.6/8)
  3315.     id AA20784; Thu, 25 Aug 88 12:05:47 MST
  3316. In-Reply-To: <1163@astroatc.UUCP>
  3317. To: icon-group@arizona.edu
  3318. Subject: Re: Logical Expressions
  3319.  
  3320. > Date: 25 Aug 88 13:01:33 GMT
  3321. > From: astroatc!tenaglia@speedy.cs.wisc.edu  (Chris Tenaglia)
  3322.  
  3323. ...
  3324.  
  3325. > In response to an article concerning the use of records I'd like to
  3326. > offer a few tips. ICON records are a little tricky. I think of them
  3327. > as a means of declaring user define data types. They must always be
  3328. > declared  near  the  beginning  of  a  file. Usually before for the
  3329. > globals.
  3330.  
  3331. The important point is that they cannot be declared inside a procedure.
  3332. You can think of record, global, and procedure declarations as all being
  3333. at the same "level" with the restriction that they cannot be nested. I
  3334. know of no reason why they must be declared at the beginning of the file,
  3335. but I find it to be a good programming convention and will join with
  3336. Chris in recommending it.
  3337.  
  3338.   ...
  3339.  
  3340. > Both ~ and not can be used for negation.
  3341.  
  3342. Yes, but it should be pointed out that they are used as negation in
  3343. very different ways.  "not" is an operator (or, perhaps more correctly,
  3344. a control structure), as in
  3345.  
  3346.    if not (s == "end") then ...
  3347.  
  3348. while ~ is used as part of on operator, as in
  3349.  
  3350.    if s ~== "end" then ...
  3351.  
  3352. When ~ is used as an operator it means cset compliment, which is
  3353. somewhat different from negation. Consider the meaning of
  3354.  
  3355.    if not upto('b', "aaabaaa") then ...
  3356.  
  3357. The then clause will not be executed because the string contains b. Now
  3358. consider
  3359.  
  3360.    if upto(~'b', "aaabaaa") then ...
  3361.  
  3362. The then clause will be executed because the string contains a character
  3363. other than b.
  3364.  
  3365.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  3366.    +1 602 621 2858  kwalker@Arizona.EDU   {allegra|noao}!arizona!kwalker
  3367.  
  3368. From DSCARGO@cim-vax.HONEYWELL.COM  Wed Aug 31 06:56:53 1988
  3369. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 31 Aug 88 06:56:53 MST
  3370. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.6/8) via SMTP
  3371.     id AA09600; Wed, 31 Aug 88 06:56:37 MST
  3372. Received: by cim-vax id <00001218081@cim-vax.HONEYWELL.COM> ;
  3373.        Wed, 31 Aug 88 08:54:40 CDT
  3374. Date: Wed, 31 Aug 88 08:43:25 CDT
  3375. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  3376. Subject: trimming revisited
  3377. To: icon-group@arizona.edu
  3378. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  3379. Message-Id: <880831084325.00001218081@cim-vax.HONEYWELL.COM>
  3380.  
  3381. I realize that what I want (discussed below) could be implemented in many
  3382. ways, but I'm interested in feedback from others about the need.  I'm
  3383. finding in many cases that the trim function isn't quite flexible enough
  3384. for what I need.  On some other systems I've used, there are three trimming
  3385. functions: a left trim, a right trim, and a both trim.  The right trim removes
  3386. trailing whitespace from the right end.  (This is the one most similar to
  3387. trim.)  The left trim removes leading whitespace from the left end.  The
  3388. both trim removes both leading and trailing whitespace.  I've often found
  3389. that (because it's easy to write and understand) that I'm using something like
  3390. line := trim(reverse(trim(reverse(read())))) in order to read lines with
  3391. whitespace removed.  I'd much rather use something like line := btrim(read()))
  3392. and I expect that it would perform somewhat better.
  3393.  
  3394. In some respects, trim is the flipside of right, which pads a string on the
  3395. right.  There are no trimming functions that correspond to left and center.
  3396. Just as a left trim and both trim can be built out of trim, left and center
  3397. could be built out of right.  There is no logical necessity for adding
  3398. left and both trim, but it would make several of my programming tasks
  3399. somewhat easier.
  3400.  
  3401. Anybody else have similar needs?
  3402.  
  3403. David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
  3404.  
  3405. From att!ihlpe!orf  Wed Aug 31 08:04:04 1988
  3406. Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 31 Aug 88 08:04:04 MST
  3407. From: att!ihlpe!orf
  3408. Message-Id: <8808311504.AA12203@megaron.arizona.edu>
  3409. Received: by megaron.arizona.edu (5.59-1.6/8)
  3410.     id AA12203; Wed, 31 Aug 88 08:04:02 MST
  3411. Received: by att.ATT.COM (smail2.5 - att-cb)
  3412.     id AA29545; 31 Aug 88 10:42:56 EDT (Wed)
  3413. Message-Version: 2
  3414. >To: /addr=arpa!cim-vax.HONEYWELL.COM!DSCARGO,
  3415.      /addr=att!arizona!icon-group
  3416. Date: Wed 31 Aug 1988 09:45 CDT
  3417. End-Of-Header: 
  3418. Email-Version: 2
  3419. X-Postmark: ihlpe!orf
  3420. To: att!arizona!icon-group
  3421. Cc: arpa!cim-vax.HONEYWELL.COM!DSCARGO
  3422. Subject: Re: trimming revisited
  3423. Ua-Message-Id: <post.orf.Wed 31 Aug 1988 09:15 CDT>
  3424. End-Of-Protocol: 
  3425. Content-Length: 602
  3426.  
  3427.  
  3428.  >...
  3429.  >could be built out of right.  There is no logical necessity for adding
  3430.  >left and both trim, but it would make several of my programming tasks
  3431.  >somewhat easier.
  3432.  >
  3433.  >Anybody else have similar needs?
  3434.  >
  3435.  >David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
  3436.  >
  3437. I have personally noticed a simliar need, and agree with David that a more 
  3438. generalized trim() (upward compatible -> add an argument) would be useful. 
  3439.  
  3440. I often write scanning expressions - simply to trim leading whitespace. A
  3441. built-in function would be nice.
  3442.  
  3443.  
  3444. O. Rick Fonorow
  3445. AT&T Bell Labs
  3446. IW 2B-462 
  3447. (312) 979-7173
  3448. ...!att!ihlpe!orf
  3449.  
  3450. From irv@aramis.rutgers.edu  Wed Aug 31 15:49:34 1988
  3451. Received: from ARAMIS.RUTGERS.EDU by megaron.arizona.edu (5.59-1.6/10) via SMTP
  3452.     id AA05244; Wed, 31 Aug 88 15:49:34 MST
  3453. Received: by aramis.rutgers.edu (5.59/1.15) 
  3454.     id AA21069; Wed, 31 Aug 88 18:46:44 EDT
  3455. Date: Wed, 31 Aug 88 18:46:44 EDT
  3456. From: irv@aramis.rutgers.edu (Irving N. Rabinowitz)
  3457. Message-Id: <8808312246.AA21069@aramis.rutgers.edu>
  3458. To: icon-group@arizona.edu
  3459. Subject: Change of addess
  3460.  
  3461. An apology for sending this far and wide, but I don't have the correct
  3462. address for making address changes.
  3463.  
  3464. My address used to be
  3465.  
  3466.             rabinowitz@rutgers.edu
  3467.  
  3468. and is now
  3469.  
  3470.             rabinowitz@aramis.rutgers.edu
  3471.  
  3472. Please continue me on the distribution.  Thanks.
  3473.  
  3474.                 --Irv (rabinowitz@aramis.rutgers.edu)
  3475.  
  3476. From icon-group-request  Mon Sep  5 20:22:44 1988
  3477. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.6/11) via SMTP
  3478.     id AB23549; Mon, 5 Sep 88 20:22:44 MST
  3479. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  3480.     id AA17221; Mon, 5 Sep 88 19:48:54 PDT
  3481. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3482.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3483.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3484. Date: 6 Sep 88 01:57:18 GMT
  3485. From: mkhaw@teknowledge-vaxc.arpa  (Mike Khaw)
  3486. Organization: Teknowledge, Inc., Palo Alto CA
  3487. Subject: whatever happened to Rebus?
  3488. Message-Id: <24781@teknowledge-vaxc.ARPA>
  3489. Sender: icon-group-request@arizona.edu
  3490. To: icon-group@arizona.edu
  3491.  
  3492. Is Rebus(*) still under development or were its lessons folded back into Icon
  3493. and Rebus itself abandoned?
  3494.  
  3495. Mike Khaw
  3496.  
  3497. * - R. E. Griswold, "Rebus - A SNOBOL4/Icon Hybrid", _SIGPLAN_Notices_,
  3498.     v20#2, Feb. 1985, pp 7-16.
  3499. -- 
  3500. internet: mkhaw@teknowledge.arpa
  3501. uucp:      {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
  3502. hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
  3503.  
  3504. From ralph  Mon Sep  5 20:40:39 1988
  3505. Date: Mon, 5 Sep 88 20:40:39 MST
  3506. From: "Ralph Griswold" <ralph>
  3507. Message-Id: <8809060340.AA23974@megaron.arizona.edu>
  3508. Received: by megaron.arizona.edu (5.59-1.6/11)
  3509.     id AA23974; Mon, 5 Sep 88 20:40:39 MST
  3510. To: icon-group@arizona.edu, mkhaw@teknowledge-vaxc.arpa
  3511. Subject: Re:  whatever happened to Rebus?
  3512. In-Reply-To: <24781@teknowledge-vaxc.ARPA>
  3513.  
  3514. There was not enough interest in Rebus for us to continue to
  3515. support it.  Every so often we get an inquirey, but we're
  3516. devoting most of our resources to supporting Icon now.
  3517.  
  3518.  
  3519.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  3520.    +1 602 621 6609   ralph@Arizona.EDU     {allegra|noao|uunet}!arizona!ralph
  3521.  
  3522.  
  3523. From DSCARGO@cim-vax.HONEYWELL.COM  Thu Sep  8 06:38:53 1988
  3524. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/12) via SMTP
  3525.     id AA18485; Thu, 8 Sep 88 06:38:53 MST
  3526. Received: by cim-vax id <0000116D071@cim-vax.HONEYWELL.COM> ;
  3527.        Thu,  8 Sep 88 08:37:32 CDT
  3528. Date: Thu,  8 Sep 88 08:26:23 CDT
  3529. From: David S. Cargo MN67-2F08 593-2822 <DSCARGO@cim-vax.HONEYWELL.COM>
  3530. Subject: Customizing Icon for VMS
  3531. To: icon-group@arizona.edu
  3532. X-Vms-Mail-To: EXOS%"icon-group@arizona.edu"
  3533. Message-Id: <880908082623.0000116D071@cim-vax.HONEYWELL.COM>
  3534.  
  3535. Where I am at inside of Honeywell we are looking at Icon as a kind of Swiss
  3536. Army knife.  There are some things we would like it to do that it doesn't now,
  3537. and that aren't particularly real language changes that we'd like to make some
  3538. other things easier.  I'm just trying to get a feel for how many Icon users
  3539. have made their own changes and how hard (or easy) it's been.
  3540.  
  3541. The change we have uppermost in mind right now is to build a data base query
  3542. interface into Icon.  (In particular, we are looking at interfacing with
  3543. INGRES.)  I expect what we would want (and here I'm interested in other
  3544. opinions) is a function that accepts a couple of character strings (a query
  3545. string and a data base specification string) and then acts as a generator
  3546. returning records from the specified data base that match the specified query.
  3547. A generator can return 0 or more records in a natural way, matching the way
  3548. a relational query can return 0 or more records. Actually, I expect the
  3549. returned result would be a list instead of a record because a record must be
  3550. predeclared, and a generator would more naturally return a list.
  3551.  
  3552. Is the Icon implementation book an adequate guide for making this kind of
  3553. change?  Is a more general data base interface something that is in the
  3554. current direction of Icon research?  Is it something other users see as a
  3555. current or future need?
  3556.  
  3557. David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM), the ever curious....
  3558.  
  3559. From ralph  Thu Sep  8 07:38:51 1988
  3560. Date: Thu, 8 Sep 88 07:38:51 MST
  3561. From: "Ralph Griswold" <ralph>
  3562. Message-Id: <8809081438.AA20209@megaron.arizona.edu>
  3563. Received: by megaron.arizona.edu (5.59-1.7/12)
  3564.     id AA20209; Thu, 8 Sep 88 07:38:51 MST
  3565. To: DSCARGO@cim-vax.HONEYWELL.COM
  3566. Subject: Re:  Customizing Icon for VMS
  3567. Cc: icon-group
  3568. In-Reply-To: <880908082623.0000116D071@cim-vax.HONEYWELL.COM>
  3569.  
  3570. Quite a few folks have made changes to the Icon language.  Some of
  3571. these have been quite extensive.
  3572.  
  3573. Obviously, we don't hear about everything.  But from I've seen, my
  3574. impression is that the kinds of things you're thinking about are
  3575. feasible, provided you're willing to invest some time in understanding
  3576. the implementation.
  3577.  
  3578. The implementation book and a supplementary report provide most of
  3579. what you need to know.  What else is needed is study of the source code
  3580. and learning what the parts are, where to find things, and probably
  3581. detailed study of the parts you need to change/interface.
  3582.  
  3583. There is one general problem with making significant modifications to Icon:
  3584. it may be impractical to back them in to new versions of the language.
  3585. For this reason, if you decide to undertake the project you describe,
  3586. you should at least get the most recent version of the source from us
  3587. (not the version in our present distribution).  We're working on a
  3588. new release of the source, which will probably be identified as Version 7.5.
  3589. We don't have a firm release date yet, but I'd expect late this fall or
  3590. early next year.
  3591.  
  3592. As to your question about whether we're planning to add features to
  3593. interface database systems, the answer is no.  We do not have any present
  3594. plans for major changes to the language.  We're always willing to
  3595. consider adding things others do, but they need to be of general
  3596. interest and applicability and also to fit our idea of what language
  3597. features are appropriate for Icon
  3598.  
  3599.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  3600.    +1 602 621 6609   ralph@Arizona.EDU     {allegra|noao|uunet}!arizona!ralph
  3601.  
  3602.  
  3603. From att!ihlpe!orf  Thu Sep  8 19:20:59 1988
  3604. From: att!ihlpe!orf
  3605. Message-Id: <8809090220.AA04462@megaron.arizona.edu>
  3606. Received: by megaron.arizona.edu (5.59-1.7/12)
  3607.     id AA04462; Thu, 8 Sep 88 19:20:59 MST
  3608. Received: by att.ATT.COM (smail2.5 - att-ih)
  3609.     id AA01450; 8 Sep 88 18:42:13 CDT (Thu)
  3610. Message-Version: 2
  3611. >To: /addr=att!arizona!icon-group,
  3612.      /addr=arpa!cim-vax.HONEYWELL.COM!DSCARGO
  3613. Date: Thu 08 Sep 1988 18:32 CDT
  3614. End-Of-Header: 
  3615. Email-Version: 2
  3616. X-Postmark: ihlpe!orf
  3617. To: arpa!cim-vax.HONEYWELL.COM!DSCARGO
  3618. Cc: att!arizona!icon-group
  3619. Subject: Re: Customizing Icon for VMS
  3620. Ua-Message-Id: <post.orf.Thu 08 Sep 1988 18:11 CDT>
  3621. End-Of-Protocol: 
  3622. Content-Length: 3023
  3623.  
  3624.  
  3625.  >The change we have uppermost in mind right now is to build a data base query
  3626.  >interface into Icon.  (In particular, we are looking at interfacing with
  3627.  >INGRES.)  I expect what we would want (and here I'm interested in other
  3628.  >opinions) is a function that accepts a couple of character strings (a query
  3629.  >string and a data base specification string) and then acts as a generator
  3630.  >returning records from the specified data base that match the specified query.
  3631.  >A generator can return 0 or more records in a natural way, matching the way
  3632.  >a relational query can return 0 or more records. Actually, I expect the
  3633.  >returned result would be a list instead of a record because a record must be
  3634.  >predeclared, and a generator would more naturally return a list.
  3635.  >
  3636.  >Is the Icon implementation book an adequate guide for making this kind of
  3637.  >change?  Is a more general data base interface something that is in the
  3638.  >current direction of Icon research?  Is it something other users see as a
  3639.  >current or future need?
  3640.  >
  3641.  >David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM), the ever curious....
  3642.  >
  3643.  
  3644. Well, if you come up with a "neat" way to add a lot of functionality (the
  3645. existing choices seem to be between adding a large number of new built-in
  3646. functions versus some smaller number with more "meaningful" arguments) Please
  3647. let me (and the icon-project) know!
  3648.  
  3649. We (Jerry Nowlin and I) have looked at doing what you seem to want to do
  3650. for interfacing Icon to a standard windowing interface. We were looking
  3651. at adding scores of new built-in functions (or passing string arguments
  3652. to some generic function) and neither way was particularly appealing, i.e.
  3653. the "single generic" function turned into a large  case/switch stmt. Adding
  3654. 30+ new functions wasn't any more appealing...
  3655.  
  3656. So to get back to your qestion. What you seem to want to do can be handled 
  3657. through the existing "PI" (personalized interpreter) mechanism. The Implement.
  3658. book is an excellent reference. I recommend looking at the existing
  3659. implementation's built-in functions, and finding the ones that are the
  3660. closet to what you want to do.  (Your function sounds analogus to
  3661. the built-in "find" function, so I'd start there.)  There is a man page
  3662. and TR88-7 describing how to build the personalized interpreter after you
  3663. have written you functions.
  3664.  
  3665. My only other advice, based on some extensive prototyping experience with
  3666. Icon, is to build your proposed system first entirely in Icon. That is,
  3667. write Icon procedures that do what you propose (use open(..,"p") or system()
  3668. functions inside your procedures) and what you learn may surpise you. You
  3669. may find  your "Icon" system performs adequately for most applications. Or,
  3670. you may discover that you only have to write a small number of C "library"
  3671. functions that can be called via popen/system to get the performance you
  3672. want.  In other words, I'd try prototyping the system entirely in Icon
  3673. before trying to maintain what amounts to a separate version of the 
  3674. language.
  3675.  
  3676.  
  3677. O. R. Fonorow
  3678. IW 2B-462 x7173
  3679. ihlpe!orf
  3680.  
  3681. From att!ihuxy!nowlin  Thu Sep  8 20:09:17 1988
  3682. From: att!ihuxy!nowlin
  3683. Message-Id: <8809090309.AA07361@megaron.arizona.edu>
  3684. Received: by megaron.arizona.edu (5.59-1.7/12)
  3685.     id AA07361; Thu, 8 Sep 88 20:09:17 MST
  3686. Received: by att.ATT.COM (smail2.5 - att-ih)
  3687.     id AA06145; 8 Sep 88 21:53:41 CDT (Thu)
  3688. Message-Version: 2
  3689. >To: /addr=att!arizona!icon-group
  3690. Date: Thu 08 Sep 1988 21:55 CDT
  3691. End-Of-Header: 
  3692. Email-Version: 2
  3693. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  3694. To: att!arizona!icon-group
  3695. Subject: Re: Customizing Icon for VMS
  3696. Ua-Message-Id: <post.nowlin.Thu 08 Sep 1988 21:29 CDT>
  3697. End-Of-Protocol: 
  3698. Content-Length: 1465
  3699.  
  3700. > ... things easier.  I'm just trying to get a feel for how many Icon users
  3701. > have made their own changes and how hard (or easy) it's been.
  3702. > The change we have uppermost in mind right now is to build a data base query
  3703. > interface into Icon.  (In particular, we are looking at interfacing with
  3704. > INGRES.)  ...
  3705. > David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM), the ever curious....
  3706.  
  3707. I hope I left enough here for people to understand that the original mail
  3708. was about modifying Icon itself to do database queries.  Something like a
  3709. new built-in function was what the posting suggested.  Maybe I'm
  3710. overlooking some criteria for this database interface that people with more
  3711. experience in databases can see, but why not write the database query code
  3712. in Icon and just include it in a library of ucode?
  3713.  
  3714. I've worked with a couple of other people on a database report generator
  3715. for a PC based database program that is used extensively to produce 
  3716. contracts for athletic referees.  I've also written database manipulation
  3717. routines in Icon to interface with the Unity database system that runs on
  3718. UNIX.  Why can't you just do the same kind of thing for your application? 
  3719.  
  3720. I hate to see people continue to think that Icon is great but that they
  3721. have to modify it to do what they really want.  There's an awful lot you
  3722. can do directly with Icon in its latest incarnation.  Database applications
  3723. are definitely within it's scope.
  3724.  
  3725. Jerry Nowlin
  3726. (...!ihnp4!ihuxy!nowlin)
  3727.  
  3728. From UNOCC07%zeus@crcvms.unl.edu  Thu Sep  8 21:52:18 1988
  3729. Message-Id: <8809090452.AA24750@megaron.arizona.edu>
  3730. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/12) via SMTP
  3731.     id AA24750; Thu, 8 Sep 88 21:52:18 MST
  3732. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Thu, 8 Sep 88 21:29 MST
  3733. Date: Thu, 8 Sep 88 22:58 CDT
  3734. From: "Some people would rather die than think; In fact, most do."
  3735.  <UNOCC07%zeus@crcvms.unl.edu>
  3736. Subject: vt100 text-windows for Icon...
  3737. To: icon-group@arizona.edu
  3738. X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
  3739.  
  3740. I have a "package" (suitable for "link"ing) of text-windowing routines
  3741. for Icon, using vt100-specific escape codes and the like.  (Though I
  3742. imagine that they would easily converted to ANSI for MS-DOS...)  The
  3743. source file is probably a bit too large to just post straight to the
  3744. group, especially when only a fraction of the readers might be interested,
  3745. so I'm offering to mail it to anyone that wants it.
  3746.  
  3747. Included in the package, I'll include a sample program that uses the
  3748. routines (the program is a MORE-like text-viewer, inspired by the MS-DOS
  3749. LIST shareware utility), to show you an actual use for them all.  The
  3750. windowing routines are not machine-specific (just terminal-specific), but
  3751. one function used in the sample program, readc(), is.
  3752.  
  3753. I'm using Icon version 7, on a VAX 8650 running VMS 4.7.  readc() is a
  3754. function to asynchronously read a single character from the keyboard
  3755. buffer (and echo it to the screen).  I haven't played with MS-DOS Icon
  3756. much at all, but I would guess that getch() does pretty much the same
  3757. thing.  (correct me if I'm wrong...)  Installing it is a bit more complex
  3758. but if you're interested, I'd be perfectly willing to send it to you as
  3759. well.  (And if you're running VMS, I'll even throw in TERMLOCK, which
  3760. was recently posted to comp.os.vms... [plug, plug] :-)
  3761.  
  3762. Well, there it is.  Free for the asking. :-)  This could even be related
  3763. to the current discussion, I guess,  since the routines (except readc())
  3764. are written in Icon, not added to the language...
  3765.  
  3766. -/ Dave Caplinger /---------------+-----------------------------------------
  3767.   Microcomputer Specialist        | Internet: unocc07%zeus@crcvms.unl.edu
  3768.   Campus Computing                | uucp:     uunet!btni!unocss!dent
  3769.   University of Nebraska at Omaha | Bitnet:   UNOCC07@UNOMA1
  3770.   Omaha, NE 68182                 | (Last Resort: dc3a+@andrew.cmu.edu)
  3771.  
  3772.  
  3773. From UNOCC07%zeus@crcvms.unl.edu  Fri Sep  9 11:34:07 1988
  3774. Message-Id: <8809091834.AA25258@megaron.arizona.edu>
  3775. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/12) via SMTP
  3776.     id AA25258; Fri, 9 Sep 88 11:34:07 MST
  3777. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Fri, 9 Sep 88 11:05 MST
  3778. Date: Fri, 9 Sep 88 12:57 CDT
  3779. From: "Some people would rather die than think; In fact, most do."
  3780.  <UNOCC07%zeus@crcvms.unl.edu>
  3781. Subject: Re: vt100 text windows
  3782. To: icon-group@arizona.edu
  3783. X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
  3784.  
  3785. Good grief!  I had no idea I was going to get this many requests!
  3786.  
  3787. Let me explain a few things about the routines though; some of you may be
  3788. reading more into it than is actually there.  Basically, this routines just
  3789. draw boxes, while keeping a copy of the text "underneath" the boxes.  Since
  3790. there is no across-the-board asynchronous single-key read routine for Icon,
  3791. the window routines cannot restrict input to the boundries of a window, nor
  3792. do they make sure that anything you print to a window does not write past
  3793. the boundaries of the window.  But, since vt-100's only have an 80x25 array
  3794. (or 132x25) of characters, I did not see this as a problem.  Actually, using
  3795. my basic routines, it would not be particularly difficult to make a package
  3796. that would impose those kinds of restructions, but this one isn't it.
  3797.  
  3798. A few other things that windows.icn won't do:
  3799.  
  3800.         -    Windows cannot overlap.
  3801.         -    Windows cannot be scrolled seperately from other windows.
  3802.                 (although VIEW does use scrolling...)
  3803.  
  3804. Basically, I just don't want people to have high hopes that are suddenly
  3805. shattered when the routines actually arrive at their site.  I've been pretty
  3806. disappointed by some public-domain software myself.  That's not to
  3807. say that I think the routines are /bad/, just very basic.  (What more could
  3808. I really do with just vt-100 codes and no assembly language SMG$ routines or
  3809. other machine-specific code?)
  3810.  
  3811. In any case, I'm still of course entertaining the requests of anyone that
  3812. wants the package. :-)
  3813.  
  3814. -/ Dave Caplinger /---------------+-----------------------------------------
  3815.   Microcomputer Specialist        | Internet: unocc07%zeus@crcvms.unl.edu
  3816.   Campus Computing                | uucp:     uunet!btni!unocss!dent
  3817.   University of Nebraska at Omaha | Bitnet:   UNOCC07@UNOMA1
  3818.   Omaha, NE 68182                 | (Last Resort: dc3a+@andrew.cmu.edu)
  3819.  
  3820.  
  3821. From icon-group-request  Thu Sep 15 10:58:36 1988
  3822. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/12) via SMTP
  3823.     id AA06913; Thu, 15 Sep 88 10:58:36 MST
  3824. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  3825.     id AA15078; Thu, 15 Sep 88 01:00:27 PDT
  3826. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3827.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3828.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3829. Date: 15 Sep 88 04:23:03 GMT
  3830. From: att!ihuxz!dutler@ucbvax.Berkeley.EDU  (Stan Dutler)
  3831. Organization: AT&T Bell Laboratories - Naperville, Illinois
  3832. Subject: escaped characters in literal strings
  3833. Message-Id: <3340@ihuxz.ATT.COM>
  3834. Sender: icon-group-request@arizona.edu
  3835. To: icon-group@arizona.edu
  3836.  
  3837. I am writing a scanner for a compiler class. One of the tokens
  3838. is a literal string that is defined as the same as the ICON
  3839. literal string. This means that escaped characters (i.e.,\",\t...)
  3840. must be converted to the appropriate character. Is there a
  3841. builtin function that will do this simply or will I need to
  3842. resort to a good old case statement? Thanks in advance for
  3843. any help.
  3844. -- 
  3845. Stan Dutler               There ya go man, Keep as cool as ya can
  3846. ..ihnp4!ihuxz!dutler          Face piles of trials with smiles     
  3847.  
  3848. From icon-group-request  Thu Sep 15 22:22:37 1988
  3849. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/12) via SMTP
  3850.     id AA14712; Thu, 15 Sep 88 22:22:37 MST
  3851. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  3852.     id AA07480; Thu, 15 Sep 88 20:59:40 PDT
  3853. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3854.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3855.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3856. Date: 16 Sep 88 00:33:16 GMT
  3857. From: vu-vlsi!sword@psuvax1.cs.psu.edu  (David Talmage)
  3858. Organization: Villanova Univ. EE Dept.
  3859. Subject: reading and writing heterogeneous lists
  3860. Message-Id: <1888@vu-vlsi.Villanova.EDU>
  3861. Sender: icon-group-request@arizona.edu
  3862. To: icon-group@arizona.edu
  3863.  
  3864.  
  3865.  
  3866. While working on other things, I've had the need for a library of
  3867. procedures that read, write, and pretty print lists, sets, and tables.
  3868. I've found an elegant solution that uses the call-by-string-value
  3869. feature of Icon.  From a software engineering point of view, it's not
  3870. such a good thing, I suppose, because it could be difficult to
  3871. determine from a source listing what exactly is happening.  I solicit
  3872. your opinions on this and, if there is sufficient interest and we all
  3873. agree that it is a good thing, will post my library of heterogeneous
  3874. I/O procedures to comp.sources.misc.
  3875.  
  3876.  
  3877. Briefly, to write a list, I write the number of elements in the list,
  3878. followed by an ordered pair: the type of an element followed by the
  3879. actual element.
  3880.  
  3881. To recreate the list from a file, I read the number of elements, make
  3882. a list that big, and read each ordered pair: the type of an element
  3883. followed by the element.
  3884.  
  3885. My procedures expect the procedures that read and write single
  3886. elements of the various types to behave in a similar manner.
  3887.  
  3888.  
  3889.  
  3890. To write a list I use a procedure much like this:
  3891.  
  3892.   procedure write_list( ListFile, List )
  3893.  
  3894.   local ListElement
  3895.   local write_ListElement
  3896.  
  3897.     write( ListFile, *List )    #How big is it?
  3898.     every ListElement := !List do {
  3899.  
  3900.       write( ListFile, type( ListElement )
  3901.       write_ListElement := "write_" || type( ListElement )
  3902.  
  3903. #
  3904. # This is the important line.  It's a call by string value, calling
  3905. # a procedure to write one entity of the same type as ListElement.
  3906. #
  3907.       write_ListElement( ListFile, ListElement )
  3908.  
  3909.     }
  3910.  
  3911.     return
  3912.  
  3913.   end # write_list
  3914.  
  3915.  
  3916.  
  3917.   procedure read_list( ListFile )
  3918.  
  3919.   local NewList
  3920.   local NewListSize
  3921.   local NewListElement
  3922.   local read_NewListElement
  3923.  
  3924.     NewList := list( NewListSize := integer( read( ListFile ) ) )
  3925.  
  3926.     every NewListElement := 1 to NewListSize do {
  3927.  
  3928.       read_NewListElement := "read_" || read( ListFile )
  3929.  
  3930. #
  3931. # This is the important line.  It's a call by string value, calling
  3932. # a procedure to read one entity of some type as directed by one line
  3933. # of ListFile.
  3934. #
  3935.      NewList[ NewListElement ] := read_NewListElement( ListFile )
  3936.  
  3937.     }
  3938.  
  3939.     return NewList
  3940.  
  3941.   end # read_list
  3942.  
  3943.  
  3944.  
  3945. I've thought of changing (write|read)_<type> to (write|read)_Element,
  3946. as below:
  3947.  
  3948.  
  3949.   procedure write_Element( ElementFile, Element )
  3950.  
  3951.     write( ElementFile, type( Element ) )
  3952.  
  3953.     return ( case type( Element ) of
  3954.  
  3955.       "integer" : write( ElementFile, Element )
  3956.       "real"    : write( ElementFile, Element )
  3957.       "string"  : write( ElementFile, Element )
  3958.       "cset"    : write( ElementFile, Element )
  3959.       "list"    : write_list( ElementFile, Element )
  3960.       "set"     : write_set( ElementFile, Element )
  3961.       "table"   : write_table( ElementFile, Element )
  3962.  
  3963.     end # case
  3964.     )
  3965.  
  3966.   end # write_Element
  3967.  
  3968.  
  3969.  
  3970. and requiring each user to write his or her own procedure
  3971. write_Element but I find this an ugly solution.  Read_Element would be
  3972. a similar case. 
  3973.  
  3974.  
  3975.  
  3976. Your comments?
  3977.  
  3978.  
  3979. Regards,
  3980.  
  3981. David W. Talmage
  3982. Villanova University
  3983. talmage@excalibur.UUCP, sword@vu-vlsi.UUCP, talmage@vuvaxcom.BITNET
  3984.  
  3985. From att!ihuxy!nowlin  Fri Sep 16 06:19:55 1988
  3986. From: att!ihuxy!nowlin
  3987. Message-Id: <8809161319.AA03857@megaron.arizona.edu>
  3988. Received: by megaron.arizona.edu (5.59-1.7/12)
  3989.     id AA03857; Fri, 16 Sep 88 06:19:55 MST
  3990. Received: by att.ATT.COM (smail2.5 - att-ih)
  3991.     id AA25645; 16 Sep 88 07:18:03 CDT (Fri)
  3992. Message-Version: 2
  3993. >To: /addr=att!arizona!icon-group
  3994. Date: Fri 16 Sep 1988 07:19 CDT
  3995. End-Of-Header: 
  3996. Email-Version: 2
  3997. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  3998. To: att!arizona!icon-group
  3999. Subject: Re: reading and writing heterogeneous lists
  4000. Ua-Message-Id: <post.nowlin.Fri 16 Sep 1988 06:54 CDT>
  4001. End-Of-Protocol: 
  4002. Content-Length: 1936
  4003.  
  4004. > While working on other things, I've had the need for a library of
  4005. > procedures that read, write, and pretty print lists, sets, and tables.
  4006. > ...
  4007. > David W. Talmage
  4008. > Villanova University
  4009. > talmage@excalibur.UUCP, sword@vu-vlsi.UUCP, talmage@vuvaxcom.BITNET
  4010.  
  4011. I hope the original mail was received since I didn't include much of it
  4012. here.  I'd have to have a better understanding of why you need this library
  4013. before I could see why you'd bother.  This seems like a lot of work for
  4014. nothing. With the possible exception of strings that contain newlines
  4015. (which you'd have to deal with anyway) why not just write one element per
  4016. line and then read the elements back in inside put() until you hit EOF. 
  4017. The writing code should be obvious.  I'd use something like this, modeled
  4018. after the procedure in the original message, to read:
  4019.  
  4020.   procedure read_list( ListFile )
  4021.   local NewList
  4022.  
  4023.     NewList := []
  4024.     every put(NewList,!ListFile)
  4025.     return NewList
  4026.  
  4027.   end # read_list
  4028.  
  4029. With automatic type conversion, the routines that use the data in NewList
  4030. as specific types should be able to handle converting it from a string. 
  4031. Icon makes handling "heterogeneous" data very simple.  Maybe you should
  4032. state the justification for going to all this work.
  4033.  
  4034. > ...  From a software engineering point of view, it's not
  4035. > such a good thing, I suppose, because it could be difficult to
  4036. > determine from a source listing what exactly is happening...
  4037.  
  4038. The ability to comment your code voids this statement.  You did a good job
  4039. of commenting the expressions that were a little obscure and that's what
  4040. you should do.  There's no excuse for using misdirection and not explaining
  4041. it, but I don't see any reason to avoid the new features of a language just
  4042. because they're tricky to understand.  I like your procedures.  I just
  4043. don't see a need for them.
  4044.  
  4045. I hope this doesn't sound too critical.  I'm cranky this morning.
  4046.  
  4047. Jerry Nowlin
  4048. (...!att!ihuxy!nowlin)
  4049.  
  4050. From icon-group-request  Fri Sep 30 05:26:22 1988
  4051. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4052.     id AA05870; Fri, 30 Sep 88 05:26:22 MST
  4053. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  4054.     id AA00442; Fri, 30 Sep 88 03:22:54 PDT
  4055. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4056.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4057.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4058. Date: 30 Sep 88 07:55:04 GMT
  4059. From: cjeffery@arizona.edu  (Clinton Jeffery)
  4060. Organization: U of Arizona CS Dept, Tucson
  4061. Subject: Sets of sets membership test!
  4062. Message-Id: <7244@megaron.arizona.edu>
  4063. Sender: icon-group-request@arizona.edu
  4064. To: icon-group@arizona.edu
  4065.  
  4066.  
  4067. OK, here's a fun one:  the problem is to test whether a set S1
  4068. (elements are all integers) is "equivalent" to any member of
  4069. set S2 (a set of sets of integers).  Linear search is too slow;
  4070. and I would rather not recode S2 as some sort of binary tree.
  4071. Any good suggestions?  Am I missing a common Icon idiom?
  4072.  
  4073. Any help appreciated!
  4074. Thanks,
  4075. -- 
  4076. | Clint Jeffery, University of Arizona Department of Computer Science
  4077. | cjeffery@arizona.edu -or- {noao allegra cmcl2}!arizona!cjeffery
  4078. --
  4079.  
  4080. From att!ihlpe!orf  Tue Oct  4 05:37:03 1988
  4081. From: att!ihlpe!orf
  4082. Message-Id: <8810041237.AA25375@megaron.arizona.edu>
  4083. Received: by megaron.arizona.edu (5.59-1.7/14)
  4084.     id AA25375; Tue, 4 Oct 88 05:37:03 MST
  4085. Received: by att.ATT.COM (smail2.6 - att-cb)
  4086.     id AA26764; 1 Oct 88 13:13:03 EDT (Sat)
  4087. Message-Version: 2
  4088. >To: /addr=att!arizona!icon-group
  4089. Date: Sat 01 Oct 1988 12:15 CDT
  4090. End-Of-Header: 
  4091. Email-Version: 2
  4092. X-Postmark: ihlpe!orf
  4093. To: att!arizona!icon-group
  4094. Subject: Re: challenge
  4095. Ua-Message-Id: <post.orf.Sat 01 Oct 1988 12:01 CDT>
  4096. End-Of-Protocol: 
  4097. Content-Length: 1130
  4098.  
  4099. > OK, here's a fun one.  The problem is to test whether a set S1 (elements
  4100. > are all integers) is "equivalent" to any member of set S2 (a set of sets of
  4101. > integers).  Linear search is too slow and I would rather not recode S2 as
  4102. > some sort of binary tree.  Any good suggestions?  Am I missing a common
  4103. > Icon idiom?
  4104.  
  4105.  
  4106. I haven't tested this extensively, but I think the following procedure is one
  4107. answer to the icon-group mail. It assumes that s1 is a set, and s2 is a set 
  4108. of sets. (I'm not sure I understand the comment about a "linear search
  4109. being too slow"?  Goal-directed evaluation, left to itself, can be
  4110. combinatorial (I wish I could spell), can't it??  Anyway, the idea is
  4111. if two sets are the same size, and their intersection is the same size, then
  4112. they are identical sets...
  4113.  
  4114. # The procedure suceeds if s1 has the same members as one of s2's sets.
  4115.  
  4116. # Succeed if s1 is a member of s2 member sets
  4117. procedure common(s1,s2)
  4118.    dynamic mset        # member set of s2
  4119.  
  4120.    if *(mset := !s2) = *s1 &
  4121.      *(mset ** s1) = *s1 then return
  4122.    fail
  4123. end
  4124.  
  4125.  
  4126. p.s. you can eliminate the mset variable -- but I didn't like all the
  4127. parenthesis...
  4128.  
  4129. From icon-group-request  Mon Oct 10 01:30:02 1988
  4130. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4131.     id AA22036; Mon, 10 Oct 88 01:30:02 MST
  4132. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  4133.     id AA15623; Mon, 10 Oct 88 00:55:25 PDT
  4134. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4135.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4136.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4137. Date: 4 Oct 88 17:47:38 GMT
  4138. From: grand.UUCP!day@uunet.uu.net  (Dave Yost)
  4139. Organization: Grand Software, Inc., 213-650-1089, Los Angeles, CA
  4140. Subject: Announcing Eiffel language mailing list
  4141. Message-Id: <434@grand.UUCP>
  4142. Sender: icon-group-request@arizona.edu
  4143. To: icon-group@arizona.edu
  4144.  
  4145. Announcing a mailing list for discussion
  4146. of the Eiffel object-oriented language
  4147. and environment.
  4148.  
  4149. To subscribe, please email the following
  4150. form including any comments you wish:
  4151.  
  4152.  ==============================
  4153.  
  4154. To: eiffel-notes-request@grand.COM
  4155. Subject: new subscription
  4156.  
  4157. [ x ] I will indicate my choices like this with an x.
  4158. [   ] Add our address to the mailing list.
  4159.       Domain address: eiffel-notes@hostname.domainlist
  4160.       Uucp address:   uunet!...!hostname!eiffel-notes
  4161.     Initial number of users who will receive eiffel-notes
  4162.     at our site: ___
  4163. [   ] We have an Eiffel compiler.
  4164. [   ] I have read Object-oriented Software Construction by Bertrand Meyers.
  4165. [   ] I would vote for a comp.lang.eiffel newsgroup.
  4166. [   ] I would vote for a comp.lang.oop newsgroup (covering all oo languages).
  4167.  
  4168. From R.J.Hare@EDINBURGH.AC.UK  Wed Oct 12 13:03:52 1988
  4169. Message-Id: <8810122003.AA08119@megaron.arizona.edu>
  4170. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4171.     id AA08119; Wed, 12 Oct 88 13:03:52 MST
  4172. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 12 Oct 88 13:04 MST
  4173. Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 0983; Wed,
  4174.  12 Oct 88 09:10:15 BST
  4175. Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 0982; Wed, 12
  4176.  Oct 88 09:10:15 BS
  4177. Date: 12 Oct 88  09:10:58 bst
  4178. From: R.J.Hare@EDINBURGH.AC.UK
  4179. Subject: Book on ICON (32)
  4180. To: icon-group@arizona.edu
  4181. Reply-To: Willard McCarty <MCCARTY@VM.EPAS.UTORONTO.CA>
  4182. Via:      000015001003.FTP.MAIL; 12 OCT 88  9:10:13 BST
  4183. Comments: This
  4184.  
  4185.  Thanks.
  4186.  
  4187.  Roger Hare.
  4188. Message-ID: <12 Oct 88  09:10:58 bst  340611@EMAS-A>
  4189.  
  4190. --- Forwarded message:
  4191.  
  4192. Subject:  Book on ICON (32)
  4193. From:     Willard McCarty <MCCARTY@CA.UTORONTO.EPAS.VM>
  4194. Date:     Sun, 9 Oct 88 14:47:09 EDT
  4195. Sender:   HUMANIST Discussion <HUMANIST@EARN.UTORONTO>
  4196. Reply to: Willard McCarty <MCCARTY@CA.UTORONTO.EPAS.VM>
  4197. To:       Roger Hare <r.j.hare@UK.AC.EDINBURGH>
  4198. Via:      UK.AC.EARN-RELAY  ; (to uk.ac.edinburgh.emas-a) 10 Oct 88  08:44:58 bs
  4199. Msg ID:   <sent 9 Oct 88 14:47:09 EDT via EARN>
  4200. Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 7087; Mon, 10
  4201.            Oct 88 08:43:51 BS
  4202.           Received: by UKACRL (Mailer X1.25) id 7023; Mon, 10 Oct 88 08:43:49 BS
  4203.  
  4204.  
  4205. Humanist Mailing List, Vol. 2, No. 219.  Sunday, 9 Oct 1988.
  4206.  
  4207. Date:         Sat, 08 Oct 88 09:57:25 CDT
  4208. From:         "Eric Johnson  Liberal Arts  DSC  Madison, SD 57042" <ERIC@SDNET>
  4209. Subject:      Icon language and new book
  4210.  
  4211.    Prentice Hall is about to publish a new book on the Icon Programming
  4212. language: ICON PROGRAMMING FOR HUMANISTS by Alan Corre.  It may be exactly
  4213. the book that Lou and Sebastian seek: programming in Icon for humanists
  4214. who do not have a background in computer science.
  4215.  
  4216.    Icon has received a good deal of attention recently.  Paul Abrahams,
  4217. ACM President, has said
  4218.  
  4219.      I think of Icon as being like a fine small French restaurant that
  4220.      not many people know about, where the clientele is loyal and
  4221.      appreciative, the chef is devoted to producing creative cuisine
  4222.      of the highest quality, and the assistant chefs are themselves
  4223.      talented and devoted to their craft.  Icon is a language where
  4224.      everything fits together, and its design is enhanced by careful
  4225.      attention to small details. . . . (Proceedings of the Third
  4226.      International Conference on Symbolic and Logical Computing, p. 17)
  4227.  
  4228.  
  4229. -- Eric Johnson (ERIC@SDNET)
  4230.  
  4231.  
  4232. --- End of forwarded message
  4233.  
  4234. From R.J.Hare@EDINBURGH.AC.UK  Wed Oct 12 23:26:58 1988
  4235. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4236.     id AA07351; Wed, 12 Oct 88 23:26:58 MST
  4237. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 12 Oct 88 23:28 MST
  4238. Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 0285; Thu,
  4239.  13 Oct 88 06:59:23 BST
  4240. Date: 13 Oct 88  07:00:08 bst
  4241. From: R.J.Hare@EDINBURGH.AC.UK
  4242. Subject: Icon Book
  4243. To: icon-group@arizona.edu
  4244. Via:        000015001003.FTP.MAIL; 13 OCT 88  6:59:21 BST
  4245. Message-Id: <13 Oct 88  07:00:08 bst  340690@EMAS-A>
  4246.  
  4247. The comment I prepended to the HUMANIST message relating to the book about
  4248. Icon appears to have been garbled, so for the benefit of anyone who is
  4249. wondering what it is all about, this message appeared on the HUMANIST
  4250. bulletin board a few days ago and may be of interest to readers of the
  4251. Icon bulletin board.
  4252.  
  4253. Roger Hare.
  4254.  
  4255. From icon-group-request  Fri Oct 14 07:08:07 1988
  4256. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4257.     id AA05035; Fri, 14 Oct 88 07:08:07 MST
  4258. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  4259.     id AA15070; Fri, 14 Oct 88 06:34:11 PDT
  4260. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4261.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4262.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4263. Date: 10 Oct 88 22:31:24 GMT
  4264. From: grand!day@uunet.uu.net  (Dave Yost)
  4265. Organization: Grand Software, Inc., 213-650-1089, Los Angeles, CA
  4266. Subject: Announcing Eiffel language mailing list
  4267. Message-Id: <440@grand.UUCP>
  4268. Sender: icon-group-request@arizona.edu
  4269. To: icon-group@arizona.edu
  4270.  
  4271.  
  4272. Announcing a mailing list for discussion
  4273. of the Eiffel object-oriented language
  4274. and environment.
  4275.  
  4276. In case you haven't heard of Eiffel, it is a strongly-typed,
  4277. Object-oriented general purpose programming language with
  4278. emphasis on compile-time checking.  It has generic types
  4279. (often caled parameterized types), multiple inheritance,
  4280. incrementally-garbage-collected automatic storage, and
  4281. exception handling.  Eiffel is a recent design, not an
  4282. extension of any previous language.  It is described in
  4283. this book:
  4284.     Object-oriented Software Construction
  4285.     by Bertrand Meyer
  4286.     Prentice Hall, 1988
  4287.     International Series in Computer Science
  4288.     ISBN 0-13-629049-3 hardcover
  4289.     ISBN 0-13-629031-0 paperback (apparently
  4290.     won't be available in the US)
  4291.  
  4292. To subscribe, please email the following
  4293. form including any comments you wish.
  4294.  
  4295. Special Instructions:
  4296.  
  4297. If you can, please set up an eiffel-notes alias
  4298. on your system so we can add that to our list
  4299. instead of adding individual user names.
  4300.  
  4301.  ==============================
  4302.  
  4303. To: eiffel-notes-request@grand.COM
  4304. Subject: new subscription
  4305.  
  4306. [ x ] I will indicate my choices like this with an x.
  4307. [   ] Add our address to the mailing list.
  4308.     [edit one or both of the following to reflect your address]
  4309.       Domain address: eiffel-notes@hostname.domainlist
  4310.       Uucp address:   uunet!...!hostname!eiffel-notes
  4311.     Initial number of users who will receive eiffel-notes
  4312.     at our site: ___
  4313. [   ] We have an Eiffel compiler.
  4314. [   ] I have read Object-oriented Software Construction by Bertrand Meyer.
  4315. [   ] I would vote for a comp.lang.eiffel newsgroup.
  4316. [   ] I would vote for a comp.lang.oop newsgroup (covering all oo languages).
  4317.  
  4318. From icon-group-request  Sat Oct 15 10:00:54 1988
  4319. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4320.     id AA01816; Sat, 15 Oct 88 10:00:54 MST
  4321. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  4322.     id AA21405; Tue, 11 Oct 88 21:30:11 PDT
  4323. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4324.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4325.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4326. Date: 11 Oct 88 15:55:43 GMT
  4327. From: mcvax!hp4nl!mhres!jv@uunet.uu.net  (Johan Vromans)
  4328. Organization: Multihouse NV, the Netherlands
  4329. Subject: Icon for HP9000/320
  4330. Message-Id: <2481@mhres.mh.nl>
  4331. Sender: icon-group-request@arizona.edu
  4332. To: icon-group@arizona.edu
  4333.  
  4334. I am looking for the configuration files for Icon
  4335. version 6 on HP9000/320 running HP-UX. I have it running already,
  4336. but I am not sure my home-brew configuration files are optimal.
  4337. Also, I'm looking for the HP9000/320 version of rswitch.s and
  4338. rover.s.
  4339.  
  4340. Thanks in advance.
  4341.  
  4342.     Johan Vromans @ Multihouse
  4343.  
  4344.  
  4345. -- 
  4346.     Johan
  4347.  
  4348. From LIBCAT@IUBACS.BITNET  Wed Oct 19 00:18:33 1988
  4349. Message-Id: <8810190718.AA16570@megaron.arizona.edu>
  4350. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4351.     id AA16570; Wed, 19 Oct 88 00:18:33 MST
  4352. Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Wed, 19 Oct 88 00:16 MST
  4353. Date: Wed, 19 Oct 88 00:36 EST
  4354. From: LIBCAT@IUBACS.BITNET
  4355. Subject: today, tomorrow, and yesterday
  4356. To: icon-group@arizona.edu
  4357. X-Original-To:  icon-group@arizona.edu, LIBCAT
  4358.  
  4359.       This is very minor problem but any help would be greatly
  4360. appreciated.   We are using ICON as the user interface for a small
  4361. in-house BBS.  The function (&dateline) is being used for the log,
  4362. etc.  The problem is that it consistently reports today as yesterday.
  4363.       When DOS reports that: Current date is Tue 10-18-1988, the
  4364. program below:
  4365.  
  4366.       procedure main ()
  4367.           write (&date)
  4368.           write (&dateline)
  4369.           write (&version)
  4370.           write (&host)
  4371.       end
  4372.  
  4373. yields:
  4374.  
  4375.       1988/10/17
  4376.       Monday, October 17, 1988  1:24 am
  4377.       Icon Version 7.0.  January 16, 1988.
  4378.       MS-DOS (ER) ex Lattice C Version 3.2
  4379.  
  4380.       At first I thought this might just be a quirk in the IBM Model
  4381. 30 we are using for the BBS, but my Taiwan clone at home reports the
  4382. same thing.  I set the clock ahead so that the BBS has the correct
  4383. date, but now the rest of the software thinks it's tomorrow.
  4384.  
  4385. ----------------------------------------------------------------------
  4386. Jon LaCure                    Arpanet : libcat@gold.iubacs.indiana.edu
  4387. Indiana University Library    Bitnet  : libcat@iubacs
  4388. Bloomington, IN  47401        Voice   : (812) 335-7511
  4389. ----------------------------------------------------------------------
  4390.  
  4391.  
  4392.  
  4393. From ralph  Wed Oct 19 04:43:45 1988
  4394. Date: Wed, 19 Oct 88 04:43:45 MST
  4395. From: "Ralph Griswold" <ralph>
  4396. Message-Id: <8810191143.AA25099@megaron.arizona.edu>
  4397. Received: by megaron.arizona.edu (5.59-1.7/14)
  4398.     id AA25099; Wed, 19 Oct 88 04:43:45 MST
  4399. To: LIBCAT@IUBACS.BITNET
  4400. Subject: Re:  today, tomorrow, and yesterday
  4401. Cc: icon-group
  4402. In-Reply-To: <8810190718.AA16570@megaron.arizona.edu>
  4403.  
  4404. The date problem is in the run-time library for MS-DOS Lattice C, which was
  4405. used to compile the version of Icon you're running. (Leap year caused the
  4406. trouble.)
  4407.  
  4408. If you can use the FR (rather than ER) version of Icon compiled under
  4409. Microsoft C that comes on the same Version 7.0 distribution, your problem
  4410. will go away.
  4411.  
  4412. Alternatively, you can get the recently released Version 7.5 of Icon
  4413. for MS-DOS from us, which uses a later version of the Lattice C compiler
  4414. with the problem fixed.  Ordering information is the same as for the
  4415. 7.0 version. (Send e-mail to icon-project@arizona.edu if you need
  4416. more information.)
  4417.  
  4418.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  4419.    +1 602 621 6609   ralph@Arizona.EDU  {uunet|allegra|noao|uunet}!arizona!ralph
  4420.  
  4421.  
  4422. From icon-group-request  Wed Oct 26 06:40:08 1988
  4423. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4424.     id AA28137; Wed, 26 Oct 88 06:40:08 MST
  4425. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  4426.     id AA20617; Wed, 26 Oct 88 00:10:54 PDT
  4427. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4428.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4429.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4430. Date: 26 Oct 88 05:52:34 GMT
  4431. From: chiba!khb@sun.com  (Keith Bierman - Sun Tactical Engineering)
  4432. Subject: ----------------------------- call for votes --------------
  4433. Message-Id: <74718@sun.uucp>
  4434. Sender: icon-group-request@arizona.edu
  4435. To: icon-group@arizona.edu
  4436.  
  4437.  
  4438.  
  4439.  
  4440. ----------------------------------------------------------------------------
  4441. ****************************************************************************
  4442.                 CALL FOR VOTES
  4443. ----------------------------------------------------------------------------
  4444. ****************************************************************************
  4445.  
  4446. Comp.lang.sigplan --- a moderated newsgroup sponsored by the ACM.
  4447. SIGPLAN is the ACM's special interest group on computer languages. The
  4448. forum will focus on issues which are of "general" interest.
  4449.  
  4450. This is merely a pointer. The "real" call for votes is located in News.groups.
  4451.  
  4452. Those who wish to vote yes can skip reading news.groups and simply
  4453. send mail to sigplan@iuvax.cs.indiana.edu. The SUBJECT should be YES.
  4454.  
  4455. Those not in favor should read the real call for votes before casting
  4456. a vote.
  4457.  
  4458. Thanks for your support.
  4459.  
  4460.  
  4461.  
  4462. Keith H. Bierman
  4463. It's Not My Fault ---- I Voted for Bill & Opus
  4464.  
  4465. From dscargo%ccsvax.decnet@cim-vax.honeywell.com  Thu Oct 27 07:02:27 1988
  4466. Message-Id: <8810271402.AA16740@megaron.arizona.edu>
  4467. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4468.     id AA16740; Thu, 27 Oct 88 07:02:27 MST
  4469. Date: 27 Oct 88 08:48:00 CDT
  4470. From: "CCSVAX::DSCARGO" <dscargo%ccsvax.decnet@cim-vax.honeywell.com>
  4471. Subject: Icon 7.5
  4472. To: "icon-group" <icon-group@arizona.edu>
  4473.  
  4474. Mention has been made of Icon 7.5, but not of what differentiates it from
  4475. Icon version 7.  Could the developers elaborate on that difference,
  4476. please?
  4477.  
  4478. DSCARGO@CIM-VAX.HONEYWELL.COM
  4479.  
  4480.  
  4481. From James.Price.Salsman@cat.cmu.edu  Sat Oct 29 12:35:23 1988
  4482. Received: from CAT.CMU.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4483.     id AA25689; Sat, 29 Oct 88 12:35:23 MST
  4484. Received: from CAT.CMU.EDU by CAT.CMU.EDU; 29 Oct 88 15:33:21 EDT
  4485. To: icon-group@arizona.edu
  4486. Subject: I cant generate your docs...
  4487. Date: Sat, 29 Oct 88 15:33:15 EDT
  4488. Message-Id: <2371.594156795@CAT.CMU.EDU>
  4489. From: James Salsman <James.Price.Salsman@CAT.CMU.EDU>
  4490.  
  4491. Dear Project,
  4492.  
  4493. I am having some trouble generating some of your tech reports...
  4494.  
  4495. TR 83-3f:  There is a graph at the bottom of page 9 that my version
  4496.            of psroff won't print.
  4497.  
  4498. TR 86-13:  uses the "bmac" package which we don't have.
  4499.  
  4500. TR 88-8:   also uses "bmac."
  4501.  
  4502. Could you either mail me the (Apple LaserWriter) PostScript for these
  4503. reports, or possibly leave the PostScript in an ftp directory on
  4504. ARIZONA.EDU ?  If you mail the p.s., please check to see that there
  4505. are no high-bit-set charectors, as our mail reciever will strip
  4506. them.
  4507.  
  4508. Thanks for your help.
  4509.  
  4510. :James
  4511.  
  4512. From ralph  Sat Oct 29 13:11:12 1988
  4513. Date: Sat, 29 Oct 88 13:11:12 MST
  4514. From: "Ralph Griswold" <ralph>
  4515. Message-Id: <8810292011.AA27351@megaron.arizona.edu>
  4516. Received: by megaron.arizona.edu (5.59-1.7/14)
  4517.     id AA27351; Sat, 29 Oct 88 13:11:12 MST
  4518. To: James.Price.Salsman@CAT.CMU.EDU, icon-group@arizona.edu
  4519. Subject: Re:  I cant generate your docs...
  4520. In-Reply-To: <2371.594156795@CAT.CMU.EDU>
  4521.  
  4522. I'll see about generating PostScript and levaing it in our FTP
  4523. area.
  4524.  
  4525. We're adding other things there as well, and now's a good time.
  4526. i'll let you know when it's done.
  4527.  
  4528.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  4529.    +1 602 621 6609   ralph@Arizona.EDU  {uunet|allegra|noao|uunet}!arizona!ralph
  4530.  
  4531.  
  4532. From sboisen@REGULUS.BBN.COM  Tue Nov  1 13:56:18 1988
  4533. Message-Id: <8811012056.AA23649@megaron.arizona.edu>
  4534. Received: from REGULUS.BBN.COM by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4535.     id AA23649; Tue, 1 Nov 88 13:56:18 MST
  4536. To: icon-group@arizona.edu
  4537. Subject: anybody have a regexp matcher for Icon?
  4538. From: Sean Boisen <sboisen@REGULUS.BBN.COM>
  4539. Sender: sboisen@REGULUS.BBN.COM
  4540. Reply-To: sboisen@bbn.com
  4541. Date: Tue, 1 Nov 88 15:48:37 EST
  4542.  
  4543. All:
  4544.     I often find myself looking for the following sort of
  4545. tool: let's say i have textual data in multi-line blocks, and if a
  4546. certain string occurs somewhere in that block, i want to output the
  4547. block. This arises frequently enough that i _really_ wish i had some
  4548. way of looking for a regular expression in the block: sort of a block-
  4549. (rather than line-)oriented grep, so that i don't have to hack up a
  4550. new little program each time i want to look for a new string. Has
  4551. anybody else out there ever wanted such a thing (and, even better,
  4552. written it?). I guess what i'd really like is some procedure which,
  4553. given a string and a regular expression, can tell me if the regexp is
  4554. matched anywhere in the string (regexp_find(s1,s2) ?). This looks like
  4555. enough of an undertaking that i'm not going to try it until i've
  4556. shopped around a little....
  4557.  
  4558. ........................................
  4559. Sean Boisen -- sboisen@bbn.com
  4560. BBN Systems and Technologies Corporation, Cambridge MA
  4561. Disclaimer: these opinions void where prohibited by lawyers.
  4562.  
  4563. From gmt  Wed Nov  2 09:31:29 1988
  4564. Date: Wed, 2 Nov 88 09:31:29 MST
  4565. From: "Gregg Townsend" <gmt>
  4566. Message-Id: <8811021631.AA17309@megaron.arizona.edu>
  4567. Received: by megaron.arizona.edu (5.59-1.7/14)
  4568.     id AA17309; Wed, 2 Nov 88 09:31:29 MST
  4569. In-Reply-To: <8811012056.AA23649@megaron.arizona.edu>
  4570. To: sboisen@bbn.com
  4571. Subject: Re:  anybody have a regexp matcher for Icon?
  4572. Cc: icon-group
  4573.  
  4574.     ...i _really_ wish i had some
  4575.     way of looking for a regular expression in the block: sort of a block-
  4576.     (rather than line-)oriented grep...
  4577.  
  4578. It's not Icon, but the latest version of the Unix utility "awk" has some
  4579. facilities for handling multiline records.  These are described in "The AWK
  4580. Programming Language" (by Aho, Kernighan, & Weinberger, Addison-Wesley, 1988).
  4581. New Awk is available for some number of bucks from the AT&T Toolchest;  for
  4582. more info call (201)522-6900 with a 1200 baud modem and login as "guest" with
  4583. no password.
  4584.  
  4585.    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  4586.    +1 602 621 4325      gmt@Arizona.EDU       110 57 16 W / 32 13 45 N / +758m
  4587.  
  4588. From alk@ux.acss.umn.edu  Wed Nov  2 12:41:02 1988
  4589. Message-Id: <8811021941.AA29504@megaron.arizona.edu>
  4590. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4591.     id AA29504; Wed, 2 Nov 88 12:41:02 MST
  4592. Return-Path: alk@ux.acss.umn.edu
  4593. Received: from UMNACVX.BITNET by rvax.ccit.arizona.edu; Wed, 2 Nov 88 12:22 MST
  4594. Received: from ux.acss.umn.edu by UMNACVX.BITNET; Wed, 2 Nov 88 13:06 CST
  4595. Date: Wed, 2 Nov 88 13:05:11 CST
  4596. From: alk@ux.acss.umn.edu
  4597. Subject: Re:  anybody have a regexp matcher for Icon?
  4598. Sender: alk@ux.acss.umn.edu
  4599. To: gmt@arizona.edu, sboisen@bbn.com
  4600. Cc: icon-group@arizona.edu
  4601.  
  4602. If you're goning to resort to awk, why not get GNU awk (FREE and fast) from the
  4603.    GNU pro
  4604. the GNU project.  It's probably availiable for anonymous ftp from p
  4605. prep.ai.mit.edu.
  4606.  
  4607. if not, it's also on the most recent (i think) DECUS tapes, or could be
  4608. ordered from the GNU project on tape for a copying fee.
  4609. Or I could put it up here on request, I s'poze.
  4610.  
  4611. From att!ihuxy!nowlin  Thu Nov  3 04:48:57 1988
  4612. From: att!ihuxy!nowlin
  4613. Message-Id: <8811031148.AA04485@megaron.arizona.edu>
  4614. Received: by megaron.arizona.edu (5.59-1.7/14)
  4615.     id AA04485; Thu, 3 Nov 88 04:48:57 MST
  4616. Received: by att.ATT.COM (smail2.6 - att-ih)
  4617.     id AA07608; 2 Nov 88 16:51:39 CST (Wed)
  4618. Message-Version: 2
  4619. >To: /addr=att!arizona!icon-group
  4620. Date: Wed 02 Nov 1988 16:53 CST
  4621. End-Of-Header: 
  4622. Email-Version: 2
  4623. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  4624. To: att!arizona!icon-group
  4625. Subject: Re: an Icon regexp matcher
  4626. Ua-Message-Id: <post.nowlin.Wed 02 Nov 1988 16:41 CST>
  4627. End-Of-Protocol: 
  4628. Content-Length: 889
  4629.  
  4630. > From: Sean Boisen <sboisen@REGULUS.BBN.COM>
  4631. > Date: Tue, 1 Nov 88 15:48:37 EST
  4632. >     I often find myself looking for the following sort of
  4633. > tool: ...
  4634. > ... I guess what i'd really like is some procedure which,
  4635. > given a string and a regular expression, can tell me if the regexp is
  4636. > matched anywhere in the string (regexp_find(s1,s2) ?). ...
  4637.  
  4638. I have a version of grep written in Icon.  I haven't bothered to look it
  4639. over much in the last two years since it was written but it still works
  4640. just like the UNIX grep for the set of tests I ran it through.  I'm sure
  4641. there are bugs in it since the test suite is fairly simple in scope but
  4642. they're probably obscure.  This program isn't in the format of the
  4643. procedure mentioned above but could be modified without to much trouble. 
  4644. If anyone wants it email me.  If there are enough requests I'll post it.
  4645.  
  4646. Jerry Nowlin
  4647. (...!att!ihuxy!nowlin)
  4648.  
  4649. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Thu Nov  3 19:07:46 1988
  4650. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4651.     id AA18800; Thu, 3 Nov 88 19:07:46 MST
  4652. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  4653.     id AA01660; Wed, 2 Nov 88 17:28:05 CST
  4654. Return-Path: <goer@sophist.uchicago.edu>
  4655. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  4656.     id AA01195; Wed, 2 Nov 88 17:18:21 CST
  4657. Date: Wed, 2 Nov 88 17:18:21 CST
  4658. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  4659. Message-Id: <8811022318.AA01195@sophist.uchicago.edu>
  4660. To: icon-group@arizona.edu
  4661. Subject: icon-grep
  4662.  
  4663. I think the fellow who posted might have wanted a real Icon-grep.
  4664. I've implemented an icon-grep using control backtracking, and 
  4665. utilizing coexpressions to create matching procedures at run-
  4666. time.  It's slow, and I dare not post it for that reason.  If
  4667. someone has implemented a more elegant version of an icon-grep,
  4668. I wonder if he or she might post it.
  4669.  
  4670.                                         -Richard L. Goerwitz
  4671.                                         goer@sophist.uchicago.edu
  4672.                                         rutgers!oddjob!gide!sophist!goer
  4673.  
  4674. From alk@ux.acss.umn.edu  Fri Nov  4 19:53:59 1988
  4675. Message-Id: <8811050253.AA08563@megaron.arizona.edu>
  4676. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4677.     id AA08563; Fri, 4 Nov 88 19:53:59 MST
  4678. Return-Path: alk@ux.acss.umn.edu
  4679. Received: from UMNACVX.BITNET by rvax.ccit.arizona.edu; Wed, 2 Nov 88 15:56 MST
  4680. Received: from ux.acss.umn.edu by UMNACVX.BITNET; Wed, 2 Nov 88 16:49 CST
  4681. Date: Wed, 2 Nov 88 16:52:26 CST
  4682. From: alk@ux.acss.umn.edu
  4683. Subject: Re:  anybody have a regexp matcher for Icon?
  4684. Sender: alk@ux.acss.umn.edu
  4685. To: alk@ux.acss.umn.edu, gmt@arizona.edu, sboisen@bbn.com
  4686. Cc: icon-group@arizona.edu
  4687.  
  4688. or better yet, get gawk from simtel20.arpa: pd2:<UNIX-C.GNU>GAWK.TAR-Z
  4689. thats the ticket
  4690.  
  4691. From ralph  Sun Nov  6 07:42:00 1988
  4692. Date: Sun, 6 Nov 88 07:42:00 MST
  4693. From: "Ralph Griswold" <ralph>
  4694. Message-Id: <8811061442.AA14202@megaron.arizona.edu>
  4695. Received: by megaron.arizona.edu (5.59-1.7/14)
  4696.     id AA14202; Sun, 6 Nov 88 07:42:00 MST
  4697. To: icon-group
  4698. Subject: Sequent Symmetry
  4699.  
  4700. Does anyone have Version 7 of Icon running on a Sequent Symmetry?
  4701.  
  4702. If so, we'd like to get a copy of the configuration files for a
  4703. potential user.
  4704.  
  4705. Thanks.
  4706.  
  4707.  
  4708.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  4709.    +1 602 621 6609   ralph@Arizona.EDU  {uunet|allegra|noao|uunet}!arizona!ralph
  4710.  
  4711.  
  4712. From icon-group-request  Sun Nov  6 11:05:07 1988
  4713. Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
  4714.     id AA18978; Sun, 6 Nov 88 11:05:07 MST
  4715. Received: by ucbvax.Berkeley.EDU (5.59/1.31)
  4716.     id AA03676; Sun, 6 Nov 88 07:27:56 PST
  4717. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4718.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4719.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4720. Date: 5 Nov 88 23:26:50 GMT
  4721. From: grand!day@uunet.uu.net  (Dave Yost)
  4722. Organization: Grand Software, Inc., Los Angels, CA 213-650-1089
  4723. Subject: Re: anybody have a regexp matcher for Icon?
  4724. Message-Id: <445@grand.UUCP>
  4725. References: <8811012056.AA23649@megaron.arizona.edu>
  4726. Sender: icon-group-request@arizona.edu
  4727. To: icon-group@arizona.edu
  4728.  
  4729. In article <8811012056.AA23649@megaron.arizona.edu> sboisen@bbn.com writes:
  4730. >All:
  4731. >       I often find myself looking for the following sort of tool:
  4732. >...
  4733. >given a string and a regular expression, can tell me if the regexp is
  4734. >matched anywhere in the string (regexp_find(s1,s2) ?).
  4735.  
  4736. I too would like to see a built-in (and therefore reasonably fast)
  4737. function such as you suggest.
  4738. There are 2 or 3 freely-avaliable C regex matching routines
  4739. available.  I wish someone would glue one of them into Icon.
  4740. Perhaps you could get someone who knows the ropes to build you
  4741. a stub/prototype inside Icon, and then you could go about making
  4742. it really work, with the Implementation of Icon book at your side.
  4743.  
  4744.  --dave yost
  4745.  
  4746. From att!ihuxy!nowlin  Sun Nov  6 14:55:41 1988
  4747. From: att!ihuxy!nowlin
  4748. Message-Id: <8811062155.AA25172@megaron.arizona.edu>
  4749. Received: by megaron.arizona.edu (5.59-1.7/14)
  4750.     id AA25172; Sun, 6 Nov 88 14:55:41 MST
  4751. Received: by att.ATT.COM (smail2.6 - att-ih)
  4752.     id AA28287; 6 Nov 88 15:50:20 CST (Sun)
  4753. Message-Version: 2
  4754. >To: /addr=att!arizona!icon-group
  4755. Date: Sun 06 Nov 1988 15:53 CST
  4756. End-Of-Header: 
  4757. Email-Version: 2
  4758. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  4759. To: att!arizona!icon-group
  4760. Subject: Icon Grep (igrep)
  4761. Ua-Message-Id: <post.nowlin.Sun 06 Nov 1988 15:50 CST>
  4762. End-Of-Protocol: 
  4763. Content-Length: 8638
  4764.  
  4765. I received quite a few requests for the Icon grep I had and since I
  4766. haven't been able to return mail to several of them I'll just post the
  4767. program here.  If you test it and find any problems try to let me know
  4768. so I can fix them.  Thanks.
  4769.  
  4770. Jerry Nowlin
  4771. (...!att!ihuxy!nowlin)
  4772.  
  4773. # This program simulates the UNIX grep command.  It recognizes the following
  4774. # special (magic) characters:
  4775. #
  4776. #     ^   -  matches if the following pattern is at the beginning of a line
  4777. #     $   -  matches if the preceding pattern is at the end of a line
  4778. #     .   -  matches any single character
  4779. #     +   -  matches from 1 to any number of occurrences of the previous
  4780. #            character
  4781. #     *   -  matches from 0 to any number of occurrences of the previous
  4782. #            character
  4783. #     \   -  escapes the special meaning of any special characters
  4784. #            recognized by this program
  4785. #
  4786. # A pair of square brackets containing other characters means that any of the
  4787. # enclosed characters should be matched.  A range of characters like '[a-z]'
  4788. # will match any of the ASCII characters between 'a' and 'z'.  If the initial
  4789. # character inside the square brackets is a '^' then the sequence matches
  4790. # any characters except the ones enclosed in the square brackets.
  4791. #
  4792. # The pattern given is broken up into parts that can be matched independent
  4793. # of each other.  Then the initial list of partial patterns is optimized.
  4794. # each partial pattern has a procedure associated with it that will be used
  4795. # in the matching phase of the program to match the pattern.
  4796. #
  4797. # While parsing the pattern there is the concept of a next string matching
  4798. # procedure and a next character matching procedure.  These change from one
  4799. # partial pattern to the next depending on the content of the previous
  4800. # and the current partial pattern.
  4801.  
  4802. # pattern records contain a procedure and a pattern
  4803. record    patrec(proc,arg)
  4804.  
  4805. procedure main(args)
  4806.  
  4807.     # the usage message
  4808.     usage := "Usage: igrep pattern [ file ... ]"
  4809.  
  4810.     # the special and non-special characters
  4811.     magic := '^$.+*[\\'
  4812.     mundane := ~magic
  4813.  
  4814.     # a string of all ASCII characters
  4815.     astr := string(&ascii)
  4816.  
  4817.     # the first program argument must be the pattern
  4818.     pattern := get(args) | stop("I at least need a pattern\n",usage)
  4819.  
  4820.     # initialize the initial pattern list
  4821.     initpat := []
  4822.  
  4823.     # initialize the next string procedure and the next cset procedure
  4824.     nexts := paststring
  4825.     nextc := pastcset
  4826.  
  4827.     # parse each character in the pattern one at a time
  4828.     # (slow but easier for '+' and '*')
  4829.     pattern ? while ch := move(1) do case ch of {
  4830.  
  4831.         # the beginning of line character
  4832.         "^": {
  4833.  
  4834.             # if this is the first character of the pattern
  4835.             # it's special
  4836.             if pos(2) then {
  4837.                 nexts := match
  4838.                 nextc := any
  4839.  
  4840.                 # if plus or star are the second characters
  4841.                 # and carat is the first then just match them
  4842.                 if ch := move(1) == ("+" | "*")  then
  4843.                     put(initpat,patrec(nexts,ch))
  4844.  
  4845.             # if carat isn't the first character just match it
  4846.             } else {
  4847.                 put(initpat,patrec(nexts,"^"))
  4848.             }
  4849.         }
  4850.  
  4851.         # the end of line character
  4852.         "$": {
  4853.  
  4854.             # if this is the last character of the pattern
  4855.             # it's special
  4856.             if pos(0) then {
  4857.                 put(initpat,patrec(pos,0))
  4858.  
  4859.             # if dollar isn't the last character just match it
  4860.             } else {
  4861.                 put(initpat,patrec(nexts,"$"))
  4862.             }
  4863.         }
  4864.  
  4865.         # the match any character character
  4866.         ".": {
  4867.             put(initpat,patrec(nextc,&ascii))
  4868.             nexts := match
  4869.             nextc := any
  4870.         }
  4871.  
  4872.         # the 1 to any number of previous characters character
  4873.         "+": {
  4874.             # if this is the first character of the pattern
  4875.             # it's not special so just match it
  4876.             if pos(2) then {
  4877.                 put(initpat,patrec(nexts,"+"))
  4878.  
  4879.             # otherwise it's special
  4880.             } else {
  4881.                 initpat[-1].proc := plus
  4882.                 nexts := match
  4883.                 nextc := any
  4884.             }
  4885.         }
  4886.  
  4887.         # the 0 to any number of previous characters character
  4888.         "*": {
  4889.             # if this is the first character of the pattern
  4890.             # it's not special so just match it
  4891.             if pos(2) then {
  4892.                 put(initpat,patrec(nexts,"*"))
  4893.  
  4894.             # otherwise it's special
  4895.             } else {
  4896.                 initpat[-1].proc := star
  4897.                 nexts := match
  4898.                 nextc := any
  4899.             }
  4900.         }
  4901.  
  4902.         # the escape other characters character
  4903.         "\\": {
  4904.  
  4905.             # if the next character is a special character
  4906.             # match it and skip the backslash
  4907.             if any(magic,&subject[&pos]) then {
  4908.                 put(initpat,patrec(nexts,move(1)))
  4909.  
  4910.             # if the next character isn't special match backslash
  4911.             } else {
  4912.                 put(initpat,patrec(nexts,"\\"))
  4913.             }
  4914.         }
  4915.  
  4916.         # the match enclosed characters character
  4917.         "[": {
  4918.             inside := ''
  4919.             lastc := "["
  4920.             ch := move(1)
  4921.  
  4922.             # if supposed to match everything but the inside cset
  4923.             if ch == "^" then {
  4924.                 notin := 1
  4925.                 ch := move(1)
  4926.  
  4927.             # if supposed to match the inside cset
  4928.             } else    notin := 0
  4929.  
  4930.             # parse the inside cset characters
  4931.             repeat {
  4932.                 case ch of {
  4933.                     # we're done
  4934.                     "]": break;
  4935.  
  4936.                     # we're in a range
  4937.                     "-": {
  4938.  
  4939.                         # if the dash is at the end
  4940.                         # or beginning of the inside
  4941.                         # cset just match a dash
  4942.                         if (lastc == "[") |
  4943.                            (&subject[&pos] == "]")
  4944.                         then {
  4945.                             lastc := "-"
  4946.                             inside ++:= cset(lastc)
  4947.  
  4948.                         # otherwise match the range
  4949.                         # of ascii characters between
  4950.                         # the last and next characters
  4951.                         # (indent violated here)
  4952.                         } else
  4953.     inside ++:= cset(astr[upto(lastc,astr)+1:upto(lastc := move(1),astr)+1])
  4954.                     }
  4955.  
  4956.                     # just take the next character
  4957.                     "\\": {
  4958.                         lastc := move(1)
  4959.                         inside ++:= cset(lastc)
  4960.                     }
  4961.  
  4962.                     default: {
  4963.                         lastc := ch
  4964.                         inside ++:= cset(lastc)
  4965.                     }
  4966.                 }
  4967.  
  4968.                 # break if we ran out of characters
  4969.                 if not (ch := move(1)) then break;
  4970.             }
  4971.  
  4972.             # check for mismatched brackets
  4973.             if pos(0) & ch ~== "]" then
  4974.                 stop("Mismatched brackets '",pattern,"'")
  4975.  
  4976.             # if the first character was a '^' complement
  4977.             # the inside cset
  4978.             if notin = 1 then inside := ~inside ** &ascii
  4979.  
  4980.             put(initpat,patrec(nextc,inside))
  4981.         }
  4982.  
  4983.         # mundane characters are just added to the pattern
  4984.         default: {
  4985.             put(initpat,patrec(nexts,ch))
  4986.             nexts := match
  4987.             nextc := any
  4988.         }
  4989.  
  4990.     } # bottom of parse the pattern
  4991.  
  4992.     # initialize the flag for being in a literal string
  4993.     instring := 0
  4994.  
  4995.     # initialize the final pattern list
  4996.     finalpat := []
  4997.  
  4998.     # go through the initial patterns and optimize them by making
  4999.     # consecutive literal strings into single literal strings
  5000.     every pat := !initpat do {
  5001.  
  5002.         # if this pattern is a literal string
  5003.         if type(pat.arg) == "string" &
  5004.            pat.proc === (match | paststring) then {
  5005.  
  5006.             # if the last pattern was a literal string add this
  5007.             # pattern to it
  5008.             if instring = 1 then {
  5009.                 finalpat[-1].arg ||:= pat.arg
  5010.  
  5011.             # if the last wasn't a literal string start a literal
  5012.             # string with this pattern
  5013.             } else {
  5014.                 put(finalpat,pat)
  5015.                 instring := 1
  5016.             }
  5017.  
  5018.         # if this pattern is a special pattern add it as is
  5019.         } else {
  5020.             put(finalpat,pat)
  5021.             instring := 0
  5022.         }
  5023.  
  5024.     }
  5025.  
  5026.     # if trace is on print the final pattern records for debugging
  5027.     if &trace ~= 0 then
  5028.         every m := !finalpat do write(image(m.proc),": ",image(m.arg))
  5029.  
  5030.     # trick the program into using standard input if no files were passed
  5031.     if *args = 0 then args := [&null]
  5032.  
  5033.     # the rest of the command arguments are files to search for the pattern
  5034.     every file := !args do {
  5035.         if \file then in := open(file) | stop("I can't open '",file,"'")
  5036.         else in := &input
  5037.  
  5038.         if *args = 1 then file := "" else file ||:= ":"
  5039.  
  5040.         while line := !in do {
  5041.  
  5042.             # scan the line for the pattern
  5043.             line ? {
  5044.  
  5045.                 # if the pattern is found print the line
  5046.                 if found := rematch(finalpat,1) then
  5047.                     write(file,line)
  5048.             }
  5049.         }
  5050.  
  5051.         close(in)
  5052.     }
  5053. end
  5054.  
  5055. # pats is the list of procedures and partial patterns to match and pind is
  5056. # the index in the list to start matching on
  5057. procedure rematch(pats,pind)
  5058.  
  5059.     # if pind is beyond the end of pats suspend with an empty string
  5060.     if pind > *pats then suspend ""
  5061.  
  5062.     # otherwise suspend with the current procedure invoked on the current
  5063.     # pattern concatenated with the rematch of the next procedure and
  5064.     # pattern pair (recursive)
  5065.     else suspend tab(pats[pind].proc(pats[pind].arg)) ||
  5066.             rematch(pats,pind+1)
  5067.  
  5068. end
  5069.  
  5070. # match partial patterns generated by the '+' special character
  5071. procedure plus(c)
  5072.  
  5073.     # the loop is so that the longest possible pattern will be matched
  5074.     suspend (many(c) to &pos+1 by -1)
  5075.  
  5076. end
  5077.  
  5078. # match partial patterns generated by the '*' special character
  5079. procedure star(c)
  5080.  
  5081.     # the loop is so that the longest possible pattern will be matched
  5082.     suspend (many(c) to &pos+1 by -1) | &pos
  5083.  
  5084. end
  5085.  
  5086. # match the shortest possible string up to and including the cset passed
  5087. procedure pastcset(c)
  5088.  
  5089.     while tab(upto(c)) do {
  5090.         suspend any(c)
  5091.         move(1)
  5092.     }
  5093.  
  5094. end
  5095.  
  5096. # match the shortest possible string up to and including the string passed
  5097. procedure paststring(c)
  5098.  
  5099.     while tab(find(c)) do {
  5100.         suspend match(c)
  5101.         =c
  5102.     }
  5103.  
  5104. end
  5105.  
  5106. From MANTEL@zeus.unl.edu  Mon Nov  7 07:54:09 1988
  5107. Message-Id: <8811071454.AA27122@megaron.arizona.edu>
  5108. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  5109.     id AA27122; Mon, 7 Nov 88 07:54:09 MST
  5110. Received: from crcvms.unl.edu by rvax.ccit.arizona.edu; Mon, 7 Nov 88 07:34 MST
  5111. Date: Sun, 6 Nov 88 20:35 CST
  5112. From: MANTEL@zeus.unl.edu
  5113. Subject: Help, please . . .
  5114. To: icon-group@arizona.edu
  5115. X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu"
  5116.  
  5117. In the July 1985 issue of Byte Magazine, Ralph Griswold (in an interview)
  5118. mentioned that "people in industry are using Icon for VLSI layout." Could you
  5119. please supply me with a starting point to digging up references in journals or
  5120. magazines on such usage? Journal names, or names of people doing this sort
  5121. of thing? I've looked, but evidently not in the right places yet . . .
  5122.  
  5123. General problem: I'm trying to find applications that are non-numeric, and
  5124. non-linguistic. (I already have plenty of examples of those two categories.)
  5125. For example, what about applications written in Icon using group theory for
  5126. chemistry applications? Seems like a natural possibility, but I haven't
  5127. found any. I suspect that articles about that exist, but "Icon" may not be
  5128. in the title or listed as a keyword. Same for applications in graph theory,
  5129. genetics, etc. Is there a bibliography of applications somewhere?
  5130.  
  5131. Thanks in advance for your time and effort. I appreciate the help.
  5132.  
  5133. From ralph  Tue Nov  8 04:47:20 1988
  5134. Date: Tue, 8 Nov 88 04:47:20 MST
  5135. From: "Ralph Griswold" <ralph>
  5136. Message-Id: <8811081147.AA28711@megaron.arizona.edu>
  5137. Received: by megaron.arizona.edu (5.59-1.7/14)
  5138.     id AA28711; Tue, 8 Nov 88 04:47:20 MST
  5139. To: icon-group
  5140. Subject: Version 7 Icon configurations for UNIX systems
  5141.  
  5142. We're in the process of updating our source-code release for
  5143. Icon.  This will bring it to Version 7.5 (the changes are
  5144. mostly in the implementation, not the language itself).
  5145.  
  5146. For the UNIX release, we'd like to include configuration files
  5147. for as many systems as possible.  We have configuration files
  5148. for Version 7 Icon for the following systems:
  5149.  
  5150.     AT&T 3B2           Sequent Balance 8000
  5151.     AT&T 3B20           Sequent Symmetry
  5152.     AT&T 3B4000           Siemens MX500
  5153.     Convex C-1/2           Sun-2 Workstation
  5154.     Encore               Sun-3 Workstation
  5155.     HP 9000/320           Sun-3 with 68881
  5156.     IBM PS/2 (XENIX 386)       Sun-4 Workstation
  5157.     IBM RT Workstation (AIX)   UNIX-PC/3B1
  5158.     IBM XT/AT (XENIX 286)       VAX-11 (BSD)
  5159.     Microport V/386           VAX-11 (System V)
  5160.                    VAX-11 (Ultrix)
  5161.  
  5162. If you have configuration files for a system that is not on this
  5163. list, we would appreciate your sending them to us.
  5164.  
  5165. You can send them any way that's convenient for you. What's worked
  5166. best in the past has been electronic mail with the files packaged
  5167. using shar.  Things like cpio or tar piped though btoa or uuencode
  5168. also work.
  5169.  
  5170. Please address any questions to me, not icon-group.
  5171.  
  5172.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  5173.    +1 602 621 6609   ralph@Arizona.EDU  {uunet|allegra|noao}!arizona!ralph
  5174.  
  5175.  
  5176. From wgg@june.cs.washington.edu  Mon Nov 14 14:04:07 1988
  5177. Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  5178.     id AA21183; Mon, 14 Nov 88 14:04:07 MST
  5179. Received: by june.cs.washington.edu (5.59/6.13+)
  5180.     id AA22448; Mon, 14 Nov 88 12:11:50 PST
  5181. Date: Mon, 14 Nov 88 12:11:50 PST
  5182. From: wgg@june.cs.washington.edu (William Griswold)
  5183. Return-Path: <wgg>
  5184. Message-Id: <8811142011.AA22448@june.cs.washington.edu>
  5185. To: icon-group@arizona.edu
  5186. Subject: Improving Table Performance
  5187.  
  5188. I have been experimenting with implementing Icon tables (and sets)
  5189. using ``dynamic hashing'' in order to achieve true linear-time insert
  5190. and lookup performance in tables.  Dynamic hashing is a technique 
  5191. that dynamically expands or contracts a hash table (i.e., the number
  5192. or ``buckets'' it has) in proportion to the number of elements in the
  5193. table.  By assuring that the number of buckets and the number of
  5194. elements is related by a constant factor (and assuring even element
  5195. distribution) linear-time performance can be achieved.  The table
  5196. expansion is acheived by a dynamically-sized-array datatype; this
  5197. introduces an extra level of indirection in accessing elements. 
  5198.  
  5199. The results of my implementation were very positive.  For a small
  5200. overhead (say, 5% in time on small tables, 10% in space), uniform table 
  5201. element access is acheived for any size table.  I'm hoping to cut 
  5202. out more of the time overhead.
  5203.  
  5204. I was inspired to attempt this by some data-intensive applications that
  5205. were running slowly due to poor table performance (as shown below, this
  5206. is only an issue for rather large tables).  The final inspiration came
  5207. from the April 1988 CACM article "Dynamic Hash Tables" by Per-Ake Larson.
  5208.  
  5209.  
  5210.                 TEST RESULTS
  5211.                 ------------
  5212. For comparison, hear are some results from running a test program.  
  5213. The program inserts random integers into a table at increments of 
  5214. powers of 2, checking at each power how long 500 lookups are
  5215. taking for each of the ``Test integers''.  HEAPSIZE is 3000000, 
  5216. STRSIZE is 2000000, Sun3, Unix.  I get pretty wide variations in
  5217. runtimes for these programs (+-5%), so I can only say these are
  5218. representative.  First the run on old iconx, then under my version: 
  5219.  
  5220. OLD ICONX:
  5221. Test integers are: 1528858604, 108158591, 1572747416, 169761597, 651873887, 
  5222. 899332472, 1088491433, 673419496, 879469459, 450641070.
  5223. tab size  look time*500   time/size    total runtime
  5224.   1         516            516.0          516       
  5225.   2         550            275.0          1066      
  5226.   4         550            137.5          1616      
  5227.   8         517            64.625         2150      
  5228.   16        517            32.3125        2683      
  5229.   32        550            17.1875        3250      
  5230.   64        633            9.890625       3883      
  5231.   128       500            3.90625        4416      
  5232.   256       567            2.21484375     5033      
  5233.   512       650            1.26953125     5833      
  5234.   1024      617            0.6025390625   6750      
  5235.   2048      867            0.4233398438   8333      
  5236.   4096      1150           0.2807617188   11000     
  5237.   8192      1550           0.1892089844   16166     
  5238.   16384     2750           0.1678466797   30383     
  5239.   32768     5200           0.1586914063   77850     
  5240.  
  5241.  
  5242. MY ICONX:
  5243. Test integers are: 1528858604, 108158591, 1572747416, 169761597, 651873887,
  5244. 899332472, 1088491433, 673419496, 879469459, 450641070.
  5245. tab size  look time*500   time/size    total runtime
  5246.   1         534            534.0          550       
  5247.   2         516            258.0          1066      
  5248.   4         567            141.75         1633      
  5249.   8         583            72.875         2216      
  5250.   16        534            33.375         2750      
  5251.   32        584            18.25          3350      
  5252.   64        567            8.859375       3933      
  5253.   128       600            4.6875         4550      
  5254.   256       600            2.34375        5233      
  5255.   512       583            1.138671875    5966      
  5256.   1024      617            0.6025390625   6883      
  5257.   2048      600            0.29296875     8066      
  5258.   4096      600            0.146484375    9850      
  5259.   8192      634            0.07739257813  12850     
  5260.   16384     567            0.03460693359  18233     
  5261.   32768     600            0.01831054688  30550     
  5262.  
  5263. The ``turnover'' point is somewhere around 500-1000 elements.
  5264. The results are similar for a similar program using words from 
  5265. /usr/dict/words.
  5266.  
  5267. On a ``real program'' (grouping words in /usr/dict/words by cset 
  5268. equivalence) I got a 25% improvement in the running time.  This 
  5269. program is I/O intensive, and uses lots of cset conversions and 
  5270. auxiliary tests.   Performance was helped *substantially* in both
  5271. programs (I think more than the new hashing algorithm could) by 
  5272. generously allocated memory space, as indicated above. 
  5273.  
  5274.  
  5275.             EXTRA FOR EXPERTS
  5276.             -----------------
  5277. The details of the algorithm can be found in the article cited above
  5278. (which is the implementation I faithfully applied).  Below I discuss
  5279. changes to the Icon element-hashing function. 
  5280.  
  5281. I reimplemented the hash functions for strings and csets, which had 
  5282. poor distributions under the scheme I was using, although they worked 
  5283. fine under the old implementation.  The reasons that the old hash 
  5284. functions did not work so well in my implementation is simple: my 
  5285. tables are not necessarily of fixed (small) size, and are not of
  5286. prime size.  Hence hash values under my implementation need to large,
  5287. and must be scrambled by something other than the bucket-assignment
  5288. ``mod'' operation.  The distributions now appear to be very good, 
  5289. judging from the profiling I've done. 
  5290.  
  5291. For strings, the function now is:
  5292.  
  5293.       for (j = (j <= 10) ? j : 10 ; j > 0; j--)
  5294.      {
  5295.          hashval += *s++ & 0377;   /* WGG - is the mask necessary anymore? */
  5296.      hashval *= 37;    /* WGG - new; better distribution, larger numbers */
  5297.      }
  5298.       hashval += StrLen(*dp);
  5299.       hashval = AbsHash(hashval); /* WGG - new; abs value - cannot be neg */
  5300.  
  5301.  
  5302. For csets it is:
  5303.  
  5304.         bitarr = BlkLoc(*dp)->cset.bits + (CsetSize-1);
  5305.             for (j = 0; j < CsetSize; j++)
  5306.          {
  5307.                 /* WGG - loop body was: i ^= BlkLoc(*dp)->cset.bits[j]; */
  5308.              hashval += AbsHash(*bitarr--);   /* WGG - AbsHash necessary? */
  5309.          hashval *= 37;    /* WGG - better distribution */
  5310.          }
  5311.         hashval += BlkLoc(*dp)->cset.size;       /* WGG - include size */
  5312.         hashval = AbsHash(hashval) % 1048583;  /* WGG - scramble */
  5313.  
  5314.  
  5315. Clearly, for tables containing values of these types, some of the 
  5316. performance loss for smaller tables could be in these hash functions
  5317. (which could be cleaned-up, as noted in the comments), although it's
  5318. more likely hidden in the extra level of indirection in the table
  5319. implementation. 
  5320.  
  5321.  
  5322.  
  5323.                 STATUS
  5324.                 ------
  5325. The implementation as it stands is not complete.  I have not implemented
  5326. the contraction part of the algorithm for tables, and the set implementation 
  5327. is not quite finished.
  5328.  
  5329.  
  5330.                     Bill Griswold
  5331.  
  5332. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Wed Nov 16 08:31:17 1988
  5333. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  5334.     id AA17345; Wed, 16 Nov 88 08:31:17 MST
  5335. Received: from sophist.uchicago.edu (sophist.uchicago.edu.ARPA) by sphinx.uchicago.edu (4.12/2.0Sx)
  5336.     id AA11820; Wed, 16 Nov 88 09:32:02 cst
  5337. Return-Path: <goer>
  5338. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  5339.     id AA00651; Tue, 15 Nov 88 20:29:21 CST
  5340. Date: Tue, 15 Nov 88 20:29:21 CST
  5341. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  5342. Message-Id: <8811160229.AA00651@sophist.uchicago.edu>
  5343. To: willr@ncsa.uiuc.edu
  5344. Subject: Re:  humanist network
  5345. Cc: icon-group@arizona.edu
  5346.  
  5347. That was pretty funny.  Fiction writer?
  5348.  
  5349. No, actually there are many people who are linguists, archeologists,
  5350. sociologists, or whatever, who use the computer for database and other
  5351. such work.  I use Icon for low-level linguistic analysis in Near Eastern
  5352. languages and literatures.  If you are involved in the humanities, you
  5353. might want to contact Willard McCarty at MCCARTY@UTOREPAS.bitnet; he
  5354. is the one that monitors the group.
  5355.  
  5356.                                         -Richard L. Goerwitz
  5357.                                         goer@sophist.uchicago.edu
  5358.                                         rutgers!oddjob!gide!sophist!goer
  5359.  
  5360. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Wed Nov 16 14:29:30 1988
  5361. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  5362.     id AA04641; Wed, 16 Nov 88 14:29:30 MST
  5363. Received: from sophist.uchicago.edu (sophist.uchicago.edu.ARPA) by sphinx.uchicago.edu (4.12/2.0Sx)
  5364.     id AA16763; Wed, 16 Nov 88 15:30:49 cst
  5365. Return-Path: <goer@sophist.uchicago.edu>
  5366. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  5367.     id AA01730; Wed, 16 Nov 88 15:22:25 CST
  5368. Date: Wed, 16 Nov 88 15:22:25 CST
  5369. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  5370. Message-Id: <8811162122.AA01730@sophist.uchicago.edu>
  5371. To: icon-group@arizona.edu
  5372. Subject: fiction writer
  5373.  
  5374. I don't mean to make fun of anyone when I said that the mention
  5375. of a fiction writer was funny on the Icon newsgroup.  I had mis-
  5376. read the note.  Fiction-writing is certainly no more or less noble
  5377. an occupation than any other.  Writing actually carries a certain
  5378. mystique about it that makes it seem very attractive to outsiders.
  5379.  
  5380.                                         -Richard L. Goerwitz
  5381.                                         goer@sophist.uchicago.edu
  5382.                                         rutgers!oddjob!gide!sophist!goer
  5383.  
  5384. From hdan@sleepy.cc.utexas.edu  Thu Nov 17 17:35:59 1988
  5385. Received: from emx.utexas.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  5386.     id AA15626; Thu, 17 Nov 88 17:35:59 MST
  5387. Received: by emx.utexas.edu (5.54/5.51)
  5388.     id AA12702; Thu, 17 Nov 88 18:36:07 CST
  5389. Date: Thu, 17 Nov 88 18:34:42 CST
  5390. From: hdan@sleepy.cc.utexas.edu (Dan Higdon)
  5391. Posted-Date: Thu, 17 Nov 88 18:34:42 CST
  5392. Message-Id: <8811180034.AA21854@sleepy.cc.utexas.edu>
  5393. Received: by sleepy.cc.utexas.edu (5.51/5.51)
  5394.     id AA21854; Thu, 17 Nov 88 18:34:42 CST
  5395. To: icon-group@arizona.edu
  5396. Subject: Icon program example
  5397.  
  5398. #
  5399. #   NOTE:
  5400. #   This is a simple course scheduling program (for students)
  5401. #   I have found it useful (that's why I wrote it), and I hope other
  5402. #   Icon users might also.  I am providing this source for use and
  5403. #   reference only, you do not have permission to sell it
  5404. #   or any program derived from this source!
  5405. #   I would be interested in any comments/ideas you have.
  5406. #   You can reach me on ARPANET or indirectly through the icon-project
  5407. #   mailing list.
  5408. #
  5409. #
  5410. #      The latest incarnation of...
  5411. #   Dan Higdon's Scheduling Program!
  5412. #           April 20, 1988
  5413. #            By Dan Higdon
  5414. #        in Icon Version 7.0
  5415. #
  5416. # ARPANET address: hdan@sleepy.cc.utaxas.edu
  5417. #
  5418. #
  5419. #   This is an attempt to bring a bit of user-
  5420. # friendliness to the recursive-backtracked
  5421. # class scheduling algorithm I have traditionally
  5422. # been using.  This ICON version of the scheduler
  5423. # will use the same tried and true PROLOG based
  5424. # algorithm that my other scheduler uses,
  5425. # only adapted to ICON's special abilities.
  5426. #
  5427. # The icon scheduler will attempt to preserve
  5428. # the "declarativeness" of this scheduler as much as possible.
  5429. # Now for the program...
  5430.  
  5431.  
  5432. #######################################################################
  5433. #
  5434. #                             Variables
  5435. #
  5436.  
  5437. #
  5438. # classdb is a table of lists of times.
  5439. # times are keyed on class names.
  5440. #
  5441. global classdb,            # The class database
  5442.        width,              # Default width of field
  5443.        shade,              # Default "spongy" character
  5444.        military,           # Whether or not to display military
  5445.        number,             # Whether or not to number each schedule
  5446.        title,              # The title line
  5447.        plot,               # Plot to screen?
  5448.        nonotes,            # Suppress the .n field?
  5449.        outfile,            # File handle, output to file?
  5450.        fwrite,             # Write to file?
  5451.        saturday            # Print saturday column?
  5452.  
  5453.  
  5454. #
  5455. # The class type
  5456. #
  5457. record class (name,       # Class name
  5458.               day,        # Set of days
  5459.               times,      # Class times
  5460.               unum,       # Unique number
  5461.               notes,      # Extra information
  5462.               shade,      # Shade character
  5463.               lab)        # The optional lab class
  5464.  
  5465.  
  5466. #######################################################################
  5467. #
  5468. #                          The scheduler
  5469. #
  5470. #
  5471. # In order to preserve the backtracking idea, schedule is
  5472. # a generator which generates the possible schedules at
  5473. # that level of recursion.
  5474. #
  5475. # clist is a list of class names
  5476. #
  5477. # The algorithm is as follows:
  5478. # If clist is null, return an empty schedule list
  5479. #    with no chance of more "generating"
  5480. # otherwise,
  5481. #    Generate every remaining schedule and do the following with each:
  5482. #       get the class name
  5483. #       Generate every non-null and unconflicting time for each class and
  5484. #          push it onto the list
  5485. #          suspend this schedule, then pop the entry
  5486. #
  5487. procedure schedule (clist)
  5488.    local t, schedl, cl
  5489.  
  5490.    if *clist = 0 then return clist
  5491.  
  5492.    every schedl <- schedule (clist[2:0]) &
  5493.          t <- !classdb[clist[1]] &
  5494.          nonConflicting (t,schedl) &
  5495.          (/t.lab | nonConflicting (\t.lab,schedl))
  5496.    do {
  5497.       cl := ([t,\t.lab] | [t])
  5498.       suspend if *schedl = 0 then cl
  5499.               else cl ||| schedl
  5500.    }
  5501. end
  5502.  
  5503.  
  5504. #
  5505. # Detect conflicts in schedule times
  5506. #
  5507. # This routine fails if there IS a conflict in the time
  5508. # specified and the schedule list supplied.  The algorithm
  5509. # checks each element of the list against the supplied time
  5510. # and returns successfully iff a match is not found
  5511. #
  5512. procedure nonConflicting (t,l)
  5513.    local lt
  5514.  
  5515.    every lt := !l do
  5516.       if (*(t.day ** lt.day) ~= 0) & SameTime(t.times,lt.times) then fail
  5517.    return  # Everything works
  5518. end
  5519.  
  5520.  
  5521. #
  5522. # Check for overlapping times.
  5523. #
  5524. procedure SameTime (x,y)
  5525.    if x[1] = y[1] |              # If same start
  5526.       (y[1] < x[1] < y[2]) |     # or overlapping
  5527.       (x[1] < y[1] < x[2])
  5528.    then return
  5529. end
  5530.  
  5531.  
  5532. #######################################################################
  5533. #
  5534. #                       Input routines
  5535. #
  5536.  
  5537. #
  5538. # The comment stripper & detabber
  5539. #
  5540. procedure strip (s)
  5541.    return detab (trim(s[1:find (";",s) | 0]))
  5542. end
  5543.  
  5544.  
  5545. #
  5546. # The preprocessor.
  5547. # This routine is responsible for processing the "dot"
  5548. # commands.  Any dot commands are interpreted and
  5549. # all other lines are passed through
  5550. #
  5551. procedure preproc (s)
  5552.    local command, arg, lab
  5553.  
  5554.    if *s = 0 | s[1] ~== "." then return s
  5555.  
  5556.    s ? {
  5557.       command := map(tab(upto (' ') | 0),&lcase,&ucase)
  5558.       tab (many (' '))
  5559.       arg := tab (0)
  5560.    }
  5561.    case command of {
  5562.       ".WIDTH":     if not (width := integer (arg)) then
  5563.                        stop ("Invalid width ",arg)
  5564.       ".SHADE":     if not (shade := arg[1:2]) then
  5565.                        stop ("Invalid shade character ",arg)
  5566.       ".MILITARY":  military := 1
  5567.       ".NUMBER":    number := 1
  5568.       ".TITLE":     title := arg
  5569.       ".PLOT":      plot := plotclass
  5570.       ".OUTFILE":   {
  5571.                        if not (outfile := open (arg,"w")) then
  5572.                           stop ("Invalid filename ",arg)
  5573.                        fwrite := writeclass
  5574.                     }
  5575.       ".SATURDAY":  saturday := "Sat"
  5576.       ".LAB":       {
  5577.                        lab := linetrans (" " || arg)
  5578.                        classdb[lab.name][1].lab := lab
  5579.                        lab.name ||:= " l"
  5580.                     }
  5581.       ".NONOTES":   nonotes := 1
  5582.       default:      stop ("Error, ", command, " not recognized")
  5583.    }
  5584.    return ""
  5585. end
  5586.  
  5587.  
  5588. #
  5589. # The class time translater
  5590. #
  5591. # This procedure translates times in the line format:
  5592. #     "[classname]  mtwthf h:mm [h:mm] [notes]"
  5593. # Each element of the line must be separated by spaces
  5594. # This format was chosen for readability.  Spacing is free-format.
  5595. #    ex: "cs410  mwf 1:00 2:00"
  5596. #
  5597. # The classname is returned if successful
  5598. #
  5599.  
  5600. procedure linetrans (string)
  5601.    local day, s, e, c, n, notes, i, nxt, unum
  5602.    static name, space
  5603.    initial space := ' '
  5604.  
  5605.    string ? {
  5606.       n := tab (upto (space))         # name = 1st word
  5607.       tab (many (space))              # Skip any spaces following
  5608.  
  5609.       day := tab (upto (space))       # day = next word
  5610.       tab (many (space))              # skip to next field
  5611.  
  5612.       start := tab (upto (space) | 0) # start = upto blank or EOS
  5613.       tab (many (space))              # skip leading blanks
  5614.  
  5615.       nxt := tab (upto (space) | 0)  # get end time or EOS
  5616.       if find (":",nxt) then {
  5617.          etime := nxt
  5618.          tab (many (space))
  5619.          nxt := tab (upto (space) | 0)
  5620.       } else {
  5621.          etime := ""
  5622.       }
  5623.       if nxt == ".n" | nxt == ".N" then {    # Option
  5624.          tab (many (space))
  5625.          notes := tab (0)
  5626.          unum := ""
  5627.       } else {
  5628.          unum := nxt
  5629.          tab (find (".n" | ".N"))
  5630.          tab (upto (space))
  5631.          tab (many (space))
  5632.          notes := tab (0)
  5633.       }
  5634.    }
  5635.    if n ~== "" then name := n        # Allow for assumed name
  5636.  
  5637.    if i := find ("th",day) then day[i:i+1] := ""
  5638.  
  5639.    s := toMilitary (start)
  5640.    e := toMilitary (etime)  |  stdtime (cset(day),s)
  5641.    return class (name,cset(day),[s,e],unum,notes,shade,&null)
  5642. end
  5643.  
  5644.  
  5645. #
  5646. # Return the standard end time for the given day.
  5647. # MWF classes are 1 hr long, others 1:30.
  5648. #
  5649. procedure stdtime (day,start)
  5650.    local   c
  5651.  
  5652.    c := start
  5653.    if *(day ** 'mwfs') = 0 then c +:= 50
  5654.    c +:= 100
  5655.    return c
  5656. end
  5657.  
  5658.  
  5659. #######################################################################
  5660. #
  5661. #                       Output routines
  5662. #
  5663.  
  5664. #
  5665. # The outclass driver routine
  5666. #
  5667. procedure outclass (l,count)
  5668.    (\plot) (l,count)
  5669.    (\fwrite) (l,count)
  5670. end
  5671.  
  5672.  
  5673. #
  5674. # Display the class in a nice format
  5675. # I hope to make this more "graphic" in the future.
  5676. #
  5677. procedure plotclass (l,count)
  5678.    local w,c
  5679.  
  5680.    if \saturday then
  5681.       w := width*6
  5682.    else
  5683.       w := width*5
  5684.    clrscrn()
  5685.    gotoxy (10,1)
  5686.    write (center (if \number then title || " " || count
  5687.                  else title,
  5688.                  w))
  5689.    DayLabel()
  5690.    TimeLabel()
  5691.    every c := !l do place (c)
  5692.    gotoxy (1,25)
  5693.    writes ("Hit any key for next schedule, <shift>+<PrtScr> to print, or <ESC> to exit.")
  5694.    if ord (getch()) = 27 then stop ("\nProgram terminated by user")
  5695.    return
  5696. end
  5697.  
  5698.  
  5699. #
  5700. # Position the class name at the proper location
  5701. # on the screen "grid"
  5702. #
  5703. procedure place (class)
  5704.    local day, od, ot, ote, shades
  5705.  
  5706.    shades  := repl (class.shade,width-2)
  5707.    every day := !class.day do {
  5708.       if day == "s" & /saturday then return
  5709.       od := (find(day,"mtwhfs") - 1)*width + 9
  5710.       ot := class.times[1]/50 - 13
  5711.       ote := class.times[2]/50 - 14
  5712.       gotoxy (od, ot)
  5713.       writes (center (class.name,width))
  5714.       if /nonotes & class.notes ~== "" then {
  5715.          ot +:= 1
  5716.          gotoxy (od,ot)
  5717.          writes (center (class.notes,width))
  5718.       }
  5719.       every gotoxy (od,ot+1 to ote) do
  5720.          writes (center (shades,width))
  5721.    }
  5722. end
  5723.  
  5724.  
  5725. #
  5726. # Produce the output for the Day display
  5727. #
  5728. procedure DayLabel()
  5729.    writes ("        ")
  5730.    every writes (
  5731.       center ("Mon" | "Tue" | "Wed" | "Thu" | "Fri" | \saturday, width))
  5732.    write()
  5733. end
  5734.  
  5735.  
  5736. #
  5737. # Produce the output for the time labels
  5738. #
  5739. procedure TimeLabel ()
  5740.    if \military then {
  5741.       every write (" ", 8 to 9,":00\n")
  5742.       every write (10 to 18,":00\n")
  5743.    } else {
  5744.       every write (" ",8 to 9,":00am\n")
  5745.       every write (10 to 11,":00am\n")
  5746.       write ("12:00pm\n")
  5747.       every write (" ",1 to 6,":00pm\n")
  5748.    }
  5749. end
  5750.  
  5751.  
  5752. #
  5753. # Write the classes to the tty style file specified
  5754. #
  5755. procedure writeclass (l,count)
  5756.    local c
  5757.  
  5758.    write (outfile,"\n",title," ",(\number,count) | "")
  5759.    write (outfile,left ("Name",width),
  5760.       " Days    "," From    "," To      ","Unique  ","Notes")
  5761.    write (outfile,repl("=",47+width))
  5762.    every c := !l do write (outfile,
  5763.       left (c.name,width)," ",
  5764.       left (toDays (c.day),8),
  5765.       left (toStandard (c.times[1]),9),
  5766.       left (toStandard (c.times[2]),9),
  5767.       left (c.unum,8),
  5768.       c.notes)
  5769.    write (outfile)
  5770. end
  5771.  
  5772.  
  5773. #
  5774. # Output the titlescreen
  5775. #
  5776. procedure titlescreen ()
  5777.    clrscrn()
  5778.    write()
  5779.    write (center ("Sched-Tool   Course Scheduling Tool",79),
  5780.           center ("Student Edition",79),
  5781.           center ("Version 1.1 Copywrite (c) 1988 Dan Higdon",79),"\n")
  5782. end
  5783.  
  5784.  
  5785. #######################################################################
  5786. #
  5787. #                            Utilities
  5788. #
  5789.  
  5790.  
  5791. #
  5792. # Convert a time into a military decimal notation
  5793. #
  5794. procedure toMilitary (t)
  5795.    local mt
  5796.  
  5797.    if *t = 0 then fail
  5798.  
  5799.    mt := (t ? tab(upto (':')))
  5800.    if mt < 8 then {
  5801.       mt +:= 12
  5802.    }
  5803.    mt *:= 100
  5804.    if find(":3",t) then mt +:= 50
  5805.    return mt
  5806. end
  5807.  
  5808.  
  5809. #
  5810. # Convert military integer to a string
  5811. #
  5812. procedure toStandard (m)
  5813.    local hr, min, sh
  5814.  
  5815.    hr := m/100
  5816.    if (m - hr*100) = 0 then
  5817.       min := ":00"
  5818.    else
  5819.       min := ":30"
  5820.    if /military & hr > 12 then  hr -:= 12
  5821.    if hr < 10 then
  5822.       sh := " " || string (hr)
  5823.    else
  5824.       sh := string (hr)
  5825.    return sh || min
  5826. end
  5827.  
  5828.  
  5829. #
  5830. # Convert a set of days into a string of days
  5831. # in the appropriate order and form
  5832. #
  5833. procedure toDays (days)
  5834.    local sd, d
  5835.  
  5836.    sd := ""
  5837.    d := ""
  5838.    every d ||:= !days
  5839.    if find ("m",d) then
  5840.       sd ||:= "m"
  5841.    if find ("t",d) then
  5842.       sd ||:= "t"
  5843.    if find ("w",d) then
  5844.       sd ||:= "w"
  5845.    if find ("h",d) then
  5846.       sd ||:= "th"
  5847.    if find ("f",d) then
  5848.       sd ||:= "f"
  5849.    if find ("s",d) then
  5850.       sd ||:= "s"
  5851.    return sd
  5852. end
  5853.  
  5854.  
  5855. #######################################################################
  5856. #
  5857. #                          The main procedure
  5858. #
  5859.  
  5860. procedure main (argv)
  5861.    local classes, ct, c, count, buf
  5862.    initial {
  5863.       classdb := table()
  5864.       classes := list()
  5865.       width := 10
  5866.       shade := "#"
  5867.       title := "Possible Schedule"
  5868.    }
  5869.  
  5870.    titlescreen()
  5871.    if \argv[1] then {
  5872.       if not (find (".",argv[1])) then argv[1] ||:= ".sch"
  5873.       buf := open (argv[1],"r")
  5874.       write (center ("Reading in file: " || argv[1], 80))
  5875.    }
  5876.    if /buf then {
  5877.       write("\n")
  5878.       write (center ("Error in opening data file.  Aborting",80))
  5879.       exit (1);
  5880.    }
  5881.    while ct := preproc(strip(read(buf))) do {
  5882.       if *ct > 0 then {
  5883.          c := linetrans (ct)
  5884.          (/classdb[c.name] := [c]) | push (classdb[c.name], c)
  5885.          (c.name == !classes)|(/classes := [c.name])|push (classes,c.name)
  5886.       }
  5887.    }
  5888.    close (buf)
  5889.    count := 0
  5890.    write ("\n",center ("Working...",80),"\n")
  5891.    every outclass (schedule (classes), count +:= 1)
  5892.    if count = 0 then write ("No schedule possible.  Exiting.")
  5893.    else write ("\nNo more schedules.  Exiting.")
  5894. end
  5895.  
  5896.  
  5897. #
  5898. #         An ANSI screen library
  5899. #
  5900. # High-level names for the low-level ANSI routines.
  5901. # If your system terminal doesn't support ANSI, you will
  5902. # have to re-implement these two routines, which should be
  5903. # pretty easy...
  5904. # You should use OS calls if possible in your implementation.
  5905. #
  5906.  
  5907. #
  5908. # Move cursor to x,y
  5909. #
  5910. procedure gotoxy (x,y)
  5911.    writes (char(27), "[", y, ";", x, "H")
  5912.    return
  5913. end
  5914.  
  5915. #
  5916. # Clear the text screen
  5917. #
  5918. procedure clrscrn()
  5919.    writes (char(27), "[2J")
  5920.    return
  5921. end
  5922.  
  5923. ############################################################################
  5924.                         -End of program. Cut here-
  5925.           Use from here on as a datafile.  Pass name on command line
  5926. ############################################################################
  5927. ;
  5928. ;   This is a sample input file.  It displays some of the
  5929. ;   functions that this program supports.  It produces
  5930. ;   a "table" of possible schedules (assuming you have implemented
  5931. ;   the cursor control codes for the main program...)
  5932. ;
  5933. .title   Dan Higdon -- Spring 1989 -- Schedule
  5934. ;
  5935. ;   GER507  -   German                  5 hrs.
  5936. ;   LIN340  -   Linguistics             3 hrs.
  5937. ;   CS352   -   Computer Architecture   3 hrs.
  5938. ;   CS345   -   Programming Languages   3 hrs.
  5939. ;   PED105M -   Fencing                 1 hrs.
  5940. ;                                     --------
  5941. ;                                      15 hrs.
  5942. ;
  5943. .width   12             ; Set the width of the columns
  5944. .number                 ; Append schedule number (in sequence) to title
  5945. .plot                   ; Produce visual output
  5946. ; .NoNotes                ; Suppress .n field in visual output
  5947. ; .outfile dans89.txt     ; Create table output to fname
  5948.  
  5949. ;
  5950. ; Classes
  5951. ;
  5952. ; Foreign Language
  5953. GER507  mtwthf  9:00    10:00   30085   .n Jes A307A
  5954.         mtwthf  10:00   11:00   30090   .n Jes A307A
  5955.         mtwthf  11:00   12:00   30095   .n Jes A307A
  5956.         mtwthf  12:00   1:00    30100   .n Jes A307A
  5957.         mtwthf  1:00    2:00    30105   .n Jes A307A
  5958.         mtwthf  2:00    3:00    30110   .n Jes A307A
  5959.         mtwthf  3:00    4:00    30115   .n Jes A307A
  5960.  
  5961. ; Linguistics 340 Automata Theory
  5962. LIN340  mwf     2:00    3:00    33225   .n Cal 100
  5963.  
  5964. ; Computer Science - Computer Systems Architecture
  5965. CS352   tth     2:00    3:30    43170   .n Tay 2.106
  5966. .lab    w       4:00    5:30            ; Lab section for CS352
  5967.  
  5968. ; Computer Science - Programming Languages
  5969. CS345   mwf     9:00    10:00   43150   .n Wel 2.310
  5970.  
  5971. ; Fencing
  5972. .shade !    ; Shade set to '!' for fencing only!
  5973. PED105M mw      10:00   11:30   09275   .n BEL 302
  5974.         tth     12:30   2:00    09280   .n BEL 302
  5975.         mw      1:00    2:30    09285   .n BEL 302
  5976.         mw      2:00    3:30    09290   .n BEL 302
  5977.         tth     2:00    3:30    09295   .n BEL 302
  5978.  
  5979. From att!ihuxy!nowlin  Wed Nov 23 05:52:34 1988
  5980. From: att!ihuxy!nowlin
  5981. Message-Id: <8811231252.AA13136@megaron.arizona.edu>
  5982. Received: by megaron.arizona.edu (5.59-1.7/14)
  5983.     id AA13136; Wed, 23 Nov 88 05:52:34 MST
  5984. Received: by att.ATT.COM (smail2.6 - att-cb)
  5985.     id AA15795; 23 Nov 88 07:47:00 EST (Wed)
  5986. Message-Version: 2
  5987. >To: /addr=att!arizona!icon-group
  5988. Date: Wed 23 Nov 1988 06:47 CST
  5989. End-Of-Header: 
  5990. Email-Version: 2
  5991. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  5992. To: att!arizona!icon-group
  5993. Subject: Icon Regular Expressions
  5994. Ua-Message-Id: <post.nowlin.Wed 23 Nov 1988 06:40 CST>
  5995. End-Of-Protocol: 
  5996. Content-Length: 9945
  5997.  
  5998. I posted a version of grep a while back that had some regular expression
  5999. procedures incorporated in it.  I mentioned that I'd try to generalize them
  6000. when I had time.  I didn't really have time but I did it anyway because it
  6001. was interesting.  Attached is a set of procedures that should be commented
  6002. well enough to explain themselves.  I'll post a new grep main procedure that
  6003. uses these routines separately.  Any comments or suggestions are welcome. 
  6004.  
  6005. Jerry Nowlin
  6006. (...!att!ihuxy!nowlin)
  6007.  
  6008. ================================ cut here ===================================
  6009.  
  6010. # This set of Icon procedures implements regular expression matching
  6011. # for use in the context of string scanning.  The regular expressions
  6012. # recognized by these procedures can contain the following special (magic)
  6013. # characters:
  6014. #
  6015. #     ^   -  matches if the following pattern is at the beginning of a line
  6016. #     $   -  matches if the preceding pattern is at the end of a line
  6017. #     .   -  matches any single character
  6018. #       []  -  matches any of the characters enclosed by square brackets
  6019. #     +   -  matches from 1 to any number of occurrences of the previous
  6020. #            character
  6021. #     *   -  matches from 0 to any number of occurrences of the previous
  6022. #            character
  6023. #     \   -  escapes the special meaning of any special characters
  6024. #            recognized by this program
  6025. #
  6026. # A pair of square brackets can enclose a range specification, like '[a-z]',
  6027. # in which case any of the ASCII characters between 'a' and 'z' will be
  6028. # matched.  If the initial character inside square brackets is a '^' then
  6029. # the matching pattern will be the complement of (any characters except)
  6030. # the ones enclosed in the square brackets.  For example, '[^a-z0-9]' will
  6031. # match any characters except lower case letters and digits.
  6032.  
  6033. # A regular expression record contains a procedure and a pattern argument
  6034. # that the procedure will be invoked on.
  6035. record    rerec(proc,arg)
  6036.  
  6037. # This procedure implements a regular expression version of "find".  This
  6038. # is an incomplete implementation since it only works in the context of
  6039. # string scanning.
  6040. procedure refind(re)
  6041.  
  6042.     savepos := &pos
  6043.     if s := regexpmatch(re,1) then {
  6044.         found := &pos - *s
  6045.         &pos := savepos
  6046.         suspend found
  6047.     }
  6048. end
  6049.  
  6050. # This procedure implements a regular expression version of "match".  This
  6051. # is an incomplete implementation since it only works in the context of
  6052. # string scanning.
  6053. procedure rematch(re)
  6054.  
  6055.     savepos := &pos
  6056.     if s := regexpmatch(re,1) then {
  6057.         found := &pos
  6058.         &pos := savepos
  6059.         if found-savepos = *s then suspend found
  6060.     }
  6061. end
  6062.  
  6063. # This procedure does the recursive matching for all the elements of a
  6064. # regular expression list.  Re is the list of regular expression records to
  6065. # match and i is the index in the list to start matching on.  This procedure
  6066. # assumes it is invoked in the context of string scanning.
  6067. procedure regexpmatch(re,i)
  6068.  
  6069.     # If i is beyond the end of re a match was found so suspend with an
  6070.     # empty string to end the recursion.
  6071.     if i > *re then suspend ""
  6072.  
  6073.     # Otherwise, suspend with the current re.procedure invoked on the
  6074.     # current re. pattern concatenated with the rematch of the next
  6075.     # re.procedure and re.pattern pair.
  6076.     else suspend tab(re[i].proc(re[i].arg)) || regexpmatch(re,i+1)
  6077. end
  6078.  
  6079. # This procedure compiles a lists of regular expression records from the
  6080. # regular expression passed in s.  If the second argument is not null it
  6081. # will invoke a dump of the final regular expression list before the
  6082. # procedure returns it.
  6083. #
  6084. # The regular expression given in s is broken up into a list of partial
  6085. # patterns that can be matched independent of each other.  Then this
  6086. # initial list of partial patterns is optimized.  Each partial pattern has
  6087. # a procedure associated with it that will be used to match it.
  6088. #
  6089. # While parsing the partial patterns there is the concept of a next string
  6090. # matching procedure and a next character matching procedure.  These change
  6091. # from one partial pattern to the next depending on the content of the
  6092. # previous and the current partial patterns.
  6093. procedure recomp(s,debug)
  6094.  
  6095.     static    magic, mundane, ascii
  6096.  
  6097.     initial {
  6098.         magic := '^$.+*[\\'
  6099.         mundane := ~magic
  6100.         ascii := string(&ascii)
  6101.     }
  6102.  
  6103.     # Initialize the temporary regular expression list.
  6104.     retmp := []
  6105.  
  6106.     # Initialize the next string procedure and the next cset procedure.
  6107.     ns := paststring
  6108.     nc := pastcset
  6109.  
  6110.     # Parse each character in the pattern one at a time.  (This is slow
  6111.     # but needed for the '+' and '*' magic characters.)
  6112.     s ? while c := move(1) do case c of {
  6113.  
  6114.         # The beginning of line character.
  6115.         "^": {
  6116.  
  6117.             # If this is the first character of the pattern
  6118.             # it's special.
  6119.             if pos(2) then {
  6120.                 ns := match
  6121.                 nc := any
  6122.  
  6123.                 # If plus or star are the second characters
  6124.                 # and carat is the first then just match them.
  6125.                 if c := move(1) == ("+" | "*")  then
  6126.                     put(retmp,rerec(ns,c))
  6127.             }
  6128.  
  6129.             # If carat isn't the first character just match it.
  6130.             else put(retmp,rerec(ns,"^"))
  6131.         }
  6132.  
  6133.         # The end of line character.
  6134.         "$": {
  6135.  
  6136.             # If this is the last character of the pattern
  6137.             # it's special.
  6138.             if pos(0) then put(retmp,rerec(pos,0))
  6139.  
  6140.             # If dollar isn't the last character just match it.
  6141.             else put(retmp,rerec(ns,"$"))
  6142.         }
  6143.  
  6144.         # The match any character character.
  6145.         ".": {
  6146.             put(retmp,rerec(nc,&ascii))
  6147.             ns := match
  6148.             nc := any
  6149.         }
  6150.  
  6151.         # The 1 to any number of previous characters character.
  6152.         "+": {
  6153.             # If this is the first character of the pattern
  6154.             # it's not special so just match it.
  6155.             if pos(2) then put(retmp,rerec(ns,"+"))
  6156.  
  6157.             # Otherwise it's special.
  6158.             else {
  6159.                 retmp[-1].proc := plus
  6160.                 retmp[-1].arg := cset(retmp[-1].arg)
  6161.                 ns := match
  6162.                 nc := any
  6163.             }
  6164.         }
  6165.  
  6166.         # The 0 to any number of previous characters character.
  6167.         "*": {
  6168.             # If this is the first character of the pattern
  6169.             # it's not special so just match it.
  6170.             if pos(2) then put(retmp,rerec(ns,"*"))
  6171.  
  6172.             # Otherwise it's special.
  6173.             else {
  6174.                 retmp[-1].proc := star
  6175.                 retmp[-1].arg := cset(retmp[-1].arg)
  6176.                 ns := match
  6177.                 nc := any
  6178.             }
  6179.         }
  6180.  
  6181.         # The escape other characters character.
  6182.         "\\": {
  6183.  
  6184.             # If the next character is a special character
  6185.             # match it and skip the backslash.
  6186.             if any(magic,&subject[&pos]) then
  6187.                 put(retmp,rerec(ns,move(1)))
  6188.  
  6189.             # If the next character isn't special match backslash.
  6190.              else put(retmp,rerec(ns,"\\"))
  6191.         }
  6192.  
  6193.         # The match enclosed characters character.
  6194.         "[": {
  6195.             inside := ''
  6196.             lastc := "["
  6197.             c := move(1)
  6198.  
  6199.             # If the complement character is the first one in
  6200.             # the brackets.
  6201.             if c == "^" then {
  6202.                 notin := 1
  6203.                 c := move(1)
  6204.             }
  6205.  
  6206.             # Otherwise the first character is not special.
  6207.             else    notin := 0
  6208.  
  6209.             # Parse the inside cset characters.
  6210.             repeat {
  6211.                 case c of {
  6212.                     # The closing bracket means we're done.
  6213.                     "]": break;
  6214.  
  6215.                     # The dash means we're in a range.
  6216.                     "-": {
  6217.  
  6218.                         # If the dash is at the end
  6219.                         # or beginning of the inside
  6220.                         # cset just match a dash.
  6221.                         if (lastc == "[") |
  6222.                            (&subject[&pos] == "]")
  6223.                         then {
  6224.                             lastc := "-"
  6225.                             inside ++:= cset(lastc)
  6226.                         }
  6227.  
  6228.                         # Otherwise match the range
  6229.                         # of ascii characters between
  6230.                         # the previous and
  6231.                         # following characters.
  6232.                         else
  6233. # The current indent is violated by this and the next line.
  6234. inside ++:= cset(ascii[upto(lastc,ascii)+1:upto(lastc := move(1),ascii)+1])
  6235.                     }
  6236.  
  6237.                     # A backslash means take the next
  6238.                     # character regardless.
  6239.                     "\\": {
  6240.                         lastc := move(1)
  6241.                         inside ++:= cset(lastc)
  6242.                     }
  6243.  
  6244.                     # The default is to add the
  6245.                     # character to the inside cset.
  6246.                     default: {
  6247.                         lastc := c
  6248.                         inside ++:= cset(lastc)
  6249.                     }
  6250.                 }
  6251.  
  6252.                 # If we ran out of characters break.
  6253.                 if not (c := move(1)) then break;
  6254.             }
  6255.  
  6256.             # This is a check for mismatched brackets.
  6257.             if pos(0) & c ~== "]" then
  6258.                 stop("Mismatched brackets '",s,"'")
  6259.  
  6260.             # If the complement flag is set complement the
  6261.             # inside cset.
  6262.             if notin = 1 then inside := ~inside ** &ascii
  6263.  
  6264.             # Add this record to the regular expression list.
  6265.             put(retmp,rerec(nc,inside))
  6266.         }
  6267.  
  6268.         # Mundane characters are just added to the list.
  6269.         default: {
  6270.             put(retmp,rerec(ns,c))
  6271.             ns := match
  6272.             nc := any
  6273.         }
  6274.  
  6275.     } # The bottom of parse the pattern loop.
  6276.  
  6277.     # Initialize the flag for being in a literal string.
  6278.     instring := 0
  6279.  
  6280.     # Initialize the final regular expression list.
  6281.     re := []
  6282.  
  6283.     # Go through the initial patterns and optimize them by making
  6284.     # consecutive literal strings into single literal strings.
  6285.     every r := !retmp do {
  6286.  
  6287.         # If this record contains a literal string.
  6288.         if type(r.arg) == "string" &
  6289.            r.proc === (match | paststring) then {
  6290.  
  6291.             # If the last record was a literal string add this
  6292.             # record to it.
  6293.             if instring = 1 then {
  6294.                 re[-1].arg ||:= r.arg
  6295.             }
  6296.  
  6297.             # If the last record wasn't a literal string start
  6298.             # a literal string with this record.
  6299.             else {
  6300.                 put(re,r)
  6301.                 instring := 1
  6302.             }
  6303.         }
  6304.  
  6305.         # If this record contains a special pattern add it as is.
  6306.         else {
  6307.             put(re,r)
  6308.             instring := 0
  6309.         }
  6310.  
  6311.     }
  6312.  
  6313.     # If the second argument was passed print a dump of the regular
  6314.     # expression list.
  6315.     if \debug then {
  6316.         write("\nRegular Expression Record Dump (",*re,"):")
  6317.         every m := !re do write("\t",image(m.proc),": ",image(m.arg))
  6318.         write()
  6319.     }
  6320.  
  6321.     # Return the list of regular expression records.
  6322.     return re
  6323. end
  6324.  
  6325. # Match partial patterns generated by the '+' magic character.
  6326. procedure plus(c)
  6327.  
  6328.     # The loop is so that the longest possible pattern will be matched.
  6329.     suspend (many(c) to &pos+1 by -1)
  6330.  
  6331. end
  6332.  
  6333. # Match partial patterns generated by the '*' magic character.
  6334. procedure star(c)
  6335.  
  6336.     # The loop is so that the longest possible pattern will be matched.
  6337.     suspend (many(c) to &pos+1 by -1) | &pos
  6338.  
  6339. end
  6340.  
  6341. # Match the shortest possible string up to and including the cset passed.
  6342. procedure pastcset(c)
  6343.  
  6344.     while tab(upto(c)) do {
  6345.         suspend any(c)
  6346.         move(1)
  6347.     }
  6348.  
  6349. end
  6350.  
  6351. # Match the shortest possible string up to and including the string passed.
  6352. procedure paststring(c)
  6353.  
  6354.     while tab(find(c)) do {
  6355.         suspend match(c)
  6356.         =c
  6357.     }
  6358.  
  6359. end
  6360.  
  6361. From att!ihuxy!nowlin  Wed Nov 23 06:05:12 1988
  6362. From: att!ihuxy!nowlin
  6363. Message-Id: <8811231305.AA13932@megaron.arizona.edu>
  6364. Received: by megaron.arizona.edu (5.59-1.7/14)
  6365.     id AA13932; Wed, 23 Nov 88 06:05:12 MST
  6366. Received: by att.ATT.COM (smail2.6 - att-cb)
  6367.     id AA15853; 23 Nov 88 07:53:55 EST (Wed)
  6368. Message-Version: 2
  6369. >To: /addr=att!arizona!icon-group
  6370. Date: Wed 23 Nov 1988 06:54 CST
  6371. End-Of-Header: 
  6372. Email-Version: 2
  6373. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  6374. To: att!arizona!icon-group
  6375. Subject: new Icon grep
  6376. Ua-Message-Id: <post.nowlin.Wed 23 Nov 1988 06:48 CST>
  6377. End-Of-Protocol: 
  6378. Content-Length: 1236
  6379.  
  6380. Here's a new Icon grep main procedure that uses the regular expression
  6381. matching procedures posted earlier.
  6382.  
  6383. Jerry Nowlin
  6384. (...!att!ihuxy!nowlin)
  6385.  
  6386. ================================ cut here ===================================
  6387.  
  6388. procedure main(a)
  6389.  
  6390.     # the usage message
  6391.     usage := "Usage: igrep pattern [ file ... ]"
  6392.  
  6393.     # the first program argument must be the pattern
  6394.     pattern := get(a) | stop("I at least need a pattern\n",usage)
  6395.  
  6396.     # compile the pattern into a regular expression list
  6397.     re := recomp(pattern)
  6398.  
  6399.     # trick the program into using standard input if no files were passed
  6400.     if *a = 0 then a := [&null]
  6401.  
  6402.     # the rest of the arguments are files to search through
  6403.     every f := !a do {
  6404.  
  6405.         # if the file isn't null try to open it
  6406.         if \f then in := open(f) | stop("I can't open '",f,"'")
  6407.  
  6408.         # otherwise use standard input
  6409.         else in := &input
  6410.  
  6411.         # if there is only one file skip printing the file name
  6412.         if *a = 1 then f := ""
  6413.  
  6414.         # otherwise tack on a colon
  6415.         else f ||:= ":"
  6416.  
  6417.         # read all the lines
  6418.         every l := !in do {
  6419.  
  6420.             # scan the line for the pattern
  6421.             l ? {
  6422.  
  6423.                 # if the pattern is found print the line
  6424.                 if refind(re) then write(f,l)
  6425.             }
  6426.         }
  6427.  
  6428.         # close the input file is one was opened
  6429.         if in ~=== &input then close(in)
  6430.     }
  6431. end
  6432.  
  6433. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Wed Nov 23 16:06:54 1988
  6434. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  6435.     id AA15351; Wed, 23 Nov 88 16:06:54 MST
  6436. Received: from sophist.uchicago.edu (sophist.uchicago.edu.ARPA) by sphinx.uchicago.edu (4.12/2.0Sx)
  6437.     id AA11091; Wed, 23 Nov 88 17:08:26 cst
  6438. Return-Path: <goer@sophist.uchicago.edu>
  6439. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  6440.     id AA01571; Wed, 23 Nov 88 16:59:33 CST
  6441. Date: Wed, 23 Nov 88 16:59:33 CST
  6442. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  6443. Message-Id: <8811232259.AA01571@sophist.uchicago.edu>
  6444. To: icon-group@arizona.edu
  6445. Subject: Huffmon encoded text
  6446.  
  6447. Say I have a tree all stored for a Huffmon encoded text.  Making
  6448. such a tree is no problem.  What I'm wondering about is how, in
  6449. Icon, one might best go about actually encoding or decoding the
  6450. text.  I've not used the bit-manipulating features of Icon much,
  6451. and I'm just wondering if anyone has already done this (and dis-
  6452. covered how Icon best handles the task).
  6453.  
  6454. Feeling ignorant : desiring enlightenment on this subject....
  6455.  
  6456.                                         -Richard L. Goerwitz
  6457.                                         goer@sophist.uchicago.edu
  6458.                                         rutgers!oddjob!gide!sophist!goer
  6459.  
  6460. From att!ihuxy!nowlin  Mon Nov 28 13:43:34 1988
  6461. From: att!ihuxy!nowlin
  6462. Message-Id: <8811282043.AA28606@megaron.arizona.edu>
  6463. Received: by megaron.arizona.edu (5.59-1.7/14)
  6464.     id AA28606; Mon, 28 Nov 88 13:43:34 MST
  6465. Received: by att.ATT.COM (smail2.6 - att-cb)
  6466.     id AA13083; 28 Nov 88 15:40:15 EST (Mon)
  6467. Message-Version: 2
  6468. >To: /addr=att!arizona!icon-group
  6469. Date: Mon 28 Nov 1988 14:40 CST
  6470. End-Of-Header: 
  6471. Email-Version: 2
  6472. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  6473. To: att!arizona!icon-group
  6474. Subject: co-expressions for regular expressions.
  6475. Ua-Message-Id: <post.nowlin.Mon 28 Nov 1988 14:05 CST>
  6476. End-Of-Protocol: 
  6477. Content-Length: 962
  6478.  
  6479. Gang,
  6480.  
  6481.     There hasn't been a lively discussion in this group for some time.
  6482. Maybe I can plant the seed.  I posted some regular expression code last
  6483. week and have since thought about some alternative solutions.
  6484.  
  6485. I was weaned on a version of Icon that didn't support co-expressions and as
  6486. a result I don't usually think of problems in terms that lend themselves to
  6487. co-expression solutions.  Is there a way to use co-expressions, instead of
  6488. records containing a procedure and an argument for that procedure, in the
  6489. code I posted?  This code was thoroughly commented and someone who knows
  6490. co-expressions better than I do can perhaps look into this.
  6491.  
  6492. Other questions are whether or not co-expressions would be faster than the
  6493. current method and if generation and goal directed evaluation could be used
  6494. in a more elegant way if the algorithm used co-expressions?  I'm never
  6495. completely happy when I have to use subscripts.  Thanks.
  6496.  
  6497. Jerry Nowlin
  6498. (...!att!ihuxy!nowlin)
  6499.  
  6500. From sboisen@REGULUS.BBN.COM  Wed Nov 30 14:15:14 1988
  6501. Message-Id: <8811302115.AA24243@megaron.arizona.edu>
  6502. Received: from REGULUS.BBN.COM by megaron.arizona.edu (5.59-1.7/14) via SMTP
  6503.     id AA24243; Wed, 30 Nov 88 14:15:14 MST
  6504. To: icon-group@arizona.edu
  6505. Subject: problems with tables of tables
  6506. From: Sean Boisen <sboisen@REGULUS.BBN.COM>
  6507. Sender: sboisen@REGULUS.BBN.COM
  6508. Reply-To: sboisen@bbn.com
  6509. Date: Wed, 30 Nov 88 16:05:26 EST
  6510.  
  6511. Here's a problem i ran into today: i found a work-around, but it
  6512. bothers me that i couldn't solve it the concise and elegant way i
  6513. wanted to (and that i'm accustomed to having Icon provide me with).
  6514. Imagine an application where you want to build a table, and the value
  6515. of each entry in the table is itself another table. For example,
  6516. you're going through a numbered list of sentences, some of which have "bad"
  6517. words (definition of bad is irrelevant here), and you want a list of
  6518. all the "bad" words, each followed by the sentences it occurs in. My
  6519. idea was to have a master table, whose entries would be "bad" words:
  6520. then the value of each entry would be itself a table, with entries
  6521. being the sentence number and values the sentence text. So i tried a
  6522. piece of code something like this (irrelevant details omitted):
  6523.  
  6524.  
  6525. procedure main()
  6526.  
  6527.    initial master := table(table())
  6528.    
  6529.    while (line := read()) do 
  6530.    {
  6531.        # imagine some code here that assigns to sentence and number
  6532.        # .....
  6533.  
  6534.        if bad-word := get_bad_word(line) then
  6535.        {
  6536.        sentence_table := master[bad_word]
  6537.        sentence_table[number] := sentence
  6538.        master[bad_word] := sentence_table
  6539.        }
  6540.    }
  6541. end
  6542.  
  6543. The idea is that master[bad_word] should produce a table, which is
  6544. assigned to sentence_table: you then play with that, and assign the
  6545. new one back to master[bad_word] (since only assignments "grows" a
  6546. table). This doesn't work, however: the best was i can describe the
  6547. failure is that sentence_table maintains the same value across
  6548. different values of bad_word, in other words it accumulates ALL
  6549. sentences, not just those specific to this particular bad_word. Am i
  6550. missing something really obvious? If there is no previous entry for
  6551. bad_word in master, shouldn't the assignment to sentence_table produce
  6552. an empty table instead of the same one as for some other value of
  6553. bad_word?
  6554.  
  6555. (by the way, the workaround i used was to keep a separate table of
  6556. "found" bad_words, and if the bad_word wasn't there, explicitly assign
  6557. a new table to sentence_table, i.e.
  6558.     sentence_table := table()
  6559. This seemed to accomplish what i wanted, but less elegantly)
  6560.  
  6561.  
  6562. Thanks for your collegiality,
  6563. Sean 
  6564.  
  6565. ........................................
  6566. Sean Boisen -- sboisen@bbn.com
  6567. BBN Systems and Technologies Corporation, Cambridge MA
  6568. Disclaimer: these opinions void where prohibited by lawyers.
  6569.  
  6570. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Wed Nov 30 22:20:33 1988
  6571. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  6572.     id AA17432; Wed, 30 Nov 88 22:20:33 MST
  6573. Received: from sophist.uchicago.edu (sophist.uchicago.edu.ARPA) by sphinx.uchicago.edu (4.12/2.0Sx)
  6574.     id AA11671; Wed, 30 Nov 88 23:22:25 cst
  6575. Return-Path: <goer@sophist.uchicago.edu>
  6576. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  6577.     id AA09107; Wed, 30 Nov 88 23:13:04 CST
  6578. Date: Wed, 30 Nov 88 23:13:04 CST
  6579. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  6580. Message-Id: <8812010513.AA09107@sophist.uchicago.edu>
  6581. To: icon-group@arizona.edu
  6582. Subject: problems with tables of tables
  6583.  
  6584. I could let the big guns take this one, I suppose, and be safe.
  6585. But the answer seems obvious to me, so I'll offer some free
  6586. advice.  The problem with saying:
  6587.  
  6588.           master := table(table())
  6589.  
  6590. is that table() does not produce a table per se.  One of the nice
  6591. things about Icon is that it takes care of pointers to structures
  6592. for you.  The sometimes inconvenient byproduct of this convenience
  6593. is that, whether you know it or not, table() returns a pointer to
  6594. a structure.  That means that every time you pull out an entry value
  6595. by saying:
  6596.  
  6597.           sentence_table := master[bad_word]
  6598.  
  6599. you are yanking out a pointer to the same table.  So no matter how
  6600. many entries you add to however many keys, you'll just be adding to
  6601. the one table, since all of your values are really pointers to the
  6602. same table.  Sound confusing?  Let's put it simply:  If you ask Icon
  6603. to initialize all values in a table to "table()", you are saying
  6604. "Please initialize all values in the table you are creating to the
  6605. result of the expression 'table().'  Since "table()" creates a table,
  6606. and produces that table (i.e. a pointer to that table), every value
  6607. in your table is automatically initialized with that pointer to the
  6608. one table!
  6609.  
  6610. Fix:  Initialize entries to the default (&null, I believe), and then
  6611. every time you find a new bad_word, check to see if its value in the
  6612. table is &null.  If so, add a copy of an empty table to the table
  6613. ("copy(table())").  That will be unique.  Also, please don't try
  6614.  
  6615.           master := table(copy(table()))
  6616.  
  6617. or you'll be in for the same problem you started with.  I'm afraid that
  6618. a copy of a table is as unique as the original table.  You need to add
  6619. a new table each time you encounter a new bad_word.
  6620.  
  6621. Did this help?  Would any of the wizards care to add anything?
  6622.  
  6623.                                         -Richard L. Goerwitz
  6624.                                         goer@sophist.uchicago.edu
  6625.                                         rutgers!oddjob!gide!sophist!goer
  6626.  
  6627. From att!ihuxy!nowlin  Thu Dec  1 07:33:37 1988
  6628. From: att!ihuxy!nowlin
  6629. Message-Id: <8812011433.AA03187@megaron.arizona.edu>
  6630. Received: by megaron.arizona.edu (5.59-1.7/14)
  6631.     id AA03187; Thu, 1 Dec 88 07:33:37 MST
  6632. Received: by att.ATT.COM (smail2.6 - att-cb)
  6633.     id AA26757; 1 Dec 88 09:30:00 EST (Thu)
  6634. Message-Version: 2
  6635. >To: /addr=att!arizona!icon-group
  6636. Date: Thu 01 Dec 1988 08:30 CST
  6637. End-Of-Header: 
  6638. Email-Version: 2
  6639. X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
  6640. To: att!arizona!icon-group
  6641. Subject: Re: problems with tables of tables
  6642. Ua-Message-Id: <post.nowlin.Thu 01 Dec 1988 07:31 CST>
  6643. End-Of-Protocol: 
  6644. Content-Length: 2828
  6645.  
  6646. > From: Sean Boisen <sboisen@REGULUS.BBN.COM>
  6647. > ...
  6648. > My idea was to have a master table, whose entries would be "bad" words:
  6649. > then the value of each entry would be itself a table, with entries
  6650. > being the sentence number and values the sentence text. So i tried a
  6651. > piece of code something like this (irrelevant details omitted):
  6652. > procedure main()
  6653. >    initial master := table(table())
  6654.  
  6655. This line creates a table called master with the property that every new
  6656. entry value will be initialized to a pointer to the same table.  That's why
  6657. this happens:
  6658.  
  6659. > ... This doesn't work, however: the best was i can describe the
  6660. > failure is that sentence_table maintains the same value across
  6661. > different values of bad_word, in other words it accumulates ALL
  6662. > sentences, not just those specific to this particular bad_word.
  6663.  
  6664. The initial assignment in this group just points sentence_table at this
  6665. shared table.  That's why any given bad_word entry value generates the
  6666. same results as another.  In fact, if this worked the way you wanted, the
  6667. final assignment back to the master table would be redundant.
  6668.  
  6669. >        sentence_table := master[bad_word]
  6670. >        sentence_table[number] := sentence
  6671. >        master[bad_word] := sentence_table
  6672.  
  6673. The workaround you used looks like the best way to do what you want and
  6674. isn't less elegant as far as I can tell.
  6675.  
  6676. > (by the way, the workaround i used was to keep a separate table of
  6677. > "found" bad_words, and if the bad_word wasn't there, explicitly assign
  6678. > a new table to sentence_table, i.e.
  6679. >     sentence_table := table()
  6680. > This seemed to accomplish what i wanted, but less elegantly)
  6681.  
  6682. I'd try using a set of bad words instead of a table and then you can just
  6683. test to see if you've created a table for a given bad word by using the
  6684. member() built-in function.  For example, I took the original code posted
  6685. and came up with the following program.  I added some extra code to make it
  6686. functional since I don't like to post things I haven't actually run.  I
  6687. hope this helps.
  6688.  
  6689. procedure main()
  6690.  
  6691.    master := table()
  6692.    bad_set := set([])
  6693.    number := 0
  6694.    
  6695.    while (line := read()) do 
  6696.    {
  6697.        # I imagined this code to assign to sentence and number
  6698.        number +:= 1
  6699.        sentence := line
  6700.  
  6701.        if bad_word := get_bad_word(line) then
  6702.        {
  6703.        if not member(bad_set,bad_word) then 
  6704.          master[bad_word] := table() & insert(bad_set,bad_word)
  6705.        master[bad_word][number] := sentence
  6706.        }
  6707.    }
  6708.  
  6709.    # added this to test
  6710.    every bw := !bad_set do {
  6711.     write("Bad Word: ",bw)
  6712.     every s := !sort(master[bw]) do
  6713.         write("  sentence ",right(s[1],3)," = '",s[2],"'")
  6714.    }
  6715.  
  6716. end
  6717.  
  6718. # added this to test
  6719. procedure get_bad_word(l)
  6720.  
  6721.     static    words
  6722.     initial    words := &ucase ++ &lcase ++ &digits
  6723.  
  6724.     l ? {
  6725.         tab(upto(words))
  6726.         w := tab(many(words))
  6727.     }
  6728.  
  6729.     return \w
  6730. end
  6731.  
  6732. Jerry Nowlin
  6733. (...!att!ihuxy!nowlin)
  6734.  
  6735. From sboisen@REGULUS.BBN.COM  Thu Dec  1 07:58:10 1988
  6736. Message-Id: <8812011458.AA03618@megaron.arizona.edu>
  6737. Received: from REGULUS.BBN.COM by megaron.arizona.edu (5.59-1.7/14) via SMTP
  6738.     id AA03618; Thu, 1 Dec 88 07:58:10 MST
  6739. To: goer <@bbn.com:goer@sophist.uchicago.edu>
  6740. Cc: icon-group@arizona.edu
  6741. In-Reply-To: Richard Goerwitz's message of Wed, 30 Nov 88 23:13:04 CST <8812010513.AA09107@sophist.uchicago.edu>
  6742. Subject: problems with tables of tables
  6743. From: Sean Boisen <sboisen@REGULUS.BBN.COM>
  6744. Sender: sboisen@REGULUS.BBN.COM
  6745. Reply-To: sboisen@bbn.com
  6746. Date: Thu, 1 Dec 88 9:49:14 EST
  6747.  
  6748.  
  6749. I'm glad the answer was obvious to Richard: it certainly wasn't to
  6750. me! If i've understood his explanation correctly the following rewrite
  6751. of the original should work:
  6752.  
  6753. procedure main()
  6754.  
  6755.    initial master := table(table())
  6756.    
  6757.    while (line := read()) do 
  6758.    {
  6759.        # imagine some code here that assigns to sentence and number
  6760.        # .....
  6761.  
  6762.        if bad-word := get_bad_word(line) then
  6763.        {
  6764.        #### previously: sentence_table := master[bad_word]
  6765.        sentence_table := ( \master[bad_word] | table() )
  6766.        sentence_table[number] := sentence
  6767.        master[bad_word] := sentence_table
  6768.        }
  6769.    }
  6770. end
  6771.  
  6772. I haven't actually tried this, but it looks superficially correct
  6773. given Richard's comments. 
  6774.  
  6775. Two last points: 
  6776.  
  6777. i've used table() instead of copy(table()), mostly because i couldn't
  6778. see what the extra copy would buy me (have i missed the point here?
  6779. would it be different if i used something like table([]) or table(0)
  6780. instead?).
  6781.  
  6782. extra credit for you conciseness fanatics, can the three lines inside
  6783. the 'if' be combined somehow? 
  6784.  
  6785.  
  6786. Thanks for the help,
  6787. Sean
  6788.  
  6789. ........................................
  6790. Sean Boisen -- sboisen@bbn.com
  6791. BBN Systems and Technologies Corporation, Cambridge MA
  6792. Disclaimer: these opinions void where prohibited by lawyers.
  6793.  
  6794. From R.J.Hare@EDINBURGH.AC.UK  Thu Dec  1 12:54:37 1988
  6795. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  6796.     id AA15977; Thu, 1 Dec 88 12:54:37 MST
  6797. Received: from UKACRL.BITNET by rvax.ccit.arizona.edu; Tue, 29 Nov 88 10:12 MST
  6798. Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 4375; Tue,
  6799.  29 Nov 88 16:58:11 GMT
  6800. Date: 29 Nov 88  16:58:56 gmt
  6801. From: R.J.Hare@EDINBURGH.AC.UK
  6802. Subject: writing the name of an open file to another file
  6803. To: icon-group@arizona.edu
  6804. Via:        000015000048.FTP.MAIL; 29 NOV 88 16:58:07 GMT
  6805. Message-Id: <29 Nov 88  16:58:56 gmt  340785@EMAS-A>
  6806.  
  6807. I want to write the name of one file to another file, ie: I have something
  6808. like:
  6809.  
  6810. write(file1,s1,s2,s3,s4,file2,s5,s6,s7...)
  6811.  
  6812. The problem is that at the time of writing, file2 is open, so that instead of
  6813. the *name* of file2 being written to file1, followed by s5, etc., I am getting
  6814. s5, etc. written to file2.
  6815.  
  6816. Does anyone have any idea how I can do this without closing file2 prior
  6817. to the write statement?
  6818.  
  6819. Thanks.
  6820.  
  6821. Roger Hare.
  6822.  
  6823. From ralph  Thu Dec  1 13:12:27 1988
  6824. Date: Thu, 1 Dec 88 13:12:27 MST
  6825. From: "Ralph Griswold" <ralph>
  6826. Message-Id: <8812012012.AA17300@megaron.arizona.edu>
  6827. Received: by megaron.arizona.edu (5.59-1.7/14)
  6828.     id AA17300; Thu, 1 Dec 88 13:12:27 MST
  6829. To: R.J.Hare@EDINBURGH.AC.UK, icon-group@arizona.edu
  6830. Subject: Re:  writing the name of an open file to another file
  6831. In-Reply-To: <29 Nov 88  16:58:56 gmt  340785@EMAS-A>
  6832.  
  6833. A value of type file in Icon has no specific relationship to the string
  6834. name of the file you used to create it.  The thing to do is to keep
  6835. both the name and the file around.  If you don't know what they are
  6836. specifically, you could use a table to look up the name, given the file.
  6837.  
  6838. In the simple case, do something like
  6839.  
  6840.     file := open(filename, ...)
  6841.  
  6842. and do
  6843.  
  6844.     write(s1,s2, ...,filename, ...)
  6845.  
  6846. In the case you don't know specifically what the name of the file is,
  6847. do
  6848.  
  6849.     filetable := table()
  6850.         .
  6851.         .
  6852.         .
  6853.     file := open(filename, ...)
  6854.     filetable[file] := filename
  6855.         .
  6856.         .
  6857.         .
  6858.     write(s1,s2, ...,filetable[file], ...)
  6859.  
  6860.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  6861.    +1 602 621 6609   ralph@Arizona.EDU  {uunet|allegra|noao}!arizona!ralph
  6862.  
  6863.  
  6864. From gudeman  Thu Dec  1 13:58:05 1988
  6865. Date: Thu, 1 Dec 88 13:58:05 MST
  6866. From: "David Gudeman" <gudeman>
  6867. Message-Id: <8812012058.AA19836@megaron.arizona.edu>
  6868. Received: by megaron.arizona.edu (5.59-1.7/14)
  6869.     id AA19836; Thu, 1 Dec 88 13:58:05 MST
  6870. To: icon-group@arizona.edu
  6871. In-Reply-To: <8812012012.AA17300@megaron.arizona.edu>
  6872. Subject:  getting the name of a file
  6873.  
  6874. Ralph suggested that if you want to know the name of a file, you can
  6875. keep it around in a table or a seperate variable.  This is the most
  6876. efficient way to handle the problem, but there is a way to get the
  6877. name of a file if you haven't kept track of it:
  6878.  
  6879.    f := open(fname, mode)
  6880.    write(image(f)[6:-1])
  6881.  
  6882. will write out fname.
  6883.  
  6884. If a file f has been created with open(), then the expression image(f)
  6885. will produce the string "file(fname)", where fname is the name of the
  6886. file.  This doesn't work for the built-in files: &input, et. al., so
  6887. you may want to include a check for those.
  6888.  
  6889. From kwalker  Thu Dec  1 14:57:32 1988
  6890. Date: Thu, 1 Dec 88 14:57:32 MST
  6891. From: "Kenneth Walker" <kwalker>
  6892. Message-Id: <8812012157.AA24031@megaron.arizona.edu>
  6893. Received: by megaron.arizona.edu (5.59-1.7/14)
  6894.     id AA24031; Thu, 1 Dec 88 14:57:32 MST
  6895. In-Reply-To: <8812011458.AA03618@megaron.arizona.edu>
  6896. To: icon-group
  6897. Subject: Re:  problems with tables of tables
  6898.  
  6899. > From: Sean Boisen <sboisen@REGULUS.BBN.COM>
  6900. > Date: Thu, 1 Dec 88 9:49:14 EST
  6901. > I'm glad the answer was obvious to Richard: it certainly wasn't to
  6902. > me! 
  6903.  
  6904. You have just run into one of the classical Icon programming errors. For
  6905. those of us who have made the mistake ourselves and seen others make it,
  6906. it has become easy to spot.
  6907.  
  6908. > procedure main()
  6909. >    initial master := table(table())
  6910.  
  6911. you want
  6912.  
  6913.    master := table()
  6914.  
  6915. or if you want to be explicit about the default value
  6916.  
  6917.    master := table(&null)
  6918.  
  6919. [rest of program deleted]
  6920.  
  6921. > i've used table() instead of copy(table()), mostly because i couldn't
  6922. > see what the extra copy would buy me (have i missed the point here?
  6923.  
  6924. You are correct; the copy is not needed.
  6925.  
  6926. > extra credit for you conciseness fanatics, can the three lines inside
  6927. > the 'if' be combined somehow? 
  6928.  
  6929. when faced with this problem, I use code something like
  6930.  
  6931.    /master[bad_word] := table()
  6932.    master[bad_word][number] := sentence
  6933.  
  6934. With strategically placed parentheses and an alternation, I belive this
  6935. can be combined on one line, but I wouldn't call it good programming
  6936. style. Does anyone see an elagant "one liner"?
  6937.  
  6938.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  6939.    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  6940.  
  6941. From @uxc.cso.uiuc.edu:willr@ncsa.uiuc.edu  Thu Dec  1 15:18:51 1988
  6942. Received: from UXC.CSO.UIUC.EDU by megaron.arizona.edu (5.59-1.7/14) via SMTP
  6943.     id AA25393; Thu, 1 Dec 88 15:18:51 MST
  6944. Received: from pluto.ncsa.uiuc.edu by uxc.cso.uiuc.edu with SMTP
  6945.     (5.60+/IDA-1.2.5) id AA25446; Thu, 1 Dec 88 16:17:29 CST
  6946. Return-Path: <willr@ncsa.uiuc.edu>
  6947. Received: by pluto.ncsa.uiuc.edu (4.0/NCSA-1.2)
  6948.     id AA01345; Thu, 1 Dec 88 16:20:22 CST
  6949. Date: Thu, 1 Dec 88 16:20:22 CST
  6950. From: willr@ncsa.uiuc.edu (Will Ridenour)
  6951. Message-Id: <8812012220.AA01345@pluto.ncsa.uiuc.edu>
  6952. To: icon-group@arizona.edu
  6953. Subject: writing a file name to another file
  6954. Cc: willr@pluto.ncsa.uiuc.edu
  6955.  
  6956.  
  6957.     :Date: 29 Nov 88  16:58:56 gmt
  6958.     :From: R.J.Hare@EDINBURGH.AC.UK
  6959.     :Subject: writing the name of an open file to another file
  6960.     :
  6961.     :I want to write the name of one file to another file, ie: I 
  6962.     :have something like:
  6963.     : 
  6964.     :write(file1,s1,s2,s3,s4,file2,s5,s6,s7...)
  6965.     : 
  6966.     :The problem is that at the time of writing, file2 is open, 
  6967.     :so that instead of the *name* of file2 being written to 
  6968.     :file1, followed by s5, etc., I am getting s5, etc. written 
  6969.     :to file2.
  6970.     : 
  6971.     :Does anyone have any idea how I can do this without 
  6972.     :closing file2 prior to the write statement?
  6973.     : 
  6974.     :Thanks.
  6975.     : 
  6976.     :Roger Hare.
  6977.  
  6978.  
  6979. please don't be offended.  this is rather like asking "is is plugged in?"
  6980. but any successful troubleshooter checks the plug first and the power
  6981. switch next.
  6982.  
  6983. the question is where does the variable file2 come from?  If it's a
  6984. string like file2 := "foo" then someone else will have to check the
  6985. power switch for you.
  6986.  
  6987. but if the value for file2 came from something like:
  6988.  
  6989. file2 := open("foo","rw") then the value of your variable file2 is not
  6990. a filename at all but a file descriptor (pointer/handle, whatever).  &
  6991. my understanding of icon is that if you pass write() a file descriptor
  6992. it will try to write something to that file.
  6993.  
  6994. otherwise unless there is something i don't know  about icon (& there
  6995. is a lot) your example should work as you intended.
  6996.  
  6997. will ridenour
  6998. national center for supercomputing applications
  6999. University of Illinois
  7000. Champaign, Illinois   willr@ncsa.uiuc.edu (internet) 792@ncsavmsa (bitnet)
  7001.  
  7002.  
  7003. From nolan@umbc3.UMD.EDU  Tue Dec  6 20:34:57 1988
  7004. Received: from umbc3.umd.edu by megaron.arizona.edu (5.59-1.7/14) via SMTP
  7005.     id AA20175; Tue, 6 Dec 88 20:34:57 MST
  7006. Received: by umbc3.UMD.EDU (5.54/umd.04)
  7007.         for icon-group@arizona.edu id AA04939; Tue, 6 Dec 88 22:33:01 EST
  7008. Date: Tue, 6 Dec 88 22:33:01 EST
  7009. From: Mr. John Nolan (NSA) <nolan@umbc3.UMD.EDU>
  7010. Message-Id: <8812070333.AA04939@umbc3.UMD.EDU>
  7011. To: icon-group@arizona.edu
  7012. Subject: Some Icon problems with SunOS 4.0
  7013.  
  7014.  
  7015. I just tried to recompile Icon Version 7 on a Sun 3/280 under SunOS 4.0
  7016. and ran into 2 problems.
  7017.  
  7018. Firstly, the value of MaxHdr (in define.h) had to be increased to 20000
  7019. in order not to get completely fatal run time errors.
  7020.  
  7021. Secondly, several tests (i.e. expr74, expr76, expr79, and expr11) have
  7022. one line which gives incorrect results.
  7023.  
  7024. Since SunOS 4.0 has been shown to be brain damaged enough to prompt Sun
  7025. to bring out a SunOS 4.0.1 (containing mostly bug fixes), I am not
  7026. quite worried about these problems (yet), but subtle bugs in code that
  7027. you are running may be explained by the above. Please note that these
  7028. problems do not appear when running SunOS 3.5. Also the source is original
  7029. version7 source and may have been fixed in the new Version 7.5.
  7030.  
  7031. I will (soon) install the new OS and will report results. If anyone has
  7032. a temporary workaround, please let me know.
  7033.  
  7034. John Nolan
  7035. nolan@umbc3.umd.edu
  7036.  
  7037. From dscargo@cim-vax.honeywell.com  Thu Dec  8 08:46:46 1988
  7038. Message-Id: <8812081546.AA21978@megaron.arizona.edu>
  7039. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7040.     id AA21978; Thu, 8 Dec 88 08:46:46 MST
  7041. Date: 7 Dec 88 14:48:00 CST
  7042. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  7043. Subject: Binary input for Icon
  7044. To: "icon-group" <icon-group@arizona.edu>
  7045.  
  7046. Having gotten to the point where I like to used Icon for everything, I've
  7047. wondered about using Icon for doing things like reading TIFF and various
  7048. flavors of PAINT file formats.  What I don't know is how to read binary files,
  7049. especially files containing 1 byte, 2 byte, and 4 byte integer quantities.
  7050. This may be another dumb idea on my part.   Has there been any thought
  7051. given to reading files containing only binary and no character data?  (I
  7052. suppose I'm trying to avoid learning to write C programs, where I've got to
  7053. allocate memory and manage pointers myself.)
  7054.  
  7055. I suppose I could write an Icon program that does a binary to hex conversion,
  7056. and then uses that as input to another program, but I'd rather avoid that.
  7057.  
  7058. I suppose I'd like to have binary objects that are indexed only by integer
  7059. indices. To create TIFF files, having the ability to do sublists, sorting
  7060. (of binary data), and concatenation of binary objects would be very handy.
  7061.  
  7062. David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
  7063.  
  7064.  
  7065. From gmt  Fri Dec  9 13:45:10 1988
  7066. Date: Fri, 9 Dec 88 13:45:10 MST
  7067. From: "Gregg Townsend" <gmt>
  7068. Message-Id: <8812092045.AA03853@megaron.arizona.edu>
  7069. Received: by megaron.arizona.edu (5.59-1.7/15)
  7070.     id AA03853; Fri, 9 Dec 88 13:45:10 MST
  7071. To: icon-group
  7072. Subject: Re: Binary input for Icon
  7073.  
  7074. Icon doesn't provide specific functions for binary input or output.
  7075. It can be done on most systems using other builtin functions, though
  7076. it is a bit tedious.
  7077.  
  7078. The builtin function reads(f,i) reads exactly n bytes from file f,
  7079. giving no special interpretation to newlines or nulls or anything else.
  7080. Ord(s) converts a byte to its integer value, and multibyte integers
  7081. can be built using ishift(i,j) and ior(i,j).
  7082.  
  7083. Output can be done similarly, breaking integers into 8-bit values using
  7084. ishift(i,j) and iand(i,16rFF), then converting to character using char(i).
  7085.  
  7086. seek(f,i)  will also be useful for reading TIFF files;  keep in mind that
  7087. Icon numbers the bytes of a file beginning at 1 and not 0.
  7088.  
  7089.     Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  7090.     +1 602 621 4325      gmt@Arizona.EDU       110 57 16 W / 32 13 45 N / +758m
  7091.  
  7092. From sunquest!whm  Wed Dec 14 21:56:52 1988
  7093. Received: by megaron.arizona.edu (5.59-1.7/15)
  7094.     id AA12192; Wed, 14 Dec 88 21:56:52 MST
  7095. Date: Wed, 14 Dec 88 21:54:01 MST
  7096. From: "Bill Mitchell" <sunquest!whm>
  7097. Message-Id: <8812150454.AA25146@sunquest>
  7098. Received: by sunquest; Wed, 14 Dec 88 21:54:01 MST
  7099. To: arizona!icon-group
  7100. Subject: Re:  Binary input for Icon
  7101.  
  7102. I once did some lobbying for ord() and char() to be able to handle multibyte
  7103. quantities, but I was unable to generate any support for my position.  I still
  7104. think it makes sense.
  7105. --------------------------------------------------------------------
  7106. Bill Mitchell                whm@sunquest.com
  7107. Sunquest Information Systems        sunquest!whm@arizona.edu
  7108. Tucson, AZ                 {arizona,uunet}!sunquest!whm
  7109. 602-885-7700
  7110.  
  7111.  
  7112. From alk@ux.acss.umn.edu  Thu Dec 15 00:12:15 1988
  7113. Message-Id: <8812150712.AA18448@megaron.arizona.edu>
  7114. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7115.     id AA18448; Thu, 15 Dec 88 00:12:15 MST
  7116. Return-Path: alk@ux.acss.umn.edu
  7117. Received: from UMNACVX.BITNET by rvax.ccit.arizona.edu; Thu, 15 Dec 88 00:14 MST
  7118. Received: from ux.acss.umn.edu by UMNACVX.BITNET; Thu, 15 Dec 88 01:04 CST
  7119. Date: Thu, 15 Dec 88 1:06:48 CST
  7120. From: alk@ux.acss.umn.edu
  7121. Subject: Re:  Re:  Binary input for Icon
  7122. Sender: alk@ux.acss.umn.edu
  7123. To: icon-group@arizona.edu
  7124.  
  7125. Well, M. Mitchell, here's one voice of support for your position.
  7126. --------------
  7127. Anthony L. Kimball, U of Mn Academic Computing Services and Systems.
  7128. alk@ux.acss.umn.edu   alk@UMNACVX
  7129.  
  7130. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Thu Dec 15 09:16:37 1988
  7131. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7132.     id AA10076; Thu, 15 Dec 88 09:16:37 MST
  7133. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  7134.     id AA14349; Thu, 15 Dec 88 10:19:28 CST
  7135. Return-Path: <goer@sophist.uchicago.edu>
  7136. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  7137.     id AA02852; Thu, 15 Dec 88 10:09:11 CST
  7138. Date: Thu, 15 Dec 88 10:09:11 CST
  7139. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  7140. Message-Id: <8812151609.AA02852@sophist.uchicago.edu>
  7141. To: icon-group@arizona.edu
  7142. Subject: char(), ord()
  7143.  
  7144. Let's think about this.
  7145.  
  7146. Just how would one go about constructing a char() or ord()
  7147. that handled whole strings?  First of all, it would need to
  7148. be a generator, that is, if we desire self-consistency within
  7149. the language.  It would be kind of like:
  7150.  
  7151.       every ord(!s)
  7152.  
  7153. Instead, you'd write -
  7154.  
  7155.       every ord(s)
  7156.  
  7157. The problem is that ord() acts logically on one character.
  7158. It's not like find() or upto(), but rather like any().  And
  7159. it makes little sense to make an any() that hops through strings,
  7160. one character at a time.  If it did, you'd have to use limit-
  7161. ation expressions every time you wanted to check the first char-
  7162. acter in a line!
  7163.  
  7164. I suppose one could have char() or ord() return several words
  7165. at once, all jammed together.  I.e. it could return the binary
  7166. value of strings, with the bits strung out into one long chain.
  7167. But isn't this a bit exotic, especially since most people are
  7168. going to be using the data one char or word at a time?  And besides,
  7169. what would the type of the result be?  Would it be a huge in-
  7170. teger?  A string?  And what of the reverse?  If you go from binary
  7171. to character, where do you divide bits?  I mean, how does Icon
  7172. know that the machine it's running on has a sixteen or thirty-two
  7173. bit word?  This whole idea seems a bit outlandish to me.  And since
  7174. it's no trouble to write "every ord(!s)" instead of "every ord(s)",
  7175. why change things - especially when one logically expects ord() and
  7176. char() to operate on short integers and characters individually?
  7177.  
  7178. Actually, now that I think about it, there have been times where
  7179. I would have liked to manipulate long strings of 0's and 1's
  7180. (e.g. when decoding Huffmon-encoded materials).  Maybe this will
  7181. seem silly, but I would have liked the R one uses in specifying
  7182. radix literals to act like an infix operator, so I could convert
  7183. integers to base two, and then ask Icon to convert the result to
  7184. a string.
  7185.  
  7186. I do hope that some of the icon-project folks will enlighten me
  7187. on some of these points, since I am probably only demonstrating
  7188. ignorance here.
  7189.  
  7190.                                         -Richard L. Goerwitz
  7191.                                         goer@sophist.uchicago.edu
  7192.                                         rutgers!oddjob!gide!sophist!goer
  7193.  
  7194. From sunquest!whm  Thu Dec 15 11:26:33 1988
  7195. Received: by megaron.arizona.edu (5.59-1.7/15)
  7196.     id AA19584; Thu, 15 Dec 88 11:26:33 MST
  7197. Date: Thu, 15 Dec 88 11:23:44 MST
  7198. From: "Bill Mitchell" <sunquest!whm>
  7199. Message-Id: <8812151823.AA27228@sunquest>
  7200. Received: by sunquest; Thu, 15 Dec 88 11:23:44 MST
  7201. To: arizona!icon-group
  7202. Subject: Re:  char(), ord()
  7203.  
  7204. For strings that represent more bits than Icon can hold in an integer,
  7205. multibyte char() and ord() are hard to imagine; I was thinking in terms
  7206. of char and ord handling 2- and 4-byte quantities.  So for example, ord("ABCD")
  7207. would return an integer and char(ord("ABCD"),4) would return "ABCD".  One
  7208. problem is how to deal with the byte ordering differences in little-endian
  7209. and big-endian machines.  The thing that seems most natural to me is to
  7210. have char() and ord() do what's natural on a machine by machine basis.
  7211. For example, on the VAX, ord("\x00\x00\x00\x01") would return 16777216, but
  7212. on the Sun it would return 1.
  7213.  
  7214. An optional argument could be used to explicitly specify big- or little-endian
  7215. interpretation.
  7216.  
  7217. I think this is a natural extension of char and ord and a big time-saver:
  7218. you need 10 procedure calls of ord, ior, and ishift (according to my count)
  7219. to do the equivalent of ord("ABCD").
  7220.  
  7221. From munck@mbunix.mitre.org  Mon Dec 19 15:05:19 1988
  7222. Received: from MBUNIX.MITRE.ORG by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7223.     id AA18194; Mon, 19 Dec 88 15:05:19 MST
  7224. Posted-From: The MITRE Corp., Bedford, MA
  7225. X-Alternate-Route: user%node@mbunix.mitre.org
  7226. To: ICON-Group@arizona.edu
  7227. Reply-To: munck@mbunix.mitre.org, munck@MITRE.ARPA
  7228. Return-Receipt-To: munck@mbunix.mitre.org
  7229. Subject: ICON as user customization language
  7230. Date: Mon, 19 Dec 88 17:04:42 EST
  7231. Message-Id: <8632.598572282@mbunix>
  7232. From: Bob Munck <munck@mbunix.mitre.org>
  7233.  
  7234. After two decades, I'm interested in continuing the Hypertext work
  7235. we started at Brown.  In particular, I want to look into hypertext-like
  7236. asynchronous teleconferencing over the Internet.  As an enthusastic user
  7237. of Final Word/SPRINT, I'm much taken with the idea of building interactive
  7238. systems around an underlying and user-accessible programming language,
  7239. in the way that the original EMACS was built around LISP and SPRINT is
  7240. built around <strange internal language>.
  7241.  
  7242. It seems to me that ICON would be ideal as the internal language of
  7243. a hypertext system, since most of the work is character processing.  Has
  7244. ICON ever been used this way?  That is, I'd implement the hypertext
  7245. support in ICON, but also allow users to modify and add to the program.
  7246. The structure would probably involve attaching routines to individual
  7247. key-presses, as in EMACS.  I'd appreciate any comments on the idea
  7248. and pointers to existing work.
  7249.  
  7250.                       -- Bob <Munck@mitre.org>, ..!linus!munck,
  7251.                       -- MITRE Corporation, 617/271-3671
  7252.  
  7253. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Thu Dec 22 21:33:54 1988
  7254. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7255.     id AA13040; Thu, 22 Dec 88 21:33:54 MST
  7256. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  7257.     id AA26752; Thu, 22 Dec 88 22:37:10 CST
  7258. Return-Path: <goer@sophist.uchicago.edu>
  7259. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  7260.     id AA02158; Thu, 22 Dec 88 22:26:26 CST
  7261. Date: Thu, 22 Dec 88 22:26:26 CST
  7262. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  7263. Message-Id: <8812230426.AA02158@sophist.uchicago.edu>
  7264. To: icon-group@arizona.edu
  7265. Subject: move(1) vs. |move(1)
  7266.  
  7267.  
  7268. (Naive?) question:  Why are
  7269.      
  7270.         while move(1) do { ...
  7271.  
  7272. and
  7273.  
  7274.         every |move(1) do {
  7275.  
  7276. not equivalent?
  7277.  
  7278.                                         -Richard L. Goerwitz
  7279.                                         goer@sophist.uchicago.edu
  7280.                                         rutgers!oddjob!gide!sophist!goer
  7281.  
  7282. From ralph  Thu Dec 22 22:20:25 1988
  7283. Date: Thu, 22 Dec 88 22:20:25 MST
  7284. From: "Ralph Griswold" <ralph>
  7285. Message-Id: <8812230520.AA14228@megaron.arizona.edu>
  7286. Received: by megaron.arizona.edu (5.59-1.7/15)
  7287.     id AA14228; Thu, 22 Dec 88 22:20:25 MST
  7288. To: goer@sophist.uchicago.edu, icon-group@arizona.edu
  7289. Subject: Re:  move(1) vs. |move(1)
  7290. In-Reply-To: <8812230426.AA02158@sophist.uchicago.edu>
  7291.  
  7292. The argument of while is "bounded" -- suspended generators
  7293. are discarded.
  7294.  
  7295. If that sounds mystical, don't be put down.  Your question
  7296. touches the heart of expression evaluation in Icon.  Described
  7297. properly (which I'm not prepared to do here), it's all "obvious".
  7298.  
  7299.    Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  7300.    +1 602 621 6609   ralph@Arizona.EDU  {uunet|allegra|noao}!arizona!ralph
  7301.  
  7302.  
  7303. From ralph  Fri Dec 23 05:27:52 1988
  7304. Date: Fri, 23 Dec 88 05:27:52 MST
  7305. From: "Ralph Griswold" <ralph>
  7306. Message-Id: <8812231227.AA25510@megaron.arizona.edu>
  7307. Received: by megaron.arizona.edu (5.59-1.7/15)
  7308.     id AA25510; Fri, 23 Dec 88 05:27:52 MST
  7309. To: goer@sophist.uchicago.edu
  7310. Subject: Re:  move(1) vs. |move(1)
  7311. Cc: icon-group
  7312. In-Reply-To: <8812230535.AA02229@sophist.uchicago.edu>
  7313.  
  7314. The information is in the Icon book, but not in a very obvious way.
  7315.  
  7316. The point is this:  move(1) increments &pos, but it suspends (like
  7317. find(s)).  It does this not so that it can produce another result if it's
  7318. resumed (there is only one way to increment &pos by 1), -- but rather to
  7319. restore &pos to its previous position (data backtracking).  See p. 126 in
  7320. the Icon book.
  7321.  
  7322. On other hand, the control clause of while-do is bounded (that particular
  7323. term is not used in the Icon book -- see p. 119).  In a bounded expression,
  7324. suspended generators are discarded, once a result is produced.  Thus, in
  7325.  
  7326.    while move(1) do ...
  7327.  
  7328. the change to &pos by move(1) is irreversible, since move(1) can't be resumed.
  7329.  
  7330. In every-do, on the other hand, the control clause is not bounded -- in fact,
  7331. the control clause must be able to generate a sequence of results for every-do
  7332. to have the effect it does.  Thus, in
  7333.  
  7334.    every |move(1) do ...
  7335.  
  7336. move(1) is resumed after the do clause is evaluated.  It restores &pos, and
  7337. then repeated alternation causes move(1) to be evaluated again, with the same
  7338. value of &pos as before -- an endless loop.
  7339.  
  7340. The problem in understanding this probably is not in what while-do does --
  7341. most folks find that to be what they expect.  It's in every-do that the
  7342. problem with understanding arises.  A simple prescription that will do
  7343. for most cases is "don't use every-do in string scanning". That may keep you
  7344. out of trouble, but a deeper understanding of expression evalation in 
  7345. Icon will show you both why you usually don't want to use every-do in
  7346. string scanning and also why you sometimes might want to.
  7347.  
  7348. Quiz:  Assuming s := "Hello world!", what does the following expression
  7349. write?
  7350.  
  7351.     every write(s ? move(1 to 10))
  7352.  
  7353.  
  7354.  
  7355. cd
  7356.  
  7357. From @sphinx.uchicago.edu:goer@sophist.uchicago.edu  Fri Dec 23 08:20:44 1988
  7358. Received: from sphinx.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7359.     id AA01434; Fri, 23 Dec 88 08:20:44 MST
  7360. Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
  7361.     id AA05554; Fri, 23 Dec 88 09:24:09 CST
  7362. Return-Path: <goer@sophist.uchicago.edu>
  7363. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  7364.     id AA02632; Fri, 23 Dec 88 09:13:23 CST
  7365. Date: Fri, 23 Dec 88 09:13:23 CST
  7366. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  7367. Message-Id: <8812231513.AA02632@sophist.uchicago.edu>
  7368. To: icon-group@arizona.edu
  7369. Subject: matching expressions
  7370.  
  7371. The real key to my understanding the difference between
  7372.  
  7373.       while move(1)
  7374.  
  7375. and
  7376.  
  7377.       every |move(1)
  7378.  
  7379. was the realization that move(1) acts like the matching expressions des-
  7380. cribed on page 158-9 in the Icon book.  In other words, one of the things
  7381. it does is to restore &pos to its original value if resumed.  In the ex-
  7382. pression
  7383.  
  7384.        every |move(1)
  7385.  
  7386. move(1) is repeatedly resumed.  And each time this happens, the value of
  7387. &pos is restored.  Hence an infinite loop results.  With while move(1),
  7388. on the other hand, no resumption occurs.  As Ralph Griswold explained it,
  7389. the result sequence is discarded, and &pos keeps its new value.
  7390.  
  7391.      As for what
  7392.  
  7393.       every write("Hello world." ? move(1 to 10))
  7394.  
  7395. does, we just note that "every" wants a result sequence.  The result se-
  7396. quence of "1 to 10" is the integers from 1 to 10.  Since move() will in
  7397. fact restore &pos to 1 each time it is resumed for another result, the
  7398. effect will be to write out "Hello world."[1:1] then "Hello world."[1:2],
  7399. and so on, up to "Hello world."[1:10].
  7400.  
  7401.      Many thanks to Icon's creator, Ralph Griswold, for the reply.  I had
  7402. thought that I had gotten the while/every difference nailed down.  This one
  7403. really crept up on me!  I hope that this brief exchance has helped others
  7404. out there who have gotten similarly befuddled.
  7405.  
  7406.                                         -Richard L. Goerwitz
  7407.                                         goer@sophist.uchicago.edu
  7408.                                         rutgers!oddjob!gide!sophist!goer
  7409.  
  7410. From @multimax.encore.com:pierson@mist.encore.com  Wed Dec 28 13:22:53 1988
  7411. Received: from MULTIMAX.ENCORE.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7412.     id AA09020; Wed, 28 Dec 88 13:22:53 MST
  7413. Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
  7414.     id AA00293; Wed, 28 Dec 88 15:21:38 EST
  7415. Received: from localhost by mist. (4.0/SMI-4.0)
  7416.     id AA10030; Wed, 28 Dec 88 15:21:36 EST
  7417. Message-Id: <8812282021.AA10030@mist.>
  7418. To: icon-group@arizona.edu
  7419. Subject: Unix V7.5 Release Doc Bugs
  7420. Date: Wed, 28 Dec 88 15:21:34 EST
  7421. From: Dan L. Pierson <pierson@mist.encore.com>
  7422.  
  7423. Hi folks, 
  7424.  
  7425.     I snarfed the 7.5 release from arizona.edu and started by printing
  7426.     the docs (using psroff).  The following problems showed up
  7427.     immediately: 
  7428.  
  7429. "s.cov" is missing.
  7430.     This causes a troff fatal error.
  7431.  
  7432. TR88-6, TR88-7, TR88-41:
  7433.     troff: Can't open /usr/lib/font/devpsc/M.out
  7434. TR88-8
  7435.     troff: Can't open /usr/lib/font/devpsc/ZI.out
  7436.         Many copies of these messages, but they all print anyway.
  7437.     Can you suggest substitute fonts?  What are these fonts
  7438.     anyway? 
  7439.  
  7440.  
  7441.                                             dan
  7442.  
  7443. In real life: Dan Pierson, Encore Computer Corporation, Research
  7444. UUCP: {talcott,linus,necis,decvax}!encore!pierson
  7445. Internet: pierson@multimax.encore.com
  7446.  
  7447.  
  7448.  
  7449.