home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group83.txt < prev    next >
Internet Message Format  |  1988-10-29  |  58KB
  1. From mmdf Sun May 15 13:57:48 1983
  2. From: whm at arizona
  3. Date-Sent: 15 May 83 13:55:59 MST  (Sun)
  4. Subject:  Welcome to Icon-Group
  5. To: icon-group@arizona
  6. Status: RO
  7.  
  8. The Icon-Group mailing list is now open for business.
  9.  
  10. This list is meant to be a common meeting area for persons interested
  11. in the Icon programming language.  Topics for discussion include (but
  12. are not limited to):
  13.  
  14.     Programming Techniques
  15.       - Style
  16.       - Efficiency
  17.       - Idioms
  18.       - Pros and Cons of certain constructs
  19.       - Clever ways to accomplish a certain task
  20.     Theoretical Aspects
  21.     Icon in relation to other languages
  22.     Applications of Icon
  23.     Implementation Issues
  24.     Porting Icon to other machines
  25.     History/Origins
  26.     Idea/Wish Lists
  27.     Announcement/Exchange of programs and procedures
  28.     Bugs
  29.     
  30. While it is hoped that this list doesn't become devoted to bug-related
  31. items, we will use the list for bug reports and fixes.  We will do
  32. our best to fix any bugs that are reported.  Bug fixes that we
  33. announce will be incorporated in the next system release.
  34.  
  35. Items of interest should be mailed to icon-group.arizona@rand-relay.
  36. Mail will be immediately redistributed to all persons on the
  37. list.  Requests for addition/removal from the list should be sent
  38. to icon-group-request.arizona@rand-relay.  Archives will be
  39. maintained locally.
  40.  
  41. This mailing list does not subsume the function of the icon-project
  42. mailbox that we currently maintain.  Rather, the mailing list
  43. supplements it.  Icon questions that may not be appropriate for
  44. icon-group can be sent to icon-project.  If you are in doubt,
  45. send to icon-project, note your uncertainty, and we'll see it
  46. ends up in the correct place.
  47.  
  48. As mentioned, the list is "on", if you have anything to say,
  49. speak up.
  50.  
  51.                     Bill Mitchell
  52.  
  53.  
  54. From mmdf Sun May 15 18:46:03 1983
  55. From: whm at arizona
  56. Date-Sent: 15 May 83 18:44:49 MST  (Sun)
  57. Subject:  Icon documentation
  58. To: icon-group@arizona
  59. Status: RO
  60.  
  61. We frequently receive requests concerning the availability of Icon
  62. documentation.  Here is the current situation.
  63.  
  64. The only up-to-date and complete documentation of Version 5 of Icon is
  65. contained in the following book (generally referred to as "the Icon book"):
  66.  
  67.    The Icon Programming Language, Ralph E. Griswold and Madge T. Griswold.
  68.    Prentice-Hall, Inc., Englewood Cliffs, NJ.  1983.  313 pages, paperback.
  69.    $18.95.
  70.  
  71. This book should be available through any seller of new books.  It is
  72. not available through the University of Arizona.
  73.  
  74. The Icon reference manual (TR 81-4a) which used to be distributed with
  75. the system is both out of date and out of print and is no longer available.
  76.  
  77. There is a brief (9-page) overview of Icon available as University of
  78. Arizona technical report TR 83-3a.  This report will be sent via the Postal
  79. Service, free of charge, to anyone who requests it.  Nroff source for this
  80. overview (~23K bytes) will be sent via electronic mail on individual request,
  81. but it will not be broadcast to icon-group because of its size.
  82.  
  83. There are quite a few other technical reports and journal articles related to
  84. Icon.  These are summarized in a bibliography of Icon documents, which, like
  85. the overview, will be sent free of charge, via the Postal Service.  Ask for
  86. the "Icon Bibliography".
  87.  
  88. All Icon-related technical reports and journal reprints authored at the
  89. University of Arizona are available free of charge, while supplies last.
  90. The bibliography described above indicates what is available.
  91.  
  92. Requests for documents should be addressed to
  93.  
  94.    icon-project.arizona@rand-relay
  95.  
  96. Be sure to include a postal address for hardcopy requests.
  97.  
  98.  
  99. From mmdf Fri May 20 07:41:34 1983
  100. From: ralph at arizona
  101. To: icon-group@arizona
  102. Subject: Survey
  103. Status: RO
  104.  
  105. In order to get an idea what directions this group might take, it would
  106. help to know how familiar its members are with Icon and where their
  107. interests lie.  Please, therefore, answer the following questions:
  108.  
  109. A.  What is your familiarity with Icon? -- on a scale of 1 to 10,
  110. graded roughly as follows:
  111.  
  112.     1 -- have heard of Icon, but that's about all
  113.         .
  114.         .
  115.         .
  116.     5 -- generally knowledgeable about Icon and competent to
  117.          formulate simple programs
  118.         .
  119.         .
  120.         .
  121.     10 -- Icon wizard
  122.  
  123. B.  What discussion topics most interest you (see the mail that announced
  124. the establishment of icon-group or make up your own categories).
  125.  
  126. Mail to
  127.  
  128.     icon-project.arizona@rand-relay
  129.  
  130. Replies will be summarized and mailed to icon-group.
  131.  
  132.         - Ralph Griswold
  133.  
  134.  
  135. From mmdf Mon May 23 16:21:54 1983
  136. From: Robert E. Wells <rwells@bbn-unix>
  137. Subject: Implementation of Icon tables
  138. To: icon-group.arizona@rand-relay
  139. Cc: rwells@bbn-unix
  140. Status: RO
  141.  
  142. I would like to know more about the implementation of Icon tables.
  143. Here are a few questions...
  144.  
  145.   * In SNOBOL4, the table create function has an optional second argument
  146.     that specifies the reallocation increment for the table.  Icon doesn't
  147.     seem to have this level of control.  Were there reasons for and
  148.     against having this control in Icon?  How does Icon pick the
  149.     reallocation increment?  In SNOBOL4, the table size returned to the
  150.     user seems to be the amount allocated, rather than the amount used.
  151.     Icon seems to return the amount used as the size; does it have a
  152.     hidden allocation size as well?
  153.  
  154.   * I assume tables use hashed searching.  Is there a particular hashing
  155.     algorithm that makes it easier to dynamically increase the size of the
  156.      table?
  157.  
  158.   * A substring operation like  x[1:4]  fails if the given substring doesn't
  159.     exist, yet  words["way"]  succeeds (returning the default table value)
  160.     even if "way" isn't in the table words.  This seems inconsistent to
  161.     me; is it a good inconsistency?  The FASBOL dialect of SNOBOL4 had a
  162.     MEMBER function that acted just like normal table references, but
  163.     failed if the given index was not in the table; this was particularly
  164.     useful if real table elements could have the default value, and one
  165.     needed to quickly determine table membership independent of value.
  166.  
  167. -Thanks, Robert
  168.  
  169.  
  170.  
  171.  
  172. From mmdf Mon May 23 18:17:24 1983
  173. From: whm at arizona
  174. Date-Sent: 23 May 83 18:15:56 MST  (Mon)
  175. Subject:  Icon on a 68000
  176. To: icon-group@arizona
  177. Status: RO
  178.  
  179. We are seriously considering porting Icon to a 68000 based UNIX-
  180. like system.  Before we dive in on this, we'd like to know if
  181. anyone has knowledge of someone who is already working on a 68000
  182. port.  If you have even so much as a strong rumor, let us know.
  183. Reply to icon-project if you would, or if the information might
  184. be of general interest, send it to icon-group.
  185.  
  186.                     Bill Mitchell
  187.  
  188.  
  189. From mmdf Tue May 24 07:39:07 1983
  190. From: ralph at arizona
  191. To: icon-group.arizona@rand-relay
  192. Subject: Tables
  193. Status: RO
  194.  
  195. Robert E. Wells has raised some interesting questions about
  196. tables in SNOBOL4 and Icon.  I can respond to some of these ques-
  197. tions from my own experience and speculate about others.
  198.  
  199. Tables were added to SNOBOL4 very late in its design and imple-
  200. mentation.  In fact, the implementation was pasted onto the sys-
  201. tem as it was about to go out the door. In this first (SIL)
  202. implementation of SNOBOL4, values in tables were not hashed, but
  203. a linear lookup was used instead.  The two arguments in
  204. TABLE(N,M) specified sizes for the initial and subsequent chained
  205. blocks, respectively (much like primary and secondary space allo-
  206. cations for OS/360 data sets).
  207.  
  208. As far as I know, most subsequent implementations of SNOBOL4 used
  209. hashing techniques for tables.  E.g., in both SITBOL and MACRO
  210. SPITBOL, the form of the function is TABLE(N), where N specifies
  211. the number of hash bins. Hashing is used to select a bin and col-
  212. lisions are handled by chaining within a bin.  In SITBOL, the
  213. default value of N is 37.
  214.  
  215. Icon uses a technique similar to SITBOL and MACRO SPITBOL, except
  216. that the number of bins is fixed (14).
  217.  
  218. There obviously is a tradeoff between the number of bins (and
  219. hence the minimum space used for each table) and efficiency of
  220. lookup, depending a lot on how many values there are in the
  221. table.
  222.  
  223. Hashing seems to me like the reasonable way to implement tables.
  224. Note that there is a problem, since a table can be subscripted
  225. with any kind of value, not just a string.  Subscripting with
  226. structures (like tables (!) and records) raises the issue of how
  227. to compute a hash number.  In fact, Icon had a bug in this area
  228. until just recently.  Algorithms for hashing values of arbitrary
  229. types might be a topic for more discussion.
  230.  
  231. I personally think that user specification of the block size or
  232. the number of hash bins is contrary to the philosophy of languages
  233. like SNOBOL4 and Icon.  Anyway, how many users know how to pick
  234. the parameters intelligently?  Most users either let the parame-
  235. ters default or fiddle around and see what seems to work best.
  236. My view is that the implementation should be clever enough to
  237. adapt the structure used for the table as necessary to maintain
  238. efficient lookup.  Needless to say, this is not easy.
  239.  
  240. The issue of s[i] failing if i is out of range of the string s,
  241. while t[x] always succeeding if t is a table, is a conceptual issue.
  242. Part of the apparent discrepancy comes from the fact that the
  243. operation x[y] is polymorphous, using the same syntax for quite
  244. different operations.  The identical syntax suggests that the
  245. semantics of the operations should be more similar than they are
  246. (perhaps).  My view on this is that s[i], where s is a string, is
  247. an operation on a fixed object and it is convenient for it to
  248. fail if i is out of the range of s.  Almost the identical thing
  249. happens for a[i], where a is a list.  In t[x], where t is a
  250. table, the underlying concept is that the domain of tables poten-
  251. tially includes every possible subscript -- or even that a table
  252. (conceptually) contains every subscript in the universe of sub-
  253. scripts, but that values have not been associated with all sub-
  254. scripts.  This leads to the idea of a default value associated
  255. with every subscript, and hence to the way tables work in Icon.
  256.  
  257. In practice, the Icon programmer picks a default value that is
  258. easy to test and that is not assigned as a value.  The null value
  259. is typical.  This splits the values associated with all possible
  260. subscripts into two parts -- those put into the table by the user
  261. and the rest.
  262.  
  263. I agree that a test for membership would be more natural in many
  264. cases.  But then I want sets, too.
  265.  
  266.     - Ralph Griswold
  267.  
  268.  
  269. From mmdf Tue May 24 21:54:43 1983
  270. From: whm at arizona
  271. Date-Sent: 24 May 83 21:52:32 MST  (Tue)
  272. Subject:  Re: Tables
  273. To: icon-group@arizona
  274. Status: RO
  275.  
  276. I believe that Spitbol 360 uses the table(m,n) form, does anyone
  277. know what the system actually does with the expansion argument?
  278.  
  279. Concerning specification of table sizes, it's nice to be able to
  280. free the user from having to worry about that, but the fact is
  281. that is that it's hard to imagine an efficient table implementation
  282. that can adapt itself to widely varying table sizes.  In Icon, if
  283. you have a table with 10,000 elements, the worst case scattering
  284. of hash values will necessitate 10,000 element accesses to add an
  285. element.  In the best case, you get about 70 accesses to add an
  286. element.  Doesn't seem too good to me.  If the same table framework
  287. is maintained, adding a size argument to the table function
  288. doesn't seem that atrocious.  The size argument would specify the
  289. expected number of elements in the table.
  290.  
  291. I suppose the real issue is that of practicality.  It might be
  292. nice to cook up some hot data structure that can easily manage
  293. tables of widely varying sizes, but if I was faced with an urgent
  294. need to have Icon handle very large tables, I'd add the size
  295. argument and let the user take some of the responsibility.
  296.  
  297. On the other hand, it does seem that the internal representation
  298. of tables is an area that can stand some work.  My first
  299. inclination would be to look at the various tree structures used
  300. by database systems to see if one of them could be used.  Of
  301. course, the issue can be further complicated by considering what
  302. operations are most prevalent and trying to optimize things on
  303. that basis.
  304.  
  305. What other languages (besides Icon and the SNOBOL4 family) have
  306. have table-like (i.e. associative) data structures?  I'd imagine
  307. that SL5 has tables.  I know that awk has tables, and I believe
  308. that bs (USG UNIX) has tables.  Is anyone familiar with the
  309. implementation of tables in these languages?
  310.  
  311.                     Bill Mitchell
  312.  
  313.  
  314. From mmdf Tue May 24 22:07:37 1983
  315. From: whm at arizona
  316. Date-Sent: 24 May 83 22:06:06 MST  (Tue)
  317. Subject:  subscripts
  318. To: icon-group@arizona
  319. Status: RO
  320.  
  321. An interesting thing to note is that if t[x] fails when x is not
  322. in the table t, it creates a bit of an inconsistency:
  323.  
  324. If you say
  325.  
  326.     s := "hello"
  327.     s[10] := "x"
  328.     
  329. the reference to s[10] fails and the assignment is not performed.
  330. If you have an empty table t, and you say
  331.  
  332.     t[1] := "x"
  333.     
  334. should t[1] fail?  If it does, tables aren't going to be a very useful
  335. language feature.  What's the alternative?  Do some special casing
  336. of some type?  No good, I think you'd just end up in a terrible mess.
  337.  
  338.                     Bill Mitchell
  339.  
  340.  
  341.  
  342. From mmdf Wed May 25 15:48:21 1983
  343. From: Jerry Leichter <Leichter@YALE.ARPA>
  344. Subject: Implementing tables efficiently
  345. To: icon-group.arizona@RAND-RELAY.ARPA
  346. Status: RO
  347.  
  348. There are two general approaches to maintaining table-like structures of widely
  349. varying sizes efficiently, both of which have been in wide use in data base
  350. applications.  The first, and usually easier approach is to update tables on
  351. a periodic basis.  The ISAM file structures (to use the IBM terminology) do
  352. this:  As items are added to and deleted from the file, access gets less and
  353. less efficient and space gets wasted.  Every once in a while (week? day? - it
  354. depends on the application and can be quite hard to decide on) a utility
  355. program gets run which re-creates the file from scratch in some efficient
  356. form.  The newly-created file has no gaps left from deleted items and has
  357. an index ("hash table") size computed to give good access.  Usually, space
  358. is left for additional records, though this is an obvious place to provide
  359. controls - if I know the file will not grow by much, there is no reason to
  360. leave much space.  The analogue for Icon (or other languages) is obvious:
  361. Either provide an explicitly-callable "cleanup table" function, or, much more
  362. in keeping with the philosophy of the language, do this as part of garbage
  363. collection.  The goal of "cleaning up" a table is to (1) eliminate all unused
  364. space (deleted elements); (2) to re-hash, if necessary, into a larger or
  365. smaller table that optimizes (some measure of) the time/space tradeoff.  Again,
  366. one can either have the user provide information like "this table will never
  367. grow again", or do something like keeping track of the changes since the last
  368. time the table was restructured and use that as a prediction.
  369.  
  370. Periodic updating, exactly like periodic garbage collection, has a problem:
  371. Every once in a while, the whole system stops for a while to do it.  For a
  372. language like Icon, this might be acceptable.  For file systems, it has turned
  373. out not to be; hence, the evolution of a second alternative:  Incremental up-
  374. dating.  (IBM VSAM files)  In incremental updating, the time/space tradeoff is
  375. evaluated on each reference to the file, and "small" restructurings are made
  376. as necessary.  B-trees are a standard technique used here.  Up until a few
  377. years ago, no incremental hashing techniques were known; then a whole slew of
  378. them were discovered in a very short time.  (I can provide references if people
  379. are interested.)  These could be adapted to tables, if desired.  However, the
  380. incremental techniques, like incremental garbage collection techniques, tend
  381. to be somewhat less efficient, averaged over long periods of time, than the
  382. periodic algorithms - they trade predictability for efficiency.
  383.  
  384. The original SIL SNOBOL implementation is a very simple incremental technique.
  385. A similar, but improved, technique could easily be used.  Suppose we use a
  386. linked-bucket hash table.  In the header of the table, maintain the lengths of
  387. each of the chains.  (This can be done very cheaply by the insertion and dele-
  388. tion code.)  Also maintain a pair of goals, LO and HI.  When the average chain
  389. length - or the maximum, or some other measure - gets outside of the goals,
  390. re-hash everything into a new table with more (or fewer) buckets.  In choosing
  391. the new number of buckets, a multiplicative factor should probably be used so
  392. that large tables, as they grow, don't get re-hashed to often.  This is a very
  393. primitive approach, but will probably work quite well; all sorts of sophistica-
  394. tion can be added.
  395.  
  396. As a point of interest, after using tables in SNOBOL for years, I've gotten to
  397. depend on them for various things to such an extent that I've implemented ana-
  398. logous structures in other languages I've used, C in particular.  (The imple-
  399. mentation is typically a package of subroutines.  I've ended up with a standard
  400. package that works out well:  add new element, delete old element, replace old
  401. element (returning old value), and iterate through table, done as i = (say) -1;
  402. while((i = next(table,i)) != -1) { work with element pointed to in some known
  403. way}.)  VERY handy!
  404.                         -- Jerry
  405.                     decvax!yale-comix!leichter
  406.                     leichter @ yale
  407. -------
  408.  
  409.  
  410. From mmdf Wed May 25 15:54:52 1983
  411. From: PAIGE@RUTGERS
  412. Subject: Re: Tables
  413. To: whm.arizona@RAND-RELAY, icon-group.arizona@RAND-RELAY
  414. In-Reply-To: Your message of 25 May 83 01:52:34 EDT
  415. Status: RO
  416.  
  417. SETL implements dynamic heterogeneous sets and mappings.  I believe,
  418. but not completely sure anymore, that each data type has its own special
  419. formula for computing its hash code.  The formula for elementary data
  420. items is straightforward; for tuples (dynamic heterogenous vectors) the
  421. hash code is just the code for the first component; for sets the code
  422. is the exclusive or of the codes of all of the elements in the set.
  423. Thus, the hash code for a set can be recomputed cheaply when it is 
  424. augmented or diminished -- in each case the new hash code is just the
  425. old code exor'ed with the element being added or deleted.
  426.  
  427. SETL mappings are similar to tables.  Mappings are access paths from
  428. a domain set to a range set, and are represented as sets of 2-tuples.
  429. However, SETL distinguishes between function and multivalued mapping
  430. operations.  The notation f(a) indicates function retrieval and is
  431. undefined if f is not a set, if f is a set but contains no pair whose
  432. first component has the value a (i.e., a is not in the domain of f),
  433. or if f is not single valued at a.  In all of those cases the value
  434. of the function retrieval is omega, the unique undefined atom.  
  435. In order for the user to define a default value in lieu of omega
  436. for f, a macro or a procedure named 'f' would have to be used.
  437.  
  438. The notation f{a} indicates multivalued map retrieval and is undefined
  439. only when f is not a set.  If a is not in the domain of f, the value is
  440. the empty set, {}.  
  441.  
  442. I like the idea of having user defined dafault values for tables, but
  443. wonder why tables are not called mappings or functions.  Also, the
  444. notation f[s] is used commonly in mathematics to denote the image of the
  445. set s under the mapping f, so I would prefer a different notation for
  446. simple table retrieval.  Image set is not available in SETL, but it is
  447. very useful in specifying algorithms clearly and concisely.
  448.  
  449. I agree that picking block size or number of hash bins runs contrary
  450. to the philosophy of high level languages.  Has anyone considered
  451. an extensible hashing technique (see Fagin, Pippenger, Strong, Nievergelt
  452. in TODS # 3, 1979) or Universal Hashing due to Carter and Wegman?
  453.  
  454. Bob Paige
  455. -------
  456.  
  457.  
  458. From mmdf Wed May 25 15:58:00 1983
  459. From: PAIGE@RUTGERS
  460. Subject: Re: subscripts
  461. To: whm.arizona@RAND-RELAY, icon-group.arizona@RAND-RELAY
  462. In-Reply-To: Your message of 25 May 83 02:06:08 EDT
  463. Status: RO
  464.  
  465. I'm not convinced that your example exhibits an inconsistency.  The 
  466. assignment f[x] := y means something different depending on the type for f.
  467. When f is a table, one could argue that f is a mapping, and therefore, a set.
  468. The indexed assignment could indicate that all pairs whose first component
  469. has the value x are removed from f after which the pair [x,y] is added.
  470. This semantics is followed by SETL and is consistent with elementary set
  471. theory.  So in this case, I don't think there should be failure.
  472. Whether or not failure occurs when f is a string and x is 10 could certainly
  473. depend on the semantics of strings.  One could argue that strings are
  474. finite tuples with character components, so that when f is of length 5
  475. one cannot extend it by placing a character in the 10th position.  So a
  476. failure in this case is natural.
  477.  
  478. Bob Paige
  479. -------
  480.  
  481.  
  482. From mmdf Thu May 26 22:15:56 1983
  483. From: whm at arizona
  484. Date-Sent: 26 May 83 22:14:20 MST  (Thu)
  485. Subject:  What's in a name
  486. To: icon-group@arizona
  487. Status: RO
  488.  
  489. Every now and then I run into somebody that sees the name "Icon"
  490. and thinks that it has something to do with Xerox, Smalltalk, etc.
  491. This might be better aimed at the Usenet st80 group, but I was
  492. wondering if anybody might know when the people at Xerox first
  493. started using the term "icon".
  494.  
  495. I believe that Icon (as in the language) dates from about 1978,
  496. but I'm not really sure.  Perhaps Ralph could give a little
  497. background on how the name was selected and when.  (<- subtle hint)
  498.  
  499. While I'm here, let me point out that Icon is spelled I-c-o-n.  In
  500. particular, note that it is not spelled I-C-O-N, or i-c-o-n.  Nobody
  501. will roll over and die if you use "ICON", but "Icon" is correct.
  502.  
  503.                     Bill Mitchell
  504.  
  505.  
  506.  
  507. From mmdf Fri May 27 23:58:47 1983
  508. From: trh at arizona
  509. To: icon-group@arizona
  510. Subject: efficiency
  511. Status: RO
  512.  
  513. Here's a question for gurus:
  514.  Is line A or line B more efficient? Why? Is it significantly so?
  515.  
  516. procedure main()
  517.     t := table()
  518.     t[1] := "abc"
  519.     t[2] := "def"
  520.     t[3] := "ghi"
  521.  
  522.     every write(!t[1] || !t[2] || !t[3])    #line A
  523.     every write(!t[1],!t[2],!t[3])        #line B
  524. end
  525.  
  526.  
  527. From mmdf Sat May 28 13:43:32 1983
  528. From: ralph at arizona
  529. To: icon-group@arizona
  530. Subject: Icon Newsletter
  531. Status: RO
  532.  
  533. The Icon Newsletter is published aperiodically, about three times a year.
  534. 11 issues have been published to date, the last in March.
  535. The next issue probably will come out in early July.
  536.  
  537. The Newsletter, as its title indicates, contains news related to Icon.
  538. Typical topics include new implementations, documents, and projects.
  539. A continuing feature of the Newletters is a `Programming Corner' that
  540. poses questions and offers solutions to various aspects of programming
  541. in Icon.
  542.  
  543. The Newsletter is distributed to interested persons, free of charge,
  544. via the Postal Service. There are presently about 500 subscribers.
  545. To subscribe, send your postal address to
  546.  
  547.    icon-project.arizona@rand-relay
  548.  
  549. At the present time, back issues of Newsletters #2-11 are available
  550. on request to new subscribers.
  551.  
  552.  
  553.     Ralph Griswold
  554.  
  555.  
  556. From mmdf Sun May 29 09:10:29 1983
  557. From: ralph at arizona
  558. To: icon-group@arizona
  559. Subject: Survey Results
  560. Status: RO
  561.  
  562. We have received 24 responses to the survey of group proficiency
  563. and interests in Icon.  (There currently are about 70 icon-group
  564. addresses, 7 of which are addresses for redistribution on other machines.)
  565. The responses are summarized below.
  566.  
  567. Question:
  568.      What is your familiarity with Icon? -- on a scale of 1 to 10,
  569.      graded roughly as follows:
  570.      
  571.         1 -- have heard of Icon, but that's about all
  572.                 .
  573.                 .
  574.                 .
  575.         5 -- generally knowledgeable about Icon and competent to
  576.              formulate simple programs
  577.                 .
  578.                 .
  579.                 .
  580.         10 -- Icon wizard
  581.  
  582. Responses:
  583.  
  584.       1:  xxxxxxxx
  585.       2:
  586.       3:  xx
  587.       4:  xxxx
  588.       5:  xxx
  589.       6:  xxx
  590.       7:  x
  591.       8:
  592.       9:  x
  593.      10:  xx
  594.  
  595. Note:  the 9s and 10s are all "locals" at Arizona.
  596.  
  597.  
  598. Question:
  599.      What discussion topics most interest you?
  600.  
  601. Responses:
  602.      The responses were varied in format and specificity.  They have
  603.      been categorized below as accurately as possible, but some
  604.      may have been misinterpreted.
  605.      
  606.      idioms and programming techniques         16
  607.      general applications                       8
  608.      language design issues                     6
  609.      implementation issues                      6
  610.      theoretical aspects                        6
  611.      program exchange                           5
  612.      comparison with other languages            3
  613.      portability                                3
  614.      program design                             3
  615.      AI applications                            2
  616.      bugs                                       2
  617.      documentation                              2
  618.      history                                    2
  619.      implementation news                        2
  620.      string manipulation                        2
  621.      tools in or for Icon                       2
  622.      wish lists                                 2
  623.      efficiency                                 1
  624.      Icon as an embedded language               1
  625.      programming environments for Icon          1
  626.  
  627.  
  628.                 - Ralph Griswold
  629.  
  630.  
  631. From mmdf Wed Jun  1 18:38:26 1983
  632. From: David Vinayak Wallace <Gumby@MIT-OZ>
  633. Reply-To: Gumby at MIT-MC
  634. To: icon-group.arizona@Rand-Relay
  635. Status: RO
  636.  
  637. Does anyone know of an implementation on Icon which runs under TOPS-20?
  638. Any pointers would be appreciated.
  639.  
  640. david
  641.  
  642.  
  643.  
  644. From mmdf Fri Jun  3 13:55:20 1983
  645. From: whm at arizona
  646. Date-Sent: 3 Jun 83 13:53:07 MST  (Fri)
  647. Subject:  Icon for TOPS-20
  648. To: gumby@mit-mc
  649. Cc: icon-group@arizona
  650. Status: RO
  651.  
  652. There is a Version 2 Icon system available from us that runs under
  653. TOPS-10.  It is a Ratfor implementation, so in addition to V2/V5
  654. language differences, it is not very fast.  This system has been
  655. brought up under TOPS-20.  There were allegedly some minor problems
  656. related to i/o on TOPS-20, but we don't have the details at hand.
  657. This system is available from us via tape (BACKUP format) for no
  658. charge, or for $15, we'll supply a tape.
  659.  
  660. There has been some interest in porting the C implementation to
  661. 10's and 20's, but the problem of sizeof(char *) not being equal
  662. to sizeof(int *) may cause severe problems.  We also aren't aware of
  663. a 10 or 20 C compiler that supports assignment and call-by-value 
  664. for structures, and Icon uses quite a bit of that.
  665.  
  666.                     Bill Mitchell
  667.  
  668.  
  669. From mmdf Fri Jun  3 14:21:26 1983
  670. From: whm at arizona
  671. Date-Sent: 3 Jun 83 14:19:01 MST  (Fri)
  672. Subject:  write(a,b) vs. write(a||b)
  673. To: icon-group@arizona
  674. Status: RO
  675.  
  676. Regarding the question of whether it's more efficient to say
  677.  
  678.     write(s1,s2,...,sn)    [1]
  679. or
  680.     write(s1||s2||...||sn)    [2]
  681.  
  682. The former is more efficient and is the suggested way to accomplish
  683. the task.  The write function deals with each argument in turn,
  684. writing it to the output file.  If an argument is a string, it
  685. can work with it directly, otherwise it converts it to a string
  686. and then writes it.  In [2], Icon computes
  687.     t := s1 || s2
  688.     t := t || s3
  689.     ...
  690.     t := t || sn
  691. and then does
  692.     write(t)
  693. For each concatenation, a new string is allocated for the result.
  694. So, in addition to performing the concatenation operation itself,
  695. there is garbage collector overhead.  In [1], no operations are
  696. performed, and there is no storage allocation unless some of the
  697. si need to be converted to strings.
  698.  
  699. So, the general answer is that [1] is a big winner.  However, we tried
  700. some timings and found that for short strings, in particular, the
  701. example given by trh@arizona, the performance of the two is about the
  702. same.  This seems to indicate that the time consumed by concatenation
  703. and allocation of intermediate results is insignificant in relation
  704. to other activities taking place.
  705.  
  706.                     Bill Mitchell
  707. p.s.
  708. That was a good question, I remembering wondering the same thing
  709. at one time.
  710.  
  711.  
  712. From mmdf Fri Jun  3 23:40:28 1983
  713. From: Guy.Steele@CMU-CS-A
  714. Subject: Icon forTOPS-20
  715. To: icon-group.arizona@rand-relay
  716. Status: RO
  717.  
  718. Thank you for your message.  I might be interested in looking at the
  719. problem of porting a C version to the -20.  Also, I would be interested
  720. in a C version for the VAX.  (By the way, the header on the
  721. mail I received claimed it was sent to "GUMBY@MC", who is definitely
  722. not me.  Strange.)
  723. --Thanks,
  724.   Guy Steele
  725. From mmdf Sat Jul 16 04:56:19 1983
  726. Date: 16 Jul 1983 04:54:53-PST
  727. From: whm at arizona
  728. Date-Sent: 16 Jul 83 04:54:52 MST  (Sat)
  729. Subject:  Icon on USG UNIX
  730. To: icon-group@arizona
  731.  
  732. We would like to know if anyone has installed Icon on a USG (e.g.
  733. System III or System V) UNIX system.  We thought that someone
  734. had probably already done this and had encountered no problems, but
  735. we have just dealt with a stream of problems from someone trying
  736. to install Icon on a System V VAX.  So, if you've already hacked
  737. through an Icon installation on a USG system, we'd like to hear
  738. from you.
  739.  
  740. While I'm here, I'll give an unofficial report on the status of our
  741. "Icon on a 68000" project.  We appear to have located a 68000 system
  742. (a Pixel) whose management will let us use to port Icon to.  The
  743. Pixel is currently waiting on software but as soon as that arrives
  744. we hope to begin a port.
  745.  
  746.                     Bill Mitchell
  747.  
  748.  
  749. From mmdf Mon Aug  1 21:44:27 1983
  750. From: whm at arizona
  751. Date-Sent: 1 Aug 83 21:42:15 MST  (Mon)
  752. Subject:  Version 5.8 of Icon
  753. To: icon-group@arizona
  754. Status: RO
  755.  
  756. Version 5.8 of Icon is now being distributed.  The new version corrects
  757. several bugs in 5.7 and also has a link directive that specifies
  758. ucode (.u1 and .u2) files to be included when linking.  For example,
  759.  
  760.     link funcs1,"../lib/io"
  761.  
  762. in an Icon program causes the corresponding ucode files to be included
  763. when the program is linked.  A search path can be used to cause
  764. the linker to check several directories in turn for a named file.
  765.  
  766. Included with Version 5.8 is the Icon Program Library which consists of
  767. Icon programs, procedures, and external functions.  The library is quite
  768. diverse and covers a wide range of application areas.  A document,
  769. TR 83-6, describing the library in UNIX manual style is available
  770. on request.
  771.  
  772. Work has been done on the source code for Version 5.8 to make it easier
  773. to port to UNIX environments.  A document, "Porting the UNIX Implementation
  774. of Icon" (TR 83-10), which endeavors to illuminate the porting process,
  775. is available on request.  In addition, a small test suite has been
  776. prepared to be used in conjunction with TR 83-10.
  777.  
  778. Version 5.8 can be configured for VAX or PDP-11 (split I/D) UNIX systems.
  779. It has been tested under 4.1bsd and V7.  USG UNIX systems have been taken
  780. into consideration and while we know of no Icon systems running under
  781. USG UNIX, we believe that Icon could be brought up under one with little
  782. effort.
  783.  
  784. To obtain Version 5.8, send a check for $15 or tape at least 600 feet long
  785. to:
  786.     Icon Project
  787.     Department of Computer Science
  788.     University Computer Center
  789.     The University of Arizona
  790.     Tucson, AZ  87521
  791.  
  792. Please indicate (where appropriate):
  793.  
  794.     Name
  795.     Address
  796.     Telephone
  797.     Electronic mail address
  798.     Desired tape density (800 or 1600 bpi)
  799.  
  800. If hardcopy and software related to porting Icon are desired, please
  801. indicate that as well.
  802.  
  803. The following new documents are available in hardcopy form:
  804.  
  805.     Implementations of Icon
  806.     Differences Between Versions 2 and 5 of Icon (TR 83-5)
  807.     The Icon Program Library (TR 83-6)
  808.     Porting the UNIX Implementation of Icon (TR 83-10)
  809.     Co-Expressions in Icon, reprinted from Computer Journal
  810.     Programmer-Defined Control Operations, reprinted from Computer Journal
  811.  
  812. To request documents, send a letter via the postal service to the above
  813. address, or send a message to icon-project.arizona@rand-relay.  Be sure
  814. to include a return postal address.
  815.  
  816. Icon Newsletter #12 has been mailed.  Persons on the Newsletter mailing list
  817. should receive a copy soon.  This Newsletter contains forms for requesting
  818. Version 5.8 of Icon and the documents listed above.
  819.  
  820.                     Bill Mitchell
  821.  
  822.  
  823. From mmdf Tue Aug  2 18:41:22 1983
  824. From: glenn@Uwisc (Glenn Blank)
  825. Subject:  Version 5.8 of Icon
  826. Reply-To: glenn@Uwisc
  827. To: icon-group.arizona@Rand-Relay, whm.arizona@Rand-Relay
  828. Status: RO
  829.  
  830. Please send me your document on The Icon Program Library, TR 83-6.
  831. My address is:
  832.   Glenn D. Blank
  833.   101-I Eagle Heights
  834.   Madison, WI 53705
  835. Thanx.
  836.  
  837.  
  838. From mmdf Wed Aug 17 18:44:23 1983
  839. From: Charlotte Mooers <mooers@BBN-UNIX>
  840. Subject: Please add me to the Icon-Group mailing list.
  841. To: Icon-Group%Arizona@Rand-Relay
  842. Cc: Mooers@BBN-UNIX
  843. Status: RO
  844.  
  845. Thanks.  Charlotte
  846. .
  847.  
  848.  
  849.  
  850. From mmdf Wed Aug 17 18:46:49 1983
  851. From: Charlotte Mooers <mooers@BBN-UNIX>
  852. Subject: My previous request to be added to Icon-Group 
  853. To: Icon-Group%Arizona@Rand-Relay
  854. Cc: Mooers@BBNA
  855. Status: RO
  856.  
  857. Better send the messages to MOOERS@BBNA.
  858. Thanks.
  859. ---Charlotte
  860.  
  861.  
  862.  
  863. From mmdf Mon Aug 29 18:42:19 1983
  864. From: Robert E. Wells <rwells@bbn-unix>
  865. Subject: Equality for reals...
  866. To: icon-group.arizona@rand-relay
  867. Cc: rwells@bbn-unix
  868. Status: RO
  869.  
  870. Equality comparisons on real numbers are notoriously untrustworthy on most
  871. systems.  Numbers which print out identically, and which were produced by
  872. intuitively equivalent operations, may differ in the least significant
  873. bits of the mantissa.  Has anyone considered incorporating range checking
  874. into the equality test itself?  I have in mind defining
  875.  
  876.     n = m
  877.  
  878. for real n or m to be equivalent to
  879.  
  880.     abs(n - m) < &epsilon
  881.  
  882. where &epsilon is a keyword, initially set to some very small positive
  883. value.
  884.  
  885. The issue of value comparison is discussed in section 10.1 of the Icon
  886. manual; it gives the example that
  887.  
  888.     (1 - 1) = (2 - 2)
  889.  
  890. is true due to the uniqueness of integer numbers.  I am much less certain
  891. that
  892.  
  893.     (3.5 - 2.5) = (17.5 - 16.5)
  894.  
  895. is true, even though that is perhaps implied in section 10.1.  The
  896. &epsilon scheme is a way of making real numbers act more the way you
  897. expect.  I would expect that
  898.  
  899.     n === m
  900.  
  901. would be defined to succeed only if the real values n and m were exactly
  902. the same, having the same bit pattern.
  903.  
  904. I am considering making this change to RPL, the command and programming
  905. language for RS/1, a decision support system for research scientists.  RPL
  906. is similar to Icon in having variables that can have values of many
  907. different types and providing appropriate conversions between them; it is
  908. used more for numeric and statistical applications than for text
  909. processing.  We have had several calls lately from users who not
  910. unreasonably expect the real numbers in their programs to behave like
  911. mathematical real numbers; after explaining some of the subtleties of
  912. floating point represention several times, I have started wondering if I
  913. could avoid some calls by making 'reals' act more like real numbers.  Do
  914. programmable calculators address this issue?  I would appreciate your
  915. views, particularly if there is a fatal flaw.  -Thanks, Robert
  916.  
  917.  
  918.  
  919. From sdcsvax!davidson Tue Aug 30 07:38:12 1983
  920. From: Greg Davidson  <sdcsvax!davidson>
  921. Subject: Equality for reals
  922. To: icon-group.arizona@rand-relay
  923. Status: RO
  924.  
  925. When doing floating point calculations by hand, one commonly maintains
  926. a precision associated with each value, modifying it appropriately as
  927. one performs calculations.
  928.  
  929. If this could be automated appropriately, it would solve several
  930. problems, including the equality question, but also the question of how
  931. many digits to show when printing real values.
  932.  
  933. If there are no mathematical problems with doing this, the precision
  934. could be determined on input, by the number of digits used to express
  935. the quantity.  An obvious optimization is to use a single precision
  936. value for collections of floating point numbers, where possible.
  937.  
  938. Well numerical analysts, is this possible?
  939.  
  940. -Greg
  941.  
  942. P.S.  I realize I'm guilty too, but do we have to call them real
  943. numbers when they aren't?  Lets call them floats!
  944.  
  945.  
  946.  
  947. From mmdf Tue Aug 30 17:24:53 1983
  948. From: greep@SU-DSN
  949. Subject: Re: Equality for reals...
  950. To: Robert E. Wells <rwells@BBN-UNIX>
  951. Cc: icon-group.arizona@RAND-RELAY
  952. In-Reply-To: Your message of 29 Aug 1983 14:06:26 EDT (Monday).
  953. Status: RO
  954.  
  955. Some people may be surprised at an equality relation which is
  956. non-transitive.
  957.  
  958.  
  959. From mmdf Tue Aug 30 22:34:09 1983
  960. From: whm at arizona
  961. Date-Sent: 30 Aug 83 22:30:51 MST  (Tue)
  962. Subject:  Re:  Equality for reals...
  963. To: icon-group@arizona
  964. Status: RO
  965.  
  966. The root of the problem is that computers can't exactly represent
  967. floating point numbers, they just represent approximations of them.
  968. That's pretty obvious, but less obvious is that floating point
  969. operations aren't always associative.  Because of the approximate
  970. nature of floating point math, having an approximate comparison seems
  971. reasonable to me.
  972.  
  973. A problem I see with &epsilon is that of picking the initial value
  974. of it.  Are there other languages with a similar concept?  (APL?)
  975. How do they pick their "little" value?
  976.  
  977. Calculators seem to be pretty smart about operations with real numbers;
  978. is that because they use lots of bits in their number representations?
  979.  
  980.  
  981. This is a bit off track, but in Icon,
  982.     x === y
  983. is just like x = y if x and y are real.  The equivalence operation is
  984. most often used (by me) for things like
  985.     x === 1
  986. to see if x is the integer 1 without first having to see if x is an
  987. integer, e.g.
  988.     integer(x) = 1
  989.  
  990.                     Avoiding real numbers,
  991.                     Bill Mitchell
  992.  
  993.  
  994. From mmdf Wed Aug 31 01:27:08 1983
  995. From: trh at arizona
  996. Date-Sent: 31 Aug 83 01:23:35 MST  (Wed)
  997. To: icon-group@arizona
  998. Status: R
  999.  
  1000. In response to rwells@bbn-unix:
  1001.  
  1002. Your keyword &epsilon seems to be a close cousin of APL's Quad-CT
  1003. system variable. Assignment to Quad-CT allows the user to specify the
  1004. "comparison tolerance"; the proportion by which two value may differ
  1005. and still be considered "equal". A good discussion of this is found in
  1006. Chapter 14 of the Sharp APL Reference Manual by Paul Berry of I. P.
  1007. Sharp Associates.  You may wish to look into this as you implement
  1008. your own version. Good luck. -tom hicks (trh@arizona).
  1009.  
  1010. From mmdf Wed Aug 31 07:40:06 1983
  1011. From: Guy.Steele@CMU-CS-A
  1012. Subject: Equality for reals
  1013. To: icon-group.arizona@rand-relay
  1014. Cc: rwells@bbn-unix
  1015. Status: R
  1016.  
  1017. Defining
  1018.         n = m
  1019. for floating-point n and/or m to be equivalent to
  1020.         abs(n - m) < &epsilon
  1021. is not a very good idea.  For very small m and n, the difference
  1022. may always be less than &epsilon, and for very large m and n,
  1023. no matter how close together, the difference may always be greater
  1024. than &epsilon.  A somewhat better definition is
  1025.         abs(n - m) < &epsilon * max (abs(m), abs(n))
  1026. I recommend that you take a look at what APL does, inasmuch as
  1027. APL provides such "fuzzy" comparisons, and APL implementors have
  1028. worried a great deal over the proper definition.  See the various
  1029. APL conference proceedings, in particular part 2 of the APL '79
  1030. conference, which is a complete proposed standard APL definition.
  1031. --Guy Steele
  1032.  
  1033. From mmdf Wed Aug 31 07:50:41 1983
  1034. From: David Vinayak Wallace <GUMBY%MIT-OZ@MIT-MC>
  1035. Subject: Equality for reals...
  1036. To: whm.arizona@Rand-Relay
  1037. Cc: icon-group.arizona@Rand-Relay
  1038. Reply-To: Gumby@mit-mc
  1039. In-Reply-To: Msg of 31 Aug 1983  02:30-EDT from whm.arizona at Rand-Relay
  1040. Status: R
  1041.  
  1042.     Date: Wednesday, 31 August 1983  02:30-EDT
  1043.     From: whm.arizona at Rand-Relay
  1044.  
  1045.             ...but less obvious is that floating point
  1046.     operations aren't always associative.  Because of the approximate
  1047.     nature of floating point math, having an approximate comparison seems
  1048.     reasonable to me.
  1049.  
  1050.     A problem I see with &epsilon is that of picking the initial value
  1051.     of it.  Are there other languages with a similar concept?  (APL?)
  1052.     How do they pick their "little" value?
  1053.  
  1054. Isn't this is architecture- (i.e. word-length-) dependent? Shouldn't
  1055. it be one half of the roundoff error?
  1056.  
  1057.     Calculators seem to be pretty smart about operations with real numbers;
  1058.     is that because they use lots of bits in their number representations?
  1059.  
  1060. My HP uses BCD to 14 significant places, and then displays 11.  You
  1061. don't notice problems unless you do a LOT of remultiplies.
  1062.  
  1063. What about using rationals (i.e. carry out the numerator and
  1064. denominator as long as possible)?  After all, irrationals don't exist
  1065. on a machine with a finite word length.
  1066.  
  1067. david
  1068.  
  1069.  
  1070. From mmdf Wed Aug 31 18:40:57 1983
  1071. From: Andy Cromarty <andy@aids-unix>
  1072. Subject: floating-point number comparisons
  1073. To: icon-group.arizona@rand-relay
  1074. Status: R
  1075.  
  1076.   I have worked in several LISP dialects wherein "flonum" equality
  1077. is approximate.  A function named "eqn" was defined such that
  1078. (eqn f1 f2) was true just in case (lessp (abs (difference f1 f2)) *fuzz),
  1079. i.e. just in case the (absolute value of the) difference between the
  1080. floating point numbers was less than some standard "fuzz-factor" variable.
  1081. The variable had a default value more or less consistent with the
  1082. architecture of the machine but was changeable by the user.  (There are
  1083. attendant pitfalls, of course, such as setting it absurdly large or
  1084. setting it to different values in different contexts, but that sort
  1085. of flexibility is arguably a part of the LISP philosophy.)
  1086.  
  1087.   Note that setting *fuzz to 0.0 enforces "strict equality", insofar as
  1088. the machine allows.
  1089.  
  1090. The note about the non-transitive nature of equality comparisons under such
  1091. a scheme bears some scrutiny.  As a rule, contemporary architectures do not
  1092. guarantee transitivity of equality once algebraic transformations are taken
  1093. into account, and when they do it is pathological -- for example, zero often
  1094. is "more equal to itself" than other values due to its ubiquity and precise
  1095. representation in many machines.  An explicit treatment of this pathology by
  1096. the language designer simply allows the programmer to control the
  1097. interference induced by the architecture to some extent rather than
  1098. uniformly victimizing him/her by it.
  1099.  
  1100.                         asc
  1101.  
  1102. From mmdf Wed Aug 31 23:45:52 1983
  1103. From: hilfingr%ucbkim@Berkeley (Paul Hilfinger)
  1104. Subject: Approximate equality of reals
  1105. To: icon-group.arizona@rand-relay
  1106. Status: R
  1107.  
  1108.  
  1109. I've consulted The Expert on this subject, with the following results:
  1110.  
  1111. First, I think I know what Robert Wells meant by saying that ``Equality
  1112. comparisons of real numbers are notoriously untrustworthy,'' but I'm not
  1113. positive.  Let me just throw out some facts to be sure; pardon me if they're
  1114. obvious.  The floating point equality operator is absolutely trustworthy;
  1115. x=y iff x and y are exactly the same quantity.  The problem is that because
  1116. the various other floating point operators yield approximations to what we
  1117. ``really intend''--to the mathematically correct answers--the result of
  1118. comparing their results with each other don't always yield what we really
  1119. intend.
  1120.  
  1121. By the way (re: comment by Greg Davidson), they most certainly ARE real
  1122. numbers!  The problem is that +, -, *, /, etc., don't have their mathematical
  1123. meanings.  The situation was clearer in Bliss, e.g., where the floating
  1124. point operators had a different appearance.
  1125.  
  1126. All right, so much for trivial quibbling.  Actually, the first quibble isn't
  1127. so trivial.  There are cases in which it is, in fact, essential that =
  1128. really mean = (that is, strict equality of the computed operands).  If you
  1129. want, I can bug my Expert for an example.  In other words, strict equality
  1130. of real quantities is a computationally legitimate operation, and since one
  1131. is going to need it from time to time, it seems confusing at best to usurp
  1132. the standard notation for it, especially when the replacement has such
  1133. radically different semantics.  For clarity, the proposed comparison should
  1134. be given a distinctive syntax (it's unfortunate that ~= has been pre-empted
  1135. in Icon; that would have been my choice.)
  1136.  
  1137. Next, we come to the real substantive difficulty.  There simply is no
  1138. sensible general definition of ``nearly equal.''  Sometimes one might want
  1139. ``absolute difference less than epsilon'' (and epsilon might vary).  For
  1140. other applications one might need ``relative difference less than epsilon.''
  1141. There are still more exotic metrics that make perfect sense for certain
  1142. applications.  All of these have an equal right to the title ``approximate
  1143. equality'' and all are totally useless for some applications.  One can, of
  1144. course, define the syntax for ``nearly equal'' and then allow the user to
  1145. supply his own definition (perhaps with a default definition supplied by the
  1146. system).  This bothers me as a language designer.  Either one has a language
  1147. that allows user definition of operators--in which case you needn't make any
  1148. special provision for defining a ``nearly equal'' operator--or you have a
  1149. language that does not allow such user definitions--in which case the
  1150. ``nearly equal'' operator would be the only operator whose definition was
  1151. set by the user and could not be relied upon to have the same meaning from
  1152. program to program.  The APL route (a fixed definition of ``near equality''
  1153. that is parameterized by epsilon) has its own additional problems; setting
  1154. appropriate values of epsilon at the right points is quite clumsy, not to
  1155. mention the oddity of a harmless-looking comparison operator whose
  1156. definition depends on a global variable.  In practice, APL's definition of
  1157. equality is hard to use correctly.
  1158.  
  1159. The idea of doing ``significance arithmetic'' (mentioned by Greg Davidson)
  1160. has been tried before.  Unfortunately, it can be horribly conservative in
  1161. some cases (reporting that a certain quantity has only 3 significant figures
  1162. when it really has 6, for example.)  A big part of the problem is that
  1163. saying that something has n significant digits (even binary digits) is a
  1164. very course measure of its accuracy, causing one to overstate the errors
  1165. involved.  Another technique is interval arithmetic.  Again, this can give
  1166. overly-conservative results.  Of course, both of these techniques cost
  1167. performance.
  1168.  
  1169. To summarize: (1) strict equality comparison of real quantities is a
  1170. legitimate operation; therefore, there seems to be no reason to redefine the
  1171. standard notation `='; (2) there seems to be no definition for ``nearly
  1172. equal'' that is widely enough useful to justify its definition as a standard
  1173. operator.
  1174.  
  1175. --Paul Hilfinger
  1176.  
  1177.  
  1178.  
  1179. From mmdf Wed Sep 14 17:38:31 1983
  1180. From: whm at arizona
  1181. Date-Sent: 14 Sep 83 17:32:35 MST  (Wed)
  1182. Subject:  Icon for VAX/VMS
  1183. To: icon-group@arizona
  1184. Status: R
  1185.  
  1186. Version 5 of Icon is now available for VAX/VMS.  VMS Icon was developed
  1187. by Bob Goldberg with support from Datalogics, Inc. and is being
  1188. distributed by the University of Arizona.  VMS Icon does not include
  1189. the Icon compiler; it consists of only the interpretive system.
  1190.  
  1191. The distribution includes executable files, object modules, sample
  1192. programs, and the procedures from the Icon book.  The executable files
  1193. were produced on Version 3.2 of VMS.  Those with VAX-11 C should be
  1194. able to rebuild Icon from the object modules should the executable
  1195. files should happen to not work on a particular version of VMS.  We do
  1196. not have the facilities to rebuild the system and thus, it is being
  1197. distributed on "as-is" basis, i.e., if problems are encountered,
  1198. it may not be possible for us to provide a solution to them.
  1199.  
  1200. To obtain a copy of the system, specify the following where applicable:
  1201.  
  1202.     Your Name
  1203.     Address
  1204.     Organization
  1205.     Telephone
  1206.     Network Address
  1207.     Desired tape density (800 or 1600 bpi)
  1208.  
  1209. and send a tape at least 600 feet long (or check/money order for $15
  1210. payable to The University of Arizona) to:
  1211.  
  1212.     Icon Project
  1213.     Department of Computer Science
  1214.     The University of Arizona
  1215.     Tucson, AZ  85721
  1216.  
  1217.  
  1218. Please direct questions to icon-project.arizona@rand-relay
  1219.  
  1220.                     Bill Mitchell
  1221.  
  1222. From mmdf Fri Sep 23 00:39:33 1983
  1223. From: whm at arizona
  1224. Date-Sent: 23 Sep 83 00:33:58 MST  (Fri)
  1225. Subject:  Icon on System III or V UNIX?
  1226. To: icon-group@arizona
  1227. Status: R
  1228.  
  1229. If you know of an Icon system running on System III or System V,
  1230. please drop me a note.
  1231.  
  1232.                     Thanks,
  1233.                     Bill Mitchell
  1234.  
  1235. From mmdf Tue Oct 18 23:21:42 1983
  1236. From: whm at arizona
  1237. Date-Sent: 18 Oct 83 23:19:18 MST  (Tue)
  1238. Subject:  s/x/y/g in Icon
  1239. To: icon-group@arizona
  1240. Status: R
  1241.  
  1242. Something I've had often occasion to do in Icon is to change all
  1243. occurrences of one string to another.  I'm always fumbling around
  1244. over how to do it.  I was wondering if anybody has any "neat"
  1245. ways to do this.  More specifically, write
  1246.     
  1247.     change(line,pat,rep)
  1248.  
  1249. that changes all occurrences of the string 'pat' in the string 'line'
  1250. to the string 'rep' and returns the new string.
  1251.  
  1252. If you've got a "neat" (you decide on what's "neat") way to do it,
  1253. post it to the group.
  1254.  
  1255.                     Bill Mitchell
  1256.  
  1257. From mmdf Thu Oct 20 17:39:35 1983
  1258. From: jacobson@wisc-rsch (Fred M Jacobson)
  1259. Subject: change(line, pat, rep)
  1260. To: icon-group.arizona@rand-relay
  1261. Cc: jacobson@wisc-rsch
  1262. Status: R
  1263.  
  1264. Bill-
  1265.    Here's my "neat" solution.  I am taking "neat" to mean "tidy, orderly,
  1266. clean", "simple, plain, unadorned", and "well-designed, well-worked-out",
  1267. not "great, wonderful, marvelous" or "clever, ingenious".  (See The
  1268. Synonym Finder by J.I. Rodale, Rodale Press, 1978, a dictionary thesaurus.)
  1269.  
  1270. procedure change(line, pat, rep)
  1271. # Change every occurrence of the string `pat' in the string `line'
  1272. # to the string `rep', and return the changed string.
  1273.    local n, result, p
  1274.    (line := string(line) & pat := string(pat) & rep := string(rep)) | fail
  1275.    n := *pat
  1276.    result := ""
  1277.    while p := find(pat, line) do {
  1278.       result ||:= line[1+:p-1] || rep
  1279.       line := line[p+n:0] }
  1280.    return result || line
  1281. end
  1282.  
  1283.    The "interesting" part of the problem is the "find" function.  A section
  1284. of Alfred V. Aho's paper, Pattern Matching in Strings, discusses efficient
  1285. algorithms.  I have a copy of the paper, but no citation.  Aho presented
  1286. the paper in December 1979.  I assume it appeared in 1980 or 1981, perhaps
  1287. in the JACM.
  1288. -Fred
  1289.  
  1290. From mmdf Fri Oct 21 19:35:04 1983
  1291. From: Mark Feldman <feldman%umcp-cs@CSNet-Relay>
  1292. Return-Path: <feldman%umcp-cs@CSNet-Relay>
  1293. Subject:  change (line, pat, rep)
  1294. To: icon-group.arizona@rand-relay
  1295. Status: R
  1296.  
  1297. Fred's solution to the change problem is neat, but it could be neater.
  1298. The one problem I have with it is that it changes the original line.
  1299. A function such as change should return a new string, leaving the
  1300. original as it was.  Here's my version:
  1301.  
  1302.  
  1303. procedure change (line, pat, rep)
  1304.  
  1305.   # returns a string consisting of <line> with all occurrences of <pat>
  1306.   # changed to <rep>
  1307.   
  1308.   local patlen, place, start, result
  1309.   
  1310.   (line := string (line) & pat := string (pat) & rep := string (rep)) | fail
  1311.   start := 1
  1312.   patlen := *pat
  1313.   result := ""
  1314.   while place := find (pat, line, start, 0) do {
  1315.     result ||:= line [start:place] || rep
  1316.     start := place + patlen }
  1317.   result ||:= line [start:0]
  1318.   return result
  1319. end
  1320.   
  1321.   
  1322. This version should also be a bit more efficient since it keeps track of
  1323. where it is in line by using a counter and not by taking substrings.
  1324. Someone once said (or should have) "The best algorithm is only as efficient 
  1325. as its implementation."  So people, let's be careful out there... (eh?)
  1326.  
  1327.  
  1328.   Mark Feldman
  1329.  
  1330.   UUCP : {seismo,allegra,brl-bmd}!umcp-cs!feldman
  1331.   CSNet: feldman@umcp-cs
  1332.   Arpa : feldman.umcp-cs@CSNet-relay
  1333.  
  1334. From mmdf Fri Oct 21 20:11:58 1983
  1335. From: whm at arizona
  1336. Date-Sent: 21 Oct 83 20:07:03 MST  (Fri)
  1337. Subject:  change(...)
  1338. To: icon-group@arizona
  1339. Status: R
  1340.  
  1341. Here's what I came up with:
  1342.  
  1343.     procedure change(line,pat,rep)
  1344.         rx := 0
  1345.         every p := find(pat,line) do {
  1346.             line[(p+rx)+:*pat] := rep
  1347.             rx +:= *rep - *pat
  1348.             }
  1349.         return line
  1350.     end
  1351.  
  1352. Note that the size calculations can be moved out of the loop.  I guess
  1353. that the "trick" here (if any) is the in-place substitution.  Also note
  1354. that although line is being modified in the procedure, the value used
  1355. as the parameter is not_ changed.  You may have noticed that the loop
  1356. can be replaced by:
  1357.  
  1358.     every line[(find(pat,line)+rx)+:*pat] := rep do
  1359.         rx +:= *rep - *pat
  1360.  
  1361. I don't know which of the three versions submitted would be the fastest;
  1362. if I get a chance I'll try some timings.
  1363.  
  1364. Any more solutions?  How about something recursive?
  1365.  
  1366.                     Bill Mitchell
  1367.  
  1368. From mmdf Sun Oct 23 07:41:11 1983
  1369. From: Mark Feldman <feldman%umcp-cs@CSNet-Relay>
  1370. Return-Path: <feldman%umcp-cs@CSNet-Relay>
  1371. Subject:  Bug in my change
  1372. To: icon-group.arizona@rand-relay
  1373. Status: R
  1374.  
  1375. Hey guys, there's a bug in my change procedure.  It seems that if <pat> is
  1376. the null string my procedure loops (infinitely).  Adding the line
  1377.  
  1378.   pat ~== "" | return line
  1379.  
  1380. before the main loop remedies the problem.  Here's the correct version:
  1381.  
  1382.  
  1383. procedure change (line, pat, rep)
  1384.  
  1385.   # returns a string consisting of <line> with all occurrences of <pat>
  1386.   # changed to <rep>
  1387.   
  1388.   local patlen, place, start, result
  1389.   
  1390.   (line := string (line) & pat := string (pat) & rep := string (rep)) | fail
  1391.   pat ~== "" | return line
  1392.   start := 1
  1393.   patlen := *pat
  1394.   result := ""
  1395.   while place := find (pat, line, start, 0) do {
  1396.     result ||:= line [start:place] || rep
  1397.     start := place + patlen }
  1398.   result ||:= line [start:0]
  1399.   return result
  1400. end
  1401.   
  1402.   
  1403. Sorry for sending something that wasn't completely tested.  It will never 
  1404. happen again :-).
  1405.  
  1406.   Mark Feldman
  1407.  
  1408.   UUCP : {seismo,allegra,brl-bmd}!umcp-cs!feldman
  1409.   CSNet: feldman@umcp-cs
  1410.   Arpa : feldman.umcp-cs@CSNet-relay
  1411.  
  1412. From mmdf Sun Oct 23 18:40:32 1983
  1413. From: Mark Feldman <feldman%umcp-cs@CSNet-Relay>
  1414. Return-Path: <feldman%umcp-cs@CSNet-Relay>
  1415. Subject:  change (line, pat, rep)
  1416. To: icon-group.arizona@rand-relay
  1417. Status: R
  1418.  
  1419. I have been having a problem with mail so I am resending my original solution
  1420. to the change problem as well as a newer recursive version.  My original
  1421. solution is based on Fred's "neat" solution.  I modified change so that it
  1422. keeps track of its location in line with a counter instead of taking
  1423. substrings.  This keeps the original line the same and increases speed since
  1424. integer math is usually faster then string manipulation.  So here it is:
  1425.  
  1426.  
  1427. procedure change (line, pat, rep)
  1428.  
  1429.   # returns a string consisting of <line> with all occurrences of <pat>
  1430.   # changed to <rep>
  1431.   
  1432.   local patlen, place, start, result
  1433.   
  1434.   (line := string (line) & pat := string (pat) & rep := string (rep)) | fail
  1435.   pat ~== "" | return line
  1436.   start := 1
  1437.   patlen := *pat
  1438.   result := ""
  1439.   while place := find (pat, line, start, 0) do {
  1440.     result ||:= line [start:place] || rep
  1441.     start := place + patlen }
  1442.   result ||:= line [start:0]
  1443.   return result
  1444. end
  1445.   
  1446.   
  1447. Here's a recursive version of change.  And while it may be "neater", it's also
  1448. slower:
  1449.  
  1450.  
  1451. procedure change (line, pat, rep)
  1452.  
  1453.   # a recursive procedure to return <line> with all occurrences of <pat>
  1454.   # changed to <rep>
  1455.  
  1456.   local place
  1457.  
  1458.   (line := string (line) & pat := string (pat) & rep := string (rep)) | fail
  1459.   line ~== "" | return line
  1460.   pat ~== "" | return line
  1461.   if place := find (pat,line) then 
  1462.     return line [1+:place-1] || rep || change (line [place+*pat:0],pat,rep)  
  1463.   else
  1464.     return line
  1465. end
  1466.  
  1467.  
  1468. --  Mark Feldman
  1469.  
  1470.     UUCP : {seismo,allegra,brl-bmd}!umcp-cs!feldman
  1471.     CSNet: feldman@umcp-cs
  1472.     Arpa : feldman.umcp-cs@CSNet-relay
  1473.  
  1474.  
  1475. From mmdf Mon Oct 24 02:34:21 1983
  1476. From: whm at arizona
  1477. Date-Sent: 24 Oct 83 02:27:17 MST  (Mon)
  1478. Subject:  tables
  1479. To: icon-group@arizona
  1480. Status: R
  1481.  
  1482. I'm in need of some background information for a report concerning
  1483. Icon tables and table programming techniques.
  1484.  
  1485. An Icon table allows the association of two arbitrary data values.
  1486. It appears that the first language to support such a capability
  1487. in any form was Lisp with "association lists".  It also appears that
  1488. SNOBOL4 was the first language to support "tables" as a separate
  1489. datatype.  Can anyone offer evidence to the contrary?  (I'm primarily
  1490. concerned about COMIT and IPL V since I know nothing about them.)
  1491.  
  1492. Also, I know that the following languages support some datatype similar
  1493. to Icon tables: AWK, SETL, and SNOBOL4.  Are there others?
  1494.  
  1495.                         Bill Mitchell
  1496.  
  1497. From mmdf Mon Oct 24 18:42:56 1983
  1498. From: Mark Feldman <feldman%umcp-cs@CSNet-Relay>
  1499. Return-Path: <feldman%umcp-cs@CSNet-Relay>
  1500. Subject:  change (one more time)
  1501. To: icon-group.arizona@rand-relay
  1502. Status: R
  1503.  
  1504. Here I go again.  This better get through.  Sorry for all the trashed mail,
  1505. but I think I've found my mail problem.  If my letter doesn't get through
  1506. this time, then the problem isn't with me (either that or I have chronic
  1507. problems :-) )
  1508.  
  1509. I have been having a problem with mail so I am resending my original solution
  1510. to the change problem as well as a newer recursive version.  My original
  1511. solution is based on Fred's "neat" solution.  I modified change so that it
  1512. keeps track of its location in line with a counter instead of taking
  1513. substrings.  This keeps the original line the same and increases speed since
  1514. integer math is usually faster then string manipulation.  So here it is:
  1515.  
  1516.  
  1517. procedure change (line, pat, rep)
  1518.  
  1519.   # returns a string consisting of <line> with all occurrences of <pat>
  1520.   # changed to <rep>
  1521.   
  1522.   local patlen, place, start, result
  1523.   
  1524.   (line := string (line) & pat := string (pat) & rep := string (rep)) | fail
  1525.   pat ~== "" | return line
  1526.   start := 1
  1527.   patlen := *pat
  1528.   result := ""
  1529.   while place := find (pat, line, start, 0) do {
  1530.     result ||:= line [start:place] || rep
  1531.     start := place + patlen }
  1532.   result ||:= line [start:0]
  1533.   return result
  1534. end
  1535.   
  1536.   
  1537. Here's a recursive version of change.  And while it may be "neater", it's also
  1538. slower:
  1539.  
  1540.  
  1541. procedure change (line, pat, rep)
  1542.  
  1543.   # a recursive procedure to return <line> with all occurrences of <pat>
  1544.   # changed to <rep>
  1545.  
  1546.   local place
  1547.  
  1548.   (line := string (line) & pat := string (pat) & rep := string (rep)) | fail
  1549.   line ~== "" | return line
  1550.   pat ~== "" | return line
  1551.   if place := find (pat,line) then 
  1552.     return line [1+:place-1] || rep || change (line [place+*pat:0],pat,rep)  
  1553.   else
  1554.     return line
  1555. end
  1556.  
  1557.  
  1558. --  Mark Feldman
  1559.  
  1560.     UUCP : {seismo,allegra,brl-bmd}!umcp-cs!feldman
  1561.     CSNet: feldman@umcp-cs
  1562.     Arpa : feldman.umcp-cs@CSNet-relay
  1563.  
  1564.  
  1565. From mmdf Sun Oct 30 23:41:56 1983
  1566. From: suz@LBL-CSAM (Suzanne O'Dell[Tourist])
  1567. Return-Path: <suz@LBL-CSAM>
  1568. Subject: Moved
  1569. To: whm.arizona@Rand-Relay
  1570. Cc: icon-group.arizona@Rand-Relay
  1571. Status: R
  1572.  
  1573. I have moved to the Washington DC area and I would like to keep
  1574. receiving the Icon newsletter.  I still have an account at LBL
  1575. for electronic mail (for now).  Will you be at the Wash. DC UNIX
  1576. conference in January?  I am still in the job hunting process
  1577. but I will have to send for an Icon tape when I have a computer
  1578. to put it on.  (On job applications with multiple choice boxes
  1579. for "what languages do you know" I write in Icon under "others"
  1580. and that gets them every time.)
  1581.  
  1582. New address for newsletter:
  1583.  
  1584. Suzanne O'Dell
  1585. 13221 Parson Lane
  1586. Fairfax, VA 22033
  1587. (703) 378 8574
  1588.  
  1589. Thanks,  Suz
  1590.  
  1591.  
  1592.