ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group84.txt

Internet Message Format | 1988-10-29 | 27KB

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 <cerda@ut-ngp>
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 <[e-mail]>
To:       [e-mail]
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: [e-mail]
Subject: MAILING LIST REQUEST
To: [e-mail]
cc: [e-mail]
Status: R

Please add my name to your mailing list.
Wayne McGuire <mdc.wayne@MIT-OZ>


-------


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 <[e-mail]>
Subject:  Re:  Sets in Icon
To:       [e-mail],
          [e-mail]
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 <WMM at ACC>
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: [e-mail]
ReSent-From: [e-mail]
ReSent-To: [e-mail]
mooers-note: Mon, 02 Jul 84 15:52:47 EDT
mooers-note: dist'ed to the 3 addressees
From: CSNET-RELAY Memo Service <[e-mail]>
Subject: Failed mail
To: Orphanage <[e-mail]>
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: [e-mail]
ReSent-From: [e-mail]
ReSent-To: [e-mail]
mooers-note: Mon, 02 Jul 84 16:28:04 EDT
mooers-note: reSent to the 3 addressees
From: CSNET-RELAY Memo Service <[e-mail]>
Subject: Failed mail
To: Orphanage <[e-mail]>
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 [e-mail]  Tue Sep  4 19:50:36 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
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 [e-mail]  Wed Sep  5 02:43:52 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
Subject: this
Status: R

is
a
test

From [e-mail]  Wed Sep  5 02:59:18 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
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 [e-mail]  Sat Sep  8 01:04:39 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
Subject: Re:  (longish) Parsing and Expression Evaluation
Cc: [e-mail]
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 [e-mail]  Sat Sep  8 06:18:17 1984
From: [e-mail] (Ralph Griswold)
To: [e-mail]
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 [e-mail]  Tue Sep 18 01:26:27 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
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 [e-mail]  Wed Sep 19 01:52:55 1984
From: [e-mail] (Mark Langley)
To: [e-mail], [e-mail]
Subject: Re:  Tricky expressions and curious programs
Cc: [e-mail], [e-mail], [e-mail]
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 [e-mail]  Wed Sep 19 02:14:19 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
Subject: Re:  Tricky expressions and curious programs
Cc: [e-mail]
Status: R

    From: [e-mail] (Mark Langley)
    To: [e-mail], [e-mail]
    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 [e-mail]  Wed Sep 19 07:04:09 1984
From: [e-mail] (Ralph Griswold)
To: [e-mail], [e-mail], [e-mail]
Subject: Re:  Tricky expressions and curious programs
Cc: [e-mail], [e-mail]
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: <[e-mail]>
    To: [e-mail], [e-mail]
    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 [e-mail]@UDel.CSNET  Wed Sep 19 19:26:59 1984
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Re:  Tricky expressions and curious programs
Cc: [e-mail],
        [e-mail],
        [e-mail],
        [e-mail]
Status: R


Still contains an assignment, right?


From [e-mail]  Thu Sep 20 01:00:14 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
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 [e-mail]  Thu Sep 20 03:12:29 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
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 [e-mail]  Thu Sep 20 12:03:38 1984
From: [e-mail] (Mark Langley)
To: [e-mail], [e-mail]
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: [e-mail] (Bill Mitchell)
    Message-Id: <[e-mail]>
    To: [e-mail]
    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@[e-mail]  Thu Sep 27 23:43:18 1984
From: Steve Minar <[e-mail]>
To: [e-mail]
Cc: [e-mail]
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
     [phone]

From [e-mail]  Sat Oct 13 02:53:59 1984
From: [e-mail] (Bill Mitchell)
To: [e-mail]
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 [e-mail]  Fri Oct 19 06:06:12 1984
From: [e-mail] (Ralph Griswold)
To: [e-mail]
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@[e-mail]  Tue Dec 18 23:42:57 1984
From: Jacob Levy <[e-mail]>
To: [e-mail]
Subject: Pls add us.
Status: R

        Please add '[e-mail]' to your list. If possible, please
send a few back issues. thanks,

        Rusty Red (AKA Jacob Levy)

        BITNET:                         jaakov@wisdom
        CSNET and ARPA:                 [e-mail]
        UUCP: (if all else fails..)     ..!decvax!humus!wisdom!jaakov



From [e-mail]  Thu Dec 27 15:00:35 1984
From: [e-mail] (Ralph Griswold)
To: [e-mail]
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