From mmdf Sun Jan 15 19:08:37 1984 From: whm at arizona Date-Sent: 15 Jan 84 19:06:08 MST (Sun) Subject: Icon on 4.2bsd To: icon-group@arizona Status: R As some of you may know, Icon is on 4.2bsd as user-contributed software. We've sort of lost contact with the people at Berkeley and we'd like to find out what versions of Icon have been distributed with 4.2bsd. If your Icon system came with 4.2bsd, we'd really appreciate it if you would run this program: procedure main() write(&version) end and mail the result to icon-project.arizona@rand-relay. Thanks, Bill Mitchell p.s. I'll be going to Usenix; if any of you are going and would like to talk about Icon, look me up. (I know there'll be about 4000 people there, but if you see someone in their mid-twenties about six feet tall with red hair, glasses, dark suit, a stack of resumes, and an Icon button, it's probably going to be me.) I'll be in DC the 16th-19th at the Hilton. From mmdf Tue Jan 24 18:39:44 1984 From: Michael Cerda Subject: Icon version number. Posted-Date: Tue, 24 Jan 84 16:07:47 CST To: icon-group.arizona@rand-relay Status: R I ran the described program and the results are included. Is the version of Icon that came with BSD4.2 different than the tape that says 5g version 5.8? cerda at ut-ngp procedure main() write(&version) end Icon, Version 5.7x compiler, March 1983 From mmdf Sun Feb 19 07:05:26 1984 From: ralph at arizona To: icon-group@arizona Subject: Icon Newsletter #14 Status: R Icon Newsletter #14 has been mailed to all persons on our Icon postal mailing list. It went out bulk rate to US addresses about three weeks ago, and should have been delievered by now. If you got a copy and haven't mailed back the questionnaire in it, please do so. If you didn't get a copy, but would like to, send us your postal address. Send requests to icon-project.arizona@rand-relay (not to icon-group, please) Ralph Griswold From mmdf Sun Apr 15 12:39:01 1984 From: Amir Razi To: Icon-Group.Arizona@csnet-relay.csnet Subject: Subscription Status: R Would you please add my name to receive ICON digests. My net address is: Razi@Udel Thank you. Amir M. Razi From mmdf Wed Apr 18 23:48:10 1984 From: MDC.WAYNE%MIT-OZ%mit-mc.arpa@csnet-relay.csnet Subject: MAILING LIST REQUEST To: ICON-GROUP.ARIZONA@csnet-relay.csnet cc: MDC.WAYNE%MIT-OZ%mit-mc.arpa@csnet-relay.csnet Status: R Please add my name to your mailing list. Wayne McGuire ------- From mmdf Fri May 4 23:27:54 1984 From: whm at arizona Date-Sent: 4 May 84 23:25:23 MST (Fri) Subject: Sets in Icon To: icon-group@arizona Status: R We are contemplating including a "set" data type in the next release of Icon and we are soliciting comments in this, the design stage. I guess the best way to describe what we have in mind is to ennumerate the language additions that we are planning. set([x1,x2, ..., xn]) Create a set from the elements of the list given as an argument. Duplicate elements will be eliminated. insert(s,x) Add x to the set s. Insert always succeeds and returns the value s. delete(s,x) Delete x from the set s. As with insert, delete always succeeds and returns the value s. x in s Succeeds if the set s contains x. seteqv(s1,s2) Succeeds if s1 and s2 contain the same elements. The cset operations ++, **, and -- will be extended to operate on sets. The prefix operators *, !, and ? and the type, copy, sort, and image functions will be extended to handle sets. That's about it. We're looking for questions and suggestions concerning any of the above constructs and any other constructs that might be worth having or not having. Bill Mitchell From mmdf Sun May 6 02:38:51 1984 From: Mark Weiser Subject: Re: Sets in Icon To: whm%arizona.csnet@csnet-relay.csnet, icon-group%arizona.csnet@csnet-relay.csnet Status: R In all my set programming I have found invaluable some fast way of iterating over sets. One way is to provide a remove-an-element function (which also returns the element as its value). One then programs an iteration like: tempset := realset while notempty(tempset) do element := remove-an-element(tempset); /* side-effect ! */ /* use element */ od Of course in clu with built in iterators it could be much cleaner. What would be the ICON way? From mmdf Mon May 7 17:57:30 1984 From: ralph at arizona To: icon-group@arizona Subject: Questionnaires Status: R I am presently compiling the results of questionnires that have been returned from Icon Newsletter #14. If you have not returned your questionnaire yet, please do so promptly if you want your answers included in the compilation. If you did not get Icon Newsletter #14 but would like one, send me a postal mailing address. Ralph Griswold icon-project.arizona@csnet-relay From mmdf Mon May 7 18:58:32 1984 From: Waiming Mok Subject: Concerning sets in ICON To: ICON-GROUP%ARIZONA.CSNET at CSNET-RELAY Reply-To: WMM at ACC Status: R Are sets going to allow inclusion of elements of different data types? or some restricted set of data types? If so, insert may have to indicate unsuccessful insertion. If an element does not exist in a set, delete may have to indicate unsuccessful deletion. At least mathematically, set operations are 1. taking union 2. taking intersections of sets 3. finding complement of a subset in another set 4. finding the cardinality of the set aside from the initial creation of a set, the first 3 operations may be used to replace insert and delete. Waiming Mok ------ From mmdf Mon May 7 20:58:39 1984 From: whm at arizona Date-Sent: 7 May 84 20:55:23 MST (Mon) Subject: Re: generation of set elements To: mark@umcp-cs Cc: icon-group@arizona Status: R Icon's element generation operator, !, will provide convenient iteration over elements of a set. To print out each element in a set s, one could say: every write(!s) !s generates the elements in sequence and these serve as arguments for successive calls to write. From mmdf Mon May 7 21:07:02 1984 From: whm at arizona Date-Sent: 7 May 84 21:04:00 MST (Mon) Subject: Re: Concerning sets in [Icon] To: WMM@ACC Cc: icon-group@arizona Status: R As is the presently the case with tables, sets will be able to hold any combination of types of elements. For example, x := set([set([1,2,3,[]]),table(2),'abc',"xyz"]) insert(x,x) will be perfectly valid. Some thought was given to having insert fail if the element being inserted already exists and having delete fail if the element being deleted didn't exist, but current thinking is that such semantics would cause more loss than gain because of problems with ambiguous failure. From mmdf Sun Jun 24 18:36:44 1984 From: ralph at arizona To: icon-group@arizona Subject: Icon Newsletter #15 Status: R Icon Newsletter #15 was mailed out last week. It goes bulkrate in the United States, so it may take a while to get to some places. Everyone who has been sent previous Icon Newsletters has been sent a copy of #15. Copies will be sent to others, free of charge, on request (be sure to include a postal address). From mmdf Mon Jun 25 16:18:32 1984 From: ralph at arizona To: icon-group@arizona Subject: Bug in the VAX/VMS Implementation of Version 5.8 Icon Status: R There is a storage allocation problem in the VAX/VMS implementation of Version 5.8 that can cause programs to run out of string or heap space after a file is opened. This is caused by the fact that VMS may allocate memory in the program's data space. VAX-11 C is smart enough to realize that this has happened, and it then prevents Icon's data space from growing. This problem is compounded by an incorrect space computation in the Icon storage management system that makes it think that it needs more space than it does. This problem can be circumvented by increasing the initial allocations of space for Icon's data regions. See the Icon HELP file. The bug can be fixed by adding IOSEGMENTS=32,NOP0BUFS to the linker options file and relinking Icon. From mmdf Mon Jul 2 18:40:31 1984 Resent-Date: Mon, 02 Jul 84 15:53:57 EDT Sender: postmaster%csnet-sh.arpa@csnet-relay.csnet ReSent-From: Postmaster@csnet-relay.csnet ReSent-To: icon-group%arizona@csnet-relay.csnet mooers-note: Mon, 02 Jul 84 15:52:47 EDT mooers-note: dist'ed to the 3 addressees From: CSNET-RELAY Memo Service Subject: Failed mail To: Orphanage Resent-Sender: postmaster@csnet-sh Status: R After 7 days (148 hours), your message could not be fully delivered. It failed to be received by the following address(es): icon @ Etl-Ai (queue: smtp) tbigham.es @ Parc-Maxc (queue: smtp) hfehling @ Usc-Eclc (queue: smtp) Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. Your message begins as follows: Received: From arizona.csnet by csnet-relay; 25 Jun 84 2:39 EDT Date: 24 Jun 1984 18:34:05-PST From: ralph at arizona To: icon-group@arizona Subject: Icon Newsletter #15 Icon Newsletter #15 was mailed out last week. It goes bulkrate in the United States, so it may take a while to get to some ... From mmdf Mon Jul 2 18:51:37 1984 Resent-Date: Mon, 02 Jul 84 16:28:39 EDT Sender: postmaster%csnet-sh.arpa@csnet-relay.csnet ReSent-From: Postmaster@csnet-relay.csnet ReSent-To: icon-group%arizona@csnet-relay.csnet mooers-note: Mon, 02 Jul 84 16:28:04 EDT mooers-note: reSent to the 3 addressees From: CSNET-RELAY Memo Service Subject: Failed mail To: Orphanage Resent-Sender: postmaster@csnet-sh Status: R After 7 days (153 hours), your message could not be fully delivered. It failed to be received by the following address(es): icon @ Etl-Ai (queue: smtp) tbigham.es @ Parc-Maxc (queue: smtp) hfehling @ Usc-Eclc (queue: smtp) Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. Your message begins as follows: Received: From arizona.csnet by csnet-relay; 25 Jun 84 21:39 EDT Date: 25 Jun 1984 16:16:17-PST From: ralph at arizona To: icon-group@arizona Subject: Bug in the VAX/VMS Implementation of Version 5.8 Icon There is a storage allocation problem in the VAX/VMS implementation of Version 5.8 that can cause programs to run out of string or heap ... From mmdf Wed Jul 4 18:21:17 1984 From: ralph at arizona To: icon-group@arizona Subject: Eunice Icon Status: R Version 5.8 Icon Now Available for Eunice Version 5.8 of Icon has been adapted to Eunice, a UNIX emulator that runs under VMS. The work was done by Mark Langley of Science Applications Inc. A copy of this implementation can be obtained, free of charge, by sending a 600' magnetic tape to Icon Project Department of Computer Science University of Arizona Tucson, AZ 85721 A check for $15, payable to University of Arizona, can be sent in lieu of a tape. Be sure to specify "Eunice Icon". From whm@arizona.CSNET Tue Sep 4 19:50:36 1984 From: whm@arizona.CSNET (Bill Mitchell) To: icon-group@arizona.CSNET Subject: A curious program Status: R Here's a program that doesn't do quite what it looks like it might at first glance. You may wish to ponder its behavior (and that of the translator). procedure main() while next := read() do write(next) end Kudos to Dave Burns for bumping into this. From whm Wed Sep 5 02:31:56 1984 From: whm (Bill Mitchell) To: icon-group-test Subject: this Status: R is a test From whm Wed Sep 5 02:33:34 1984 From: whm (Bill Mitchell) To: icon-group-test Subject: this Status: R is with foo. From whm@arizona.CSNET Wed Sep 5 02:43:52 1984 From: whm@arizona.CSNET (Bill Mitchell) To: icon-group-test@arizona.CSNET Subject: this Status: R is a test From whm@arizona.CSNET Wed Sep 5 02:59:18 1984 From: whm@arizona.CSNET (Bill Mitchell) To: icon-group@arizona.CSNET Subject: Mailing list switch Status: R I've just switched the Icon-Group mailing list over from MMDF to sendmail and rather than bore you with a test message to see if things still work, I'll pose you a puzzle: Give an expression that uses only relational operators and alternation that produces the smallest value among three integer-valued variables a, b, and c. From mark Thu Sep 6 22:25:45 1984 From: mark (Mark Langley) To: icon-group Subject: (longish) Parsing and Expression Evaluation Cc: janalee, rogerh, trh, wendt Status: R Conjecture for the day: I think that Icon should parse (or give the appearance of parsing) right-associative operators from right to left, rather than left-to right. Namely, instead of, for a := b := c producing := a := b c Where it has to derefence a and then check to see if it has changed a as a side effect; instead it should produce: := := a b c And just evaluate the tree with no further ado. It could do this by producing a "mirror-image parse tree" instead of the usual one... ie when, in left to right encountering of . a := b := c it could make a the rson (instead of left), and then do the same for a := . b := c Ie The (YACC) parsing machine would be the same, it would just produce the evaluation tree backwards. Am I missing something? We didn't go over the parser in much detail in 620, so I may have misinferred the point of how it uses YACC... From whm@arizona.CSNET Sat Sep 8 01:04:39 1984 From: whm@arizona.CSNET (Bill Mitchell) To: mark@arizona.CSNET Subject: Re: (longish) Parsing and Expression Evaluation Cc: icon-group@arizona.CSNET Status: R It seems like what you're proposing is to alter the strict left-right evaluation order to avoid implementation difficulties. I think the actual problem that you'd run into with your scheme is that when parsing an assignment expression, you don't really know that you've got an assignment until code has been generated for the lhs. The solution would be to have the assignment operator assign the lhs to the rhs, e.g.: 1 + 2 =: x (Just kidding folks!) From ralph@arizona.CSNET Sat Sep 8 06:18:17 1984 From: ralph@arizona.CSNET (Ralph Griswold) To: icon-group@arizona.CSNET Subject: Version 5.9 of Icon Status: R Version 5.9 of Icon for PDP-11s and VAXs running under UNIX is now available. The main features of this version are: There is an optional language extension that provides sets and set operations. The Icon compiler has been removed, leaving only the interpreter. A "personalized interpreter" facility has been added to allow individuals to maintain customized versions of the Icon run-time system. This facility replaces the former use of external functions with the compiler. The implementation of the table data type has been redone to increase the efficiency of table lookup. The source code has been commented extensively and considerable work has be done throughout the Icon system to improve the quality of the code and to remove nonportable constructs. Several minor bugs have been fixed also. The Icon program library has been reorganized and new material has been added to it. The distribution hierarchy has been reorganized and new material has been added to aid in testing and porting to other computers. Version 5.9 of Icon is in the public domain. Program material and documentation is provided without charge. To obtain a copy, format the t/nroff text following the dashed line using -ms and mail it to us as indicated. -------------------------------------------------------------------- .nr LL 6.5i .ds CF .de LE \l'3.9i' .sp 1 .. .de Ip .IP "\\$1" 25 .LE .. .LP .ce 1 \f3Version 5.9 UNIX Icon Distribution Request\fR .sp 2 \fINote:\fR This system can be configured for PDP-11s with separate I and D spaces or VAX-11s. .sp 1.5 Contact Information: .sp 1 .Ip name .Ip address .LE .LE .LE .Ip telephone .Ip "electronic mail address" .sp 1 .Ip computer .Ip "operating system" .sp 1 .LP All tapes are written in 9-track \fItar\fR format. Preferred tape recording density: .sp 1 \(sq 1600 bpi\h'|1.8i'\(sq 800 bpi .sp 1.2 Return this form to: .DS Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 .DE Enclose a magnetic tape (at least 600\(fm) \fIor\fR a check for $15 payable to the University of Arizona. From whm@arizona.CSNET Tue Sep 18 01:26:27 1984 From: whm@arizona.CSNET (Bill Mitchell) To: icon-group@arizona.CSNET Subject: Tricky expressions and curious programs Status: R I posted a note a couple of days ago about a program with confounding behavior. The program went something like: procedure main() sum := 0 while next := read() do sum +:= next end At first glance, it looks like the program computes the sum of a set of numbers. However, when the program is run, it just loops, not reading anything from standard input. When I first looked at this, I noted that this program uses "next", a reserved word, as a variable. My first reaction was that this was a horrendous translator error; a reserved word was being accepted as a variable. I then realized that since there are no statements in Icon, just expressions, "next" was being treated as an expression. Thus, while the program parses as one would expect, the evaluation of "next := read()" causes control to branch back to the start of the while loop when the lhs of the assignment is being evaluated. One might argue that a "next" occurring in the conditional part of the while statement should be considered to be in an invalid context, but I suppose that there are some possible exploitations of the current treatment. On another topic, I also posted a note posing the problem: Give an expression that uses only relational operators and alternation that produces the smallest value among three integer-valued variables a, b, and c. One solution is: c > ((b > a) | b) | c The solution is fairly obvious if you think about it. First, consider an expression that produces the smallest of two values, a and b. The expression: b > a produces a if it is smaller than b and fails otherwise. By adding an alternative, (b > a) | b a is the value if smaller than b and b is the value otherwise. Since a can really represent an arbitrary expression, it is easy to extend the solution to another variable: c > ((b > a) | b) | c and another... d > (c > ((b > a) | b) | c) | d And now for a problem that I don't have a solution for: Give an expression that produces the smallest element of a list x. Assignments, calls to non-builtin procedures, and modifications to x are disallowed. From mark@arizona.CSNET Wed Sep 19 01:52:55 1984 From: mark@arizona.CSNET (Mark Langley) To: icon-group@arizona.CSNET, whm@arizona.CSNET Subject: Re: Tricky expressions and curious programs Cc: icon@arizona.CSNET, ralph@arizona.CSNET, trh@arizona.CSNET Status: R Give an expression that produces the smallest element of a list x. Assignments, calls to non-builtin procedures, and modifications to x are disallowed. This seems to work: (min >:=!lis) & &fail And if you don't like the keyword, try: (min >:=!lis) & (0>1) The key being to make goal-directed evaluation iterate through the list. From whm@arizona.CSNET Wed Sep 19 02:14:19 1984 From: whm@arizona.CSNET (Bill Mitchell) To: mark@arizona.CSNET Subject: Re: Tricky expressions and curious programs Cc: icon-group@arizona.CSNET Status: R From: mark@arizona.CSNET (Mark Langley) To: icon-group@arizona.CSNET, whm@arizona.CSNET Subject: Re: Tricky expressions and curious programs Give an expression that produces the smallest element of a list x. Assignments, calls to non-builtin procedures, and modifications to x are disallowed. This seems to work: (min >:=!lis) & &fail ^ Nice solution as such, but this ^ looks like an "assignment" to me. From ralph@arizona.CSNET Wed Sep 19 07:04:09 1984 From: ralph@arizona.CSNET (Ralph Griswold) To: icon-group@arizona.CSNET, mark@arizona.CSNET, whm@arizona.CSNET Subject: Re: Tricky expressions and curious programs Cc: icon@arizona.CSNET, trh@arizona.CSNET Status: R From mark Wed Sep 19 01:52:41 1984 Received: by arizona.UUCP (4.12/4.7) id AA27994; Wed, 19 Sep 84 01:52:32 mst Date: Wed, 19 Sep 84 01:52:32 mst From: mark (Mark Langley) Message-Id: <8409190852.AA27994@arizona.UUCP> To: icon-group@arizona.CSNET, whm@arizona.CSNET Subject: Re: Tricky expressions and curious programs Cc: icon, ralph, trh Status: O Give an expression that produces the smallest element of a list x. Assignments, calls to non-builtin procedures, and modifications to x are disallowed. This seems to work: (min >:=!lis) & &fail And if you don't like the keyword, try: (min >:=!lis) & (0>1) The key being to make goal-directed evaluation iterate through the list. how about every min >:= !lis From shafto@Nprdc.ARPA@UDel.CSNET Wed Sep 19 19:26:59 1984 From: shafto%nprdc.arpa@csnet-relay.csnet Reply-To: shafto%nprdc.arpa@csnet-relay.csnet To: ralph%arizona.csnet@csnet-relay.csnet Subject: Re: Re: Tricky expressions and curious programs Cc: icon-group%arizona.csnet@csnet-relay.csnet, icon%arizona.csnet@csnet-relay.csnet, trh%arizona.csnet@csnet-relay.csnet, shafto%nprdc.arpa@csnet-relay.csnet Status: R Still contains an assignment, right? From whm@arizona.CSNET Thu Sep 20 01:00:14 1984 From: whm@arizona.CSNET (Bill Mitchell) To: icon-group@arizona.CSNET Subject: Smallest element in a list Status: R Look, these solutions with min >:= !lis are interesting, but they've got an assignment in them. Roger Hayes suggested: sort(lis)[1] but that's just too easy. Let's keep thinking. Oh, and about min >:= !lis min has to be initialized, and what are you going to initialize it to? From whm@arizona.CSNET Thu Sep 20 03:12:29 1984 From: whm@arizona.CSNET (Bill Mitchell) To: icon-group@arizona.CSNET Subject: Re: Smallest element in a list Status: R I found a solution which works for lists which contain up to a pre-specified number of elements, but it can't be generalized to handle the arbitrary case. However, producing this solution was interesting. To state an instantiation specifically: Write an expression that finds the smallest element in a list that contains from one to four elements. The same restrictions given for the earlier problem apply, i.e., no assignments, etc. I suppose the essence of the restrictions is to require the state of the calculation to be expressed solely in terms of expression activations. From mark@arizona.CSNET Thu Sep 20 12:03:38 1984 From: mark@arizona.CSNET (Mark Langley) To: icon-group@arizona.CSNET, whm@arizona.CSNET Subject: Re: Smallest element in a list Status: R Received: by arizona.UUCP (4.12/4.7) id AA16329; Thu, 20 Sep 84 01:04:18 mst Received: by arizona.UUCP (4.12/4.7) id AA16178; Thu, 20 Sep 84 01:00:14 mst Received: by arizona.UUCP (4.12/4.7) id AA16135; Thu, 20 Sep 84 00:59:56 mst Date: Thu, 20 Sep 84 00:59:56 mst From: whm@arizona.CSNET (Bill Mitchell) Message-Id: <8409200759.AA16135@arizona.UUCP> To: icon-group@arizona.CSNET Subject: Smallest element in a list Status: O Look, these solutions with min >:= !lis are interesting, but they've got an assignment in them. Roger Hayes suggested: sort(lis)[1] but that's just too easy. Let's keep thinking. Oh, and about min >:= !lis min has to be initialized, and what are you going to initialize it to? For simplicity I did not specify the trivial init. something like (/min := !lis) & (min >:= !lis)... should be sufficient, to get the first element of the list (if it the list is not empty.) From steve@SRI-SPAM@UDel.CSNET Thu Sep 27 23:43:18 1984 From: Steve Minar To: Icon-Group.Arizona@Rand-Relay.CSNET Cc: minar@sri-spam.CSNET Subject: Please Add Me to your list! Status: R I would like to be added to the Icon group distribution list. I am doing research in computer graphics and would like to monitor current ideas, research, etc. The project that I am currently involved with is studying the use of an icon user interface for use on the SUN microcomputer. Messsages sent to me will be archived in one place for users with accounts on our machine. Thanks! Steve Minar arpanet address: minar@sri-spam US Mail: SRI International 333 Ravenswood Ave Room EJ394 Menlo Park, CA. 94025 (415) 859-3806 From whm@arizona.CSNET Sat Oct 13 02:53:59 1984 From: whm@arizona.CSNET (Bill Mitchell) To: icon-group@arizona.CSNET Subject: Smallest element in a list Status: R I never did get around to finding an expression (given the outlined constraints) that produces the smallest element in a list, but I did bump into an interesting solution for lists of non-arbitrary size. For a list "lst" with four or less elements, the expression: (!lst > !lst > !lst > !lst) | (!lst > !lst > !lst) | (!lst > !lst) | !lst produces the smallest element. Consider how it works: If lst has four distinct elements, then the leftmost alternative finds an ordering of all four elements from largest to smallest, with the smallest being the result of the expression. If there are only three distinct values (e.g. [1,2,2,3]) in lst, then the first alternative fails because a strict ordering doesn't exist. In this case, the second alternative will succeed because a distinct ordering of three of the elements exists. Similarly, if there are only two distinct values, the third alternative takes effect. The last alternative handles the case of four identical values. From ralph@arizona.CSNET Fri Oct 19 06:06:12 1984 From: ralph@arizona.CSNET (Ralph Griswold) To: icon-group@arizona.CSNET Subject: Next Icon Newsletter Status: R I am preparing the next Icon Newsletter. If you have something of interest to contribute, a topic you would like to see included, or just general suggestions, let me know. For items of general interest, mail to icon-group.arizona@csnet-relay Personal mail should be addressed to ralph.arizona@csnet-relay From JAAKOV%WISDOM.BITNET@UCB-VAX@UDel.CSNET Tue Dec 18 23:42:57 1984 From: Jacob Levy To: icon-group.arizona@CSNET-RELAY.CSNET Subject: Pls add us. Status: R Please add 'icon@wisdom.bitnet' to your list. If possible, please send a few back issues. thanks, Rusty Red (AKA Jacob Levy) BITNET: jaakov@wisdom CSNET and ARPA: jaakov%wisdom.bitnet@wiscvm.ARPA UUCP: (if all else fails..) ..!decvax!humus!wisdom!jaakov From ralph@arizona.CSNET Thu Dec 27 15:00:35 1984 From: ralph@arizona.CSNET (Ralph Griswold) To: icon-group@arizona.CSNET Subject: Icon Newsletter #16 Status: R Icon Newsletter #16 was sent out several weeks ago (bulk rate in the United States). If you are on the mailing list but have not received your copy, let me know (and provide a postal address). Ralph Griswold ralph@arizona