home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group89b.txt < prev    next >
Internet Message Format  |  1990-01-01  |  306KB

  1. From dscargo@cim-vax.honeywell.com  Thu Jul  6 12:12:48 1989
  2. Message-Id: <8907061912.AA12575@megaron.arizona.edu>
  3. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4.     id AA12575; Thu, 6 Jul 89 12:12:48 MST
  5. Date: 6 Jul 89 13:57:00 CST
  6. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  7. Subject: text formatter
  8. To: "icon-group" <icon-group@arizona.edu>
  9.  
  10. Anybody tried to write a text formatter in Icon?  It seems like such a
  11. natural application.     o       o
  12.                           \_____/
  13.                           /-o-o-\     _______
  14. DDDD      SSSS   CCCC    /   ^   \   /\\\\\\\\
  15. D   D    S      C        \ \___/ /  /\   ___  \
  16. D   D     SSS   C         \_   _/  /\   /\\\\  \
  17. D   D        S  C           \  \__/\   /\ @_/  /
  18. DDDDavid SSSS.   CCCCargo    \____\____\______/ DSCARGO@CIM-VAX.HONEYWELL.COM
  19.  
  20.  
  21. From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS  Fri Jul  7 11:07:04 1989
  22. Received: from mailgw.cc.umich.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  23.     id AA25361; Fri, 7 Jul 89 11:07:04 MST
  24. Received: from him1.cc.umich.edu by mailgw.cc.umich.edu (5.59/1.0)
  25.     id AA06157; Fri, 7 Jul 89 14:03:02 EDT
  26. Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Fri, 7 Jul 89 14:05:48 EDT
  27. Date: Fri, 7 Jul 89 13:13:16 EDT
  28. From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
  29. To: icon-group@arizona.edu
  30. Message-Id: <153527@Wayne-MTS>
  31. Subject: Text formatters
  32.  
  33. In response to David Cargo: I wrote a rather large and elaborate formatter in
  34. Icon about 18 months ago.  It was very ad-hoc: it simulated a subset of
  35. IBM Script/GML, with output to the Canon LBP-8 printer.  Unfortunately it's
  36. not good for anything else.
  37.  
  38. Paul Abrahams
  39.  
  40. From goer@sophist.uchicago.edu  Mon Jul 10 00:42:03 1989
  41. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  42.     id AA13457; Mon, 10 Jul 89 00:42:03 MST
  43. Received: from sophist.uchicago.edu by tank.uchicago.edu Mon, 10 Jul 89 02:41:49 CDT
  44. Return-Path: <goer@sophist.uchicago.edu>
  45. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  46.     id AA01903; Mon, 10 Jul 89 02:40:32 CDT
  47. Date: Mon, 10 Jul 89 02:40:32 CDT
  48. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  49. Message-Id: <8907100740.AA01903@sophist.uchicago.edu>
  50. To: icon-group@arizona.edu
  51. Subject: return expressions
  52.  
  53. Why doesn't the following program output "go"?
  54.  
  55. procedure main()
  56.   write(writeit())
  57. end
  58.  
  59. procedure writeit()
  60.   (return \stopit)
  61.   return "go"
  62. end
  63.  
  64. I figured that the variable stopit, being null, would
  65. cause the return expression in which it is mentioned
  66. to fail.  This would result only in expression failure,
  67. however, and not in failure of the entire procedure.
  68. I expected that control would then pass to the next
  69. return expression, which would return the string "go"
  70. - the string that would ultimately be written to the
  71. stdout by the write function in the main procedure.
  72.  
  73. It looks, however, as though the expression
  74.  
  75.   return \stopit
  76.  
  77. is the same as 
  78.  
  79.   fail
  80.  
  81. at least in this instance, where \stopit fails.
  82. Why is this so?  Why doesn't the program simply
  83. print "go"?
  84.  
  85.                                         -Richard L. Goerwitz
  86.                                         goer@sophist.uchicago.edu
  87.                                         rutgers!oddjob!gide!sophist!goer
  88.  
  89. From ralph  Mon Jul 10 05:18:43 1989
  90. Date: Mon, 10 Jul 89 05:18:43 MST
  91. From: "Ralph Griswold" <ralph>
  92. Message-Id: <8907101218.AA21612@megaron.arizona.edu>
  93. Received: by megaron.arizona.edu (5.59-1.7/15)
  94.     id AA21612; Mon, 10 Jul 89 05:18:43 MST
  95. To: goer@sophist.uchicago.edu, icon-group@arizona.edu
  96. Subject: Re:  return expressions
  97. In-Reply-To: <8907100740.AA01903@sophist.uchicago.edu>
  98.  
  99. The return expression always returns.  It returns the *outcome* of
  100. evaluating its argument.  If its argument fails, the return causes
  101. failure of the procedure invocation in which it occurs. E.g.,
  102.  
  103.     return &fail
  104.  
  105. has the same effect as
  106.  
  107.     fail
  108.  
  109.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  110.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  111.  
  112.  
  113. From naucse!sbw  Mon Jul 10 16:31:28 1989
  114. Received: by megaron.arizona.edu (5.59-1.7/15)
  115.     id AA01077; Mon, 10 Jul 89 16:31:28 MST
  116. Message-Id: <8907102139.AA04164@naucse>
  117. Date: Mon, 10 Jul 89 14:39:04 MST
  118. X-Mailer: Mail User's Shell (6.5 4/17/89)
  119. From: naucse!naucse!sbw (Steve Wampler)
  120. To: Richard Goerwitz <arizona!icon-group-sender>, arizona!icon-group
  121. Subject: Re: return expressions
  122.  
  123. On Jul 10 at  1:54, Richard Goerwitz writes:
  124. } Why doesn't the following program output "go"?
  125. } procedure main()
  126. }   write(writeit())
  127. } end
  128. } procedure writeit()
  129. }   (return \stopit)
  130. }   return "go"
  131. } end
  132. } It looks, however, as though the expression
  133. }   return \stopit
  134. } is the same as 
  135. }   fail
  136. } at least in this instance, where \stopit fails.
  137. } Why is this so?  Why doesn't the program simply
  138. } print "go"?
  139. One thing to keep in mind is that 'return' is a control regime
  140. and not an operator.  While I can see arguments for the behavior
  141. of 'return' going either way, I prefer it the way it is, as I
  142. more often write things like:
  143.  
  144.     return f(x)
  145.  
  146. where I want the current function to fail if f(x) fails.
  147.  
  148. You might see if the control regime
  149.  
  150.     suspend \stopit
  151.  
  152. fits with what you're trying to do...
  153.  
  154. -- 
  155.     Steve Wampler
  156.     {....!arizona!naucse!sbw}
  157.  
  158. From naucse!arizona!cheyenne  Mon Jul 10 20:39:34 1989
  159. Received: by megaron.arizona.edu (5.59-1.7/15)
  160.     id AA09846; Mon, 10 Jul 89 20:39:34 MST
  161. Date: Mon, 10 Jul 89 18:37:59 MST
  162. From: "Cheyenne Wills" <naucse!arizona!cheyenne>
  163. Message-Id: <8907110137.AA05891@megaron.arizona.edu>
  164. Received: by megaron.arizona.edu (5.59-1.7/15)
  165.     id AA05891; Mon, 10 Jul 89 18:37:59 MST
  166. In-Reply-To: <8907102139.AA04164@naucse>
  167. To: arizona!icon-group, arizona!icon-group-sender, naucse!sbw
  168. Subject: Re: return expressions
  169.  
  170.  
  171. >You might see if the control regime
  172. >
  173. >        suspend \stopit
  174. >
  175. >fits with what you're trying to do...
  176.  
  177. Or you might want to try:
  178.  
  179. procedure writeit()
  180.     return \stopit | "go"
  181. end
  182.  
  183. Cheyenne Wills
  184.  
  185. From goer@sophist.uchicago.edu  Wed Jul 12 14:57:01 1989
  186. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  187.     id AA18864; Wed, 12 Jul 89 14:57:01 MST
  188. Received: from sophist.uchicago.edu by tank.uchicago.edu Wed, 12 Jul 89 16:56:58 CDT
  189. Return-Path: <goer@sophist.uchicago.edu>
  190. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  191.     id AA06421; Wed, 12 Jul 89 16:55:35 CDT
  192. Date: Wed, 12 Jul 89 16:55:35 CDT
  193. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  194. Message-Id: <8907122155.AA06421@sophist.uchicago.edu>
  195. To: icon-group@arizona.edu
  196. Subject: xenix
  197.  
  198. I wonder if XENIX users reading this group might take a moment to
  199. let a soon-to-be XENIX user know what hardware they are using, and
  200. any tips I might want to know about in using Icon in this environ-
  201. ment.  I'm coming from the BSD 4.3 and MS-DOS worlds, and I'm dread-
  202. fully worried about incompatibilities and other assorted chinks in
  203. the armor of 32-bit extensions to AT busses and XENIX/386.
  204.  
  205.                                         -Richard L. Goerwitz
  206.                                         goer@sophist.uchicago.edu
  207.                                         rutgers!oddjob!gide!sophist!goer
  208.  
  209. From ralph  Thu Jul 13 16:01:47 1989
  210. Date: Thu, 13 Jul 89 16:01:47 MST
  211. From: "Ralph Griswold" <ralph>
  212. Message-Id: <8907132301.AA05866@megaron.arizona.edu>
  213. Received: by megaron.arizona.edu (5.59-1.7/15)
  214.     id AA05866; Thu, 13 Jul 89 16:01:47 MST
  215. To: icon-group
  216. Subject: Version 7.5 of Icon for the IBM 370
  217.  
  218. Version 7.5 of Icon is now available for IBM 370 computers running
  219. VM/CMS.  It should run on the IBM 30xx and 43xx families of processors
  220. and on other 370-type processors that use the VM/CMS operating system.
  221.  
  222. This system is available from the Icon project on a 1600 bpi magnetic
  223. tape.  The tape includes executables and source code (which compiles
  224. under Waterloo C 3.0 and should be easily adaptable to other production-
  225. quality C compilers).
  226.  
  227. The tape is available from
  228.  
  229.     Icon Project
  230.     Department of Computer Science
  231.     Gould-Simpson Building
  232.     The University of Arizona
  233.     Tucson, AZ   85721
  234.     USA
  235.  
  236. The cost is $30, payable by Visa, MasterCard, or check.  Checks must be in US
  237. dollars, written on a bank with a branch in the United States, and made payable
  238. to The University of Arizona.  See Icon Newsletter 30 for more information on
  239. ordering.
  240.  
  241. There is no charge for shipping in the United States and Canada.  There is
  242. a $10 charge for shipment overseas, which is by air.
  243.  
  244. This version of Icon is not available via FTP or RBBS.
  245.  
  246. Please address any questions to me, not to icon-project or icon-group.
  247.  
  248.  
  249.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  250.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  251.  
  252.  
  253. From naucse!sbw  Thu Jul 13 17:34:32 1989
  254. Received: by megaron.arizona.edu (5.59-1.7/15)
  255.     id AA11041; Thu, 13 Jul 89 17:34:32 MST
  256. Message-Id: <8907132342.AA09033@naucse>
  257. Date: Thu, 13 Jul 89 16:42:54 MST
  258. X-Mailer: Mail User's Shell (6.5 4/17/89)
  259. From: naucse!naucse!sbw (Steve Wampler)
  260. To: arizona!icon-group
  261. Subject: Anyone have Icon 7.5 on a DECstation 3100?
  262.  
  263. I guess that just about says it.  I'd appreciated hearing
  264. from anyone who has brought up Icon on a DECstation.
  265.  
  266. If no one has, I'll give it a go when I get some time, but
  267. that's going to be awhile.
  268.  
  269. -- 
  270.     Steve Wampler
  271.     {....!arizona!naucse!sbw}
  272.  
  273. From naucse!arizona!ralph  Thu Jul 13 19:42:41 1989
  274. Received: by megaron.arizona.edu (5.59-1.7/15)
  275.     id AA22025; Thu, 13 Jul 89 19:42:41 MST
  276. Date: Thu, 13 Jul 89 17:54:21 MST
  277. From: "Ralph Griswold" <naucse!arizona!ralph>
  278. Message-Id: <8907140054.AA11823@megaron.arizona.edu>
  279. Received: by megaron.arizona.edu (5.59-1.7/15)
  280.     id AA11823; Thu, 13 Jul 89 17:54:21 MST
  281. To: arizona!icon-group, naucse!sbw
  282. Subject: Re:  Anyone have Icon 7.5 on a DECstation 3100?
  283. In-Reply-To: <8907132342.AA09033@naucse>
  284.  
  285. We installed Icon on a DECstation 3100 while we had one on loan for
  286. evaluation.
  287.  
  288. We had the same problem with Ultrix as on other DEC machines (documented
  289. in earlier mail to icon-group).  Otherwise, the installation was
  290. trivial.  Gregg Townsend implemented co-expressions also (which was
  291. not so trivial).
  292.  
  293.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  294.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  295.  
  296.  
  297. From icon-group-request  Fri Jul 14 23:05:40 1989
  298. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  299.     id AA28085; Fri, 14 Jul 89 23:05:40 MST
  300. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  301.     id AA25671; Fri, 14 Jul 89 22:47:04 -0700
  302. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  303.     for icon-group@arizona.edu (icon-group@arizona.edu)
  304.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  305. Date: 15 Jul 89 05:45:59 GMT
  306. From: iris!hildum@ucdavis.ucdavis.edu  (Eric Hildum)
  307. Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
  308. Subject: LEX and YACC in/for Icon
  309. Message-Id: <4892@ucdavis.ucdavis.edu>
  310. References: <8907132342.AA09033@naucse>, <8907140054.AA11823@megaron.arizona.edu>
  311. Sender: icon-group-request@arizona.edu
  312. To: icon-group@arizona.edu
  313.  
  314. Hello there!
  315.  
  316. I have been going through some of the back issues of the Icon digest,
  317. and ran across a reference to versions of lex and yacc that would
  318. generate Icon code.  I have recently installed version 7.5 of Icon,
  319. but have not found these amoung the included contributed programs.
  320. Did these programs ever get included?  If they did, where are they? If
  321. not, does anybody have copies that they would be willing to send to
  322. me?
  323.  
  324.                 Eric Hildum
  325.                 hildum@iris.ucdavis.edu
  326.                 dehildum@ucdavis.ucdavis.edu    (Internet)
  327.                 dehildum@ucdavis.bitnet    (BITNET)
  328.                 ucbvax!ucdavis!dehildum    (uucp)
  329.  
  330. From icon-group-request  Sat Jul 15 00:22:45 1989
  331. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  332.     id AA01062; Sat, 15 Jul 89 00:22:45 MST
  333. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  334.     id AA28423; Fri, 14 Jul 89 23:47:05 -0700
  335. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  336.     for icon-group@arizona.edu (icon-group@arizona.edu)
  337.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  338. Date: 15 Jul 89 05:52:17 GMT
  339. From: iris!hildum@ucdavis.ucdavis.edu  (Eric Hildum)
  340. Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
  341. Subject: Contributed programs and version 7.5 UNIX installation
  342. Message-Id: <4893@ucdavis.ucdavis.edu>
  343. References: <8907132342.AA09033@naucse>, <8907140054.AA11823@megaron.arizona.edu>
  344. Sender: icon-group-request@arizona.edu
  345. To: icon-group@arizona.edu
  346.  
  347. Hello!
  348.  
  349. I have just recently installed version 7.5 of Icon on a Sun 3/60 Sun
  350. OS 3.5 system.  The UNIX tar file contained the ipl directory and
  351. associated programs; however, these appear to be out of date, and do
  352. not match the listings given the iplv7p1.doc file.  The iplv7p1.tar
  353. file contains a set of procedures and programs that correspond to the
  354. document, but does not include any make files or scripts to install
  355. the library.  Is the contributed library currently undergoing
  356. revision, and should we expect a new tar file soon?
  357.  
  358.  
  359.                 Eric Hildum
  360.                 hildum@iris.ucdavis.edu
  361.                 dehildum@ucdavis.ucdavis.edu    (Internet)
  362.                 dehildum@ucdavis.bitnet    (BITNET)
  363.                 ucbvax!ucdavis!dehildum    (uucp)
  364.  
  365. From ralph  Sat Jul 15 06:36:51 1989
  366. Date: Sat, 15 Jul 89 06:36:51 MST
  367. From: "Ralph Griswold" <ralph>
  368. Message-Id: <8907151336.AA23947@megaron.arizona.edu>
  369. Received: by megaron.arizona.edu (5.59-1.7/15)
  370.     id AA23947; Sat, 15 Jul 89 06:36:51 MST
  371. To: icon-group@arizona.edu, iris!hildum@ucdavis.ucdavis.edu
  372. Subject: Re:  Contributed programs and version 7.5 UNIX installation
  373. In-Reply-To: <4893@ucdavis.ucdavis.edu>
  374.  
  375. The UNIX and VMS distributions of 7.5 of Icon were assembled before
  376. the current Version 7 of the Icon program library was complete.  These
  377. distributions contail an older versi of the library, as you've noted.
  378.  
  379. We do not plan to update the UNIX and VMS distributions of Icon in the
  380. near future.  However, the documentation that accompanies Version 7
  381. of the Icon program library contains the information necessary to
  382. install it.  Granted, there is no "button to push", it's really quite
  383. easy.
  384.  
  385.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  386.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  387.  
  388.  
  389. From uunet!rayssd!mlfarm!ron  Sat Jul 15 17:09:50 1989
  390. Received: by megaron.arizona.edu (5.59-1.7/15)
  391.     id AA14835; Sat, 15 Jul 89 17:09:50 MST
  392. Received: from rayssd.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
  393.     id AA06276; Sat, 15 Jul 89 12:01:34 -0400
  394. Received: from mlfarm with UUCP by rayssd.RAY.COM ; Sat, 15 Jul 89 03:00:15 edt
  395. Received: by mlfarm.uucp (smail2.5)
  396.     id AA11817; 14 Jul 89 07:38:13 EDT (Fri)
  397. To: goer@sophist.uchicago.edu
  398. Cc: arizona!icon-group
  399. In-Reply-To: Richard Goerwitz's message of Wed, 12 Jul 89 16:55:35 CDT <8907122155.AA06421@sophist.uchicago.edu>
  400. Subject: xenix
  401. Message-Id: <8907140738.AA11817@mlfarm.uucp>
  402. Date: 14 Jul 89 07:38:13 EDT (Fri)
  403. From: uunet!mlfarm!ron (Ronald Florence)
  404.  
  405. Richard,
  406.  
  407. I ported ICON to Xenix/386 with no difficulties.  I believe the
  408. configuration files for Xenix/386 are now included with the ICON
  409. distibution.  
  410.  
  411. My own system is an IBM ps2/80, and the ICON benchmark suite produced
  412. very acceptable results, faster than a Sun 3/160 or any DOS or OS/2
  413. version of ICON on the same machine, including the protected mode DOS
  414. version.  The only ICON feature I did not implement is co-expressions.
  415.  
  416. If you need the configuration files or other information, let me know.
  417.  
  418. Ronald Florence                    ...{hsi!aati,rayssd}!mlfarm!ron
  419.  
  420.  
  421. From uunet!ladcgw!l66a.ladc.bull.com!ZENITH  Mon Jul 17 13:14:22 1989
  422. Received: by megaron.arizona.edu (5.59-1.7/15)
  423.     id AA06824; Mon, 17 Jul 89 13:14:22 MST
  424. Received: from ladcgw.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
  425.     id AA22294; Mon, 17 Jul 89 15:55:23 -0400
  426. Received: from l66a by ladc.bull.com (3.2/SMI-3.2)
  427.     id AA14202; Mon, 17 Jul 89 11:38:38 PDT
  428. Date: Mon, 17 Jul 89 11:33 PDT
  429. From: ZENITH <uunet!l66a.ladc.bull.com!ZENITH>
  430. Reply-To: Zenith/A_Birner <uunet!l66a.ladc.bull.com!Zenith/A_Birner>
  431. To: icon-group@arizona.edu
  432. Really-To: icon-group
  433. Subject: porting Icon to machines with strange word sizes
  434. Message-Id: <890717.11383092.013057@L66A.CP6>
  435.  
  436.  Has anyone worked at porting Icon to a machine with a word size that is
  437.  
  438. _not_ a multiple of eight?  I'm entertaining the notion of porting Icon
  439. to run on the Bull (nee Honeywell) DPS-8 architecture, under the CP-6
  440. operating system; the salient feature of this hardware is its nine-bit
  441. bytes (36-bit words).  Am I likely to run into any major headaches as a
  442. result of this?
  443.  
  444. - Andy -
  445.  
  446. From kwalker  Tue Jul 18 17:01:28 1989
  447. Date: Tue, 18 Jul 89 17:01:28 MST
  448. From: "Kenneth Walker" <kwalker>
  449. Message-Id: <8907190001.AA07073@megaron.arizona.edu>
  450. Received: by megaron.arizona.edu (5.59-1.7/15)
  451.     id AA07073; Tue, 18 Jul 89 17:01:28 MST
  452. In-Reply-To: <890717.11383092.013057@L66A.CP6> Has anyone worked at
  453.     porting Icon to a machine with a word size that is
  454. To: icon-group
  455. Subject: Re:  porting Icon to machines with strange word sizes
  456.  
  457.     Date: Mon, 17 Jul 89 11:33 PDT
  458.     From: ZENITH <uunet!l66a.ladc.bull.com!ZENITH>
  459.     Reply-To: Zenith/A_Birner <uunet!l66a.ladc.bull.com!Zenith/A_Birner>
  460.      
  461.      Has anyone worked at porting Icon to a machine with a word size that is
  462.     _not_ a multiple of eight?  I'm entertaining the notion of porting Icon
  463.     to run on the Bull (nee Honeywell) DPS-8 architecture, under the CP-6
  464.     operating system; the salient feature of this hardware is its nine-bit
  465.     bytes (36-bit words).  Am I likely to run into any major headaches as a
  466.     result of this?
  467.      
  468. You will probably run into headaches. The implementation of Icon has
  469. become a lot more portable in the last few releases so it is hard
  470. to judge just how difficult it will be (some of it depends on how robust
  471. your C compiler is, of course). There is actually a configuration parameter
  472. for specifying the number of bits/byte. It seems to only be used in the linker.
  473. I am not sure anyone has tried setting it to a number other than 8. At one
  474. time there were problems with the random number generator, but I think
  475. that has been fixed to work as long as you have at least 32 bit integers
  476. (someone can correct me if I am wrong.)
  477.  
  478. Is the DPS-8 a byte addressable machine or do byte pointers have a special
  479. form like they do in the Cray (so far no one has managed a port of Icon
  480. to that machine)? Are pointers and ints (or longs) the same size?
  481.  
  482. We can try to give you some advice if you decide to attempt the port. You
  483. can address questions to icon-project@arizona.edu or directly to me (though
  484. I may pass them on if I can't answer them).
  485.  
  486.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  487.    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  488.  
  489. From tenaglia%astroatc.UUCP@cs.wisc.edu  Wed Jul 19 11:21:30 1989
  490. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  491.     id AA24574; Wed, 19 Jul 89 11:21:30 MST
  492. Received: from astroatc.UUCP by spool.cs.wisc.edu; Wed, 19 Jul 89 13:17:35 -0500
  493. Received: by astroatc.UUCP (5.51/4.7)
  494.     id AA03022; Wed, 19 Jul 89 12:44:34 CDT
  495. Date: Wed, 19 Jul 89 12:44:34 CDT
  496. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  497. Message-Id: <8907191744.AA03022@astroatc.UUCP>
  498. To: icon-group@arizona.edu
  499.  
  500. Dear Icon-Group,
  501.  
  502.   I am a heavy Icon user. We have icon in DOS, UNIX, and VMS. Having
  503.   benefitted so much from it, I feel glad to be able to contribute a
  504.   little.
  505.  
  506.   Below is one of my favorite procedures. I realize it can be done in
  507.   line with the string scanning features. But I discovered, I do the
  508.   same string scanning over and over. So I composed this software chip
  509.   that I include in many programs. It could be ucoded too. I leave that
  510.   up to the programmer. This first one is more general. As a postscript
  511.   I include a variation that is a little more specific, but still very
  512.   useful.
  513.  
  514.   It can be used in an assignment ->     words := parse(line)
  515.   Or on the fly                   -> if parse(line,' :,')[3] == "X800" then...
  516.  
  517. ##################################################################
  518. #                                                                #
  519. # THIS PROCEDURE PULLS ALL THE ELEMENTS (TOKENS) OUT OF A LINE   #
  520. # BUFFER AND RETURNS THEM IN A LIST. A VARIABLE NAMED 'CHARS'    #
  521. # CAN BE STATICALLY DEFINED HERE OR GLOBAL. IT IS A CSET THAT    #
  522. # CONTAINS THE VALID CHARACTERS THAT CAN COMPOSE THE ELEMENTS    #
  523. # ONE WISHES TO EXTRACT.                                         #
  524. #                                                                #
  525. ##################################################################
  526. procedure parse(line,delims)
  527.   if delims === &null then delims := ' \t'
  528.   chars := &cset -- delims
  529.   tokens := []
  530.   line ? while tab(upto(chars)) do put(tokens,tab(many(chars)))
  531.   return tokens
  532.   end
  533.  
  534. #ps
  535. procedure parse(line)
  536.   static chars
  537.   initial chars := &cset -- ' \t'
  538.   tokens := []
  539.   line ? while tab(upto(chars)) do put(tokens,tab(many(chars)))
  540.   return tokens
  541.   end
  542.  
  543.  
  544. Chris Tenaglia
  545. Astronautics Corporation of America
  546. 4115 N. Teutonia Avenue
  547. Milwaukee, Wi 53209 USA
  548. (414) 447-8200 X-421
  549.  
  550.  
  551. From icon-group-request  Thu Jul 20 08:54:15 1989
  552. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  553.     id AA12235; Thu, 20 Jul 89 08:54:15 MST
  554. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  555.     id AA13910; Thu, 20 Jul 89 08:42:42 -0700
  556. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  557.     for icon-group@arizona.edu (icon-group@arizona.edu)
  558.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  559. Date: 20 Jul 89 13:58:52 GMT
  560. From: astroatc!tenaglia@speedy.wisc.edu  (Chris Tenaglia)
  561. Organization: Astronautics Technology Cntr, Madison, WI
  562. Subject: handy icon procedure
  563. Message-Id: <2378@astroatc.UUCP>
  564. Sender: icon-group-request@arizona.edu
  565. To: icon-group@arizona.edu
  566.  
  567.  
  568.   I am a heavy Icon user. We have icon in DOS, UNIX, and VMS. Having
  569.   benefitted so much from it, I feel glad to be able to contribute a
  570.   little.
  571.  
  572.   Below is one of my favorite procedures. I realize it can be done in
  573.   line with the string scanning features. But I discovered, I do the
  574.   same string scanning over and over. So I composed this software chip
  575.   that I include in many programs. It could be ucoded too. I leave that
  576.   up to the programmer. This first one is more general. As a postscript
  577.   I include a variation that is a little more specific, but still very
  578.   useful.
  579.  
  580.   It can be used in an assignment ->     words := parse(line)
  581.   Or on the fly                   -> if parse(line,' :,')[3] == "X800" then...
  582.  
  583. ##################################################################
  584. #                                                                #
  585. # THIS PROCEDURE PULLS ALL THE ELEMENTS (TOKENS) OUT OF A LINE   #
  586. # BUFFER AND RETURNS THEM IN A LIST. A VARIABLE NAMED 'CHARS'    #
  587. # CAN BE STATICALLY DEFINED HERE OR GLOBAL. IT IS A CSET THAT    #
  588. # CONTAINS THE VALID CHARACTERS THAT CAN COMPOSE THE ELEMENTS    #
  589. # ONE WISHES TO EXTRACT.                                         #
  590. #                                                                #
  591. ##################################################################
  592. procedure parse(line,delims)
  593.   if delims === &null then delims := ' \t'
  594.   chars := &cset -- delims
  595.   tokens := []
  596.   line ? while tab(upto(chars)) do put(tokens,tab(many(chars)))
  597.   return tokens
  598.   end
  599.  
  600. #ps
  601. procedure parse(line)
  602.   static chars
  603.   initial chars := &cset -- ' \t'
  604.   tokens := []
  605.   line ? while tab(upto(chars)) do put(tokens,tab(many(chars)))
  606.   return tokens
  607.   end
  608.  
  609.  
  610. Chris Tenaglia
  611. Astronautics Corporation of America
  612. 4115 N. Teutonia Avenue
  613. Milwaukee, Wi 53209 USA
  614. (414) 447-8200 X-421
  615.  
  616. From icon-group-request  Fri Jul 21 11:22:38 1989
  617. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  618.     id AA27601; Fri, 21 Jul 89 11:22:38 MST
  619. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  620.     id AA09225; Fri, 21 Jul 89 11:18:21 -0700
  621. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  622.     for icon-group@arizona.edu (icon-group@arizona.edu)
  623.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  624. Date: 21 Jul 89 18:06:17 GMT
  625. From: notecnirp!mk@princeton.edu  (Makoto Kobayashi)
  626. Organization: Dept. of Computer Science, Princeton University
  627. Subject: MS-DOS version
  628. Message-Id: <18305@princeton.Princeton.EDU>
  629. Sender: icon-group-request@arizona.edu
  630. To: icon-group@arizona.edu
  631.  
  632. What is the latest version of icon running on MS-DOS
  633. and how I can get the source?
  634.  
  635. From goer@sophist.uchicago.edu  Sat Jul 22 11:51:47 1989
  636. Received: from [128.135.4.27] by megaron.arizona.edu (5.59-1.7/15) via SMTP
  637.     id AA07193; Sat, 22 Jul 89 11:51:47 MST
  638. Received: from sophist.uchicago.edu by tank.uchicago.edu Sat, 22 Jul 89 13:47:28 CDT
  639. Return-Path: <goer>
  640. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  641.     id AA27534; Sat, 22 Jul 89 12:16:29 CDT
  642. Date: Sat, 22 Jul 89 12:16:29 CDT
  643. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  644. Message-Id: <8907221716.AA27534@sophist.uchicago.edu>
  645. To: icon-group@arizona.edu
  646. Subject: sets
  647.  
  648.  
  649. Recently I ran a simple program like this:
  650.  
  651.   lineset := set()
  652.   while line := !&input do {
  653.     insert(lineset,line)
  654.     }
  655.   every write(!lineset)
  656.  
  657. I used it to remove duplicate lines from a file
  658. looking like this:
  659.  
  660. stuffofonesort data data data
  661. stuffofanothersort data data data
  662. stuffofanothersort data data data
  663. stuffofonesort data data data
  664.  
  665. When I printed everything out, all the lines begin-
  666. ning with stuffofonesort were together; same with
  667. stuffofanothersort.  However, sorting stopped there.
  668. No sorting was done on the data fields (separated
  669. by a space from the first field).  They were listed
  670. in the order in which they were entered into the
  671. set.
  672.  
  673. This is a neat feature.  By some wild coincidence
  674. this sorting order turned out to be very, very
  675. useful to me.  But why did it turn out that way?
  676. Could someone who understands the implementation
  677. better help?
  678.  
  679. -Richard
  680.  
  681. P.S.  The Xenix 386 implementation of Icon is, by
  682. all report, very fast and nice.  I am planning on
  683. snarfing a copy over soon (as soon as I get some
  684. hardware questions nailed down).  Before I get all
  685. involved with it, I wonder:  Has anyone implemented
  686. coexpressions and not told us about it?  I wish I
  687. could say I was competent to write good 386 assem-
  688. bler code, but alas....  If someone else is either
  689. working on this, or else had done it, I'd really
  690. like to know about it.
  691.  
  692. From wgg@june.cs.washington.edu  Sat Jul 22 15:03:12 1989
  693. Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  694.     id AA15732; Sat, 22 Jul 89 15:03:12 MST
  695. Received: by june.cs.washington.edu (5.59/6.13+)
  696.     id AA10995; Sat, 22 Jul 89 14:59:29 PDT
  697. Date: Sat, 22 Jul 89 14:59:29 PDT
  698. From: wgg@june.cs.washington.edu (William Griswold)
  699. Return-Path: <wgg@june.cs.washington.edu>
  700. Message-Id: <8907222159.AA10995@june.cs.washington.edu>
  701. To: goer@sophist.uchicago.edu, icon-group@arizona.edu
  702. Subject: Re:  sets
  703.  
  704. >Date: Sat, 22 Jul 89 12:16:29 CDT
  705. >From: Richard Goerwitz <goer@sophist.uchicago.edu>
  706. >To: icon-group@arizona.edu
  707. >Subject: sets
  708. >
  709. >Recently I ran a simple program like this:
  710. >
  711. >  lineset := set()
  712. >  while line := !&input do {
  713. >    insert(lineset,line)
  714. >    }
  715. >  every write(!lineset)
  716. >
  717. >I used it to remove duplicate lines from a file
  718. >looking like this:
  719. >
  720. >stuffofonesort data data data
  721. >stuffofanothersort data data data
  722. >stuffofanothersort data data data
  723. >stuffofonesort data data data
  724. >
  725. >When I printed everything out, all the lines begin-
  726. >ning with stuffofonesort were together; same with
  727. >stuffofanothersort.  However, sorting stopped there.
  728. >No sorting was done on the data fields (separated
  729. >by a space from the first field).  They were listed
  730. >in the order in which they were entered into the
  731. >set.
  732. >
  733. >This is a neat feature.  By some wild coincidence
  734. >this sorting order turned out to be very, very
  735. >useful to me.  But why did it turn out that way?
  736. >Could someone who understands the implementation
  737. >better help?
  738. >
  739. >-Richard
  740. >
  741.  
  742. What is probably causing this is that the implementation of sets in
  743. Icon uses a hash table.  Hash tables are used frequently as a way to
  744. store values that need to be looked-up quickly by some `key'.  In sets,
  745. the key is the element itself.  In order to make hash tables reasonably
  746. efficient, they are implemented as arrays indexed by pseudo-keys (that
  747. is, keys that are not unique).  Anything that has the same pseudo-key
  748. gets put in the same array-slot.  However, it the elements are not
  749. actually the same, they are all saved in the array-slot as a list.
  750. To perform a look-up then, the element is converted into a pseudo-key,
  751. the array is indexed by the key, and then the resulting list is searched
  752. for the element.
  753.  
  754. For the Icon implementation of sets, the function that produces a
  755. pseudo-key for the input strings only looks at the first 10 or so
  756. characters of the string (to avoid long key-computation times for long
  757. strings).  This means that strings that are identical for the first 10
  758. characters will be put in the same array-slot.  When the elements of the
  759. table are generated, they are generated one array-slot at a time.  So all 
  760. the elements with the same pseudo-key will be in the same array-slot, and
  761. will appear consecutively in the generation sequence.  
  762.  
  763. Needless to say you can't count on this working consistently, or in the
  764. next release of Icon.  You probably want a table indexed by the first
  765. phrase in the line, and store a set of all lines with that phrase as the
  766. element.  Then you can sort the table by the phrase, and generate the elements
  767. of each set in turn.
  768.  
  769. I hope this wasn't too confusing!
  770.  
  771.                     Bill Griswold
  772.  
  773. From icon-group-request  Sun Jul 23 00:53:10 1989
  774. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  775.     id AA05831; Sun, 23 Jul 89 00:53:10 MST
  776. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  777.     id AA23065; Sun, 23 Jul 89 00:41:08 -0700
  778. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  779.     for icon-group@arizona.edu (icon-group@arizona.edu)
  780.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  781. Date: 22 Jul 89 13:01:14 GMT
  782. From: ssbell!mcmi!amperif!unocss!payne@uunet.uu.net  (Matt Payne)
  783. Organization: U. of Nebraska at Omaha
  784. Subject: ICON 7.5 for the AMIGA
  785. Message-Id: <1106@unocss.UUCP>
  786. Sender: icon-group-request@arizona.edu
  787. To: icon-group@arizona.edu
  788.  
  789. I don't see the amiga executables for Icon 7.5 at the Arizona ftp cite.
  790. Would someone please tell me how I may get this executable?  I would prefer
  791. not to pay any copying charges since I don't have much money.  :-(
  792.  
  793. Thanks in advance for the help!
  794. -- 
  795. Matt Payne
  796. Internet:conslt10@zeus.unl.edu  UUCP:uunet!btni!unocss!payne 
  797. Bitnet:CONSLT10@UNOMA1
  798.  
  799. From ralph  Sun Jul 23 05:51:54 1989
  800. Date: Sun, 23 Jul 89 05:51:54 MST
  801. From: "Ralph Griswold" <ralph>
  802. Message-Id: <8907231251.AA19602@megaron.arizona.edu>
  803. Received: by megaron.arizona.edu (5.59-1.7/15)
  804.     id AA19602; Sun, 23 Jul 89 05:51:54 MST
  805. To: icon-group@arizona.edu, ssbell!mcmi!amperif!unocss!payne@uunet.uu.net
  806. Subject: Re:  ICON 7.5 for the AMIGA
  807. In-Reply-To: <1106@unocss.UUCP>
  808.  
  809. Icon for the Amiga is not yet available via FTP.  We're working on it'
  810. perhaps a week or two.
  811.  
  812.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  813.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  814.  
  815.  
  816. From tenaglia%astroatc.UUCP@cs.wisc.edu  Sun Jul 23 06:34:35 1989
  817. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  818.     id AA21363; Sun, 23 Jul 89 06:34:35 MST
  819. Received: from astroatc.UUCP by spool.cs.wisc.edu; Sun, 23 Jul 89 08:30:57 -0500
  820. Received: by astroatc.UUCP (5.51/4.7)
  821.     id AA07154; Sun, 23 Jul 89 08:27:43 CDT
  822. Date: Sun, 23 Jul 89 08:27:43 CDT
  823. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  824. Message-Id: <8907231327.AA07154@astroatc.UUCP>
  825. To: icon-group@arizona.edu
  826.  
  827. Dear Icon-Group,
  828.  
  829. Here is another goodie. It's targetted to unix machines and the unix plot
  830. utility. I use it with a TEK4014 emulation. One can do graphics using icon.
  831. This collection of procedures should be made into a ucode type library.
  832. Your graphics application would have a link statement to pull them together.
  833. Later I may include a sample program using this. Have fun !  
  834.  
  835. Chris Tenaglia
  836. Astronautics Corporation of America
  837. 4115 N. Teutonia Avenue
  838. Milwaukee, Wi 53209 USA
  839. (414) 447-8200 X-421
  840.  
  841. ##########################################################################
  842. #                                                                        #
  843. # draw.icn          5/23/89             by tenaglia                      #
  844. #                                                                        #
  845. # this is a plotting library routine for icon in unix.                   #
  846. # use these procedures to generate plotting commands                     #
  847. # that can be piped into the unix plot command.                          #
  848. #                                                                        #
  849. # usage: icont draw -c        # generate the ucode library               #
  850. #        link draw            # include routines when linking            #
  851. #        icont prog -x | plot # compile, run, & pipe into plot           #
  852. #                                                                        #
  853. ##########################################################################
  854.  
  855. #
  856. # move to a given x,y screen location
  857. #
  858. procedure moveto(x,y)
  859.   write("m",hex(x),hex(y))
  860.   return
  861.   end
  862.  
  863. #
  864. # draw to a given x,y screen location
  865. #
  866. procedure drawto(x,y)
  867.   write("n",hex(x),hex(y))
  868.   return                                      
  869.   end
  870.  
  871. #
  872. # dot at an x,y screen location
  873. #
  874. procedure dot(x,y)
  875.   write("p",hex(x),hex(y))
  876.   return
  877.   end
  878.  
  879. #
  880. # plot from x1,y1 to x2,y2
  881. #
  882. procedure plot(x1,y1,x2,y2)
  883.   write("l",hex(x1),hex(y1),hex(x2),hex(y2))
  884.   return
  885.   end
  886.  
  887. #
  888. # label text to the screen at current location
  889. #
  890. procedure label(data)
  891.   write("t",data,"\n")
  892.   return
  893.   end
  894.  
  895. #
  896. # arc with x,y center sx,sy beginning point and
  897. # fx,fy finishing point. draws counterclockwise.
  898. #
  899. procedure arc(x1,y1,sx,sy,fx,fy)
  900.   write("a",hex(x1),hex(y1),hex(sx),hex(sy),hex(fx),hex(fy))
  901.   return
  902.   end
  903.  
  904. #
  905. # circle with center at x,y and radius r
  906. #
  907. procedure circle(x,y,r)
  908.   write("c",hex(x),hex(y),hex(r))
  909.   return
  910.   end
  911.  
  912. #
  913. # clear screen
  914. #
  915. procedure clear()
  916.   write("e")
  917.   return
  918.   end
  919.  
  920. #
  921. # this polyline routine takes a list as its parameter.
  922. # the list must have an even number of elements.
  923. #
  924. procedure polyline(pairs)
  925.   if *pairs%2 = 1 then fail
  926.   case *pairs of
  927.       {
  928.       0 : return
  929.       2 : write("p",hex(pairs[1]),hex(pairs[2]))
  930. default : {
  931.           write("m",hex(pairs[1]),hex(pairs[2]))
  932.           every i := 3 to *pairs by 2 do write("n",hex(pairs[i]),hex(pairs[i+1]))
  933.           }
  934.     }
  935.   return
  936.   end
  937.  
  938. #       
  939. # style of line. parameter is a string that is either 'dotted',
  940. # 'solid', 'longdashed', 'shortdashed', or 'dotdashed'
  941. #
  942. procedure style(method)
  943.   case method of
  944.     {
  945.     "dotted"      : &null
  946.     "solid"       : &null
  947.     "longdashed"  : &null
  948.     "shortdashed" : &null
  949.     "dotdashed"   : &null
  950.     default       : fail
  951.     }
  952.   write("f",method)
  953.   return
  954.   end
  955.                                                  
  956. #
  957. # window to set up coordinate space with x1,y1 as ll corner
  958. # and x2,y2 as ur corner. tek 4014 is (0,0,3120,3120)
  959. #
  960. procedure window(x1,y1,x2,y2)
  961.   write("s",hex(x1),hex(y1),hex(x2),hex(y2))
  962.   return
  963.   end
  964.  
  965. #
  966. # hex converts a number to a 32 bit binary value
  967. #
  968. procedure hex(n)
  969.   n := integer(n)
  970.   n %:= 65536
  971.   if n < 0 then n+:=65536
  972.   return (char(integer(n%256)) || char(integer(n/256)))
  973.   end
  974.  
  975. # end of the graphics program
  976.  
  977.  
  978. From tenaglia%astroatc.UUCP@cs.wisc.edu  Mon Jul 24 08:03:05 1989
  979. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  980.     id AA26146; Mon, 24 Jul 89 08:03:05 MST
  981. Received: from astroatc.UUCP by spool.cs.wisc.edu; Mon, 24 Jul 89 09:59:14 -0500
  982. Received: by astroatc.UUCP (5.51/4.7)
  983.     id AA22804; Mon, 24 Jul 89 09:53:52 CDT
  984. Date: Mon, 24 Jul 89 09:53:52 CDT
  985. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  986. Message-Id: <8907241453.AA22804@astroatc.UUCP>
  987. To: icon-group@arizona.edu
  988.  
  989. Dear Icon-Group,
  990.  
  991.   Here's a sample icon program that takes advantage of the
  992.   drawing procedures I recently posted. It will generate
  993.   the recursive Sierpinski triangle. You need a unix system,
  994.   a tektronix 4014 compatible terminal or emulator, icon,
  995.   and the drawing procedures compiled to ucode.
  996.  
  997.   Step 1. Cut the rest of this file from the # banner on down.
  998.   Step 2. Compile it (icont triang). draw.u1 & draw.u2 should also be in the
  999.            same directory.
  1000.   Step 3. Run it. (iconx triang | plot).
  1001.   Step 4. Answer the question and enjoy the picture.
  1002.  
  1003. Yours truly,
  1004.  
  1005. Chris Tenaglia
  1006. Astronautics Corporation of America
  1007. 4115 N. Teutonia Avenue
  1008. Milwaukee, Wi 53209 USA
  1009. (414) 447-8200 X-421
  1010.  
  1011. #########################################################
  1012. #                                                       #
  1013. # TRIANG.ICN          7/19/89          BY TENAGLIA      #
  1014. #                                                       #
  1015. # SIERPINSKI TRIANGLE GENERATOR USING RANDOM FRACTALS   #
  1016. #                                                       #
  1017. #########################################################
  1018.  
  1019. link draw
  1020. global kbd,crt
  1021.  
  1022. procedure main(p)
  1023. #
  1024. # INITIALIZATION
  1025. #
  1026.   crt := open("/dev/tty","w") ; kbd := open("/dev/cons")
  1027.   &random := map(&clock,":","0")
  1028.   (points := numeric(p[1])) |
  1029.     (points:=numeric(input("_Points>"))) |
  1030.     stop("Points must be integer > 1")
  1031.   px := []   ; py := []
  1032.   w  := 4000 ; h  := 3200
  1033.   window(0,0,w,h)
  1034.   clear()
  1035.   every 1 to 3 do
  1036.     {
  1037.     put(px,?w)
  1038.     put(py,?h)
  1039.     }
  1040.   px |||:= px ; py |||:= py
  1041. #
  1042. # ILLUSTRATE
  1043. #
  1044.   plot(px[1],py[1],px[2],py[2])
  1045.   drawto(px[3],py[3]) ; drawto(px[1],py[1])
  1046.   x := ?w ; y := ?h
  1047.   every 1 to points do
  1048.     {
  1049.     p := ?6
  1050.     x1 := px[p] ; y1 := py[p]
  1051.     x2 := integer((x1 - x) / 2.0 + x)
  1052.     y2 := integer((y1 - y) / 2.0 + y)
  1053.     dot(x2,y2) ; x := x2 ; y := y2
  1054.     }
  1055.   label("\007Done.") ; read()
  1056.   end
  1057. #
  1058. # GET INPUT FROM CONSOLE
  1059. #
  1060. procedure input(prompt)
  1061.   writes(crt,prompt) ; value := read(kbd)
  1062.   return value
  1063.   end
  1064.  
  1065. # END OF PROGRAM
  1066.  
  1067.  
  1068. From icon-group-request  Mon Jul 24 13:56:16 1989
  1069. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1070.     id AA19593; Mon, 24 Jul 89 13:56:16 MST
  1071. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  1072.     id AA02724; Mon, 24 Jul 89 13:47:39 -0700
  1073. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1074.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1075.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1076. Date: 24 Jul 89 16:23:52 GMT
  1077. From: mcvax!hp4nl!mhres!jv@uunet.uu.net  (Johan Vromans)
  1078. Organization: Multihouse NV, the Netherlands
  1079. Subject: Icon 7.5 for Ultrix 3.0
  1080. Message-Id: <3407@mhres.mh.nl>
  1081. Sender: icon-group-request@arizona.edu
  1082. To: icon-group@arizona.edu
  1083.  
  1084. This has probably be answered before, but ...
  1085.  
  1086. I'm porting Icon 7.5 to a VAX running Ultrix 3.0. I choose the
  1087. "vax_ultrix" configuration file.
  1088.  
  1089. First, Ultrix doesn't like fopen(...,"rb") and fopen(...,"wb"), so I
  1090. changed them.
  1091.  
  1092. Now I'm running into memory allocation problems.  
  1093.  
  1094. When I run a program, iconx opens the icon-executable with fopen(...),
  1095. which apparetly calls malloc.  However, initalloc is not yet called,
  1096. so iconx aborts with a stratup error "malloc: static region not
  1097. initialized".
  1098.  
  1099. Has anyone solved this problem, and how? Are other problems to be
  1100. expected?
  1101.  
  1102. Thanks in advance.
  1103.  
  1104.     Johan
  1105. -- 
  1106. Johan Vromans                       jv@mh.nl via internet backbones
  1107. Multihouse Automatisering bv               uucp: ..!{mcvax,hp4nl}!mh.nl!jv
  1108. Doesburgweg 7, 2803 PL Gouda, The Netherlands  phone/fax: +31 1820 62944/62500
  1109. ------------------------ "Arms are made for hugging" -------------------------
  1110.  
  1111. From ralph  Mon Jul 24 16:39:08 1989
  1112. Date: Mon, 24 Jul 89 16:39:08 MST
  1113. From: "Ralph Griswold" <ralph>
  1114. Message-Id: <8907242339.AA01427@megaron.arizona.edu>
  1115. Received: by megaron.arizona.edu (5.59-1.7/15)
  1116.     id AA01427; Mon, 24 Jul 89 16:39:08 MST
  1117. To: icon-group@arizona.edu, mcvax!hp4nl!mhres!jv@uunet.uu.net
  1118. Subject: Re:  Icon 7.5 for Ultrix 3.0
  1119. In-Reply-To: <3407@mhres.mh.nl>
  1120.  
  1121. These are known problems with Version 7.5 under Ultrix.  They are fixed
  1122. in our development version, but it will be a while until it's available
  1123. for distribution.
  1124.  
  1125. To work around the memory allocation problem, add
  1126.  
  1127.     #define FixedRegions
  1128.  
  1129. to define.h.
  1130.  
  1131. Icon's memory regions won't expand automatically, but you can set them
  1132. to large values with environment variables.
  1133.  
  1134.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  1135.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  1136.  
  1137.  
  1138. From icon-group-request  Tue Jul 25 18:37:54 1989
  1139. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1140.     id AA28465; Tue, 25 Jul 89 18:37:54 MST
  1141. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  1142.     id AA03680; Tue, 25 Jul 89 18:30:11 -0700
  1143. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1144.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1145.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1146. Date: 25 Jul 89 22:06:05 GMT
  1147. From: srcsip!nic.MR.NET!ns!dean@csd4.milw.wisc.edu  (Dean Gahlon x2434)
  1148. Organization: Network Systems Corporation
  1149. Subject: Re: ICON 7.5 for the AMIGA
  1150. Message-Id: <1508@ns.network.com>
  1151. References: <1106@unocss.UUCP>
  1152. Sender: icon-group-request@arizona.edu
  1153. To: icon-group@arizona.edu
  1154.  
  1155.  
  1156.     Just having gone through this, I have the information you
  1157. seek. Unfortunately, the Icon Project currently doesn't have an Amiga,
  1158. so getting the files onto their ftp machine is rather difficult at
  1159. present.  The only way to get it currently is to spend the $15 and
  1160. order it.  (I got a response last week from Dr. Griswold to this
  1161. effect, whereupon I immediately called the phone number listed and
  1162. ordered the disk.  It hasn't arrived yet, but this doesn't surprise
  1163. me, since it's been less than a week)
  1164.  
  1165.                 Sorry to be the bearer of bad news,
  1166.                 Dean C. Gahlon.
  1167.  
  1168. From icon-group-request  Fri Jul 28 11:10:21 1989
  1169. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1170.     id AA25138; Fri, 28 Jul 89 11:10:21 MST
  1171. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  1172.     id AA22426; Fri, 28 Jul 89 11:02:58 -0700
  1173. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1174.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1175.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1176. Date: 27 Jul 89 19:49:45 GMT
  1177. From: srcsip!nic.MR.NET!hal!ncoast!davewt@csd4.milw.wisc.edu  (David Wright)
  1178. Organization: Cleveland Public Access UN*X, Cleveland, OH
  1179. Subject: Re: ICON 7.5 for the AMIGA
  1180. Message-Id: <14298@ncoast.ORG>
  1181. References: <1106@unocss.UUCP>
  1182. Sender: icon-group-request@arizona.edu
  1183. To: icon-group@arizona.edu
  1184.  
  1185.  
  1186.     Please post a reply to this newsgroup, as I am also interested in
  1187. getting a copy...
  1188.  
  1189.             Dave
  1190.  
  1191. From ralph  Sun Jul 30 06:05:25 1989
  1192. Date: Sun, 30 Jul 89 06:05:25 MST
  1193. From: "Ralph Griswold" <ralph>
  1194. Message-Id: <8907301305.AA22938@megaron.arizona.edu>
  1195. Received: by megaron.arizona.edu (5.59-1.7/15)
  1196.     id AA22938; Sun, 30 Jul 89 06:05:25 MST
  1197. To: icon-group
  1198. Subject: Icon Version 7.5 for the Amiga
  1199.  
  1200. Version 7.5 Icon executables and the Icon program library for the Amiga
  1201. are now available from us via FTP and RBBS.
  1202.  
  1203. Please let me know of any problems (mail to me, not icon-group, please).
  1204.  
  1205.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  1206.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  1207.  
  1208.  
  1209. From tenaglia%astroatc.UUCP@cs.wisc.edu  Tue Aug  1 06:57:03 1989
  1210. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1211.     id AA11485; Tue, 1 Aug 89 06:57:03 MST
  1212. Received: from astroatc.UUCP by spool.cs.wisc.edu; Tue, 1 Aug 89 08:53:36 -0500
  1213. Received: by astroatc.UUCP (5.51/4.7)
  1214.     id AA05853; Tue, 1 Aug 89 07:55:25 CDT
  1215. Date: Tue, 1 Aug 89 07:55:25 CDT
  1216. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  1217. Message-Id: <8908011255.AA05853@astroatc.UUCP>
  1218. To: icon-group@arizona.edu
  1219.  
  1220. Dear Icon-Group,
  1221.  
  1222. ( I recently mailed this to icon-group but had it bounce back as undeliverable.
  1223.   I don't know if it made it or not, so I'm resending it. If it already has
  1224.   been posted, just ignore it. )
  1225.  
  1226.   Here's a sample icon program that takes advantage of the
  1227.   drawing procedures I recently posted. It will generate
  1228.   the recursive Sierpinski triangle. You need a unix system,
  1229.   a tektronix 4014 compatible terminal or emulator, icon,
  1230.   and the drawing procedures compiled to ucode.
  1231.  
  1232.   Step 1. Cut the rest of this file from the # banner on down.
  1233.   Step 2. Compile it (icont triang). draw.u1 & draw.u2 should also be in the
  1234.            same directory.
  1235.   Step 3. Run it. (iconx triang | plot).
  1236.   Step 4. Answer the question and enjoy the picture.
  1237.  
  1238. Yours truly,
  1239.  
  1240. Chris Tenaglia
  1241. Astronautics Corporation of America
  1242. 4115 N. Teutonia Avenue
  1243. Milwaukee, Wi 53209 USA
  1244. (414) 447-8200 X-421
  1245.  
  1246. #########################################################
  1247. #                                                       #
  1248. # TRIANG.ICN          7/19/89          BY TENAGLIA      #
  1249. #                                                       #
  1250. # SIERPINSKI TRIANGLE GENERATOR USING RANDOM FRACTALS   #
  1251. #                                                       #
  1252. #########################################################
  1253.  
  1254. link draw
  1255. global kbd,crt
  1256.  
  1257. procedure main(p)
  1258. #
  1259. # INITIALIZATION
  1260. #
  1261.   crt := open("/dev/tty","w") ; kbd := open("/dev/cons")
  1262.   &random := map(&clock,":","0")
  1263.   (points := numeric(p[1])) |
  1264.     (points:=numeric(input("_Points>"))) |
  1265.     stop("Points must be integer > 1")
  1266.   px := []   ; py := []
  1267.   w  := 4000 ; h  := 3200
  1268.   window(0,0,w,h)
  1269.   clear()
  1270.   every 1 to 3 do
  1271.     {
  1272.     put(px,?w)
  1273.     put(py,?h)
  1274.     }
  1275.   px |||:= px ; py |||:= py
  1276. #
  1277. # ILLUSTRATE
  1278. #
  1279.   plot(px[1],py[1],px[2],py[2])
  1280.   drawto(px[3],py[3]) ; drawto(px[1],py[1])
  1281.   x := ?w ; y := ?h
  1282.   every 1 to points do
  1283.     {
  1284.     p := ?6
  1285.     x1 := px[p] ; y1 := py[p]
  1286.     x2 := integer((x1 - x) / 2.0 + x)
  1287.     y2 := integer((y1 - y) / 2.0 + y)
  1288.     dot(x2,y2) ; x := x2 ; y := y2
  1289.     }
  1290.   label("\007Done.") ; read()
  1291.   end
  1292. #
  1293. # GET INPUT FROM CONSOLE
  1294. #
  1295. procedure input(prompt)
  1296.   writes(crt,prompt) ; value := read(kbd)
  1297.   return value
  1298.   end
  1299.  
  1300. # END OF PROGRAM
  1301.  
  1302.  
  1303. From KARNA@wharton.upenn.edu  Tue Aug  1 08:42:14 1989
  1304. Received: from REMOTE.DCCS.UPENN.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1305.     id AA15053; Tue, 1 Aug 89 08:42:14 MST
  1306. Return-Path: <KARNA@wharton.upenn.edu>
  1307. Received: from WHARTON.UPENN.EDU by remote.dccs.upenn.edu
  1308.     id AA12843; Tue, 1 Aug 89 11:39:11 -0400
  1309. Message-Id: <8908011539.AA12843@remote.dccs.upenn.edu>
  1310. Date: Tue, 1 Aug 89 11:40 EDT
  1311. From: KARNA@wharton.upenn.edu
  1312. To: icon-group@arizona.edu
  1313. X-Vms-To: IN%"icon-group@arizona.edu"
  1314.  
  1315. I was wondering if anyone out there that has been using the PC version of 
  1316. Icon has tryed recompiling it using something like 'Heap Expander', or any
  1317. other virtual memory package.  I'm curious as to what troubles you en
  1318. encountered, what changes were needed, etc. ion
  1319.  
  1320. I am also curious as to whether anyone has implemented a dBase interface
  1321. to Icon.  
  1322.  
  1323.     --karna@wharton.upenn.edu
  1324.  
  1325. From ralph  Tue Aug  1 10:19:39 1989
  1326. Date: Tue, 1 Aug 89 10:19:39 MST
  1327. From: "Ralph Griswold" <ralph>
  1328. Message-Id: <8908011719.AA20235@megaron.arizona.edu>
  1329. Received: by megaron.arizona.edu (5.59-1.7/15)
  1330.     id AA20235; Tue, 1 Aug 89 10:19:39 MST
  1331. To: KARNA@wharton.upenn.edu
  1332. Subject: MS-DOS Icon
  1333. Cc: icon-group
  1334. In-Reply-To: <8908011539.AA12843@remote.dccs.upenn.edu>
  1335.  
  1336. Virtual memory for Icon won't help a lot, since it's a large-memory
  1337. model program, which limits its region sizes to 64K.  We've been
  1338. trying to get it to compile with the huge-memory model, but there
  1339. are all kinds of problems that we've not been able to fix.
  1340.  
  1341. There is a 386 32-bit protected-mode version of Icon that runs under
  1342. MS-DOS and requires extended memory.  It will use all the memory you
  1343. have, and then some.
  1344.  
  1345.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  1346.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  1347.  
  1348.  
  1349. From tenaglia%astroatc.UUCP@cs.wisc.edu  Thu Aug  3 13:20:08 1989
  1350. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1351.     id AA15748; Thu, 3 Aug 89 13:20:08 MST
  1352. Received: from astroatc.UUCP by spool.cs.wisc.edu; Thu, 3 Aug 89 15:15:59 -0500
  1353. Received: by astroatc.UUCP (5.51/4.7)
  1354.     id AA11677; Thu, 3 Aug 89 14:58:15 CDT
  1355. Date: Thu, 3 Aug 89 14:58:15 CDT
  1356. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  1357. Message-Id: <8908031958.AA11677@astroatc.UUCP>
  1358. To: icon-group@arizona.edu
  1359.  
  1360. Dear Icon-Group,
  1361.  
  1362.   Here's a rather curious utility. It's an ASCII/EBCDIC translator. Some of
  1363.   us occasionally get data tapes from IBM mainframes. Unix does supply a
  1364.   dd utility as a translator, but not MS-DOS or VMS. So I constructed this
  1365.   one. You may just find the translate tables useful of themselves.
  1366.  
  1367.   The program is run as a filter. ebasc -a <file1 >file2 is ebcdic to ascii.
  1368.   ebasc -e <file1 >file2 is ascii to ebcdic. You may have noticed some special
  1369.   'metacomments'. In a future submission I will submit an Icon program pretty
  1370.   printer that makes use of them.
  1371.  
  1372. Yours truly, 
  1373.  
  1374. Chris Tenaglia
  1375. Astronautics Corporation of America
  1376. 4115 N. Teutonia Avenue
  1377. Milwaukee, Wi 53209 USA
  1378. (414) 447-8200 X-421
  1379.  
  1380. Our motto : Icon do it!
  1381.  
  1382. #TITLE EBASC : ASCII/EBCDIC TRANSLATOR
  1383. #SUB USAGE : ICONX EBASC -OPTION <STDIN >STDOUT
  1384. #EJECT
  1385. #############################################################################
  1386. #                                                                           #
  1387. # EBASC.ICN                3/24/88                     BY TENAGLIA          #
  1388. #                                                                           #
  1389. #############################################################################
  1390. procedure main(option)
  1391.   asc := string(&cset)
  1392.   ebc := "\000\001\002\003\234\011\206\177\227\215\216\013\014\015\016\017"||
  1393.          "\020\021\022\023\235\205\010\207\030\031\222\217\034\035\036\037"||
  1394.          "\200\201\202\203\204\012\027\033\210\211\212\213\214\005\006\007"||
  1395.          "\220\221\026\223\224\225\226\004\230\231\232\233\024\025\236\032"||
  1396.          "\040\240\241\242\243\244\245\246\247\250\133\056\074\050\053\041"||
  1397.          "\046\251\252\253\254\255\256\257\260\261\135\044\052\051\073\136"||
  1398.          "\055\057\262\263\264\265\266\267\270\271\174\054\045\137\076\077"||
  1399.          "\272\273\274\275\276\277\300\301\302\140\072\043\100\047\075\042"||
  1400.          "\303\141\142\143\144\145\146\147\150\151\304\305\306\307\310\311"||
  1401.          "\312\152\153\154\155\156\157\160\161\162\313\314\315\316\317\320"||
  1402.          "\321\176\163\164\165\166\167\170\171\172\322\323\324\325\326\327"||
  1403.          "\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347"||
  1404.          "\173\101\102\103\104\105\106\107\110\111\350\351\352\353\354\355"||
  1405.          "\175\112\113\114\115\116\117\120\121\122\356\357\360\361\362\363"||
  1406.          "\134\237\123\124\125\126\127\130\131\132\364\365\366\367\370\371"||
  1407.          "\060\061\062\063\064\065\066\067\070\071\372\373\374\375\376\377"
  1408.   (method := option[1]) | help()
  1409.   case method of
  1410.     {
  1411.     "-a" : while write(map(read(),asc,ebc))      #ebcdic to ascii
  1412.     "-e" : while write(map(read(),ebc,asc))      #ascii to ebcdic
  1413.  default : help()                                #on line help    (default)
  1414.     }
  1415. end
  1416.  
  1417. procedure help()
  1418.   if find("nix",map(&host)) then                         # open screen for
  1419.     vdu := open("/dev/tty","w")                          # online help. It
  1420.   if find("dos",map(&host)) then                         # recognizes Unix
  1421.     vdu := open("cons","w") else vdu := open("tt:","b")  # DOS & VMS.
  1422.   write(vdu,"USAGE : iconx ebasc -option <stdin >stdout")
  1423.   write(vdu,"\e[1;7m*** Translate between ascii and ebcdic coded data ***\e[m")
  1424.   write(vdu,"\e[1;7m-a Option translates ebcdic to ascii.                \e[m")
  1425.   write(vdu,"\e[1;7m-e Option translates ascii to ebcdic.                \e[m")
  1426.   write(vdu,"\e[1;7m-h Option outputs this help paragraph.               \e[m")
  1427.   write(vdu,"\e[1;7m<stdin  Specify  input file using redirector symbol. \e[m")
  1428.   write(vdu,"\e[1;7m>stdout Specify output file using redirector symbol. \e[m")
  1429.   stop()
  1430. end
  1431.  
  1432. From icon-group-request  Thu Aug  3 20:05:07 1989
  1433. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1434.     id AA05798; Thu, 3 Aug 89 20:05:07 MST
  1435. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  1436.     id AA14050; Thu, 3 Aug 89 19:56:58 -0700
  1437. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1438.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1439.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1440. Date: 3 Aug 89 22:42:08 GMT
  1441. From: oliveb!mipos3!omepd!mipon2!dan@apple.com  (Dan Casali)
  1442. Organization: Oregon Microcomputer Engineering, Intel Corp., Hillsboro, OR
  1443. Subject: Icon and SNOBOL now available (supported!) on Mac
  1444. Message-Id: <4755@omepd.UUCP>
  1445. Sender: icon-group-request@arizona.edu
  1446. To: icon-group@arizona.edu
  1447.  
  1448. I recently received by direct mailing an annoucement of a supported
  1449. ICON for the Mac.  I purchased it, and with the package came an announcement
  1450. of a SNOBOL4 for the Mac as well.
  1451.  
  1452. Both the ICON (called ProIcon) and the SNOBOL4 (called MaxSPITBOL)
  1453. come with a development environment (editor and windows), and an
  1454. exportable runtime system.  The entire Icon package fits on a single 800Kb
  1455. diskette.  Both have support for file and text dialogs and window
  1456. manipulation (but no direct access to the Mac toolbox).
  1457.  
  1458. I have been quite pleased with ProIcon, and have ordered MaxSPITBOL as well.
  1459. I previously had been running the Arizona Mac Icon, which must be run
  1460. under MPW and doesn't handle files very nicely.
  1461.  
  1462. Both ProIcon and MaxSPITBOL can be ordered from 
  1463.     Catspaw, Inc.
  1464.     PO Box 1123
  1465.     Salida, Colorado 81201
  1466.     (719) 539-3884
  1467.  
  1468. ProIcon costs $175.00 plus shipping w/o the Griswold book;
  1469. implementation documentation is quite comprehensive.
  1470.  
  1471. MaxSPITBOL costs $195.00.  plus shipping.
  1472.  
  1473. Its great to see my favorite languages supported on the Mac!
  1474.  
  1475. From R.J.Hare@EDINBURGH.AC.UK  Fri Aug  4 03:39:18 1989
  1476. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1477.     id AA19040; Fri, 4 Aug 89 03:39:18 MST
  1478. Received: from UKACRL.BITNET by rvax.ccit.arizona.edu; Fri, 4 Aug 89 03:07 MST
  1479. Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 3582; Fri,
  1480.  04 Aug 89 10:58:51 BST
  1481. Date: 04 Aug 89  11:01:14 bst
  1482. From: R.J.Hare@EDINBURGH.AC.UK
  1483. Subject: Speed of Icon
  1484. To: icon-group@arizona.edu
  1485. Via:        000015001006.FTP.MAIL;  4 AUG 89 10:58:48 BST
  1486. Message-Id: <04 Aug 89  11:01:14 bst  340765@EMAS-A>
  1487.  
  1488. I have written a context editor in Icon which is compatible with our local
  1489. mainframe editor. The editor is fine but very slow in reading in the text of
  1490. the file prior to editing, and slow to write out at the end of an editing
  1491. session. The file to be edited is read in as a list of strings, each line
  1492. being one item in the list. Does anyone out there have any idea how to speed
  1493. up the reading/writing process?
  1494.  
  1495. Thanks.
  1496.  
  1497. Roger Hare.
  1498.  
  1499. From tenaglia%astroatc.UUCP@cs.wisc.edu  Sat Aug  5 07:09:24 1989
  1500. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1501.     id AA15123; Sat, 5 Aug 89 07:09:24 MST
  1502. Received: from astroatc.UUCP by spool.cs.wisc.edu; Sat, 5 Aug 89 09:05:59 -0500
  1503. Received: by astroatc.UUCP (5.51/4.7)
  1504.     id AA04910; Sat, 5 Aug 89 08:46:58 CDT
  1505. Date: Sat, 5 Aug 89 08:46:58 CDT
  1506. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  1507. Message-Id: <8908051346.AA04910@astroatc.UUCP>
  1508. To: icon-group@arizona.edu
  1509.  
  1510. Dear Icon-Group,
  1511.  
  1512.   This is a rather long goody. Its an icon program pretty printer.
  1513.   I integrated it with the ipxref crossreference program as well.
  1514.   The program itself is written to be printed by itself. It you'd
  1515.   like to keep neat listings of iconware, you'll like this one.
  1516.   You may even customize it to have your company/school header or
  1517.   whatever. It's over 350 lines long, I hope your mail utility
  1518.   has a more filter. Good Luck!
  1519.  
  1520. Yours truly,
  1521.  
  1522. Chris Tenaglia
  1523. Astronautics Corporation of America
  1524. 4115 N. Teutonia Avenue
  1525. Milwaukee, Wi 53209 USA
  1526. (414) 447-8200 X-421
  1527.  
  1528. #TITLE FANCY LISTER OF ICONWARE
  1529. #SUB MAIN LINE
  1530. #EJECT
  1531. #################################################################
  1532. #                                                               #
  1533. # ILIST.ICN             11/26/88              BY CHRIS TENAGLIA #
  1534. #                                                               #
  1535. #        THIS PROGRAM MAKES NICE LIST FILES OF ICONWARE         #
  1536. #                                                               #
  1537. # LISTER DIRECTIVES    DESCRIPTION                              #
  1538. #  #TITLE text.....     SET MAIN TITLE INFORMATION              #
  1539. #  #SUB text.......     SET SUBTITLE INFORMATION                #
  1540. #  #EJECT               EJECT PAGE                              #
  1541. #                                                               #
  1542. # CROSSREFERENCE OF PROCEDURES REQUIRES THAT ALL PROCEDURES BE  #
  1543. # DECLARED STARTING IN COLUMN 1.   THIS PROGRAM WAS WRITTEN TO  #
  1544. # DEMONSTRATE ITS USE. IPXREF FROM THE IPL WAS ADDED AS AN OP-  #
  1545. # OPTION TO PROVIDE A DETAILED CROSSREFERENCE AT THE END.       #
  1546. # USAGE : ICONX ILIST [-V] FILE[.ICN] [OUTPUT]                  #
  1547. #                                                               #
  1548. #################################################################
  1549. global in,out,pgnum,lnum,lcnt,tline,subline,option,source
  1550. global resword, linenum, letters, digits, var, buffer, qflag, f, fflag, xflag
  1551. global inmaxcol, inlmarg, inchunk, localvar, lin
  1552.  
  1553. record procrec(pname,begline,lastline)
  1554.  
  1555. procedure main(param)
  1556.   init(param)
  1557.   pgnum    := 0
  1558.   lnum     := 0
  1559.   lcnt     := 0              
  1560.   tline    := ""             
  1561.   subline  := ""
  1562.   xpage    := table()
  1563.   xline    := table()
  1564.  
  1565.   every line := !in do
  1566.     {
  1567.     lnum +:= 1
  1568.     if (i := match("procedure ",line)) then
  1569.       {
  1570.       name        := line[i:upto('(',line,i)]
  1571.       xpage[name] := pgnum
  1572.       xline[name] := lnum
  1573.       }
  1574.     if (temp := title(line)) then
  1575.       {
  1576.       tline := temp
  1577.       next
  1578.       }
  1579.     if (temp := subtitle(line)) then
  1580.       {
  1581.       subline := temp
  1582.       next
  1583.       }
  1584.     if match("#eject",map(line)) then
  1585.       {
  1586.       header()
  1587.       next
  1588.       }
  1589.     if lcnt > 55 then header()
  1590.     write(out,ing(line))
  1591.     lcnt +:= 1
  1592.     }
  1593.   close(in)
  1594.   subline := "***** CROSSREFERENCE ***** "
  1595.   header()
  1596.   write(out,left("\nPROCEDURE NAME",32),right("PAGE",8),right("LINE",8))
  1597.   xref1 := sort(xpage,2)
  1598.   xref2 := sort(xline,2)
  1599.   every i := 1 to *xref1 do
  1600.     {
  1601.     proc := xref1[i]
  1602.     page := xref2[i]
  1603.     text := left(page[1],32) || right(proc[2],8) || right(page[2],8)
  1604.     write(out,text)
  1605.     }
  1606.   write(out,left("\nPROCEDURE NAME",32),right("PAGE",8),right("LINE",8))
  1607.   xref1 := sort(xpage,1)
  1608.   xref2 := sort(xline,1)
  1609.   every i := 1 to *xref1 do
  1610.     {
  1611.     proc := xref1[i]
  1612.     page := xref2[i]
  1613.     text := left(proc[1],32) || right(proc[2],8) || right(page[2],8)
  1614.     write(out,text)
  1615.     }
  1616.   if option == "-v" then ipxref([source])
  1617.   close(out)
  1618.   write("\nProcess Completed !")
  1619. end
  1620.                       
  1621. #SUB HANDY SUBROUTINES SECTION
  1622. #EJECT
  1623. #################################################################
  1624. #                                                               #
  1625. # THIS ROUTINE RECOGNIZES AND RETURNS A TITLE IF ANY            #
  1626. #                                                               #
  1627. #################################################################
  1628. procedure title(line)
  1629.   if (i := match("#title ",map(line))) then return line[i:0]
  1630. end
  1631.  
  1632. #################################################################
  1633. #                                                               #
  1634. # THIS ROUTINE RECOGNIZES AND RETURNS A SUBTITLE IF ANY         #
  1635. #                                                               #
  1636. #################################################################
  1637. procedure subtitle(line)
  1638.   if (i := match("#sub ",map(line))) then return line[i:0]
  1639. end
  1640.  
  1641. #################################################################
  1642. #                                                               #
  1643. # THIS ROUTINE SPECIALLY FORMATS THE LINE                       #
  1644. #                                                               #
  1645. #################################################################
  1646. procedure ing(line)                      
  1647.   return (right(lnum,6) || " : " || line)
  1648. end
  1649.  
  1650. #################################################################
  1651. #                                                               #
  1652. # THIS ROUTINE OUTPUTS THE HEADER                               #
  1653. #                                                               #
  1654. #################################################################
  1655. procedure header()
  1656.   pgnum +:= 1
  1657.   write(out,"\f")                                 
  1658.   id := "<> ICON LISTER " || &host || " " || &dateline
  1659.   id ||:= " Page " || pgnum || " <>\n"
  1660.   write(out,center(id,79))
  1661.   write(out,center("<< "||tline||" >>",79))
  1662.   write(out,center("< "||subline||" >",79),"\n")
  1663.   lcnt   := 1
  1664. end
  1665.  
  1666. #EJECT
  1667. #################################################################
  1668. #                                                               #
  1669. # THIS ROUTINE PERFORMS THE INITIAL SET UP AND OPENS FILES      #
  1670. #                                                               #
  1671. #################################################################
  1672. procedure init(param)
  1673.   option := ""
  1674.   parx   := 0
  1675.   if param[1] == "-v" then {option := param[1];parx+:=1}
  1676.   if not(source := param[(parx+:=1)]) then
  1677.     {
  1678.     writes("Source >")
  1679.     source := read()
  1680.     }
  1681.   if not(find(".icn",map(source))) then source ||:= ".icn"
  1682.   (in := open(source)) | stop("Can't open ",source)
  1683.  
  1684.   if not(target := param[(parx+:=1)]) then
  1685.     target := source[1:find(".",source)] || ".lis"
  1686.   (out := open(target,"w")) | stop("Can't open ",target)
  1687.  
  1688.   a      := "\e[1m"
  1689.   c      := "\e[2J\e[H"      
  1690.   z      := "\e[0m\n"
  1691.   top    := list()
  1692.   put(top, (c || a || center("< Nice ICON Lister >",79) || z))
  1693.   put(top, (a || center( (&host || " " || &dateline) ,79) || z))
  1694.   q := center(("Reading " || source || " | Writing " || target),79)
  1695.   b := (a || q || z)
  1696.   put(top, b)
  1697.   put(top, (repl("-",80) || z))
  1698.   every write(!top)
  1699. end
  1700.  
  1701. #    IPXREF
  1702. #
  1703. #    Create Icon program cross-reference
  1704. #
  1705. #    Allan J. Anderson
  1706. #
  1707. #    Last modified 4/29/86 by Ralph E. Griswold
  1708. #
  1709. procedure ipxref(a)
  1710.    local word, w2, p, prec, i, L, ln
  1711.    initial {
  1712.       resword := ["break","by","case","default","do","dynamic","else",
  1713.          "end","every","fail","global","if","initial","link",
  1714.          "local","next","not","of","procedure",
  1715.          "record","repeat","return","static","suspend","then",
  1716.          "to","until","while"]
  1717.       linenum := 0
  1718.       var := table()        # var[variable[proc]] is list of line numbers
  1719.       prec := []        # list of procedure records
  1720.       localvar := []        # list of local variables of current routine
  1721.       buffer := []        # a put-back buffer for getword
  1722.       proc := "global"
  1723.       letters := &lcase ++ &ucase ++ '_'
  1724.       digits := '1234567890'
  1725.       }
  1726.    i := 0
  1727.    header()
  1728.    while p := a[i +:= 1] do
  1729.       case p of {
  1730.          "-q":  qflag := 1
  1731.          "-x":  xflag := 1
  1732.          "-w":  inmaxcol := integer(a[i +:= 1])
  1733.          "-l":  inlmarg := integer(a[i +:= 1])
  1734.          "-c":  inchunk := integer(a[i +:= 1])
  1735.          default:  if f := open(p,"r") then fflag := 1
  1736.             else stop("usage:  [-q -x -w -l -c] file")
  1737.             }
  1738.    while word := getword() do
  1739.       if word == "link" then {
  1740.          buffer := []
  1741.          lin := ""
  1742.          next
  1743.          }
  1744.       else if word == "procedure" then {
  1745.          put(prec,procrec("",linenum,0))
  1746.          proc := getword() | break
  1747.          p := pull(prec)
  1748.          p.pname := proc
  1749.          put(prec,p)
  1750.          }
  1751.       else if word == ("global" | "link" | "record") then {
  1752.          word := getword() | break
  1753.          addword(word,"global",linenum)
  1754.          while (w2 := getword()) == "," do {
  1755.             if Find(word,resword) then break
  1756.             word := getword() | break
  1757.             addword(word,"global",linenum)
  1758.             }
  1759.          put(buffer,w2)
  1760.          }
  1761.       else if word == ("local" | "dynamic" | "static") then {
  1762.          word := getword() | break
  1763.          put(localvar,word)
  1764.          addword(word,proc,linenum)
  1765.          while (w2 := getword()) == "," do {
  1766.             if Find(word,resword) then break
  1767.             word := getword() | break
  1768.             put(localvar,word)
  1769.             addword(word,proc,linenum)
  1770.             }
  1771.          put(buffer,w2)
  1772.          }
  1773.       else if word == "end" then {
  1774.          proc := "global"
  1775.          localvar := []
  1776.          p := pull(prec)
  1777.          p.lastline := linenum
  1778.          put(prec,p)
  1779.          }
  1780.       else if Find(word,resword) then 
  1781.          next
  1782.       else {
  1783.          ln := linenum
  1784.          if (w2 := getword()) == "(" then
  1785.             word ||:= " *"            # special mark for procedures
  1786.          else
  1787.             put(buffer,w2)            # put back w2
  1788.          addword(word,proc,ln)
  1789.          }
  1790.    every write(out,!format(var))
  1791.    write(out,"\n\nprocedures:\tlines:\n")
  1792.    L := []
  1793.    every p := !prec do
  1794.       put(L,left(p.pname,16," ") || p.begline || "-" || p.lastline)
  1795.    every write(out,!(sort(L)))
  1796. end
  1797.  
  1798. procedure addword(word,proc,lineno)
  1799.    if any(letters,word) | \xflag then {
  1800.       /var[word] := table()
  1801.       if /var[word]["global"] | Find(word,\localvar) then {
  1802.          /(var[word])[proc] := [word,proc]
  1803.          put((var[word])[proc],lineno)
  1804.          }
  1805.       else {
  1806.          /var[word]["global"] := [word,"global"]
  1807.          put((var[word])["global"],lineno)
  1808.          }
  1809.       }
  1810. end
  1811.  
  1812. procedure getword()
  1813.    local j, c
  1814.    static i, nonwhite
  1815.    nonwhite := ~' \t\n'
  1816.    repeat {
  1817.       if *buffer > 0 then return get(buffer)
  1818.       if /lin | i = *lin + 1 then
  1819.          if lin := myread() then {
  1820.             i := 1
  1821.             linenum +:= 1
  1822.             }
  1823.          else fail
  1824.       if i := upto(nonwhite,lin,i) then {   # skip white space
  1825.          j := i
  1826.          if lin[i] == ("'" | '"') then {   # don't xref quoted words
  1827.             if /qflag then {
  1828.                c := lin[i]
  1829.                i +:= 1
  1830.                repeat
  1831.                   if i := upto(c ++ '\\',lin,i) + 1 then
  1832.                      if lin[i - 1] == c then break
  1833.                      else i +:= 1
  1834.                   else {
  1835.                      i := 1
  1836.                      linenum +:= 1
  1837.                      lin := myread() | fail
  1838.                      }
  1839.                }
  1840.             else i +:= 1
  1841.             }
  1842.          else if lin[i] == "#" then {    # don't xref comments; get next line
  1843.             i := *lin + 1
  1844.             }
  1845.          else if i := many(letters ++ digits,lin,i) then
  1846.             return lin[j:i]
  1847.          else {
  1848.             i +:= 1
  1849.             return lin[i - 1]
  1850.             }
  1851.          }
  1852.       else
  1853.          i := *lin + 1
  1854.    }       # repeat
  1855. end
  1856.  
  1857. procedure format(T)
  1858.    local V, block, n, L, lin, maxcol, lmargin, chunk, col
  1859.    initial {
  1860.       maxcol := \inmaxcol | 80
  1861.       lmargin := \inlmarg | 40
  1862.       chunk := \inchunk | 4
  1863.       }
  1864.    L := []
  1865.    col := lmargin
  1866.    every V := !T do
  1867.       every block := !V do {
  1868.          lin := left(block[1],16," ") || left(block[2],lmargin - 16," ")
  1869.          every lin ||:= center(block[3 to *block],chunk," ") do {
  1870.             col +:= chunk
  1871.             if col >= maxcol - chunk then {
  1872.                lin ||:= "\n\t\t\t\t\t"
  1873.                col := lmargin
  1874.                }
  1875.             }
  1876.          if col = lmargin then lin := lin[1:-6] # came out exactly even
  1877.          put(L,lin)
  1878.          col := lmargin
  1879.          }
  1880.    L := sort(L)
  1881.    push(L,"variable\tprocedure\t\tline numbers\n")
  1882.    return L
  1883. end
  1884.  
  1885. procedure Find(w,L)
  1886.    every if w == !L then return
  1887. end
  1888.  
  1889. procedure myread()
  1890.    if \fflag then return read(f) else return read()
  1891. end
  1892.  
  1893. From uunet!ukc!arc1  Mon Aug  7 12:50:02 1989
  1894. Received: by megaron.arizona.edu (5.59-1.7/15)
  1895.     id AA06475; Mon, 7 Aug 89 12:50:02 MST
  1896. Received: from ukc.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
  1897.     id AA13842; Mon, 7 Aug 89 14:28:25 -0400
  1898. Message-Id: <8908071828.AA13842@uunet.uu.net>
  1899. Received: from harrier by kestrel.Ukc.AC.UK   Over Ring with SMTP  id ab15752;
  1900.           7 Aug 89 17:24 BST
  1901. Date: Mon, 07 Aug 89 17:18:42 +0100
  1902. From: uunet!ukc.ac.uk!arc1
  1903. To: arizona!icon-group
  1904. Subject: Icon Sources
  1905.  
  1906.  
  1907. Hi, sorry if this is the wrong mailing list to send to but I was looking
  1908. for the latest versions of the sources for Icon. I've checked the
  1909. UK archive sites but have had no joy, so I looked in comp.lang.icon
  1910. and found this address.
  1911.  
  1912. I'm interested in porting it to a parallel system here at UKC (A
  1913. MEiKO transputer system) and distributing it over a network of
  1914. processors.
  1915.  
  1916. Thanks in advance
  1917.  
  1918. Tony Curtis (...uunet!mcvax!ukc!arc1),
  1919.  
  1920. Parallel Systems Group
  1921. Computing Laboratory
  1922. University of Kent
  1923. Canterbury
  1924. England.
  1925.  
  1926. From icon-group-request  Tue Aug  8 09:57:59 1989
  1927. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1928.     id AA25571; Tue, 8 Aug 89 09:57:59 MST
  1929. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  1930.     id AA01286; Tue, 8 Aug 89 09:38:33 -0700
  1931. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1932.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1933.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1934. Date: 8 Aug 89 16:35:32 GMT
  1935. From: corre@csd4.milw.wisc.edu  (Alan D Corre)
  1936. Organization: University of Wisconsin-Milwaukee
  1937. Subject: Icon procedure
  1938. Message-Id: <3722@csd4.milw.wisc.edu>
  1939. Sender: icon-group-request@arizona.edu
  1940. To: icon-group@arizona.edu
  1941.  
  1942. I wanted to write an Icon procedure to check if a string has precisely
  1943. 22 characters (the size of the Hebrew alphabet) and no duplicate
  1944. characters, so I wrote the following:
  1945.  
  1946. procedure checkstring(abc)
  1947. local cs, current
  1948.   if *abc ~= 22 then fail #check length
  1949.   cs := '' #initialize cset
  1950.   abc ? every 1 to 22 do {
  1951.           current := move(1) #select a char
  1952.           if cs ** current ~=== '' then fail #char is already a member
  1953.           cs ++:= current } #char is ok
  1954. return
  1955. end
  1956.  
  1957. The procedure worked fine, but I said: "That isn't an Icon procedure.
  1958. It's a thinly disguised Pascal function. Now write an Icon procedure."
  1959. So I forsook "IF mouse IN hole" and wrote:
  1960.  
  1961. procedure checkstring2(abc)
  1962. local t, current
  1963.   if *abc ~= 22 then fail
  1964.   t := table(22)
  1965.   abc ? every 1 to 22 do {
  1966.           current := move(1)
  1967.           \t[current] | fail
  1968.           t[current] := 1 }
  1969. return
  1970. end
  1971.  
  1972. More Icon constructs, but no better really.
  1973.  
  1974. Then I wrote:
  1975.  
  1976. procedure checkstring3(abc)
  1977. return *abc = *cset(abc) = 22
  1978. end
  1979.  
  1980. Now that's an Icon procedure.
  1981. --
  1982. Alan D. Corre
  1983. Department of Hebrew Studies
  1984. University of Wisconsin-Milwaukee                     (414) 229-4245
  1985. PO Box 413, Milwaukee, WI 53201             corre@csd4.milw.wisc.edu
  1986.  
  1987. From icon-group-request  Tue Aug  8 17:39:03 1989
  1988. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  1989.     id AA23133; Tue, 8 Aug 89 17:39:03 MST
  1990. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  1991.     id AA27927; Tue, 8 Aug 89 17:23:16 -0700
  1992. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1993.     for icon-group@arizona.edu (icon-group@arizona.edu)
  1994.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1995. Date: 8 Aug 89 23:37:00 GMT
  1996. From: cjp@apple.com  (Chris Plummer)
  1997. Organization: Apple Computer Inc, Cupertino, CA
  1998. Subject: Icon ucode
  1999. Message-Id: <33844@apple.Apple.COM>
  2000. Sender: icon-group-request@arizona.edu
  2001. To: icon-group@arizona.edu
  2002.  
  2003.  
  2004. I've just started using Icon on the mac under MPW 3.0 and I have a
  2005. few questions.
  2006.  
  2007. First of all, the mem01 test goes off the deep end after running for
  2008. a few minutes.  The output file in the "stand" folder shows that it
  2009. should print out the numbers 1 to 100 and then quit with a runtime
  2010. error and it seems to do this with the version of Icon I have running
  2011. under unix, but on the Mac it runs for a few minutes and then crashes
  2012. with not output.  There are also a couple of other things that don't
  2013. seem to work such as (\system).  Has anyone else had these problems?
  2014.  
  2015. I noticed that the syntax of ucode has changed since the publication
  2016. of "The Implementation of the Icon Language".  Have the changes been
  2017. documented anywhere?
  2018.  
  2019. Also, is the format of the binary (linked) version of Icon programs
  2020. documented anywhere.
  2021.  
  2022. Thanks in advance for any help.
  2023.  
  2024.         Chris Plummer
  2025.         Apple Computer Inc.
  2026.         cjp@apple.com
  2027.  
  2028. From dscargo@cim-vax.honeywell.com  Thu Aug 10 06:54:37 1989
  2029. Message-Id: <8908101354.AA28972@megaron.arizona.edu>
  2030. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2031.     id AA28972; Thu, 10 Aug 89 06:54:37 MST
  2032. Date: 10 Aug 89 08:35:00 CST
  2033. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  2034. Subject: Real World Icon Application
  2035. To: "icon-group" <icon-group@arizona.edu>
  2036.  
  2037. I came across mention of an Icon application that I thought might be worth
  2038. mentioning.  In the ACM SIGPLAN Notices Volume 24, Number 7 (July 1989),
  2039. Proceedings of the SIGPLAN '89 Conference on Programming Language Design
  2040. and Implementation there is one paper by Christopher W. Fraser (now of
  2041. AT&T Bell Laboratories), A Language for Writing Code Generators.  This is on
  2042. page 238 of the Proceedings.  On page 244 there is a section named
  2043. "Discussion" whose first paragraph says in part, "The sample rules above
  2044. demonstrate all principal features of the rule language.  The rule compiler is
  2045. written in the Icon programming language and takes about 1000 lines."  It's
  2046. nice to see an application of Icon that is part of some cutting-edge research.
  2047. (The acknowledgements also credit Dave Hanson with some of the work.)
  2048.  
  2049. David S. Cargo
  2050.  
  2051.  
  2052. From MYankowski.BSPO@DOCKMASTER.NCSC.MIL  Mon Aug 14 14:12:27 1989
  2053. Received: from DOCKMASTER.NCSC.MIL by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2054.     id AA10496; Mon, 14 Aug 89 14:12:27 MST
  2055. Date:  Mon, 14 Aug 89 17:04 EDT
  2056. From: MYankowski@DOCKMASTER.ARPA
  2057. Subject:  compilation problems
  2058. To: icon-group@arizona.edu
  2059. Message-Id:  <890814210448.224026@DOCKMASTER.ARPA>
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065. I am trying to compile an icon source file and a c source file together
  2066. using iconc under 4.2 BSD.  The program complies fine but I get a
  2067. illegal instruction (core dumped) when I execute the program.  The two
  2068. source files are as follows:
  2069.  
  2070. =========== one.icn:  =========== external two program main()
  2071.      write("this is from main") end
  2072.  
  2073. ========== two.c ========== Btwo() {
  2074.      printf("this is inside the C function two\n"); }
  2075.  
  2076.  
  2077.  
  2078. the compile line is:
  2079.  
  2080. $ iconc one.icn two.c
  2081.  
  2082. then to execute one
  2083.  
  2084. $ one
  2085.  
  2086. this is from main illegal instruction (core dumped)
  2087.  
  2088. I have the book "The Icon Programming Language" which references a
  2089. technical report as guidance for inclusion of c source.  Since this
  2090. technical reference is out of date I purchased the book "The
  2091. Implementation of the Icon Programming Language".  I have not thoroughly
  2092. read the book, but from my examination of the book it would seem that I
  2093. should write a function to extend the language.  Eventually I will try
  2094. this but for now I would like to just do it as outlined above.  Any
  2095. suggestions would be appreciated.  I am running version 5 of ICON which
  2096. I will upgrade when I get the chance.
  2097.  
  2098. By the way, how often are the newsletter and the email stuff released.
  2099.  
  2100.  
  2101. Michael Yankowski DOCKMASTER
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108.  
  2109. From icon-group-request  Tue Aug 15 10:42:09 1989
  2110. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2111.     id AA06591; Tue, 15 Aug 89 10:42:09 MST
  2112. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  2113.     id AA22567; Tue, 15 Aug 89 10:25:16 -0700
  2114. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2115.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2116.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2117. Date: 15 Aug 89 14:55:33 GMT
  2118. From: hubcap!ncrcae!PEDEV!rogerson@gatech.edu  (Dale Rogerson)
  2119. Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC
  2120. Subject: Icon for MS Windows
  2121. Message-Id: <2664@PEDEV.Columbia.NCR.COM>
  2122. Sender: icon-group-request@arizona.edu
  2123. To: icon-group@arizona.edu
  2124.  
  2125. Is anyone currently working on a port of ICON to Microsoft Windows?
  2126.  
  2127. I would be interested in preforming this port depending on how "friendly"
  2128. the source code is.  
  2129.  
  2130. Any information, ideas, or help would be appriciated.
  2131.  
  2132. -----Dale
  2133.     Rogerson-----
  2134.  
  2135. From lti!talmage  Tue Aug 22 20:16:04 1989
  2136. Received: from BU-IT.BU.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2137.     id AA13159; Tue, 22 Aug 89 20:16:04 MST
  2138. Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7)
  2139.     id AA09373; Tue, 22 Aug 89 23:12:42 EDT
  2140. Received:  by buita.bu.edu (3.2/4.7)
  2141.     id AA19304; Tue, 22 Aug 89 23:12:53 EDT
  2142. Received: from waltham.lti.com by lti.com (4.0/SMI-4.0)
  2143.     id AA07400; Tue, 22 Aug 89 18:14:28 EDT
  2144. Date: Tue, 22 Aug 89 18:14:28 EDT
  2145. From: lti!talmage (David Talmage)
  2146. Message-Id: <8908222214.AA07400@lti.com>
  2147. Received: by waltham.lti.com (4.0/SMI-4.0)
  2148.     id AA02330; Tue, 22 Aug 89 18:13:14 EDT
  2149. To: icon-group@arizona.edu
  2150. Subject: Amiga Icon V7.5 environment variables
  2151. Reply-To: lti!talmage
  2152.  
  2153.  
  2154.  
  2155.  
  2156.  
  2157.  
  2158.  
  2159.  
  2160.                        Icon Trouble Report
  2161.  
  2162.  
  2163.  
  2164. Name                     David W. Talmage
  2165.  
  2166. Address                  P. O. Box 8848
  2167.  
  2168.                          Salem, MA 01971-8848
  2169.  
  2170.  
  2171. Telephone                (617) 894-4939 (home)
  2172.  
  2173. Electronic mail address  talmage@lti.uucp, talmage@luvthang.uucp
  2174.  
  2175. Icon version             7.5
  2176.  
  2177. Computer                 Amiga
  2178.  
  2179. Operating system         AmigaDOS 1.3
  2180.  
  2181. Date                     22 August, 1989
  2182.  
  2183.  
  2184. Description of the problem:
  2185.  
  2186. Icon doesn't use AmigaDOS 1.3-style environment variables.
  2187. This is easy enough to fix.  Enclosed is are getenv() and setenv(), two
  2188. Icon procedures for manipulating environment variables.  You may distribute
  2189. them freely.
  2190.  
  2191. Approximately:
  2192.  
  2193. # Amiga-specific getenv that uses AmigaDOS 1.3-style environment variables.
  2194. #
  2195. # parameters:
  2196. #    environment_variable    a string that names some environment
  2197. #                variable
  2198. #
  2199. # returns:
  2200. #    if environment_variable exists, getenv() returns the string value
  2201. #    of environment_variable.
  2202. #
  2203. #    if environment_varable does not exist, getenv() fails.
  2204. #
  2205. procedure getenv( environment_variable )
  2206.  
  2207. local value        # if environment_variable exists, this is its value
  2208. local env_file        # the file in ENV: that represents environment_variable
  2209.  
  2210.  
  2211.             # fail if environment_variable doesn't exist
  2212.   (env_file := open( "ENV:"||environment_variable, "r" ) ) | fail
  2213.  
  2214.             # fail if environment_variable doesn't exist
  2215.   (value := read( env_file ) ) | fail
  2216.  
  2217.   close( env_file )
  2218.  
  2219.   return value        # environment variable exists
  2220.  
  2221. end # getenv
  2222.  
  2223.  
  2224. # Amiga-specific setenv that uses AmigaDOS 1.3-style environment variables.
  2225. #
  2226. # parameters:
  2227. #    environment_variable    a string that names some environment
  2228. #                variable
  2229. #
  2230. #    value            a string containing the new value of
  2231. #                environment_variable 
  2232. #
  2233. # returns:
  2234. #    if setenv() can create or modify environment_variable, it returns
  2235. #    value.
  2236. #
  2237. #    if setenv() cannot create or modify environment_variable, it fails.
  2238. #
  2239. #
  2240. procedure setenv( environment_variable, value )
  2241.  
  2242. local env_file        # the file in ENV: that represents environment_variable
  2243.  
  2244.  
  2245.             # fail if we cannot create or modify
  2246.             #environment_variable 
  2247.   (env_file := open( "ENV:"||environment_variable, "w" ) ) | fail
  2248.  
  2249.             # fail if we cannot modify environment_variable
  2250.   (write( env_file, value ) ) | fail
  2251.  
  2252.   close( env_file )
  2253.  
  2254.   return value        # we can create or modify environment_variable
  2255.  
  2256. end # setenv
  2257.  
  2258.  
  2259. Attach additional information, listings, enclose source code,
  2260. etc., as appropriate. Send to:
  2261.  
  2262.         Icon Project
  2263.         Department of Computer Science
  2264.         Gould-Simpson Building
  2265.         The University of Arizona
  2266.         Tucson, AZ   85721
  2267.         U.S.A.
  2268.         (602) 621-2018
  2269.         icon-project@arizona.edu     (Internet)
  2270.         ... {uunet, allegra, noao}!arizona!icon-project     (uucp)
  2271.  
  2272.  
  2273.  
  2274.  
  2275. IPD46a                                               June 2, 1989
  2276.  
  2277.  
  2278.  
  2279.  
  2280. From lti!talmage  Tue Aug 22 20:16:04 1989
  2281. Received: from BU-IT.BU.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2282.     id AA13158; Tue, 22 Aug 89 20:16:04 MST
  2283. Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7)
  2284.     id AA09372; Tue, 22 Aug 89 23:12:42 EDT
  2285. Received:  by buita.bu.edu (3.2/4.7)
  2286.     id AA19301; Tue, 22 Aug 89 23:12:52 EDT
  2287. Received: from waltham.lti.com by lti.com (4.0/SMI-4.0)
  2288.     id AA07392; Tue, 22 Aug 89 17:56:39 EDT
  2289. Date: Tue, 22 Aug 89 17:56:39 EDT
  2290. From: lti!talmage (David Talmage)
  2291. Message-Id: <8908222156.AA07392@lti.com>
  2292. Received: by waltham.lti.com (4.0/SMI-4.0)
  2293.     id AA02328; Tue, 22 Aug 89 17:55:25 EDT
  2294. To: icon-group@arizona.edu
  2295. Subject: Amiga Icon v7.5 trouble
  2296. Reply-To: lti!talmage
  2297.  
  2298.  
  2299.  
  2300.  
  2301.  
  2302.  
  2303.  
  2304.  
  2305.                        Icon Trouble Report
  2306.  
  2307.  
  2308.  
  2309. Name                     David W. Talmage
  2310.  
  2311. Address                  P. O. Box 8848
  2312.  
  2313.                          Salem, MA 01971-8848
  2314.  
  2315.  
  2316. Telephone                (617) 894-4939 (home)
  2317.  
  2318. Electronic mail address  talmage@lti.uucp, talmage@luvthang.uucp
  2319.  
  2320. Icon version             7.5
  2321.  
  2322. Computer                 Amiga
  2323.  
  2324. Operating system         AmigaDOS 1.3
  2325.  
  2326. Date                     22 August, 1989
  2327.  
  2328.  
  2329. Description of the problem:
  2330.  
  2331. Icont cannot resolve references to files in any directory but the current one.
  2332. This happens regardless of the value of IPATH.
  2333.  
  2334.  
  2335. Example program:
  2336.  
  2337. link "DH0:icon/ipl/procs/dt-strutil"    # icont can't find this.
  2338. link "dt-strutil"            # If this is in the current
  2339.                     # directory, then icont does find
  2340.                     # it.
  2341.  
  2342. procedure main()
  2343.  
  2344. local c
  2345.  
  2346.   c := "a"
  2347.   c := upper_case( c )
  2348.  
  2349.   write( c )
  2350.  
  2351. end
  2352.  
  2353.  
  2354.  
  2355. Attach additional information, listings, enclose source code,
  2356. etc., as appropriate. Send to:
  2357.  
  2358.         Icon Project
  2359.         Department of Computer Science
  2360.         Gould-Simpson Building
  2361.         The University of Arizona
  2362.         Tucson, AZ   85721
  2363.         U.S.A.
  2364.         (602) 621-2018
  2365.         icon-project@arizona.edu     (Internet)
  2366.         ... {uunet, allegra, noao}!arizona!icon-project     (uucp)
  2367.  
  2368.  
  2369.  
  2370.  
  2371. IPD46a                                               June 2, 1989
  2372.  
  2373.  
  2374.  
  2375. From ralph  Wed Aug 23 08:12:20 1989
  2376. Date: Wed, 23 Aug 89 08:12:20 MST
  2377. From: "Ralph Griswold" <ralph>
  2378. Message-Id: <8908231512.AA09025@megaron.arizona.edu>
  2379. Received: by megaron.arizona.edu (5.59-1.7/15)
  2380.     id AA09025; Wed, 23 Aug 89 08:12:20 MST
  2381. To: icon-group
  2382. Subject: Conference reminder
  2383.  
  2384.  
  2385. The Fourth International Conference on Symbolic and Logical Computing
  2386. will be held October 5-6 at Dakota State University.
  2387.  
  2388. This conference provides an excellent opportunity for persons who are
  2389. interested in Icon and SNOBOL4 to get together.
  2390.  
  2391. Conference information is available from
  2392.  
  2393.     Eric Johnson
  2394.     114 Beadle Hall
  2395.     Dakota State University
  2396.     Madison, South Dakota   57042
  2397.  
  2398.     605-256-5270
  2399.  
  2400.     ERIC@SDNET.BITNET
  2401.  
  2402. I'll also be glad to answer questions about the conference.
  2403.  
  2404.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  2405.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  2406.  
  2407.  
  2408. From lti!talmage  Wed Aug 23 14:17:49 1989
  2409. Received: from BU-IT.BU.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2410.     id AA02801; Wed, 23 Aug 89 14:17:49 MST
  2411. Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7)
  2412.     id AA10640; Wed, 23 Aug 89 17:14:27 EDT
  2413. Received:  by buita.bu.edu (3.2/4.7)
  2414.     id AA10952; Wed, 23 Aug 89 17:14:39 EDT
  2415. Received: from waltham.lti.com by lti.com (4.0/SMI-4.0)
  2416.     id AA08104; Wed, 23 Aug 89 11:38:36 EDT
  2417. Date: Wed, 23 Aug 89 11:38:36 EDT
  2418. From: lti!talmage (David Talmage)
  2419. Message-Id: <8908231538.AA08104@lti.com>
  2420. Received: by waltham.lti.com (4.0/SMI-4.0)
  2421.     id AA02462; Wed, 23 Aug 89 11:37:18 EDT
  2422. To: icon-group@arizona.edu
  2423. Cc: icon-project@arizona.edu
  2424. Subject: Apology
  2425. Reply-To: lti!talmage
  2426.  
  2427. By mistake I posted two bug reports to icon-group.  Had I two brain cells
  2428. to rub together, I would have read the bottom of the Icon Trouble Report
  2429. form and sent them to icon-project instead.  I'm sorry.  I won't do it
  2430. again.
  2431.  
  2432. DT
  2433. ------------------------------------------------------------------------------
  2434. David W. Talmage, Systems Programmer        ...!{buita,bbn}!lti!talmage
  2435. Language Technology, Inc.            talmage%lti.uucp@bu-it.bu.edu
  2436. 27 Congress St., Salem, MA 01970        (508) 741-1507
  2437.  
  2438. From icon-group-request  Sat Aug 26 16:26:47 1989
  2439. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2440.     id AA23912; Sat, 26 Aug 89 16:26:47 MST
  2441. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  2442.     id AA08990; Sat, 26 Aug 89 16:20:59 -0700
  2443. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2444.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2445.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2446. Date: 25 Aug 89 08:01:00 GMT
  2447. From: m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh@uxc.cso.uiuc.edu
  2448. Subject: Why ICON?
  2449. Message-Id: <223000001@s.cs.uiuc.edu>
  2450. Sender: icon-group-request@arizona.edu
  2451. To: icon-group@arizona.edu
  2452.  
  2453.  
  2454. I have been reading this notesfile for awhile, and must say I am mystified by
  2455. its very presence. What is ICON? What is so special about it as a lanaguage
  2456. that it merits its own notesfile? So far, most of what I've read has been
  2457. about ICON bugs in Amiga! I would appreciate some explanation about the
  2458. purpose of this language and whether it is at all worth learning.
  2459.  
  2460. From icon-group-request  Sun Aug 27 02:57:12 1989
  2461. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2462.     id AA13325; Sun, 27 Aug 89 02:57:12 MST
  2463. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  2464.     id AA04742; Sun, 27 Aug 89 02:51:55 -0700
  2465. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2466.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2467.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2468. Date: 25 Aug 89 22:30:17 GMT
  2469. From: mailrus!sharkey!mcf!mibte!gamma!thumper!clayton@handies.ucar.edu  (R. Clayton)
  2470. Organization: Bellcore, Morristown, N.J.
  2471. Subject: Another testimonial
  2472. Message-Id: <1693@thumper.bellcore.com>
  2473. Sender: icon-group-request@arizona.edu
  2474. To: icon-group@arizona.edu
  2475.  
  2476. My icon programs often are written as a series of filters on a objects
  2477. in a stream.  The filters do one object look-ahead on the stream with a
  2478. read/pushback sequence, with read implemented something like this: 
  2479.  
  2480.    global push_back_o
  2481.  
  2482.    procedure next_o()
  2483.  
  2484.       local o
  2485.  
  2486.       if \push_back_o then {
  2487.      o := push_back_o
  2488.      push_back_o := &null
  2489.      return o
  2490.      }
  2491.       else return read_o()
  2492.  
  2493.       end # next_o
  2494.  
  2495. It eventually occurred to me that I could use the local variable's &null
  2496. initialization to rewrite the then part of the if statement as 
  2497.  
  2498.    return o :=: push_back_o
  2499.  
  2500. which lets the procedure body collapse to
  2501.  
  2502.    return ((\push_back_o & (o :=: push_back_o)) | read_o())
  2503.  
  2504. and again to
  2505.  
  2506.    return (o :=: \push_back_o) | read_o()
  2507.  
  2508. From kwalker  Sun Aug 27 12:43:02 1989
  2509. Date: Sun, 27 Aug 89 12:43:02 MST
  2510. From: "Kenneth Walker" <kwalker>
  2511. Message-Id: <8908271943.AA28708@megaron.arizona.edu>
  2512. Received: by megaron.arizona.edu (5.59-1.7/15)
  2513.     id AA28708; Sun, 27 Aug 89 12:43:02 MST
  2514. In-Reply-To: <223000001@s.cs.uiuc.edu>
  2515. To: icon-group
  2516. Subject: Re:  Why ICON?
  2517.  
  2518. > Date: 25 Aug 89 08:01:00 GMT
  2519. > From: m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh@uxc.cso.uiuc.edu
  2520. > I have been reading this notesfile for awhile, and must say I am mystified by
  2521. > its very presence. What is ICON?
  2522.  
  2523. Here is my standard brief description of Icon.
  2524.  
  2525.   Icon is a high level programming language designed for string processing
  2526.   and other non-numeric applications (numeric processing can be done, but the
  2527.   language and implementation are not tuned for it). Goal-directed evaluation
  2528.   with control backtracking is an integral part of the language. However,
  2529.   Icon is very different from other languages, such as Prolog, which use
  2530.   this evaluation scheme. Icon has a rich set of control structures which
  2531.   use and control backtracking. Most of these control structures look and
  2532.   act very much like the control structures of more traditional languages,
  2533.   allowing Pascal-like programming where the full power of goal-directed
  2534.   evaluation is not required. Icon incorporates generators as a natural feature
  2535.   within this goal-directed evaluation scheme.
  2536.   
  2537.   Icon has a flexible run-time type system: variables may take on values of
  2538.   any type and automatic type conversions are preformed as needed by
  2539.   operations. There are a variety of types including strings, sets, associative
  2540.   tables, and lists with positional, queue, and stack access methods. All
  2541.   storage management is automatic; garbage collection is performed as needed.
  2542.  
  2543. > What is so special about it as a lanaguage
  2544. > that it merits its own notesfile? So far, most of what I've read has been
  2545. > about ICON bugs in Amiga! I would appreciate some explanation about the
  2546. > purpose of this language and whether it is at all worth learning.
  2547.  
  2548. I am on the Icon Project, so my opinions are somewhat biased. Perhaps
  2549. others of you can comment on what you find to be Icon's strengths
  2550. and weaknesses. What do you use Icon for and why? What don't you
  2551. use Icon for and why? (Perhaps I will express some of my biased
  2552. opinions after others have commented.)
  2553.  
  2554.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  2555.    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  2556.  
  2557. From att!ihuxy!nowlin  Sun Aug 27 15:04:06 1989
  2558. Date: Sun, 27 Aug 89 15:04:06 MST
  2559. Message-Id: <8908272204.AA02985@megaron.arizona.edu>
  2560. Received: by megaron.arizona.edu (5.59-1.7/15)
  2561.     id AA02985; Sun, 27 Aug 89 15:04:06 MST
  2562. From: ihuxy!nowlin (Jerry D Nowlin +1 312 979 0441)
  2563. To: att!arizona!icon-group
  2564. Subject: Re: why Icon
  2565.  
  2566. > Date: Sun, 27 Aug 89 12:43:02 MST
  2567. > From: "Kenneth Walker" <kwalker@arizona.edu>
  2568. > > Date: 25 Aug 89 08:01:00 GMT
  2569. > > From: m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh@uxc.cso.uiuc.edu
  2570. > > 
  2571. > > I have been reading this notesfile for awhile, and must say I am
  2572. > > mystified by its very presence. What is ICON?
  2573. > > What is so special about it as a language
  2574. > > that it merits its own notesfile? So far, most of what I've read has
  2575. > > been about ICON bugs in Amiga! I would appreciate some explanation
  2576. > > about the purpose of this language and whether it is at all worth
  2577. > > learning.
  2578. > I am on the Icon Project, so my opinions are somewhat biased. Perhaps
  2579. > others of you can comment on what you find to be Icon's strengths
  2580. > and weaknesses. What do you use Icon for and why? What don't you
  2581. > use Icon for and why? (Perhaps I will express some of my biased
  2582. > opinions after others have commented.)
  2583.  
  2584. I've been using Icon for around five years now.  Most of my experience is
  2585. with languages like FORTRAN, BASIC, and C but Icon is now my favorite
  2586. language by far.  My favorite parts of Icon are dynamic memory allocation, 
  2587. strings as a real data type along with string scanning, goal directed
  2588. evaluation, and generation.  I've written many Icon programs; calculators,
  2589. spelling checkers, a version of grep, games, text formatting filters, and
  2590. even some expert systems prototypes.  Most of them have operated on text or
  2591. some other type of symbolic data.
  2592.  
  2593. My last large Icon project (~4000 lines) was a simulator for a screen
  2594. generator.  The target system for the real screen generator was in limited
  2595. supply and a simulator that would allow testing on other systems was
  2596. needed.  Icon allowed me to easily parse the screen generation language and
  2597. implement an interpreter for the executable portions of it.  The simulator
  2598. is easy to modify and maintain since Icon is so understandable.  We can now
  2599. test on all the machines in our computing environment from 3B2s to
  2600. mainframes since Icon runs on all of those machines.
  2601.  
  2602. Icon does have some limitations though.  I've since converted the parsing
  2603. portion of the simulator into C for another project because I needed to
  2604. generate intermediate data files that contained binary C structures.  If it
  2605. weren't for this language specific portion of the requirements Icon would
  2606. have been used for this project too.
  2607.  
  2608. One of the real advantages of Icon is the ability to code simple sequences
  2609. in a simple way.  My favorite example is opening files.  In C you have to
  2610. have a minimum amount of code to declare variables and check for errors:
  2611.  
  2612.     FILE *in;
  2613.  
  2614.     if ((in = fopen(infile,"r")) == NULL) {
  2615.         fprintf(stderr,"I can't open '%s' for reading\n",infile);
  2616.         exit(1);
  2617.     }
  2618.  
  2619. In Icon there is no declaration to bother with and the error checking is
  2620. simple:
  2621.  
  2622.     (in := open(infile,"r")) | stop("I can't open '",infile,"' for reading")
  2623.  
  2624. The extra parentheses are to enforce the order of precedence that's wanted
  2625. but since stop() terminates the program they aren't really needed.  I find
  2626. the Icon example much simpler to read and understand than the C example.
  2627. If you use examples that take advantage of goal directed evaluation the
  2628. simplifications become really amazing.
  2629.  
  2630. I could go on for a long time but you get the idea.  I would still be a die
  2631. hard C fan if I hadn't had a friend practically force me to read The Icon
  2632. Programming Language by Ralph and Madge Griswold.  I'm now a happy convert
  2633. and busy proselytizing everywhere I go.  Try it and you'll get hooked too.
  2634.  
  2635. Jerry Nowlin
  2636. (...!att!ihuxy!nowlin)
  2637.  
  2638. From att!ihuxy!nowlin  Sun Aug 27 15:23:45 1989
  2639. Date: Sun, 27 Aug 89 15:23:45 MST
  2640. Message-Id: <8908272223.AA03566@megaron.arizona.edu>
  2641. Received: by megaron.arizona.edu (5.59-1.7/15)
  2642.     id AA03566; Sun, 27 Aug 89 15:23:45 MST
  2643. From: ihuxy!nowlin (Jerry D Nowlin +1 312 979 0441)
  2644. To: att!arizona!icon-group
  2645. Subject: Re: P.S to why Icon
  2646.  
  2647. Just a P.S. to the last mail I sent.  The simulator I was talking about not
  2648. only parsed a language, it interpreted it, allowed extensive tracing of the
  2649. language as it was interpreted, and generated screen displays.  It also
  2650. generated PostScript, pic, and another color printer language for
  2651. hardcopies of the screen displays.  The entire source was only 3,909 lines.
  2652.  
  2653. In contrast the C program that did nothing but parse the same language and
  2654. generate binary C readable intermediate files was over 7,000 lines.  I know
  2655. these kinds of numbers are open to interpretation but since I wrote both
  2656. programs I think the comparison is still meaningful.  Icon is an elegant
  2657. language.
  2658.  
  2659. Jerry Nowlin
  2660. (...!att!ihuxy!nowlin)
  2661.  
  2662. From icon-group-request  Mon Aug 28 01:26:57 1989
  2663. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2664.     id AA22592; Mon, 28 Aug 89 01:26:57 MST
  2665. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  2666.     id AA04978; Mon, 28 Aug 89 01:16:10 -0700
  2667. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2668.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2669.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2670. Date: 27 Aug 89 22:31:50 GMT
  2671. From: agate!saturn!ucscb.UCSC.EDU!kellyp@ucbvax.Berkeley.EDU  (73716000)
  2672. Organization: University of California, Santa Cruz; CATS
  2673. Subject: looking for Emacs setup for icon programming
  2674. Message-Id: <8901@saturn.ucsc.edu>
  2675. Sender: icon-group-request@arizona.edu
  2676. To: icon-group@arizona.edu
  2677.  
  2678. I'm looking for an Emacs Icon programming set-up file.
  2679. Suggestions?
  2680.  
  2681.  
  2682.  
  2683.  
  2684.  
  2685.  
  2686.  
  2687.  
  2688. Patrick Kelly ----- kellyp@ucscb.UCSC.EDU
  2689.  
  2690. From icon-group-request  Mon Aug 28 09:45:52 1989
  2691. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2692.     id AA19537; Mon, 28 Aug 89 09:45:52 MST
  2693. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  2694.     id AA28017; Mon, 28 Aug 89 09:39:13 -0700
  2695. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2696.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2697.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2698. Date: 28 Aug 89 03:05:41 GMT
  2699. From: sumax!amc-gw!nwnexus!intek01!mark@beaver.cs.washington.edu  (Mark McWiggins)
  2700. Organization: Integration Technologies Inc. (Intek), Bellevue WA
  2701. Subject: Re: Why ICON?
  2702. Message-Id: <236@intek01.UUCP>
  2703. References: <223000001@s.cs.uiuc.edu>
  2704. Sender: icon-group-request@arizona.edu
  2705. To: icon-group@arizona.edu
  2706.  
  2707. mccaugh@s.cs.uiuc.edu writes:
  2708.  
  2709.  
  2710. >I have been reading this notesfile for awhile, and must say I am mystified by
  2711. >its very presence. What is ICON? What is so special about it as a lanaguage
  2712. >that it merits its own notesfile? So far, most of what I've read has been
  2713. >about ICON bugs in Amiga! I would appreciate some explanation about the
  2714. >purpose of this language and whether it is at all worth learning.
  2715.  
  2716. Icon is the successor to Snobol4, a rather weird and wonderful pattern-matching
  2717. language developed by Ralph Griswold et. al., I guess reaching back into the
  2718. 60's.
  2719.  
  2720. Griswold and cohorts took some of the ideas from Snobol and put them into a
  2721. more structured, Pascal-ish language.  (Snobol control structures are
  2722. unusual.)  I haven't really used it, but I have the book and it looks good.
  2723. I've seen a reference recently on automatic generation of compiler BACK ENDS
  2724. (not just another parser generator) that was written in Icon, so obviously
  2725. some high-powered types find it useful.
  2726.  
  2727. I also understand that it runs pretty much everywhere and on everything, and
  2728. since it was developed by public money it's pretty much public domain.  (Last
  2729. I heard; I'm sure someone will correct me if I'm wrong.)
  2730.  
  2731. I've been meaning to look further into Icon myself for a while, and may have
  2732. just convinced myself ... :)
  2733. -- 
  2734. Mark McWiggins            Integration Technologies, Inc. (Intek)
  2735. +1 206 455 9935            DISCLAIMER:  I could be wrong ...
  2736. 1400 112th Ave SE #202        Bellevue WA  98004
  2737. uunet!intek01!mark        Ask me about C++!
  2738.  
  2739. From icon-group-request  Mon Aug 28 14:43:24 1989
  2740. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2741.     id AA09589; Mon, 28 Aug 89 14:43:24 MST
  2742. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  2743.     id AA15597; Mon, 28 Aug 89 14:33:15 -0700
  2744. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2745.     for icon-group@arizona.edu (icon-group@arizona.edu)
  2746.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2747. Date: 28 Aug 89 16:22:30 GMT
  2748. From: att!cbnewsc!kca@ucbvax.Berkeley.EDU  (k.c.archie)
  2749. Organization: AT&T Bell Laboratories
  2750. Subject: Re: Why Icon?
  2751. Message-Id: <2742@cbnewsc.ATT.COM>
  2752. References: <223000001@s.cs.uiuc.edu>, <8908271943.AA28708@megaron.arizona.edu>
  2753. Sender: icon-group-request@arizona.edu
  2754. To: icon-group@arizona.edu
  2755.  
  2756. > What do you use Icon for and why? What don't you
  2757. > use Icon for and why? 
  2758. >    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  2759. >    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  2760.  
  2761. We used Icon to prototype a new test management system we were developing
  2762. several years ago. Since we were experimenting with new testing techniques
  2763. we decided to experiment with new development techniques as well. One
  2764. of the team members was well versed in Icon and convinced us to try it.
  2765.  
  2766. This was a risk as very few people are familiar with Icon. If we
  2767. had gotten into schedule problems on a C project, we could
  2768. grab dozens of people out of the hallways here to help. Not so with
  2769. Icon. But, we found that Icon was simple to pick up, at least a working
  2770. knowledge. I found that I could read and modify Icon code even before I
  2771. had read the book.
  2772.  
  2773. The first release of the system was written largely in Icon and was (and is)
  2774. a great success. Nevertheless, we converted it entirely to C over the
  2775. first couple of years of its life. This was done for two reasons.
  2776. The most important was speed. Since the runtime system is an interpretor,
  2777. large Icon programs are rather slow. 
  2778.  
  2779. The second reason is that it is easier for new people coming into the 
  2780. project to read C code than Icon.
  2781. This appears to contradict what I said above about Icon being easy to learn.
  2782. That is true but most people here are already well versed in C and it is easier
  2783. not to have to teach them a new language.
  2784. But the major drawback was speed. If we had had an Icon compiler, we probably
  2785. would have left the system in Icon.
  2786.  
  2787. A small study indicated that converting Icon to C doubled the size of the
  2788. source code and doubled the execution speed.
  2789.  
  2790. I am convinced by this that Icon is an excellent language for trying out
  2791. ideas before casting them into stone. It could be used for production
  2792. code more easily if it had a compiler and if it had easier access to libraries
  2793. like curses.
  2794.  
  2795. **kent
  2796. Kent Archie att!iwtbv!kca
  2797.  
  2798. From lti!lti.com!talmage  Tue Aug 29 08:17:15 1989
  2799. Received: from BU-IT.BU.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2800.     id AA23401; Tue, 29 Aug 89 08:17:15 MST
  2801. Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7)
  2802.     id AA22697; Tue, 29 Aug 89 11:13:53 EDT
  2803. Received:  by buita.bu.edu (3.2/4.7)
  2804.     id AA09887; Tue, 29 Aug 89 11:14:07 EDT
  2805. Received: from waltham.lti.com by lti.com (4.0/SMI-4.0)
  2806.     id AA03066; Tue, 29 Aug 89 09:56:26 EDT
  2807. Date: Tue, 29 Aug 89 09:56:26 EDT
  2808. From: talmage@lti.com (David Talmage)
  2809. Message-Id: <8908291356.AA03066@lti.com>
  2810. Received: by waltham.lti.com (4.0/SMI-4.0)
  2811.     id AA03695; Tue, 29 Aug 89 09:54:53 EDT
  2812. To: icon-group@arizona.edu
  2813. In-Reply-To: (k.c.archie's message of 28 Aug 89 16:22:30 GMT <2742@cbnewsc.ATT.COM>
  2814. Subject: Why Icon?
  2815. Reply-To: lti!talmage
  2816.  
  2817. > What do you use Icon for and why? What don't you
  2818. > use Icon for and why? 
  2819. >    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  2820. >    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  2821.  
  2822. It took me about two minutes to write a useable "strings" finder (a la
  2823. UNIX's strings(1)) in Icon.
  2824.  
  2825. I've built a travesty generator in Icon.  It's a toy built around a
  2826. frequency table.  You feed it a pattern length, n, and a text, say 5000
  2827. words from Jay McInerney's _Bright Lights, Big City_, and it prints text
  2828. that looks, statistically, as if Jay McInerney wrote it.  The output may
  2829. not be intelligible, but it is easily verified that patterns of some length
  2830. n occur with the same frequency in the input and the output.  As n
  2831. increases, the intelligibility of the output increases and so does the
  2832. output's resemblance to the input.
  2833.  
  2834. After hours, I'm doing some machine translation experiments in Icon.  My
  2835. Amiga now speaks, more or less, Esperanto.  By December, I think I'll have
  2836. a (possibly useful) Esperanto-to-English translator.  Would that I were a
  2837. student again so I could spend more time on this project!
  2838.  
  2839.  
  2840. DT
  2841. ------------------------------------------------------------------------------
  2842. David W. Talmage, Systems Programmer        ...!{buita,bbn}!lti!talmage
  2843. Language Technology, Inc.            talmage%lti.uucp@bu-it.bu.edu
  2844. 27 Congress St., Salem, MA 01970        (508) 741-1507
  2845.  
  2846. From jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK  Tue Aug 29 14:31:08 1989
  2847. Received: from NSFNET-RELAY.AC.UK by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2848.     id AA19269; Tue, 29 Aug 89 14:31:08 MST
  2849. Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK   via Janet with NIFTP
  2850.            id aa10697; 29 Aug 89 21:49 BST
  2851. Date: Tue, 29 Aug 89 21:57:06 BST
  2852. Message-Id: <27070.8908292057@aiai.ed.ac.uk>
  2853. From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
  2854. Subject: Re: Why Icon?
  2855. To: icon-group@arizona.edu
  2856.  
  2857. > What do you use Icon for and why? What don't you
  2858. > use Icon for and why? 
  2859.  
  2860. I like Icon, but I don't use it very much because it's not (or at least
  2861. wasn't) interactive.  I like to be able to define and call procedures
  2862. interactively, like I can in Lisp or Prolog.
  2863.  
  2864. From gudeman  Tue Aug 29 14:50:34 1989
  2865. Date: Tue, 29 Aug 89 14:50:34 MST
  2866. From: "David Gudeman" <gudeman>
  2867. Message-Id: <8908292150.AA20214@megaron.arizona.edu>
  2868. Received: by megaron.arizona.edu (5.59-1.7/15)
  2869.     id AA20214; Tue, 29 Aug 89 14:50:34 MST
  2870. To: agate!saturn!ucscb.UCSC.EDU!kellyp@ucbvax.Berkeley.EDU
  2871. Cc: icon-group@arizona.edu
  2872. In-Reply-To: (73716000's message of 27 Aug 89 22:31:50 GMT <8901@saturn.ucsc.edu>
  2873. Subject: looking for Emacs setup for icon programming
  2874.  
  2875. What Emacs are you using, GNU, Unipress, Micro-, etc.?
  2876.  
  2877. From tenaglia%astroatc.UUCP@cs.wisc.edu  Thu Aug 31 06:12:43 1989
  2878. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  2879.     id AA23228; Thu, 31 Aug 89 06:12:43 MST
  2880. Received: from astroatc.UUCP by spool.cs.wisc.edu; Thu, 31 Aug 89 08:09:12 -0500
  2881. Received: by astroatc.UUCP (5.51/4.7)
  2882.     id AA28882; Thu, 31 Aug 89 07:52:07 CDT
  2883. Date: Thu, 31 Aug 89 07:52:07 CDT
  2884. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  2885. Message-Id: <8908311252.AA28882@astroatc.UUCP>
  2886. To: icon-group@arizona.edu
  2887.  
  2888. Dear Icon-group,
  2889.  
  2890. Here's another of my favorite and handy utilities. I include the instructions
  2891. first, then the code. There is a variable called 'os' which kind of tells it
  2892. how to behave on different platforms. It works best in unix and vms. In DOS
  2893. it may run short of memory (I use Icon 5.9 in DOS because it uses less memory).
  2894.  
  2895. Chris Tenaglia
  2896. Astronautics Corporation of America
  2897. 4115 N. Teutonia Avenue
  2898. Milwaukee, Wi 53209 USA
  2899. (414) 447-8200 X-421
  2900.  
  2901.                 USAGE AND DESCRIPTION OF THE IAWK/IGREP UTILITY
  2902.  
  2903.  
  2904. INTRODUCTION :
  2905.  
  2906.      This  utility  was  written  because  of  something  I  observed in the
  2907.      creation  of many file mungers/analyzers using the icon language. There
  2908.      were   all  the  same  program  except  for  a  couple  of  lines  that
  2909.      accomplished the actual filtering or editing. So why should one rewrite
  2910.      the  same  program over and over again, when the same job could be done
  2911.      by  a  computer?  So  that  is what IAWK/IGREP is. Actually that is two
  2912.      different  names  for  the  same program. 2 different names were chosen
  2913.      because the program is used basically 2 different ways.
  2914.  
  2915.      AWK  is  a  unix  utility used to gross global conversions on files. It
  2916.      reads  one  file  and  writes another. The AWK language file supplies a
  2917.      series  of expressions and rules that perform the filtering of the data
  2918.      file. It is a nonprocedural language.
  2919.  
  2920.      GREP is a directory/file scanning utility. A byte stream is run through
  2921.      it, and a 'regular expression' is beat against the stream. And when the
  2922.      regular expression is matched, the stream record is displayed.
  2923.  
  2924.      These  are  useful  but limitted. The regular expression is a powerful,
  2925.      but  nonprocedural construct. Therefore, what about such a utility that
  2926.      used  icon  expressions?  They can be more precise, and do more complex
  2927.      things.  And  so  this  is  just  what was done. When run with only one
  2928.      filespec,   the  program  behaves  like  GREP,  simply  displaying  the
  2929.      analysis.  When  run  with  two  filespecs,  it  is  running  like AWK,
  2930.      generating the second filespec as the output file.
  2931.  
  2932. USAGE :
  2933.  
  2934.      USAGE: iawk infile [outfile]
  2935.      Once  invoked,  you  will  be prompted for a series of expressions. The
  2936.      prompting will stop after the first empty line. This signals the end of
  2937.      the  expression  entry  phase.  The expressions should be icon language
  2938.      expressions.  They  are inserted into a program called grepawk.icn. Its
  2939.      basic form is as follows :
  2940.  
  2941.           global MOST HANDY VARIABLES
  2942.           procedure main()
  2943.           INITIALIZE GLOBAL VARIABLES
  2944.           while write(update(read()))
  2945.           OUTPUT NUMERICAL SUMMARY IF ANY
  2946.           end
  2947.  
  2948.           procedure update(line)
  2949.           # ... user inputted expressions appear here
  2950.           end
  2951.  
  2952.           procedure parse(text,delims)
  2953.           # ... converts string text to list w/respect to delims
  2954.           end
  2955.  
  2956.                 USAGE AND DESCRIPTION OF THE IAWK/IGREP UTILITY
  2957.  
  2958.  
  2959. USAGE : cont...
  2960.  
  2961.      USAGE: iawk infile [outfile]    continued ...
  2962.  
  2963.      As  you  may  have  noticed,  there  is  a  goodly collection of global
  2964.      variables. These are very useful. The goal of the program is as follows
  2965.      Whatever update() returns, is what is displayed or written to the file.
  2966.      Below  is  a  description  of the global variables, in case you haven't
  2967.      figured it out from the source listing above.
  2968.  
  2969.      line      - The line read in.
  2970.      num       - The line number (position) within the input file.
  2971.      flags     - These are used to toggle certain features. Currently
  2972.                  only one flag "nocount" is supported. Append "nocount"
  2973.                  to flags to suppress the final count summary.
  2974.      count     - A table that holds counts of things. All non-zero
  2975.                  entries are summarized at the end of the process.
  2976.                  w1 is the width of the entry column (default=20).
  2977.                  w2 is the width of the tally column (default=8).
  2978.      ebcdic    - A mapping table for ascii/ebcdic file translations.
  2979.      unascii   - A mapping table useful for wordstar print files.
  2980.      alpha     - Alpha characters used with rot13.
  2981.      rot13     - Cheap and dirty encryption table.
  2982. tty, crt, kbd  - Used to force output to screen or take output from
  2983.                  keyboard. These are all identical.
  2984.  
  2985.      You may begin the expressions section with such things as ...
  2986.  
  2987.      static var1,var2,...
  2988.      initial {
  2989.              var1 := ....
  2990.              var2 := ...
  2991.              }
  2992.  
  2993.      Remember  that  the  object  of the 'return' is what is displayed in an
  2994.      IGREP or written to the file in an IAWK. Upon completion several things
  2995.      happen.  If the table count has been loaded with anything, a summary is
  2996.      output. This can be suppressed by appending "nocount" to the flags var-
  2997.      iable.   Finally the grepawk files that were created to do the work are
  2998.      deleted unless "keep" is appended to the flags variable.
  2999.  
  3000.      The program itself follows. Clip and use (about 90 to 100 lines).
  3001.  
  3002. #TITLE ICON EQUIVALENT OF GREP AND AWK
  3003. #SUB ONE PROGRAM DOES BOTH 
  3004. #EJECT
  3005. #################################################################
  3006. #                                                               #
  3007. # IAWK.ICN              08/29/88              BY CHRIS TENAGLIA #
  3008. # IGREP.ICN                                                     #
  3009. #                                                               #
  3010. #################################################################
  3011. procedure main(param)
  3012.   platform := "vms"    # either unix, vms, or dos
  3013.   case platform of {
  3014.                    "unix" : vdu := "/dev/tty"
  3015.                    "vms"  : vdu := "tt:"
  3016.                    "dos"  : vdu := "con"
  3017.                  default  : stop("platform ",platform," not recognized.")
  3018.                    }
  3019.   front := [
  3020.            "#################################################################",
  3021.            "#                                                               #",
  3022.            "# GREPAWK.ICN     " || &dateline || "         BY TENAGLIA       #",
  3023.            "#                                                               #",
  3024.            "# THIS IS THE INTERMEDIATE PROGRAM THAT HANDLES THE MUNGING     #",
  3025.            "#                                                               #",
  3026.            "#################################################################",
  3027.            "global count,crt,tty,alpha,rot13,ebcdic,kbd,lnum",
  3028.            "procedure main()",
  3029.            "  alpha:= \042ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\042",                        
  3030.            "  rot13:= \042NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm\042",
  3031.            " ebcdic:= \042\\000\\001\\002\\003\\234\\011\\206\\177\\227\\215\\216\\013\\014\\015\\016\\017\042||",
  3032.            "          \042\\020\\021\\022\\023\\235\\205\\010\\207\\030\\031\\222\\217\\034\\035\\036\\037\042||",
  3033.            "          \042\\200\\201\\202\\203\\204\\012\\027\\033\\210\\211\\212\\213\\214\\005\\006\\007\042||",
  3034.            "          \042\\220\\221\\026\\223\\224\\225\\226\\004\\230\\231\\232\\233\\024\\025\\236\\032\042||",
  3035.            "          \042\\040\\240\\241\\242\\243\\244\\245\\246\\247\\250\\133\\056\\074\\050\\053\\041\042||",
  3036.            "          \042\\046\\251\\252\\253\\254\\255\\256\\257\\260\\261\\135\\044\\052\\051\\073\\136\042||",
  3037.            "          \042\\055\\057\\262\\263\\264\\265\\266\\267\\270\\271\\174\\054\\045\\137\\076\\077\042||",
  3038.            "          \042\\272\\273\\274\\275\\276\\277\\300\\301\\302\\140\\072\\043\\100\\047\\075\\042\042||",
  3039.            "          \042\\303\\141\\142\\143\\144\\145\\146\\147\\150\\151\\304\\305\\306\\307\\310\\311\042||",
  3040.            "          \042\\312\\152\\153\\154\\155\\156\\157\\160\\161\\162\\313\\314\\315\\316\\317\\320\042||",
  3041.            "          \042\\321\\176\\163\\164\\165\\166\\167\\170\\171\\172\\322\\323\\324\\325\\326\\327\042||",
  3042.            "          \042\\330\\331\\332\\333\\334\\335\\336\\337\\340\\341\\342\\343\\344\\345\\346\\347\042||",
  3043.            "          \042\\173\\101\\102\\103\\104\\105\\106\\107\\110\\111\\350\\351\\352\\353\\354\\355\042||",
  3044.            "          \042\\175\\112\\113\\114\\115\\116\\117\\120\\121\\122\\356\\357\\360\\361\\362\\363\042||",
  3045.            "          \042\\134\\237\\123\\124\\125\\126\\127\\130\\131\\132\\364\\365\\366\\367\\370\\371\042||",
  3046.            "          \042\\060\\061\\062\\063\\064\\065\\066\\067\\070\\071\\372\\373\\374\\375\\376\\377\042",
  3047.            "  crt  := open(\042" || vdu || "\042,\042b\042)",
  3048.            "  kbd  := crt ; tty := crt",
  3049.            "  lnum := 1",
  3050.            "  count := table(0)",
  3051.            "  while line := read() do",
  3052.            "    {",
  3053.            "    write(update(line,lnum))",
  3054.            "    lnum +:= 1",
  3055.            "    }",
  3056.            "  write(crt,\042\\e[1;7mProcess Completed !\\e[m\042)",
  3057.            "  end",
  3058.            "procedure parse(line,vals)",
  3059.            "  static chars",
  3060.            "  initial chars := &cset -- vals",
  3061.            "  tokens := []",
  3062.            "  line ? while tab(upto(chars)) do put(tokens,tab(many(chars)))",
  3063.            "  return tokens",
  3064.            "  end",
  3065.            "procedure update(line,num)"
  3066.            ]      
  3067.   items := []
  3068.   if *param = 0 then stop("Missing filespec(s)\n",
  3069.                           "Usage: (awk or grep) infile [outfile]")
  3070.   if *param = 1 then write("Grepping ",param[1],"\n")
  3071.   if *param = 2 then write("Awking from ",param[1]," to ",param[2],"\n")
  3072.   repeat
  3073.     {
  3074.     writes("\e[1;7m_expression :\e[m ")
  3075.     if not(line := read()) then break
  3076.     if line == "" then break
  3077.     put(items,("  " || line))
  3078.     }
  3079.   (out := open("grepawk.icn","w")) | stop("Can't create grepawk.icn !")
  3080.   every write(out,!front)
  3081.   every write(out,!items)
  3082.   write(out,"  end")
  3083.   close(out)
  3084.   write("\n\e[1;7mCompiling expressions for transmogrification.\e[m\n")
  3085.   From := (" <" || param[1])|""
  3086.   To   := (" >" || param[2])|""
  3087.   system(("icont grepawk.icn -x" || From || To))
  3088.   if not find("keep",flags) then
  3089.     {
  3090.     while remove("grepawk.icn") do writes(".")
  3091.     while remove("grepawk.icx") do writes(".")
  3092.     while remove("grepawk")     do writes(".")
  3093.     }
  3094. end
  3095. #########################################################################
  3096.  
  3097. From tenaglia%astroatc.UUCP@cs.wisc.edu  Thu Aug 31 08:12:22 1989
  3098. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3099.     id AA28445; Thu, 31 Aug 89 08:12:22 MST
  3100. Received: from astroatc.UUCP by spool.cs.wisc.edu; Thu, 31 Aug 89 10:09:02 -0500
  3101. Received: by astroatc.UUCP (5.51/4.7)
  3102.     id AA03653; Thu, 31 Aug 89 10:05:57 CDT
  3103. Date: Thu, 31 Aug 89 10:05:57 CDT
  3104. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  3105. Message-Id: <8908311505.AA03653@astroatc.UUCP>
  3106. To: icon-group@arizona.edu
  3107.  
  3108. Dear Icon_Group,
  3109.  
  3110. Here at Astronautics in Milwaukee we have ICON on VAX/VMS, Unix Workstations
  3111. and superminis, and MS-DOS PCs. We have found it very portable. I'd like to
  3112. flame a little on the matter.
  3113.  
  3114. 1. Under VAX/VMS it provides some unix/shell like functionality. For instance
  3115.    a generic filter can be written and the output redirected such as follows,
  3116.    $ iconx filter <input_file >outputfile. You can also open a process for
  3117.    read or write like a file using 'open' with the "pr" or "pw" option.
  3118.  
  3119. 2. Icon is fairly quick and easy to learn. It is a very rich language that can
  3120.    be used in very creative fashions. In the projects we've done, we had to
  3121.    agree on rules of style and complexity to keep the code maintainable. Icon
  3122.    styles can be in the spirit of pascal, or lisp, or c, or ada, etc,...
  3123.    We save the clever stuff for our personal research and utilities. Best of
  3124.    all icon doesn't violate structured programming rules by implementing a
  3125.    "goto" statement like BASIC, C, FORTRAN, PASCAL, or ADA. Another great
  3126.    feature is that all of it's functions return something useful, not just a
  3127.    0 or 1 or -1 or a pointer. This makes everything 'fit' together well.
  3128.  
  3129. 3. It's in the public domain. There are commercial versions beginning to
  3130.    appear. I think the demand for native mode compilers will drive this,
  3131.    and I think it is OK if the Icon-Project wants it to be this way. I think
  3132.    the public domain nature of the language is fantastic. It's what I used
  3133.    to get my company to obtain it.
  3134.  
  3135. 4. Disadvantages...  (Playing the devils advocate)
  3136.    To be fair I've included what I consider to be disadvantages as well. First
  3137.    is that is can be slow since it doesn't generate optimized pure executables.
  3138.    This is especially true on VAX/VMS on an 11/780 or weaker CPU.
  3139.    The greatest disadvantage is it spoils you after a time. When you return to
  3140.    some of the old languages like BASIC, FORTRAN, PASCAL, or C they seem so
  3141.    awkward(BASIC,FORTRAN), cryptic(C), and nitpicky(PASCAL,ADA) you dread
  3142.    having to come back.
  3143.  
  3144. 5. Useful work done with ICON here includes such things as ...
  3145.    a. Personal databases.
  3146.    b. BASIC style line editor for hardcopy or graphics devices.
  3147.    c. PLM to C source language transmogrifier.
  3148.    d. Numerous file translation/conversion tools.
  3149.    e. Graphics interface and programs using unix 'plot'.
  3150.    f. VAX System Mgt report generators using the accounting data.
  3151.    g. Unix System management utilities and reports.
  3152.  
  3153. Chris Tenaglia
  3154. Astronautics Corporation of America
  3155. 4115 N. Teutonia Avenue
  3156. Milwaukee, Wi 53209 USA
  3157. (414) 447-8200 X-421
  3158.  
  3159.  
  3160. From dscargo@cim-vax.honeywell.com  Thu Aug 31 15:08:17 1989
  3161. Message-Id: <8908312208.AA05244@megaron.arizona.edu>
  3162. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3163.     id AA05244; Thu, 31 Aug 89 15:08:17 MST
  3164. Date: 31 Aug 89 16:46:00 CST
  3165. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  3166. Subject: IAWK
  3167. To: "icon-group" <icon-group@arizona.edu>
  3168.  
  3169. After seeing and using IAWK (albeit in a trivial fashion) I realized that it
  3170. lacked some features that I think would make it much more useful.
  3171.  
  3172. (1) The code that was input by the user should be written to a log file of
  3173. some sort, for future reference.
  3174.  
  3175. (2) There should be some kind of simple include directive that allows the user
  3176. to retrieve pieces of code from a specified file.
  3177.  
  3178. (3) There should be an option to suppress output of empty results.  (I hadn't
  3179. tried having update return &fail as a result, but that might work.)
  3180.  
  3181. (4) The name of the output routine should be a global variable intialized to
  3182. the standard output routine. The user can then input his own output routine
  3183. and change the value of the variable containing the routine to call.  This
  3184. allows the user to get more control of the output when needed.
  3185.  
  3186. Changes 1 and 2 used together would allow some iteration, providing a method
  3187. for the users to make an initial guess as to what they want and then tuning
  3188. the results.  (Alternatively the deletion of the generated program could be
  3189. turned off or made optional.)
  3190.  
  3191. Any responses or other opinions (especially invited from the author).
  3192.  
  3193. dsc
  3194.  
  3195.  
  3196. From tenaglia%astroatc.UUCP@cs.wisc.edu  Sat Sep  2 07:18:54 1989
  3197. Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3198.     id AA14207; Sat, 2 Sep 89 07:18:54 MST
  3199. Received: from astroatc.UUCP by spool.cs.wisc.edu; Sat, 2 Sep 89 09:15:32 -0500
  3200. Received: by astroatc.UUCP (5.51/4.7)
  3201.     id AA09263; Sat, 2 Sep 89 08:25:14 CDT
  3202. Date: Sat, 2 Sep 89 08:25:14 CDT
  3203. From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia)
  3204. Message-Id: <8909021325.AA09263@astroatc.UUCP>
  3205. To: icon-group@arizona.edu, dscargo@cim-vax.honeywell.com
  3206. Subject: ignature
  3207. Cc: icon-group@arizona.edu
  3208.  
  3209. Thanks for the observations. I like the 'include' idea a lot. I'm not
  3210. sure but I think if you at the 'while remove' lines they are (should)
  3211. be nested in a 'if not(find("keep",flags)) then' structure. Thus, if
  3212. you have an 'initial' block with 'flags ||:= "keep"' the grepawk
  3213. files will not be removed. On supression of empty output, if nothing
  3214. is returned, it fails automatically, causing the write() in the caller
  3215. to fail.
  3216.  
  3217. The static and initial are very useful in the update() procedure.
  3218. Also if you need more procedures, you can end the update() procedure
  3219. with 'end' and then start 'procedure ????()' on the next line.
  3220. There are global variables called tty, crt, and kbd. These equate
  3221. to stdin and stdout for direct i/o. I use them for debugging usually.
  3222.  
  3223. I think I will try the 'include' idea, and implement another flags
  3224. value called "log" that will generate an iawk.log file that will
  3225. record the expressions for later inclusion.
  3226.  
  3227. If you add some goodies, don't hesitate to mail me a sample.
  3228.  
  3229. Yours truly,
  3230.  
  3231. Chris Tenaglia
  3232. Astronautics Corporation of America
  3233. 4115 N. Teutonia Avenue
  3234. Milwaukee, Wi 53209 USA
  3235. (414) 447-8200 X-421
  3236.  
  3237.  
  3238. From icon-group-request  Mon Sep  4 05:48:56 1989
  3239. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3240.     id AA07747; Mon, 4 Sep 89 05:48:56 MST
  3241. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  3242.     id AA13394; Mon, 4 Sep 89 05:35:37 -0700
  3243. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3244.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3245.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3246. Date: 4 Sep 89 09:53:44 GMT
  3247. From: mcsun!sunic!dkuug!iesd!iesd.auc.dk!kasper@uunet.uu.net  (Kasper Osterbye)
  3248. Organization: Mathematics & Computer Science, University of Aalborg
  3249. Subject: Amiga Icon ?
  3250. Message-Id: <1989Sep4.095344.24219@iesd.auc.dk>
  3251. Sender: icon-group-request@arizona.edu
  3252. To: icon-group@arizona.edu
  3253.  
  3254. Hi,
  3255.  
  3256. I want to get hold of the latest Icon version for the amiga! I
  3257. know that it is at the university of Arizona, but I need the
  3258. exact CITENUMBER (that is NUMBER, not name, as our host table
  3259. is nect to nonexistent). Can anyone please help me?
  3260.  
  3261. Thanks in advance,
  3262.     Kasper Osterbye.
  3263.  
  3264. -- 
  3265. Kasper Osterbye                     Internet: iesd!kasper@uunet.uu.net
  3266. Institute for electronic systems    UUCP: ...!mcvax!iesd!kasper
  3267. Strandvejen 19, 9000 Aalborg
  3268. DENMARK. (W) +45 98 13 87 88-285  (H) +45 98 37 30 65
  3269.  
  3270. From icon-group-request  Wed Sep  6 03:49:29 1989
  3271. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3272.     id AA25884; Wed, 6 Sep 89 03:49:29 MST
  3273. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  3274.     id AA22616; Wed, 6 Sep 89 03:35:03 -0700
  3275. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3276.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3277.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3278. Date: 6 Sep 89 00:00:21 GMT
  3279. From: mstan!amull@uunet.uu.net  (Andrew P. Mullhaupt)
  3280. Organization: Morgan Stanley & Co. NY, NY
  3281. Subject: Availablility of PD ICON
  3282. Message-Id: <366@ewr.Morgan.COM>
  3283. Sender: icon-group-request@arizona.edu
  3284. To: icon-group@arizona.edu
  3285.  
  3286. I was intrigued to find that SNOBOL4 had a successor, reportedly
  3287. in the public domain. Is this available for IBM-PC/AT boxes running
  3288. MS-DOS or OS/2?
  3289.  
  3290. Thanks
  3291. Andrew Mullhaupt
  3292.  
  3293.  
  3294. From icon-group-request  Wed Sep  6 20:34:50 1989
  3295. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3296.     id AA04207; Wed, 6 Sep 89 20:34:50 MST
  3297. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  3298.     id AA15837; Wed, 6 Sep 89 20:26:46 -0700
  3299. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3300.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3301.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3302. Date: 6 Sep 89 15:50:20 GMT
  3303. From: esquire!yost@nyu.edu  (David A. Yost)
  3304. Organization: DP&W, New York, NY
  3305. Subject: anyone have sun4 coexpressions working?
  3306. Message-Id: <1398@esquire.UUCP>
  3307. Sender: icon-group-request@arizona.edu
  3308. To: icon-group@arizona.edu
  3309.  
  3310. If so, please reply to yost@esquire.dpw.COM
  3311. and to icon-project@arizona.edu.
  3312. Thanks.
  3313.  
  3314.  --dave yost
  3315.  
  3316. From icon-group-request  Fri Sep  8 10:06:11 1989
  3317. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3318.     id AA12395; Fri, 8 Sep 89 10:06:11 MST
  3319. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  3320.     id AA11758; Fri, 8 Sep 89 09:54:52 -0700
  3321. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3322.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3323.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3324. Date: 8 Sep 89 16:43:55 GMT
  3325. From: dino!atanasoff!atanasoff.cs.iastate.edu!lakshmin@uunet.uu.net  (Lakshminarayana Rudrabhatla)
  3326. Organization: Iowa State U. Computer Science Department, Ames, IA
  3327. Subject: criticism of icon
  3328. Message-Id: <1489@atanasoff.cs.iastate.edu>
  3329. Sender: icon-group-request@arizona.edu
  3330. To: icon-group@arizona.edu
  3331.  
  3332.  
  3333. procedure main()
  3334.  
  3335.     words:=table()
  3336.     line_no:=0
  3337.     while line:=read() do {
  3338.         line_no +:=1
  3339.         write(left(line_no,6),left(line,40))
  3340.         line:=map(line)
  3341.         i:=1
  3342.         while j:=upto(&lcase,line,i) do {
  3343.         i:=many(&lcase,line,j)
  3344.         if *line[i:j] >= 3
  3345.         then {if   \words[line[i:j]]       #line 14
  3346.                   then insert(words[line[i:j]],line_no)    #line 15
  3347.               else {words[line[i:j]]:=set()    #line 16
  3348.                     insert(words[line[i:j]], line_no)   #line 17 
  3349.               }
  3350.                      }
  3351.         }
  3352.         }
  3353.  
  3354.       words:=sort(words)
  3355.     i:=0
  3356.     while pair:=words[i +:=1] do  {
  3357.        writes(left(pair[1],10),":")
  3358.        s:=!pair[2]
  3359.        pair[2]:=delete(pair[2],!pair[2])
  3360.            every s ||:= ", " ||!pair[2]
  3361.        write(s)
  3362.        }
  3363.     end
  3364.  
  3365. ---------------------------------------------------------
  3366. question:
  3367.    
  3368.    in lines 14 thru 17 of the above program i had to implicitly
  3369.    declare the type of assigned value of table "words"
  3370.    as set(){ref: line#16} before i could perform
  3371.    the insert op. in line #15.
  3372.    this problem arose because &null would'nt coerce automatically
  3373.    to set(). this inspite of the claim that icon is dynamically typed.
  3374.    As a user, my "natural" impression was to assume that &null could
  3375.    represent an set() or "" or [] , as the case may be, since
  3376.    this facilitates easier and logical manipulation of the
  3377.    assigned value part of the structure "table" in general.
  3378.    
  3379.    does anyone see any problems with modifying the language to allow
  3380.    coercion of &null to set() or "" or [], as the case maybe depending
  3381.    upon the type of operation being performed on the assigned part of
  3382.    the structure "table".
  3383.  
  3384. From wgg@june.cs.washington.edu  Fri Sep  8 11:43:31 1989
  3385. Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3386.     id AA19457; Fri, 8 Sep 89 11:43:31 MST
  3387. Received: by june.cs.washington.edu (5.61/7.0j)
  3388.     id AA19647; Fri, 8 Sep 89 11:40:09 -0700
  3389. Date: Fri, 8 Sep 89 11:40:09 -0700
  3390. From: wgg@june.cs.washington.edu (William Griswold)
  3391. Return-Path: <wgg@june.cs.washington.edu>
  3392. Message-Id: <8909081840.AA19647@june.cs.washington.edu>
  3393. To: dino!atanasoff!atanasoff.cs.iastate.edu!lakshmin@uunet.uu.net,
  3394.         icon-group@arizona.edu
  3395. Subject: Re:  criticism of icon
  3396.  
  3397. >Date: 8 Sep 89 16:43:55 GMT
  3398. >From: dino!atanasoff!atanasoff.cs.iastate.edu!lakshmin@uunet.uu.net  (Lakshminarayana Rudrabhatla)
  3399. >Organization: Iowa State U. Computer Science Department, Ames, IA
  3400. >Subject: criticism of icon
  3401. >Sender: icon-group-request@arizona.edu
  3402. >To: icon-group@arizona.edu
  3403. >Errors-To: icon-group-errors@arizona.edu
  3404. >
  3405. >
  3406. ... program ...
  3407. >---------------------------------------------------------
  3408. >question:
  3409. >   
  3410. >   in lines 14 thru 17 of the above program i had to implicitly
  3411. >   declare the type of assigned value of table "words"
  3412. >   as set(){ref: line#16} before i could perform
  3413. >   the insert op. in line #15.
  3414. >   this problem arose because &null would'nt coerce automatically
  3415. >   to set(). this inspite of the claim that icon is dynamically typed.
  3416. >   As a user, my "natural" impression was to assume that &null could
  3417. >   represent an set() or "" or [] , as the case may be, since
  3418. >   this facilitates easier and logical manipulation of the
  3419. >   assigned value part of the structure "table" in general.
  3420. >   
  3421. >   does anyone see any problems with modifying the language to allow
  3422. >   coercion of &null to set() or "" or [], as the case maybe depending
  3423. >   upon the type of operation being performed on the assigned part of
  3424. >   the structure "table".
  3425. >
  3426.  
  3427. In language design there is a constant tension between flexibility and
  3428. protecting the programmer from himself or herself.  One of the design
  3429. decisions of Icon was that if the programmer hasn't said what a value is,
  3430. that it is null.  If this weren't the case, every time I used an uninitialized
  3431. variable (and I had intended it be initialzed with some special value, but had
  3432. forgotten to do it) it would default to something else (perhaps close), and 
  3433. it could be very difficult to debug.
  3434.  
  3435. I can personally testify that this feature of Icon has saved me hours of
  3436. debugging time.  When Icon terminates on an error ``Integer expected,
  3437. offending value: null'', I know what has gone wrong.  However, if my
  3438. porgram terminates normally, and I find the integer result is off by
  3439. 17, I don't quite know where to begin to look.  This feature of
  3440. Icon is especially valuable for larger programs, in which it is difficult
  3441. to keep track of everything that is going on, or perhaps many people are
  3442. writing code.
  3443.  
  3444. Also, it is not entirely clear from the code you provided whether the value
  3445. should be a set or table, since table has insert as well (although it
  3446. wouldn't be doing anything incredibly reasonable here).  In fact, you'll 
  3447. run into the same problem whenever you have a polymorphic operation that 
  3448. isn't binary symmetric.  If default behavior becomes very complicated, it
  3449. is better to do without. 
  3450.  
  3451. Actually, there *is* a more concise solution to your problem.  Here is the
  3452. code that you annotated in your previous example, and a shorter version.
  3453.  
  3454. >        then {if   \words[line[i:j]]       #line 14
  3455. >                  then insert(words[line[i:j]],line_no)    #line 15
  3456. >              else {words[line[i:j]]:=set()    #line 16
  3457. >                    insert(words[line[i:j]], line_no)   #line 17 
  3458. >              }
  3459. >                     }
  3460.  
  3461.         then { /words[line[i:j]] := set()        #line 14
  3462.                   insert(words[line[i:j]],line_no)    #line 17
  3463.                      }
  3464.  
  3465. It may not be automatic, but it is only one line longer than the solution
  3466. you'd like to have.  You can actually do it in one line, but it isn't
  3467. pretty.
  3468.  
  3469.                     Bill Griswold
  3470.  
  3471. From naucse!sbw  Fri Sep  8 12:46:40 1989
  3472. Received: by megaron.arizona.edu (5.59-1.7/15)
  3473.     id AA22741; Fri, 8 Sep 89 12:46:40 MST
  3474. Message-Id: <8909081853.AA12663@naucse>
  3475. Date: Fri, 8 Sep 89 11:53:29 MST
  3476. X-Mailer: Mail User's Shell (6.5 4/17/89)
  3477. From: naucse!naucse!sbw (Steve Wampler)
  3478. To: arizona!wgg@june.cs.washington.edu (William Griswold)
  3479. Subject: Re:  criticism of icon
  3480. Cc: arizona!icon-group
  3481.  
  3482. On Sep 8 at 11:42, William Griswold writes:
  3483. }         then { /words[line[i:j]] := set()        #line 14
  3484. }                   insert(words[line[i:j]],line_no)    #line 17
  3485. }                      }
  3486. } It may not be automatic, but it is only one line longer than the solution
  3487. } you'd like to have.  You can actually do it in one line, but it isn't
  3488. } pretty.
  3489. Is too:
  3490.  
  3491.         words[line[i:j]] := insert(\words[line[i:j]]|set(), line_no)
  3492.  
  3493. well, maybe if we do the assignment:  word := line[i:j] first, then:
  3494.  
  3495.         words[word] := insert(\words[word]|set(), line_no)
  3496.  
  3497. well, maybe if... nevermind.
  3498.  
  3499. -- 
  3500.     Steve Wampler
  3501.     {....!arizona!naucse!sbw}
  3502.  
  3503. From icon-group-request  Sun Sep 10 08:51:22 1989
  3504. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3505.     id AA00773; Sun, 10 Sep 89 08:51:22 MST
  3506. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  3507.     id AA26355; Sun, 10 Sep 89 08:42:17 -0700
  3508. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3509.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3510.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3511. Date: 10 Sep 89 15:26:23 GMT
  3512. From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  3513. Subject: Re: Why ICON?
  3514. Message-Id: <7174@rpi.edu>
  3515. References: <223000001@s.cs.uiuc.edu>, <8908271943.AA28708@megaron.arizona.edu>
  3516. Sender: icon-group-request@arizona.edu
  3517. To: icon-group@arizona.edu
  3518.  
  3519. In article <8908271943.AA28708@megaron.arizona.edu>, kwalker@ARIZONA.EDU ("Kenneth Walker") writes:
  3520. > > What is so special about it as a lanaguage
  3521. > > that it merits its own notesfile? So far, most of what I've read has been
  3522. > > about ICON bugs in Amiga! I would appreciate some explanation about the
  3523. > > purpose of this language and whether it is at all worth learning.
  3524.  
  3525. Why does it have its own newsgroup? Well since it is a government funded
  3526. research project I think many people are interested in being able contibute
  3527. ideas. It is also handy to have a newsgroup for each language.
  3528.  
  3529. > I am on the Icon Project, so my opinions are somewhat biased. Perhaps
  3530. > others of you can comment on what you find to be Icon's strengths
  3531. > and weaknesses. What do you use Icon for and why? What don't you
  3532. > use Icon for and why? (Perhaps I will express some of my biased
  3533. > opinions after others have commented.)
  3534.  
  3535. Why do I use Icon?
  3536.  
  3537. Well, I use Icon because I like to experiment with neat computer languages
  3538. and Icon is one, and (wow neato!) it is almost free (duplication and mailing
  3539. costs only - or FTP, of course you still have to shell out $30 for the manual
  3540. but a total cost of $50 for a language of this power is just spectacular. And
  3541. gee, if you are interested in compiler design etc, the source plus a book
  3542. describing the implementation may be had for a total cost of $80 or so.
  3543.  
  3544. What do I program with it? Well one of my interests is writing text adventure
  3545. games. A major feature of such games is a parser, it took me about 50 hours
  3546. to write a decent parser in Icon, when I wrote in Pascal, it took me almost
  3547. that long to write a very trivial parser. When I decided I wanted the program
  3548. to word wrap its output, it took me 1 hour to write a word wrap routine.
  3549.  
  3550. Another advantage of Icon: its extremely portable! True there are very few
  3551. I/O procedures (such as graphics, cursor control {although maybe this is
  3552. available on bigger systems?}, sound etc) but the bulk of the code is
  3553. completely portable (well except co-expressions if your target doesn't support
  3554. them). A developer who desired more fancy I/O could easily get the source code
  3555. and add the procedures he needed and then for porting considerations, carefully
  3556. control where these non-standard procedures are used. Since Icon is in the
  3557. public domain, the modified executor could be distributed with programs.
  3558.  
  3559. On the subject of portability I have a few questions:
  3560.  
  3561.    are executable images (.ICX) portable to all machines?
  3562.  
  3563.    how about some way to allow a standard call to included assembly language
  3564.    routines (or .OBJ type files from compilers)? Is this what personalized
  3565.    interpreters allow? If so could this feature be ported to the micro domain?
  3566.  
  3567.    how about a standard of some sort for system calls with some standardization
  3568.    for particular calls such as something like -
  3569.  
  3570.        syscall("movecursor",x,y)
  3571.  
  3572.           where x and y would be from 1 to n and translated as required, errors
  3573.           would be the result if the particular system did not support cursor
  3574.           addressing.
  3575.  
  3576.    along with this a variable &syscalls which listed the featured syscalls in
  3577.    the particular implementation (and perhaps any limits)
  3578.  
  3579.     the problem I see (with examples from the IBM-PC) is how to deal with the
  3580.     fact that micros will always come out with some usefull system call which
  3581.     does not yet have a standard name. How does that get standardized? Also
  3582.     how do you select between BIOS and DOS calls. BIOS calls are often faster
  3583.     but DOS calls are more portable, then of course one also has the choice
  3584.     of using ANSI codes and ANSI.SYS.
  3585.  
  3586.     Examples of some calls are the wealth of different keyboard and screen
  3587.     calls on the PC.
  3588.  
  3589.     Perhaps this is best left to commercial versions of the language, but I
  3590.     would like to see support of system calls in the general Icon langauge.
  3591.     Of course another problem is what do these system calls relate to in
  3592.     the Unix and VMS world? I guess movecursor etc would map to curses calls
  3593.     in Unix (I have no programming experience inm Unix, just dropping buzz
  3594.     words here).
  3595.  
  3596.     I also realize that system calls are of low priority to the Icon project.
  3597. The Icon project is concerned with new language concepts, not how do you
  3598. create a portable screen I/O system which supports more than teletype level
  3599. of display control.
  3600.  
  3601. Frank Filz
  3602.  
  3603. From icon-group-request  Sun Sep 10 20:36:25 1989
  3604. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3605.     id AA00227; Sun, 10 Sep 89 20:36:25 MST
  3606. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  3607.     id AA28446; Sun, 10 Sep 89 20:29:56 -0700
  3608. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3609.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3610.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3611. Date: 11 Sep 89 03:19:09 GMT
  3612. From: unsvax!arrakis.nevada.edu!doon@uunet.uu.net  (Harry W. Reed)
  3613. Organization: Univ of Nevada System Computing Services - Las Vegas
  3614. Subject: ICON src
  3615. Message-Id: <790@unsvax.NEVADA.EDU>
  3616. Sender: icon-group-request@arizona.edu
  3617. To: icon-group@arizona.edu
  3618.  
  3619. Hi,
  3620.     I am very interested in working with an ICON compiler.
  3621. Is the ICON source available via ftp anywhere? or "How can
  3622. I get source code for the ICON compiler?".
  3623.  
  3624.     Thanks,
  3625.  
  3626.     Harry Reed
  3627.     ...!arrakis!doon
  3628.  
  3629. From goer@sophist.uchicago.edu  Sun Sep 10 22:21:18 1989
  3630. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3631.     id AA03312; Sun, 10 Sep 89 22:21:18 MST
  3632. Received: from sophist.uchicago.edu by tank.uchicago.edu Mon, 11 Sep 89 00:19:31 CDT
  3633. Return-Path: <goer@sophist.uchicago.edu>
  3634. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  3635.     id AA02630; Mon, 11 Sep 89 00:16:18 CDT
  3636. Date: Mon, 11 Sep 89 00:16:18 CDT
  3637. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  3638. Message-Id: <8909110516.AA02630@sophist.uchicago.edu>
  3639. To: icon-group@arizona.edu
  3640. Subject: &null
  3641.  
  3642. It is often extremely useful to test whether a variable has the
  3643. type &null, in much the same way as one might perform boolean
  3644. operations in other context with other languages.  Recently a
  3645. poster complained that variables of type &null could not be con-
  3646. verted into other types automatically.  Personally, I cannot see
  3647. using Icon without &null.  For instance, if a procedure that is
  3648. supposed to assign a value to a variable fails, that variable will
  3649. retain its previous value.  In many cases, that value is null, and
  3650. a simple slash can test whether this is the case or not.
  3651.  
  3652. Rarely does the lack of any &null -> other types conversions com-
  3653. plicate a program much.  In the program submitted by the above-
  3654. mentioned poster, it amounts to one extra line (comments are mine):
  3655.  
  3656. procedure main()
  3657.     words:=table()
  3658.     line_no:=0
  3659.     while line:=read() do {
  3660.         line_no +:=1
  3661.         write(left(line_no,6),left(line,40))
  3662.         line:=map(line)
  3663.         i:=1
  3664.         while j:=upto(&lcase,line,i) do {
  3665.         i:=many(&lcase,line,j)
  3666.         if *line[i:j] >= 3
  3667.                      #
  3668.                      #
  3669.         then {if   \words[line[i:j]]       #line 14
  3670.                   then insert(words[line[i:j]],line_no)    #line 15
  3671.               else {words[line[i:j]]:=set()    #line 16
  3672.                     insert(words[line[i:j]], line_no)   #line 17 
  3673.               }
  3674.                      # Try instead:
  3675.                      #
  3676.                      # /words[line[i:j]] := set()
  3677.                      # insert(words[line[i:j]],line_no)
  3678.                      }
  3679.         }
  3680.         }
  3681.  
  3682.       words:=sort(words)
  3683.     i:=0
  3684.     while pair:=words[i +:=1] do  {
  3685.        writes(left(pair[1],10),":")
  3686.        s:=!pair[2]
  3687.        pair[2]:=delete(pair[2],!pair[2])
  3688.            every s ||:= ", " ||!pair[2]
  3689.        write(s)
  3690.        }
  3691.     end
  3692.  
  3693.  
  3694. I might point out that those i:j subscripting operations above are
  3695. all much more elegantly handled by string scanning operations, such
  3696. as:
  3697.  
  3698.     while substr := tab(many(&lcase)) do {
  3699.       tab(upto(&lcase))
  3700.       *substr > 3 | next
  3701.       etc.
  3702.  
  3703.  
  3704. Oh, and don't forget about sort(x,3)!
  3705.  
  3706.                                         -Richard L. Goerwitz
  3707.                                         goer@sophist.uchicago.edu
  3708.                                         rutgers!oddjob!gide!sophist!goer
  3709.  
  3710. From icon-group-request  Mon Sep 11 09:06:49 1989
  3711. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3712.     id AA05499; Mon, 11 Sep 89 09:06:49 MST
  3713. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  3714.     id AA03637; Mon, 11 Sep 89 08:54:35 -0700
  3715. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3716.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3717.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3718. Date: 11 Sep 89 15:40:41 GMT
  3719. From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  3720. Subject: bug in Atari ST v7.5 Icon
  3721. Message-Id: <7189@rpi.edu>
  3722. Sender: icon-group-request@arizona.edu
  3723. To: icon-group@arizona.edu
  3724.  
  3725. I have observed whai I think is a bug in ICONX.PRG on the Atari ST. I have
  3726. a 1040 so it seems that a large program with full sized regions should be
  3727. able to run on top of ASH but I get memory errors.
  3728.  
  3729. I think the bug may be that ICONX is using the region sizes (in bytes) as
  3730. a parameter to a TOS allocation routine which might be using 2 or 4 byte
  3731. allocation units.
  3732.  
  3733. Other than this bug, Icon is great on the ST although it would be nice to
  3734. have some support of the graphics, mouse and cursor addressing etc.
  3735.  
  3736. Frank Filz
  3737.  
  3738. From kwalker  Mon Sep 11 09:15:35 1989
  3739. Date: Mon, 11 Sep 89 09:15:35 MST
  3740. From: "Kenneth Walker" <kwalker>
  3741. Message-Id: <8909111615.AA06027@megaron.arizona.edu>
  3742. Received: by megaron.arizona.edu (5.59-1.7/15)
  3743.     id AA06027; Mon, 11 Sep 89 09:15:35 MST
  3744. In-Reply-To: <790@unsvax.NEVADA.EDU>
  3745. To: icon-group
  3746. Subject: Re:  ICON src
  3747.  
  3748. > Date: 11 Sep 89 03:19:09 GMT
  3749. > From: unsvax!arrakis.nevada.edu!doon@uunet.uu.net  (Harry W. Reed)
  3750. >     I am very interested in working with an ICON compiler.
  3751. > Is the ICON source available via ftp anywhere? or "How can
  3752. > I get source code for the ICON compiler?".
  3753.  
  3754. Icon source is available for a number of systems. To ftp Icon material:
  3755.  
  3756.    ftp arizona.edu
  3757.    log onto ftp with the name anonymous
  3758.    use any password
  3759.    cd icon
  3760.    look at the README file to find out what is available
  3761.  
  3762. Note that Icon does not currently have a compiler in the sense of
  3763. producing machine executable code. There is a translator and intepreter.
  3764.  
  3765.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  3766.    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  3767.  
  3768. From kwalker  Mon Sep 11 10:11:13 1989
  3769. Date: Mon, 11 Sep 89 10:11:13 MST
  3770. From: "Kenneth Walker" <kwalker>
  3771. Message-Id: <8909111711.AA09803@megaron.arizona.edu>
  3772. Received: by megaron.arizona.edu (5.59-1.7/15)
  3773.     id AA09803; Mon, 11 Sep 89 10:11:13 MST
  3774. In-Reply-To: <7174@rpi.edu>
  3775. To: icon-group
  3776. Subject: Re: Why ICON?
  3777.  
  3778. > Date: 10 Sep 89 15:26:23 GMT
  3779. > From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  3780. > On the subject of portability I have a few questions:
  3781. >    are executable images (.ICX) portable to all machines?
  3782.  
  3783. Without investigating too thoroughly, I believe there are a number of
  3784. problems preventing an i-code file from being executed by the iconx
  3785. intepreters on differenct machines. Numeric constants are stored in
  3786. the files in binary form. Thus differnt byte ordering within integers
  3787. will cause problems as will different floating point formats. There
  3788. may also be problems with different data sizes between some systems.
  3789. I-code files on Unix systems have an executable header which finds
  3790. and invokes iconx. This header prevents these i-code files from
  3791. being used on systems without them or on systems with different sized
  3792. headers. There may be other portability problems, though none come to
  3793. mind at the moment.
  3794.  
  3795. >    how about some way to allow a standard call to included assembly language
  3796. >    routines (or .OBJ type files from compilers)? Is this what personalized
  3797. >    interpreters allow? If so could this feature be ported to the micro domain?
  3798.  
  3799. The assmebly language (or C or Pascal or ...) routine must be called from
  3800. iconx. This means that either you need a dynamic linking facility or you
  3801. must relink iconx to specifically include the routine. In addition, any time
  3802. you do ``mixed language programming'', you may have to translate data from
  3803. the internal format of one language to that of the other. Iconx is written
  3804. in C. Becuase values in Icon include type information, even simple Icon types
  3805. do not map into primative C types; structures must be used. The present
  3806. method for adding a new function to Icon is to write a C routine which
  3807. manipulates the structures used to implement Icon types and to tell
  3808. icont/iconx about the new routine. On most systems, these C routines may
  3809. call routines in written other languages. The personalized interpreter
  3810. system just provides a way to compile and link a modified iconx without
  3811. making a copy of the entire source. If you want the source for several
  3812. modifications of Icon on one system, it will save you disk space, but
  3813. does nothing else.
  3814.  
  3815. >    how about a standard of some sort for system calls with some standardization
  3816. >    for particular calls such as something like -
  3817. >        syscall("movecursor",x,y)
  3818.  
  3819. This sort of thing would certainly be useful, though it probably won't
  3820. get done by the Icon Project.
  3821.  
  3822.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  3823.    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  3824.  
  3825. From wgg@june.cs.washington.edu  Mon Sep 11 11:59:27 1989
  3826. Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3827.     id AA16681; Mon, 11 Sep 89 11:59:27 MST
  3828. Received: by june.cs.washington.edu (5.61/7.0j)
  3829.     id AA12798; Mon, 11 Sep 89 11:56:19 -0700
  3830. Date: Mon, 11 Sep 89 11:56:19 -0700
  3831. From: wgg@june.cs.washington.edu (William Griswold)
  3832. Return-Path: <wgg@june.cs.washington.edu>
  3833. Message-Id: <8909111856.AA12798@june.cs.washington.edu>
  3834. To: icon-group@arizona.edu, kwalker@arizona.edu
  3835. Subject: Re: Why ICON?
  3836.  
  3837. In response to Ken's last message, I would like to interject something
  3838. about system calls and the like.
  3839.  
  3840. >
  3841. >Date: Mon, 11 Sep 89 10:11:13 MST
  3842. >From: "Kenneth Walker" <kwalker@arizona.edu>
  3843. >In-Reply-To: <7174@rpi.edu>
  3844. >To: icon-group@arizona.edu
  3845. >Subject: Re: Why ICON?
  3846. >Status: R
  3847. >
  3848. >
  3849. >>    how about a standard of some sort for system calls with some standardization
  3850. >>    for particular calls such as something like -
  3851. >> 
  3852. >>        syscall("movecursor",x,y)
  3853. >
  3854. >This sort of thing would certainly be useful, though it probably won't
  3855. >get done by the Icon Project.
  3856. >
  3857. >   Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  3858. >   +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  3859. >
  3860.  
  3861. There is *planned* for a later version of Icon a facility--called ``call'', 
  3862. I believe--that will allow making system calls and such things without
  3863. extending the Icon built-in function repetoire.  This is necessarily
  3864. machine dependent, and I am not sure what the interface will be (integers
  3865. vs. strings for system calls), or if it will even be useful unless a
  3866. personalized interpreter is built to make it do something reasonable.  As
  3867. mentioned earlier in Ken's message, the handling of different data formats
  3868. and their translation to and from Icon is non-trivial.  The facility
  3869. certainly won't be a panacea. 
  3870.  
  3871.                     Bill Griswold
  3872.  
  3873. From dscargo@cim-vax.honeywell.com  Tue Sep 12 07:09:08 1989
  3874. Message-Id: <8909121409.AA06843@megaron.arizona.edu>
  3875. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3876.     id AA06843; Tue, 12 Sep 89 07:09:08 MST
  3877. Date: 12 Sep 89 08:29:00 CST
  3878. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  3879. Subject: cset comparisons
  3880. To: "icon-group" <icon-group@arizona.edu>
  3881.  
  3882. I found myself doing some cset manipulations for a program and then realized
  3883. that I couldn't remember what kinds of comparison operators work for csets.
  3884. So I tried looking in the Icon book.  Nothing seemed to be clearly indicated.
  3885. At a guess csets are converted to strings for comparisons.  Is that the way
  3886. it works?  Is it unavoidable?
  3887.  
  3888. I wanted to see if the intersection of two csets was empty or not, e. g.,
  3889.  
  3890. if a ** b == '' then ...
  3891.  
  3892. but then I realized that I wasn't sure if == was the right operator.
  3893. (Not that I think that every type needs its own equality operator.)
  3894. Can someone provide some guidance (what to use and why Icon wants it that way)?
  3895.  
  3896. David S. Cargo
  3897. DSCARGO@CIM-VAX.HONEYWELL.COM
  3898.  
  3899.  
  3900.  
  3901. From ralph  Tue Sep 12 07:38:14 1989
  3902. Date: Tue, 12 Sep 89 07:38:14 MST
  3903. From: "Ralph Griswold" <ralph>
  3904. Message-Id: <8909121438.AA07886@megaron.arizona.edu>
  3905. Received: by megaron.arizona.edu (5.59-1.7/15)
  3906.     id AA07886; Tue, 12 Sep 89 07:38:14 MST
  3907. To: dscargo@cim-vax.honeywell.com, icon-group@arizona.edu
  3908. Subject: Re:  cset comparisons
  3909.  
  3910. The correct comparison operation to use is
  3911.  
  3912.     c1 === c2
  3913.  
  3914. provided both c1 and c2 are csets (=== does no type conversion).  For
  3915. csets, the bits are compared in about as fast a way as possible.
  3916.  
  3917. If you write
  3918.  
  3919.     c1 == c2
  3920.  
  3921. both operands are converted to strings and then compared.  Slow and
  3922. it also requires storage allocation.
  3923.  
  3924. Incidentally, to find out if a cset is empty, it's probably better to use
  3925.  
  3926.     *c1 = 0
  3927.  
  3928. I'm not positive about this; would have to do timings.  The size of
  3929. a cset is computed only when it's first needed.  IF it's used the second
  3930. time, it's available without additional computation.
  3931.  
  3932.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  3933.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  3934.  
  3935.  
  3936. From icon-group-request  Wed Sep 13 10:56:20 1989
  3937. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3938.     id AA14820; Wed, 13 Sep 89 10:56:20 MST
  3939. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  3940.     id AA18840; Wed, 13 Sep 89 10:51:27 -0700
  3941. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  3942.     for icon-group@arizona.edu (icon-group@arizona.edu)
  3943.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  3944. Date: 13 Sep 89 17:23:35 GMT
  3945. From: mfci!m3!genly@CS.YALE.EDU  (Chris Hind Genly)
  3946. Organization: Multiflow Computer Inc., Branford CT
  3947. Subject: var params
  3948. Message-Id: <1027@m3.mfci.UUCP>
  3949. Sender: icon-group-request@arizona.edu
  3950. To: icon-group@arizona.edu
  3951.  
  3952.  
  3953. I've done a little bit of icon programming, and I enjoy the language.
  3954. I use it under Unix, and I've started to use Icon instead of shell
  3955. scripts.  It's nice to switch over to a real language for quick jobs.
  3956.  
  3957. I was wondering if anyone besides myself misses var parameters.  A var
  3958. parameter being a way to return a value through a parameter.  Without
  3959. them one is limited to returning one value.  Or alternatively, multiple
  3960. values would have to be packaged into a list, or some other aggregate,
  3961. and then the list returned.  I find this a little clumsy.
  3962.  
  3963. Do you miss var params?  Opinions and techniques welcome.
  3964. --
  3965. =======================================================================
  3966. Chris Hind Genly, N1GLZ - Multiflow Computer - mfci!genly (203)488-6090
  3967.  
  3968.     
  3969.  
  3970. From EM302723@VMTECMEX.BITNET  Wed Sep 13 15:26:03 1989
  3971. Message-Id: <8909132226.AA11881@megaron.arizona.edu>
  3972. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  3973.     id AA11881; Wed, 13 Sep 89 15:26:03 MST
  3974. Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Wed, 13 Sep 89 15:15
  3975.  MST
  3976. Received: by VMTECMEX (Mailer R2.03B) id 4543; Wed, 13 Sep 89 08:38:42 MEX
  3977. Date: Wed, 13 Sep 89 08:36:10 MEX
  3978. From: "Mario Camou R. (Dr. Mangagoras)" <EM302723@VMTECMEX.BITNET>
  3979. Subject: MS-DOS cursor control, etc?
  3980. To: icon-group@arizona.edu
  3981.  
  3982. Hi,
  3983. Has anybody (working with the Icon source) implemented cursor control &
  3984. graphics in Icon? How about the "Extension interpreter" that was commented
  3985. a few Newsletters back?
  3986.  
  3987. One other thing: How about distributing the Icon Newsletter via email?
  3988.  
  3989. -------------------------------------------------------------------
  3990.  
  3991. This is just my humble opinion. If you like it...great. If you don't...
  3992. well, who cares for your opinion, anyway?
  3993.  
  3994. +----------------------------------+------------------------------+
  3995. |                                  | Mario Camou Riveroll         |
  3996. |  Dr. Mangagoras                  | Apdo. Postal 41554           |
  3997. |  EM302723@VMTECMEX.BITNET        | Lomas de Chapultepec         |
  3998. |                                  | Mexico, D.F. 11001           |
  3999. |                                  |                              |
  4000. | "Don't take life too seriously   | "Laugh at life, or life will |
  4001. | it's just a temporary situation" | laugh at you"                |
  4002. +----------------------------------+------------------------------+
  4003.  
  4004. From icon-group-request  Thu Sep 14 08:50:05 1989
  4005. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4006.     id AA25805; Thu, 14 Sep 89 08:50:05 MST
  4007. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  4008.     id AA29691; Thu, 14 Sep 89 08:43:01 -0700
  4009. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4010.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4011.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4012. Date: 14 Sep 89 15:31:00 GMT
  4013. From: swrinde!cs.utexas.edu!mailrus!uwm.edu!rpi!unix.cie.rpi.edu!vicc@ucsd.edu  (VICC Project (Rose))
  4014. Subject: Re: var params
  4015. Message-Id: <7319@rpi.edu>
  4016. References: <1027@m3.mfci.UUCP>
  4017. Sender: icon-group-request@arizona.edu
  4018. To: icon-group@arizona.edu
  4019.  
  4020. I too miss var parameters, unfortuanately they require a new data type (to some
  4021. extent at least) to implement.
  4022.  
  4023. I am planning on playing arround with adding some features to Icon and I would
  4024. like to know what people are interested in and what people have worked on
  4025. and what their experiences have been. I will be working on the ms-dos version.
  4026.  
  4027. What I plan to play with are:
  4028.  
  4029.    Arrays - static sized multiple dimnensioned arrays, will be more space
  4030.             and time efficient than lists. A procedure will be used to generate
  4031.             an empty array.
  4032.  
  4033.    A range data type that can be converted into that needed for subscripting
  4034.    strings. (I'm not sure this is really needed, and I'm not sure that the
  4035.    current string range mechanism won't work, I have to read the implementation
  4036.    book.
  4037.  
  4038.    variable parameters, and maybe general pointer variables
  4039.  
  4040.    a system() function like I described earlier
  4041.  
  4042. anyone who has comments on this please feel free to contact me. I've always
  4043. wanted to hack with a compiler and Icon seems just right for that, complete
  4044. source code, a manual which describes the designers philosophy behind
  4045. everything etc. I wish to maintain as much of Icon's original philosophy as
  4046. possible in my work.
  4047.  
  4048. also, what are the additional documents which come with the implementation
  4049. documentation package? I may need to order them, I've signed out the
  4050. implementation book from my school library (they have a neat cs section,
  4051. they have the Snobol implementation book also)
  4052.  
  4053. Frank Filz
  4054.  
  4055. From hplabs!hp-sdd!ncr-sd!ncr-fc!avery@ucbvax.Berkeley.EDU  Thu Sep 14 10:34:47 1989
  4056. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4057.     id AA03098; Thu, 14 Sep 89 10:34:47 MST
  4058. Received: from hplabs.UUCP by ucbvax.Berkeley.EDU (5.61/1.37)
  4059.     id AA06407; Thu, 14 Sep 89 10:35:39 -0700
  4060. From: hplabs!hp-sdd!ncr-sd!ncr-fc!avery@ucbvax.Berkeley.EDU
  4061. Received: from hp-sdd.sdd.hp.com (hp-sdd) by hplabs.HP.COM with SMTP ; Thu, 14 Sep 89 09:31:59 PST
  4062. Received: by hp-sdd.sdd.hp.com; Thu, 14 Sep 89 10:31:31 pdt
  4063. Received: from ncr-sd with uucp; Thu, 14 Sep 89 10:10 PDT
  4064. Received: by ncr-fc.FtCollins.NCR.com on Thu, 14 Sep 89 11:09:02 MDT
  4065. Date: Thu, 14 Sep 89 11:09:02 MDT
  4066. Message-Id: <8909141709.AA18214@ncr-fc.FtCollins.NCR.com>
  4067. To: ncr-sd!arizona.edu!icon-group
  4068. Subject: Kill participation in icon group
  4069.  
  4070.  
  4071.  
  4072. Please remove my name from icon e-mail group.
  4073. Thanks....
  4074.  
  4075.  
  4076.  
  4077.  
  4078. From att!ihcup!pax  Thu Sep 14 12:51:44 1989
  4079. Date: Thu, 14 Sep 89 12:51:44 MST
  4080. From: att!ihcup!pax
  4081. Message-Id: <8909141951.AA11958@megaron.arizona.edu>
  4082. Received: by megaron.arizona.edu (5.59-1.7/15)
  4083.     id AA11958; Thu, 14 Sep 89 12:51:44 MST
  4084. To: att!arizona!icon-group
  4085.  
  4086.    From arpa!arizona.edu!icon-group-request Thu Sep 14 12:21:19 1989
  4087.    Date: 14 Sep 89 15:31:00 GMT
  4088.    
  4089.    I too miss var parameters, unfortuanately they require a new data type
  4090.    (to some extent at least) to implement.
  4091.    
  4092. I agree, they would be useful.  I also would like to see the equivalent of
  4093. argv[0] so that an Icon program could discover its name.
  4094.  
  4095.    I am planning on playing arround with adding some features to Icon and I would
  4096.    like to know what people are interested in and what people have worked on
  4097.    and what their experiences have been. I will be working on the ms-dos version.
  4098.    
  4099. If you are going to be working with the DOS implementation, let me note that my
  4100. biggest problem with it has been, without a doubt, memory management.  I run
  4101. Icon on several different types of UNIX machines without any difficulties but
  4102. on DOS I am forever playing with [STAT,STR,HEAP]SIZE trying to get a large
  4103. Icon program to just load.  Once loaded, there are lots of "dead stops" that
  4104. seem, somehow, to be associated with running out of some memory resource.
  4105. It has been a very frustrating task to simply port a running Icon program 
  4106. into the DOS environment.  I realize that this is caused, not by the Icon
  4107. implementation, but by restrictions imposed by DOS.  What I need is more help
  4108. and information from Icon as to what is really going on with memory management.
  4109.  
  4110. The DOS version needs some tools, or indicators, that monitor or report on
  4111. memory usage.  Where is the memory going, how much, how fast, etc.  Perhaps
  4112. some data could be dumped at the conclusion of every garbage collection that
  4113. would help in understanding the programs' needs for memory resources.
  4114.  
  4115.    What I plan to play with are:
  4116.    
  4117.       Arrays - static sized multiple dimnensioned arrays, will be more space
  4118.                and time efficient than lists. A procedure will be used to
  4119.            generate an empty array.
  4120.    
  4121.       A range data type that can be converted into that needed for subscripting
  4122.       strings. (I'm not sure this is really needed, and I'm not sure that the
  4123.       current string range mechanism won't work, I have to read the
  4124.       implementation book.
  4125.    
  4126.       variable parameters, and maybe general pointer variables
  4127.    
  4128.       a system() function like I described earlier
  4129.    
  4130. As an old SNOBOL4/SPITBOL programmer from way the hell back, I must admit that
  4131. I miss in Icon the SNOBOL4/SPITBOL rather generous capabilities for tracing.
  4132. I'd like to see the equivalent functionality available in Icon.  The features
  4133. are well documented and were very useful.
  4134.  
  4135.    anyone who has comments on this please feel free to contact me. I've always
  4136.    wanted to hack with a compiler and Icon seems just right for that, complete
  4137.    source code, a manual which describes the designers philosophy behind
  4138.    everything etc. I wish to maintain as much of Icon's original philosophy as
  4139.    possible in my work.
  4140.    
  4141.    also, what are the additional documents which come with the implementation
  4142.    documentation package? I may need to order them, I've signed out the
  4143.    implementation book from my school library (they have a neat cs section,
  4144.    they have the Snobol implementation book also)
  4145.    
  4146.    Frank Filz
  4147.    
  4148.  
  4149. Joe T. Hall
  4150. AT&T Bell Laboratories
  4151. 200 Park Plaza, Room IHP 2B-524
  4152. Naperville, Illinois 60566-7050
  4153. USA
  4154. att!ihcup!pax
  4155. tel: +1 312 713-7285
  4156. fax: +1 312 713-7480
  4157. tlx:157294384(JTHALL)
  4158.  
  4159. From gudeman  Thu Sep 14 14:35:37 1989
  4160. Date: Thu, 14 Sep 89 14:35:37 MST
  4161. From: "David Gudeman" <gudeman>
  4162. Message-Id: <8909142135.AA18591@megaron.arizona.edu>
  4163. Received: by megaron.arizona.edu (5.59-1.7/15)
  4164.     id AA18591; Thu, 14 Sep 89 14:35:37 MST
  4165. To: icon-group@arizona.edu
  4166. In-Reply-To: Rose's message of 14 Sep 89 15:31:00 GMT <7319@rpi.edu>
  4167. Subject: Icon additions (was: var params)
  4168.  
  4169. [I was going to reply directly, but I had doubts about the return
  4170. address.  Frank, you should include a return address in your
  4171. .signiture file, or maybe add a Reply-To: to your mail header.]
  4172.  
  4173. Var params require a new _internal_ data type, but they don't really
  4174. require a new user-accessible one.  If you want to go all the way and
  4175. add C-style pointers, you have to consider things like what operations
  4176. will be allowed.  For example, in C you can add an integer to a
  4177. pointer to get a new pointer.  There is no range check because the C
  4178. philosophy puts the responsibility for such things on the programmer
  4179. and because C models memory as one huge continuous array.  Icon models
  4180. memory as a set of independent locations with variable (changing)
  4181. sizes, so if you want pointer addition, you have to come up with some
  4182. reasonable Iconesque semantics.
  4183.  
  4184. Assume that ^expr returns a pointer to the variable produced by expr.
  4185. Then {ls := list(10); ptr := ls[3]} creates a list, and makes ptr a
  4186. pointer into the list.  Presumably, ptr + 3 returns a pointer to
  4187. ls[6].  What does ptr + 9 do?  It would be terribly non-Iconish for it
  4188. to produce a random memory location.  I can think of two
  4189. possibilities: (1) pointers wrap around in a list, so ptr + 9 produces
  4190. a pointer to ls[2], or  (2) ptr + 9 fails, just like ls[3+9] would.
  4191.  
  4192. Here's another consideration: what happens after you do a push(ls, x)?
  4193. Does ptr still point to ls[3], or does it now point to ls[4]?  All of
  4194. this is relatively simple, when you add pointers to table elements
  4195. things get complicated...
  4196.  
  4197. Multiple dimensioned arrays would be useful, and I can see why you
  4198. want them static-sized (to avoid the semantic complexity of APL) , but
  4199. I think you are exaggerating the performance penalty of Icon's
  4200. variable-sized lists.  If you create a list with the list() function
  4201. and never extend it, there is very little difference between access
  4202. time of the list and that of a fixed-size array.  In fact, I would be
  4203. surprised if you could measure any performance difference by timing
  4204. programs.  And the list() only uses about 10 more words of memory than
  4205. a fixed-size array would need.  Unless you have hundreds of very small
  4206. arrays, this shouldn't be a problem.
  4207.  
  4208. From icon-group-request  Thu Sep 14 20:19:50 1989
  4209. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4210.     id AA05270; Thu, 14 Sep 89 20:19:50 MST
  4211. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  4212.     id AA10838; Thu, 14 Sep 89 20:15:25 -0700
  4213. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4214.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4215.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4216. Date: 15 Sep 89 02:48:58 GMT
  4217. From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  4218. Subject: Re: Icon additions (was: var params)
  4219. Message-Id: <7331@rpi.edu>
  4220. References: <7319@rpi.edu>, <8909142135.AA18591@megaron.arizona.edu>
  4221. Sender: icon-group-request@arizona.edu
  4222. To: icon-group@arizona.edu
  4223.  
  4224. In article <8909142135.AA18591@megaron.arizona.edu>, gudeman@ARIZONA.EDU ("David Gudeman") writes:
  4225. > [I was going to reply directly, but I had doubts about the return
  4226. > address.  Frank, you should include a return address in your
  4227. > ..signiture file, or maybe add a Reply-To: to your mail header.]
  4228.  
  4229. I wasn't thinking about that. We have a central news server here which actually
  4230. submits the articles. One of the problems is you can not cancel an article.
  4231.  
  4232. > Var params require a new _internal_ data type, but they don't really
  4233. > require a new user-accessible one.  If you want to go all the way and
  4234. > add C-style pointers, you have to consider things like what operations
  4235. > will be allowed.  For example, in C you can add an integer to a
  4236. > pointer to get a new pointer.  There is no range check because the C
  4237. > philosophy puts the responsibility for such things on the programmer
  4238. > and because C models memory as one huge continuous array.  Icon models
  4239. > memory as a set of independent locations with variable (changing)
  4240. > sizes, so if you want pointer addition, you have to come up with some
  4241. > reasonable Iconesque semantics.
  4242.  
  4243. If I implemented a user-accessible pointer type I would implement it in a more
  4244. pascalish way. You can get a pointer to a variable, copy a pointer, or get
  4245. a pointer to newly allocated space. I think anything more (such as c type
  4246. operations) would stretch Icon's structure a bit too far (at least for my
  4247. tastes)
  4248. > Assume that ^expr returns a pointer to the variable produced by expr.
  4249. > Then {ls := list(10); ptr := ls[3]} creates a list, and makes ptr a
  4250. > pointer into the list.  Presumably, ptr + 3 returns a pointer to
  4251. > ls[6].  What does ptr + 9 do?  It would be terribly non-Iconish for it
  4252. > to produce a random memory location.  I can think of two
  4253. > possibilities: (1) pointers wrap around in a list, so ptr + 9 produces
  4254. > a pointer to ls[2], or  (2) ptr + 9 fails, just like ls[3+9] would.
  4255. > Here's another consideration: what happens after you do a push(ls, x)?
  4256. > Does ptr still point to ls[3], or does it now point to ls[4]?  All of
  4257. > this is relatively simple, when you add pointers to table elements
  4258. > things get complicated...
  4259.  
  4260. As far as I can see, it would have to now point to ls[4], it would take
  4261. a lot of work to change all of the pointers that might exist to ls[3].
  4262. This of course is one place that pointers will get messy with Icon even if
  4263. operations are not defined on pointers.
  4264.  
  4265. > Multiple dimensioned arrays would be useful, and I can see why you
  4266. > want them static-sized (to avoid the semantic complexity of APL) , but
  4267. > I think you are exaggerating the performance penalty of Icon's
  4268. > variable-sized lists.  If you create a list with the list() function
  4269. > and never extend it, there is very little difference between access
  4270. > time of the list and that of a fixed-size array.  In fact, I would be
  4271. > surprised if you could measure any performance difference by timing
  4272. > programs.  And the list() only uses about 10 more words of memory than
  4273. > a fixed-size array would need.  Unless you have hundreds of very small
  4274. > arrays, this shouldn't be a problem.
  4275.  
  4276. I see that for a single dimensioned array, but what about a multi-dimensioned
  4277. array with lists, is not that a list of lists, in which case you have that
  4278. extra 10 words of overhead for each sub list? Also you have the time of an
  4279. extra list lookup as opposed to a multiplication. I think you are right though,
  4280. now that I think about it the speed improvement probably wont be much, but
  4281. I can see some space improvement by avoiding the list of lists. Of course
  4282. the programmer could also do the multiplication himself.
  4283.  
  4284. The other thing I hope to be able to do is to allow arbitrary lower bounds
  4285. which will improve the readability of some types of algorithms. Another
  4286. advantage of the array would be that copy would copy all the elements, not
  4287. just the first dimension.
  4288.  
  4289. Another reason to play with arrays is that I believe they will be a relatively
  4290. simple implementation which should be a good practice start. Pointers on the
  4291. other hand obviously have many ramifications which must be examined.
  4292.  
  4293. One other question, is it correct that to add an operator one will have to
  4294. alter ICONT?
  4295.  
  4296. Frank Filz
  4297. Center For Integrated Electronics
  4298. Rensselaer Polytechnic Institute
  4299. vicc@unix.cie.rpi.edu
  4300.  
  4301. From icon-group-request  Fri Sep 15 05:50:33 1989
  4302. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4303.     id AA01532; Fri, 15 Sep 89 05:50:33 MST
  4304. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  4305.     id AA07535; Fri, 15 Sep 89 05:38:07 -0700
  4306. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4307.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4308.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4309. Date: 15 Sep 89 12:29:53 GMT
  4310. From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  4311. Subject: Re: (none)
  4312. Message-Id: <7341@rpi.edu>
  4313. References: <8909141951.AA11958@megaron.arizona.edu>
  4314. Sender: icon-group-request@arizona.edu
  4315. To: icon-group@arizona.edu
  4316.  
  4317. In article <8909141951.AA11958@megaron.arizona.edu>, pax@ihcup.UUCP writes:
  4318. > I also would like to see the equivalent of
  4319. > argv[0] so that an Icon program could discover its name.
  4320.  
  4321. Should be relatively easy actually since ICONX needs to know the name.
  4322. Have to think about the syntax though. I don't recall off hand the syntax/
  4323. strategy for parameters and this is not something to break existing programs
  4324. over.
  4325.  
  4326. > If you are going to be working with the DOS implementation, let me note that my
  4327. > biggest problem with it has been, without a doubt, memory management.  I run
  4328. > Icon on several different types of UNIX machines without any difficulties but
  4329. > on DOS I am forever playing with [STAT,STR,HEAP]SIZE trying to get a large
  4330. > Icon program to just load.  Once loaded, there are lots of "dead stops" that
  4331. > seem, somehow, to be associated with running out of some memory resource.
  4332. > It has been a very frustrating task to simply port a running Icon program 
  4333. > into the DOS environment.  I realize that this is caused, not by the Icon
  4334. > implementation, but by restrictions imposed by DOS.  What I need is more help
  4335. > and information from Icon as to what is really going on with memory management.
  4336.  
  4337. > The DOS version needs some tools, or indicators, that monitor or report on
  4338. > memory usage.  Where is the memory going, how much, how fast, etc.  Perhaps
  4339. > some data could be dumped at the conclusion of every garbage collection that
  4340. > would help in understanding the programs' needs for memory resources.
  4341.  
  4342. From my understanding, Icon requires almost 640k of memory (including system
  4343. etc., one note is to be carefull of how many TSRs you have loaded. Thus,
  4344. since a full sized program/memory space won't fit, you have to jiggle for
  4345. each. Note the new & variables in V7.5 for allocation and garbage collection
  4346. tracing. They may help your situation some what. How long did you wait for
  4347. after the dead stop? I'm not sure how Icon's garbage collection compares with
  4348. others but I remember one LISP interpreter warning that garbage collections
  4349. could take several minutes. If you are using 90% of a region and the items
  4350. are small objects, garbage collection could take a while. If that is not
  4351. the case, perhaps you have discovered a bug when the ammount of space left
  4352. is really small. I will leave further comments to other more experienced
  4353. people.
  4354.  
  4355. >As an old SNOBOL4/SPITBOL programmer from way the hell back, I must admit that
  4356. > I miss in Icon the SNOBOL4/SPITBOL rather generous capabilities for tracing.
  4357. > I'd like to see the equivalent functionality available in Icon.  The features
  4358. > are well documented and were very useful.
  4359.  
  4360. I doubt that I will do much in that line. That could be a major problem
  4361. actually. If anything, I was thinking of producing a more production
  4362. model without the tracing. A question there would be how much run time
  4363. memory allocation and time would actually be saved? If it would only be
  4364. a few percent I see no reason to do it. This would be set up as a complementary
  4365. ICONX if done, the tracing is still needed for development purposes.
  4366.  
  4367. Frank Filz
  4368.  
  4369.  
  4370. Frank Filz
  4371. Center For Integrated Electronics
  4372. Rensselaer Polytechnic Institute
  4373. vicc@unix.cie.rpi.edu
  4374.  
  4375. From dscargo@cim-vax.honeywell.com  Fri Sep 15 06:57:35 1989
  4376. Message-Id: <8909151357.AA03203@megaron.arizona.edu>
  4377. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4378.     id AA03203; Fri, 15 Sep 89 06:57:35 MST
  4379. Date: 15 Sep 89 08:43:00 CST
  4380. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  4381. Subject: Icon additions
  4382. To: "icon-group" <icon-group@arizona.edu>
  4383.  
  4384. There are three things of various levels of complexity that I'd like to see
  4385. added to Icon.
  4386.  
  4387. 1) A bit-string type similar in underlying mechanisms to csets.  (In other
  4388. words a 256-bit limit is probably acceptable.  The same operations available
  4389. on csets should be provided.  Conversions should be available between bit
  4390. strings and strings, and possibly between bit strings and csets.  I don't
  4391. see any good way of representing bit string constants.  Translating them
  4392. to strings could be done in a combination of ways:  to a string of binary,
  4393. octal, or hex digits, and padded to full length or truncated (on the left
  4394. or right) if the remainder is zero filled.  I'm inclined to use Icon for
  4395. some graphics applications and true bit-strings would be very helpful.
  4396.  
  4397. 2) Formatted translation from bytestrings to integers.  Given a specification
  4398. about width and byte order, translate a string of bytes into a list of
  4399. integers.  Useful for cracking some arbitrary file internal formats (like
  4400. TIFF and PCX).
  4401.  
  4402. 3) POSIX compatibility.  In particular, if there are screen and keyboard
  4403. interfaces specified (or drafted), make them accessible to Icon so that
  4404. portable user interfaces for applications can be developed.  In the MS-DOS
  4405. world alone, support for ANSI or lower-level access to video memory might
  4406. be nice.
  4407.  
  4408. dsc
  4409.  
  4410.  
  4411. From icon-group-request  Fri Sep 15 09:06:31 1989
  4412. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4413.     id AA09825; Fri, 15 Sep 89 09:06:31 MST
  4414. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  4415.     id AA17623; Fri, 15 Sep 89 08:55:47 -0700
  4416. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4417.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4418.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4419. Date: 15 Sep 89 15:34:48 GMT
  4420. From: cs.utexas.edu!uwm.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  4421. Subject: Re: Icon additions
  4422. Message-Id: <7346@rpi.edu>
  4423. References: <8909151357.AA03203@megaron.arizona.edu>
  4424. Sender: icon-group-request@arizona.edu
  4425. To: icon-group@arizona.edu
  4426.  
  4427. In article <8909151357.AA03203@megaron.arizona.edu>, dscargo@CIM-VAX.HONEYWELL.COM ("DAVE CARGO") writes:
  4428. > There are three things of various levels of complexity that I'd like to see
  4429. > added to Icon.
  4430.  
  4431. > 1) A bit-string type similar in underlying mechanisms to csets.  (In other
  4432. > words a 256-bit limit is probably acceptable.  The same operations available
  4433.  
  4434. This woud seem easy to do, perhaps without the need for a new data type. A few
  4435. functions would go a long way.
  4436.  
  4437. > 2) Formatted translation from bytestrings to integers.  Given a specification
  4438. > about width and byte order, translate a string of bytes into a list of
  4439. > integers.  Useful for cracking some arbitrary file internal formats (like
  4440. > TIFF and PCX).
  4441.  
  4442. Well there is ord and char, but yes, a few additional functions would be
  4443. nice.
  4444.  
  4445. > 3) POSIX compatibility.  In particular, if there are screen and keyboard
  4446. > interfaces specified (or drafted), make them accessible to Icon so that
  4447. > portable user interfaces for applications can be developed.  In the MS-DOS
  4448. > world alone, support for ANSI or lower-level access to video memory might
  4449. > be nice.
  4450.  
  4451. I have some ideas on this that I mentioned a few posts back. Basically the
  4452. idea would be to implement a function which has a string parameter specifying
  4453. the function call, and a variable number of parameters to be passed. The reason
  4454. I would have a single Icon function, is primarily to avoid generating too
  4455. many function names. Also searches for use of these I/O routines would be
  4456. easy since you would look for 1 function, not 30 or more. A system variable
  4457. such as &sysfuncs or so would be a generator like &features. There would be
  4458. a single addition to &features list.
  4459.  
  4460. On MS-DOS I would map these to DOS and BIOS calls. ANSI calls might be nice
  4461. but I think most MS-DOS users these days are PC BIOS compatible. (If I am
  4462. wrong let me know) The big problem will be in assigning a reasonably standard
  4463. list of I/O call names.
  4464.  
  4465.  
  4466.  
  4467.  
  4468. Frank Filz
  4469. Center For Integrated Electronics
  4470. Rensselaer Polytechnic Institute
  4471. vicc@unix.cie.rpi.edu
  4472.  
  4473. From dscargo@cim-vax.honeywell.com  Fri Sep 15 13:14:37 1989
  4474. Message-Id: <8909152014.AA25425@megaron.arizona.edu>
  4475. Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4476.     id AA25425; Fri, 15 Sep 89 13:14:37 MST
  4477. Date: 15 Sep 89 14:59:00 CST
  4478. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  4479. Subject: string range replacement confusion
  4480. To: "icon-group" <icon-group@arizona.edu>
  4481.  
  4482. #The following fragment represents part of a program that scans
  4483. #a file of user names and writes out lines that match, uppercasing
  4484. #the part of the line that matched.  Three methods are used to assign
  4485. #capital letters to the output string.  One uppercases the pattern and
  4486. #assigns it to the part of the line that matched.  Two other methods
  4487. #copy characters from an uppercased copy of the line.  So far
  4488. #as I can determine, all three methods should work the same.
  4489. #They don't.  I'm using Icon 7.0 for VMS.  I'm trying to determine
  4490. #if methods 2 and 3(represented by the write(pline2) and write(pline3))
  4491. #are correct but somehow failing to produce the correct results, or if I'm
  4492. #misunderstanding how some of this Icon is supposed to work.
  4493. global sstr
  4494. procedure main()
  4495.     sstr := "cargo"
  4496.     line := "cargo, dave                  cargo"
  4497.     write(line) #added for testing
  4498.     print_line(line,"skyler")
  4499. end
  4500.  
  4501. procedure print_line(line, nodename)
  4502. # three copies for the three different methods
  4503.     pline1 := copy(line)
  4504.     pline2 := copy(line)
  4505.     pline3 := copy(line)
  4506.     lower := map(sstr)
  4507. # this is the desired replacement text
  4508.     upper := map(sstr, &lcase, &ucase)
  4509. # this is an altermate source for the replacement text
  4510.     uline := map(line, &lcase, &ucase)
  4511. # the size of the search string
  4512.     starsstr := *sstr
  4513.  # finding all instances of the search string
  4514.    every i := find(lower, line) do
  4515.         {
  4516. # I think these assignments should replace the same
  4517. # characters in the same places.
  4518. # method 1 explicitly calculates the ranges
  4519.         j := i + *sstr
  4520.         pline1[i:j] := uline[i:j]
  4521. # method 2 uses the same ranges
  4522.         pline2[i:+starsstr] := uline[i:+starsstr]
  4523. # method three only uses one range, but should have the same text
  4524.         pline3[i:+starsstr] := upper
  4525.         }
  4526.     write(pline1)
  4527.     write(pline2)
  4528.     write(pline3)
  4529.     return
  4530. end
  4531. # minus the pound signs, this is what comes out
  4532. # (from a screen capture)
  4533. #cargo, dave                  cargo
  4534. #CARGO, dave                  CARGO
  4535. #CARGO, DAVE                  cargo
  4536. #CARGCARGO cargo
  4537.  
  4538.  
  4539.  
  4540. From goer@sophist.uchicago.edu  Fri Sep 15 18:56:44 1989
  4541. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4542.     id AA13518; Fri, 15 Sep 89 18:56:44 MST
  4543. Received: from sophist.uchicago.edu by tank.uchicago.edu Fri, 15 Sep 89 19:49:21 CDT
  4544. Return-Path: <goer@sophist.uchicago.edu>
  4545. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  4546.     id AA08151; Fri, 15 Sep 89 19:45:56 CDT
  4547. Date: Fri, 15 Sep 89 19:45:56 CDT
  4548. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  4549. Message-Id: <8909160045.AA08151@sophist.uchicago.edu>
  4550. To: icon-group@arizona.edu
  4551.  
  4552. The problem with the uppercasing procedure just submitted by
  4553. Dave Cargo boils down to a slight error in subscripting no-
  4554. tation.  The plus sign needs to go before the colon; otherwise
  4555. it is interpreted as a prefix operator creating a positive in-
  4556. teger (that integer here being starsstr).
  4557.  
  4558.         pline2[i:+starsstr] := uline[i:+starsstr]
  4559. #### the correct way of saying this is str[i+:j] ####
  4560.         pline3[i:+starsstr] := upper
  4561. #### ditto ####
  4562.  
  4563. This i:j stuff, though, is very un-iconish.  But then I'm
  4564. biased.  String scanning can get to be a kind of religion:
  4565.  
  4566. procedure main()
  4567.   sstr := "cargo"
  4568.   line := "cargo, dave                  cargo"
  4569.   write(capline(sstr,line))
  4570. end
  4571.  
  4572. procedure capline(word,line)
  4573.   line2 := ""
  4574.   line ? {
  4575.     while line2 ||:= tab(find(word))
  4576.     do line2 ||:= map(=word,&lcase,&ucase)
  4577.     line2 ||:= tab(0)
  4578.     }
  4579.   return line2
  4580. end
  4581.  
  4582. From att!ihcup!pax  Mon Sep 18 06:59:42 1989
  4583. Date: Mon, 18 Sep 89 06:59:42 MST
  4584. From: att!ihcup!pax
  4585. Message-Id: <8909181359.AA18860@megaron.arizona.edu>
  4586. Received: by megaron.arizona.edu (5.59-1.7/15)
  4587.     id AA18860; Mon, 18 Sep 89 06:59:42 MST
  4588. To: att!arizona!icon-group
  4589.  
  4590. Ralph, Cheyenne,
  4591.  
  4592. I know that you are not really very interested in the 640K DOS
  4593. situation with Icon.  But, I have customers running Icon programs
  4594. that I've written for them and they sure don't want to trash their
  4595. existing 640K machines - at least not right now.
  4596.  
  4597. Any help at all you can give me on memory management will be most
  4598. appreciated.  Especially some words specifically on how to best
  4599. trim the size of tables and lists as the items are no longer needed.
  4600.  
  4601. Also, I believe I can recreate dependably a problem with the
  4602. system() function in DOS Icon.  Depending upon how large the
  4603. program is, system() may or may not do anything.  No error
  4604. or failure return - it's just as if the call was skipped.
  4605.  
  4606. I have a large program that is made by combining the .U files
  4607. of six, translated with -c, subprograms.  When they are all put
  4608. together the system() function disappears.  I can leave off
  4609. most any of them and system() works again.
  4610.  
  4611. Is it possible that some DOS system buffer is getting clobbered
  4612. by a very large icon executable?
  4613.  
  4614. I put a simple DOS comand:
  4615.  
  4616.     system("copy a b")
  4617.     stop()
  4618.  
  4619. at the very beginning of my large program and then tried all
  4620. kinds of combinations of .U's with it.  Leaving off just one
  4621. of the subprograms seems to be enough to clear up the problem.
  4622.  
  4623. When it works, I get the normal DOS standard output:
  4624.  
  4625.         1 File(s) copied
  4626.  
  4627. and the file is copied.
  4628.  
  4629. When it fails, I get NOTHING on standard out from the DOS
  4630. command and there is no copy made.
  4631.  
  4632. Can you offer any assistance?
  4633.  
  4634. jth
  4635.  
  4636. From dscargo@cim-vax.honeywell.com  Wed Sep 20 09:14:41 1989
  4637. Message-Id: <8909201614.AA16660@megaron.arizona.edu>
  4638. Received: from cim-vax.Honeywell.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4639.     id AA16660; Wed, 20 Sep 89 09:14:41 MST
  4640. Date: 20 Sep 89 11:01:00 CST
  4641. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  4642. Subject: string scanning vs. assignment
  4643. To: "icon-group" <icon-group@arizona.edu>
  4644.  
  4645. Richard Goerwitz corrected my problem with the Icon syntax and
  4646. proposed his solution to the capitalization problem.  I tried it and it
  4647. worked, but I got currious about performance.  When I timed his
  4648. solution  with a corrected varient of one of mine,I discovered that 
  4649. the string scanning approach takes more time (about half again 
  4650. more as revealed by timing tests on Icon 7.0 for VMS.
  4651.  
  4652. Richard's solution:
  4653.  
  4654. procedure capline(word, line)
  4655.   line2 := ""
  4656.   line ? {
  4657.     while line2 ||:= tab(find(word))
  4658.     do line2 ||:= map(=word,&lcase,&ucase)
  4659.     line2 ||:= tab(0)
  4660.     }
  4661.   return line2
  4662. end
  4663.  
  4664. my corrected and modified solution:
  4665.  
  4666. procedure capline(word, line)
  4667.     line2 := copy(line)
  4668.     every line2[find(word, line)+:*word] := map(word, &lcase, &ucase)
  4669.     return line2
  4670. end
  4671.  
  4672. I think my solution is faster because it creates fewer tempory
  4673. variables and does fewer operations.
  4674.  
  4675.  
  4676. From att!ihlpb!nevin1  Wed Sep 20 16:35:44 1989
  4677. Date: Wed, 20 Sep 89 16:35:44 MST
  4678. Message-Id: <8909202335.AA19395@megaron.arizona.edu>
  4679. Received: by megaron.arizona.edu (5.59-1.7/15)
  4680.     id AA19395; Wed, 20 Sep 89 16:35:44 MST
  4681. From: ihlpb!nevin1 (Nevin J Liber +1 312 979 4751)
  4682. To: att!arizona!icon-group
  4683. Subject: Re: Icon additions
  4684.  
  4685. >If I implemented a user-accessible pointer type I would implement it in a more
  4686. >pascalish way. You can get a pointer to a variable, copy a pointer, or get
  4687. >a pointer to newly allocated space.
  4688.  
  4689. My question to you is:  what do you wish to be able to do with
  4690. pointers in Icon?  Pointers are needed in languages like Pascal, C,
  4691. etc. to implement entities such as linked lists and hash tables.  But
  4692. these are already built into Icon!  Also, trying to implement
  4693. user-accessible pointers in conjunction with garbage collection is far
  4694. from trivial.  I just can't see what new types of *implementation-independent*
  4695. (I know that there basically only one implementation of Icon right now,
  4696. but language design should not be restricted to one implementation)
  4697. applications that I cannot now write in Icon solely because I don't have
  4698. pointers.  What power would pointers give me?
  4699.  
  4700.  
  4701. >The other thing I hope to be able to do is to allow arbitrary lower bounds
  4702. >[on arrays,] which will improve the readability of some types of algorithms.
  4703.  
  4704. IMHO, this would not be very Icon-ish.  First off, negative indices
  4705. already are defined in Icon; they allow you to work from the end
  4706. of a string, list, etc.  instead of the beginning; with arbituary
  4707. lower bounds on arrays, this wouldn't work (there are ways to kludge it
  4708. in, but code that would take advantage of it would look very messy).
  4709.  
  4710. Secondly:  for the current data types, to generate over them in reverse
  4711. order the construct "every element := dataType[*dataType to 1 by -1]" works; 
  4712. this would not hold true for non-0 lower-bounded arrays.
  4713.  
  4714. Thirdly:  how does one pass an array to a procedure?  A procedure would
  4715. need some way of determining the lower bound of an array passed to it
  4716. (unless you want to write different procedures for each differently
  4717. bounded array as in standard Pascal -- blecch!).  Or do you plan on
  4718. converting all passed arrays into lists, in which case adding an array
  4719. type doesn't gain you very much at all.
  4720.  
  4721. NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751
  4722.  
  4723. From icon-group-request  Thu Sep 21 05:21:59 1989
  4724. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4725.     id AA21724; Thu, 21 Sep 89 05:21:59 MST
  4726. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  4727.     id AA16934; Thu, 21 Sep 89 05:18:22 -0700
  4728. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4729.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4730.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4731. Date: 21 Sep 89 12:10:32 GMT
  4732. From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  4733. Organization: Rensselaer Polytechnic Institute, Troy NY
  4734. Subject: Re: Icon additions
  4735. Message-Id: <1989Sep21.121032.14168@rpi.edu>
  4736. References: <8909202335.AA19395@megaron.arizona.edu>
  4737. Sender: icon-group-request@arizona.edu
  4738. To: icon-group@arizona.edu
  4739.  
  4740. In article <8909202335.AA19395@megaron.arizona.edu>, nevin1@ihlpb.UUCP (Nevin J Liber +1 312 979 4751) writes:
  4741. > >If I implemented a user-accessible pointer type I would implement it in a more
  4742. > >pascalish way. You can get a pointer to a variable, copy a pointer, or get
  4743. > >a pointer to newly allocated space.
  4744. > My question to you is:  what do you wish to be able to do with
  4745. > pointers in Icon?  Pointers are needed in languages like Pascal, C,
  4746. > etc. to implement entities such as linked lists and hash tables.  But
  4747. > these are already built into Icon!
  4748.  
  4749. Pointers could also be used to access non-Icon memory. This would obviously
  4750. be machine and os dependant, but I think is necessary for any language
  4751. on a personal computer. The most successeful pc programs are those which
  4752. directly use the machines resources. They may or may not do so in a
  4753. structured way. I will agree that this reason for pointers is a VERY
  4754. touchy subject.
  4755.  
  4756. Pointers are also usefull for constructing (more efficiently perhaps, or
  4757. more intuitively) tree structures which might have multiple pointers
  4758. in each record (and might have data in each record also).
  4759.  
  4760. > Also, trying to implement
  4761. > user-accessible pointers in conjunction with garbage collection is far
  4762. >from trivial.
  4763.  
  4764. The pointers I would implement would be required always to point to a
  4765. structure. This would simplify garbage collection in that there would be
  4766. a block (pointed to by a variable = accessible to garbage collector) which
  4767. contains a pointer to a block and the type of that block. I understand that
  4768. setting things up for the garbage collector is most important.
  4769.  
  4770. > I just can't see what new types of *implementation-independent*
  4771. > (I know that there basically only one implementation of Icon right now,
  4772. > but language design should not be restricted to one implementation)
  4773. > applications that I cannot now write in Icon solely because I don't have
  4774. > pointers.  What power would pointers give me?
  4775.  
  4776. Pointers are one way to implement pass by reference parameters. Basically, I
  4777. see an internal pointer type comming out to implement pass by reference
  4778. parameters without changing syntax in a way which would break existing
  4779. programs (a very important consideration in any change to Icon). Once these
  4780. pointers exist, it would be easy to make that pointer structure available
  4781. to the programmer.
  4782.  
  4783. > >The other thing I hope to be able to do is to allow arbitrary lower bounds
  4784. > >[on arrays,] which will improve the readability of some types of algorithms.
  4785. > IMHO, this would not be very Icon-ish.  First off, negative indices
  4786. > already are defined in Icon; they allow you to work from the end
  4787. > of a string, list, etc.  instead of the beginning; with arbituary
  4788. > lower bounds on arrays, this wouldn't work (there are ways to kludge it
  4789. > in, but code that would take advantage of it would look very messy).
  4790.  
  4791. I don't see how this would be non-Iconish, also note that the suggested
  4792. project in the Icon implementation book mentioned lower bounds other than
  4793. 1. Tables do not follow this indexing. I see arrays as allowing more
  4794. efficient means of storing data which most logically should be organized
  4795. in a multi-dimensioned manner by scalar indices. Sparse arrays should be
  4796. implemented with tables.
  4797.  
  4798. > Secondly:  for the current data types, to generate over them in reverse
  4799. > order the construct "every element := dataType[*dataType to 1 by -1]" works; 
  4800. > this would not hold true for non-0 lower-bounded arrays.
  4801.  
  4802. Not for tables. (note also that the "Iconish" way would be a lower bound
  4803. of 1 not 0 :-)
  4804.  
  4805. > Thirdly:  how does one pass an array to a procedure?  A procedure would
  4806. > need some way of determining the lower bound of an array passed to it
  4807.  
  4808. The array block will contain the ranges for each dimension. I think image()
  4809. would be one way to retrieve these. A record type access to them might also
  4810. work. At the worst case, an internal function may be used. Other than that,
  4811. arrays will be passed like all other structures (ie effectively a pointer
  4812. is passed)
  4813.  
  4814. One other item I was thinking of to go with arrays is a range data type
  4815. with a constuctor like .. (ie A[1..3]). This could allow reverse order
  4816. specification (which could even be used by the interpreter). I see that
  4817. this range data type would be converted to a subrange (1:3) if used
  4818. anywheres where a subrange is allowed (lists and strings). A[1..3]
  4819. might construct a list even.
  4820.  
  4821.  
  4822.  
  4823.  
  4824.  
  4825.  
  4826. Frank Filz
  4827. Center For Integrated Electronics
  4828. Rensselaer Polytechnic Institute
  4829. vicc@unix.cie.rpi.edu
  4830.  
  4831. From kwalker  Thu Sep 21 10:11:26 1989
  4832. Date: Thu, 21 Sep 89 10:11:26 MST
  4833. From: "Kenneth Walker" <kwalker>
  4834. Message-Id: <8909211711.AA08091@megaron.arizona.edu>
  4835. Received: by megaron.arizona.edu (5.59-1.7/15)
  4836.     id AA08091; Thu, 21 Sep 89 10:11:26 MST
  4837. In-Reply-To: <1989Sep21.121032.14168@rpi.edu>
  4838. To: icon-group
  4839. Subject: Re: Icon additions
  4840.  
  4841. > Date: 21 Sep 89 12:10:32 GMT
  4842. > From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  4843. > Pointers could also be used to access non-Icon memory. This would obviously
  4844. > be machine and os dependant, but I think is necessary for any language
  4845. > on a personal computer.
  4846.  
  4847. The word "necessary" is too strong. It is true that the feature
  4848. significantly extends the application domain of the language, though.
  4849.  
  4850. > Pointers are also usefull for constructing (more efficiently perhaps, or
  4851. > more intuitively) tree structures which might have multiple pointers
  4852. > in each record (and might have data in each record also).
  4853.  
  4854. The pointers are already there in the pointer semantics of Icon data
  4855. structures. Your suggestion would just make them explicit. It seems
  4856. to me that using them will necessarily make the code to construct
  4857. trees more verbose, without adding any power.
  4858.  
  4859. I am confused as to what your pointers would be allowed to point to.
  4860. You make 3 seemingly conflicting statements:
  4861.  
  4862. 1) > Pointers could also be used to access non-Icon memory.
  4863.  
  4864. 2) > The pointers I would implement would be required always to point to a
  4865.    > structure.
  4866.  
  4867. 3) > Pointers are one way to implement pass by reference parameters.
  4868.  
  4869. Number 1 could be an "unsafe" pointer type. That is, the programmer
  4870. would be responsible for avoiding any kind of memory violation. This
  4871. is somewhat un-Iconish, but one makes compromises in language design.
  4872. You will probably have to avoid pointing into an Icon structure, because
  4873. garbage collection won't know how to relocate the pointer (at least
  4874. not without changes to the garbage collector).
  4875.  
  4876. Number 2 is no problem; it corresponds to the current pointer semantics
  4877. of Icon data structures.
  4878.  
  4879. Number 3 requires pointers to variables. While this is no problem
  4880. for the garbage collector, there is a problem of dangling pointers
  4881. to local variables that no longer exist (this is not a problem if you
  4882. only use the pointers for pass-by-reference). Ignoring the problem
  4883. would be very un-Iconish! One solution is to allocate local variables
  4884. in the heap so they don't go away while something is pointing to them.
  4885. For programs that do a lot of procedure calls, this can significantly
  4886. increase the number of garbage collections. An other approach would
  4887. be to keep track of pointers to local variables and change them
  4888. to the null value when the procedure terminates. This would also
  4889. be expensive.
  4890.  
  4891.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  4892.    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  4893.  
  4894. From naucse!sbw  Thu Sep 21 11:36:27 1989
  4895. Received: by megaron.arizona.edu (5.59-1.7/15)
  4896.     id AA14503; Thu, 21 Sep 89 11:36:27 MST
  4897. Message-Id: <8909211737.AA26397@naucse>
  4898. Date: Thu, 21 Sep 89 10:37:37 MST
  4899. X-Mailer: Mail User's Shell (6.5 4/17/89)
  4900. From: naucse!naucse!sbw (Steve Wampler)
  4901. To: arizona!gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose)),
  4902.         arizona!icon-group
  4903. Subject: Re: Icon additions
  4904.  
  4905. On Sep 21 at  6:33, VICC Project (Rose) writes:
  4906. } Pointers could also be used to access non-Icon memory. This would obviously
  4907. } be machine and os dependant, but I think is necessary for any language
  4908. } on a personal computer. The most successeful pc programs are those which
  4909. } directly use the machines resources. They may or may not do so in a
  4910. } structured way. I will agree that this reason for pointers is a VERY
  4911. } touchy subject.
  4912.  
  4913. I can see this use, though perhaps there is some other way.
  4914.  
  4915. } Pointers are also usefull for constructing (more efficiently perhaps, or
  4916. } more intuitively) tree structures which might have multiple pointers
  4917. } in each record (and might have data in each record also).
  4918.  
  4919. I guess I don't see this one.  That's already easy to do.  Perhaps it's
  4920. more intuitive to one who things in pointers, but you're really using
  4921. pointers to represent hierarchies.
  4922.  
  4923. } The pointers I would implement would be required always to point to a
  4924. } structure. This would simplify garbage collection in that there would be
  4925. } a block (pointed to by a variable = accessible to garbage collector) which
  4926. } contains a pointer to a block and the type of that block. I understand that
  4927. } setting things up for the garbage collector is most important.
  4928.  
  4929. If you do this, then...
  4930.  
  4931. } Pointers are one way to implement pass by reference parameters. Basically, I
  4932.  
  4933. you're being redundant.  Given your constraint above, you already have it in
  4934. Icon.  Try the following program:
  4935.  
  4936.     procedure main()
  4937.        local a
  4938.           call(a := [])
  4939.           every write(!a)
  4940.     end
  4941.  
  4942.     procedure call(x)
  4943.           every put(x,1 to 10)
  4944.     end
  4945.  
  4946. You must mean to have internal pointers as being different than pointers at
  4947. the source level?
  4948.  
  4949. Pointers are not the only way to do this, though they are perhaps the
  4950. simplest to implement.  I do see a lot of redundancy showing up, however,
  4951. given that structures provide pointer 'functionality' already.  It only
  4952. seems a gain in having pass by reference to simple data types.  A more
  4953. 'Icon-ish' solution would be to extend the co-expression mechanism to
  4954. do it for you - i.e. have co-expressions exist in the environment of
  4955. their creation, rather than in a copy of that environment (providing
  4956. a scheme for isolating the environment if needed).  That gives you
  4957. more flexibility than simple pointers.  Of course, it also requires
  4958. some substantial (and potentially costly) changes to the implementation.
  4959.  
  4960. -- 
  4961.     Steve Wampler
  4962.     {....!arizona!naucse!sbw}
  4963.  
  4964. From icon-group-request  Thu Sep 21 12:23:10 1989
  4965. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  4966.     id AA16898; Thu, 21 Sep 89 12:23:10 MST
  4967. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  4968.     id AA08802; Thu, 21 Sep 89 12:06:36 -0700
  4969. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4970.     for icon-group@arizona.edu (icon-group@arizona.edu)
  4971.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4972. Date: 21 Sep 89 18:56:07 GMT
  4973. From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  4974. Organization: Rensselaer Polytechnic Institute, Troy NY
  4975. Subject: Re: Icon additions
  4976. Message-Id: <1989Sep21.185607.2120@rpi.edu>
  4977. References: <1989Sep21.121032.14168@rpi.edu>, <8909211711.AA08091@megaron.arizona.edu>
  4978. Sender: icon-group-request@arizona.edu
  4979. To: icon-group@arizona.edu
  4980.  
  4981. In article <8909211711.AA08091@megaron.arizona.edu>, kwalker@ARIZONA.EDU ("Kenneth Walker") writes:
  4982. > > Date: 21 Sep 89 12:10:32 GMT
  4983. > > From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  4984. > > 
  4985. > > Pointers could also be used to access non-Icon memory. This would obviously
  4986. > > be machine and os dependant, but I think is necessary for any language
  4987. > > on a personal computer.
  4988. > The word "necessary" is too strong. It is true that the feature
  4989. > significantly extends the application domain of the language, though.
  4990.  
  4991. Ok, I was too strong here. 
  4992.  
  4993. > > Pointers are also usefull for constructing (more efficiently perhaps, or
  4994. > > more intuitively) tree structures which might have multiple pointers
  4995. > > in each record (and might have data in each record also).
  4996. > The pointers are already there in the pointer semantics of Icon data
  4997. > structures. Your suggestion would just make them explicit. It seems
  4998. > to me that using them will necessarily make the code to construct
  4999. > trees more verbose, without adding any power.
  5000. > I am confused as to what your pointers would be allowed to point to.
  5001. > You make 3 seemingly conflicting statements:
  5002. > 1) > Pointers could also be used to access non-Icon memory.
  5003. > 2) > The pointers I would implement would be required always to point to a
  5004. >    > structure.
  5005. > 3) > Pointers are one way to implement pass by reference parameters.
  5006. > Number 1 could be an "unsafe" pointer type. That is, the programmer
  5007. > would be responsible for avoiding any kind of memory violation. This
  5008. > is somewhat un-Iconish, but one makes compromises in language design.
  5009. > You will probably have to avoid pointing into an Icon structure, because
  5010. > garbage collection won't know how to relocate the pointer (at least
  5011. > not without changes to the garbage collector).
  5012.  
  5013. I agree absolutely, I should have clarified things a bit. I think two
  5014. types of user pointers are implicated. One should only point to non-Icon
  5015. memory and the other for pointing to Icon structures (and this type might
  5016. also include some type information). One possibility is that if all the uses
  5017. of a non-Icon pointer are easy to enumerate (including possible calls to
  5018. malloc for non-Icon memory on the heap) Then one could set up a more
  5019. bomb proof pointer structure.
  5020.  
  5021. > Number 2 is no problem; it corresponds to the current pointer semantics
  5022. > of Icon data structures.
  5023.  
  5024. My intention is to follow Icon as closely as possible here to ease the work
  5025. of the garbage collector.
  5026.  
  5027. > Number 3 requires pointers to variables. While this is no problem
  5028. > for the garbage collector, there is a problem of dangling pointers
  5029. > to local variables that no longer exist (this is not a problem if you
  5030. > only use the pointers for pass-by-reference). Ignoring the problem
  5031. > would be very un-Iconish! One solution is to allocate local variables
  5032. > in the heap so they don't go away while something is pointing to them.
  5033. > For programs that do a lot of procedure calls, this can significantly
  5034. > increase the number of garbage collections. An other approach would
  5035. > be to keep track of pointers to local variables and change them
  5036. > to the null value when the procedure terminates. This would also
  5037. > be expensive.
  5038.  
  5039. This is one I didn't think about too much. Of course this is one advantage
  5040. of airing ones ideas in such a forum (of course when I sat down to actually
  5041. do the implementation I hope I would have seen this).
  5042.  
  5043. Here is an idea that might work:
  5044.  
  5045.    When a pointer to a local variable (static variables are fine) is generated,
  5046. we move the variable into the heap and replace the local variable with a
  5047. construct similar to a trapped variable. Thus if the pointer is left hanging,
  5048. the pointer is actually pointing to something in the heap which is then
  5049. accesible to the garbage collector and remains after the procedure returns.
  5050. I think this would provide protection without too much heap overhead. If the
  5051. use of a pointer to a local variable was intentional, and the procedure was
  5052. not re-entrant (recursive or otherwise), then a static variable could be used
  5053. to avoid the heap allocation.
  5054.  
  5055.  
  5056. One advantage that I do see to Icon pointers is that with care, you can never
  5057. end up with a dangling pointer. In Pascal or C it is easy to allocate
  5058. memory for a structure, set a pointer to it, copy that pointer, release the
  5059. memory and still have a pointer to the memory. In Icon, to deallocate
  5060. memory pointed to by a pointer, all we need do is set the variable to &null
  5061. (or any non-pointer variable). If all pointers to a structure are removed
  5062. in this way, the garbage collector will free the memory when called.
  5063.  
  5064. One thing in reference to non-Icon pointers is that I think most of the
  5065. time one would need them (other than for I/O type activities which can
  5066. easily be implemented in Icon so that pointers are not needed for them)
  5067. is that Icon can allocate the memory and then when the pointer need be
  5068. passed to some C or assembly function, the pointer can just be adjusted to
  5069. point to the space in the block. If a block is needed which can't be
  5070. moved, one could use malloc or modify the garbage collector in some way.
  5071.  
  5072.  
  5073. Frank Filz
  5074. Center For Integrated Electronics
  5075. Rensselaer Polytechnic Institute
  5076. vicc@unix.cie.rpi.edu
  5077.  
  5078. From vicc@unix.cie.rpi.edu  Thu Sep 21 12:34:01 1989
  5079. Received: from rpi.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5080.     id AA18009; Thu, 21 Sep 89 12:34:01 MST
  5081. Received: from unix.cie.rpi.edu by rpi.edu (4.0/SM35-RPI-ITS);
  5082.     id AA02426; Thu, 21 Sep 89 15:03:52 EDT for arizona!icon-group@arizona.edu
  5083. Date: Thu, 21 Sep 89 15:05:22 EDT
  5084. From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
  5085. Received: by unix.cie.rpi.edu (5.51/1.2-RPI-CIE)
  5086.     id AA19693; Thu, 21 Sep 89 15:05:22 EDT
  5087. Message-Id: <8909211905.AA19693@unix.cie.rpi.edu>
  5088. To: icon-group@arizona.edu, naucse!naucse!sbw@arizona.edu,
  5089.         vicc@unix.cie.rpi.edu
  5090. Subject: Re: Icon additions
  5091.  
  5092. I have often wanted to be able to refer to a variable containing a
  5093. simple type. Also, being able to pass a simple type by reference
  5094. is more efficient than constucting a list with that element and passing
  5095. the list (although admittedly to a small ammount).
  5096.  
  5097. Frank Filz
  5098.  
  5099. From icon-group-request  Thu Sep 21 12:36:07 1989
  5100. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5101.     id AA18127; Thu, 21 Sep 89 12:36:07 MST
  5102. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  5103.     id AA10421; Thu, 21 Sep 89 12:34:51 -0700
  5104. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  5105.     for icon-group@arizona.edu (icon-group@arizona.edu)
  5106.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  5107. Date: 21 Sep 89 17:15:33 GMT
  5108. From: dasys1!aj-mberg@nyu.edu  (Micha Berger)
  5109. Organization: AishDas Society: 73-32 173 St, Hillcrest NY 11366 (718)380-7572
  5110. Subject: Re: var params
  5111. Message-Id: <10746@dasys1.UUCP>
  5112. References: <1027@m3.mfci.UUCP>
  5113. Sender: icon-group-request@arizona.edu
  5114. To: icon-group@arizona.edu
  5115.  
  5116. "var" params, as you call it, is normally called "passing by reference. What
  5117. this means is that you're passing the variable, not the value it holds. "var"
  5118. is just the keyword Pascal uses, it's not the standard term. (The type of
  5119. passing ICON allows is "pass-by-value"; i.e. only the value is passed.)
  5120.  
  5121. Now, back to your question....
  5122.  
  5123. Passing by reference is considered by most language feature as dangerous. It
  5124. allows a function to change the value of a variable without the user realizing.
  5125. If you came back to your program years later, will you remember all the
  5126. side effects? 
  5127. The problem is that you can end up with p(a)+a <> a+p(a). If p's
  5128. parameter is passed by reference, and p changes the value of a,
  5129. it makes a difference which gets done first.
  5130.  
  5131. If you want to return a bunch of values from one function, why not return a
  5132. list?
  5133. -- 
  5134.                     Micha Berger
  5135.                     ...cucard!dasys1!aj-mberg
  5136.  
  5137. Imitatio Dei means never having to say "I'm sorry."
  5138.  
  5139. From icon-group-request  Fri Sep 22 05:05:33 1989
  5140. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5141.     id AA02746; Fri, 22 Sep 89 05:05:33 MST
  5142. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  5143.     id AA02509; Fri, 22 Sep 89 05:06:16 -0700
  5144. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  5145.     for icon-group@arizona.edu (icon-group@arizona.edu)
  5146.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  5147. Date: 22 Sep 89 12:00:00 GMT
  5148. From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  5149. Organization: Rensselaer Polytechnic Institute, Troy NY
  5150. Subject: Re: var params
  5151. Message-Id: <1989Sep22.120000.13561@rpi.edu>
  5152. References: <1027@m3.mfci.UUCP>, <10746@dasys1.UUCP>
  5153. Sender: icon-group-request@arizona.edu
  5154. To: icon-group@arizona.edu
  5155.  
  5156. In article <10746@dasys1.UUCP>, aj-mberg@dasys1.UUCP (Micha Berger) writes:
  5157. > Passing by reference is considered by most language feature as dangerous. It
  5158. > allows a function to change the value of a variable without the user
  5159. > realizing. If you came back to your program years later, will you remember
  5160. > all the side effects?
  5161.  
  5162. One must program ones procedures which use pass by reference such that side
  5163. effects will be obvious.
  5164.  
  5165. > The problem is that you can end up with p(a)+a <> a+p(a). If p's
  5166. > parameter is passed by reference, and p changes the value of a,
  5167. > it makes a difference which gets done first.
  5168.  
  5169. One of my personal styles is to avoid using a procedure which returns a
  5170. value (other than some kind of return code) in combination with pass by
  5171. reference parameters. The result is that the construct p(a) + a should not
  5172. occur.
  5173.  
  5174. > If you want to return a bunch of values from one function, why not return a
  5175. > list?
  5176.  
  5177. This might in general be fine, but there have been comments about the int86()
  5178. function for MS-DOS Icon which returns a list. It is a little slower because
  5179. of this, also in certain programs (which are probably using int86() to speed
  5180. things up) there is heavy use of int86() which then causes needless garbage
  5181. collections.
  5182.  
  5183. Of course in this instance one doesn't need special pass by reference since
  5184. Icon structures are always passed by reference.
  5185.  
  5186.  
  5187.  
  5188. Frank Filz
  5189. Center For Integrated Electronics
  5190. Rensselaer Polytechnic Institute
  5191. vicc@unix.cie.rpi.edu
  5192.  
  5193. From icon-group-request  Fri Sep 22 08:22:26 1989
  5194. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5195.     id AA09550; Fri, 22 Sep 89 08:22:26 MST
  5196. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  5197.     id AA12087; Fri, 22 Sep 89 08:15:33 -0700
  5198. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  5199.     for icon-group@arizona.edu (icon-group@arizona.edu)
  5200.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  5201. Date: 22 Sep 89 15:06:38 GMT
  5202. From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
  5203. Organization: Rensselaer Polytechnic Institute, Troy NY
  5204. Subject: Re: (none)
  5205. Message-Id: <1989Sep22.150638.21014@rpi.edu>
  5206. References: <8909181359.AA18860@megaron.arizona.edu>
  5207. Sender: icon-group-request@arizona.edu
  5208. To: icon-group@arizona.edu
  5209.  
  5210. I tried e-mail on this and it bounced so...
  5211.  
  5212. In article <8909181359.AA18860@megaron.arizona.edu>, pax@ihcup.UUCP writes:
  5213. > Ralph, Cheyenne,
  5214. > I know that you are not really very interested in the 640K DOS
  5215. > situation with Icon.  But, I have customers running Icon programs
  5216. > that I've written for them and they sure don't want to trash their
  5217. > existing 640K machines - at least not right now.
  5218. > Any help at all you can give me on memory management will be most
  5219. > appreciated.  Especially some words specifically on how to best
  5220. > trim the size of tables and lists as the items are no longer needed.
  5221.  
  5222. Garbage collection should take care of most of this, also If I remember
  5223. correctly you can delete from a table. pop, pull or get from a list to dispose
  5224. of extra entries.
  5225.  
  5226. > Also, I believe I can recreate dependably a problem with the
  5227. > system() function in DOS Icon.  Depending upon how large the
  5228. > program is, system() may or may not do anything.  No error
  5229. > or failure return - it's just as if the call was skipped.
  5230.  
  5231. You may have run out of memory to load COMMAND.COM. It does
  5232. seem odd however that there is no failure event or value returned to
  5233. indicate this failure.
  5234.  
  5235. To resolve the memory problem try the following:
  5236.  
  5237.    1. Trim your program
  5238.  
  5239.    2. set the STRSIZE and BLOCKSIZE environment variables so that less
  5240.       than 65k is allocated for these regions
  5241.  
  5242.    3. trim out TSRs like sidekick
  5243.  
  5244.  
  5245. Frank Filz
  5246. Center For Integrated Electronics
  5247. Rensselaer Polytechnic Institute
  5248. vicc@unix.cie.rpi.edu
  5249.  
  5250. From goer@sophist.uchicago.edu  Sun Sep 24 11:11:19 1989
  5251. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5252.     id AA24862; Sun, 24 Sep 89 11:11:19 MST
  5253. Received: from sophist.uchicago.edu by tank.uchicago.edu Sun, 24 Sep 89 13:13:20 CDT
  5254. Return-Path: <goer@sophist.uchicago.edu>
  5255. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  5256.     id AA17945; Sun, 24 Sep 89 13:09:33 CDT
  5257. Date: Sun, 24 Sep 89 13:09:33 CDT
  5258. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  5259. Message-Id: <8909241809.AA17945@sophist.uchicago.edu>
  5260. To: icon-group@arizona.edu
  5261. Subject: removing one or more elements from a list
  5262.  
  5263. Having written some slow and inelegant code, I am left wondering
  5264. whether anyone has evolved other solutions to the problem of how
  5265. to remove a specific element from a list.
  5266.  
  5267. Basically, what I need to do is be able to remove a range of
  5268. members from a given list -
  5269.  
  5270.       removerange(lst,firstone,secondone)
  5271.         # returns lst[1:firstone] ||| lst[secondone+1:0]
  5272.         # unless firstone = 1 in which case, it returns
  5273.         # lst[secondone + 1:0]
  5274.         # same sort of thing when secondone = *lst
  5275.       end
  5276.  
  5277. Kinda cluttered-looking, when written out in full.  I tried a recur-
  5278. sive procedure where one element is removed for each element from
  5279. firstone to secondone.  That way I really needed only one procedure
  5280. to remove a single element, and one every loop.  But this was slow.
  5281.  
  5282. Anyone have any ideas?
  5283.  
  5284.                                         -Richard L. Goerwitz
  5285.                                         goer@sophist.uchicago.edu
  5286.                                         rutgers!oddjob!gide!sophist!goer
  5287.  
  5288. From icon-group-request  Sun Sep 24 21:07:53 1989
  5289. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5290.     id AA14922; Sun, 24 Sep 89 21:07:53 MST
  5291. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  5292.     id AA08040; Sun, 24 Sep 89 21:09:46 -0700
  5293. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  5294.     for icon-group@arizona.edu (icon-group@arizona.edu)
  5295.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  5296. Date: 23 Sep 89 10:52:23 GMT
  5297. From: uhccux!munnari.oz.au!cs.mu.oz.au!ok@ames.arc.nasa.gov  (Richard O'Keefe)
  5298. Subject: Re: var params
  5299. Message-Id: <2174@munnari.oz.au>
  5300. References: <1027@m3.mfci.UUCP>, <10746@dasys1.UUCP>
  5301. Sender: icon-group-request@arizona.edu
  5302. To: icon-group@arizona.edu
  5303.  
  5304. [I've lost the original context]
  5305. In article <10746@dasys1.UUCP>, aj-mberg@dasys1.UUCP (Micha Berger) writes:
  5306. > "var" params, as you call it, is normally called "passing by reference.
  5307.  
  5308. If you will be content with pass by value result (as Fortran and Ada are),
  5309. you can get that effect just by bending the Icon translator.  Suppose, for
  5310. example, that you add Ada syntax for arguments:
  5311.     'in'        value passed in
  5312.     'out'        result passed back
  5313.     'in out'    value passed in and result passed back.
  5314. A procedure definition like
  5315.     procedure foo(in x, out y, in out z)
  5316.     ...
  5317.     end
  5318. could be translated as
  5319.  
  5320.     procedure foo(x, OUTARGS)
  5321.         use OUTARGS[1] wherever y appears
  5322.         use OUTARGS[2] wherever z appears
  5323.     end
  5324.  
  5325. A call
  5326.     foo(eks, out wye, in out zed)
  5327. would then be translated as
  5328.     temp := [&null, zed];
  5329.     foo(eks, temp);
  5330.     wye := temp[1], zed := temp[2]
  5331.  
  5332. This gets a wee bit tricky if wye and zed are expressions, but Icon
  5333. already has the machinery to represent "references" so that procedure
  5334. calls can be used on the left hand side of := .
  5335.  
  5336. This looks as though it should work, and it seems like a better idea to
  5337. just bend the translator than to hack the low level stuff -- more portable
  5338. if you do it right.  And you'll have to bend the translator anyway.
  5339.  
  5340. From EM302723@VMTECMEX.BITNET  Mon Sep 25 07:09:55 1989
  5341. Message-Id: <8909251409.AA13884@megaron.arizona.edu>
  5342. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5343.     id AA13884; Mon, 25 Sep 89 07:09:55 MST
  5344. Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Mon, 25 Sep 89 07:11
  5345.  MST
  5346. Received: by VMTECMEX (Mailer R2.03B) id 3045; Mon, 25 Sep 89 07:59:28 MEX
  5347. Date: Mon, 25 Sep 89 07:57:34 MEX
  5348. From: "Mario Camou R. (Dr. Mangagoras)" <EM302723@VMTECMEX.BITNET>
  5349. Subject: Re: cursor control on PC
  5350. To: icon-group@arizona.edu
  5351.  
  5352. My fault. I was too unspecific on my last posting. What I'm interested in is
  5353. in an implementation (personalized interpreter?) of Icon which uses some kind
  5354. of WINDOWING library (curses-like, or something similar). Has anybody worked
  5355. on that?
  5356.  
  5357.  
  5358. +----------------------------------+------------------------------+
  5359. |                                  | Mario Camou Riveroll         |
  5360. |  Dr. Mangagoras                  | Apdo. Postal 41554           |
  5361. |  EM302723@VMTECMEX.BITNET        | Lomas de Chapultepec         |
  5362. |                                  | Mexico, D.F. 11001           |
  5363. |                                  |                              |
  5364. | "Don't take life too seriously   | "Laugh at life, or life will |
  5365. | it's just a temporary situation" | laugh at you"                |
  5366. +----------------------------------+------------------------------+
  5367.  
  5368. From goer@sophist.uchicago.edu  Tue Sep 26 10:59:39 1989
  5369. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5370.     id AA00814; Tue, 26 Sep 89 10:59:39 MST
  5371. Received: from sophist.uchicago.edu by tank.uchicago.edu Tue, 26 Sep 89 12:15:00 CDT
  5372. Return-Path: <goer@sophist.uchicago.edu>
  5373. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  5374.     id AA21032; Tue, 26 Sep 89 12:11:08 CDT
  5375. Date: Tue, 26 Sep 89 12:11:08 CDT
  5376. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  5377. Message-Id: <8909261711.AA21032@sophist.uchicago.edu>
  5378. To: icon-group@arizona.edu
  5379. Subject: tables, efficiency
  5380.  
  5381. Could someone familiar with the implementation of tables explain
  5382. how efficient use can be made of storage when the ultimate size
  5383. of the table is unknown?  Or does the interpreter indeed check
  5384. to see how big the various regions are, and adjust the algorithm
  5385. to make maximum use of a given memory space?
  5386.  
  5387. Just dunno, but would like t'know.
  5388.  
  5389.                                         -Richard L. Goerwitz
  5390.                                         goer@sophist.uchicago.edu
  5391.                                         rutgers!oddjob!gide!sophist!goer
  5392.  
  5393. From wgg@june.cs.washington.edu  Tue Sep 26 14:13:47 1989
  5394. Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5395.     id AA15616; Tue, 26 Sep 89 14:13:47 MST
  5396. Received: by june.cs.washington.edu (5.61/7.0j)
  5397.     id AA07260; Tue, 26 Sep 89 14:13:49 -0700
  5398. Date: Tue, 26 Sep 89 14:13:49 -0700
  5399. From: wgg@june.cs.washington.edu (William Griswold)
  5400. Return-Path: <wgg@june.cs.washington.edu>
  5401. Message-Id: <8909262113.AA07260@june.cs.washington.edu>
  5402. To: goer@sophist.uchicago.edu, icon-group@arizona.edu
  5403. Subject: Re:  tables, efficiency
  5404.  
  5405. >Date: Tue, 26 Sep 89 12:11:08 CDT
  5406. >From: Richard Goerwitz <goer@sophist.uchicago.edu>
  5407. >To: icon-group@arizona.edu
  5408. >Subject: tables, efficiency
  5409. >Errors-To: icon-group-errors@arizona.edu
  5410. >
  5411. >Could someone familiar with the implementation of tables explain
  5412. >how efficient use can be made of storage when the ultimate size
  5413. >of the table is unknown?  Or does the interpreter indeed check
  5414. >to see how big the various regions are, and adjust the algorithm
  5415. >to make maximum use of a given memory space?
  5416. >
  5417. >Just dunno, but would like t'know.
  5418. >
  5419. >                                        -Richard L. Goerwitz
  5420.  
  5421.  
  5422. The current table implementation uses a simple hashing scheme.  If you are
  5423. not familiar with hashing, check your nearest data structures text or the
  5424. Knuth volume on searching and sorting.  The briefest description follows.
  5425.  
  5426. Basically, a hashing data structure allows computing an array index for
  5427. an input element (a constant-time operation), and storing the element at
  5428. that index.  If multiple elements are assigned to the same slot, both are
  5429. stored there on a linked list.  Elements on a chain are stored in sorted
  5430. order of their hash numbers.  By simple hashing, I mean that there are a
  5431. fixed number of hash slots.  For small tables, constant-time access is
  5432. usually achieved for an individual element.  For tables over 1000
  5433. elements, performance begins to degrade measurably.  This is due to the
  5434. linear-time cost of searching down the hash chain.
  5435.  
  5436. Hashing does not take memory availability into account in building tables.
  5437. It is hard to say how this could be done effectively in the face of so
  5438. many dynamic properties of programs.
  5439.  
  5440. However, an upcoming version of Icon may have an implementation of tables 
  5441. (and sets) employing dynamic hashing.  Dynamic hashing permits increasing 
  5442. the number of slots in a hash table as a table grows.  This avoids 
  5443. performance degradation when tables become large, because the collision 
  5444. resolution chains are kept short.  This uses an additional 10% of memory
  5445. over the old hash table implementation.  It does not take memory
  5446. availability characteristics in to account, unless memory is actually
  5447. exhausted.  For a more complete description of dynamic hashing, look for
  5448. your next issue of the Icon Newsletter. 
  5449.  
  5450. I should note that taking memory characteristics into account on a machine 
  5451. supporting a paging operating system does not make sense.  The operating
  5452. system on such a system makes every attempt to make the finiteness of
  5453. memory invisible in terms of function *and* performance.  They are usually
  5454. successful.  This is not at all the case with PC machines with more
  5455. primitive operating systems.  With any luck, however, all of these
  5456. machines will be gone in a decade. 
  5457.  
  5458.  
  5459.                     Bill Griswold
  5460.  
  5461. From icon-group-request  Tue Sep 26 14:19:27 1989
  5462. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5463.     id AA15913; Tue, 26 Sep 89 14:19:27 MST
  5464. Received: by ucbvax.Berkeley.EDU (5.61/1.37)
  5465.     id AA13076; Tue, 26 Sep 89 14:00:24 -0700
  5466. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  5467.     for icon-group@arizona.edu (icon-group@arizona.edu)
  5468.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  5469. Date: 26 Sep 89 18:09:16 GMT
  5470. From: hsi!mfci!m3!genly@uunet.uu.net  (Chris Hind Genly)
  5471. Organization: Multiflow Computer Inc., Branford CT
  5472. Subject: var params
  5473. Message-Id: <1045@m3.mfci.UUCP>
  5474. Sender: icon-group-request@arizona.edu
  5475. To: icon-group@arizona.edu
  5476.  
  5477. In article <10746@dasys1.UUCP> aj-mberg@dasys1.UUCP (Micha Berger) writes:
  5478.  
  5479.    From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
  5480.    I too miss var parameters, unfortuanately they require a new data
  5481.    type (to some extent at least) to implement.
  5482.  
  5483. Thanks for the reply.
  5484.  
  5485.    From: aj-mberg@dasys1.UUCP (Micha Berger)
  5486.    "var" params, as you call it, is normally called "passing by reference.
  5487.  
  5488. I was being informal here.  Either pass by reference or copy-in copy-out would
  5489. accomplish what I want.
  5490.  
  5491.    Passing by reference is considered by most language feature as
  5492.    dangerous. It allows a function to change the value of a variable
  5493.    without the user realizing.
  5494.  
  5495. This is an issue of exposition.  It is not clear from looking at a
  5496. call using pass-by-reference that it is actually using pass by
  5497. reference.  One must go to the definition of the procedure being
  5498. called.  Rather than the feature of pass-by-reference being dangerous,
  5499. this seems to be a weakness in the syntax of a language like Pascal.
  5500. There is no difference in the syntax between passing an argument by
  5501. value or by reference.  If the syntax were different, anyone reading
  5502. the source would know that the value of an argument could be changed.
  5503.  
  5504. As an example, if the values which are to be passed by referenced were
  5505. followed by an '=', then it would be clear which variables could be
  5506. changed.  In the following example, a could not change value, while b
  5507. and c could.
  5508.  
  5509.         p(a, b=, c=)
  5510.  
  5511.    If you want to return a bunch of values from one function, why not
  5512.    return a list?
  5513.  
  5514. This is a matter of clarity and efficiency.  I want to be able to
  5515. express pass-by-reference in the language directly.  I don't want to
  5516. introduce an auxiliary structure like a list, and have to pack it and
  5517. unpack it.  The list has nothing to do with the reason I am writing
  5518. the program.  I don't want to introduce it just to work around the
  5519. lack of call by reference.
  5520.  
  5521.    From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
  5522.    One must program ones procedures which use pass by reference such that side
  5523.    effects will be obvious.
  5524.  
  5525. Agreed.  I would be interested in what techniques you've been using to do this.
  5526.  
  5527.    From: ok@cs.mu.oz.au (Richard O'Keefe)
  5528.    If you will be content with pass by value result (as Fortran and Ada are),
  5529.    you can get that effect just by bending the Icon translator.  Suppose, for
  5530.    example, that you add Ada syntax for arguments:
  5531.        'in'        value passed in
  5532.        'out'        result passed back
  5533.        'in out'    value passed in and result passed back.
  5534.  
  5535. I wasn't actually proposing to change the language, but this is along
  5536. the lines I was thinking.
  5537.  
  5538.  
  5539.  
  5540. I understand how to work around call-by-value, and I see that its
  5541. possible to change the translator.  But I'm still wondering if people
  5542. miss the ability to return multiple values from a call.  Regardless of
  5543. the mechanism, either by call-by-reference, copy-in copy-out, or by a
  5544. multi-valued return value.
  5545.  
  5546. Do you find you have to return multiple value so few times that its
  5547. not a problem?  Are the icon programs you write so small that you
  5548. resort to using global variables without trading off
  5549. understandability?  Do you find using an auxiliary structure to pack
  5550. multiple return values to be unobtrusive?
  5551.  
  5552. --
  5553. =======================================================================
  5554. Chris Hind Genly, N1GLZ - Multiflow Computer - mfci!genly (203)488-6090
  5555.  
  5556.     
  5557.  
  5558. From @ricevm1.rice.edu:EM302723@VMTECMEX.BITNET  Mon Oct  9 16:21:06 1989
  5559. Message-Id: <8910092321.AA23785@megaron.arizona.edu>
  5560. Received: from icsa.rice.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5561.     id AA23785; Mon, 9 Oct 89 16:21:06 MST
  5562. Received: from VMTECMEX.BITNET by ricevm1.rice.edu (IBM VM SMTP R1.2.1) with BSMTP id 8974; Mon, 09 Oct 89 18:21:34 CDT
  5563. Date: Mon, 09 Oct 89 09:40:02 MEX
  5564. To: icon-group@arizona.edu
  5565. From: EM302723%VMTECMEX.BITNET@ricevm1.rice.edu
  5566. Comment: CROSSNET mail via SMTP@INTERBIT
  5567.  
  5568. Date: 9 October 89, 09:39:35 MEX
  5569. From: Mario Camou R. (Dr. Mangagoras)                EM302723 at VMTECMEX
  5570. To:   ICON-GROUP at ARIZONA
  5571. Subject: Icon assembler?
  5572.  
  5573.  
  5574. Hi,
  5575. I have been browsing through the Icode files produced by ICONT. They seem to be
  5576. coded in some kind of assembly code...Has anybody thought about writing some
  5577. sort of an Icode assembler? It seems to me that a version of ICONX that worked
  5578. with binary files should be faster than one that works with text files. Also,
  5579. it SHOULD use less memory (maybe you UNIX hacks with gigabytes of virtual
  5580. memory don't think much about this...but memory is scarce in the MS-DOS envi-
  5581. ronment). I really haven't read the implementation book, so I don't know much
  5582. about what I'm talking about. This is just an idea that cropped up recently.
  5583. Any comments?
  5584.  
  5585. +----------------------------------+------------------------------+
  5586. |  Dr. Mangagoras                  | Mario Camou Riveroll         |
  5587. |  EM302723@VMTECMEX.BITNET        | Apdo. Postal 41554           |
  5588. |                                  | Mexico, D.F. 11001 Mexico    |
  5589. +----------------------------------+------------------------------+
  5590. | Don't take life too seriously - it's just a temporary situation |
  5591. +-----------------------------------------------------------------+
  5592.  
  5593. From kwalker  Wed Oct 11 17:12:51 1989
  5594. Date: Wed, 11 Oct 89 17:12:51 MST
  5595. From: "Kenneth Walker" <kwalker>
  5596. Message-Id: <8910120012.AA04649@megaron.arizona.edu>
  5597. Received: by megaron.arizona.edu (5.59-1.7/15)
  5598.     id AA04649; Wed, 11 Oct 89 17:12:51 MST
  5599. In-Reply-To: <8910092321.AA23785@megaron.arizona.edu>
  5600. To: icon-group
  5601.  
  5602. > Date: 9 October 89, 09:39:35 MEX
  5603. > From: Mario Camou R. (Dr. Mangagoras)                EM302723 at VMTECMEX
  5604. > Hi,
  5605. > I have been browsing through the Icode files produced by ICONT. They seem to be
  5606. > coded in some kind of assembly code...Has anybody thought about writing some
  5607. > sort of an Icode assembler? It seems to me that a version of ICONX that worked
  5608. > with binary files should be faster than one that works with text files. Also,
  5609. > it SHOULD use less memory (maybe you UNIX hacks with gigabytes of virtual
  5610. > memory don't think much about this...but memory is scarce in the MS-DOS envi-
  5611. > ronment).
  5612.  
  5613. You can think of iconx as an intepreter implementing a virtual machine. In
  5614. which case the ucode (the text files produced with the -c option to icont)
  5615. can be viewed as a kind of assembly language. In addition to creating ucode
  5616. files, icont combines (links) them, resolving undeclared variables, and
  5617. produces icode files. The icode is in binary form and is the "machine code"
  5618. for iconx.
  5619.  
  5620. Even when you don't use the -c option, icont creates temporary ucode
  5621. files and deletes them when it is done. It would probably be more
  5622. efficient if icont created intermediate code in binary form rather
  5623. than as text. However, the text files are useful for debugging Icon and
  5624. for understanding the implementation. No one has yet done a lot of work
  5625. on improving the efficiency of icont.
  5626.  
  5627. It is possible to translate ucode into a real machine code. However, you
  5628. won't necessarily gain in terms of memory. Icode is quite compact. 
  5629. In addition, if you produce a real executable, you will have to link
  5630. in most of the Icon run-time system (the biggest part of iconx). Each
  5631. program you have compiled and linked will have a copy of this run-time
  5632. code, taking up a lot of disk space. If you think you can tell what is
  5633. called and thus link in only a fraction of the library, consider the
  5634. problem of string invocation (this is a problem we must tackle in our
  5635. research into an optimizing compiler for Icon).
  5636.  
  5637. Real machine code will gain you something in terms of speed, but
  5638. less than you might think. Icon programs spend most of their time
  5639. in run-time routines, not in intepreting icode instructions. An earlier
  5640. version of Icon had a compiler which produced machine code. In addition,
  5641. Janalee O'Bagy has a prototype compiler which produces machine code
  5642. (with C code as an intermediate step). The speed improvement for the
  5643. eariler compiler is usually quoted as being 5%-10% for typical programs.
  5644. In her dissertation, Janalee O'Bagy lists speed improvements for
  5645. naive compilation of 6 programs as ranging from 3% to 24%. Better
  5646. speed improvements require more than simple "assembly" of ucode.
  5647.  
  5648.    Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  5649.    +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker
  5650.  
  5651. From EM302723@VMTECMEX.BITNET  Fri Oct 13 18:11:44 1989
  5652. Message-Id: <8910140111.AA06348@megaron.arizona.edu>
  5653. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5654.     id AA06348; Fri, 13 Oct 89 18:11:44 MST
  5655. Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Fri, 13 Oct 89 18:11
  5656.  MST
  5657. Received: by VMTECMEX (Mailer R2.03B) id 3250; Fri, 13 Oct 89 09:33:49 MEX
  5658. Date: Fri, 13 Oct 89 09:28:33 MEX
  5659. From: "Mario Camou R. (Dr. Mangagoras)" <EM302723@VMTECMEX.BITNET>
  5660. Subject: Icon executables?
  5661. To: icon-group@arizona.edu
  5662.  
  5663. OK...so you wouldn't get much of a speed gain by directly compiling to machine
  5664. code.
  5665.  
  5666. However, that brings up another idea. Seems to me that to have a directly
  5667. executable Icon program would be a real help in production systems (whether
  5668. internal use or for external distribution). An idea would be to put an option
  5669. on ICONT so that ICONX is linked together with the program. That way you would
  5670. get executable programs without modifying ICONT or ICONX too much.
  5671.  
  5672. Of course, I'm just speaking from the top of my head. How's this sound, feasi-
  5673. bility-wise?
  5674.  
  5675. +----------------------------------+------------------------------+
  5676. |  Dr. Mangagoras                  | Mario Camou Riveroll         |
  5677. |  EM302723@VMTECMEX.BITNET        | Apdo. Postal 41554           |
  5678. |                                  | Mexico, D.F. 11001 Mexico    |
  5679. +----------------------------------+------------------------------+
  5680. | Don't take life too seriously - it's just a temporary situation |
  5681. +-----------------------------------------------------------------+
  5682.  
  5683. From icon-group-request  Sat Oct 14 02:54:29 1989
  5684. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5685.     id AA21138; Sat, 14 Oct 89 02:54:29 MST
  5686. Received: by ucbvax.Berkeley.EDU (5.61/1.38)
  5687.     id AA11007; Sat, 14 Oct 89 02:42:07 -0700
  5688. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  5689.     for icon-group@arizona.edu (icon-group@arizona.edu)
  5690.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  5691. Date: 14 Oct 89 03:15:00 GMT
  5692. From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!petersen@iuvax.cs.indiana.edu
  5693. Subject: Re: (none)
  5694. Message-Id: <30300001@uicsrd.csrd.uiuc.edu>
  5695. Sender: icon-group-request@arizona.edu
  5696. To: icon-group@arizona.edu
  5697.  
  5698.  
  5699. It seems the one solution to promoting icon programs as first class
  5700. citizens would be to use dynamic libraries such as used by the
  5701. Amiga, OS/2, or SunOS 4.0.  This would allow compilation to machine code
  5702. without the need to link in the run time library explicitly into
  5703. each copy.  Has any work been done to support this on the systems
  5704. that have dynamic libraries?
  5705.  
  5706. -Paul Petersen (petersen@uicsrd.csrd.uiuc.edu)
  5707.  
  5708. From icon-group-request  Mon Oct 16 11:44:52 1989
  5709. Received: from ucbvax.Berkeley.EDU by megaron (5.59-1.7/15) via SMTP
  5710.     id AA01740; Mon, 16 Oct 89 11:44:52 MST
  5711. Received: by ucbvax.Berkeley.EDU (5.61/1.39)
  5712.     id AA22589; Mon, 16 Oct 89 11:25:39 -0700
  5713. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  5714.     for icon-group@arizona.edu (icon-group@arizona.edu)
  5715.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  5716. Date: 16 Oct 89 13:35:17 GMT
  5717. From: esquire!yost@nyu.edu  (David A. Yost)
  5718. Organization: DP&W, New York, NY
  5719. Subject: Re: icon should use dynamic linking on systems that have it
  5720. Message-Id: <1487@esquire.UUCP>
  5721. References: <30300001@uicsrd.csrd.uiuc.edu>
  5722. Sender: icon-group-request@arizona.edu
  5723. To: icon-group@arizona.edu
  5724.  
  5725. In article <30300001@uicsrd.csrd.uiuc.edu> petersen@uicsrd.csrd.uiuc.edu writes:
  5726. >It seems the one solution to promoting icon programs as first class
  5727. >citizens would be to use dynamic libraries such as used by the
  5728. >Amiga, OS/2, or SunOS 4.0.  This would allow compilation to machine code
  5729. >without the need to
  5730.              invoke a separate interpreter program at runtime.
  5731.  
  5732. This is a nice idea.
  5733.  
  5734. I think the problem of Icon first class
  5735. citizenry is that there has to be another
  5736. file installed somewhere (the interpreter).
  5737. Moving the interpreter from its present home
  5738. in an executable file to a new home in a
  5739. shared library doesn't change this.
  5740.  
  5741. Aside from startup time, would execution time
  5742. or in-core memory residency really be improved?
  5743.  
  5744.  --dave
  5745.  
  5746. From EM302723@VMTECMEX.BITNET  Fri Oct 27 17:37:27 1989
  5747. Message-Id: <8910280037.AA19850@megaron>
  5748. Received: from rvax.ccit.arizona.edu by megaron (5.59-1.7/15) via SMTP
  5749.     id AA19850; Fri, 27 Oct 89 17:37:27 MST
  5750. Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Fri, 27 Oct 89 17:37
  5751.  MST
  5752. Received: by VMTECMEX (Mailer R2.04) id 9737; Fri, 27 Oct 89 15:45:49 MEX
  5753. Date: Fri, 27 Oct 89 15:44:11 MEX
  5754. From: "Dr. Mangagoras" <EM302723@VMTECMEX.BITNET>
  5755. Subject: Are you still alive?
  5756. To: Icon user's group <icon-group@arizona.edu>
  5757.  
  5758. Hi,
  5759. Since it's been a couple of weeks since I received anything from this group
  5760. I was wondering whether everybody's still alive and well in Iconland, or
  5761. if everybody has left for the next language revolution. What's up??
  5762.  
  5763. +----------------------------------+------------------------------+
  5764. |  Dr. Mangagoras                  | Mario Camou Riveroll         |
  5765. |  EM302723@VMTECMEX.BITNET        | Apdo. Postal 41554           |
  5766. |                                  | Mexico, D.F. 11001 Mexico    |
  5767. +----------------------------------+------------------------------+
  5768. | Don't take life too seriously - it's just a temporary situation |
  5769. +-----------------------------------------------------------------+
  5770.  
  5771. From icon-group-request  Sun Oct 29 01:16:40 1989
  5772. Received: from ucbvax.Berkeley.EDU by megaron (5.59-1.7/15) via SMTP
  5773.     id AA19114; Sun, 29 Oct 89 01:16:40 MST
  5774. Received: by ucbvax.Berkeley.EDU (5.61/1.39)
  5775.     id AA01733; Sun, 29 Oct 89 01:10:10 -0700
  5776. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  5777.     for icon-group@arizona.edu (icon-group@arizona.edu)
  5778.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  5779. Date: 29 Oct 89 03:50:15 GMT
  5780. From: agate!saturn!ucscg.UCSC.EDU!kellyp@ucbvax.Berkeley.EDU  (17531000)
  5781. Organization: University of California, Santa Cruz  CATS
  5782. Subject: some questions
  5783. Message-Id: <9551@saturn.ucsc.edu>
  5784. Sender: icon-group-request@arizona.edu
  5785. To: icon-group@arizona.edu
  5786.  
  5787. Is there a pre-procesor around for making Icon object oriented?  In the
  5788. spirit of C++.  If not, how difficult would this be to make?  I'm looking 
  5789. for encapsulation and auto-setup/terminate procedures.  The main thing 
  5790. is that I don't like to worry about name conflicts when I put modules together.
  5791.  
  5792. ----
  5793.  
  5794. I lost the two messages I received about Emacs helpers for Icon. Could
  5795.    you send them again?
  5796.  
  5797. ----
  5798.  
  5799. In article <1487@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes:
  5800. >In article <30300001@uicsrd.csrd.uiuc.edu> petersen@uicsrd.csrd.uiuc.edu ws:
  5801. >>It seems the one solution to promoting icon programs as first class
  5802. >>citizens would be to use dynamic libraries such as used by the
  5803. >>Amiga, OS/2, or SunOS 4.0.  This would allow compilation to machine code
  5804. >>without the need to
  5805. >             invoke a separate interpreter program at runtime.
  5806. >
  5807. >Aside from startup time, would execution time
  5808. >or in-core memory residency really be improved?
  5809. >
  5810. > --dave
  5811.  
  5812. Yes.  On the Amiga using a library would make it so that the interpreter
  5813. stuff is only loaded once.  As it is currently, each time you invoke
  5814. an Icon program the header (interpreter) is also loaded.  Another way to 
  5815. fix this is to make the header 'resident'.  This requires that the
  5816. header be re-entrant.  In the latest version that I picked up (for the
  5817. Amiga) there is only icont and iconx.  The compiled program can not be
  5818. invoked itself, you must do 'iconx prg'.  I tried making it resident and
  5819. it did some strange things concerning the command line arguments on the
  5820. second invocation, and I concluded that it was not re-entrant.
  5821.  
  5822. For the Amiga, it seems to me, that the simplest way to avoid double
  5823. loads would be to make the interpreter re-entrant and make it 'resident'.
  5824. The problems with this is that the load of the interpreter must be made
  5825. explicitly (with the resident command) or else you are right back where 
  5826. you started (loading multiple copies into memory).  To use a library
  5827. would make it so that the load is done implicitly when a compiled Icon
  5828. program is invoked.  To make a library would be a heck of a lot harder.
  5829.  
  5830. If this was done, tho, you have an interesting situation: any program may
  5831. access the library.  The library could be used as an imbedded virtual
  5832. machine within an application.
  5833. -----------------------------------------------------------------------------
  5834. Patrick Kelly    ----   mail to kellyp@ucscB.ucsc.edu   ----    Zxcvbne Rtyui
  5835. -----------------------------------------------------------------------------
  5836.  
  5837. From cjeffery  Sun Oct 29 16:20:19 1989
  5838. Date: Sun, 29 Oct 89 16:20:19 MST
  5839. From: "Clinton Jeffery" <cjeffery>
  5840. Message-Id: <8910292320.AA23794@megaron.arizona.edu>
  5841. Received: by megaron.arizona.edu (5.59-1.7/15)
  5842.     id AA23794; Sun, 29 Oct 89 16:20:19 MST
  5843. To: icon-group
  5844. Subject: Making Iconx resident on the Amiga
  5845.  
  5846. As the Amiga contact at Arizona, I feel obliged to comment on the recent
  5847. discussion.  Yes, making iconx resident would make Icon much more pleasant
  5848. on the Amiga.  There are a lot of other things that would make Icon much
  5849. more pleasant on the Amiga, for that matter.
  5850.  
  5851. While I do not have the time available to learn machine-specific
  5852. environments like the Amiga, I would certainly be glad to talk to
  5853. any C/Amiga-gurus interested in tackling the residence problem.
  5854. If anyone makes this work and sends us some reasonable source code we'll
  5855. be sure to incorporate it into the next release of Amiga Icon.  This
  5856. goes for other niceties that fall under the category of "Amigazation"
  5857. instead of the category of "computer science research".
  5858.  
  5859. Clint Jeffery
  5860. --
  5861. P.S. I am speaking for myself.  This is not an Icon project opinion.
  5862.  
  5863. From cjeffery  Sun Oct 29 16:49:04 1989
  5864. Date: Sun, 29 Oct 89 16:49:04 MST
  5865. From: "Clinton Jeffery" <cjeffery>
  5866. Message-Id: <8910292349.AA24876@megaron.arizona.edu>
  5867. Received: by megaron.arizona.edu (5.59-1.7/15)
  5868.     id AA24876; Sun, 29 Oct 89 16:49:04 MST
  5869. To: kellyp@ucscB.ucsc.EDU
  5870. Cc: icon-group@arizona.edu
  5871. Subject: Objects and Icon
  5872.  
  5873. Several people have done work towards an object-oriented Icon.  The first
  5874. person to propose anything concrete was (I think) Bill Griswold; I hope
  5875. he (and the others working in this area) will comment on the status of
  5876. their projects and whether they are publicly available.
  5877.  
  5878. My own hack, an Icon-Derived Object Language (Idol), will be described in
  5879. the next Icon newsletter.  It is a preprocessor rather than a modification
  5880. to icont or a variant translator.  It provides the encapsulation and
  5881. auto-setup procedures you requested within the framework of classes
  5882. and multiple inheritance.  It looks more like Icon than C++.
  5883.  
  5884. I will see about placing a copy of Idol in our FTP copying area.  Email
  5885. me if you are interested.
  5886.  
  5887. Clint Jeffery
  5888.  
  5889. From uunet!hsi!mlfarm!ron  Sun Oct 29 17:06:33 1989
  5890. Received: by megaron.arizona.edu (5.59-1.7/15)
  5891.     id AA25935; Sun, 29 Oct 89 17:06:33 MST
  5892. Received: from hsi.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
  5893.     id AA00114; Sun, 29 Oct 89 18:06:55 -0500
  5894. Received: by hsi.HSI.COM (smail2.5)
  5895.     id AA14032; 29 Oct 89 17:06:30 EST (Sun)
  5896. Received: by mlfarm.uucp (smail2.5)
  5897.     id AA00374; 29 Oct 89 13:02:40 EST (Sun)
  5898. To: icon-group-sender@arizona.edu
  5899. Cc: icon-group@arizona.edu, icon-group-request@arizona.edu,
  5900.         icon-group-errors@arizona.edu
  5901. Subject: address change
  5902. Message-Id: <8910291302.AA00374@mlfarm.uucp>
  5903. Date: 29 Oct 89 13:02:40 EST (Sun)
  5904. From: uunet!mlfarm!ron (Ronald Florence)
  5905.  
  5906. I would appreciate very much if you could change my address on the
  5907. various mailing lists to
  5908.  
  5909.     ron@mlfarm.uucp 
  5910.  
  5911. as the routing via aati is no longer reliable.  Thanks.
  5912.  
  5913. Ronald Florence            ...{hsi,rayssd}!mlfarm!ron
  5914.  
  5915. From EM302723@VMTECMEX.BITNET  Mon Oct 30 10:10:57 1989
  5916. Message-Id: <8910301710.AA10982@megaron>
  5917. Received: from rvax.ccit.arizona.edu by megaron (5.59-1.7/15) via SMTP
  5918.     id AA10982; Mon, 30 Oct 89 10:10:57 MST
  5919. Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Mon, 30 Oct 89 10:12
  5920.  MST
  5921. Received: by VMTECMEX (Mailer R2.04) id 3009; Mon, 30 Oct 89 09:26:55 MEX
  5922. Date: Mon, 30 Oct 89 09:24:15 MEX
  5923. From: "Dr. Mangagoras" <EM302723@VMTECMEX.BITNET>
  5924. Subject: Discussion logs?
  5925. To: icon-group@arizona.edu
  5926.  
  5927. Hi,
  5928. I was wondering, is there a log of the most recent posts to the newsgroup? I
  5929. have FTP'ed all logs from GROUP83.TXT to GROUP89A.TXT, but I'm interested in
  5930. the more recent posts (after GROUP89A). This is because the @$@"$|"@$ operators
  5931. in our installation sometimes purge the reader before we can read the mail, so
  5932. I'd like to check whether I've got all posts.
  5933.  
  5934. Thanx,
  5935. +----------------------------------+------------------------------+
  5936. |  Dr. Mangagoras                  | Mario Camou Riveroll         |
  5937. |  EM302723@VMTECMEX.BITNET        | Apdo. Postal 41554           |
  5938. |                                  | Mexico, D.F. 11001 Mexico    |
  5939. +----------------------------------+------------------------------+
  5940. | Don't take life too seriously - it's just a temporary situation |
  5941. +-----------------------------------------------------------------+
  5942.  
  5943. From ralph  Mon Oct 30 10:37:32 1989
  5944. Date: Mon, 30 Oct 89 10:37:32 MST
  5945. From: "Ralph Griswold" <ralph>
  5946. Message-Id: <8910301737.AA12538@megaron.arizona.edu>
  5947. Received: by megaron.arizona.edu (5.59-1.7/15)
  5948.     id AA12538; Mon, 30 Oct 89 10:37:32 MST
  5949. To: EM302723@VMTECMEX.BITNET, icon-group@arizona.edu
  5950. Subject: Re:  Discussion logs?
  5951. In-Reply-To: <8910301710.AA10982@megaron>
  5952.  
  5953. We collect icon-group mail and put it out on out FTP and RBBS areas
  5954. periodically.  Recent material is not available (yet).
  5955.  
  5956.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  5957.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  5958.  
  5959.  
  5960. From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS  Tue Oct 31 02:02:06 1989
  5961. Received: from shadooby.cc.umich.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5962.     id AA14292; Tue, 31 Oct 89 02:02:06 MST
  5963. Received: from ummts.cc.umich.edu by shadooby.cc.umich.edu (5.61/gossip-1.1)
  5964.     id AA03900; Tue, 31 Oct 89 04:01:12 -0500
  5965. Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Tue, 31 Oct 89 04:01:53 EST
  5966. Date: Mon, 30 Oct 89 23:11:46 EST
  5967. From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu
  5968. To: icon-group@arizona.edu
  5969. Message-Id: <177711@Wayne-MTS>
  5970. Subject: Redirecting error output from icont
  5971.  
  5972. I tried the following way of redirecting error output from the translator:
  5973.    icont -e pgm.err pgm
  5974. The error output appeared on the standard output file anyway.  This was
  5975. with version 7.5 under MS-DOS. 
  5976.  
  5977. Can it be done?  If so, how?
  5978.  
  5979. Paul Abrahams (abrahams%wayne-mts@um.cc.umich.edu)
  5980.  
  5981. From ralph  Tue Oct 31 06:41:40 1989
  5982. Date: Tue, 31 Oct 89 06:41:40 MST
  5983. From: "Ralph Griswold" <ralph>
  5984. Message-Id: <8910311341.AA27751@megaron.arizona.edu>
  5985. Received: by megaron.arizona.edu (5.59-1.7/15)
  5986.     id AA27751; Tue, 31 Oct 89 06:41:40 MST
  5987. To: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu, icon-group@arizona.edu
  5988. Subject: Re:  Redirecting error output from icont
  5989.  
  5990. The -e option to redirect error output only applies to iconx.  Sorry.
  5991.  
  5992.   Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721
  5993.   +1 602 621 6609   ralph@Arizona.EDU  uunet!arizona!ralph
  5994.  
  5995.  
  5996. From goer@sophist.uchicago.edu  Fri Nov  3 14:21:00 1989
  5997. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  5998.     id AA05519; Fri, 3 Nov 89 14:21:00 MST
  5999. Received: from sophist.uchicago.edu by tank.uchicago.edu Fri, 3 Nov 89 15:21:06 CST
  6000. Return-Path: <goer@sophist.uchicago.edu>
  6001. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  6002.     id AA15615; Fri, 3 Nov 89 15:18:40 CST
  6003. Date: Fri, 3 Nov 89 15:18:40 CST
  6004. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  6005. Message-Id: <8911032118.AA15615@sophist.uchicago.edu>
  6006. To: icon-group@cs.arizona.edu
  6007. Subject: frivolous child's game
  6008.  
  6009. I used the following program to teach my son to count.  It's extremely
  6010. simple, but effective enough to encourage a child who knows how to get
  6011. from 1-10 to take it to 100 or 1000.  It runs on any terminal that can
  6012. accept ANSI color sequences.  Mono monitors will work, but gee whiz.
  6013. Please don't ask why I didn't comment some of the more cryptic sections.
  6014. It was just a Saturday afternoon hack for my kid.  Maybe yours will like
  6015. it too.
  6016.  
  6017. procedure main(a)
  6018.  
  6019.   x := integer(\a[1]) | 1
  6020.   s := ""
  6021.   writes("\e[2J\e[6;1H")
  6022.  
  6023.   every s ||:= string(x) | (" " || |(x +:= 1)) do {
  6024.     (x % ([3,7,11][?4])) = 0 & goodjob()
  6025.       repeat {
  6026.       writes("\n\nWhat's next?\n")
  6027.       outstr := ""
  6028.       every outstr ||:= (format(s) || " \n")
  6029.       writes(trim(outstr,'\n'))
  6030.       if (x + 1) = integer(n := read())
  6031.       then break
  6032.       else {
  6033.         (any("Q"|"q",n) & stop("\e[0m\e[2J"))
  6034.         write("\nNO.  TRY AGAIN.\x07\x07")
  6035.         }
  6036.       }
  6037.     }
  6038.  
  6039. end
  6040.  
  6041.  
  6042. procedure format(s)
  6043.   (s || " ") ? {
  6044.     while (nextline := lines(s))[-1] == " " do {
  6045.       nextline ?:= trim((tab(many(' ')) | &null, tab(0)))
  6046.       suspend nextline
  6047.       }
  6048.     }
  6049. end
  6050.  
  6051.  
  6052. procedure lines(s)
  6053.   suspend &subject[.&pos:&pos <- (&pos+31 to &pos+39) | 0]
  6054. end
  6055.  
  6056.  
  6057. procedure goodjob()
  6058.   writes("\e[2J")
  6059.   every 1 to ((25 * ?6) + 10) do {
  6060. #   T := &time; until &time > (T+3)
  6061.     every i := 1 to 100 + ?5
  6062.     write("\e[",?24,";",?71,"H\e[",29+?17,";",29+?17,"mGOOD JOB!\e[0m")
  6063.     }
  6064.   T := &time; until &time > (T+1000)
  6065.   write("\e[2J\e[8;1H\e[0m                              \e[",
  6066.         37,";",43,"mYOU DID VERY GOOD!!\e[0m")
  6067.   T := &time; until &time > (T+2000)
  6068.   writes("\e[",i := (29+?7),";",(i + 10) ~= (39+|?7),"m")
  6069.   writes("\e[2J\e[8;1H")
  6070.   return
  6071. end
  6072.  
  6073.  
  6074.                                         -Richard L. Goerwitz
  6075.                                         goer@sophist.uchicago.edu
  6076.                                         goer%sophist@uchicago.bitnet
  6077.                                         rutgers!oddjob!gide!sophist!goer
  6078.  
  6079. From goer@sophist.uchicago.edu  Fri Nov  3 19:44:22 1989
  6080. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6081.     id AA17603; Fri, 3 Nov 89 19:44:22 MST
  6082. Received: from sophist.uchicago.edu by tank.uchicago.edu Fri, 3 Nov 89 20:44:34 CST
  6083. Return-Path: <goer@sophist.uchicago.edu>
  6084. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  6085.     id AA16069; Fri, 3 Nov 89 20:42:07 CST
  6086. Date: Fri, 3 Nov 89 20:42:07 CST
  6087. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  6088. Message-Id: <8911040242.AA16069@sophist.uchicago.edu>
  6089. To: icon-group@cs.arizona.edu
  6090. Subject: more frivolity
  6091.  
  6092. This is another game I wrote for my son one day when he was
  6093. being naughty, and we were having a bad time.  I hope some-
  6094. one else finds programming in icon interesting enough to
  6095. stray into corners like this (assumes an ANSI terminal that
  6096. accepts color commands).  If the field names seem in poor
  6097. tast, remember that just about everything is in poor taste
  6098. when a three year-old and his dad are hanging around the
  6099. house:
  6100.  
  6101. record wholething(poop,body)
  6102. procedure main(a)
  6103.  
  6104.   static snake, limit
  6105.   repeat {
  6106.     snake := list(25); snake[1] := [?25, ?80]
  6107.     every x := 2 to 25 do snake[x] := findnext(snake[x-1])
  6108.     limit := (\a[1] | 2000)
  6109.     every i := 1 to limit do {
  6110.       r := makenew(snake)
  6111.       leftbehind := r.poop
  6112.       snake := r.body
  6113.       display(leftbehind,snake)
  6114.       }
  6115.     every leftbehind := !snake
  6116.     do display(leftbehind)
  6117.     }
  6118.  
  6119. end 
  6120.  
  6121.  
  6122. procedure findnext(l)
  6123.   i := l[1]; j := l[2]
  6124.   (k := 26 > [i,i+1,i-1][|?3]) > 0 &
  6125.   (l := 81 > [j,j+1,j-1][|?3]) > 0 &
  6126.   not (k = 25, l = 80)
  6127.   return [k, l]
  6128. end
  6129.  
  6130.  
  6131. procedure different(l,snake)
  6132.   (l[1] = (bit := !\snake)[1], l[2] = bit[2]) & fail
  6133.   return
  6134. end
  6135.  
  6136.  
  6137. procedure display(lb,snake)
  6138.   static i,j,k
  6139.   initial {
  6140.     # kinda have to fool with my implementation to get somewhat
  6141.     # random numbers
  6142.     T := &time; while color := |?3 do &time > T + 90 & break
  6143.     case color of {
  6144.       1 : { i := "37"; j := "41"; k := "40" }
  6145.       2 : { i := "31"; j := "44"; k := "40" }
  6146.       3 : { i := "32"; j := "47"; k := "40" }
  6147.       }
  6148.     writes("\e[",i,";",j,"m")
  6149.     writes("\e[2J")
  6150.     }
  6151.   if different(lb,snake)
  6152.   then writes("\e[",lb[1],";",lb[2],"H\e[",k,"m ")
  6153.   writes("\e[",i,";",j,"m")
  6154.   writes("\e[",snake[*\snake][1],";",snake[*snake][2],"H\xDB")
  6155.   return
  6156. end
  6157.  
  6158.  
  6159. procedure makenew(snake)
  6160.   leftbehind := snake[1]
  6161.   every i := 1 to *snake - 1
  6162.   do snake[i] := snake[i+1]
  6163.   snake[*snake] := findnext(snake[*snake-1])
  6164.   return wholething(leftbehind,snake)
  6165. end
  6166.  
  6167. From @s.ms.uky.edu:mtbb95@ms.uky.edu  Sun Nov  5 18:56:32 1989
  6168. Received: from e.ms.uky.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6169.     id AA12427; Sun, 5 Nov 89 18:56:32 MST
  6170. Received: from s.ms.uky.edu by g.ms.uky.edu id aa01196; 5 Nov 89 20:53 EST
  6171. From: Bob Maras <mtbb95@ms.uky.edu>
  6172. Date: Sun, 5 Nov 89 20:53:32 EST
  6173. X-Mailer: Mail User's Shell (6.4 2/14/89)
  6174. To: Richard Goerwitz <goer@sophist.uchicago.edu>, icon-group@cs.arizona.edu
  6175. Subject: Re: more frivolity
  6176. Message-Id:  <8911052053.aa13668@s.s.ms.uky.edu>
  6177.  
  6178. Richard,
  6179.      As a teacher for 20 years and a parent of two elementary school students,
  6180. I really appreciate your recent postings re: applicable software in icon.  
  6181.  
  6182.      Bob
  6183.  
  6184. -- 
  6185.                           _      _
  6186.                          ( ) __ ( )
  6187.                           | O  O |         B O B   M A R A S
  6188.                           /  __  \      /
  6189.                          (   \/   )  __/
  6190.                           \ \__/ / 
  6191.                            \____/ 
  6192.                            |_/\_|     H A P P Y    C O M P U T I N G    !!!
  6193.         
  6194.  
  6195. From R.J.Hare@EDINBURGH.AC.UK  Wed Nov 15 05:21:45 1989
  6196. Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6197.     id AA07506; Wed, 15 Nov 89 05:21:45 MST
  6198. Received: from UKACRL.BITNET by rvax.ccit.arizona.edu; Wed, 15 Nov 89 05:23 MST
  6199. Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1519; Wed,
  6200.  15 Nov 89 09:05:16 GMT
  6201. Date: 15 Nov 89  09:03:40 gmt
  6202. From: R.J.Hare@EDINBURGH.AC.UK
  6203. Subject: Icon Mailer
  6204. To: icon-group@arizona.edu
  6205. Via:        UK.AC.ED.EMAS-A; 15 NOV 89  9:04:09 GMT
  6206. Message-Id: <15 Nov 89  09:03:40 gmt  340955@EMAS-A>
  6207.  
  6208. This is by way of being a begging letter...
  6209.  
  6210. I currently do the newsletter mailshot for a couple of small clubs I am a
  6211. member of, and will shortly want to pass this job onto someone else. This will
  6212. necessitate the transfer of the job from one (non-Icon) machine to another
  6213. (Icon) machine. My current mailshot program is *not* portable, so I want an
  6214. Icon mailshot program.
  6215.  
  6216. To save me writing one from scratch, does anyone out there have a (simple)
  6217. mailshot program they would be prepared to gift to me for the above purpose?
  6218.  
  6219. Thanks.
  6220. @
  6221. Roger Hare.
  6222.  
  6223. From goer@sophist.uchicago.edu  Thu Nov 16 11:36:52 1989
  6224. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6225.     id AA26958; Thu, 16 Nov 89 11:36:52 MST
  6226. Received: from sophist.uchicago.edu by tank.uchicago.edu Thu, 16 Nov 89 12:36:42 CST
  6227. Return-Path: <goer@sophist.uchicago.edu>
  6228. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  6229.     id AA08318; Thu, 16 Nov 89 12:33:54 CST
  6230. Date: Thu, 16 Nov 89 12:33:54 CST
  6231. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  6232. Message-Id: <8911161833.AA08318@sophist.uchicago.edu>
  6233. To: icon-group@arizona.edu
  6234. Subject: frivolity once again
  6235.  
  6236.  
  6237. It's not as if I only write games for my son, though the code I
  6238. post here seems inevitably to tend in that direction.  Normally
  6239. I use icon to help me reconstruct the phonology of dead langu-
  6240. ages by comparing computational models of various phonological
  6241. processes against known texts to see if they conform to all the
  6242. known evidence.  If anyone else is using Icon for natural langu-
  6243. age processing of this or any other type, I surely would like to
  6244. know about it!
  6245.  
  6246. But anyway, here's a kids' game.  Sorry it's IBM charset and ANSI
  6247. specific.  These are the tools I have around the house (Xenix on an
  6248. AT-type machine, to be specific):
  6249.  
  6250. global name_of_wordfile, termlength, timing
  6251. procedure main()
  6252.  
  6253.   name_of_wordfile := "/so/goer/words"
  6254.   termlength := 24
  6255.   timing := 60
  6256.  
  6257.   # Kind of a hangman game, built for my three year-old son to peel
  6258.   # him away from Wheel of Fortune (which he calls "the letter game").
  6259.   # Assumes an ANSI or similar terminal - one has a 256 char IBM set 
  6260.   # and accepts color commands.  Before running, create a file of words,
  6261.   # phrases, or sentences, and then assign name_of_wordfile to the name
  6262.   # of that file.  For 24-line terminals, assign termlength to 24.  If
  6263.   # things happen too slowly for you, try resetting the global variable
  6264.   # "timing" to 40 or 30.  Oh, by the way, the format of the wordfile
  6265.   # is one word or phrase to a line.  Couldn't be simpler.  Ask your
  6266.   # kid what words he or she likes, and the interest level will go up
  6267.   # several orders of magnitude.  Make sure the user has write permis-
  6268.   # sion on the wordfile.  To abort, type "quit."  To solve the puz-
  6269.   # zle, type in the entire word or phrase at the prompt.  To give up,
  6270.   # type "tell me."
  6271.  
  6272.   hitlst := list()
  6273.   until *(s := readword()) < 33
  6274.   writes("\e[30;44m\e[2J")
  6275.   every i := upto(~(&ucase++&lcase), s)
  6276.   do put(hitlst,s[i])
  6277.   writeboxes(s,hitlst)
  6278.   until *hitlst = *s do {
  6279.     hitlst := query(s,hitlst)
  6280.     writeboxes(s,hitlst)
  6281.     }
  6282.   T := &time; until &time > (T + timing*8)
  6283.   writes("\e[37;41m\e[2J")
  6284.   goodjob(); readword(1)
  6285.   stop("\e[",string(termlength - 1),";1H\e[37;40m")
  6286. end
  6287.  
  6288.  
  6289. procedure writeboxes(s,l)
  6290.  
  6291.   writes("\e[30;44m")
  6292.   writes("\e[9;11H\e[33m")
  6293.   every i := 1 to *s do {
  6294.     T := &time; until &time > (T + timing/2)
  6295.     if map(s[i]) == map(!\l)
  6296.     then {
  6297.       writes("\e[s\e[30m\xDB")
  6298.       T := &time; until &time > (T + timing/5)
  6299.       writes("\e[u\e[37m",s[i],"\e[30m")
  6300.       }
  6301.     else {
  6302.       writes("\e[s\e[30m\xDB")
  6303.       T := &time; until &time > (T + timing/5)
  6304.       writes("\e[u\e[33m\xDB\e[30m")
  6305.       }
  6306.     i ~= *s & writes(" ")
  6307.     }
  6308.   writes("\e[30;44m")
  6309.   return
  6310.  
  6311. end
  6312.  
  6313.  
  6314. procedure query(s,l)
  6315.  
  6316.   static tried
  6317.   initial tried := ""
  6318.   snew := map(s)
  6319.   repeat {
  6320.     ad := string(cset(tried))
  6321.     writes("\e[",string(termlength),";2HYou've tried:  \e[32m",ad,"\e[30m\e[K")
  6322.     sd := &lcase -- string(cset(ad))
  6323.     writes("\e[",string(termlength),";40HStill left:  \e[32m",sd,"\e[30m\e[K")
  6324.     writes("\e[11;11HGuess a letter:  \e[K\e[31m")
  6325.     guess := map(read())
  6326.     writes("\e[30m")
  6327.     if guess == "quit" then readword(1)
  6328.     if *guess ~= 1
  6329.     then {
  6330.       if guess == map(s) then {
  6331.         hitlst := []
  6332.         every put(hitlst,!s)
  6333.         return hitlst
  6334.         }
  6335.       if trim(guess,'.?!') == "tell me" then {
  6336.         hitlst := []; every put(hitlst,!s)
  6337.         writeboxes(s,hitlst)
  6338.         readword(1)
  6339.         }
  6340.       writes("\e[14;11HHas to be one letter, not ",*guess," letters!\e[K")
  6341.       T := &time; until &time > (T + timing*10)
  6342.       every j := 12 to (termlength - 1) do writes("\e[",j,";1H\e[K")
  6343.       writes("\e[14;1H\e[K")
  6344.       }
  6345.     else {
  6346.       if any(~(&ucase ++ &lcase),guess) then {
  6347.         writes("\e[14;11HHas to be a letter!\e[K")
  6348.         T := &time; until &time > (T + timing*7)
  6349.         writes("\e[14;1H\e[K")
  6350.         next
  6351.         }
  6352.       if find(guess,tried) then {
  6353.         writes("\e[14;11HYou already did that one!\e[K")
  6354.         T := &time; until &time > (T + timing*7)
  6355.         writes("\e[14;1H\e[K")
  6356.         next
  6357.         }
  6358.       tried ||:= guess
  6359.       if find(guess,snew)
  6360.       then {
  6361.         every find(guess,snew)
  6362.         do put(l,guess)
  6363.         break
  6364.         }
  6365.       else {
  6366.         writes("\e[14;11HSorry, try again!\e[K")
  6367.         T := &time; until &time > (T + timing*4)
  6368.         writes("\e[14;1H\e[K")
  6369.         }
  6370.       }
  6371.     }
  6372.   return l
  6373.  
  6374. end
  6375.  
  6376.  
  6377. procedure readword(c)
  6378.  
  6379.   static wordlist, count, position
  6380.   initial {
  6381.     wordlist := list(200,"")
  6382.     count := 0; position := 0
  6383.     intext := open(name_of_wordfile,"r") |
  6384.       stop("You first have to create a wordfile (see source).")
  6385.     every "" ~== trim(s := !intext)
  6386.     do wordlist[count +:= 1] := s
  6387.     close(intext)
  6388.     }
  6389.  
  6390.   if type(c) == "null"
  6391.   then {
  6392.     position := getpos(count,position)
  6393.     return wordlist[position]
  6394.     }
  6395.   else {
  6396.     outtext := open(name_of_wordfile,"w") | stop()
  6397.     every i := position + 1 to count
  6398.     do write(outtext,wordlist[i])
  6399.     every j := 1 to (position)
  6400.     do write(outtext,wordlist[j])       # if position = 0 it'll fail
  6401.     close(outtext)
  6402.     stop("\e[",string(termlength - 1),";1H\e[37;40m")
  6403.     }
  6404.  
  6405. end
  6406.  
  6407.  
  6408. procedure getpos(count,position)
  6409.   if count < (position +:= 1)
  6410.   then return 1
  6411.   else return position
  6412. end
  6413.  
  6414.  
  6415. procedure goodjob()
  6416.   writes("\e[2J")
  6417.   every 1 to ((50 * ?5) + 90) do {
  6418.     every i := 1 to 100 + ?5
  6419.     write("\e[",?24,";",?71,"H\e[",29+?17,";",29+?17,"mYOU WON!\e[0m")
  6420.     }
  6421.   return
  6422. end
  6423.  
  6424.  
  6425. From cjeffery  Fri Nov 17 14:45:31 1989
  6426. Received: from caslon.cs.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6427.     id AA05070; Fri, 17 Nov 89 14:45:31 MST
  6428. Date: Fri, 17 Nov 89 14:45:29 mst
  6429. From: "Clinton Jeffery" <cjeffery>
  6430. Message-Id: <8911172145.AA26671@caslon>
  6431. Received: by caslon; Fri, 17 Nov 89 14:45:29 mst
  6432. To: icon-group
  6433. Subject: Object Oriented Icon
  6434.  
  6435. A copy of Idol, an Icon-derived object language, is available by anonymous
  6436. ftp from cs.arizona.edu (or arizona.edu).
  6437.  
  6438. The distribution is in the icon subdirectory, and you can take your pick
  6439. of file formats: idol.arc, idol.zoo, idol.cpi, idol.tar, and idol.shr
  6440. (ARC, ZOO, CPIO, TAR, or SHAR format, respectively).
  6441.  
  6442. Idol is a preprocessor which provides Icon with classes and multiple
  6443. inheritance in the form of an augmented record data type. The current
  6444. version has not been tested on non-UNIX systems; feel free to add support
  6445. for your favorite system and email it to me.  Bug reports (and fixes!)
  6446. concerning Idol should be sent to cjeffery@cs.arizona.edu rather than the
  6447. Icon project.  I would appreciate feedback from anyone who uses Idol in
  6448. a substantial Icon application.
  6449.  
  6450. Clint Jeffery
  6451.  
  6452. From dscargo@cim-vax.honeywell.com  Mon Nov 20 09:30:53 1989
  6453. Message-Id: <8911201630.AA01326@megaron.arizona.edu>
  6454. Received: from cim-vax.Honeywell.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6455.     id AA01326; Mon, 20 Nov 89 09:30:53 MST
  6456. Date: 17 Nov 89 16:53:00 CST
  6457. From: "DAVE CARGO" <dscargo@cim-vax.honeywell.com>
  6458. Subject: reverse match
  6459. To: "icon-group" <icon-group@arizona.edu>
  6460.  
  6461. I found myself writing a application where I wanted to make a decision
  6462. based on characters at the END of a string.  I wanted something like match
  6463. but working from the end rather than the beginning of the string.  What I
  6464. chose by way of implementation was the following:
  6465.  
  6466. nekot := reverse(token)
  6467. if match("." | ")." | "\"." | ")\".", nekot) ...
  6468.  
  6469. I have two questions.  In general is there a better way to do this?  The
  6470. strings I wanted to test for are different sizes so a fixed range didn't work.
  6471. Second, could I have used
  6472.  
  6473. if match("." | ")." | "\"." | ")\".", reverse(token))
  6474.  
  6475. directly without having the reverse(...) evaluated multiple times?  (An
  6476. admittedly lazy question on my part, since I could have tested this.)
  6477.  
  6478. David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM)
  6479.  
  6480.  
  6481. From goer@sophist.uchicago.edu  Mon Nov 20 18:00:41 1989
  6482. Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6483.     id AA07924; Mon, 20 Nov 89 18:00:41 MST
  6484. Received: from sophist.uchicago.edu by tank.uchicago.edu Mon, 20 Nov 89 19:00:48 CST
  6485. Return-Path: <goer@sophist.uchicago.edu>
  6486. Received:  by sophist.uchicago.edu (3.2/UofC3.0)
  6487.     id AA14426; Mon, 20 Nov 89 18:57:56 CST
  6488. Date: Mon, 20 Nov 89 18:57:56 CST
  6489. From: Richard Goerwitz <goer@sophist.uchicago.edu>
  6490. Message-Id: <8911210057.AA14426@sophist.uchicago.edu>
  6491. To: icon-group@arizona.edu
  6492. Subject: reverse, ends of sentences
  6493.  
  6494. It looks to me as though you were trying to determine whether a given
  6495. string ends in a sequence normally associated with sentence-closure.
  6496. The best way to do this depends on the context in which you are pro-
  6497. gramming.  Are you, say, looking for an accurate sentence count in a
  6498. document?  If so, you will doutless want to use string scanning.  If
  6499. not, then a simple procedure like IsSentence might be invoked (its
  6500. main virtue is clarity, not speed):
  6501.  
  6502. procedure main()
  6503.   while line := !&input do {
  6504.     if IsSentenceEnd(line)
  6505.     then write("yes")
  6506.     else write("no")
  6507.     }
  6508. end
  6509. procedure IsSentenceEnd(str)
  6510.   punctuation := '\'"()[]?!.'
  6511.   shortstr := trim(str,punctuation)
  6512.   if upto('?!.',str,*shortstr+1)
  6513.   then return
  6514. end
  6515.  
  6516. In the context of string scanning, it is hard to use the reverse function.
  6517. Besides, I find that it tends to obfuscate code I write.  This might not
  6518. be true for you, but I find I have to think too hard about strings that
  6519. have been bent around backwards, especially when used for string scanning.
  6520. If you are processing whole texts, something like the following, though not ef-
  6521. ficient, will do nicely (if you are interested in efficiency, use C :-).
  6522. There are many things one could to to speed up the code, such as tabbing
  6523. provisionally up to periods, question marks, exclamations points.  Still
  6524. you get the point, I'm sure -
  6525.  
  6526. procedure main()
  6527.   count := 0; extrabit := ""
  6528.   while line := !&input do {
  6529.     if line == "" ~== extrabit then {
  6530.       write(string(count+:=1),":  ",extrabit)
  6531.       extrabit := ""
  6532.       next
  6533.       }
  6534.     else line := extrabit || line
  6535.     line ? {
  6536.       while sentence := TabSentence()
  6537.       do write(string(count+:=1),":  ",sentence)
  6538.       extrabit := tab(0)
  6539.       if extrabit[-1] ~== "-"
  6540.       then extrabit ||:= " "
  6541.       }
  6542.     }
  6543. end
  6544.  
  6545. procedure TabSentence()
  6546.   return {
  6547.     End2Front() ||
  6548.     tab(upto('!.?')+1) ||
  6549.     (tab(many('\'"()[]')) | &null, "") ||
  6550.     ((pos(0), "") | ="  ")
  6551.     }
  6552. end
  6553.  
  6554. procedure End2Front()
  6555.   suspend &subject[.&pos:&pos <- *&subject+1 to &pos by -1]
  6556. end
  6557.  
  6558. From icon-group-request@arizona.edu  Sun Nov 26 14:04:41 1989
  6559. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6560.     id AA12515; Sun, 26 Nov 89 14:04:41 MST
  6561. Received: by ucbvax.Berkeley.EDU (5.61/1.39)
  6562.     id AA18099; Sun, 26 Nov 89 12:56:42 -0800
  6563. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  6564.     for icon-group@arizona.edu (icon-group@arizona.edu)
  6565.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  6566. Date: 26 Nov 89 19:22:55 GMT
  6567. From: mcsun!ukc!sys.uea!superman@uunet.uu.net  (System Admin)
  6568. Organization: Democracy & Freedom
  6569. Subject: help
  6570. Message-Id: <876@sys.uea.ac.uk>
  6571. Sender: icon-group-request@arizona.edu
  6572. To: icon-group@arizona.edu
  6573.  
  6574. Appeal for all hackers and student organizations in world.
  6575. Please, give morality help and solidarity
  6576. for Czechoslovak students.
  6577. Regards, Friendly hacker. (anon)
  6578.  
  6579. From icon-group-request@arizona.edu  Mon Nov 27 10:36:50 1989
  6580. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6581.     id AA22868; Mon, 27 Nov 89 10:36:50 MST
  6582. Received: by ucbvax.Berkeley.EDU (5.61/1.39)
  6583.     id AA22641; Mon, 27 Nov 89 09:21:28 -0800
  6584. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  6585.     for icon-group@arizona.edu (icon-group@arizona.edu)
  6586.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  6587. Date: 27 Nov 89 15:29:48 GMT
  6588. From: esquire!yost@nyu.edu  (David A. Yost)
  6589. Organization: DP&W, New York, NY
  6590. Subject: Re: a < b < c
  6591. Message-Id: <1616@esquire.UUCP>
  6592. References: <192@eiffel.UUCP>,, <182@enea.se>,, <16655@ultima.cs.uts.oz>
  6593. Sender: icon-group-request@arizona.edu
  6594. To: icon-group@arizona.edu
  6595.  
  6596. In article <16655@ultima.cs.uts.oz> potter@ultima.cs.uts.oz (John Potter) writes:
  6597. >
  6598. > From article <192@eiffel.UUCP>, by bertrand@eiffel.UUCP (Bertrand
  6599. >                                                          Meyer):
  6600. >  >From article <182@enea.se>, sommar@enea.se (Erland Sommarskog):
  6601. >>   
  6602. >> > [...] The rule for a relational expression should be something like:
  6603. >> >     Rel_exp ::= Expression (Rel_op Expression)*
  6604. >> > [...] The semantic interpretation would be than of a logical AND so
  6605. >> that:
  6606. >> >      a < b <= c > a + 2
  6607. >> > would be a shorthand for
  6608. >> >      a < b AND b <= c AND c > a + 2
  6609. >> > [...] Since Eiffel still is open for changes for some more time,
  6610. >> > why not take the chance and add it? Not an essential thing,
  6611. >> > but one of those little things that makes life easier. Or
  6612. >> > is there some problem I have overlooked?
  6613. >> 
  6614. >>       I have tried to find an argument for not following
  6615. >>       Mr. Sommarskog's suggestion and I cannot think of one.
  6616. >>       As a matter of fact, many assertions in the basic Data Structure
  6617. >>       Library and elsewhere would be written more simply in this way.
  6618. >> 
  6619. >>       It may be that the reason why no mainstream language has
  6620. >>       included the form suggested by Mr. Sommarskog is that people feared
  6621. >>       ambiguity.
  6622. >>       But the simple semantics he suggests (``and'') makes any such fear
  6623. >>       unfounded.
  6624. >
  6625. >I've just got around to reading these articles and their followups.
  6626. >
  6627. >It may be of passing interest to note that the language Miranda allows
  6628. >precisely this form of relational expression. Miranda is a functional
  6629. >language with non-strict semantics (i.e. uses lazy evaluation).
  6630. >The semantic interpretation of
  6631. >        a < b <= c > a + 2
  6632. >would be akin to the Eiffel form
  6633. >        a < b and then b <= c and then c > a + 2
  6634. >The "then" corresponds to the non-strict semantics in Miranda.
  6635.  
  6636. OK, I guess it's time someone said that the
  6637. Icon programming language (available free
  6638. from icon-project@arizona.edu, but please
  6639. give them a few bucks) can do this, plus Icon
  6640. expressions yield more information.  In most
  6641. languages you could divide the world of
  6642. expression values into two types: boolean
  6643. (used for control structures) and non-
  6644. boolean.  In Icon, by contrast, every
  6645. expression acts as both.  Every expression
  6646. either "succeeds" or "fails", giving you your
  6647. true/false indication, if you want to use it,
  6648. and, if the expression succeeds, it has a
  6649. (non-boolean) value, if you want to use it.
  6650. When any subexpression fails, expression
  6651. evaluation stops, and the entire expression
  6652. fails.  And everything is an expression in
  6653. Icon; there are no statements.
  6654.  
  6655. If a relational expression succeeds, it takes
  6656. the value of the right side.  So, the
  6657. expression
  6658.  
  6659.     (a < b) + 1 < c
  6660.  
  6661. evaluates like this
  6662.  
  6663.      a   b   c   expression
  6664.     --- --- --- -----------------
  6665.      2   1   3   no value - fails because a < b fails
  6666.      1   2   3   no value - fails because b + 1 < c fails
  6667.      1   2   4   c
  6668.  
  6669. This succeed/fail property of Icon
  6670. expressions is nice to use in practice.
  6671. Yet there is more still: if an expression
  6672. succeeds, it can be resumed, at which point
  6673. it can yield another value or fail.  Thus,
  6674. you will see many forms of multi-valued
  6675. "generator" expressions.  You can use each
  6676. value in turn or just the first value, if you
  6677. like.  For instance, the expression
  6678.  
  6679.     1 to 3
  6680.  
  6681. which yields 1, then 2, then 3, ... then
  6682. fails.  There are various control structures
  6683. that make it easy to take advantage of the
  6684. multiple values that expressions can
  6685. generate, such as
  6686.  
  6687.     every expression [ do expression ]
  6688.  
  6689.     while expression [ do expression ]
  6690.  
  6691. For example,
  6692.  
  6693.     every x := 1 to 3 do write (x)
  6694.  
  6695. Of course, Icon subroutines either succeed
  6696. or fail, and can be written to generate
  6697. additional values when resumed.
  6698.  
  6699. Icon is neat.  My ideal language would be
  6700. an Icon-ish Eiffel, that is, for example,
  6701. everything a succeed/fail multi-valued
  6702. expression instead of some things
  6703. statements and some things expressions,
  6704. {} syntax instead of keywords, semicolons
  6705. optional, and icon-like lists in the
  6706. library.
  6707.  
  6708.  --dave yost
  6709.  
  6710. From icon-group-request@arizona.edu  Mon Nov 27 14:04:47 1989
  6711. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6712.     id AA11460; Mon, 27 Nov 89 14:04:47 MST
  6713. Received: by ucbvax.Berkeley.EDU (5.61/1.39)
  6714.     id AA06817; Mon, 27 Nov 89 12:57:43 -0800
  6715. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  6716.     for icon-group@arizona.edu (icon-group@arizona.edu)
  6717.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  6718. Date: 27 Nov 89 20:34:51 GMT
  6719. From: mist!budd@cs.orst.edu  (Tim Budd)
  6720. Organization: Oregon State Univ. -- Computer Science
  6721. Subject: Re: a < b < c
  6722. Message-Id: <13990@orstcs.CS.ORST.EDU>
  6723. References: <182@enea.se>, <16655@ultima.cs.uts.oz>, <1616@esquire.UUCP>
  6724. Sender: icon-group-request@arizona.edu
  6725. To: icon-group@arizona.edu
  6726.  
  6727. I'm developing a new programming language called LEDA, which is designed to
  6728. be ``multiparadigm''.  That is, you can program in a logical (prolog
  6729. style), functional, object oriented or imparative style - or in any mix.
  6730. It provides generators similar (and largely taken from) Icon, as well as
  6731. many other features.
  6732.  
  6733. Several papers on LEDA are in various pipelines, but none has seen daylight
  6734. yet.  If you want to see various technical reports let me know and I can
  6735. send them.
  6736. --tim budd  (budd@cs.orst.edu)
  6737.  
  6738. From tenaglia@fps.mcw.edu  Mon Nov 27 14:46:10 1989
  6739. Received: from RUTGERS.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6740.     id AA14407; Mon, 27 Nov 89 14:46:10 MST
  6741. Received: from uwm.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP 
  6742.     id AA11592; Mon, 27 Nov 89 16:45:44 EST
  6743. Received: by uwm.edu; id AA22193; Mon, 27 Nov 89 15:29:08 -0600
  6744. Message-Id: <8911272129.AA22193@uwm.edu>
  6745. Received: from mis by fps.mcw.edu (DECUS UUCP w/Smail);
  6746.           Mon, 27 Nov 89 14:40:18 CDT
  6747. Received: by mis.mcw.edu (DECUS UUCP w/Smail);
  6748.           Mon, 27 Nov 89 13:06:40 CDT
  6749. Date: Mon, 27 Nov 89 13:06:40 CDT
  6750. From: Chris Tenaglia - 257-8765 <tenaglia@mis.mcw.edu>
  6751. To: icon-group@arizona.edu
  6752. Subject: Handy Dandy List Cooker
  6753.  
  6754. Dear Icon-Group,                      
  6755.  
  6756. Here is another very useful procedure. I call it cook. It takes a list
  6757. of strings (filenames, usernames, etc,...) and converts them into a list
  6758. of output lines. It currently assumes that the list is sorted.
  6759.  
  6760. One can output a list of strings usually by
  6761.  
  6762.     every writes(!elements," ")
  6763.  
  6764. where elements is a list of strings. But the format is typically like
  6765. the VMS DIR or DOS DIR/W command. Unix generates a vertically oriented
  6766. alphabetical list of filenames which is easier to look through. I submit
  6767. my attempt below. However, my code does not have much of the spirit of
  6768. icon to it, and many of you may have more elegant (and more efficient)
  6769. implementations. Please feel free to improve on it. Perhaps even a
  6770. different approach as a type of sorter? Have fun!
  6771.  
  6772. The prototype is - procedure cook(lst,cols,width)
  6773.     required  :    lst is the sorted list of strings to be formatted
  6774.     optional  :    cols is how many cols are desired (5 is default)
  6775.     optional  :    width is the output width (80 is default)
  6776.  
  6777. Yours truly,
  6778.  
  6779. Chris Tenaglia (System Manager)         tenaglia@mis.mcw.edu
  6780. Medical College of Wisconsin
  6781. 8701 W. Watertown Plank Rd.
  6782. Milwaukee, WI 53226
  6783. (414)257-8765
  6784.  
  6785. ======================================================================
  6786.  
  6787. ##################################################################
  6788. #                                                                #
  6789. # THIS PROCEDURE COOKS A LIST OF STRINGS SO THAT THE LIST COMES  #
  6790. # OUT IN UNIX LS FORMAT RATHER THAN VMS DIR FORMAT               #
  6791. #                                                                #
  6792. ##################################################################
  6793. procedure cook(lst,cols,width)
  6794.   local limit,size,array,meal,food,i,j,row,column
  6795.   /cols := 5                ; /width := 80
  6796.   items := *lst             ; size   := width / cols
  6797.   rows  := items / cols + 1 ; limit  := rows * cols
  6798.   array := table(" ")       ; meal   := []
  6799.   until *lst > limit do put(lst," ")            # push for reverse order
  6800.   every column := 1 to cols do
  6801.     every row  := 1 to rows do
  6802.       array[row||","||column] := pop(lst)       # pull for reverse order
  6803.   every row := 1 to rows do
  6804.     {
  6805.     food := ""
  6806.     every column  := 1 to cols do
  6807.       food ||:= left(array[row||","||column],size)
  6808.     put(meal,trim(food))
  6809.     }
  6810.   return meal
  6811.   end
  6812.  
  6813.  
  6814. From icon-group-request@arizona.edu  Tue Nov 28 20:05:30 1989
  6815. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6816.     id AA09536; Tue, 28 Nov 89 20:05:30 MST
  6817. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  6818.     id AA22872; Tue, 28 Nov 89 19:00:25 -0800
  6819. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  6820.     for icon-group@arizona.edu (icon-group@arizona.edu)
  6821.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  6822. Date: 28 Nov 89 22:16:04 GMT
  6823. From: ficc!peter@uunet.uu.net  (Peter da Silva)
  6824. Organization: Xenix Support, FICC
  6825. Subject: Re: a < b < c
  6826. Message-Id: <7138@ficc.uu.net>
  6827. References: <192@eiffel.UUCP>
  6828. Sender: icon-group-request@arizona.edu
  6829. To: icon-group@arizona.edu
  6830.  
  6831. I would like to note that this syntax has been used before. I implemented a
  6832. real-time control language that did this about 6 or 7 years ago. It's very
  6833. easy to implement, and the ambiguity does not produce much difficulty in
  6834. practice. I was skeptical at first, but now I'm a convert.
  6835.  
  6836. Too bad that project ended up getting canned due to overengineering. :-<
  6837. -- 
  6838. `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>.
  6839.  'U`  --------------  +1 713 274 5180.
  6840. "The basic notion underlying USENET is the flame."
  6841.     -- Chuq Von Rospach, chuq@Apple.COM 
  6842.  
  6843. From @mirsa.inria.fr:ol@cerisi.cerisi.Fr  Wed Nov 29 11:56:21 1989
  6844. Received: from mirsa.inria.fr by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6845.     id AA22015; Wed, 29 Nov 89 11:56:21 MST
  6846. Received: from cerisi.cerisi.fr by mirsa.inria.fr with SMTP
  6847.     (5.59++/IDA-1.2.8) id AA02956; Wed, 29 Nov 89 19:56:56 +0100
  6848. Message-Id: <8911291856.AA02956@mirsa.inria.fr>
  6849. Date: Wed, 29 Nov 89 19:48:01 -0100
  6850. Posted-Date: Wed, 29 Nov 89 19:48:01 -0100
  6851. From: Lecarme Olivier <ol@cerisi.cerisi.Fr>
  6852. To: budd%mist@cs.orst.edu
  6853. Cc: icon-group@arizona.edu
  6854. In-Reply-To: (Tim Budd's message of 27 Nov 89 20:34:51 GMT <13990@orstcs.CS.ORST.EDU>
  6855. Subject: a < b < c
  6856.  
  6857. I'm interested in ANY new programming language, and especially in any
  6858. programming language trying to take out some good ideas from Icon. Here
  6859. is my postal address:
  6860.  
  6861. Olivier LECARME
  6862. University of Nice
  6863. Parc Valrose
  6864. 06034 NICE cedex
  6865. FRANCE
  6866.  
  6867.  
  6868.  
  6869.                 Olivier Lecarme
  6870.  
  6871. From tenaglia@fps.mcw.edu  Thu Nov 30 14:24:13 1989
  6872. Received: from RUTGERS.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6873.     id AA22061; Thu, 30 Nov 89 14:24:13 MST
  6874. Received: from uwm.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP 
  6875.     id AA16946; Thu, 30 Nov 89 16:23:24 EST
  6876. Received: by uwm.edu; id AA28554; Thu, 30 Nov 89 13:56:48 -0600
  6877. Message-Id: <8911301956.AA28554@uwm.edu>
  6878. Received: from mis by fps.mcw.edu (DECUS UUCP w/Smail);
  6879.           Thu, 30 Nov 89 12:53:11 CDT
  6880. Received: by mis.mcw.edu (DECUS UUCP w/Smail);
  6881.           Thu, 30 Nov 89 12:49:57 CDT
  6882. Date: Thu, 30 Nov 89 12:49:57 CDT
  6883. From: Chris Tenaglia - 257-8765 <tenaglia@mis.mcw.edu>
  6884. To: icon-group@arizona.edu
  6885. Subject: Prompting String Input Procedure
  6886.  
  6887. Dear Icon-Group :
  6888.  
  6889. Here is a simple and handy procedure I use all over the place. It's
  6890. called input. I've used it in DOS, VMS, and UNIX. Although in unix
  6891. I've had to make it a little different in some cases.
  6892.  
  6893. Problem : Getting a screen inputted value takes 2 lines.
  6894.           writes("Enter Value>")
  6895.           value := read()
  6896.  
  6897. Solution: It would be nice to do it in one line.
  6898.           value := input("Enter Value>")
  6899.  
  6900. Method  : Input Procedure...
  6901.           procedure input(prompt)
  6902.             writes(prompt)
  6903.             return read()
  6904.             end
  6905.  
  6906. Example : Main procedure parameters.
  6907.           This example also makes nice use of what I call the
  6908.           'either or' construct (alternation).
  6909.  
  6910.           procedure main(files)
  6911.           source := (files[1] | input("Source File:") | stop("Cancelled"))
  6912.           target := (files[2] | input("Target File:") | stop("Cancelled"))
  6913.  
  6914. VMS     : The procedure will fail if CTRL_Z is pressed. This adds a little
  6915. &         of the failure driven stuff.
  6916. DOS
  6917.  
  6918. UNIX    : However, under unix, CTRL_Z stops the process. And pressing CTRL_D
  6919.           seems to cause a failure avalanch. In one application I ended up
  6920.           defining . as the failure string. The procedure looks like ...
  6921.           procedure input(prompt)
  6922.             local temp
  6923.             writes(prompt)
  6924.             temp := read()
  6925.             if temp ~== "." then return temp else fail
  6926.             end
  6927.  
  6928. Conclusion : I hope some of you out there may find this helpful/useful.
  6929.              Perhaps there is room for improvement, especially in the
  6930.              UNIX example. Perhaps instead of a single string, it can
  6931.              truly dynamic (like write()). Enjoy !
  6932.  
  6933. Chris Tenaglia (System Manager)
  6934. Medical College of Wisconsin
  6935. 8701 W. Watertown Plank Rd.
  6936. Milwaukee, WI 53226
  6937. (414)257-8765
  6938. tenaglia@mis.mcw.edu
  6939.  
  6940.  
  6941. From icon-group-request@arizona.edu  Sun Dec  3 16:36:47 1989
  6942. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6943.     id AA18635; Sun, 3 Dec 89 16:36:47 MST
  6944. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  6945.     id AA21093; Sun, 3 Dec 89 15:29:32 -0800
  6946. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  6947.     for icon-group@arizona.edu (icon-group@arizona.edu)
  6948.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  6949. Date: 3 Dec 89 21:55:11 GMT
  6950. From: clp@wjh12.harvard.edu  (Charles L. Perkins)
  6951. Organization: Harvard University, Cambridge MA
  6952. Subject: Does anyone have an implementation of the language "Self"?
  6953. Message-Id: <438@wjh12.harvard.edu>
  6954. Sender: icon-group-request@arizona.edu
  6955. To: icon-group@arizona.edu
  6956.  
  6957. (Sorry about the eclectic distribution, but I wanted "O-O People")
  6958.  
  6959. I am extremely interested in the new language Self that Dave Ungar & Co. are
  6960.  working on at Stanford.  They are currently rewriting their old version of
  6961.  the system to make it new and improved, but I would love to get any older
  6962.  version of the system that any of you may have lying around....
  6963.  
  6964. There was an early release in Smalltalk, and (I think) one later released
  6965.  with an optimizing compiler as a stand-alone system.  Any pointers, ideas,
  6966.  etc. about how and where to find old Selves appreciated.
  6967.  
  6968.                                 Charles L. Perkins
  6969.                               clp@wjh12.harvard.edu
  6970.  
  6971. From icon-group-request@arizona.edu  Tue Dec 12 10:44:20 1989
  6972. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  6973.     id AA13002; Tue, 12 Dec 89 10:44:20 MST
  6974. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  6975.     id AA29185; Tue, 12 Dec 89 09:35:29 -0800
  6976. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  6977.     for icon-group@arizona.edu (icon-group@arizona.edu)
  6978.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  6979. Date: 12 Dec 89 17:34:51 GMT
  6980. From: zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@tut.cis.ohio-state.edu  (Alan D Corre)
  6981. Organization: University of Wisconsin-Milwaukee
  6982. Subject: library procedures
  6983. Message-Id: <1453@uwm.edu>
  6984. Sender: icon-group-request@arizona.edu
  6985. To: icon-group@arizona.edu
  6986.  
  6987. Chris's useful little input() procedure is a good candidate for a library
  6988. module. Such modules are very easy to use in v.7 of Icon by compiling with
  6989. the -c switch and using the link declaration
  6990.  
  6991. This prompts me to publish a few useful procedures. The version here is for
  6992. the z-29 terminal, but you can modify it fairly easily. I also have a
  6993. version for the pc which I can post if someone wants it. I use ANSI mode on
  6994. the z-29 for a good reason. If you are in ANSI mode already, and you writes
  6995. the command to switch from ZENITH mode, it is simply ignored, so which ever
  6996. of the two modes you are in will be fine. Not so if you give the ANSI
  6997. command to switch to ZENITH mode and you are already in ZENITH! On my
  6998. installation the system hangs irretrievably, and if you already waited 20
  6999. minutes to get on that is pretty frustrating! I dont know why that occurs,
  7000. but my experience with computers indicates that if something blows up, dont
  7001. push the button again. Here is the documentation, followed by the code.
  7002.  
  7003. ****
  7004. Some of these procedures assume the use of a terminal in ANSI mode. If
  7005. your terminal is in Zenith mode, it will be switched to ANSI mode and
  7006. left in that mode. It can be returned to Zenith mode by the use of the
  7007. setup key.
  7008.  
  7009. procedure banner(s1,s2..sn)
  7010. Takes an arbitrary number of strings and places them in a display box on the
  7011. screen. Strings should be a maximum of 78 characters.
  7012.  
  7013. procedure instructions(filename)
  7014. Asks the user if instructions are desired. If so, opens the file "filename"
  7015. and reads it by screenfuls until ended or user wishes to stop. User is told
  7016. if file is unavailable.
  7017.  
  7018. procedure randomize()
  7019. Sets the random seed to a number determined by the clock time. The seed may
  7020. be reset to initial value by the statement
  7021. &random := 0
  7022.  
  7023. procedure clear()
  7024. Clears the screen and puts the cursor in the home position.
  7025.  
  7026. procedure gotoxy(l,r)
  7027. Sets the cursor at line l, row r.
  7028.  
  7029.  
  7030. ***
  7031. procedure banner(l[])
  7032. local n
  7033.   writes("\e<") #go into ansi mode
  7034.   writes("\e[10m") #graphics mode
  7035.   write();write();write()
  7036.   writes(char(102)) #top left right angle
  7037.   writes(repl(char(97),78)) #straight line
  7038.   writes(char(99)) #top right right angle
  7039.   writes(char(96)) #upright line at left
  7040.   writes(right(char(96),79)) #upright line at right
  7041.   every n := 1 to *l do {
  7042.     writes(char(96)) #upright line at left
  7043.     writes("\e[11m",center(l[n],78),"\e[10m",char(96)) #string centered followed by upright line, exit graphics mode for text
  7044.     writes(char(96)) #upright line at left
  7045.     writes(right(char(96),79)) #upright line at right
  7046. }
  7047.   writes(char(101)) #bottom left right angle
  7048.   writes(repl(char(97),78)) #straight line
  7049.   write(char(100)) #bottom right right angle
  7050.   write("\e[11m")
  7051.   write("Press return to continue.")
  7052.   read()
  7053. return
  7054. end
  7055.  
  7056.  
  7057. procedure instructions(filename)
  7058. local filvar,counter,line
  7059.   writes("Do you need instructions? y/n ")
  7060.   if upto('yY',read()) then {
  7061. #The following if-statement fails if the file is not available
  7062.   counter := 0
  7063.   if filvar := open(filename) then
  7064. #Read the help file. It's a good idea to keep this kind of info in a
  7065. #separate file because you can modify it easily without redoing the
  7066. #program. In general---keep data out of programs!
  7067.     while line := read(filvar) do {
  7068. #Write out a line and increment the counter
  7069.       write(line)
  7070.       counter +:= 1
  7071. #Now we have a screenful; ask if we should continue
  7072.       if counter >22 then {
  7073.         write()
  7074.         writes ("More? y/n ")
  7075. #User has had enough; break out of loop
  7076.         if upto('nN',read()) then break  else
  7077. #User wants more; reset counter and continue
  7078.           counter := 0}} else
  7079. #This else goes with the second if-statement; the attempt to open the
  7080. #help file failed:
  7081.       write("Sorry, instructions not available.")}
  7082.     write ("Press return to continue.")
  7083.     read()
  7084. #Close the file if it existed and was opened. If it was never opened
  7085. #the value of filvar will be null. This check has to be made because
  7086. #an attempt to use close() on a variable NOT valued at a file would
  7087. #cause an error. See Psalm 130.3
  7088. /filvar | close(filvar)
  7089. end
  7090.  
  7091. procedure randomize()
  7092. #extracts the seconds from  clock time, and uses the resulting number as seed
  7093. local clock
  7094.   clock := &clock
  7095.   clock[1:7] := ""
  7096.   &random := clock
  7097. end
  7098.  
  7099. procedure clear()
  7100. #clears the screen
  7101.   writes("\e<\e[2J")
  7102. end
  7103.  
  7104. procedure gotoxy(l,r)
  7105. #sets the cursor at line l, row r
  7106.   writes("\e<\e[",l,";",r,"H")
  7107. end
  7108. --
  7109. Alan D. Corre
  7110. Department of Hebrew Studies
  7111. University of Wisconsin-Milwaukee                     (414) 229-4245
  7112. PO Box 413, Milwaukee, WI 53201               corre@csd4.csd.uwm.edu
  7113.  
  7114. From icon-group-request@arizona.edu  Sat Dec 16 13:42:15 1989
  7115. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7116.     id AA14947; Sat, 16 Dec 89 13:42:15 MST
  7117. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  7118.     id AA14392; Sat, 16 Dec 89 12:33:26 -0800
  7119. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  7120.     for icon-group@arizona.edu (icon-group@arizona.edu)
  7121.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  7122. Date: 16 Dec 89 20:22:53 GMT
  7123. From: ns-mx!umaxc.weeg.uiowa.edu!amthor@uunet.uu.net  (Geoffrey Amthor)
  7124. Organization: U of Iowa, Iowa City, IA
  7125. Subject: WOULD *YOU* BUY A NeXT COMPUTER? (Read even if you wouldn't)
  7126. Message-Id: <317@ns-mx.uiowa.edu>
  7127. Sender: icon-group-request@arizona.edu
  7128. To: icon-group@arizona.edu
  7129.  
  7130. Hi.  As many of you know, former Apple co-founder Steve Jobs has founded
  7131. a new company that has produced an advanced personal computer/workstation
  7132. known as the NeXT computer.  This computer has been initially targeted at
  7133. the university community, with more recent expansion into the mainstream
  7134. business market.  I won't belabor you with the details, but the NeXT
  7135. computer is viewed as important because of its pioneering application
  7136. of new technology, an easy interface builder for programmers, and an
  7137. advanced bundling of both special hardware and software, making the
  7138. "lowest comon denominator" (to which most developers write applications)
  7139. rather high.  The machine is somewhat controversial, as some are
  7140. irritated that yet another standard has reached the marketplace, while
  7141. some others believe the NeXT promises more than it delivers.  On the
  7142. other hand, there is a growing group of NeXT fans who see it as THE
  7143. platform for the future.
  7144.  
  7145. Fans and flamers alike share one uncertainty, however: Will the NeXT
  7146. succeed in the marketplace?
  7147.  
  7148. I'm not in a position to answer that question, but I CAN tabulate what
  7149. USENET readers think of the NeXT, and summarize that information for
  7150. the net.
  7151.  
  7152. As a graduate student interested in buying a NeXT, I realize that
  7153. part of what holds me up is my ignorance of what *other* people think of
  7154. it.  My reasoning is this: if most other people aren't even close to
  7155. buying, the NeXT will fail; if others are held back by mere (fixable)
  7156. technicalities, the NeXT will likely succeed.
  7157.  
  7158. Even if you haven't heard of the NeXT, you can help me by at least saying
  7159. that.  Like any survey, this one will benefit from a high percentage of
  7160. returns--please vote!  Of course, since returns are voluntary and readers
  7161. are preselected by their subscription to USENET, results will be
  7162. unscientific.  But I am certain they will help me, and I WILL SUMMARIZE
  7163. TO THE NET so that everyone else's curiosity can be satisfied.
  7164.  
  7165. There are only 10 questions.  When multiple choice options are offered,
  7166. please select as many as apply--but IN ORDER OF PRIORITY.  Feel free to
  7167. add whatever comments you wish, but keep in mind that multiple choice
  7168. selections are easier to summarize.  Also, unless you indicate otherwise,
  7169. summaries to the net will be ANONYMOUS, so if you secretly love or hate
  7170. the NeXT, you needn't worry about the secret getting out.
  7171.  
  7172. PLEASE REPLY BY E-MAIL.  Postings will quickly dwarf the net, I may miss
  7173. your posting, and I will summarize to the net anyway.
  7174.  
  7175. Be assured that I have no affiliation whatsoever with NeXT or Businessland.
  7176. Though I am a graduate student at the University of Iowa, this survey
  7177. does not represent the interest of UI.
  7178.  
  7179. SURVEY:
  7180.  
  7181. 1. What is your occupation?
  7182.  
  7183. 2. What computer(s) do you presently own or use regularly?  What other
  7184. computer(s) do you have actual experience with?
  7185.  
  7186. 3. What contact have you had with the NeXT computer?
  7187.    A. Never heard of it
  7188.    B. Heard it talked about
  7189.    C. Have seen print ads (name publication)
  7190.    D. Have read articles about it (name publication)
  7191.    E. Have seen one in use or in demonstration (where?)
  7192.    F. Have tried it myself in demo (where?)
  7193.    G. Have used, or borrowed access to it, for some time
  7194.    H. Currently own it or have it provided for my own use
  7195.    I. Other (please specify)
  7196.  
  7197. 4. How interested are you in purchasing a present or future version of the
  7198.    NeXT, or having your department acquire one for your use?  (Specify
  7199.    purchase or department acquisition)
  7200.    A. Not even remotely interested, ever
  7201.    B. Haven't really though about it
  7202.    C. Wouldn't rule it out somday
  7203.    D. Would be interested *if* certain conditions were satisfied
  7204.    E. Would be *very* interested if certain conditions were satisfied
  7205.    F. Am literally ready to buy once certain conditions are met
  7206.    G. Am ready to buy right now
  7207.    H. Already own or have sufficient access to a NeXT
  7208.    I. Other (please specify)
  7209.  
  7210. 5. If you named conditions in (2), which of the following apply?  (Please
  7211.    name only those conditions that are *conditions*, not wish lists.)
  7212.    A. If I can find the money
  7213.    B. If the NeXT comes down in price (How much?  Off of university or
  7214.       Businessland prices?)
  7215.    C. If I can get a hands-on look/feel (demo? rent? 30-day guarantee?)
  7216.    D. If color arrives
  7217.    E. If the CPU is upgraded to a 68040 and/or graphics are sped up
  7218.    F. If the floptical drive is made faster
  7219.    G. If the floptical drive is doubled in capacity to 512 MB
  7220.    H. If laser printing can be handled more seamlessly
  7221.    I. If the NeXT can be better integrated with existing equipment
  7222.       (name existing equipment)
  7223.    J. If a 3-1/2" floppy disk drive is bundled
  7224.    K. If a supplemental operating system runs in emulation or via
  7225.       co-processor, or if another UNIX variant runs (name the OS or
  7226.       variant)
  7227.    L. If a certain software category is filled by a high-quality
  7228.       application (name category)
  7229.    M. If a certain software package or language (such as C++) is ported
  7230.       to the NeXT (name item)
  7231.    N. If NeXT applications in general reach a critical mass
  7232.    O. If the NeXTStep interface is improved (name improvement sought)
  7233.    P. If enough NeXTs are sold to make it a "safe" platform
  7234.    Q. If a laptop NeXT arrives
  7235.    R. If a multi-user NeXT arrives (1 cube, several full function inputs
  7236.       that could either be dedicated Megapixel displays or NeXTStep
  7237.       interfaces in non-NeXT boxes.  Indicate Megapixel or non-NeXT; if
  7238.       non-NeXT, specify the machine.)
  7239.    S. If IBM, which has licensed the NeXTStep interface, markets it
  7240.    T. If bugs are eliminated in the operating system
  7241.    U. If hardware reliability improves/is proven
  7242.    V. If distribution is widened to include my university (name university)
  7243.    W. If distribution is widened to more commercial vendors (suggest one)
  7244.    X. If my company/university/department endorses it (specify)
  7245.    Y. If customer support is improved (name support sought)
  7246.    Z. If.... (please specify)
  7247.  
  7248. 6. Which of the above possibilities are not absolute conditions for you,
  7249.    but would carry significant favorable weight in your decision?
  7250.  
  7251. 7. If you aren't seriously considering acquiring a NeXT in any incarnation,
  7252.    why not?
  7253.    A. Very happy with my own system (please specify)
  7254.    B. Don't have enough (or any) information about NeXT
  7255.    C. Already plan to buy another system (which system?)
  7256.    D. Price of NeXT is prohibitively high
  7257.    E. Don't think the NeXT will ever catch on
  7258.    F. Don't like the user/programmer interface (why not?)
  7259.    G. Require a different primary operating system or UNIX variant
  7260.       (specify OS or variant)
  7261.    H. Hardware is inadequate for needs (what is missing?)
  7262.    I. Have heard too many negative things about NeXT (such as?)
  7263.    J. Think the NeXT is "too much computer" for needs
  7264.    K. Buying a NeXT is politically impossible (why?)
  7265.    L. Other (please specify)
  7266.  
  7267. 8. Does the NeXT interest you enough that you want to find out more about it?
  7268.  
  7269. 9. As a computer user, what percent of your interest or time is devoted to
  7270.    end-user computing?  To programming?  To system administration?  To
  7271.    other activities (specify)?  How might these percentages change if you
  7272.    acquired a NeXT?
  7273.  
  7274. 10. What do you think about how the NeXT has been marketed?  Any suggestions
  7275.     for improvement?
  7276.  
  7277. From icon-group-request@arizona.edu  Sat Dec 16 19:12:19 1989
  7278. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7279.     id AA27249; Sat, 16 Dec 89 19:12:19 MST
  7280. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  7281.     id AA01476; Sat, 16 Dec 89 18:04:29 -0800
  7282. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  7283.     for icon-group@arizona.edu (icon-group@arizona.edu)
  7284.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  7285. Date: 7 Dec 89 20:56:00 GMT
  7286. From: pur-phy!tippy!yorkw@ee.ecn.purdue.edu
  7287. Subject: What is ICON?
  7288. Message-Id: <134400001@tippy>
  7289. Sender: icon-group-request@arizona.edu
  7290. To: icon-group@arizona.edu
  7291.  
  7292.  
  7293. Well I have a Basic Question. WHAT IS THE ICON LANGUAGE?
  7294. I havent been able to get a good idea from these notes.
  7295. Well just wondering...
  7296. C-ya.
  7297.  
  7298. From icon-group-request@arizona.edu  Mon Dec 18 17:27:58 1989
  7299. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7300.     id AA05157; Mon, 18 Dec 89 17:27:58 MST
  7301. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  7302.     id AA21885; Mon, 18 Dec 89 16:12:32 -0800
  7303. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  7304.     for icon-group@arizona.edu (icon-group@arizona.edu)
  7305.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  7306. Date: 18 Dec 89 21:32:58 GMT
  7307. From: cbmvax!snark!eric@rutgers.edu  (Eric S. Raymond)
  7308. Subject: Re: WOULD *YOU* BUY A NeXT COMPUTER? (Read even if you wouldn't)
  7309. Message-Id: <1TqpCt#6PkSJw=eric@snark.uu.net>
  7310. References: <317@ns-mx.uiowa.edu>
  7311. Sender: icon-group-request@arizona.edu
  7312. To: icon-group@arizona.edu
  7313.  
  7314. In <317@ns-mx.uiowa.edu> Geoffrey Amthor wrote:
  7315. > Fans and flamers alike share one uncertainty, however: Will the NeXT
  7316. > succeed in the marketplace?
  7317.  
  7318. I answered this in email, but I cannot resist the urge to post one question
  7319. to any NeXT fans reading news. To wit:
  7320.  
  7321. Why should I buy Steve Jobs's Mac-on-steroids closed-architecture box when
  7322. I can get cheaper, faster commodity iron with better standards conformance
  7323. based on the 386?
  7324. -- 
  7325.       Eric S. Raymond = eric@snark.uu.net    (mad mastermind of TMN-Netnews)
  7326.  
  7327. From kwalker  Mon Dec 18 18:59:14 1989
  7328. Date: Mon, 18 Dec 89 18:59:14 MST
  7329. From: "Kenneth Walker" <kwalker>
  7330. Message-Id: <8912190159.AA07877@megaron.arizona.edu>
  7331. Received: by megaron.arizona.edu (5.59-1.7/15)
  7332.     id AA07877; Mon, 18 Dec 89 18:59:14 MST
  7333. In-Reply-To: <134400001@tippy>
  7334. To: icon-group
  7335. Subject: Re:  What is ICON?
  7336.  
  7337.     Date: 7 Dec 89 20:56:00 GMT
  7338.     From: pur-phy!tippy!yorkw@ee.ecn.purdue.edu
  7339.     
  7340.     Well I have a Basic Question. WHAT IS THE ICON LANGUAGE?
  7341.     I havent been able to get a good idea from these notes.
  7342.     Well just wondering...
  7343.  
  7344. The following is my standard reply to that question.
  7345.  
  7346. Icon is a high level programming language designed for string processing
  7347. and other non-numeric applications (numeric processing can be done, but the
  7348. language and implementation are not tuned for it). Goal-directed evaluation
  7349. with control backtracking is an integral part of the language. However,
  7350. Icon is very different from other languages, such as Prolog, which use
  7351. this evaluation scheme. Icon has a rich set of control structures which
  7352. use and control backtracking. Most of these control structures look and
  7353. act very much like the control structures of more traditional languages,
  7354. allowing Pascal-like programming where the full power of goal-directed
  7355. evaluation is not required. Icon incorporates generators as a natural feature
  7356. within this goal-directed evaluation scheme.
  7357.  
  7358. Icon has a flexible run-time type system: variables may take on values of
  7359. any type and automatic type conversions are preformed as needed by
  7360. operations. There are a variety of types including strings, sets, associative
  7361. tables, and lists with positional, queue, and stack access methods. All
  7362. storage management is automatic; garbage collection is performed as needed.
  7363.  
  7364.   Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  7365.   +1 602 621 2858  kwalker@cs.arizona.edu {uunet|allegra|noao}!arizona!kwalker
  7366.  
  7367. From @s.ms.uky.edu:mtbb95@ms.uky.edu  Mon Dec 18 20:11:08 1989
  7368. Received: from e.ms.uky.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7369.     id AA10320; Mon, 18 Dec 89 20:11:08 MST
  7370. Received: from s.ms.uky.edu by g.ms.uky.edu id aa11415; 18 Dec 89 22:02 EST
  7371. From: Bob Maras <mtbb95@ms.uky.edu>
  7372. Date: Mon, 18 Dec 89 22:02:29 EST
  7373. X-Mailer: Mail User's Shell (6.4 2/14/89)
  7374. To: Kenneth Walker <kwalker@cs.arizona.edu>, icon-group@cs.arizona.edu
  7375. Subject: Re:  What is ICON?
  7376. Message-Id:  <8912182202.aa03359@s.s.ms.uky.edu>
  7377.  
  7378. Thanks to Ken Walker for a most descriptive summary of the ICON language!!!
  7379. Bob
  7380.  
  7381. -- 
  7382.                           _      _
  7383.                          ( ) __ ( )
  7384.                           | O  O |         B O B   M A R A S
  7385.                           /  __  \      /
  7386.                          (   \/   )  __/
  7387.                           \ \__/ / 
  7388.                            \____/ 
  7389.                            |_/\_|     H A P P Y    C O M P U T I N G    !!!
  7390.         
  7391.  
  7392. From mtbb95@ms.uky.edu  Mon Dec 18 20:26:14 1989
  7393. Received: from RUTGERS.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7394.     id AA10713; Mon, 18 Dec 89 20:26:14 MST
  7395. Received: from ukma.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.04) with UUCP 
  7396.     id AA21321; Mon, 18 Dec 89 22:25:16 EST
  7397. Received: from e.ms.uky.edu by g.ms.uky.edu id aa27894; 19 Dec 89 2:57 GMT
  7398. Received: from s.ms.uky.edu by g.ms.uky.edu id aa11391; 18 Dec 89 21:54 EST
  7399. From: Bob Maras <mtbb95@ms.uky.edu>
  7400. Date: Mon, 18 Dec 89 21:54:08 EST
  7401. X-Mailer: Mail User's Shell (6.4 2/14/89)
  7402. To: tippy!yorkw@newton.physics.purdue.edu, icon-group@arizona.edu
  7403. Subject: Re: What is ICON?
  7404. Message-Id:  <8912182154.aa02781@s.s.ms.uky.edu>
  7405.  
  7406. I have really enjoyed following the developments of the ICON language that
  7407. have been shared with the icon-group.  I sort of like the request that was 
  7408. a simple question, "WHAT IS THE ICON LANGUAGE?"
  7409.  
  7410. It might be of great value if all group recipients could receive a few statementthat share the similarities as well as the differences ICON has with other 
  7411. currently used languages, primarily C, but, also pascal, and even perhaps 
  7412. simpler languages such as BASIC.  
  7413.  
  7414. I think that some of these introductory messages may serve well in the drawing
  7415. of individuals with programming into the group.
  7416.  
  7417. Bob
  7418.  
  7419. -- 
  7420.                           _      _
  7421.                          ( ) __ ( )
  7422.                           | O  O |         B O B   M A R A S
  7423.                           /  __  \      /
  7424.                          (   \/   )  __/
  7425.                           \ \__/ / 
  7426.                            \____/ 
  7427.                            |_/\_|     H A P P Y    C O M P U T I N G    !!!
  7428.         
  7429.  
  7430. From icon-group-request@arizona.edu  Tue Dec 19 14:24:34 1989
  7431. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7432.     id AA08601; Tue, 19 Dec 89 14:24:34 MST
  7433. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  7434.     id AA03973; Tue, 19 Dec 89 13:03:58 -0800
  7435. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  7436.     for icon-group@arizona.edu (icon-group@arizona.edu)
  7437.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  7438. Date: 19 Dec 89 21:03:47 GMT
  7439. From: zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@tut.cis.ohio-state.edu  (Alan D Corre)
  7440. Organization: University of Wisconsin-Milwaukee
  7441. Subject: Library procedures for MS-DOS
  7442. Message-Id: <1569@uwm.edu>
  7443. Sender: icon-group-request@arizona.edu
  7444. To: icon-group@arizona.edu
  7445.  
  7446. By request I am posting the MS-DOS version of the procedures I posted
  7447. recently for the Zenith terminal. I have added Chris Tenaglia's input
  7448. procedure, and have gilded his lily by offering a variant, inputl, which
  7449. insists on a response of a specific length. This can readily be modified
  7450. to include other determinants, that the response must be an integer, for
  7451. example.
  7452.  
  7453.  
  7454. procedure banner(l[])
  7455. #Writes to the screen an arbitrary number of strings and encloses them.
  7456. local n
  7457.   write();write();write()
  7458.   writes(char(201)) #top left right angle
  7459.   writes(repl(char(205),78)) #straight line
  7460.   writes(char(187)) #top right right angle
  7461.   writes(char(186)) #upright line at left
  7462.   writes(right(char(186),79)) #upright line at right
  7463.   every n := 1 to *l do {
  7464.     writes(char(186)) #upright line at left
  7465.     writes(center(l[n],78),char(186)) #string centered followed by upright line
  7466.     writes(char(186)) #upright line at left
  7467.     writes(right(char(186),79)) #upright line at right
  7468. }
  7469.   writes(char(200)) #bottom left right angle
  7470.   writes(repl(char(205),78)) #straight line
  7471.   write(char(188)) #bottom right right angle
  7472.   write()
  7473. return
  7474. end
  7475.  
  7476.  
  7477. procedure instructions(filename)
  7478. #writes contents of a file to screen, allows user to stop after any screenful.
  7479. local filvar,counter,line
  7480.   writes("Do you need instructions? y/n ")
  7481.   if upto('yY',read()) then {
  7482. #The following if-statement fails if the file is not available
  7483.   counter := 0
  7484.   if filvar := open(filename) then
  7485. #Read the help file. It's a good idea to keep this kind of info in a
  7486. #separate file because you can modify it easily without redoing the
  7487. #program. In general---keep data out of programs!
  7488.     while line := read(filvar) do {
  7489. #Write out a line and increment the counter
  7490.       write(line)
  7491.       counter +:= 1
  7492. #Now we have a screenful; ask if we should continue
  7493.       if counter >22 then {
  7494.         write()
  7495.         writes ("More? y/n ")
  7496. #User has had enough; break out of loop
  7497.         if upto('nN',read()) then break  else
  7498. #User wants more; reset counter and continue
  7499.           counter := 0}} else
  7500. #This else goes with the second if-statement; the attempt to open the
  7501. #help file failed:
  7502.       write("Sorry, instructions not available.")}
  7503.     write ("Press return to continue.")
  7504.     read()
  7505. #Close the file if it existed and was opened. If it was never opened
  7506. #the value of filvar will be null. This check has to be made because
  7507. #an attempt to use close() on a variable NOT valued at a file would
  7508. #cause an error. 
  7509. /filvar | close(filvar)
  7510. end
  7511.  
  7512. procedure randomize()
  7513. #deletes the colons from the clock time, and uses the resulting number as seed
  7514. local clock
  7515.   clock := &clock
  7516.   clock[6] := ""
  7517.   clock[3] := ""
  7518.   &random := clock
  7519. end
  7520.  
  7521. procedure clear()
  7522. #clears the screen
  7523.   writes("\e[2J")
  7524. end
  7525.  
  7526. procedure gotoxy(l,r)
  7527. #sets the cursor at line l, row r
  7528.   writes("\e[",l,";",r,"H")
  7529. end
  7530.  
  7531. procedure input(s)
  7532. #prints the prompt s and returns the user's response
  7533.   writes(s)
  7534. return read()
  7535. end
  7536.  
  7537. procedure inputl(s,n)
  7538. #prints the prompt s,  indicates that the response must be n characters
  7539. #max, and insists on appropriate response.
  7540. local ans
  7541.   write(s)
  7542.   writes(n," characters maximum. ")
  7543. #if ANSI driver is installed omit initial #-sign in following lines
  7544. # writes("\e[7m\e[s", repl(" ",n),"\e[u\e[0m") #save cursor,reverse video,
  7545.                                ##n blanks, restore cursor, normal video
  7546.   while *(ans := read()) > n do {
  7547.     write(s)
  7548.     writes(n," characters maximum. ")
  7549. #   writes("\e[7m\e[s", repl(" ",n),"\e[u\e[0m")
  7550.                                  }
  7551. return ans
  7552. end
  7553.  
  7554. --
  7555. Alan D. Corre
  7556. Department of Hebrew Studies
  7557. University of Wisconsin-Milwaukee                     (414) 229-4245
  7558. PO Box 413, Milwaukee, WI 53201               corre@csd4.csd.uwm.edu
  7559.  
  7560. From icon-group-request@arizona.edu  Tue Dec 19 14:33:41 1989
  7561. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7562.     id AA08978; Tue, 19 Dec 89 14:33:41 MST
  7563. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  7564.     id AA05253; Tue, 19 Dec 89 13:23:57 -0800
  7565. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  7566.     for icon-group@arizona.edu (icon-group@arizona.edu)
  7567.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  7568. Date: 19 Dec 89 21:23:03 GMT
  7569. From: zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@tut.cis.ohio-state.edu  (Alan D Corre)
  7570. Organization: University of Wisconsin-Milwaukee
  7571. Subject: Re: What is ICON?
  7572. Message-Id: <1570@uwm.edu>
  7573. References: <8912182154.aa02781@s.s.ms.uky.edu>
  7574. Sender: icon-group-request@arizona.edu
  7575. To: icon-group@arizona.edu
  7576.  
  7577.  
  7578. In my view, one of the most useful and characteristic features of Icon
  7579. is the string scanning facility (marked by the question mark "?")
  7580. which enables strings to be manipulated simply. In my recently
  7581. published book "Icon Programming for Humanists" I introduced this
  7582. feature right at the beginning since it can be utilized with a modest
  7583. understanding of the rest of the language. Another characteristic
  7584. feature (mentioned recently in this newsgroup) is the fact that
  7585. results of procedures can be used Boolean fashion, returning something
  7586. being equivalent to TRUE. There is a difference from Lisp however, in
  7587. that the return of a null value still counts as a "success".
  7588.  
  7589. An American visitor to London once commented to me that in that city
  7590. they erect railings to stop people from crossing the street mid-block.
  7591. She commented that in America we believe in freedom, so we allow
  7592. people to cross and kill themselves. Computer languages are a bit like
  7593. that. Pascal hems you in with railings. Snobol lets your programs blow
  7594. up. Icon, it seems to me, strikes a good balance between the Germanic
  7595. coercion of Pascal and the American permissiveness of Snobol.
  7596. --
  7597. Alan D. Corre
  7598. Department of Hebrew Studies
  7599. University of Wisconsin-Milwaukee                     (414) 229-4245
  7600. PO Box 413, Milwaukee, WI 53201               corre@csd4.csd.uwm.edu
  7601.  
  7602. From gudeman  Tue Dec 19 15:02:36 1989
  7603. Date: Tue, 19 Dec 89 15:02:36 MST
  7604. From: "David Gudeman" <gudeman>
  7605. Message-Id: <8912192202.AA10764@megaron.arizona.edu>
  7606. Received: by megaron.arizona.edu (5.59-1.7/15)
  7607.     id AA10764; Tue, 19 Dec 89 15:02:36 MST
  7608. To: icon-group@arizona.edu
  7609. In-Reply-To: (Alan D Corre's message of 19 Dec 89 21:23:03 GMT <1570@uwm.edu>
  7610. Subject: What is ICON?
  7611.  
  7612.    From: zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@tut.cis.ohio-state.edu  (Alan D Corre)
  7613.  
  7614.    An American visitor to London once commented to me that in that city
  7615.    they erect railings to stop people from crossing the street mid-block.
  7616.    She commented that in America we believe in freedom, so we allow
  7617.    people to cross and kill themselves.
  7618.  
  7619. In London, perhaps people respect railings.  In America we believe in
  7620. freedom, so we would jump over or go under :-).
  7621.  
  7622. From spqr%ecs.southampton.ac.uk@NSFnet-Relay.AC.UK  Wed Dec 20 02:34:36 1989
  7623. Received: from NSFNET-RELAY.AC.UK by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7624.     id AA09720; Wed, 20 Dec 89 02:34:36 MST
  7625. Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK 
  7626.            via Janet with NIFTP  id aa02097; 20 Dec 89 9:24 GMT
  7627. Received: from alonzo.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Wed, 20 Dec 89 09:32:46 GMT
  7628. From: Sebastian P Q Rahtz <spqr%ecs.southampton.ac.uk@NSFnet-Relay.AC.UK>
  7629. Date: Wed, 20 Dec 89 09:31:46 GMT
  7630. Message-Id: <539.8912200931@alonzo.ecs.soton.ac.uk>
  7631. To: icon-group@arizona.edu
  7632. In-Reply-To: David Gudeman's message of Tue, 19 Dec 89 15:02:36 MST <8912192202.AA10764@megaron.arizona.edu>
  7633. Subject: Re: What is ICON?
  7634.  
  7635.  
  7636.  >    An American visitor to London once commented to me that in that city
  7637.  >    they erect railings to stop people from crossing the street mid-block.
  7638.  >    She commented that in America we believe in freedom, so we allow
  7639.  >    people to cross and kill themselves.
  7640. I have to tell you, from these wet and wild shores, that we don't have
  7641. blocks on our streets. our permissiveness and freedom is such  that
  7642. most of out cities are built higgledy-piggledy. We also tend to have
  7643. traffic lights that simply go green, rather than instructing
  7644. pedestrians to WALK.
  7645.  
  7646. Icon, of course, is neither wet nor higgledy-piggledy; it always
  7647. strikes me when I defend or describe it that one of the joys is that
  7648. fact that it has a specific origin, namely Arizona and Ralph Griswold.
  7649. Of course lots of people have worked on it, but there is still a
  7650. feeling that a small group is looking after the language because they
  7651. care, not to make money or satisfy a committee. We'll know to give up
  7652. when ISO appoint an Icon committee!
  7653.  
  7654. Sebastian Rahtz                        S.Rahtz@uk.ac.soton.ecs (JANET)
  7655. Computer Science                       S.Rahtz@ecs.soton.ac.uk (Bitnet)
  7656. Southampton S09 5NH, UK                S.Rahtz@sot-ecs.uucp    (uucp)
  7657.  
  7658.  
  7659.  
  7660. From icon-group-request@arizona.edu  Wed Dec 20 18:31:34 1989
  7661. Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP
  7662.     id AA04726; Wed, 20 Dec 89 18:31:34 MST
  7663. Received: by ucbvax.Berkeley.EDU (5.61/1.40)
  7664.     id AA13135; Wed, 20 Dec 89 17:22:32 -0800
  7665. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  7666.     for icon-group@arizona.edu (icon-group@arizona.edu)
  7667.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  7668. Date: 20 Dec 89 20:39:53 GMT
  7669. From: gvlv2!imagine!chris@burdvax.prc.unisys.com  (Chris Sterritt)
  7670. Organization: Unisys/Automated Document Management Systems, Radnor, PA
  7671. Subject: ICON wanted
  7672. Message-Id: <179@imagine.ADMS-RAD.Unisys.COM>
  7673. Sender: icon-group-request@arizona.edu
  7674. To: icon-group@arizona.edu
  7675.  
  7676. Hello,
  7677.     I (and a friend not on the net) would like to get the icon
  7678. language for various machines.  I would appreciate finding out where
  7679. to FTP source and/or binaries for SUNs, Macs, and AT&T 3b1.
  7680. Please reply to me directly, and I'll summarize to the net if there's
  7681. enough interest.  I apologize if it's out of line to make this request
  7682. on this group, however I don't know where else to find this out.
  7683.     thanks very much in advance,
  7684.     chris sterritt
  7685.     chris@adms-rad.unisys.com
  7686.  
  7687.