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

Internet Message Format | 1992-05-06 | 400KB

From icon-group-request  Wed Jan  1 09:42:23 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 1 Jan 92 09:42:23 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA06371; Wed, 1 Jan 92 09:42:21 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA27710; Wed, 1 Jan 92 08:35:03 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 12 Dec 91 22:51:53 GMT
From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!convex![e-mail]  (Russ Urquhart)
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Subject: Snobol4 to Icon: A converter?
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

I'm kind of new to this group, so if this question has already been
asked/answered, please bear with me.

I an looking for a snobol4 to icon conversion. I have some snobol4 programs
that I would like to convert and use under icon.

Any help would be appreciated!

Thanks


Russ Urquhart
Convex Computer Corporation

From icon-group-request  Wed Jan  1 23:18:45 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 1 Jan 92 23:18:45 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA25319; Wed, 1 Jan 92 23:18:43 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA05563; Wed, 1 Jan 92 17:05:23 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 13 Dec 91 17:56:39 GMT
From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!wupost!dsuvax.dsu.edu![e-mail]  (Guy Helmer)
Organization: Dakota State University
Subject: CFP: SIXTH INTERNATIONAL CONFERENCE on SYMBOLIC and LOGICAL COMPUTING
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]



   SIXTH INTERNATIONAL CONFERENCE on SYMBOLIC and LOGICAL COMPUTING

                      DAKOTA STATE UNIVERSITY
                       MADISON, SOUTH DAKOTA
                       OCTOBER 15 - 16, 1992

    ICEBOL6, the Sixth International Conference on Symbolic and Logical
Computing, is designed for teachers, scholars, and programmers who want
to meet to exchange ideas about computer programming for non-numeric
applications -- especially those in the humanities.  In addition to a
focus on SNOBOL4, SPITBOL, and Icon, ICEBOL6 invites presentations on
textual and logical processing in a variety of programming languages such
as Prolog and C.  Topics of discussion will include artificial
intelligence and expert systems, and a wide range of analyses of texts in
English and other natural languages.  Parallel tracks of concurrent
sessions are planned.

    ICEBOL's coffee breaks, social hours, lunches, and banquet will
provide a series of opportunities for participants to meet and informally
exchange information.


CALL FOR PAPERS

    Abstracts (250-750 words) of proposed papers to be read at ICEBOL6
are invited in any area of non-numeric programming.  Planned sessions
include the following:

    analysis of texts (including bibliography, concordance, and index
       generation)
    artificial intelligence and expert systems
    computational linguistics
    computer languages and compilers designed for non-numeric processing
    electronic texts and encoding
    grammar and style checkers
    linguistic and lexical analysis (including parsing and machine
       translation)
    music analysis
    preparation of texts for publishing


    Papers must be in English and may not exceed twenty minutes reading
time.  Abstracts should be received by March 1, 1992.  Notification of
acceptance (based on recommendations of readers) will follow promptly.
Papers will be published in ICEBOL6 Proceedings.

    Presentations at previous ICEBOL conferences were made by Paul
Abrahams (ACM President), Gene Amdahl (Andor Systems), Robert Dewar (New
York University), Mark Emmer (Catspaw, Inc.),  James Gimpel (Lehigh),
Ralph Griswold (Arizona), Susan Hockey (Oxford), Nancy Ide (Vassar) and
many others.  Copies of the ICEBOL5 Proceedings are available.


FOR FURTHER INFORMATION

    All correspondence including abstracts of proposed papers as well as
requests for registration materials may be sent to:

                   Eric Johnson
                   ICEBOL Director
                   114 Beadle Hall
                   Dakota State University
                   Madison, SD  57042 U.S.A.

    Inquiries, abstracts, and correspondence are encouraged via
electronic mail, and they may be sent to Eric Johnson at:

                   [e-mail]

                          or

                [e-mail]

--
          Guy Helmer, Dakota State University Computing Services
[e-mail], [e-mail], dsuvax![e-mail]
         Whip me, beat me, but don't make me maintain BASIC code!

From icon-group-request  Thu Jan  2 14:18:45 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Jan 92 14:18:45 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA00596; Thu, 2 Jan 92 14:18:42 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA22969; Thu, 2 Jan 92 08:07:02 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 2 Jan 92 19:22:27 GMT
From: att!cbnewsj![e-mail]  (donald.s.klett)
Organization: AT&T Bell Laboratories
Subject: Icon Version 8 System for Mac
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

I have ported the Icon translator and interpreter to the Macintosh using
THINK C 5.0.1 under System 7.  This is not the MPW version.  I used the
"console" feature in THINK C.  Since I am not sure how much interest there
is in the Mac community, I will initially offer to e-mail the binaries to
anyone interested.  Just send e-mail making the request.  Source code is not
available from me, but may be available from the Icon project.  I submitted
the ported code to the project.
At this stage, coexpressions are not activated, and calling C routines is
not supported.

Don Klett
[e-mail]
[phone]

From icon-group-request  Fri Jan  3 21:10:07 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 3 Jan 92 21:10:07 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA06817; Fri, 3 Jan 92 21:10:01 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA08162; Fri, 3 Jan 92 20:05:15 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 3 Jan 92 07:12:19 GMT
From: csus.edu!wupost!spool.mu.edu!munnari.oz.au!uniwa![e-mail]  (D John McKenna)
Organization: University of Western Australia
Subject: Re: tic-tac-toe
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] writes:
>The reason I brought this up was the tic-tac-toe game that's popped up here
>a couple of times lately.  The nim program has a learning mode (which is
>what made it applicable to the AI seminar) that applies real well to
>tic-tac-toe since tic-tac-toe has a finite range of possible "states" that
>can be recorded in game memory.  The nim game remembers the success or
>failure of a given choice for a given "state" of the game and eventually
>only makes choices for a given "state" that result in success.  It learns
>by playing so it tends to make stupid moves for the first five or ten
>games.  Then if it was playing someone smart it gets just as good.  The
>same learning mode could be easily applied to tic-tac-toe.

>I would tackle it but thought I'd give the original poster a shot at this
>technique first.  Tic-tac-toe has a more difficult algorithm than nim
>(although not that hard) so the learning version may be easier to program
>than the algorithmic version.  A neat trick would be to have the game
>record it's game memory in a file so it doesn't have to learn all over
>again every time the game is started.  The nim game doesn't (yet).

Your mention of a learning tic-tac-toe reminds me of something I saw in
some book produced by Reader's Digest many years ago. This was circa
1980, maybe earlier.

There was a method of creating a learning tic-tac-toe system, where
every possible situation (except reflections, of course) were drawn on a
macthbox - that is, one matchbox per situation. Each possible next move
by the opponent was drawn in a different colour - ie green if the
opponent moves into the top left corner, red if the opponent moves into
the centre, etc. Each move is represented by a coloured bead in the
matchbox.  Once this is all set up, you begin playing.

So you do your move - maybe in the centre of the grid. Then, taking the
matchbox that represents this situation, you take a bead out of it at
random, to determine the system's move. You then do your move, and get
the matchbox representing that situation, etc. This continues till the
game is over.  If the system loses, you destroy the last bead you drew -
ie leave it out of the matchbox in future.

Now I think about it, the game wasn't tic-tac-toe - it was played on a 3
by 3 grid with chess pawns - the top row had 3 pawns belonging to the
human, and the bottom row had 3 pawns belonging to the system.  But the
same principles applied.  It was interesting to me - I was probably
younger than ten when I did this - my first contact with AI I suppose,
although I didn't know it at the time.

Oh well, that was much harder to explain than it should be.

Steven McLeod (posing as John Mckenna)  - the man without a signature

From icon-group-request  Sat Jan  4 03:52:32 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 4 Jan 92 03:52:32 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA24629; Sat, 4 Jan 92 03:52:29 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA00564; Sat, 4 Jan 92 02:40:49 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 12 Dec 91 18:53:06 GMT
From: arizona.edu!arizona.edu![e-mail]  (Kurt Parten)
Organization: Dept of Electrical and Computer Engineering, University of Arizona, Tucson, Arizona
Subject: read() problems
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Is there a way for read to be OS independent, so that DOS text files
look like UNIX text files.  I'm running icon under UNIX, but the
data files are in DOS format.  I would like to get rid of
the ^M character that shows up in every line.

I tried trim(read(dosfile), "\r"), but that transformed

h  e  l  l  o \r \n

to:

h  e  l  l  o \r \r \n

instead of

h  e  l  l  o  \n
--
Kurt Parten
[e-mail]

From icon-group-request  Sat Jan  4 14:28:57 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 4 Jan 92 14:28:57 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA07848; Sat, 4 Jan 92 14:28:55 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA06274; Sat, 4 Jan 92 13:17:13 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 19 Dec 91 01:44:22 GMT
From: mips.mitek.com!utacfd.uta.edu!utagraph.uta.edu!utarlg.uta.edu![e-mail]  (DOUG WITMER)
Organization: The University of Texas at Arlington
Subject: Memory Mangement
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

This question is directed at those having an in depth knowledge
of ICON internals and in particular ICON memory management.  I
know from my readings that the ICON system finds it necessary
to perform frequent garbage collections to maintain an adequate
supply of unfragmented memory.  I also know that ICON is
implemented in the C language.  My question stems from a claim
which I read today concerning the Mathematica language which is
also implemented in C.  Here is what they say about garbage
collection:

     Mathematica does memory management with reference counts,
     so that pieces of memory are freed as soon as they stop
     being used.  This means that Mathematica can make use of
     essentially all the memory that is available on a
     particular computer, without the need for operations such
     as garbage collection.  (Mathematica by Wolfram 1988:xvi)

Does anyone have an explanation of reference counts?  Can the
use of reference counts really eliminate garbage collection?
Thanks for helping satisfy my curiosity.
Doug Witmer
[e-mail]

From icon-group-request  Mon Jan  6 16:06:26 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 6 Jan 92 16:06:26 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA19180; Mon, 6 Jan 92 16:06:21 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA18045; Mon, 6 Jan 92 14:50:57 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 21 Dec 91 03:22:27 GMT
From: ksr![e-mail]  (Tim Peters)
Organization: Kendall Square Research Corp.
Subject: Re: Memory Mangement
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>...
>I know from my readings that the ICON system finds it necessary to
>perform frequent garbage collections to maintain an adequate supply of
>unfragmented memory.

Guess I'll have to do until a real expert comes along <grin>.  The
frequency of Icon garbage collection depends on an awful lot of things.
In general, I'd say that if Icon *is* doing collections frequently,
there's an easily-changed (if not easily-found ...) way to stop that by
rewriting a bit of the Icon application.  For most Icon programs most
times, garbage collection should not be a problem; indeed, for many real
Icon programs garbage collection is never needed at all.

> ...
>     Mathematica does memory management with reference counts,
>     so that pieces of memory are freed as soon as they stop
>     being used.  This means that Mathematica can make use of
>     essentially all the memory that is available on a
>     particular computer, without the need for operations such
>     as garbage collection.  (Mathematica by Wolfram 1988:xvi)
>
>Does anyone have an explanation of reference counts?
>Can the use of reference counts really eliminate garbage collection?

Dynamic memory management has become a rather large field by now, but
the intro in Knuth's "Art of Computer Programming" (Volume 1) remains
helpful.

Assuming you can read Icon, here's a fragement to help explain the
differences:

   B := [2]
   A := [1, b, 3]  # === [1, B === pointer to [2], 3]
   B := &null
   A := &null

I'll call those lines #1, #2, #3 and #4.

Icon-style garbage collection works by (in effect) putting a mark on all
the memory you can possibly reference, then reusing all the memory that
is *not* marked (it's trickier than that, of course, but I think that's
a fair summary of the basic idea).

So if garbage collection (GC) occurs right after line #2, the memory
earlier allocated for the lists A and B will get marked, because you
could still reference that memory in the future just by mentioning A or
B.

If GC occurs after #3, we must still keep all the memory around, but for
a subtler reason:  even though you can't reference the [2] list directly
via B any more, the garbage collector knows you might still reference A,
and the value of A still contains a pointer to the list that used to be
named by B.  So all the allocated memory is still potentially reachable,
so the garbage collector can't reuse it.  GC must in general not only
mark all the memory reachable in "one step", but all the memory
reachable from that in turn, and so on & so on.

If GC occurs after #4, of course neither of the earlier-allocated lists
are reachable, so the memory they occupy won't get "marked", so that
memory will get reused.

The general behavior is that "the system" doesn't worry about memory
until it runs out of it, at which point it stops everything else to
find & recycle the old memory that's no longer being used.

This can take an appreciable amount of time when it happens, and of
course the collector is itself a program that needs memory for its own
use.  That's the likely source of the (misleading; see below) claim that
Mathematica can use "essentially all" the memory for real stuff.

Reference counting (RC) is a different technique.  Under RC, each piece
of allocated memory keeps track of how many times it's pointed *at* by
other pieces of memory; when this count drops to 0, the memory can be
reused (that the count is 0 *means* that it's not being pointed at).

So in executing line #1, a piece of data is attached to the [2] list
that records that the [2] list is pointed at once (by the program
variable A).

In executing line #2, the "reference count" for the [2] list must be
bumped up by 1 because the [2] list is again referenced by a pointer
embedded in the A list.  In addition, a RC of 1 must be attached to the
list assigned to A.

In line #3, the system sees that B is being changed to point at a
different chunk of memory, so the RC of what it used to point at (the
[2] list) must be decreased by 1.  This will decrease it from 2 to 1.
Since it's 1, it's still being pointed at by something, so the system
can't reuse it.

Similarly, in line #4 the reference count of the A list is decreased
from 1 to 0.  Aha!  Since it's 0, nobody else is referencing it, so the
system can reuse it.  Since it will be reused, the reference counts of
everything *it* points at must also be decreased by 1, so the system has
to examine the A list carefully to find all the things it points at.  It
will find that it's pointing to the [2] list, so will decrease the [2]
list's RC by 1.  That in turn decrease's the [2] list's RC to 0, so that's
no longer used either.  The system then searches thru the [2] list in
order to find anything *it* may be referencing, but doesn't find another
pointer so the process stops there.

There are several things to note about this:  (1) It takes memory to
store the reference counts.  So a claim that an RC approach lets you use
"almost all" the available memory for "real stuff" is misleading.  (2)
Like Icon-flavor GC, RC also needs to recursively traverse your data
structures looking for contained pointers.  (3) It takes time to
increase and decrease the counts.  (4) While Icon-flavor GC lumps all
the work together at one time, RC-based systems tend to spread the work
out over time so that memory-management "hiccups" (pauses) aren't
noticeable.  (5) An RC-based system does all the work of maintaining the
counts whether or not you eventually run out of memory; so an Icon-
flavor GC gets off cheaper in the common case where the initial memory
region suffices.


Dynamic memory management is a very involved topic, and the stuff above
conveniently ignored almost all the interesting problems & possible
workarounds in both systems.  They both face real problems in practice!
As another complication, almost all large programs (like Icon, and
probably Mathematica too) use several different strategies (e.g., Icon
uses a different scheme for strings than it uses for co-expressions, and
so on).

I just hoped to convey enough of the essentials to make you skeptical of
marketing hype <grin>.

from-what-i-know-of-them-icon's-strategies-are-very-intelligent-choices-
   for-icon's-needs-and-i'd-be-real-surprised-if-mathematica's-choices-
   weren't-intelligent-for-its-needs-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

From icon-group-request  Mon Jan  6 16:34:14 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 6 Jan 92 16:34:14 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA20619; Mon, 6 Jan 92 16:34:11 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA19778; Mon, 6 Jan 92 15:22:35 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 21 Dec 91 04:52:15 GMT
From: [e-mail]  (Felix Lee)
Organization: Penn State Computer Science
Subject: Re: Memory Mangement
Message-Id: <lfdH+&=[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

>     Mathematica does memory management with reference counts,
>     so that pieces of memory are freed as soon as they stop
>     being used.  This means that Mathematica can make use of
>     essentially all the memory that is available on a
>     particular computer, without the need for operations such
>     as garbage collection.  (Mathematica by Wolfram 1988:xvi)

This is called "propaganda": condensing many subtle issues into a
sweeping, positive-image statement.

The memory management problem is this: if X used to refer to A but now
refers to B, you can reuse the memory occupied by A, but only if
noone else is using A.

Reference counting (RC) is giving each object a count of how many
things are using it.  When you assign X = A, you increase A's count by
one.  When you later assign X = B, you decrease A's count, and
increase B's count.  When the count for something reaches zero, you
know that noone is using it, so you can reclaim it.

The main flaw is this does not handle circular references.  Say that A
refers to B and B refers to A, but neither A nor B is being used any
more.  In principle you can reclaim both A and B, but RC cannot
discover this fact easily.  This isn't a problem if you can't create
recursive structures.  Perhaps Mathematica forbids them.  But these
types of structures are quite natural and common in languages like
Icon and Lisp.

Garbage collection (GC) strategies are more general than RC.  Rather
than continually doing RC bookkeeping, you periodically discover which
objects are in use and reclaim everything else.  There are several
different strategies for this, with different contraints and
characteristics.  I'm not going to describe them here.

The main flaw with GC is it has a bad image.  At apparently random
times, the system may pause for several seconds to do GC.  But modern
GC systems tend to behave well, and there's still plenty of active
research into improving GC in different ways.

There is good evidence that, overall, GC is more efficient than RC.
All the bookkeeping involved in RC doesn't come free.  However, the
costs get amortized over all operations, giving you a more predictable
response time.  This is attractive for interactive and real-time use,
as long as you can ignore the circular-reference problem.  Incremental
and concurrent GC strategies may be viable alternatives.

Memory fragmentation is a related issue.  If you allocate variably
sized pieces of memory, then the available memory in the system tends
to become scattered into many small pieces over the course of many
allocations and deallocations.

Now say you need to allocate 16 bytes.  There may be more than 1600
bytes of memory available, but you won't be able to use any of it if
all the pieces are smaller than 16 bytes.  RC is not enough to ensure
you can actually use "all the memory that is available on a particular
computer".

Pathological fragmentation is unavoidable in general unless you do
garbage compaction.  This involves moving all the objects in memory to
collect the available memory into a single area.  This suffers from
all the performance objections that apply to GC.  Note, however, that
with some types of GC you get compaction for free.

Now, try to condense all this into a simple blurb.  "Mathematica uses
reference counting instead of garbage collection because it seemed
like a good idea at the time."  Not very marketroidish...
--
Felix Lee    [e-mail]

From icon-group-request  Tue Jan  7 17:37:14 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 7 Jan 92 17:37:14 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA21434; Tue, 7 Jan 92 17:37:11 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA17595; Tue, 7 Jan 92 16:20:34 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 6 Jan 92 22:50:53 GMT
From: autodesk![e-mail]  (Dan Drake)
Organization: Autodesk Inc., Sausalito CA, USA
Subject: Re: tic-tac-toe
Message-Id: <[e-mail]>
References: <[e-mail]+
Sender: [e-mail]
To: [e-mail]

[e-mail] (D John McKenna) writes:
+ Your mention of a learning tic-tac-toe reminds me of something I saw in
+ some book produced by Reader's Digest many years ago. This was circa
+ 1980, maybe earlier.
+
+ There was a method of creating a learning tic-tac-toe system, where
+ every possible situation (except reflections, of course) were drawn on a
+ macthbox - that is, one matchbox per situation. Each possible next move
+ by the opponent was drawn in a different colour - ie green if the
+ opponent moves into the top left corner, red if the opponent moves into
+ the centre, etc. Each move is represented by a coloured bead in the
+ matchbox.  Once this is all set up, you begin playing.

Reader's Digest?  Interesting.  It was first written up in the early
60's in the Amateur Scientist department (I think) of Scientific
American.  It was called Matchbox Educable Naughts And Crosses Engine, or
Menace.  No worse than Oak Ridge Automatic Computing and Logical Engine,
which was an ORACLE long before Larry whatsisname got into business.

+ ...
+ Now I think about it, the game wasn't tic-tac-toe - it was played on a 3
+ by 3 grid with chess pawns - the top row had 3 pawns belonging to the
+ human, and the bottom row had 3 pawns belonging to the system.  But the
+ same principles applied.  It was interesting to me - I was probably
+ younger than ten when I did this - my first contact with AI I suppose,
+ although I didn't know it at the time.

The Hexpawn game was described in the same SciAm article, as another
candidate for this treatment.  I implemented it as my first non-trivial
assembler program, on an IBM 1620 in 1965.  Decimal assembly language.
NO arithmetic capability in the hardware; just table lookup.  160
microseconds for a NO-OP.  Those were the days.

--
Dan Drake             "When you're as good as I am, it's hard to be humble"
[e-mail]    "It wasn't hard for Einstein; so what's _your_ problem?"

From icon-group-request  Tue Jan  7 19:22:40 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 7 Jan 92 19:22:40 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA24614; Tue, 7 Jan 92 19:22:38 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA23397; Tue, 7 Jan 92 18:16:49 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 7 Jan 92 16:58:51 GMT
From: walter!MERLIN.ims.bellcore.com![e-mail]  (Leslie A. Walko)
Organization: Bellcore - IMS, Morristown, NJ
Subject: windows interface ?
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Hello,

Is there an operating system independent graphic system for Icon?
What I have in mind is a UIMS such as CLIM (Common Lisp Interface
Management System) that can provide high level graphics and presentation
services.

Thank you,
Leslie A. Walko
[e-mail]

From cfcl![e-mail]  Wed Jan  8 00:51:23 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 8 Jan 92 00:51:23 MST
Received: from apple.com by optima.cs.arizona.edu (4.1/15)
    id AA04369; Wed, 8 Jan 92 00:51:18 MST
Received: by apple.com (5.61/10-Dec-1991-eef)
    id AA04511; Tue, 7 Jan 92 23:38:53 -0800
    for
Received: by cfcl.uucp (4.1/SMI-4.1)
    id AA17517; Tue, 7 Jan 92 22:38:00 PST
Date: Tue, 7 Jan 92 22:38:00 PST
From: cfcl![e-mail] (Rich Morin)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  windows interface ?  (Or: Icon do Windows?)

I tried hacking Icon together with NeWS a few years back.  It wasn't too
hard to do; I just allowed Icon to open I/O channels with the NeWS server.
The programs then emitted commands as text PostScript strings.  I never
pursued it, however, so I can't say whether it would have worked out well.

If I were to try it today, I think I would tie in with a high-level X11
toolkit.  Tk (ftp: sprite.berkeley.edu) might be an interesting choice.
It is written in C, making it easy to hack onto Icon. The relevant paper is:

  An X11 Toolkit based on the Tcl Language
  John K. Ousterhout
  USENIX Conference Proceedings, Winter, 1991

Here's the Abstract:

  This paper describes a new toolkit for X11 called Tk.  The overall functions
  provided by Tk are similar to those of the standard toolkit Xt.  However,
  Tk is implemented using Tcl, a lightweight interpretive command language.
  This means that Tk's functions are available not just from C code compiled
  into the application but also via Tcl commands issued dynamically while the
  application runs.  Tcl commands are used for binding keystrokes and other
  events to application-specified actions, for creating and configuring
  widgets, and for dealing with geometry managers and the selection.  The use
  of an interpretive language means that any aspect of the user interface may
  be changed dynamically while an application executes.  It also means that
  many interesting applications can be created without writing any new C code,
  simply by writing Tcl scripts for existing applications.  Furthermore,  Tk
  provides a special "send" command that allows any Tk-based application to
  invoke Tcl commands in any other Tk-based application.  Send allows
  applications to communicate in more powerful ways than a selection
  mechanism and makes it possible to replace monolithic applications with
  collections of reusable tools.

From icon-group-request  Sun Jan 12 07:27:21 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 12 Jan 92 07:27:21 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA05986; Sun, 12 Jan 92 07:27:19 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA16412; Sun, 12 Jan 92 06:12:51 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 30 Dec 91 22:03:32 GMT
From: uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: bibleref-2.2
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

For anyone who wants it, a maintenance update of bibleref has been
placed in ~ftp/icon/contrib/bibleref-2.2.tar.Z on cs.arizona.edu.
Bibleref is a King James Bible text retrieval program geared for
UNIX systems.  It comes with a pre-indexed, compressed King James
text, but other texts can be indexed as well (e.g. the CCAT RSV
text with the Catholic Apocrypha, the Princeton Qur'an, and the
Book of Mormon).

I've not tried running the program under anything but UNIX.  It
can't run under DOS because of the 64k executable size-limit, but
maybe it would run under VMS - ?  Dunno.

Anyone wanting additional information, please drop me a line.

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]         rutgers!oddjob!gide!sophist!goer

From [e-mail]  Mon Jan 13 08:18:53 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 08:18:53 MST
Received: from SJ03.TS.TELE.NOKIA.FI by optima.cs.arizona.edu (4.1/15)
    id AA07720; Mon, 13 Jan 92 08:18:43 MST
Date:    Mon, 13 Jan 1992 17:18:45 GMT+0300
From: [e-mail] (Arne Larsson tel [phone] fax [phone])
Message-Id: <[e-mail]>
Subject: Icon on HP Apollo under Domain/OS?
To: [e-mail]
X-Vmsmail-To: INET::"[e-mail]"

        Have the Icon programming language been ported
        to the HP Apollo hardware running under Domain/OS
        SR 10.2 and/or higher.

        If so, would there be a binary downloadable using
        FTP from cs.arizona.edu?

        Best regards,
        Arne Larsson


From isidev![e-mail]  Mon Jan 13 15:57:27 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 15:57:27 MST
Received: from relay1.UU.NET by optima.cs.arizona.edu (4.1/15)
    id AA29311; Mon, 13 Jan 92 15:57:24 MST
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05558; Mon, 13 Jan 92 17:57:20 -0500
Date: Mon, 13 Jan 92 17:57:20 -0500
From: isidev![e-mail]
Message-Id: <[e-mail]>
Received: from isidev.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 175706.8102; Mon, 13 Jan 1992 17:57:06 EST
To: uunet!cs.arizona.edu![e-mail]
Subject: large integer bug?

This may be related to an earlier problem with large integers that was
posted a while back but I just recently noticed a problem with large
integers that work just fine for other operations but bomb with run-time
error 101 when used with "to".  This program illustrates:

        procedure main(args)
                local i
                while i := integer(get(args)) do {
                        write(i)
                        every write("\t",(i-4) to i)
                }
        end

If this program is invoked with 1234567890 and 999999999999999:

        $ testint 1234567890 999999999999999
        1234567890
                1234567886
                1234567887
                1234567888
                1234567889
                1234567890
        999999999999999
        Run-time error 101
        File testint.icn; Line 5
        integer expected
        offending value: 999999999999995
        Trace back:
           main(list_1 = [])
           {999999999999995 to 999999999999999 by 1} from line 5 in testint.icn

it can convert both strings to integers and can subtract 4 from each but it
croaks when it tries to use 999999999999995 in the every loop.  Any
thoughts?

--- ---
 | S | Iconic Software, Inc.  -  Jerry Nowlin  -  uunet!isidev!nowlin
--- ---


From ralph  Mon Jan 13 16:22:06 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 16:22:06 MST
Received: from relay1.UU.NET by optima.cs.arizona.edu (4.1/15)
    id AA01345; Mon, 13 Jan 92 16:22:04 MST
Received: from optima.cs.arizona.edu by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA13471; Mon, 13 Jan 92 18:21:49 -0500
Received: from cheltenham.cs.arizona.edu by optima.cs.arizona.edu (4.1/15)
    id AA01308; Mon, 13 Jan 92 16:21:48 MST
Date: Mon, 13 Jan 92 16:21:46 MST
From: "Ralph Griswold" <[e-mail]>
Message-Id: <[e-mail]>
Received: by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 16:21:46 MST
To: isidev![e-mail], cs.arizona.edu![e-mail]
Subject: Re:  large integer bug?

Large integers are not supported in

    i to j

and
    seq()

This is documented, although it might be easy to overlook.  The
reason is that supporting large integers in these situations would
have a significant performance impact on the customary use.

    Ralph Griswold / Department of Computer Science
    The University of Arizona / Tucson, AZ 85721

    [e-mail] / uunet!arizona!ralph

    voice: 602-621-6609 / fax: [phone]

From kwalker  Mon Jan 13 16:56:54 1992
Received: from ocotillo.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 16:56:54 MST
Date: Mon, 13 Jan 92 16:56:53 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
Received: by ocotillo.cs.arizona.edu; Mon, 13 Jan 92 16:56:53 MST
To: icon-group
Subject: Re:  large integer bug?

Part of the confusion in trying to use large integers in "to" is that
in V8.0 the error message is

    integer expected

that is fixed in future releases by changing it to

    integer expected or out of range

  Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  [phone]  [e-mail] {uunet|allegra|noao}!arizona!kwalker

From icon-group-request  Tue Jan 14 15:36:29 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 14 Jan 92 15:36:29 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA26091; Tue, 14 Jan 92 15:36:22 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA10408; Tue, 14 Jan 92 14:32:00 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 2 Jan 92 19:22:27 GMT
From: att!cbnewsj![e-mail]  (donald.s.klett)
Organization: AT&T Bell Laboratories
Subject: Icon Version 8 System for Mac
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

I have ported the Icon translator and interpreter to the Macintosh using
THINK C 5.0.1 under System 7.  This is not the MPW version.  I used the
"console" feature in THINK C.  Since I am not sure how much interest there
is in the Mac community, I will initially offer to e-mail the binaries to
anyone interested.  Just send e-mail making the request.  Source code is not
available from me, but may be available from the Icon project.  I submitted
the ported code to the project.
At this stage, coexpressions are not activated, and calling C routines is
not supported.

Don Klett
[e-mail]
[phone]

From icon-group-request  Tue Jan 14 17:51:39 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 14 Jan 92 17:51:39 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA01375; Tue, 14 Jan 92 17:51:33 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA17429; Tue, 14 Jan 92 16:41:19 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 2 Jan 92 19:47:27 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!yale.edu!jvnc.net!netnews.upenn.edu!msuinfo!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: bibleref, more info
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

I have been asked to offer more information about Bibleref.  It's not
a very complicated program, but I've certainly found it useful.  A tri-
lingual version (English-Hebrew-Aramaic) is actually the driving data
collection tool for my dissertation.  (Don't ask me for the trilingual
version, though; I can't possible maintain it at other sites.)  I've
appended part of the README file for Bibleref below.  I hope this satis-
fies the requests for additional information I've received.  If not,
please drop me a line.


--------


Program:  Bibleref  (version 2.2)
Language: Icon
Purpose:  Perform word and passage-based retrievals on the King
      James or CCAT Revised Standard versions of the Bible
      (check with me if you have a Greek New Testament online)

Files: bibleref.src convertb.icn convertr.icn listutil.icn
       name2num.icn passutil.icn readfile.icn ref2bmap.icn
       srchutil.icn

Requires: Icon version 8, a working, up-to-date Icon Program Library
      (see below on IPATH), and a King James or RSV Bible text
      (the latest from helens.stanford.edu; write me if yours is
      different)


--------


Overview:

    This package, Bibleref, offers simple tools for word and
passage-based access to the King James or Revised Standard Version of
the Bible on UNIX platforms.  Bibleref is quick, and fairly easy to
install (assuming you possess a suitable King James Bible text, a
sufficiently powerful machine, and know a little about Icon).  It will
also run with stock terminals - even nasty old ones that leave magic
cookies on your screen.  Bibleref will, however, put a significant
dent in your mass storage resources.  Your 4-5 megabyte King James or
RSV text will get block Huffman encoded, which will bring it down to
about three.  The freed space, however, will be gobbled up immediately
by some 2 megabytes of auxiliary files, and by the 150k executable
(more if you compile, rather than interpret).  In-core requirements
for the executable start at about 300k, and go up from there (if your
searches are complex enough, you could easily eat up two or three
megabytes).  In brief: Bibleref has a large appetite for memory.  Once
set up, though, it can operate with fairly minimal impact on the CPU.
    With Bibleref, you can perform most of the more basic,
low-level functions commercial Bible browsing packages offer (and
perhaps a few not found in some of the commercial packages).  You can,
for example,

    -  retrieve any passage in the Bible instantaneously
    -  move forward or backward relative to the retrieved passage
    -  search the entire Bible for words and/or word-patterns
    -  search for word co-occurrences (or the absence thereof)
    -  save passages and/or passage-lists for use with an editor

Although this program is hardly the product of any major research
effort :-), it should prove sophisticated enough for quick lookup of
passages whose precise location you have forgotten, for research on
sermons and Bible study classes, and for general topical perusal of
the biblical text.


--------


Installation:

    The following set-up and installation instructions generally
assume that you received Bibleref as a shell archive, with no prebuilt
data files.  If you snarfed it from an ftp site, with the data files
already built, you can skip all the instructions about obtaining and
indexing a King James Bible text.  If there's any doubt over whether
your data files are prebuilt, check to see if the file "index.done"
exists in your Bibleref source directory.  If it does, then your data
files have already been built.  Otherwise, you'll need to do a "from
scratch" installation.
    In brief, the setup process consists of the following steps
(those with prebuilt data files only need to do the starred ones):

    *  make sure Icon is installed & your IPATH variable is set
    -  get a hold of a KJV or RSV text
    -  unpack the text & link the files to the current directory
    *  modify the makefile to suit your machine
    *  make

Although I will discuss it below briefly, installation of the Icon
programming language falls outside the scope of this manual.  I will
therefore begin setup instructions with directions on how to get a
biblical text, and how to set it up for indexing.

And so on... (blah, blah, blah)

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]         rutgers!oddjob!gide!sophist!goer

From icon-group-request  Wed Jan 15 08:34:28 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 15 Jan 92 08:34:28 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA08139; Tue, 14 Jan 92 22:20:36 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA02147; Tue, 14 Jan 92 21:07:59 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 2 Jan 92 22:40:15 GMT
From: mcsun!sun4nl!wn1.sci.kun.nl![e-mail]  (NUnet News Owner)
Organization: University of Nijmegen
Subject: test
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

this is the first line.
This is he second line.
This is the third line.
Sorry folks, this test is very important for me.

From cliff  Fri Jan 17 11:32:46 1992
Received: from javelina.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Jan 92 11:32:46 MST
Date: Fri, 17 Jan 92 11:32:42 MST
From: "Cliff Hathaway" <cliff>
Message-Id: <[e-mail]>
Received: by javelina.cs.arizona.edu; Fri, 17 Jan 92 11:32:42 MST
To: icon-group
Subject: resending message


The disk that the icon-group mailinglist address file resides on went down
yesterday - here's a message that apparently didn't make it out.


    Cliff Hathaway
    Dept. of Computer Science [phone]
    University of Arizona     [e-mail]             (internet)
    Tucson, Ariz. 85721          {cmcl2,noao,uunet}!arizona!cliff    (uucp)

=============  forwarded message starts here  ================================

Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
        id AA01541; Thu, 16 Jan 92 19:59:08 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
        id AA28720; Thu, 16 Jan 92 18:56:28 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for [e-mail] ([e-mail])
        (contact [e-mail] if you have questions)
Date: 15 Jan 92 23:58:06 GMT
From: pa.dec.com!nntpd.lkg.dec.com!tle.enet.dec.com![e-mail]  (John Ellenberger)
Organization: Digital Equipment Corporation
Subject: New Version of Catspaw Snobol Available
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

This month's BYTE article on Snobol mentions a free implmentation
of the language available on the network.  Unfortunately the version
available in most archives (uu, wuarchive, simtel) is out of date
and will not work on some PCs (486s in particular).

Catspaw Inc. has provided an up to date version and I have downloaded
it to GATEKEEPER for general use.  Fell free to propigate it to the
other archives if you wish.  It can be ftp'd from:

        gatekeeper:/pub/micro/msdos/Snobol/vanilla.zip

Any questions/concerns/orders should be directed to:

        Catspaw, Inc.
        P.O. Box 1123
        Salida, Colorado 81201
        719-539-3884
        FAX [phone]
        AppleLink D6941
        CompuServe 76176,1304
        Internet [e-mail]


From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:[e-mail]  Fri Jan 17 12:41:31 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Jan 92 12:41:31 MST
Received: from sun2.nsfnet-relay.ac.uk by optima.cs.arizona.edu (4.1/15)
    id AA26478; Fri, 17 Jan 92 12:41:07 MST
Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET
          with NIFTP id <[e-mail]>;
          Fri, 17 Jan 1992 13:24:47 +0000
Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa21167;
          17 Jan 92 12:15 WET
Date: 17 Jan 92 12:16:32 gmt
From: [e-mail]
Subject: Test
To: [e-mail]
Message-Id: <17 Jan 92 12:16:32 gmt 320862@EMAS-A>
Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:[e-mail]>

This also is a test - problems with mail at this end - please ignore.
RH

From icon-group-request  Fri Jan 17 21:48:19 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Jan 92 21:48:19 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA19476; Fri, 17 Jan 92 21:48:11 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA18359; Fri, 17 Jan 92 20:45:51 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 7 Jan 92 11:56:39 GMT
From: csus.edu!wupost!zaphod.mps.ohio-state.edu!caen!garbo.ucc.umass.edu!risky.ecs.umass.edu!umaecs!amh![e-mail]
Organization: Amherst College, Amherst, MA.
Subject: MS-DOS Icon limitations?
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Hello all.  Richard Goerwitz recently posted the following to HUMANIST:

>[MS-DOS's] memory limitations and inability to multitask make it a
>bit difficult for many of us to stomach (although its small size and
>relative simplicity make it fine for applications).  Icon is a very
>high level, OS-independent language, and its implementation was geared
>for machines with medium or large address spaces and high-level memory
>management facilities (i.e. UNIX, VMS, etc.).  There is a DOS version
>available from cs.arizona.edu (which you can obtain via anonymous ftp),
>and it's very popular.  I found it klunky, though, and the inherent
>limitations of DOS memory management facilities forced me quickly to
>move "up."

My Icon programs aren't nearly as long as Goerwitz's programs that I've
seen, so I was curious about just what kind of limitation DOS might really
have for me.  I do my Icon work in VMS.  I decided to see whether the
program I am currently writing would work on MS-DOS.  Here are the
VMS and MS-DOS compiles, respectively:

$ icont create                C:\> icont create
Translating:                Translating:
create.icn:                         create.icn:
  main (99/15000)                         main (3037/15000)
  pow (5/15000)                           pow (179/15000)
  get1or2 (8/15000)                       get1or2 (286/15000)
  makeprintout (11/15000)                 makeprintout (388/15000)
  printit (111/15000)                     printit (3565/15000)
  randomseed (8/15000)                    randomseed (267/15000)
No errors                               No errors
Linking:                                Linking:
$                                       C:\>

I remember (perhaps incorrectly) that the (99/15000), etc. has to do with
memory, but I don't remember where I read it.  Anyway, I wonder if
anyone out there can tell me where to find out.  It appears as though
some of my procedures are making a dent in MS-DOS Icon, whereas to VMS
Icon, they are pretty dinky.

So what's the point of my post?  First, the question above, and second,
some folks may not know the difference between the compiles across
platforms, so maybe it is a little interesting.  I am not trying to
knock MS-DOS.

Keith Handley
kehandley@amherst

From icon-group-request  Sat Jan 18 12:05:29 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 18 Jan 92 12:05:29 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA11462; Sat, 18 Jan 92 12:05:25 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA17097; Sat, 18 Jan 92 11:00:12 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 16 Jan 92 03:42:29 GMT
From: dorm.rutgers.edu!pilot.njin.net![e-mail]  (Douglas Hedges)
Organization: Rutgers Univ., New Brunswick, N.J.
Subject: Re: New Version of Catspaw Snobol Available
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] (John Ellenberger) writes:

>This month's BYTE article on Snobol mentions a free implmentation
>of the language available on the network.  Unfortunately the version
>available in most archives (uu, wuarchive, simtel) is out of date
>and will not work on some PCs (486s in particular).

>Catspaw Inc. has provided an up to date version and I have downloaded
>it to GATEKEEPER for general use.  Fell free to propigate it to the
>other archives if you wish.  It can be ftp'd from:

>    gatekeeper:/pub/micro/msdos/Snobol/vanilla.zip

>Any questions/concerns/orders should be directed to:

>    Catspaw, Inc.
>    P.O. Box 1123
>    Salida, Colorado 81201
>    719-539-3884
>    FAX [phone]
>    AppleLink D6941
>    CompuServe 76176,1304
>    Internet [e-mail]

Let me add that Catspaw also has an excellent version
of Spitbol available for the Mac, MaxSPITBOL.
Mark Emmer has continued to refine it and has  been
generous in his update policy.  Note that MaxSPITBOL
is, unlike the 'vanilla' version of Snobol he makes
available for DOS machines, a commercial product
and  well worth the money at that.

NOTE:  I've no connection with Catspaw other than
as a satisfied customer.  It's nice to be able to
call and speak with Mark himself in re questions
or  problems.

From icon-group-request  Sun Jan 19 10:52:06 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Jan 92 10:52:06 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA13840; Sun, 19 Jan 92 10:52:04 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA26974; Sun, 19 Jan 92 09:45:58 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 16 Jan 92 11:21:41 GMT
From: dog.ee.lbl.gov!network.ucsd.edu!swrinde!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!gmdzi![e-mail]  (Werner Icking)
Organization: GMD, St. Augustin, F.R. Germany
Subject: Re: New Version of Catspaw Snobol Available
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] (John Ellenberger) writes:

>[...]
>Catspaw Inc. has provided an up to date version and I have downloaded
>it to GATEKEEPER for general use. [...]

You mean:  gatekeeper.dec.com? I could ftp it from there :-) Thanks

>    gatekeeper:/pub/micro/msdos/Snobol/vanilla.zip
--
Werner Icking         [e-mail]         ([phone]
GMD - Gesellschaft fuer Mathematik und Datenverarbeitung mbH
Schloss Birlinghoven, P.O.Box 1316, D-5205 Sankt Augustin 1, Germany
                               "Der Dativ ist dem Genitiv sein Tod."

From [e-mail]  Mon Jan 20 11:58:19 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 20 Jan 92 11:58:19 MST
Received: from cc.Helsinki.FI (hylka.Helsinki.FI) by optima.cs.arizona.edu (4.1/15)
    id AA25506; Mon, 20 Jan 92 11:58:15 MST
Date: Mon, 20 Jan 1992 20:58 EET
From: "Kimmo Kettunen; HYLK" <[e-mail]>
Subject: Subscription
To: [e-mail]
Message-Id: <[e-mail]>

Hi,

could you put me on the subscription list of Icon newsgroup. My e-mail
address is [e-mail].

Yours,

Kimmo Kettunen
Helsinki



From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:[e-mail]  Mon Jan 20 22:48:15 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 20 Jan 92 22:48:15 MST
Received: from  by optima.cs.arizona.edu (4.1/15)
    id AB17386; Mon, 20 Jan 92 22:48:08 MST
Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET
          with NIFTP id <[e-mail]>;
          Mon, 20 Jan 1992 12:18:49 +0000
Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa22781;
          20 Jan 92 12:02 WET
Date: 20 Jan 92 12:03:54 gmt
From: [e-mail]
Subject: Mac Icon
To: [e-mail]
Message-Id: <20 Jan 92 12:03:54 gmt 320141@EMAS-A>
Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:[e-mail]>

I am having great trouble contacting Donald Klett (poster of the THINK C Mac
Icon) by email - could he please post his email address somwhere in clear
please (I can't see what is going wrong - I mail to the States every day and
don't normally have problems).

Thanks.

Roger Hare.

From kwalker  Tue Jan 21 08:51:22 1992
Received: from ocotillo.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 21 Jan 92 08:51:22 MST
Date: Tue, 21 Jan 92 08:51:20 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
Received: by ocotillo.cs.arizona.edu; Tue, 21 Jan 92 08:51:20 MST
To: icon-group
Subject: Re:  MS-DOS Icon limitations?

> Keith Handley (kehandley@amherst) writes:
> ...
> Here are the VMS and MS-DOS compiles, respectively:
>
> $ icont create                C:\> icont create
> Translating:                Translating:
> create.icn:                         create.icn:
>   main (99/15000)                         main (3037/15000)
> ...
> I remember (perhaps incorrectly) that the (99/15000), etc. has to do with
> memory, but I don't remember where I read it.

The first number indicates the amount of memory used during translation
to represent the procedure. The second number is the amount of memory
reserved for this; it can be changed with the -St option of icont. icont
is implemented in C and the first number may vary somewhat between
systems depending how the C compiler represents structures. However, I
would say that, in your case, at least one set of numbers is bogus. The
code to print the numbers in our working version of Icon looks okay to me,
but I haven't checked it out on different platforms to see if it really is.
I vaguely recall that a problem in that code was fixed a while ago.

In any event, these numbers don't tell you anything about the run-time
memory usage of your program.

  Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  [phone]  [e-mail] {uunet|allegra|noao}!arizona!kwalker

From @um.cc.umich.edu:[e-mail]  Thu Jan 23 19:01:44 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Jan 92 19:01:44 MST
Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15)
    id AA15122; Thu, 23 Jan 92 19:01:37 MST
Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0)
    id AA08470; Thu, 23 Jan 92 20:57:24 -0500
Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Thu, 23 Jan 92 19:12:54 EST
Date: Thu, 23 Jan 92 19:12:38 EST
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Pipes in MS-DOS Icon

The latest issue of the Icon Analyst discusses several handy uses
of pipes.  It also points out that pipes are not available under
the MS-DOS version of Icon and states:

"Note that the MS-DOS idea of pipes---writing the output of a
program to a temporary file and then reading that file in another
program---is bogus."

In fact, the MS-DOS idea of pipes is only slightly less powerful
than the Unix version, and including pipes in MS-DOS Icon poses
no problem in principle.  (Not knowing the code, I can't speak to
the problems that it might pose in practice.)  Nearly all useful
cases would be covered by a straightforward implementation of
pipes in MS-DOS; in particular, such an implementation would
easily handle all the examples in the Analyst article.  The
straightforward  and obvious implementation goes like this:

(1) When opening a pipe for input, execute the command in a
subshell, save the output in a temporary file, and read that
temporary file as though you were reading the pipe.

(2) When opening a pipe for output, save all data written to the
pipe in a temporary file; when the pipe is closed either
explicitly or implicitly (at program termination), execute the
piped command with that file as its standard input.

To understand why the DOS use of temporary files isn't really so
far from the Unix treatment of pipes, it helps to look at what
the Unix treatment of pipes really is.  Unix treats pipes at two
levels: shell commands and system functions.  The shell commands,
which are what most users see, behave very much like the DOS
ones; typing
   prog1 | prog2
produces the same effect in either system.

The underlying mechanism is that the shell sets up a pipe between
prog1 and prog2 by calling the "pipe" function to obtain a pair
of file descriptors, one for output and one for input.  The shell
associates the output descriptor with the output of prog1 and the
input descriptor with the input of prog2.  The shell then calls
the system function "fork" twice to establish prog1 and prog2 as
its child processes.

The pipe itself uses an internal 4096-byte memory buffer (in
classic Unix, at least); if no context switching takes place and
the output of prog1 is less than 4096 bytes long, the sequence of
events is:
  (1) prog1 writes its output to the memory buffer.  (If prog2
tries to start before prog1, it is suspended on its first read
from standard input.)
  (2) prog1 fills the memory buffer and terminates.
  (3) prog2 executes, reading the memory buffer, and terminates.
In fact, the sequence is almost exactly equivalent to what
happens under DOS using a RAM disk to hold the temporary file.

Although other variations are possible under Unix in principle,
they don't matter much in practice.  For instance, context
switching might take place so that execution of prog1 and prog2
is interleaved.  However, if the result depends on the presence
of such interleaving, prog1 and prog2 are probably not very
robust.  If the size of the output exceeds the capacity of the
memory buffer associated with the pipe, interleaving will be
unavoidable, but still should not affect the result.

Unix does, of course, also offer the opportunity for a C
programmer to construct pipes within a program (as the various
shells do).  Such programmed pipes offer possibilities not
available at the command-line level or through MS-DOS (although
some of them can be achieved in MS-DOS through explicit
subshelling).  For instance, you can connect two processes
through two independent pipes.  (I don't know how often people
really do this.)  However, if the pipes don't all flow in the
same direction, then the possibility of deadlock is immediately
introduced.  And if they do flow in the same direction, the
straightforward MS-DOS implementation described above still
works; it is only necessary to execute the upstream program
before the downstream program.

I don't believe the rare case that is expressible in Unix but not
in MS-DOS (processes that share pairs of pipes pointing in
opposite directions) arises very often.  Virtually all of the
examples I have seen of pipes used for program input and output
involve system programs such as "ls" (for Unix) or "dir" (for
MS-DOS).  And even if this case is excluded, the functionality of
piped commands would be very useful for MS-DOS Icon.

Another way of looking at it is that Unix provides more possible
orders of computation than MS-DOS; the temporary file model
greatly constrains the order of computation.  However, programs
that are sensitive to the order of computation are unlikely to be
well-behaved or useful.  Therefore the MS-DOS order must be
semantically equivalent to any of the Unix orders.  Any
counterexamples?

Paul Abrahams
[e-mail]

From ralph  Thu Jan 23 19:20:31 1992
Date: Thu, 23 Jan 92 19:20:31 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by cheltenham.cs.arizona.edu; Thu, 23 Jan 92 19:20:31 MST
To: [e-mail], [e-mail]
Subject: Re:  Pipes in MS-DOS Icon

I stand by my statement.  If the output of one process is very large (or
not bounded), the use of a temporary file as in MS-DOS ranges from
downright painful to unworkable.

I'll let my side of the conversation drop there -- this is the kind
of thing that results in endless "flames" that do little to
illuminate and only clutter the network.

    Ralph Griswold / Department of Computer Science
    The University of Arizona / Tucson, AZ 85721

    [e-mail] / uunet!arizona!ralph

    voice: 602-621-6609 / fax: [phone]

From [e-mail]  Fri Jan 24 02:05:11 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Jan 92 02:05:11 MST
Received: from apple.com by optima.cs.arizona.edu (4.1/15)
    id AA08658; Fri, 24 Jan 92 02:05:08 MST
Received: from [90.134.16.31] by apple.com with SMTP (5.61/10-Dec-1991-eef)
    id AA25306; Fri, 24 Jan 92 01:04:57 -0800
    for [e-mail]
Message-Id: <[e-mail]>
Date: Fri, 24 Jan 1992 01:06:13 -0800
To: [e-mail]
From: [e-mail] (Nevin :-] Liber)
Subject: Re:  Pipes in MS-DOS Icon
Cc: [e-mail]

[This is pretty much off the subject of Icon.  Followup by mail and/or to
another newsgroup if you feel that you must.]

Ralph Griswold ([e-mail]) writes:
>... If the output of one process is very large (or
>not bounded), the use of a temporary file as in MS-DOS ranges from
>downright painful to unworkable.

Let me second this sentiment.  As someone who once had to make the
transition from Unix to MS-DOS, I was made painfully aware of how limiting
MS-DOS pseudo-pipes (or MPW pipes on the Macintosh, for that matter) really
are.

One of the most common idioms I use under Unix is something like:

        command1 | command2 | ... | commandN | more

where the output of each of the commands is typically much larger than 4K
(a typical size for a Unix pipe), and I using "more" to do some interactive
filtering of the data.  If I had to wait until command1 finished running,
then command2 starting, then command2 ending, then command3 starting, etc.
(MS-DOS pipes are equivalent to sequential execution of the commands)
before I could even begin to look at my output, it would at a minimum slow
me down and take a lot of temporary space.  As a human, I tend to
implicitly exploit the property that I am pushing through much more data
than the size of the pipe, and I suspect that most other Unix users do too.

Many uses of pipes involve looking for a specific piece of information and
ignoring the rest of the input.  Even if you have a lot of temp space (and
believe me; it is very frustrating when you run out), this is vastly
inefficient on an MS-DOS machine.  And if one of the processes happens to
produce an unbounded amount of output (such as a random sentence generator
or getting live data from a port and then piping the output to some kind of
a filter), all bets are off.

Back when I was using MS-DOS (it should be obvious from my .signature why I
don't anymore :-)), I was running most of my stuff using the MKS Toolkit
(an excellent commercial port of most of the Unix utilities).  Even with
this environment, the scripts I used under Unix were much different than
the ones I used under MS-DOS, precisely because of the way pipes didn't
work on my MS-DOS machine.  The sequential execution/temporary file model
of pipes, although still quite useful, does not even come close to the
power of a Unix pipe.


From @um.cc.umich.edu:[e-mail]  Fri Jan 24 20:08:41 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Jan 92 20:08:41 MST
Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15)
    id AA19622; Fri, 24 Jan 92 20:08:34 MST
Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0)
    id AA17741; Fri, 24 Jan 92 22:04:37 -0500
Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Fri, 24 Jan 92 21:17:59 EST
Date: Fri, 24 Jan 92 21:18:04 EST
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Pipes in MS-DOS Icon (continued)


I readily concede the point that when intermediate results are
very large and the ultimate output is being processed
interactively, the MS-DOS imitation of pipes doesn't work very
well (or not at all, if the output is unbounded).  Nonetheless
I still argue that there are many useful applications of the
MS-DOS model, including practically all of the published examples
of Icon pipes.  The disk usage implied under MS-DOS is not much
of a penalty if the disk is a RAM disk---which is easily provided
for on machines having the hardware capability of typical Unix
machines.  Moreover, if the temporary files fit on the RAM disk
and the final output is not being processed interactively, the
MS-DOS timings (for comparable hardware) should be similar to the
Unix ones.  In fact, some MS-DOS programs run faster than their
Unix equivalents on the same hardware; for example, Eberhard
Mattes's version of TeX, EmTeX, runs about 40% faster than Unix
TeX on my computer.

I also point out that "sort" is one of the most commonly used
filters in a Unix pipeline, and if the amount of data being
passed through "sort" exceeds the memory capacity, even Unix
needs to use an intermediate file implicitly.  The same holds for
any other filter that cannot operate in a single pass.

Paul Abrahams
[e-mail]


From icon-group-request  Fri Jan 24 20:27:34 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Jan 92 20:27:34 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA20187; Fri, 24 Jan 92 20:27:32 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA17612; Fri, 24 Jan 92 19:12:14 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 18 Jan 92 21:19:06 GMT
From: uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: icon & parsing
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

If one were outputting a LALR(k) parser of some sort in Icon,
I wonder how states might best be represented.  Normally, one
can created labeled nodes in the source code to which one sim-
ply jumps via a goto.  In Icon this isn't possible.  What
would be better?  To create a coexpression that reads a state
table, outputting states as needed, and then check these
states against a (possibly huge) case statement?

Sorry if these questions sound naive.  I'd appreciate any ad-
vice I can get.

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]         rutgers!oddjob!gide!sophist!goer

From [e-mail]  Fri Jan 24 23:14:45 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Jan 92 23:14:45 MST
Received: from ucsd.edu by optima.cs.arizona.edu (4.1/15)
    id AA25014; Fri, 24 Jan 92 23:14:41 MST
Received: from odin.ucsd.edu by ucsd.edu; id AA00993
    sendmail 5.64/UCSD-2.2-sun via SMTP
    Fri, 24 Jan 92 22:14:33 -0800 for [e-mail]
Received: by odin.ucsd.edu (4.1/UCSDPSEUDO.4)
    id AA10946 for uchinews!ellis![e-mail]; Fri, 24 Jan 92 22:14:32 PST
Date: Fri, 24 Jan 92 22:14:32 PST
From: [e-mail] (William Griswold)
Message-Id: <[e-mail]>
To: [e-mail], uchinews!ellis![e-mail]
Subject: Re:  icon & parsing

Yes, simulating gotos with a case statement is quite reasonable.  I
don't know that a coexpression would be necessary to generate the states.

You can think of the state transitions as instructions to be
executed by an interpreter.  Then you can think of case statement as the
basic interpreter-loop for the instructions.

But I'll bet someone out there can out-do this solution.

                    bill

From icon-group-request  Sat Jan 25 00:58:33 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Jan 92 00:58:33 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA27646; Sat, 25 Jan 92 00:58:30 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA29028; Fri, 24 Jan 92 23:54:47 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 17 Jan 92 12:51:41 GMT
From: mcsun!uknet!bcc.ac.uk![e-mail]  (Dominik Wujastyk)
Organization: Bloomsbury Computing Consortium, London
Subject: Re: New Version of Catspaw Snobol Available
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

What is the ftp address of "Gatekeeper"?

Thanks,

Dominik

From @um.cc.umich.edu:[e-mail]  Sat Jan 25 10:16:24 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Jan 92 10:16:24 MST
Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15)
    id AA13933; Sat, 25 Jan 92 10:16:21 MST
Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0)
    id AA21466; Sat, 25 Jan 92 12:12:26 -0500
Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Sat, 25 Jan 92 12:13:20 EST
Date: Sat, 25 Jan 92 12:13:24 EST
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Pipes for MS-DOS Icon revisited

The question of whether or not MD-DOS pipes are bogus has, I think,
obscured my main point relative to Icon: that providing pipes in MS-DOS
Icon would be a very useful enhancement.  Even if the MS-DOS version
lacks the full power of the Unix version, the power it provides would
be very convenient.  Moreover, the visible semantics under the two
systems are the same (modulo the fact that the DOS utilities have
different names from their Unix counterparts).  The weaknesses of the
DOS version show up not in different results but in programs that run
more slowly (including the extreme point of nontermination).

Paul Abrahams
[e-mail]

From [e-mail]  Sun Jan 26 01:37:21 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 26 Jan 92 01:37:21 MST
Received: from apple.com by optima.cs.arizona.edu (4.1/15)
    id AA26138; Sun, 26 Jan 92 01:37:16 MST
Received: from [90.134.16.31] by apple.com with SMTP (5.61/10-Dec-1991-eef)
    id AA12732; Sun, 26 Jan 92 00:37:01 -0800
    for [e-mail]
Message-Id: <[e-mail]>
Date: Sun, 26 Jan 1992 00:38:22 -0800
To: [e-mail]
From: [e-mail] (Nevin :-] Liber)
Subject: Re: Pipes for MS-DOS Icon revisited
Cc: [e-mail]

>The question of whether or not MD-DOS pipes are bogus has, I think,
>obscured my main point relative to Icon: that providing pipes in MS-DOS
>Icon would be a very useful enhancement.

The interface between Icon and the underlying operating system a given
implementation is run on is minimal (and should be, IMHO.  This is one of
the reasons why the Icon implementation itself is highly portable).  It
does, however, provide extra support for OS features (system(), pipes in
Unix, etc.) when the cost for the service is negligible.  To provide pipes
under Unix, all that has to happen on the C implementation side is to call
popen() instead of fopen() to open the file.  No other bookkeeping is
required.  [As a side note:  when I write Unix utilities with multiple
input and/or output streams, I tend to add options to allow users to pipe
to and from the utility via the command line precisely because it is so
easy to implement.]

Now, should features be added to Icon to make up for operating system
deficiencies?  IMHO, this is not something that Icon is well-suited for.
This problem falls outside of what a programming language for processing
symbolic data should be fixing; it goes against the "spirit" of Icon
(again, IMHO).

>Moreover, the visible semantics under the two
>systems are the same (modulo the fact that the DOS utilities have
>different names from their Unix counterparts).

Not true.  Adding the ability to save the output of a command into a
temporary file and then reading that file back in (equivalent to reading
from MS-DOS pipes) or the ability to write to a temporary file and then
execute a command using that file as input (writing to MS-DOS pipes) does
not provide any new functionality to Icon, while true Unix-type pipes do.

Now, if you still really think that this enhancement justifies the cost,
then why don't you implement it yourself?  And you can do it all without
writing a single line of C code!  And it would be almost transparent (all
you really need are five Icon procedures and a global variable) to the rest
of your program, too (ie, you can make it so the code takes advantage of
real pipes when it is running under Unix)!


How to go about implementing MS-DOS pipes for Icon in Icon:

Under Icon, you can replace any of the built-in function calls with your
own procedures.  All you would need to replace are open, close, exit, and
stop (exit and stop are replaced because they may need to close and remove
the temporary files if there are still open pipes).  You would need an
initialization routine to do this; let's call it PIPEInitialize().  The
code for PIPEInitialize() would go something like this (note: this code is
100% untested):


global  PIPETGlobals

procedure main(LArguments)

initial {       #in case main() is called recursively
        PIPEInitialize()
        ...     #your code
}
...
end

procedure PIPEInitialize()

initial {       #put it in the initial clause in case someone tries to call
                #it a second time

        if ("pipes" ~== &features) then {       #only bother if real pipes
                                                #are not available

                PIPETGlobals := table()         #need to still call
                PIPETGlobals["open"] := open    # the built-ins
                PIPETGlobals["close"] := close
                PIPETGlobals["exit"] := exit
                PIPETGlobals["stop"] := stop

                open := PIPEOpen
                close := PIPEClose
                exit := PIPEExit
                stop := PIPEStop
        }
}

end


Since the semantics of reading from/writing to a sequentially executed pipe
are very well defined, it should be fairly straightforward to write the
procedures PIPEOpen(sFilename, sOptions), PIPEClose(fFile),
PIPEExit(iExitStatus), and PIPEStop(xStrings[]).  For instance: the code
for PIPEOpen should go something like this:

1.      Trap run-time errors
2.      Call "open" (fFile := PIPETGlobals["open"](sFilename, sOptions))
3.      If no errors occurred, restore &error and return \fFile
4.      If the error was not invalid option or "p" is not in sOptions, then
                restore &error, do runerr() and fail
5.      Make up a unique file name.
6.      Call system(sFilename || " > " || sTemporaryFilename)
7.      Open the temp file
                fFile := PIPETGlobals["open"](sTemporaryFilename)
8.      Keep track of the file so PIPEClose can remove it when done
                PIPETGlobals[fFile] := sTemporaryFilename
9.      restore &error and return fFile


And PIPEClose() (again, ignoring the case of writing to a pipe) would do
something like this:

        procedure PIPEClose(fFile)

                PIPETGlobals["close"](fFile)

                remove(\PIPETGlobals[fFile])
                delete(PIPETGlobals, fFile)

                return fFile

        end


Anyway, you get the idea.  Starting with this model and a few hours work,
you can have your sequentially executed pipes without having to bog down
the implementation with yet another "creeping featurism".  Plus, it can be
100% portable, too!
___
NEVIN ":-)" LIBER,  Speech Recognition Guy
 email: [e-mail]         paper:  Apple Computer, Inc.
 voice: (408) 974-MIX1                  20525 Mariani Avenue, MS: 76-7E
 AppleLink: NEVIN.LIBER                 Cupertino, California 95014


From @um.cc.umich.edu:[e-mail]  Sun Jan 26 13:00:20 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 26 Jan 92 13:00:20 MST
Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15)
    id AA15095; Sun, 26 Jan 92 13:00:14 MST
Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0)
    id AA27886; Sun, 26 Jan 92 14:56:15 -0500
Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Sun, 26 Jan 92 14:54:51 EST
Date: Sun, 26 Jan 92 13:33:04 EST
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Pipes in MS-DOS Icon (ctd.)

What strikes me about the debate over pipes in MS-DOS Icon is
that just about all of the objections to my suggestion have come
from Unix users who, judging from their comments, consider MS-DOS
to be beneath contempt and never use MS-DOS Icon.  (As for me, I
use Icon under both MS-DOS and Unix.)  It would be interesting to
get some comments from whoever is responsible for the current
MS-DOS implementation as well as from people who are using MS-DOS
Icon.  My impression is that there are many of them out there
(any data, Ralph?)

I just don't see why enhancements to MS-DOS Icon should be so
irksome to the Unix folk.  After all, what difference does it
make to you?  It's a big world, guys and gals!

However, I can't resist one dig: anybody out there who has paid
for Unix software or hardware with an unreimbursed personal check
(OK, Visa and Mastercard count too)?

Paul Abrahams
[e-mail]

From cfcl![e-mail]  Sun Jan 26 15:28:01 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 26 Jan 92 15:28:01 MST
Received: from apple.com by optima.cs.arizona.edu (4.1/15)
    id AA18810; Sun, 26 Jan 92 15:27:57 MST
Received: by apple.com (5.61/10-Dec-1991-eef)
    id AA18262; Sun, 26 Jan 92 14:12:26 -0800
    for
Received: by cfcl.uucp (4.1/SMI-4.1)
    id AA05456; Sun, 26 Jan 92 13:55:18 PST
Date: Sun, 26 Jan 92 13:55:18 PST
From: cfcl![e-mail] (Rich Morin)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: UNIX software prices

> However, I can't resist one dig: anybody out there who has paid
> for Unix software or hardware with an unreimbursed personal check
> (OK, Visa and Mastercard count too)?

I have bought in excess of $50K worth of "UNIX Hardware" (primarily
Sun-related equipment) over the years.  By and large, I consider it
to be money well-spent.  I spend vanishingly small amounts of money
on software, however.  Reasons:

  1)    As a trade writer, I tend to get free copies of almost any
    software I want.  This isn't much, however, as I really don't
    use much commercial software.  Instead, I use:

  2)    Bundled UNIX tools.  The UNIX system comes with zillions of
    useful tools.  I can usually make some combination of them
    do the trick.  Interesting combinations get saved as shell
    scripts, and may be distributed as:

  3)    Freeware.  I am a very minimal producer of freeware, but I
    use a number of freeware packages on a regular basis.  The
    fact that source code distribution is the norm for UNIX
    freeware allows me to build upon others' work, fix bugs, etc.
    Aside from the usual ftp and UUCP techniques, I can acquire
    this code in the form of inxpensive CDROM collections.

Which gives me an entree into a commercial pitch (tune out if desired,
flames to /dev/null):

Prime Time Freeware, Volume 1, Number 1 (January, 1992)

The first issue of Prime Time Freeware (PTF) is now available.  It contains
over 1500 MB of UNIX-related source code, stored as compressed tar(1) files
on an ISO-9660 CDROM.  A 50+ page booklet introduces and explains the disc.
The issue contains recent versions of over 100 packages, including:

        Andrew (windowing code)
        Athena (except Kerberos)
        CLU
        comp.sources.{amiga,3b1,games,x,sun,unix}
        Epoch
        GNU (current and vintage versions)
        Icon
        InterViews
        ISODE
        Kermit (tapes A-E)
        Mach
        NCSA Data Analysis Code
        Scheme
        Serpent
        T
        Utah Rendering Toolkit
        X11R5

The disc and booklet are available from:

        Prime Time Freeware
        415-112 N. Mary Ave., Suite 50
        Sunnyvale, CA  94086  USA

        [phone]
        cfcl![e-mail]

The list price is $60 US, payable by check or money order.  A 30% discount
applies to orders of 10-100 units.  Include $5 per order for shipping and
handling.  Add %7 to help with sales tax, if ordering within California.

From [e-mail]  Mon Jan 27 05:14:17 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Jan 92 05:14:17 MST
Received: from Arizona.edu (Osprey.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15)
    id AA15072; Mon, 27 Jan 92 05:14:06 MST
Received: from UKACRL.BITNET (MAILER@UKACRL) by Arizona.edu with PMDF#10282;
 Mon, 27 Jan 1992 05:13 MST
Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 0390; Mon,
 27 Jan 92 10:18:33 GMT
Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 1263; Mon, 27
 Jan 92 10:18:04 GMT
Date: Mon, 27 Jan 92 10:04:33 GMT
From: "R.J.Hare" <[e-mail]>
Subject: Compiler on Sun
To: icon-group <[e-mail]>
Message-Id: <[e-mail]>
X-Envelope-To: [e-mail]
Via:        UK.AC.ED.FESTIVAL; 27 JAN 92 10:04:24 GMT

I am getting:

write failed, file system full

messages when I try and compile large(ish) Icon programs on a Sun. Our system
staff tell me that this is probably because Icon is grabbing all the available
space on the /tmp directory. Is there any switch or environment variable I
ould use or set to force Icon to use a different area for its temporary files
(for local reasons, they are unwilling to increase the size of the /tmp
disrectory).

Thanks.

Roger Hare.


From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:[e-mail]  Mon Jan 27 09:14:09 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Jan 92 09:14:09 MST
Received: from  by optima.cs.arizona.edu (4.1/15)
    id AB22341; Mon, 27 Jan 92 09:14:02 MST
Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET
          with NIFTP id <[e-mail]>;
          Mon, 27 Jan 1992 15:32:05 +0000
Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa18388;
          27 Jan 92 15:36 WET
Date: 27 Jan 92 15:37:40 gmt
From: [e-mail]
Subject: Compiler on Sun.
To: [e-mail]
Message-Id: <27 Jan 92 15:37:40 gmt 320193@EMAS-A>
Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:[e-mail]>

Please ignore my last message - problem fixed, and in any case the message
should have gone to the Icon team. Soirry...

Roger Hare.

From @um.cc.umich.edu:[e-mail]  Mon Jan 27 11:43:37 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Jan 92 11:43:37 MST
Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15)
    id AA02700; Mon, 27 Jan 92 11:43:33 MST
Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0)
    id AA01345; Mon, 27 Jan 92 13:39:39 -0500
Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Mon, 27 Jan 92 12:39:17 EST
Date: Mon, 27 Jan 92 12:39:04 EST
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Pipes for MS-DOS clarified

Some of the heat generated by my comments about pipes in MS-DOS
may come from a confusion between two different ways of using
pipes.  The case that most people have cited to show the
inadequacies of MSDOS piping is a command line of the form

prog1 | prog2 | ... | more

where at least one of the progs is an Icon program.  The
enhancements I was discussing were not directed at all towards
this case; I don't see anything that MS-DOS Icon can reasonably
do to improve DOS's behavior here.

The other case, the one that concerned me, was the use, internal
to a program, of an Icon expression such as

infile := open("dir", "rp")

(or its Unix equivalent using "ls").  I still see no difficulties
in principle with enhancing MS-DOS Icon to cover this case,
although I want to make very clear that I'm not expecting the
Icon project to take on the burden of providing this enhancement.
If they want to do it, I'd be delighted; if they don't, I'll
remain grateful for all the other fine things they have done.  My
postings have been directed only at the question of whether the
enhancement poses difficulties in principle.

Although generalizations are risky, my impression, not
contradicted by the posted examples, is that most uses of pipes
that depend on process interleaving are at the command level
rather than at the internal level.  Indeed, the internal level is
much more useful for extracting the output of a fixed command,
while the external level is more useful for combining programs in
a flexible way.

Paul Abrahams
[e-mail]


From [e-mail]  Mon Jan 27 12:29:41 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Jan 92 12:29:41 MST
Received: from vtopus.cs.vt.edu by optima.cs.arizona.edu (4.1/15)
    id AA05171; Mon, 27 Jan 92 12:29:35 MST
Received: by vtopus.cs.vt.edu (5.57/Ultrix3.0-C)
    id AA14401; Mon, 27 Jan 92 14:29:20 -0500
Message-Id: <[e-mail]>
Subject: Programming Problem
To: [e-mail]
Date: Mon, 27 Jan 92 14:29:20 EST
From: Thomas F. Reid <[e-mail]>
Cc: [e-mail] (Thomas F. Reid)
X-Mailer: ELM [version 2.3 PL11]

I am going to spend a day (2 1/2 hours) of my graduate level programming
languages class on Icon and would like the students to do a small
programming problem in Icon as homework.  What I would like about a 100
line program that I can leave out about 10 lines that they have to figure
out and enter.

Any suggestions for a meaty little program that will help the students
get the gist of Icon without having to do a tremendous amount of
programming?

Thanks in advance,

Tom Reid, Virginia Tech No VA Graduate Center,
Falls Church VA,  [phone]
[e-mail]


From icon-group-request  Wed Jan 29 18:05:49 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 29 Jan 92 18:05:49 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA12117; Wed, 29 Jan 92 18:05:46 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA01057; Wed, 29 Jan 92 16:52:19 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 Jan 92 12:34:43 GMT
From: hsi!mlfarm!rosie![e-mail]  (Ronald Florence)
Organization: Maple Lawn Farm, Stonington, CT
Subject: Re: Pipes in MS-DOS Icon
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] writes:

   In fact, the MS-DOS idea of pipes is only slightly less powerful
   than the Unix version, and including pipes in MS-DOS Icon poses
   no problem in principle.

Since I don't use MS-DOS I cannot comment on the efficiency of
temporary files as pseudo-pipes, and in any case I don't want to join
a flame war.  I wrote the following code to imitate pipes for MS-DOS
and other Icon implementations which cannot write-to or read-from
pipes.  It works, but as the comment in the header notes, I'm not sure
how to determine when a pseudo-pipe fails in MS-DOS.  Any suggestions?


-----------------------------pipes.icn--------------------------
# pipes.icn
# imitates pipes
# [e-mail], 24 Jan 92
#
# This is a modest effort at portability.  Unix implementations of
# Icon have the ability to read from and write to pipes.  Pipeout()
# and pipein() are an effort to duplicate this functionality for
# systems without pipes, like ms-dos.  Both functions could do with
# some error-trapping, especially in the ms-dos versions.  My
# experience with the system function is that it returns 0 (success)
# on ms-dos machines even when command.com cannot find the command, so
# I'm at a loss how to trap errors.


    # write "what" (a list) to command "cmd"

procedure pipeout(what, cmd)
  static real_pipes

  initial real_pipes := find("pipes", &features)
  p := (\real_pipes & open(cmd, "wp")) | open(tfn := tempname(), "w")
  every write(p, !what)
  if \real_pipes then return close(p)
  else {
    cmd ||:= " < " || tfn
    status := system(cmd)
    remove(tfn)
    return status
  }
end

    # read from command "cmd"

procedure pipein(cmd)
  static real_pipes

  initial real_pipes := find("pipes", &features)
  if \real_pipes then p := open(cmd || " 2> /dev/null", "rp")
  else {
    tfn := tempname()
    system(cmd || " > " || tfn)
    p := open(tfn)
  }
  suspend !p
  /real_pipes & remove(tfn)
end


    # Richard Goerwitz's ever-useful generator.

procedure tempname()
  dir := ""

  every temp_name := dir || "pipe." || right(1 to 999,3,"0") do {
    close(open(temp_name)) & next
    suspend \temp_name
  }
end
--------------------------------eof-----------------------------
--

                Ronald Florence
                [e-mail]

From icon-group-request  Thu Jan 30 06:10:49 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 30 Jan 92 06:10:49 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA07373; Thu, 30 Jan 92 06:10:45 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA02380; Thu, 30 Jan 92 05:03:05 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 26 Jan 92 15:39:34 GMT
From: hsi!mlfarm!rosie![e-mail]  (Ronald Florence)
Organization: Maple Lawn Farm, Stonington, CT
Subject: Re: Pipes for MS-DOS Icon revisited
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] writes:

   The question of whether or not MD-DOS pipes are bogus has, I think,
   obscured my main point relative to Icon: that providing pipes in MS-DOS
   Icon would be a very useful enhancement.  Even if the MS-DOS version
   lacks the full power of the Unix version, the power it provides would
   be very convenient.

Agreed.  The code below is intuitive, if not efficient.  The `pipe'
has to be closed with pclose under ms-dos.

#
# popen.icn
# [e-mail], 26 Jan 1992
#
# popen(cmd, mode)
#    mode == "w" writes to a pipe, mode == "r" reads from a pipe
# pclose(pipe)
#
# On systems without real pipes (ms-dos), popen and pclose imitate
# pipes; pclose must be called after popen.  The code should run
# faster on ms-dos if dir in tempname() points to a directory on a
# virtual disk.
#
# On systems with real pipes, popen & pclose open and close a pipe.
#

global real_pipes, pipe_cmd, pipe_fname

procedure popen(cmd, mode)

  initial {
    real_pipes := find("pipes", &features)
    pipe_cmd := table()
    pipe_fname := table()
  }
  \real_pipes & return open(cmd, mode || "p")
  tfn := tempname()
  upto('r', mode) & system(cmd || " > " || tfn)
  p := open(tfn, mode)
  pipe_fname[p] := tfn
  upto('w', mode) &  pipe_cmd[p] := cmd
  return p
end


procedure pclose(pipe)

  \real_pipes & return close(pipe)
  if \pipe_cmd[pipe] then {
    pipe_cmd[pipe] ||:= " < " || pipe_fname[pipe]
    status := system(pipe_cmd[pipe])
  }
  else status := close(pipe)
  remove(pipe_fname[pipe])
  pipe_cmd[pipe] := pipe_fname[pipe] := &null
  return status
end

    # Richard Goerwitz's ever-useful generator.

procedure tempname()
  dir := ""

  every temp_name := dir || "pipe." || right(1 to 999,3,"0") do {
    close(open(temp_name)) & next
    suspend \temp_name
  }
end
--

                Ronald Florence
                [e-mail]

From icon-group-request  Mon Feb  3 16:55:51 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 3 Feb 92 16:55:51 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA23123; Mon, 3 Feb 92 16:55:45 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA14662; Mon, 3 Feb 92 15:51:00 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 2 Feb 92 05:54:47 GMT
From: wupost!uwm.edu!csd4.csd.uwm.edu![e-mail]  (Alan D Corre)
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Subject: Icon and MSDOS
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

"Nobody appreciates what I do until I don't do it." -- notice above
the service desk at our gym.

  I should like to offer some reflections on using Icon under MSDOS.
It seems to me that MSDOS is like a Chevy with automatic shift. It is
meant for use by ordinary people who have no interest in looking under
the hood. (The last time I did that a hole in a pipe was spurting
gasoline and I ran for my life.) MSDOS is rock solid. In the years I
have been writing Icon programs and doing much else, my Zenith has
never once stopped working. Error messages aplenty, always justified,
but never, never a need to reboot. Its commands are named with humans,
not machines, in mind. Compare dir, erase, rename with ls, rm and mv.
MSDOS made it possible for the ordinary, non-professional programmer
to do a lot of useful, if simple-minded, work. So it doesn't have
pipes. I was never a smoker anyway.
  I only realised this when I shifted to using ProIcon on the Mac. For
years I had wanted to confront some problems in the teaching of Hebrew
in a particular way. I had tried programmed learning, but it was
clumsy and cumbersome. The Mac's visual capabilities seemed to make it
possible. The result was really excellent. The student sees one window
in which he types an English transcription, and another window offers
the unvocalized Hebrew equivalent, which he is able to enunciate
because he used a modified phonemic transcription. She can switch off
the transcription at will. A cumulative log is kept, and is instantly
available with dates, lessons studied, and scores. A vocabulary can be
viewed at any time. The student can print documents in mixed Hebrew
and English. But how difficult it was for me as developer to
achieve! The machine was forever blowing up for no apparent reason,
and demanding to be restarted from scratch. Some of this was due to
bugs in the Icon program, which were promptly attended to by the
author, but most were simply that Mac operating system. Peter Robinson
of Oxford, author of a Mac program called "Collate" puts it well in
the documentation (p.69):

    I have taken every care I could to make Collate as stable as
    possible. However, C programming is notoriously tricky, and
    nowhere more so than on the Mac. Essentially, C lets you
    manipulate any bit of memory you like anyway you like. But if
    you do this to this bit, or that to that bit, the machine will
    crash. Most difficult of all: a program will include a memory
    error which every Mac you run it on tolerates. But the next
    Mac won't! This applies particularly to locking and unlocking
    handles to memory. Lock or unlock the wrong handle, at the
    wrong time, and most of the time all is well. But sometimes...

Sometimes, says he. Maybe in Oxford it's sometimes, but in Milwaukee
it's like frequently. At the hundredth appearance of that cute little
bomb, I started remarking with Queen Victoria: We are not amused. For
a period of more than a month I was unable to get my SE to run Icon
altogether. I had two people who know much more about the Mac than I
do working on it for days. We took all the files off the hard disk and
reinitialized it. We removed the inits. Nothing seemed to work. Then I
tried booting up the Mac from a floppy, and Icon worked again. The next
time I tried from the hard disk, and we were back in business.
  Last week I needed to make a small change to the program. Since the
program was written under system six, and I am now using system seven
on the SE, I decided to take Icon off the SE and use the chief Mac in
the lab the students use to recompile under the old system six Icon.
The lab folks dont want to switch to seven, because they can't spare
the memory. Anyway, I made the change, and told the Mac to recompile.
It did so. Then characters started appearing on the screen that looked
like a cross between Chinese and Mongolian. Then a window appeared
that looked like a standard Mac message window, but it was completely
empty. And the machine was frozen. I said to the lab monitor glumly:
It's stuck. Her hand flew to the reset button at the bottom of the
machine. I said:  Stop! Tom told me never to do that. She said: Why
not? This happens all the time, and I'm always hitting that button. I
pleaded: Call Tom, and ask him if it's ok. (I'm too old to adopt the
morals of the new generation.) She called and announced: He's with the
director of Computer services. He can't come to the phone. She added
archly: Can I hit the button now? Go ahead, I said in resignation. The
machine made that silly noise and came to life. There was the newly
compiled program, and it worked just fine.  What had I done wrong? I
asked. After compiling the program properly, why should it go beserk?
  MSDOS I love you.
--
Alan D. Corre
Department of Hebrew Studies
University of Wisconsin-Milwaukee                     [phone]
PO Box 413, Milwaukee, WI 53201               [e-mail]

From icon-group-request  Tue Feb  4 01:27:27 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 4 Feb 92 01:27:27 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA11856; Tue, 4 Feb 92 01:27:25 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA04266; Tue, 4 Feb 92 00:19:44 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 29 Jan 92 02:01:18 GMT
From: hsi!mlfarm!rosie![e-mail]  (Ronald Florence)
Organization: Maple Lawn Farm, Stonington, CT
Subject: Re: Pipes in MS-DOS Icon (ctd.)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] writes:

   What strikes me about the debate over pipes in MS-DOS Icon is
   that just about all of the objections to my suggestion have come
   from Unix users who, judging from their comments, consider MS-DOS
   to be beneath contempt and never use MS-DOS Icon.

Someone once gave me the good advice to never criticize the spouse or
children of a friend.  Given the sensitivity that the issue provokes,
I'd add `operating system' to the do-not-criticize list.

That said, I think there is little to be gained by pretending that
differences of operating systems do not exist.  Unix has pipes on the
kernel level; ms-dos does not.  We can produce Icon code that will
imitate the _function_ of pipes in ms-dos, and doing so makes it
possible to write portable Icon code.  But there is a difference
between reading from and writing to a temporary file, and a true pipe;
code which depends heavily on pipes will run better on an operating
system with real pipes.  Recognizing those differences is not judging
ms-dos "beneath contempt."

   However, I can't resist one dig: anybody out there who has paid
   for Unix software or hardware with an unreimbursed personal check
   (OK, Visa and Mastercard count too)?

For what it is worth, we bought our Sun workstations and SunOS (the
only software we had to buy) with an unreimbursed personal check.
Now, let's please let this newsgroup return to talk about Icon, a
language that does many things, on many operating systems, very well.
--

                Ronald Florence
                [e-mail]

From [e-mail]  Wed Feb  5 02:08:11 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 5 Feb 92 02:08:11 MST
Received: from colossus.apple.com by optima.cs.arizona.edu (4.1/15)
    id AA19032; Wed, 5 Feb 92 02:08:03 MST
Received: from [90.1.0.10] by colossus.apple.com with SMTP (5.65/11-Dec-1991-eef)
    id AA01496; Tue, 4 Feb 92 23:43:35 -0800
    for
Received: from [90.134.16.31] (peachfuzz.apple.com) by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef)
    id AA16328; Tue, 4 Feb 92 23:43:27 -0800
    for [e-mail]
Message-Id: <[e-mail]>
Date: Tue, 4 Feb 1992 23:45:13 -0800
To: [e-mail]
From: [e-mail] (Nevin ":-]" Liber)
Subject: Re: Icon and MSDOS
Cc: [e-mail]

Alan Corre ([e-mail]) writes:
>It [MS-DOS] is
>meant for use by ordinary people who have no interest in looking under
>the hood.

But as you point out later, you DO want to look under the hood!

>Its commands are named with humans,
>not machines, in mind. Compare dir, erase, rename with ls, rm and mv.

Actually, the only reason that dir, erase, and rename are used is because
they have been used on computer systems for years before the PC (my TRS-80
is one example, I believe CP/M is another).  Ask any non-computer person
what "dir" means, and they'll look at you kind of funny.  From the name
"erase", can you tell if it actually erases the file, or does it just mark
the directory entry as unavailable?  Also, "rename" was fine in the old
days where there weren't hierarchial file systems, but it is not intuitive
that you can "rename" something to put it somewhere else in the directory
tree (after all, there is a big distinction made between a directory and a
file, and all of a sudden that distinction no longer applies), but you
aren't allowed to "rename" it to a different file system.

ls, rm, and mv were named with humans in mind; the attempt was to reduce
the number of keystrokes to perform a common command (I know that this
causes other problems for humans, but the original idea was to help
humans).  It is utterly obsurd to think that the two letter commands were
designed for the machine's sake.

>  I only realised this when I shifted to using ProIcon on the Mac.
>...
>But how difficult it was for me as developer to
>achieve!

But now you are tinkering UNDER THE HOOD; that's what developers DO!  It
isn't fair to compare USING system A with PROGRAMMING system B!  I could
claim that using a Mac is much easier than programming a PC, and I don't
think I'll get much argument from the PC community.  In general, using an
arbituary computer system X is always easier than programming arbituary
computer system Y.

Now, I also believe that we have a long way to go on our development
environments (or, to fit it into the analogy:  it should be easy for those
home mechanics to do the very common stuff like oil changes), but that is a
very different topic, and as inappropriate for this newsgroup/mailing list
as this one is (sorry folks).
___
NEVIN ":-)" LIBER,  Speech Recognition Guy
 email: [e-mail]         paper:  Apple Computer, Inc.
 voice: (408) 974-MIX1                  20525 Mariani Avenue, MS: 76-7E
 AppleLink: NEVIN.LIBER                 Cupertino, California 95014


From [e-mail]  Wed Feb  5 08:08:06 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 5 Feb 92 08:08:06 MST
Received: from convex.csd.uwm.edu by optima.cs.arizona.edu (4.1/15)
    id AA12168; Wed, 5 Feb 92 08:08:02 MST
Received: by convex.csd.uwm.edu; id AA02512; Wed, 5 Feb 92 09:07:59 -0600
Date: Wed, 5 Feb 92 09:07:59 -0600
From: Alan D Corre <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Icon and MSDOS

My comparison was writing Icon programs on the Zenith and Icon programs
on the Mac. I'm sorry if I didn't make this clear, but I was not comparing
apples and oranges.

From [e-mail]  Thu Feb  6 12:22:17 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 6 Feb 92 12:22:17 MST
Received: from Arizona.edu (Hopey.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15)
    id AA29878; Thu, 6 Feb 92 12:22:14 MST
Received: from HIRAMB (TELLEFSE@HIRAMB) by Arizona.edu (PMDF #12663) id
 <[e-mail]>; Thu, 6 Feb 1992 11:45 MST
Date: Thu, 6 Feb 1992 13:41 EST
From: [e-mail]
Subject: Question on generators
To: [e-mail]
Message-Id: <12444929E060142A@HIRAMB>
X-Envelope-To: [e-mail]
X-Vms-To: IN%"[e-mail]"

        I was reading through the Icon Programming Language book last
night and I came across a line something like this:

        if (&features = = "co-expressions") then....

        Is there a space between the equals signs, or is it a "==" string
comparison? And if it is, why isn't there an "every" before the expression in
parentheses (to continue generating values from &features until it fails or
matches "co-expressions")? And if it isn't, what do the two equals signs do?
        I'm sure I'm missing something very basic here, but I still don't know
what it is... any help would be appreciated!

                                                Thanks,
                                                        Guy Tellefsen

From isidev![e-mail]  Thu Feb  6 13:27:27 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 6 Feb 92 13:27:27 MST
Received: from relay2.UU.NET by optima.cs.arizona.edu (4.1/15)
    id AA03838; Thu, 6 Feb 92 13:27:23 MST
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18697; Thu, 6 Feb 92 15:27:25 -0500
Date: Thu, 6 Feb 92 15:27:25 -0500
From: isidev![e-mail]
Message-Id: <[e-mail]>
Received: from isidev.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 152632.3443; Thu, 6 Feb 1992 15:26:32 EST
To: uunet!cs.arizona.edu![e-mail]
Subject: Re: ? on generators

 >         I was reading through the Icon Programming Language book last night
 > and I came across a line something like this:
 >
 >         if (&features = = "co-expressions") then....
 >
 >         Is there a space between the equals signs, or is it a "==" string
 > comparison?  And if it is, why isn't there an "every" before the expression
 > in parentheses (to continue generating values from &features until it fails
 > or matches "co-expressions")?  And if it isn't, what do the two equals
 > signs do?
 >
 >         I'm sure I'm missing something very basic here, but I still don't
 > know what it is...  any help would be appreciated!
 >
 >                                                 Thanks,
 >                                                 Guy Tellefsen

I'm sure given the context, the operator is supposed to be a string
comparison, the ==.  This illustrates one of the real snazzy features of
Icon, goal directed evaluation.  I'd suggest reading up on it in the book
now that your curiosity is aroused.  Goal directed evaluation is very handy
for expressions like this where the goal is to determine if co-expressions
are one of the features in the version of Icon being executed.  Since
&features is a generator, all of its results are generated until the
comparison succeeds or the generator is exhausted and the comparison
expression fails.

You have to be cautions with goal directed evaluation since it can sneak up
on you when you don't expect it.  The first example that comes to mind is
when you only want the first element in a list and you use !list as a quick
way to get it.  If you inadvertently include this expression in a larger
comparison expression you will end up generating all the elements in the
list until the expression is satisfied or the list is exhausted.  I learned
this the hard way.  I'm sure there are other examples of goal directed
evaluation gotchas.  The more powerful the tool the more dangerous.  Any
horror stories out there (not related to pipes in MS-DOS)?

--- ---
 | S | Iconic Software, Inc.  -  Jerry Nowlin  -  uunet!isidev!nowlin
--- ---


From [e-mail]  Mon Feb 10 10:47:29 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 10:47:29 MST
Received: from sun2.nsfnet-relay.ac.uk by optima.cs.arizona.edu (4.1/15)
    id AA24310; Mon, 10 Feb 92 10:47:19 MST
Received: from festival.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET
          with NIFTP id <[e-mail]>;
          Mon, 10 Feb 1992 15:49:58 +0000
From: "R.J.Hare" <[e-mail]>
Subject: Various
To: [e-mail]
Date: Mon, 10 Feb 92 15:56:24 GMT
Message-Id: <[e-mail]>


1) Is there a charge currently for Icon reports?

2) I read the stuff about pipes in the last Analyst with some interest as I
   have a need for a 'one line calculator' at the moment.

   Accordingly, I modified the simple code example in the Analyst (last
   example,in col2 of p2) to accept an Icon expression rather than just the
   'write("Hello World")' text.

   I then read in an expression (say, 3+4) at run time and got the answer I
   expected. I then modified the program to accept a command line argument -
   no problems until I entered something like sin(1) when I got a syntax error
   message. If I entered sin(1) as the input to the read statement (ie: not on
   the command line) it works fine. However, if I enter "sin(1)" as a command
   line argument, it works - am I missing something about the differnce
   between 'simple' things like '3+4' and 'difficult' things like 'sin(1)'?

3) Apart from the advantages outlined in the Newsletter of November 1991, is
   there any advantage in using the 386 version of Icon? Is it 'faster' or
   more 'efficient' for instance?

Thanks.

Roger Hare.

From [e-mail]  Mon Feb 10 11:21:47 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 11:21:47 MST
Received: from netcomsv.netcom.com by optima.cs.arizona.edu (4.1/15)
    id AA27340; Mon, 10 Feb 92 11:21:34 MST
Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1)
    id AA01946; Mon, 10 Feb 92 10:22:00 PST
Received: by netcom.netcom.com (4.1/SMI-4.1)
    id AA24509; Mon, 10 Feb 92 10:22:00 PST
From: [e-mail] (Phil Bewig)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Permuted Index for Icon Program Library
Date: Mon, 10 Feb 1992 10:20:02 -0800

The following simple pipeline, run from the /usr/icon/v8/ipl directory,
will produce a permuted index of all procs and progs in the library:

    grep "Title:" */*.icn |
    sed 's/.icn.*:[ \t]*/ /' |
    ptx -frt | troff -mptx | ...

The pipeline works as follows:  First, extract the title line from the
header in each ipl file; grep prepends the filename to each line.  Then,
replace everything from the ".icn" filename suffix to the white space
after the word "Title:" with a single space.  The options to ptx fold
upper and lower case together and ignore non-letters (-f), take the first
word on each line to be an index entry (-r), and produce output suitable
for troff (-t); some of these options may vary on some systems.  Finally,
the index is printed by troff through whatever post-processors your system
requires.  You can vary the pipeline to do such things as specify an ignore
file for the ptx command or specify additional text or formatting details
to troff.

I hope you find this useful.

Phil
[e-mail]

From [e-mail]  Mon Feb 10 12:48:06 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 12:48:06 MST
Received: from colossus.apple.com by optima.cs.arizona.edu (4.1/15)
    id AA02532; Mon, 10 Feb 92 12:48:03 MST
Received: from [90.1.0.10] by colossus.apple.com with SMTP (5.65/11-Dec-1991-eef)
    id AA01902; Mon, 10 Feb 92 11:44:44 -0800
    for
Received: from [90.134.16.31] (peachfuzz.apple.com) by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef)
    id AA00449; Mon, 10 Feb 92 11:44:38 -0800
    for [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 10 Feb 1992 11:46:38 -0800
To: [e-mail]
From: [e-mail] (Nevin ":-]" Liber)
Subject: Re: Various
Cc: "R.J.Hare" <[e-mail]>

Roger Hare <[e-mail]> writes:
>   no problems until I entered something like sin(1) when I got a syntax error
>   message. If I entered sin(1) as the input to the read statement (ie: not on
>   the command line) it works fine. However, if I enter "sin(1)" as a command
>   line argument, it works - am I missing something about the differnce
>   between 'simple' things like '3+4' and 'difficult' things like 'sin(1)'?

(I assume you meant didn't work from the command line).  Many shell
languages use parentheses as special characters, and may need to be quoted
to remove their special meaning so they can be passed directly from the
shell to your Icon program.  Try something like sin\(1\) or 'sin(1)'
(backslashes and single quotes included) and see if that works.
___
NEVIN ":-)" LIBER,  Speech Recognition Guy
 email: [e-mail]         paper:  Apple Computer, Inc.
 voice: (408) 974-MIX1                  20525 Mariani Avenue, MS: 76-7E
 AppleLink: NEVIN.LIBER                 Cupertino, California 95014


From [e-mail]  Mon Feb 10 16:05:44 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 16:05:44 MST
Received: from netcomsv.netcom.com by optima.cs.arizona.edu (4.1/15)
    id AA18593; Mon, 10 Feb 92 16:05:32 MST
Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1)
    id AA02403; Mon, 10 Feb 92 15:05:55 PST
Received: by netcom.netcom.com (4.1/SMI-4.1)
    id AA22714; Mon, 10 Feb 92 15:03:53 PST
Date: Mon, 10 Feb 92 15:03:53 PST
From: [e-mail] (Phil Bewig)
Message-Id: <[e-mail]>
Subject:  Untranslated Mode in &input
Apparently-To: [e-mail]

In the MS-DOS/386 version of icon from Catspaw, it appears that the
file &input is opened in translated mode.  I would like to access the
bytes of &input one at a time in untranslated mode using reads().  Is
there any way to close &input and re-open it in untranslated mode?

Thanks,

Phil Bewig
[e-mail]

From ralph  Mon Feb 10 16:36:51 1992
Date: Mon, 10 Feb 92 16:36:51 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 16:36:51 MST
To: [e-mail]
Subject: Re:  Untranslated Mode in &input
Cc: icon-group

Standard input (&input) is always opened in the translated mode.  You
can't do anything about it -- it's a property of the C I/O library.
The same is true of the standard MS-DOS Icon.  To the best of
my knowledge, this "feature" is true of all MS-DOS C libraries.

The thing I usually do to work around this is to pass a file name
as a command-line argument and open the file in untranslated mode
inside the program.

Incidentally, there probably is a good reason for always opening
standard input in the translated mode.  Perhaps someone more knowledgeable
than I am can illuminate this.

    Ralph Griswold / Department of Computer Science
    The University of Arizona / Tucson, AZ 85721

    [e-mail] / uunet!arizona!ralph

    voice: 602-621-6609 / fax: [phone]

From [e-mail]  Fri Feb 14 13:05:56 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 14 Feb 92 13:05:56 MST
Received: from netcomsv.netcom.com by optima.cs.arizona.edu (4.1/15)
    id AA03220; Fri, 14 Feb 92 13:05:31 MST
Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1)
    id AA24327; Fri, 14 Feb 92 12:05:58 PST
Received: by netcom.netcom.com (4.1/SMI-4.1)
    id AA27907; Fri, 14 Feb 92 12:05:56 PST
Date: Fri, 14 Feb 92 12:05:56 PST
From: [e-mail] (Phil Bewig)
Message-Id: <[e-mail]>
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: [e-mail]
Subject: Lists, Timing, and Memory Consumption

Hello,

I've been studying the chapter on lists in the icon implementation book.
An interesting conclusion of that study is that the manner in which a
list is created can have a drastic effect on the memory consumed by the
list and the time taken to access the elements of the list.  The following
program shows the difference between pre-initializing a list by using a
L := list(n, 0) statement, to allocate space for the list, or using stack-
and-queue statements to build from an initially empty list:

procedure main(args)

    # write headings, initialize variables
    write("            Pre-initialize List        Successive Insertions")
    write("                                                            ")
    write("           Block  Set-Up  Search       Block  Set-Up  Search")
    write(" Items    Memory   Time    Time       Memory   Time    Time ")
    write("------    ------  ------  ------      ------  ------  ------")
    trials := [25, 100, 500, 1000, 2000, 5000, 10000, 25000, 50000]
    memory := []

    # performs tests
    every n := !trials do {
        writes(right(n, 6))

        # pre-initialize list
        every put(memory, -&storage)
        timer := -&time
        L := list(n, 0)
        every L[1 to n] := 1992 # a very good year
        timer +:= &time
        i := 0
        every s := &storage do memory[i +:= 1] +:= s
        writes(right(memory[3], 10), right(timer, 8))
        timer := -&time
        every k := L[1 to n]
        timer +:= &time
        writes(right(timer, 8))
        L := []
        collect()

        # successive insertions
        every put(memory, -&storage)
        timer := -&time
        M := []
        every 1 to n do put(M, 1992)
        timer +:= &time
        i := 0
        every s := &storage do memory[i +:= 1] +:= s
        writes(right(memory[3], 12), right(timer, 8))
        timer := -&time
        every k := M[1 to n]
        timer +:= &time
        writes(right(timer, 8))
        M := []
        collect()
        write() }
end

Here is the output from one run of the program:

            Pre-initialize List        Successive Insertions

           Block  Set-Up  Search       Block  Set-Up  Search
 Items    Memory   Time    Time       Memory   Time    Time
------    ------  ------  ------      ------  ------  ------
    25       248       0       0        1124       0       0
   100      2632      50       0        4476      60       0
   500      9184     110     280       15136     110     110
  1000     23936     380     220       36024     390     220
  2000     52948     600     610       70660     600     660
  5000    111584    1370    1370      168372    1320    1540
 10000    249468    2360    2800      334160    2690    3680
 25000    535256    7090    6980      817432    6920    9120
 50000   1218528   14060   14280     1640988   13510   18780

I am running on a Compaq 386 at 16mhz using the MS-DOS/386 version
of Icon from Catspaw.

I have several questions:

1) Is there a better way to extract the amount of block memory used
from the &storage keyword?  What I did is just too ugly.

2) When pre-initializing, why does the memory consumed per item vary?
It is 10 bytes per item for 25 items, 26 bytes per item for 100, 24
bytes at 1000, 22 bytes at 5000, 25 bytes at 10000, 21 bytes at 25000,
and 24 bytes at 50000.

3) Memory consumed per item for successive insertions also varies, from
45 bytes per item at 25 and 100 items, to 30 bytes per item at 500, back
up to 36 bytes at 1000, decreasing at each step to 32 bytes per item at
25000, and then increasing to 33 bytes at 50000.  Why?

The moral of the story is to pre-initialize lists whenever possible so
that space is allocated more efficiently, especially when making a
large number of searches in a static array.

Phil Bewig
[e-mail]

From icon-group-request  Sat Feb 15 16:04:22 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 15 Feb 92 16:04:22 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA07253; Sat, 15 Feb 92 16:04:16 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA15789; Sat, 15 Feb 92 14:53:38 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 10 Feb 92 22:46:33 GMT
From: csus.edu!wupost!zaphod.mps.ohio-state.edu!uwm.edu!convex.csd.uwm.edu![e-mail]  (Alan D Corre)
Organization: University of Wisconsin - Milwaukee
Subject: ProIcon Program
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Since I have not seen much here on ProIcon I offer a program which is a small
part of the package to which I referred in a previous posting. This is the one
that prints mixed Hebrew and English text. It is not a word processor,
although it has some of the characteristics of one. Since in this system
students are encouraged to regard as Hebrew words what goes into their heads
and not what goes on paper, this program is psychologically important, since
it enables the student to produce nicely printed "real" Hebrew. Part of the
point is to avoid the archaic, difficult, addictive massoretic vowel point
system. I realise that it could be greatly improved, but it works well
enough, and sufficient unto the day is the evil thereof.
----------------------------------------------------------------------------
#This program is written in ProIcon for the Macintosh computer. Alan D. Corre
#August 1991. It takes input in a transcription of Hebrew which represents
#current pronunciation adequately but mimics the peculiarities of Hebrew
#spelling. Here are some sentences from the beginning of Agnon's story
#"Friendship": marat qliyngel 'i$ah mefursemet haytah umenahelet beyt sefer
#haytah qowdem liymowt hamilHamah. mi$eni$tanu sidrey ha`owlam,neHtexah
#migdulatah..wexol miy $eyac'u low mowniyTiyn ba`owlam haytah mitqarevet
#'eclow weyowce't wenixneset leveytow" The letter sin is represented by the
#German ess-zed which is alt-s on the Mac and cannot be represented here.
#The tilde (~)toggles between English and Hebrew, so the word "bar" will be
#the English word "bar" or the Hebrew beyt-rey$ according to the current
#mode of the program. Finals are inserted automatically. Justification
#both ways occurs unless the program detects a blank or empty line, in
#which case the previous line is not justified.
#Since I took out non-ASCII chars, and have not rechecked that this
#works with the corresponding octal chars, there could be some slips in
#this text.


global outfilename, outvar, outwin,hebrew_string_flag, hebrew_text_flag,
    screenwidth,screenheight,markers

procedure main()
#message() creates a standard Mac message box
    if message("Do you wish to create a new text or print an old one?","New",
        "Old") then newtext() else
        oldtext()
#Empty and hide the interactive window
    wset(0,5)
    wset(0,0)
end


procedure newtext()
    set_markers()
    get_info()
    get_screensize()
    create_file()
    go()
end

procedure oldtext()
#getfile() allows selection of a file already available
    outfilename := getfile("Please select file.",,)
#attempt to open a window with the name of the file
    if not (outwin := wopen(outfilename,"f")) then stop()
#put a font in this window which has Hebrew letters in high ASCII numbers
    wfont(outwin,"Ivrit")
#use 12-point
    wfontsize(outwin,12)
#show the window. The user wishing to edit must make the window active
#and use the appropriate alt keys to edit the Hebrew text. This is not
#necessary when using the transcription initially
    wset(outwin,1)
    if message("Do you wish to edit? (Press return when through editing.)","Yes","No") then
            read()
    if message("Do you wish to print?","Yes","No") then
#send the window to the printer if the user desires
            wprint(outwin,1,1)
end

procedure set_markers()
#five letters preceding these characters take a special final shape
    markers := ' ,.;:-\324\"?)]}'
end


procedure get_info()
local dimlist
    outfilename := gettext("What is the name of your output file?",,"Cancel")
    if /outfilename then stop()
#the program has to know what is the principal language in order to leave
#blanks at paragraph endings properly. When the text flag is set, then the
#program overall is operating in Hebrew mode. When the string flag is set
#the current string is Hebrew
    if message("What is the principal language of the text?","Hebrew","English") then
        hebrew_string_flag := hebrew_text_flag := 1
    if \hebrew_text_flag then {
        if not message("The principal language used is Hebrew.","Okay","Cancel") then
        stop()} else
    if not message("The principal language used is English.","Okay","Cancel") then
        stop()
end

procedure get_screensize()
local dimlist
#&screen is a list. Work with the old standard mac screen
    dimlist := &screen
    screenheight := dimlist[3]
    screenwidth := dimlist[4]
    if screenwidth > 470 then screenwidth := 470
end


procedure create_file()
#arrange the various fonts and sizes
    outwin := wopen(outfilename,"n")
    outvar := open(outfilename,"w")
    wsize(0,screenwidth,(screenheight / 2 - 40))
    wsize(outwin,screenwidth,(screenheight / 2 - 40))
    wfont(outwin,"Ivrit")
    wfontsize(outwin,12)
    wfont(0,"Geneva")
    wfontsize(0,12)
#position windows
    wmove(0,0,40)
    wmove(outwin,0,screenheight / 2 + 20)
    wset(outwin,1) #show the output window
end

procedure process(l)
local cursor,substring,newline
if *l = 0 then return " "
    cursor := 1
    newline := ""
#look for a tilde, and piece together a new line accordingly
    l ? while substring := tab(upto('~')) do {
    move(1)
    if \hebrew_string_flag then substring := hebraize(substring)
    if /hebrew_text_flag then newline ||:= substring else
        newline := (substring || newline)
#string flag toggle
    (/hebrew_string_flag := 1) | (hebrew_string_flag := &null)
    cursor := &pos}
    substring := l[cursor:0]
    if \hebrew_string_flag then substring := hebraize(substring)
    if /hebrew_text_flag then newline ||:= substring else
        newline := (substring || newline)
return newline
end

procedure justify(l)
#doesnt give perfect right justification, but its good enough
local stringlength,counter,n,increment,newline
    stringlength := wtextwidth(outwin,l)
    newline := l
    increment := 1
    while stringlength < screenwidth do {
        counter := 0
        l ? every n := upto(' ') do {
                    newline[n + (counter * increment)] := "  "
                    counter +:= 1
                    stringlength +:= 4
                    if stringlength >= screenwidth then break}
        increment +:= 1}
return newline
end

procedure go()
#the appearence of the Hebrew/English window lags one line behind the
#input window
local line,line2,counter,mess
    counter := 0
    line := read()
#octal 263 is option-period.
    if line == "\263" then stop()
    while (line2 := read()) ~== "\263" do {
        counter +:= 1
        if ((not match(" ",line2)) & (*line2 ~= 0)) then
        line := justify(process(line)) else
          if /hebrew_text_flag then line := process(line) else
                line := rt(process(line))
        if (wtextwidth(outwin,line) - screenwidth) > 10 then {
            mess := "Warning. Line " || counter || " is " || (wtextwidth(outwin,line) -
            screenwidth) || " pixels too long."
            message(mess,"Okay","")}
        write(outvar,line)
        line := line2}
    if /hebrew_text_flag then line := process(line) else
        line := rt(process(line))
            if (wtextwidth(outwin,line) - screenwidth) > 10 then {
            mess := "Warning. Last Line is " || (wtextwidth(outwin,line) -
            screenwidth) || " pixels too long."
            message(mess,"Okay","")}
    write(outvar,line)
    if message("Do you wish to print?","Yes","No") then wprint(outwin,1,1)
    close(outvar)
    wclose(outwin,"")
end

procedure hebraize(l)
static s2,s3
#' is used for aleph. For the abreviation sign use either alt-] which gives
#an appropriate sign, or alt-' which is easier to remember but gives a funny
#looking digraph on the screen
    initial{ s2 := "u\'\276\324bvgdhwzHTykKlmMnNs`pfFcCqr$\247tx\261\335(){}[]X"
                     s3 := "\267\324\'\'\272\272\355\266\372\267\275\305\303\264\373\373\302\265_
                                     \265\176\176\247\322\304\304\304\215\215\317\250\246\244\240_
                                    \373+$)(}{][\373"}
#the following (1) inserts initial aleph in case the student has forgotten it
#(2) takes care of final x with vowel (all other finals are vowelless in
#modern Hebrew (3) takes out vowels except u which is usually represented in
#modern Hebrew (4) takes care of other finals (5) converts to Hebrew letters
#(6) reverses to Hebrew direction
    l := reverse(map(finals(devowel(xa(aleph(l)))),s2,s3))
return l
end

procedure aleph(l)
#inserts an aleph in words beginning with vowels only
#this alters the duplicate line; compare procedure devowel which rebuilds
#the line from scratch
local newl,offset
    newl := l
    offset := 0
    if upto('aeiou',l[1]) then {
        offset +:= 1
        newl[1] := ("\'" || l[1])}
        l ?  while tab(upto(' ')) do {
                        tab(many(' '))
                        if upto('aeiou',l[&pos]) then {
                            newl[&pos + offset] := ("\'" || l[&pos])
                            offset +:= 1}}
return newl
end

procedure xa(s)
#takes care of the special case of final xa
local substr,newstr
    newstr := ""
    s ||:= " "
    s ? {while substr := tab(find("xa")) || move(2) || tab(any(markers)) do {
                    substr[-3] := char(170)
                    newstr ||:= substr}
                newstr ||:= s[&pos:-1]}
return newstr
end


procedure finals(l)
#arranges the final letters
static finals,corresp
local newline
initial {finals := 'xmncf'
                     corresp := table("")
                     corresp["x"] := "\301"
                     corresp["m"] := "\243"
                     corresp["n"] := "\242"
                     corresp["f"] := "\354"
                     corresp["c"] := "\260"}
    newline := l
    l ? while tab(upto(finals)) do {
                move(1)
                if (any(markers)) | (&pos = *l + 1) then
                    newline[&pos - 1] := corresp[l[&pos - 1]]
                                                                    }
return newline
end

procedure rt(l)
#for right justification; chars are of different size
local stringlength,newline
    stringlength := wtextwidth(outwin,l)
    newline := l
    if (screenwidth-stringlength) > 0 then
    newline := (repl(" ",(screenwidth-stringlength +2) / 4) || l)
return newline
end

procedure devowel(l)
local newline,substring
    newline := ""
    l ? {while substring := tab(upto('aeio')) do {
        newline ||:= substring
        move(1)}
        newline ||:= l[&pos:0]}
return newline
end

From icon-group-request  Mon Feb 17 00:08:37 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 17 Feb 92 00:08:37 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA01005; Mon, 17 Feb 92 00:08:34 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA29116; Sun, 16 Feb 92 23:04:29 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 16 Feb 92 19:45:07 GMT
From: world!ksr![e-mail]  (Tim Peters)
Organization: Kendall Square Research Corp.
Subject: Re: Lists, Timing, and Memory Consumption
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Bewig) writes:
>I've been studying the chapter on lists in the icon implementation book. ...
> ...[stuff deleted]...
>...
>1) Is there a better way to extract the amount of block memory used
>from the &storage keyword?  What I did is just too ugly.

Suggest hiding the trickery in a procedure.  E.g.,

procedure block_memory()
    local temp
    every temp := &storage  # block memory is the last one
    return temp
end

Co-expressions are another way, but (I believe) less portable.

>2) When pre-initializing, why does the memory consumed per item vary?
>...
>3) Memory consumed per item for successive insertions also varies, ...
>...  Why?

Suspect you'll be surprised if you put the line

    every write(!memory)

at the end of your program; don't think you quite managed to measure
what you intended to measure.  Here are all the lines that affect the
`memory' vrbl:

>procedure main(args)
>    ...
>    memory := []
>    ...
>    every n := !trials do {
>     ...
>     every put(memory, -&storage)
>     ...
>     i := 0
>     every s := &storage do memory[i +:= 1] +:= s
>     writes(right(memory[3], 10), right(timer, 8))
>     ...
>     every put(memory, -&storage)
>     ...
>     i := 0
>     every s := &storage do memory[i +:= 1] +:= s
>     writes(right(memory[3], 12), right(timer, 8))
>     ...

The scoop is that `memory' keeps growing in length (6 additional
elements are appended on each loop iteration), but the elements after
memory[3] are never referenced.     Expect that what you really want is to
delete the
    memory := []
line before the loop and insert it before each of the two `put' lines.

When I did that, the bytes/element reported for the preinitialized case
settled down to a very steady 8; in the successive-insertion case, I
believe Icon needs additional memory to chain in overflow blocks as
needed.

>The moral of the story is to pre-initialize lists whenever possible so
>that space is allocated more efficiently, especially when making a
>large number of searches in a static array.

I don't know much about Icon's implementation, but believe your
conclusion holds (albeit with somewhat less force) anyway; on the other
hand, there's almost no measurable difference until the number of
elements in the list is on the order of a thousand, so for "almost all"
lists I wouldn't worry about it.

was-actually-quite-surprised-at-how-efficiently-icon-managed-to-implement-
   dynamic-length-list-indexing!-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

ps:  for comparison, here's the output of the program after making the
changes described above; this is on a Solbourne (souped-up SPARC):

        Pre-initialize List           Successive Insertions

       Block  Set-Up  Search       Block  Set-Up  Search
 Items      Memory   Time       Time          Memory   Time    Time
------      ------  ------  ------      ------  ------  ------
    25         248       0       0     420      16       0
   100         848       0       0    1184       0       0
   500        4048       0      17    5200      16       0
  1000        8048      34      33       11336      33      17
  2000       16048      50      67       16836      66      67
  5000       40048     133     117       55912     150     167
 10000       79936     266     250       83644     300     317
 25000      199936     650     600      281128     766     800
 50000      399936    1334    1250      421412    1566    1650

>>> END OF MSG

From [e-mail]  Tue Feb 18 13:35:46 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 18 Feb 92 13:35:46 MST
Received: from netcom.netcom.com by optima.cs.arizona.edu (4.1/15)
    id AA09531; Tue, 18 Feb 92 13:35:44 MST
Received: by netcom.netcom.com (4.1/SMI-4.1)
    id AA15491; Tue, 18 Feb 92 12:36:10 PST
Date: Tue, 18 Feb 92 12:36:10 PST
From: [e-mail] (Phil Bewig)
Message-Id: <[e-mail]>
Apparently-To: [e-mail]

Tim Peters, responding to my earlier post, writes:
    The scoop is that 'memory' keeps growing in length but the
    elements after memory[3] are never referenced.

Oops!  Kernighan and Plauger's book The Elements of Programming
Style taught me that ugly code is quite frequently wrong, too.
I think I'll have to re-read that classic book.

Tim Peters also writes:
    was-actually-quite-surprised-at-how-efficiently-icon-
    managed-to-implement-dynamic-length-list-indexing!

So was I.  In fact, the first chapter I read from the implementation
book was the chapter on lists, to see how they did it.

From icon-group-request  Tue Feb 18 20:36:36 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 18 Feb 92 20:36:36 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA00482; Tue, 18 Feb 92 20:36:32 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA03670; Tue, 18 Feb 92 19:26:54 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 18 Feb 92 22:10:31 GMT
From: van-bc!rsoft!agate!spool.mu.edu!sdd.hp.com!think.com!rpi!sarah!eve.albany.edu![e-mail]  (The Sea Nymph)
Organization: State University of New York at Albany
Subject: implementation book[s]?
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]


I have only seen one book on implementing Icon (in C). Unfortunately
I can't remember the specific title or author.. but in general,
does anyone know if there is more than one book, and can you
tell me what book[s] there is/are?

many thanks,
lg

****************IAMNOTASIGNATUREIAMAFREETHINKINGINDIVIDUAL******************

From dorsaidm![e-mail]  Wed Feb 19 14:44:00 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 19 Feb 92 14:44:00 MST
Received: from uu.psi.com by optima.cs.arizona.edu (4.1/15)
    id AA26562; Wed, 19 Feb 92 14:42:25 MST
Received: from dorsaidm.UUCP by uu.psi.com (5.65b/4.1.011392-PSI/PSINet)
    id AA18826; Wed, 19 Feb 92 16:06:41 -0500
Received: by dorsai.com (1.64/waf)
    via UUCP; Wed, 19 Feb 92 15:39:26 EST
    for cs.arizona.edu!icon-group
To: [e-mail]
Subject: ICON Procedures for Reading and Writing Standard MIDI Files
From: [e-mail] (Jeff Harrington)
Message-Id: <[e-mail]>
Date: Wed, 19 Feb 92 15:39:26 EST
Organization: The Dorsai Diplomatic Mission, New York's Computer Consulate

I am interested in archive sites or individuals who have ICON
code for this purpose.  I am currently developing such a set of
procedures and was wondering if others had done work in this area yet.

I am developing the capability for algorithmic composition and
decomposition ;) of MIDI files and MIDI files containing "gestural"
MIDI streams.  I would like to be able to convert such files to
human readable text and back.

Thanks for your consideration of this project.

Jeff Harrington
[e-mail]

From [e-mail]  Thu Feb 20 02:16:17 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 20 Feb 92 02:16:17 MST
Received: from chenas.inria.fr by optima.cs.arizona.edu (4.1/15)
    id AA06911; Thu, 20 Feb 92 02:16:10 MST
Received: from laas.laas.fr by chenas.inria.fr (5.65c8d/91.12.15)
    via Fnet-EUnet id AA04012; Thu, 20 Feb 1992 10:15:59 +0100 (MET)
Received: by laas.laas.fr, Thu, 20 Feb 92 10:11:40 +0100,Sendmail 5.61+
Date: Thu, 20 Feb 92 10:11:40 +0100
From: Patrick Senac <[e-mail]>
Message-Id: <[e-mail]>
Return-Receipt-To: [e-mail]
To: [e-mail]
Subject: How to get Icon ?

 Could you tell me please how to get a free software version of an Icon
compiler ( for MS-DOS )from an ftp with your university.
I am researcher in CS at LAAS in Toulouse, France,
and I am interested by the Icon's string handling capabilities.

Thank You very much.


From ralph  Fri Feb 21 10:28:44 1992
Date: Fri, 21 Feb 92 10:28:44 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by cheltenham.cs.arizona.edu; Fri, 21 Feb 92 10:28:44 MST
To: icon-group
Subject: Version 8.5 of Icon

Executables and source code for Version 8.5 of Icon for MS-DOS are
now available by anonymous FTP from cs.arizona.edu.

    cd /icon/interpr/packages/msdos

and look around.

Stand-alone Macintosh executables are in the parallel macintosh
subdirectory.

These files will show up on our RBBS in a couple of days.


    Ralph Griswold / Department of Computer Science
    The University of Arizona / Tucson, AZ 85721

    [e-mail] / uunet!arizona!ralph

    voice: 602-621-6609 / fax: [phone]

From [e-mail]  Sat Feb 22 07:45:36 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 22 Feb 92 07:45:36 MST
Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15)
    id AA02828; Sat, 22 Feb 92 07:45:32 MST
Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12252) id
 <[e-mail]>; Sat, 22 Feb 1992 08:46 CST
Date: Sat, 22 Feb 1992 08:46 CST
From: Chris Tenaglia - 257-8765 <[e-mail]>
Subject: Word Finder Puzzle
To: [e-mail]
Message-Id: <[e-mail]>
X-Organization: Medical College of Wisconsin (Milwaukee, WI)
X-Vms-To: IN%"[e-mail]"


I noticed a word finder puzzle in comp.lang.icon this past week from
Richard Goerwitz. Working from a VMS platform, and lacking some of the
links he had, it took me a little while to get it working. But it was
intriguing, and I recalled I forgot to post a holiday code for the
Valentines/Presidents day. So I'm including my hack of a word finder
puzzle generator. I think mine uses more 'brute force' than Richards'
and I've only tested it with 8 to 12 words. It should work as well in
DOS or Unix. It seems to take too long (probably has too much table
copying). Oh well. Enjoy!

Chris Tenaglia (System Manager) |  "The past explained,
Medical College of Wisconsin    |   the future fortold,
8701 W. Watertown Plank Rd.     |   the present largely appologized for."
Milwaukee, WI 53226             |   Organon to The Doctor
[phone]                   |
[e-mail], mcwmis!tenaglia

############################################################
#                                                          #
# puzz.icn          2/21/92          by tenaglia           #
#                                                          #
# this program generates a word search puzzle              #
# usage : puzz <word_list_file >puzz_out_file x y          #
#                                                          #
############################################################

global matrix,      # the actual puzzle board
       width,       # width of the puzzle
       height,      # height of the puzzle
       completed    # number of completed word placements

procedure main(param)
#
# initial set up : x=20, y=20 by default
#
  width  := param[1] | 20
  height := param[2] | 20
  words  := []
#
# load words to place in a space delimited
# file. more than one word per line is ok.
#
  while line := map(read()) do
    {
    tokens := parse(line,' \t')
    while put(words,pop(tokens))
    }
#
# get ready for main processing
#
  matrix    := table(" ")
  pass      := 0
  completed := 0
  &random:= map(&clock,":","0")
#
# here's the actual word placement rouinte
#
  every word := !words do place(word)
#
# fill in the unchosen areas with random alphas
#
  every i := 1 to height do
    every j := 1 to width do
      if matrix[i||","||j] == " " then
         matrix[i||","||j] := ?(&ucase)
#
# output results (for the test giver, words are lcase, noise is ucase)
#
  write(completed," words inserted out of ",*words," words.\n")
  write("\nNow for the puzzle you've been waiting for! (ANSWER)\n")
  every i := 1 to height do
    {
    every j := 1 to width do writes(matrix[i||","||j]," ")
    write()
    }
#
# output results (for the test taker, everything is upper case
#
  write("\fNow for the puzzle you've been waiting for! (PUZZLE)\n")
  every i := 1 to height do
    {
    every j := 1 to width do writes(map(matrix[i||","||j],&lcase,&ucase)," ")
    write()
    }
  end

#
# this procedure tries to place the word in a copy of the matrix
# if successful the updated copy is moved into the original
# if not, the problem word is skipped after 20 tries
#
procedure place(str)

  static xstep,ystep
  initial {
          xstep := [0,1,1,1,0,-1,-1,-1]
          ystep := [-1,-1,0,1,1,1,0,-1]
          }
  pass := 0

  repeat  {
  if (pass +:= 1) > 20 then
    {
    write("skipping ",str)
    fail
    }
  direction := ?8
  xinc      := integer(xstep[direction])
  yinc      := integer(ystep[direction])

  if xinc < 0 then x := *str + ?(width - *str)
  if xinc = 0 then x := ?height
  if xinc > 0 then x := ?(width - *str)

  if yinc < 0 then y := *str + ?(height - *str)
  if yinc = 0 then y := ?width
  if yinc > 0 then y := ?(height - *str)

  if (x < 1) | (y < 1) then stop(str," too long.")

  construct := copy(matrix)
  item      := str
  write("placing ",item)
  every byte := !item do
    {
    if (construct[x||","||y] ~== " ")  &
       (construct[x||","||y] ~== byte) then break next
    construct[x||","||y] := byte
    x +:= xinc
    y +:= yinc
    }
  matrix     := copy(construct)
  completed +:= 1
  return "ok"
  } # end repeat
  return "ok"
  end

#
# parse a string into a list with respect to a delimiter (cset)
#
procedure parse(line,delims)
  static chars
  chars  := &cset -- delims
  tokens := []
  line ? while tab(upto(chars)) do put(tokens,tab(many(chars)))
  return tokens
  end


From icon-group-request  Sat Feb 22 13:12:40 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 22 Feb 92 13:12:40 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA11503; Sat, 22 Feb 92 13:12:34 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA05518; Sat, 22 Feb 92 11:54:54 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 6 Feb 92 15:41:29 GMT
From: hsi!mlfarm!rosie![e-mail]  (Ronald Florence)
Organization: Maple Lawn Farm, Stonington, CT
Subject: mr.icn - a mail (and news) reader
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Mr is a simple reader for mail.  It won't replace elm, mush, mailtool,
or the emacs mail readers, but it is small, quick, easy-to-use, and
robust.  Mr has commands to page, reply-to, save, append, print,
forward, pipe, conceal and reveal headers, originate, delete, and
undelete mail.  An alternate mailspool, or a newspool created by
bsnews, a news system for leaf nodes, can be specified on the command
line.  Mr is written entirely in Icon.

To build mr, you need iolib.icn, available from the IPL.  Rename
Makefile.unix or Makefile.dos to Makefile, configure mr.icn
(instructions are in the header comments), and do `make'.  The Unix
Makefile includes an install option.  On a non-Unix system, make sure
the TERM and TERMCAP environmental variables are set correctly; see
the comments in iolib.icn if you are not familiar with termcap.  Mr
has not been tested on ms-dos: it might run up against memory limits
on large mail spools, and while the ms-dos pseudo-pipes in popen.icn
should work to send a mail message thru a simple pipe command like
`uudecode' or `unshar', they probably will not work on a pipeline like
`pretty-formatter | print-spooler'.

A list of the commands is available by entering `h' or `?' in mr.  The
shar file also included a man page, and for those without troff, a
formatted version of the man page using backspaces for bolds and
underlines.

In the interest of portability and simplicity, mr does not use getch()
command input.  Nor does it include a lot of other bells and whistles
that are pretty standard in sophisticated mail readers.  Mr might be
useful to someone with simpler mail needs.

Ronald Florence


#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
#    mr.icn
#    popen.icn
#    mr.man
#    Makefile.unix
#    Makefile.dos
#    manpage.mr
# This archive created: Thu Feb  6 10:24:02 1992
# By:    Ronald Florence (Maple Lawn Farm, Stonington, CT )
export PATH; PATH=/bin:/usr/bin:$PATH
echo shar: "extracting 'mr.icn'" '(11250 characters)'
if test -f 'mr.icn'
then
    echo shar: "will not over-write existing file 'mr.icn'"
else
sed 's/^X//' << \SHAR_EOF > 'mr.icn'
X############################################################################
X#
X#    Name:    mr.icn
X#
X#    Title:    Mail (and News) Reader
X#
X#    Author:    Ronald Florence ([e-mail])
X#
X#    Date:    7 February 1992
X#
X#    Version: 1.0
X#
X############################################################################
X#
X#  This simple mail reader will also work with bsnews news spools (see
X#  comp.sources.misc).
X#
X#  Configuration:
X#    Editor    for replies or new mail.
X#    Host      optional upstream routing address for outgoing mail;
X#        a domained Host is appended to the address, a uucp
X#        Host prefixes the address.
X#    Print_cmd     command to format and/or spool material for the printer.
X#    Mail_cmd      the system mailer (usually sendmail, smail, or mail).
X#    Ignore      a list of headers to ignore when paging messages.
X#
X#    On non-Unix systems, change DUNNO in the Mailspool assignment to
X#    the full path of the default mailspool.  Ms-dos users could set
X#    dir in popen.icn to a directory on a virtual (RAM) disk.  Make
X#    sure the TERMCAP and TERM environment variables are set correctly
X#    for displays other than ms-dos mono.  If you are not familiar with
X#    termcap, see the header section of iolib.icn.
X#
X############################################################################
X
Xlink popen, iolib
Xglobal Host, Editor, Spool, Status, Ignore,
X       Print_cmd, Mail_cmd, Mailspool, Md, Me, Ce
X
Xprocedure main(arg)
X  local i, cmd, art
X                # configuration
X  Editor := "vi"
X  Host := &null
X  Print_cmd := "mp -F | lpr"
X  Mail_cmd := "/usr/lib/sendmail -t"
X  Ignore := ["From ", "Message-Id", "Received", "Return-path", "\tid",
X         "Path", "Xref", "References", "X-mailer", "Errors-to",
X         "Resent-Message-Id", "Status", "X-lines"]
X  if "UNIX" == &features then
X      Mailspool := "/usr/spool/mail/" || getenv("LOGNAME"|"USER")
X  else Mailspool := getenv("MAILSPOOL") | "DUNNO"
X
X                # end of configuration
X
X  Md := ckval("md" | "so") | "\e[1m"
X  Me := ckval("me" | "se") | "\e[m"
X  Ce := (ckval("up") || ckval("ce")) | "\e[A\e[K"
X  (*arg > 0) & Mailspool := arg[1]
X  i := readin(Mailspool)
X  headers(i)
X  repeat {
X    cmd := query("\n[" || i || "/" || *Status || "]: ", " ")
X    if integer(cmd) & (cmd > 0) & (cmd <= *Status) then headers(i := cmd)
X    else case map(!cmd) of {
X      "a":  save(query("Append to: "), i, "append")
X      "x":  upto('yY', query("Are you sure? ")) & exit(1)
X      "l":  headers(i)
X      "r":  reply(i)
X      "d":  { (Status[i] ++:= 'D'); writes(Ce); i := inc(i) }
X      "f":  forward(query("Forward to: "), i)
X      "g":  readin(Mailspool, "update") & headers(i)
X      "s":  save(query("Filename: "), i)
X      "q":  quit()
X      "|":  pipeto(query("Command: "), i)
X      " ":  { showart(i); i := inc(i) }
X      "-":  { if (i -:= 1) = 0 then i := *Status; showart(i) }
X      "n"|"+":  showart(i := inc(i))
X      "u":  { (Status[i] --:= 'D'); writes(Ce); i := inc(i) }
X      "m":  newmail(query("Address: "))
X      "p":  { pipeto(Print_cmd, i) & Status[i] ++:= 'P'; writes(Ce) }
X      "v":  showart(i, "all")
X      "!":  { system(query("Command: "))
X          write() & query("Press <return> to continue") }
X      "?"|"h":  help()
X      default: { writes(Ce); writes("\^g") }
X    }
X  }
Xend
X
X                # Read the mail spool into a list of
X                # lists and set up a status list.
Xprocedure readin(spoolname, update)
X  local sf, i, article
X
X  Spool := []
X  \update | Status := []
X  sf := open(spoolname) | stop("Can't read " || spoolname)
X  i := 0
X  every !sf ? {
X    ="From " & {
X      ((i +:= 1) > 1) & put(Spool, article)
X      article := []
X      /update | /Status[i] & put(Status, 'N')
X    }
X    (i > 0) & put(article, &subject)
X  }
X  (i > 0) & {
X    put(Spool, article)
X    i := 1
X  }
X  close(sf)
X  return i
Xend
X
X                # Parse messages for author & subject,
X                # highlight the current message.
Xprocedure headers(art)
X  local hlist, i, entry, author, subj
X
X  hlist := []
X  every i := 1 to *Status do {
X    entry := if i = art then Md else ""
X    entry ||:= left(i, 3, " ") || left(Status[i], 4, " ")
X    author := ""
X    subj := ""
X    while  (*author = 0) | (*subj = 0) do !Spool[i] ? {
X      ="From: " & author := tab(0)
X      ="Subject: " & subj := tab(0)
X      (*&subject = 0) & break
X    }
X    entry ||:= " [" || right(*Spool[i], 3, " ") || ":"
X    entry ||:= left(author, 17, " ") || "]  " || left(subj, 45, " ")
X    (i = art) & entry ||:= Me
X    put(hlist, entry)
X  }
X  put(hlist, "")
X  more(Mailspool, hlist)
Xend
X
X                # Check if any messages are deleted;
X                # if the spool cannot be written,
X                # write a temporary spool.  Rename
X                # would be convenient, but won't work
X                # across file systems.
Xprocedure quit()
X  local msave, f, tfn, i
X
X  every !Status ? { find("D") & break msave := 1 }
X  \msave & {
X    (f := open(Mailspool, "w")) | {
X      f := open(tfn := tempfile("spool."), "w")
X      write("Cannot write " || Mailspool || ".  Saving changes to " || tfn)
X    }
X    every i := 1 to *Status do {
X      find("D", Status[i]) | every write(f, !Spool[i])
X    }
X  }
X  exit(0)
Xend
X
X
Xprocedure save(where, art, append)
X  local mode, outf
X
X  mode := if \append then "a" else "w"
X  outf := open(where, mode) | { write("Can't write ", where) & fail }
X  every write(outf, !Spool[art])
X  Status[art] ++:= 'S'
X  return close(outf)
Xend
X
X
X                # A pipe for Unix; pseudo-pipe for ms-dos.
Xprocedure pipeto(cmd, art)
X  local p
X
X  p := popen(cmd, "w")
X  every write(p, !Spool[art])
X  return pclose(p)
Xend
X
X
X                # Lots of case-insensitive parsing.
Xprocedure reply(art)
X  local tfn, fullname, address, quoter, date, id, subject, newsgroup, refs, r
X
X  r := open(tfn := tempfile("reply."), "w")
X  every !Spool[art] ? {
X    tab(match("from: " | "reply-to: ", map(&subject))) & {
X      if find("<") then {
X    fullname := tab(upto('<'))
X    address := (move(1), tab(find(">")))
X      }
X      else {
X    address := trim(tab(upto('(') | 0))
X    fullname := (move(1), tab(find(")")))
X      }
X      while match(" ", \fullname, *fullname) do fullname ?:= tab(-1)
X      quoter := if *\fullname > 0 then fullname else address
X    }
X    tab(match("date: ", map(&subject))) & date := tab(0)
X    tab(match("message-id: ", map(&subject))) & id := tab(0)
X    match("subject: ", map(&subject)) & subject := tab(0)
X    match("newsgroups: ", map(&subject)) & newsgroup := tab(upto(',') | 0)
X    match("references: ", map(&subject)) & refs := tab(0)
X    (\address & *&subject = 0) & {
X      writes(r, "To: " || address)
X      write(r, if *\fullname > 0 then " (" || fullname || ")" else "")
X      \subject & write(r, subject)
X      \newsgroup & write(r, newsgroup)
X      \refs & write(r, refs, " ", id)
X      write(r, "In-reply-to: ", quoter, "'s message of ", date);
X      write(r, "\nIn ", id, ", ", quoter, " writes:\n")
X      break
X    }
X  }
X  every write(r, " > ", !Spool[art])
X  send(tfn, address) & {
X    Status[art] ++:= 'RO'
X    Status[art] --:= 'N'
X  }
Xend
X
X                # Put user in an editor with a temp
X                # file, query for confirmation, if
X                # necessary rewrite address, and send.
Xprocedure send(what, where)
X  local edstr, mailstr, done
X  static console
X
X  initial {
X    if "UNIX" == &features then console := "/dev/tty"
X    else if "MS-DOS" == &features then console := "CON"
X    else write("Need to configure `console' in mr.icn.") & fail
X  }
X  edstr := getenv("EDITOR") | Editor || " " || what || " < " || console
X  system(edstr)
X  upto('nN', query( "Send to " || where || " y/n? ")) & {
X    if upto('yY', query("Save your draft y/n? ")) then
X      writes(Ce) & write("Your draft is saved in " || what || "\n")
X    else writes(Ce) & remove(what)
X    fail
X  }
X  writes(Ce)
X  \Host & not find(map(Host), map(where)) & upto('!@', where) & {
X    find("@", where) & where ? {
X      name := tab(upto('@'))
X      where := (move(1), tab(upto(' ') | 0)) || "!" || name
X    }
X    if find(".", Host) then where ||:= "@" || Host
X    else where := Host || "!" || where
X  }
X  mailstr := Mail_cmd || " " || where || " < " || what
X  done := system(mailstr)
X  remove(what)
X  return done
Xend
X
X
Xprocedure forward(who, art)
X  local out, tfn
X
X  out := open(tfn := tempfile("forward."), "w")
X  write(out, "To: " || who)
X  write(out, "Subject: FYI (forwarded mail)\n")
X  write(out, "-----[begin forwarded message]-----")
X  every write(out, !Spool[art])
X  write(out, "------[end forwarded message]------")
X  send(tfn, who) & Status[art] ++:= 'F'
Xend
X
X
Xprocedure newmail(address)
X  local out, tfn
X
X  out := open(tfn := tempfile("mail."), "w")
X  write(out, "To: " || address)
X  write(out, "Subject:\n")
X  return send(tfn, address)
Xend
X
X
Xprocedure showart(art, eoh)
X  local out
X
X  out := []
X  every !Spool[art] ? {
X    /eoh := *&subject = 0
X    if \eoh | not match(map(!Ignore), map(&subject)) then put(out, tab(0))
X  }
X  more("Message " || art, out, "End of Message " || art)
X  Status[art] ++:= 'O'
X  Status[art] --:= 'N'
Xend
X
X
Xprocedure help()
X  local hlist
X  static pr, sts
X
X  initial {
X    pr := ["Append message to a file",
X       "Delete message",
X       "eXit, without saving changes",
X       "Forward message",
X       "Get new mail",
X       "Help",
X       "List headers",
X       "Mail to a new recipient",
X       "Next message",
X       "Print message",
X       "Quit, saving changes",
X       "Reply to message",
X       "Save message",
X       "Undelete message",
X       "View all headers",
X       "| pipe message to a command",
X       "+ next message",
X       "- previous message",
X       "! execute command",
X       "# make # current message"]
X    sts := ["New", "Old", "Replied-to", "Saved",
X        "Deleted", "Forwarded", "Printed"]
X  }
X  hlist := []
X  every !pr ? put(hlist, "  " || tab(upto(&ucase++'!|+-#') \1) ||
X          Md || move(1) || Me || tab(0))
X  put(hlist, "")
X  every !sts ? put(hlist, "  " || tab(upto(&ucase)) ||
X           Md || move(1) || Me || tab(0))
X  put(hlist, "")
X  more("Commands & Status Symbols", hlist)
Xend
X
X                # The second parameter specifies a
X                # default response if the user presses
X                # <return>.
Xprocedure query(prompt, def)
X  local ans
X
X  writes(Ce)
X  writes(prompt)
X  ans := read()
X  return (*ans = 0 & \def) | ans
Xend
X
X                # Increment the count, then cycle
X                # through again when user reaches the
X                # end of the list.
Xprocedure inc(art)
X
X  if (art +:= 1) > *Status then art := 1
X  return art
Xend
X
X
Xprocedure more(header, what, footer)
X  local ans, lines
X  static li, so, se, co, cl, us, ue
X
X  initial {
X    li := ckval("li") | 25
X    co := ckval("co") | 80
X    so := ckval("so") | "\e[7m"
X    se := ckval("se") | "\e[m"
X    cl := ckval("cl") | "\e[H\e[2J"
X    us := ckval("us"|"so") | "\e[4m"
X    ue := ckval("ue"|"se") | "\e[m"
X  }
X  writes(cl)
X  if \header then {
X    write(us || header || ue)
X    lines := 1
X  }
X  else lines := 0
X  every !what ? {
X    write(tab(0))
X    ((lines +:= 1 + *&subject/co) % (li - 1) = 0) & {
X      writes(so || "-MORE-(", (100 > (lines - 2)*100/*what) | 100, "%)" || se)
X      ans := read() & writes(Ce)
X      upto('nNqQ', ans) & fail
X    }
X  }
X  \footer & {
X    writes(so || footer || se)
X    read() & writes(Ce)
X  }
Xend
X
X
Xprocedure ckval(titem)
X  static termcap
X
X  initial {
X    if \getenv("TERMCAP") | close(open("/etc/termcap")) then termcap := 1
X    else if "MS-DOS" == &features then termcap := &null
X    else stop("Need TERMCAP & TERM environment variables")
X  }
X  \termcap & return getval(titem)
X  fail
Xend
X
SHAR_EOF
if test 11250 -ne "`wc -c < 'mr.icn'`"
then
    echo shar: "error transmitting 'mr.icn'" '(should have been 11250 characters)'
fi
fi
echo shar: "extracting 'popen.icn'" '(1855 characters)'
if test -f 'popen.icn'
then
    echo shar: "will not over-write existing file 'popen.icn'"
else
sed 's/^X//' << \SHAR_EOF > 'popen.icn'
X########################################################################
X#
X#    Name:    popen.icn
X#
X#    Title:    Pipes for Unix and non-Unix systems
X#
X#    Author:    Ronald Florence ([e-mail])
X#
X#    Version: 1.0
X#
X#########################################################################
X#
X#  Contents:
X#
X#  popen(command, mode)
X#    mode == "w" writes to a pipe
X#    mode == "r" reads from a pipe
X#
X#  pclose(pipe)
X#
X#  On systems without real pipes (ms-dos), popen and pclose imitate
X#  pipes; pclose must be called after popen.  The code should run
X#  faster on ms-dos if dir in tempfile() points to a directory on a
X#  virtual disk.
X#
X#  On systems with real pipes, popen & pclose open and close a pipe.
X#
X##########################################################################
X
Xglobal PIPE_cmd, PIPE_fname
X
Xprocedure popen(cmd, mode)
X  local tfn, p
X
X  initial ("pipes" == &features) | {
X    PIPE_cmd := table()
X    PIPE_fname := table()
X  }
X  (type(PIPE_fname) ~== "table") & return open(cmd, mode || "p")
X  tfn := tempfile("pipe.")
X  upto('r', mode) & system(cmd || " > " || tfn)
X  p := open(tfn, mode)
X  PIPE_fname[p] := tfn
X  upto('w', mode) & PIPE_cmd[p] := cmd
X  return p
Xend
X
X
Xprocedure pclose(pipe)
X  local status
X
X  (type(PIPE_fname) ~== "table") & return close(pipe)
X  if \PIPE_cmd[pipe] then {
X    close(pipe)
X    PIPE_cmd[pipe] ||:= " < " || PIPE_fname[pipe]
X    status := system(PIPE_cmd[pipe])
X  }
X  else status := close(pipe)
X  remove(PIPE_fname[pipe])
X  PIPE_cmd[pipe] := PIPE_fname[pipe] := &null
X  return status
Xend
X
X    # Richard Goerwitz's ever-useful generator.
X
Xprocedure tempfile(template)
X  local temp_name
X  static dir
X
X  initial {
X    if "UNIX" == &features then dir := "/tmp/"
X    else dir := ""
X  }
X  every temp_name := dir || template || right(1 to 999,3,"0") do {
X    close(open(temp_name)) & next
X    suspend \temp_name
X  }
Xend
SHAR_EOF
if test 1855 -ne "`wc -c < 'popen.icn'`"
then
    echo shar: "error transmitting 'popen.icn'" '(should have been 1855 characters)'
fi
fi
echo shar: "extracting 'mr.man'" '(2580 characters)'
if test -f 'mr.man'
then
    echo shar: "will not over-write existing file 'mr.man'"
else
sed 's/^X//' << \SHAR_EOF > 'mr.man'
X.\" mr.man version 1.0
X.\" copyright 1991 Ronald Florence
X.TH MR LOCAL "7 Feb 1992"
X.SH NAME
Xmr \- mail (or news) reader
X.SH SYNOPSIS
X.B mr
X[
X.I spool
X]
X.SH DESCRIPTION
XMr is a simple reader for mail and/or news spools.  It won't obsolete
Xelm, mailtool, emacs, mush, or even /usr/ucb/Mail, but it allows a
Xreader to page, reply-to, save, append, print, forward, pipe,
Xoriginate, conceal or reveal headers, and delete or undelete mail.  Mr
Xcan also be used to read the news spools produced by the bsnews news
Xsystem for leaf nodes.
X.SH COMMANDS
XAn alternate mail or news spool can be named on the command line.  The
Xinitial display lists waiting messages:
X.ta .5i 1i 3.5i
X.sp
X.nf
X.if t .ft CR
X1    FOP    [ 22:[e-mail] (R]    How to use mr
X.ie t .ft CB
X.el .ft B
X2    DOR    [985:[e-mail]]    Improving MR (part I)
X.ie t .ft CR
X.el .ft R
X3    N    [ 61:[e-mail].]    MS-Dos Pipes
X.ft R
X.fi
X.P
XThe letters after the message number indicate the status of the
Xmessage; New, Old, Replied-to, Printed, Deleted, Saved, Forwarded.
XThe number inside the square brackets is the number of lines in the
Xmessage, followed by the author's name and/or email address, and the
Xsubject.  The current message is highlighted in bold or reverse video,
Xdepending on the capabilities of the display.  The prompt shows the
Xcurrent message number and the total number of messages.  The
Xfollowing commands can be given:
X.sp
X.nf
X.RS
XA    Append current message to a file
XD    Delete current message
XF    Forward current message
XG    Get new mail
XH    Help
XL    List headers
XM    Mail to a new recipient
XN    Next message
XP    Print current message
XQ    Quit, saving changes
XR    Reply-to current message
XS    Save current message to a file
XU    Undelete current message
XV    View all headers
XX    eXit without saving changes
X|    pipe current message to a command
X!    execute command
X#    make # current message
X+    next message
X-    previous message
X?    help
X.RE
X.fi
X.P
XPressing
X.RI < return >
Xwill page thru the current message, then advance the current message
Xnumber.  Press
X.I Q
Xor
X.I N
Xat a
X.SM MORE
Xprompt to return to the command prompt.
X.SH ENVIRONMENT
XThe
X.SM EDITOR
Xand
X.SM MAILSPOOL
Xenvironmental variables can be used to override default settings.  Mr
Xuses the
X.SM TERM
Xand
X.SM TERMCAP
Xvariables to lookup screen parameters and control strings.
X.SH SEE ALSO
Xmail(1), sendmail(1), bsnews(\s-1LOCAL\s0)
X.SH BUGS
XThe pseudo-pipes used for ms-dos cannot handle a complex command.
XSome users would undoubtedly prefer getch() style command parsing.
XThe pager used to display messages does not back-up.
X.SH AUTHOR
XRonald Florence (ron\s-2@\s0mlfarm.com).
SHAR_EOF
if test 2580 -ne "`wc -c < 'mr.man'`"
then
    echo shar: "error transmitting 'mr.man'" '(should have been 2580 characters)'
fi
fi
echo shar: "extracting 'Makefile.unix'" '(276 characters)'
if test -f 'Makefile.unix'
then
    echo shar: "will not over-write existing file 'Makefile.unix'"
else
sed 's/^X//' << \SHAR_EOF > 'Makefile.unix'
X# Makefile for mr
X
X.SUFFIXES: .icn .u1
X
X.icn.u1:
X    icont -c $<
X
X.icn:
X    icont $@
X
XBINDIR = /usr/local/bin
XMANDIR = /usr/man/mann
XMANEXT = n
X
Xmr:     popen.u1 iolib.u1 mr.icn
X    icont -u $@
X
Xinstall: mr mr.man
X    cp mr $(BINDIR)
X    cp mr.man $(MANDIR)/mr.$(MANEXT)
X
Xclean:
X    rm -f *.u[12]
SHAR_EOF
if test 276 -ne "`wc -c < 'Makefile.unix'`"
then
    echo shar: "error transmitting 'Makefile.unix'" '(should have been 276 characters)'
fi
fi
echo shar: "extracting 'Makefile.dos'" '(129 characters)'
if test -f 'Makefile.dos'
then
    echo shar: "will not over-write existing file 'Makefile.dos'"
else
sed 's/^X//' << \SHAR_EOF > 'Makefile.dos'
X# ms-dos makefile for mr
X
X.SUFFIXES: .icn .u1 .icx
X
X.icn.u1:
X    icont -c $<
X
X.icn.icx:
X    icont $*
X
Xmr.icx:    popen.u1 iolib.u1 mr.icn
SHAR_EOF
if test 129 -ne "`wc -c < 'Makefile.dos'`"
then
    echo shar: "error transmitting 'Makefile.dos'" '(should have been 129 characters)'
fi
fi
echo shar: "extracting 'manpage.mr'" '(3534 characters)'
if test -f 'manpage.mr'
then
    echo shar: "will not over-write existing file 'manpage.mr'"
else
sed 's/^X//' << \SHAR_EOF > 'manpage.mr'
X
X
X
XMR(LOCAL)                                               MR(LOCAL)
X
X
XNNAAMMEE
X       mr - mail (or news) reader
X
XSSYYNNOOPPSSIISS
X       mmrr [ _s_p_o_o_l ]
X
XDDEESSCCRRIIPPTTIIOONN
X       Mr  is  a  simple  reader for mail and/or news spools.  It
X       won't  obsolete  elm,  mailtool,  emacs,  mush,  or   even
X       /usr/ucb/Mail,  but  it allows a reader to page, reply-to,
X       save, append, print, forward, pipe, originate, conceal  or
X       reveal  headers, and delete or undelete mail.  Mr can also
X       be used to read the news spools  produced  by  the  bsnews
X       news system for leaf nodes.
X
XCCOOMMMMAANNDDSS
X       An  alternate  mail or news spool can be named on the com-
X       mand line.  The initial display lists waiting messages:
X
X       1    FOP  [ 22:[e-mail] (R]  How to use mr
X       22    DDOORR  [[998855::ggooeerr@@ssoopphhiisstt..uucchhii]]  IImmpprroovviinngg MMRR ((ppaarrtt II))
X       3    N    [ 61:[e-mail].]  MS-Dos Pipes
X
X       The letters after the message number indicate  the  status
X       of  the  message;  New, Old, Replied-to, Printed, Deleted,
X       Saved, Forwarded.  The number inside the  square  brackets
X       is  the  number  of  lines in the message, followed by the
X       author's name and/or email address, and the subject.   The
X       current  message  is highlighted in bold or reverse video,
X       depending on the capabilities of the display.  The  prompt
X       shows  the  current message number and the total number of
X       messages.  The following commands can be given:
X
X              A    Append current message to a file
X              D    Delete current message
X              F    Forward current message
X              G    Get new mail
X              H    Help
X              L    List headers
X              M    Mail to a new recipient
X              N    Next message
X              P    Print current message
X              Q    Quit, saving changes
X              R    Reply-to current message
X              S    Save current message to a file
X              U    Undelete current message
X              V    View all headers
X              X    eXit without saving changes
X              |    pipe current message to a command
X              !    execute command
X              #    make # current message
X              +    next message
X              -    previous message
X              ?    help
X
X
X
X                            7 Feb 1992                          1
X
X
X
X
X
XMR(LOCAL)                                               MR(LOCAL)
X
X
X       Pressing <_r_e_t_u_r_n> will page thru the current message, then
X       advance  the  current  message  number.  Press _Q or _N at a
X       MORE prompt to return to the command prompt.
X
XEENNVVIIRROONNMMEENNTT
X       The EDITOR and MAILSPOOL environmental  variables  can  be
X       used  to  override default settings.  Mr uses the TERM and
X       TERMCAP variables to lookup screen parameters and  control
X       strings.
X
XSSEEEE AALLSSOO
X       mail(1), sendmail(1), bsnews(LOCAL)
X
XBBUUGGSS
X       The  pseudo-pipes  used for ms-dos cannot handle a complex
X       command.  Some  users  would  undoubtedly  prefer  getch()
X       style command parsing.  The pager used to display messages
X       does not back-up.
X
XAAUUTTHHOORR
X       Ronald Florence ([e-mail]).
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X                            7 Feb 1992                          2
X
X
echo shar: "119 control characters may be missing from 'manpage.mr'"
SHAR_EOF
if test 3534 -ne "`wc -c < 'manpage.mr'`"
then
    echo shar: "error transmitting 'manpage.mr'" '(should have been 3534 characters)'
fi
fi
exit 0
#    End of shell archive
--

                Ronald Florence
                [e-mail]

From [e-mail]  Sun Feb 23 07:51:22 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 23 Feb 92 07:51:22 MST
Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15)
    id AA12627; Sun, 23 Feb 92 07:51:19 MST
Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12252) id
 <[e-mail]>; Sun, 23 Feb 1992 08:52 CST
Date: Sun, 23 Feb 1992 08:52 CST
From: Chris Tenaglia - 257-8765 <[e-mail]>
Subject: Word Puzzle Times
To: [e-mail]
Message-Id: <[e-mail]>
X-Organization: Medical College of Wisconsin (Milwaukee, WI)
X-Vms-To: IN%"[e-mail]"


I had a chance to try out the word puzzle I posted earlier on a number
of different platforms and noticed something totally unexpected.

          VAX 780          1MIP          36 sec
          VAX4500         25MIP          28 sec
          VAX6620         70MIP          33 sec
          MSDOS-286        ?MIP          11 sec
          DEC-Risc        20MIP           1 sec

This was on the same piece of code during off hours, so there were no
other competing loads. VMS icon usually doesn't make such a bad showing
but I wonder if this might be something worth looking into. Perhaps there
is some aspect of Icon and VMS where certain coding pratices should be
watched out for.

Chris Tenaglia (System Manager) | Medical College of Wisconsin
8701 W. Watertown Plank Rd.     | Milwaukee, WI 53226
[phone]                   | [e-mail], mcwmis!tenaglia


From icon-group-request  Tue Feb 25 07:40:17 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 25 Feb 92 07:40:17 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA21544; Tue, 25 Feb 92 07:40:14 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA15085; Tue, 25 Feb 92 06:32:10 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 21 Feb 92 09:58:23 GMT
From: [e-mail]  (Clinton Jeffery)
Subject: Re: Beginner questions
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

From article <[e-mail]>, by [e-mail] (Richard L. Goerwitz):
> [e-mail] (Budi Rahardjo) writes:
>
>>- I'd like to add my own function (written in C). How would
>>  I call/link that function with my icon program ?
>
> You would need to recompile the Icon run-time system with your function
Richard is right.  There is a C-callout mechanism, or you can always write
your own Icon "builtin function" that calls your C function.  The details
are not too hard once you are familiar with Icon's C-based implementation.
Lastly, note that Version 8.5 has different details than Version 8.0.

>>- Is there an ICON compiler for the MS-DOS (ie. produce .exe file) ?
>>  (I don't want to run the program with 'iconx'  :-)
Well, many Icon systems feature executable headers that call iconx when
they are run, so you don't have to type it.  Under this approach, icont
would put out a .COM file or .EXE file, but MS-DOS Icon doesn't have
this feature.  We'd love it if someone would get it working, bearing in
mind that memory is so precious under MS-DOS that only a few kilobytes
could be spared for it at runtime.  Richard's comments about a REAL Icon
compiler under MS-DOS are right on target.  Not likely to fit on less
than a 386; I don't know of anyone doing one.  Does anyone else?

>>Sorry if those questions are in the FAQ.
> There *is* no FAQ; we answer as we go.  Please don't feel you need to
> apologize.
Would anyone like to start and maintain an icon-group/comp.lang.icon FAQ?

> I'd kinda like for one of the more technically inclined readers of this
> group to post a followup to this reply.  I'm not really qualified to give
> definitive answers to your queries (although I hope I've helped sketch
> things out).
Your answers are generally very high quality, Richard.  Please don't feel
you need to apologize for them! :-)
--
Clint Jeffery, U. of Arizona Dept. of Computer Science
[e-mail] -or- {noao allegra}!arizona!cjeffery
--

From @um.cc.umich.edu:[e-mail]  Tue Feb 25 10:52:38 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 25 Feb 92 10:52:38 MST
Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15)
    id AA29961; Tue, 25 Feb 92 10:52:35 MST
Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0)
    id AA13119; Tue, 25 Feb 92 12:48:33 -0500
Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Tue, 25 Feb 92 12:47:51 EST
Date: Tue, 25 Feb 92 12:47:56 EST
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Element generation

On page 12 of the October 1991 issue of the Icon Analyst, a technique
is suggested for providing a multi-line macro definition facility for
input streams.  The essence of the method is that you have a loop of
the form:
   every s := !input do {
      ...
   }
When you encounter a macro definition, you place its lines into a list;
when you encounter a use of a macro, you "change" the value of `input'
to the list associated with the macro.

The trouble with this suggestion is that you can't make the change to
`input' in the obvious way, by executing an assignment to `input' from
within the loop.  The value (and result sequence) of `input' is
determined when you enter the loop, and subsequent assignments to
`input' are ineffective.  It's possible to get the desired effect by
breaking out of the loop and restarting it when a macro is encountered,
but the necessity of restarting the loop is not obvious from the
article.

Nevertheless, it's a useful technique to know about.

Paul Abrahams

From icon-group-request  Sat Feb 29 19:30:48 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 29 Feb 92 19:30:48 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA24504; Sat, 29 Feb 92 19:30:44 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA19317; Sat, 29 Feb 92 18:17:11 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 20 Feb 92 16:30:34 GMT
From: bonnie.concordia.ca!ccu.umanitoba.ca![e-mail]  (Budi Rahardjo)
Organization: University of Manitoba
Subject: Beginner questions
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

I've just got the Icon book and installed icont and iconx on my PC.
Some questions:

- I'd like to add my own function (written in C). How would
  I call/link that function with my icon program ?
  (The book mentioned something about 'reference 8', is this
  another document ? ftp-able ?)

- In MS-DOS how can I get a list of files in certain directory ?
  Is there an 'opendir()' function ?
  (Would be nice if I can pipe a 'dir' or 'ls' command in MS-DOS)

- Is there an ICON compiler for the MS-DOS (ie. produce .exe file) ?
  (I don't want to run the program with 'iconx'  :-)

Sorry if those questions are in the FAQ.

-- budi

--
Budi Rahardjo
<[e-mail]>      <[e-mail]>
Electrical Engineering - University of Manitoba - Canada

From icon-group-request  Sat Feb 29 20:46:05 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 29 Feb 92 20:46:05 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA26299; Sat, 29 Feb 92 20:46:02 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA22981; Sat, 29 Feb 92 19:37:21 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 28 Feb 92 07:08:19 GMT
From: uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: sample BNFs
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

#
# Here, by the way, is the sample grammar offered in the magazine
# article that got me wondering about Icon-based chart parsers:
#
<S>    ::= <NP> <VP> | <S> <CONJ> <S>
<VP>   ::= <VP> <CONJ> <VP> | <IV> ( () | <PP> ) | \
       <TV> ( <NP> | <NP> <PP> | <NP> <VP> | <REL> <S> )
<NP>   ::= <DET> ( <NP> | <ADJ> <NP> | <ADJ> <NP> <PP> | <NP> <PP> ) | \
       <ADJ> <NP> |  <N> | <N> <CONJ> <N> | \
       <NP> <CONJ> <NP>
<PP>   ::= <P> ( <NP> | <ADJ> <NP> ) | <PP> <CONJ> <PP>
<ADJ>  ::= <ADJ> <CONJ> <ADJ>
<CONJ> ::= and
<DET>  ::= the | a | his | her
<NP>   ::= her | he | they
<N>    ::= nurse | nurses | book | books | travel | arrow | arrows | \
      fortune | fortunes | report
<ADJ>  ::= outrageous | silly | blue | green | heavy | white | red | \
      black | yellow
<IV>   ::= travel | travels | report | see | suffer
<TV>   ::= hear | see | suffer
<P>    ::= on | of
<REL>  ::= that

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]         rutgers!oddjob!gide!sophist!goer

From icon-group-request  Sun Mar  1 17:35:55 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 1 Mar 92 17:35:55 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA07815; Sun, 1 Mar 92 17:35:54 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA10682; Sun, 1 Mar 92 16:20:57 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 16 Feb 92 19:45:07 GMT
From: world!ksr![e-mail]  (Tim Peters)
Organization: Kendall Square Research Corp.
Subject: Re: Lists, Timing, and Memory Consumption
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] (Phil Bewig) writes:
>I've been studying the chapter on lists in the icon implementation book. ...
> ...[stuff deleted]...
>...
>1) Is there a better way to extract the amount of block memory used
>from the &storage keyword?  What I did is just too ugly.

Suggest hiding the trickery in a procedure.  E.g.,

procedure block_memory()
    local temp
    every temp := &storage  # block memory is the last one
    return temp
end

Co-expressions are another way, but (I believe) less portable.

>2) When pre-initializing, why does the memory consumed per item vary?
>...
>3) Memory consumed per item for successive insertions also varies, ...
>...  Why?

Suspect you'll be surprised if you put the line

    every write(!memory)

at the end of your program; don't think you quite managed to measure
what you intended to measure.  Here are all the lines that affect the
`memory' vrbl:

>procedure main(args)
>    ...
>    memory := []
>    ...
>    every n := !trials do {
>     ...
>     every put(memory, -&storage)
>     ...
>     i := 0
>     every s := &storage do memory[i +:= 1] +:= s
>     writes(right(memory[3], 10), right(timer, 8))
>     ...
>     every put(memory, -&storage)
>     ...
>     i := 0
>     every s := &storage do memory[i +:= 1] +:= s
>     writes(right(memory[3], 12), right(timer, 8))
>     ...

The scoop is that `memory' keeps growing in length (6 additional
elements are appended on each loop iteration), but the elements after
memory[3] are never referenced.     Expect that what you really want is to
delete the
    memory := []
line before the loop and insert it before each of the two `put' lines.

When I did that, the bytes/element reported for the preinitialized case
settled down to a very steady 8; in the successive-insertion case, I
believe Icon needs additional memory to chain in overflow blocks as
needed.

>The moral of the story is to pre-initialize lists whenever possible so
>that space is allocated more efficiently, especially when making a
>large number of searches in a static array.

I don't know much about Icon's implementation, but believe your
conclusion holds (albeit with somewhat less force) anyway; on the other
hand, there's almost no measurable difference until the number of
elements in the list is on the order of a thousand, so for "almost all"
lists I wouldn't worry about it.

was-actually-quite-surprised-at-how-efficiently-icon-managed-to-implement-
   dynamic-length-list-indexing!-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

ps:  for comparison, here's the output of the program after making the
changes described above; this is on a Solbourne (souped-up SPARC):

        Pre-initialize List           Successive Insertions

       Block  Set-Up  Search       Block  Set-Up  Search
 Items      Memory   Time       Time          Memory   Time    Time
------      ------  ------  ------      ------  ------  ------
    25         248       0       0     420      16       0
   100         848       0       0    1184       0       0
   500        4048       0      17    5200      16       0
  1000        8048      34      33       11336      33      17
  2000       16048      50      67       16836      66      67
  5000       40048     133     117       55912     150     167
 10000       79936     266     250       83644     300     317
 25000      199936     650     600      281128     766     800
 50000      399936    1334    1250      421412    1566    1650

>>> END OF MSG

From icon-group-request  Sun Mar  1 21:22:35 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 1 Mar 92 21:22:35 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA16165; Sun, 1 Mar 92 21:22:32 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA20359; Sun, 1 Mar 92 20:11:28 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 27 Feb 92 09:31:44 GMT
From: uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: NLP & Icon
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]


############################################################################
#
#    Name:     ichartp.icn
#
#    Title:     Iconish implementation of a simple chart parser
#
#    Author:     Richard L. Goerwitz
#
#    Version: 1.2
#
############################################################################
#
#      I was reading Byte Magazine (vol. 17:2 [February, 1992]), and
#  ran into an article entitled "A Natural Solution" (pages 237-244)
#  in which a standard chart parser was described in terms of its C++
#  implementation.  The author remarked at how his optimizations made
#  it possible to parse a 14-word sentence in only 32 seconds (versus
#  146 for a straight Gazdar-Mellish LISP chart parser).  32 seconds
#  struck me as hardly anything to write home about, so started coding
#  up a quick system in Icon to see how it compared.  This library is
#  the result.
#
#      The library has a small stub main() procedure that can be used
#  to get an idea of what is going on.  If compiled, the resulting
#  program takes just a single argument - the name of a BNF file
#  containing the grammar to use for parsing.  Parsing is done
#  line-by-line on the fly, using the standard input.  The results of
#  the parse are reported using the notation for trees described in
#  Griswold & Griswold, and also in the IPL collection entitled
#  "structs.icn."  There is often more than one possible parse, and
#  these are suspended successively, as they are encountered.  Unknown
#  vocabulary is flagged immediately as an error.  The tokenizing
#  routine folds uppercase letters into their lowercase equivalents,
#  and ignores anything that is not a &letter.
#
#      The parser itself operates in bottom-up fashion, but it might
#  just as well have been coded as a top-down parser.  It also tends
#  to do things in breadth-first fashion, rather than walking through
#  each alternative until it is exhausted.  BNFs are specified using
#  the same notation used in Griswold & Griswold, and as described in
#  the IPL program "pargen.icn," with the difference that all
#  metacharacters (space, tab, vertical slash, right/left parends,
#  brackets and angle brackets) can be converted to literals by
#  prepending a backslash (rendering <lb>, <rb>, etc. as notations for
#  these characters unnecessary).  Comments can be include along with
#  BNFs using the same notation as for Icon code (i.e. #-sign).
#
#      Pitfalls to be aware of include things like <L> ::= <L> | ha |
#  () (a weak attempt at a laugh recognizer).  This grammar will
#  accept "ha," "ha ha," etc. but will suspend an infinite number of
#  possible parses.  The right way to do this sort of thing is <L> ::=
#  ha <S> | ha, or if you really insist on having the empty string as
#  a possibility, try things like:
#
#          <S>      ::= () | <LAUGHS>
#          <LAUGHS> ::= ha <LAUGHS> | ha
#
#      Ichartp was kinda thrown together just to see how well Icon
#  would do at jobs traditionally assigned to LISP, Prolog, etc.  I'm
#  sure it could be very much improved upon.
#
############################################################################
#
#  Links: structs, slashbal, rewrap, strip, stripcom (and ximage for debugging)
#
#  Requires:  an up-to-date IPL
#
############################################################################

# I use ximage for debugging purposes.
link structs, slashbal, rewrap, strip, stripcom#, ximage

record stats(edge_list, lhs_table, term_set)
record chart(inactive, active)               # inactive - set; active - list
record retval(no, item)

record edge(LHS, RHS, LEN, DONE, BEG, END, SEEN)
record short_edge(LHS, RHS)

#
# For debugging only.
#
procedure main(a)

    local res, filename
    # &trace := -1
    filename := \a[1] | "bnfs.byte"
    while line := read(&input) do {
        every res := parse_sentence(line, filename, "S") do {
            if res.no = 0 then
            write(stree(edge2tree(res.item)))
#            write(ximage(res.item))
        else if res.no = 1 then
        write("unknown vocabulary item, ", res.item)
        }
    }

end


#
# parse_sentence:  string x string -> edge records
#                  (s, filename) -> Es
#     where s is a chunk of text presumed to constitute a sentence
#     where filename is the name of a grammar file containing BNFs
#     where Es are edge records containing possible parses of s
#
procedure parse_sentence(s, filename, start_symbol)

    local file, e, i, elist, ltbl, tset, ch, tokens, st,
        memb, new_e, token_set, none_found, active_modified
    static master, old_filename
    initial master := table()

    #
    # Initialize and store stats for filename (if not already stored).
    #
    if not (filename == \old_filename) then {
        file := open(filename, "r") | p_err(filename, 7)
        #
        # Read BNFs from file; turn them into edge structs, and
        # store them all in a list; insert terminal symbols into a set.
        #
        elist := list(); ltbl := table(); tset := set()
        every e := bnf_file_2_edges(file) do {
            put(elist, e)                      # main edge list (active)
            (/ltbl[e.LHS] := set([e])) | insert(ltbl[e.LHS], e) # index LHSs
            every i := 1 to e.LEN do           # LEN holds length of e.RHS
                if /e.RHS[i].RHS then          # RHS for terminals is null
                    insert(tset, e.RHS[i].LHS) & break
        }
        insert(master, filename, stats(elist, ltbl, tset))
        old_filename := filename
        close(file)
    }
    elist := fullcopy(master[filename].edge_list)
    ltbl  := fullcopy(master[filename].lhs_table)
    tset  := master[filename].term_set

    #
    # Make edge list into the active section of chart; tokenize the
    # sentence s & check for unrecognized vocabulary.
    #
    ch := chart(set(), elist)
    tokens := tokenize(s)

    #
    # Begin parse by entering all tokens in s into the inactive set
    # in the chart as edges with no RHS (a NULL RHS is characteristic
    # of all terminals).
    #
    token_set := set(tokens)
    every i := 1 to *tokens do {
        # Flag words not in the grammar as errors.
        if not member(tset, tokens[i]) then
            suspend retval(1, tokens[i])
        # Now, give us an inactive edge corresponding to word i.
        insert(ch.inactive, e := edge(tokens[i], &null, 1, 1, i, i+1))
        # Insert word i into the LHS table.
        (/ltbl[tokens[i]] := set([e])) | insert(ltbl[tokens[i]], e)
    # Watch out for those empty RHSs.
    insert(ch.inactive, e := edge("", &null, 1, 1, i, i))
        (/ltbl[""] := set([e])) | insert(ltbl[""], e)
    }
    *tokens = 0 & i := 0
    insert(ch.inactive, e := edge("", &null, 1, 1, i+1, i+1))
    (/ltbl[""] := set([e])) | insert(ltbl[""], e)

    #
    # Until no new active edges can be built, keep ploughing through
    # the active edge list, trying to match unconfirmed members of their
    # RHSs up with inactive edges.
    #
    until \none_found do {
#    write(ximage(ch))
        none_found := 1
        every e := !ch.active do {
            active_modified := &null
            # keep track of inactive edges we've already tried
            /e.SEEN := set()
            #
            # e.RHS[e.DONE+1] is the first unconfirmed category in the
            # RHS of e; ltbl[e.RHS[e.DONE+1].LHS] are all edges having
            # as their LHS the LHS of the first unconfirmed category in
            # e's RHS; we simply intersect this set with the inactives,
            # and then subtract out those we've seen before in connec-
            # tion with this edge -
            #
            if *(st := \ltbl[e.RHS[e.DONE+1].LHS] ** ch.inactive -- e.SEEN) > 0
            then {
                # record all the inactive edges being looked at as seen
                e.SEEN ++:= st
                every memb := !st do {
            # make sure this inactive edge starts where the
            # last confirmed edge in e.RHS ends!
            if memb.BEG ~= \e.RHS[e.DONE].END then next
            # set none_found to indicate we've created a new edge
            else none_found := &null
                    # create a new edge, having the LHS of e, the RHS of e,
                    # the start point of e, the end point of st, and one more
                    # confirmed RHS members than e
                    new_e := edge(e.LHS, fullcopy(e.RHS),
                  e.LEN, e.DONE+1, e.BEG, memb.END)
                    new_e.RHS[new_e.DONE] := memb
                    /new_e.BEG := memb.BEG
                    if new_e.LEN = new_e.DONE then {      # it's inactive
                        insert(ch.inactive, new_e)
                        insert(ltbl[e.LHS], new_e)
                        if new_e.BEG = 1 & new_e.END = (*tokens+1) then {
                            if new_e.LHS == start_symbol  # complete parse
                            then suspend retval(0, new_e)
                        }
                    } else {
                        put(ch.active, new_e)            # it's active
                        active_modified := 1
                    }
                }
            }
            # restart if the ch.active list has been modified
            if \active_modified then break next
        }
    }

end


#
# tokenize:  break up a sentence into constituent words, using spaces,
#            tabs, and other punctuation as separators (we'll need to
#            change this a bit later on to cover apostrophed words)
#
procedure tokenize(s)

    local l, word

    l := list()
    s ? {
        while tab(upto(&letters)) do
            put(l, map(tab(many(&letters))))
    }
    return l

end


#
# edge2tree:  edge -> tree
#             e -> t
#
#    where e is an edge structure (active or inactive; both are okay)
#    where t is a tree like what's described in Ralph Griswold's
#    structs library (IPL); I don't know about the 2nd ed. of
#    Griswold & Griswold, but the structure is described in the 1st
#    ed. in section 16.1
#
#    fails if, for some reason, the conversion can't be made (e.g. the
#    edge structure has been screwed around with in some way)
#
procedure edge2tree(e)

    local memb, t

    t := [e.LHS]
    \e.RHS | (return t)                                 # a terminal
    type(e) == "edge" | (return put(t, []))             # incomplete edge
    every memb := !e.RHS do                             # has daughters
    put(t, edge2tree(memb))
    return t

end


#
# bnf_file_2_edges: concatenate backslash-final lines & parse
#
procedure bnf_file_2_edges(f)

    while line := read(f) do {
    line := stripcom(line)
        while line ?:= 1(tab(-2) || tab(slashupto('\\')), pos(-1)) || !f
        suspend bnf_2_edges(line)
    }

end


#
# bnf_2_edges: string -> edge records
#              s -> Es (a generator)
#    where s is a CFPSG rule in BNF form
#    where Es are edges
#
procedure bnf_2_edges(s)

    #
    # Take out non-backslashed whitespace (i.e. spaces and tabs).
    #
    stripped_s := ""
    s ? {
        while stripped_s ||:= tab(slashupto(' \t')) do
            tab(many(' \t'))
        stripped_s ||:= tab(0)
    }

    #
    # Break BNF-style CFPSG rule into LHS and RHS.  If there is more
    # than one RHS (a la the | alternation op), suspend multiple re-
    # sults.
    #
    stripped_s ? {
        LHS := 1("" ~== tab(slashbal(':', '<', '>')), ="::=") | p_err(s,1)
        LHS ?:= strip(2(="<", tab(-1), =">"), '\\') | p_err(s, 2)
    LHS == "" & p_err(s, 6)
        every RHS := do_slash(tab(0) \ 1) do {
            RHS := string_2_list(RHS)
            suspend edge(LHS, RHS, *RHS, 0, &null, &null)
        }
    }

end


#
# string_2_list:  string -> list
#                 s -> L
#    where L is a list of partially constructed (short) edges, having
#    only LHS and RHS; in the case of nonterminals, the RHS is set
#    to 1, while for terminals the RHS is null (and remains that way
#    throughout the parse)
#
procedure string_2_list(s)

    local RHS_list, LHS

    (s || "\x00") ? {
        pos(-1) & (return [short_edge("", &null)])
        RHS_list := list()
        until pos(-1) do {
            if match("<") then {
                LHS := ("" ~== tab(slashbal(&cset, '<', '>'))) | p_err(s, 4)
                LHS ?:= strip(2(="<", tab(-1), =">"), '\\') | p_err(s, 4)
                put(RHS_list, short_edge(LHS, 1))
            } else {
                LHS := tab(slashupto('<') | -1)
                slashupto('>', LHS) & p_err(s, 5)
                put(RHS_list, short_edge(strip(LHS, '\\'), &null))
            }
        }
    }
    return RHS_list

end


#
# slashupto:  cset x string x integer x integer -> integers
#             (c, s, i, j) -> Is (a generator)
#    where Is are the integer positions in s[i:j] before characters
#    in c that is not preceded by a backslash escape
#
procedure slashupto(c, s, i, j)

    if /s := &subject
    then /i := &pos
    else /i := 1
    /j := *s + 1

    /c := &cset
    c ++:= '\\'
    s[1:j] ? {
        tab(i)
        while tab(upto(c)) do {
            if (="\\", move(1)) then next
            suspend .&pos
            move(1)
        }
    }

end


#
# fullcopy:  make full recursive copy of object
#
procedure fullcopy(obj)

    local retval, i, k

    case type(obj) of {
        "co-expression"  : return obj
        "cset"           : return obj
        "file"           : return obj
        "integer"        : return obj
        "list"           : {
            retval := list(*obj)
            every i := 1 to *obj do
                retval[i] := fullcopy(obj[i])
            return retval
        }
        "null"           :  return &null
        "procedure"      :  return obj
        "real"           :  return obj
        "set"            :  {
            retval := set()
            every insert(retval, fullcopy(!obj))
            return retval
        }
        "string"         :  return obj
        "table"          :  {
            retval := table(obj[[]])
            every k := key(obj) do
                insert(retval, fullcopy(k), fullcopy(obj[k]))
            return retval
        }
        # probably a record; if not, we're dealing with a new
        # version of Icon or a nonstandard implementation, and
    # we're screwed
        default          :  {
            retval := copy(obj)
            every i := 1 to *obj do
                retval[i] := fullcopy(obj[i])
            return retval
        }
    }

end


#
# do_slash:  string -> string(s)
#     Given a|b suspend a then b.  Used in conjunction with do_parends().
#
procedure do_slash(s)

    local chunk
    s ? {
    while chunk := tab(slashbal('|', '(', ')')) do {
        suspend do_parends(chunk)
        move(1)
    }
    suspend do_parends(tab(0))
    }

end


#
# do_parends:  string -> string(s)
#    Given a(b)c suspend abc; given a(b|c)d suspend abd and acd, etc.
#    Used in conjuction with do_slash().
#
procedure do_parends(s)

    local chunk, i, j
    s ? {
    if not (i := slashupto('(')) then {
        chunk := tab(0)
        slashupto(')') & p_err(s, 8)
        suspend chunk
    } else {
        j := i + slashbal(')', '(', ')', s[i+1:0]) | p_err(s, 9)
        suspend tab(i) ||
        (move(1), do_slash(tab(j))) ||
        (move(1), do_parends(tab(0)))
    }
    }

end


#
# p_err:  print error message to stderr & abort
#
procedure p_err(s, n)

    local i, msg
    static errlist
    initial {
        errlist := [[1, "malformed LHS"],
                    [2, "nonterminal lacks proper <> enclosure"],
                    [3, "missing left angle bracket"],
                    [4, "unmatched left angle bracket"],
                    [5, "unmatched right angle bracket"],
            [6, "empty symbol in LHS"],
                    [7, "unable to open file"],
                    [8, "unmatched right parenthesis"],
                    [9, "unmatched left parenthesis"]
                   ]
    }
    every i := 1 to *errlist do
        if errlist[i][1] = n then msg := errlist[i][2]
    writes(&errout, "error ", n, " (", msg, ") in \n")
    every write("\t", rewrap(s) | rewrap())
    exit(n)

end

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]         rutgers!oddjob!gide!sophist!goer

From icon-group-request  Sun Mar  8 12:53:23 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 8 Mar 92 12:53:23 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA05923; Sun, 8 Mar 92 12:53:16 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA27992; Sun, 8 Mar 92 11:48:31 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 27 Feb 92 09:31:44 GMT
From: uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: NLP & Icon
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]


############################################################################
#
#    Name:     ichartp.icn
#
#    Title:     Iconish implementation of a simple chart parser
#
#    Author:     Richard L. Goerwitz
#
#    Version: 1.2
#
############################################################################
#
#      I was reading Byte Magazine (vol. 17:2 [February, 1992]), and
#  ran into an article entitled "A Natural Solution" (pages 237-244)
#  in which a standard chart parser was described in terms of its C++
#  implementation.  The author remarked at how his optimizations made
#  it possible to parse a 14-word sentence in only 32 seconds (versus
#  146 for a straight Gazdar-Mellish LISP chart parser).  32 seconds
#  struck me as hardly anything to write home about, so started coding
#  up a quick system in Icon to see how it compared.  This library is
#  the result.
#
#      The library has a small stub main() procedure that can be used
#  to get an idea of what is going on.  If compiled, the resulting
#  program takes just a single argument - the name of a BNF file
#  containing the grammar to use for parsing.  Parsing is done
#  line-by-line on the fly, using the standard input.  The results of
#  the parse are reported using the notation for trees described in
#  Griswold & Griswold, and also in the IPL collection entitled
#  "structs.icn."  There is often more than one possible parse, and
#  these are suspended successively, as they are encountered.  Unknown
#  vocabulary is flagged immediately as an error.  The tokenizing
#  routine folds uppercase letters into their lowercase equivalents,
#  and ignores anything that is not a &letter.
#
#      The parser itself operates in bottom-up fashion, but it might
#  just as well have been coded as a top-down parser.  It also tends
#  to do things in breadth-first fashion, rather than walking through
#  each alternative until it is exhausted.  BNFs are specified using
#  the same notation used in Griswold & Griswold, and as described in
#  the IPL program "pargen.icn," with the difference that all
#  metacharacters (space, tab, vertical slash, right/left parends,
#  brackets and angle brackets) can be converted to literals by
#  prepending a backslash (rendering <lb>, <rb>, etc. as notations for
#  these characters unnecessary).  Comments can be include along with
#  BNFs using the same notation as for Icon code (i.e. #-sign).
#
#      Pitfalls to be aware of include things like <L> ::= <L> | ha |
#  () (a weak attempt at a laugh recognizer).  This grammar will
#  accept "ha," "ha ha," etc. but will suspend an infinite number of
#  possible parses.  The right way to do this sort of thing is <L> ::=
#  ha <S> | ha, or if you really insist on having the empty string as
#  a possibility, try things like:
#
#          <S>      ::= () | <LAUGHS>
#          <LAUGHS> ::= ha <LAUGHS> | ha
#
#      Ichartp was kinda thrown together just to see how well Icon
#  would do at jobs traditionally assigned to LISP, Prolog, etc.  I'm
#  sure it could be very much improved upon.
#
############################################################################
#
#  Links: structs, slashbal, rewrap, strip, stripcom (and ximage for debugging)
#
#  Requires:  an up-to-date IPL
#
############################################################################

# I use ximage for debugging purposes.
link structs, slashbal, rewrap, strip, stripcom#, ximage

record stats(edge_list, lhs_table, term_set)
record chart(inactive, active)               # inactive - set; active - list
record retval(no, item)

record edge(LHS, RHS, LEN, DONE, BEG, END, SEEN)
record short_edge(LHS, RHS)

#
# For debugging only.
#
procedure main(a)

    local res, filename
    # &trace := -1
    filename := \a[1] | "bnfs.byte"
    while line := read(&input) do {
        every res := parse_sentence(line, filename, "S") do {
            if res.no = 0 then
            write(stree(edge2tree(res.item)))
#            write(ximage(res.item))
        else if res.no = 1 then
        write("unknown vocabulary item, ", res.item)
        }
    }

end


#
# parse_sentence:  string x string -> edge records
#                  (s, filename) -> Es
#     where s is a chunk of text presumed to constitute a sentence
#     where filename is the name of a grammar file containing BNFs
#     where Es are edge records containing possible parses of s
#
procedure parse_sentence(s, filename, start_symbol)

    local file, e, i, elist, ltbl, tset, ch, tokens, st,
        memb, new_e, token_set, none_found, active_modified
    static master, old_filename
    initial master := table()

    #
    # Initialize and store stats for filename (if not already stored).
    #
    if not (filename == \old_filename) then {
        file := open(filename, "r") | p_err(filename, 7)
        #
        # Read BNFs from file; turn them into edge structs, and
        # store them all in a list; insert terminal symbols into a set.
        #
        elist := list(); ltbl := table(); tset := set()
        every e := bnf_file_2_edges(file) do {
            put(elist, e)                      # main edge list (active)
            (/ltbl[e.LHS] := set([e])) | insert(ltbl[e.LHS], e) # index LHSs
            every i := 1 to e.LEN do           # LEN holds length of e.RHS
                if /e.RHS[i].RHS then          # RHS for terminals is null
                    insert(tset, e.RHS[i].LHS) & break
        }
        insert(master, filename, stats(elist, ltbl, tset))
        old_filename := filename
        close(file)
    }
    elist := fullcopy(master[filename].edge_list)
    ltbl  := fullcopy(master[filename].lhs_table)
    tset  := master[filename].term_set

    #
    # Make edge list into the active section of chart; tokenize the
    # sentence s & check for unrecognized vocabulary.
    #
    ch := chart(set(), elist)
    tokens := tokenize(s)

    #
    # Begin parse by entering all tokens in s into the inactive set
    # in the chart as edges with no RHS (a NULL RHS is characteristic
    # of all terminals).
    #
    token_set := set(tokens)
    every i := 1 to *tokens do {
        # Flag words not in the grammar as errors.
        if not member(tset, tokens[i]) then
            suspend retval(1, tokens[i])
        # Now, give us an inactive edge corresponding to word i.
        insert(ch.inactive, e := edge(tokens[i], &null, 1, 1, i, i+1))
        # Insert word i into the LHS table.
        (/ltbl[tokens[i]] := set([e])) | insert(ltbl[tokens[i]], e)
    # Watch out for those empty RHSs.
    insert(ch.inactive, e := edge("", &null, 1, 1, i, i))
        (/ltbl[""] := set([e])) | insert(ltbl[""], e)
    }
    *tokens = 0 & i := 0
    insert(ch.inactive, e := edge("", &null, 1, 1, i+1, i+1))
    (/ltbl[""] := set([e])) | insert(ltbl[""], e)

    #
    # Until no new active edges can be built, keep ploughing through
    # the active edge list, trying to match unconfirmed members of their
    # RHSs up with inactive edges.
    #
    until \none_found do {
#    write(ximage(ch))
        none_found := 1
        every e := !ch.active do {
            active_modified := &null
            # keep track of inactive edges we've already tried
            /e.SEEN := set()
            #
            # e.RHS[e.DONE+1] is the first unconfirmed category in the
            # RHS of e; ltbl[e.RHS[e.DONE+1].LHS] are all edges having
            # as their LHS the LHS of the first unconfirmed category in
            # e's RHS; we simply intersect this set with the inactives,
            # and then subtract out those we've seen before in connec-
            # tion with this edge -
            #
            if *(st := \ltbl[e.RHS[e.DONE+1].LHS] ** ch.inactive -- e.SEEN) > 0
            then {
                # record all the inactive edges being looked at as seen
                e.SEEN ++:= st
                every memb := !st do {
            # make sure this inactive edge starts where the
            # last confirmed edge in e.RHS ends!
            if memb.BEG ~= \e.RHS[e.DONE].END then next
            # set none_found to indicate we've created a new edge
            else none_found := &null
                    # create a new edge, having the LHS of e, the RHS of e,
                    # the start point of e, the end point of st, and one more
                    # confirmed RHS members than e
                    new_e := edge(e.LHS, fullcopy(e.RHS),
                  e.LEN, e.DONE+1, e.BEG, memb.END)
                    new_e.RHS[new_e.DONE] := memb
                    /new_e.BEG := memb.BEG
                    if new_e.LEN = new_e.DONE then {      # it's inactive
                        insert(ch.inactive, new_e)
                        insert(ltbl[e.LHS], new_e)
                        if new_e.BEG = 1 & new_e.END = (*tokens+1) then {
                            if new_e.LHS == start_symbol  # complete parse
                            then suspend retval(0, new_e)
                        }
                    } else {
                        put(ch.active, new_e)            # it's active
                        active_modified := 1
                    }
                }
            }
            # restart if the ch.active list has been modified
            if \active_modified then break next
        }
    }

end


#
# tokenize:  break up a sentence into constituent words, using spaces,
#            tabs, and other punctuation as separators (we'll need to
#            change this a bit later on to cover apostrophed words)
#
procedure tokenize(s)

    local l, word

    l := list()
    s ? {
        while tab(upto(&letters)) do
            put(l, map(tab(many(&letters))))
    }
    return l

end


#
# edge2tree:  edge -> tree
#             e -> t
#
#    where e is an edge structure (active or inactive; both are okay)
#    where t is a tree like what's described in Ralph Griswold's
#    structs library (IPL); I don't know about the 2nd ed. of
#    Griswold & Griswold, but the structure is described in the 1st
#    ed. in section 16.1
#
#    fails if, for some reason, the conversion can't be made (e.g. the
#    edge structure has been screwed around with in some way)
#
procedure edge2tree(e)

    local memb, t

    t := [e.LHS]
    \e.RHS | (return t)                                 # a terminal
    type(e) == "edge" | (return put(t, []))             # incomplete edge
    every memb := !e.RHS do                             # has daughters
    put(t, edge2tree(memb))
    return t

end


#
# bnf_file_2_edges: concatenate backslash-final lines & parse
#
procedure bnf_file_2_edges(f)

    while line := read(f) do {
    line := stripcom(line)
        while line ?:= 1(tab(-2) || tab(slashupto('\\')), pos(-1)) || !f
        suspend bnf_2_edges(line)
    }

end


#
# bnf_2_edges: string -> edge records
#              s -> Es (a generator)
#    where s is a CFPSG rule in BNF form
#    where Es are edges
#
procedure bnf_2_edges(s)

    #
    # Take out non-backslashed whitespace (i.e. spaces and tabs).
    #
    stripped_s := ""
    s ? {
        while stripped_s ||:= tab(slashupto(' \t')) do
            tab(many(' \t'))
        stripped_s ||:= tab(0)
    }

    #
    # Break BNF-style CFPSG rule into LHS and RHS.  If there is more
    # than one RHS (a la the | alternation op), suspend multiple re-
    # sults.
    #
    stripped_s ? {
        LHS := 1("" ~== tab(slashbal(':', '<', '>')), ="::=") | p_err(s,1)
        LHS ?:= strip(2(="<", tab(-1), =">"), '\\') | p_err(s, 2)
    LHS == "" & p_err(s, 6)
        every RHS := do_slash(tab(0) \ 1) do {
            RHS := string_2_list(RHS)
            suspend edge(LHS, RHS, *RHS, 0, &null, &null)
        }
    }

end


#
# string_2_list:  string -> list
#                 s -> L
#    where L is a list of partially constructed (short) edges, having
#    only LHS and RHS; in the case of nonterminals, the RHS is set
#    to 1, while for terminals the RHS is null (and remains that way
#    throughout the parse)
#
procedure string_2_list(s)

    local RHS_list, LHS

    (s || "\x00") ? {
        pos(-1) & (return [short_edge("", &null)])
        RHS_list := list()
        until pos(-1) do {
            if match("<") then {
                LHS := ("" ~== tab(slashbal(&cset, '<', '>'))) | p_err(s, 4)
                LHS ?:= strip(2(="<", tab(-1), =">"), '\\') | p_err(s, 4)
                put(RHS_list, short_edge(LHS, 1))
            } else {
                LHS := tab(slashupto('<') | -1)
                slashupto('>', LHS) & p_err(s, 5)
                put(RHS_list, short_edge(strip(LHS, '\\'), &null))
            }
        }
    }
    return RHS_list

end


#
# slashupto:  cset x string x integer x integer -> integers
#             (c, s, i, j) -> Is (a generator)
#    where Is are the integer positions in s[i:j] before characters
#    in c that is not preceded by a backslash escape
#
procedure slashupto(c, s, i, j)

    if /s := &subject
    then /i := &pos
    else /i := 1
    /j := *s + 1

    /c := &cset
    c ++:= '\\'
    s[1:j] ? {
        tab(i)
        while tab(upto(c)) do {
            if (="\\", move(1)) then next
            suspend .&pos
            move(1)
        }
    }

end


#
# fullcopy:  make full recursive copy of object
#
procedure fullcopy(obj)

    local retval, i, k

    case type(obj) of {
        "co-expression"  : return obj
        "cset"           : return obj
        "file"           : return obj
        "integer"        : return obj
        "list"           : {
            retval := list(*obj)
            every i := 1 to *obj do
                retval[i] := fullcopy(obj[i])
            return retval
        }
        "null"           :  return &null
        "procedure"      :  return obj
        "real"           :  return obj
        "set"            :  {
            retval := set()
            every insert(retval, fullcopy(!obj))
            return retval
        }
        "string"         :  return obj
        "table"          :  {
            retval := table(obj[[]])
            every k := key(obj) do
                insert(retval, fullcopy(k), fullcopy(obj[k]))
            return retval
        }
        # probably a record; if not, we're dealing with a new
        # version of Icon or a nonstandard implementation, and
    # we're screwed
        default          :  {
            retval := copy(obj)
            every i := 1 to *obj do
                retval[i] := fullcopy(obj[i])
            return retval
        }
    }

end


#
# do_slash:  string -> string(s)
#     Given a|b suspend a then b.  Used in conjunction with do_parends().
#
procedure do_slash(s)

    local chunk
    s ? {
    while chunk := tab(slashbal('|', '(', ')')) do {
        suspend do_parends(chunk)
        move(1)
    }
    suspend do_parends(tab(0))
    }

end


#
# do_parends:  string -> string(s)
#    Given a(b)c suspend abc; given a(b|c)d suspend abd and acd, etc.
#    Used in conjuction with do_slash().
#
procedure do_parends(s)

    local chunk, i, j
    s ? {
    if not (i := slashupto('(')) then {
        chunk := tab(0)
        slashupto(')') & p_err(s, 8)
        suspend chunk
    } else {
        j := i + slashbal(')', '(', ')', s[i+1:0]) | p_err(s, 9)
        suspend tab(i) ||
        (move(1), do_slash(tab(j))) ||
        (move(1), do_parends(tab(0)))
    }
    }

end


#
# p_err:  print error message to stderr & abort
#
procedure p_err(s, n)

    local i, msg
    static errlist
    initial {
        errlist := [[1, "malformed LHS"],
                    [2, "nonterminal lacks proper <> enclosure"],
                    [3, "missing left angle bracket"],
                    [4, "unmatched left angle bracket"],
                    [5, "unmatched right angle bracket"],
            [6, "empty symbol in LHS"],
                    [7, "unable to open file"],
                    [8, "unmatched right parenthesis"],
                    [9, "unmatched left parenthesis"]
                   ]
    }
    every i := 1 to *errlist do
        if errlist[i][1] = n then msg := errlist[i][2]
    writes(&errout, "error ", n, " (", msg, ") in \n")
    every write("\t", rewrap(s) | rewrap())
    exit(n)

end

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]         rutgers!oddjob!gide!sophist!goer

From icon-group-request  Mon Mar  9 02:26:56 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 9 Mar 92 02:26:56 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA03693; Mon, 9 Mar 92 02:26:53 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA28760; Mon, 9 Mar 92 01:17:17 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 18 Feb 92 22:10:31 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!sdd.hp.com!think.com!rpi!sarah!eve.albany.edu![e-mail]  (The Sea Nymph)
Organization: State University of New York at Albany
Subject: implementation book[s]?
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]


I have only seen one book on implementing Icon (in C). Unfortunately
I can't remember the specific title or author.. but in general,
does anyone know if there is more than one book, and can you
tell me what book[s] there is/are?

many thanks,
lg

****************IAMNOTASIGNATUREIAMAFREETHINKINGINDIVIDUAL******************

From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:[e-mail]  Thu Mar 12 22:00:41 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 12 Mar 92 22:00:41 MST
Received: from  by optima.cs.arizona.edu (4.1/15)
    id AB27665; Thu, 12 Mar 92 22:00:27 MST
Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET
          with NIFTP id <[e-mail]>;
          Wed, 11 Mar 1992 15:04:49 +0000
Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa17676;
          11 Mar 92 11:58 WET
Date: 11 Mar 92 11:58:36 gmt
From: [e-mail]
Subject: Soundex
To: [e-mail]
Message-Id: <11 Mar 92 11:58:36 gmt 320969@EMAS-A>
Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:[e-mail]>

Somewhere, recently, I saw Icon code for the Soundex algorithm. I now need
this code and can't find it. It doesn't seem to be in the Icon Program
Library. Was it posted here? If yes, I'd be grateful if the originator would
re-post it.

Thanks.

Roger Hare.

From [e-mail]  Fri Mar 13 05:14:32 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 13 Mar 92 05:14:32 MST
Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15)
    id AA21865; Fri, 13 Mar 92 05:14:28 MST
Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12865) id
 <[e-mail]>; Fri, 13 Mar 1992 06:15 CST
Date: Fri, 13 Mar 1992 06:15 CST
From: Chris Tenaglia - 257-8765 <[e-mail]>
Subject: Re: Soundex
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Organization: Medical College of Wisconsin (Milwaukee, WI)
X-Vms-To: IN%"[e-mail]"
X-Vms-Cc: IN%"[e-mail]"

> From:    IN%"[e-mail]" 12-MAR-1992 23:12:53.41
> To:    IN%"[e-mail]"
> Subj:    Soundex

> Somewhere, recently, I saw Icon code for the Soundex algorithm. I now need
> this code and can't find it. It doesn't seem to be in the Icon Program
> Library. Was it posted here? If yes, I'd be grateful if the originator would
> re-post it.

> Thanks.
> Roger Hare.

Here's my posting from earlier this year. Dr. Griswold also had mentioned
that another version is available from the IPL.

Chris Tenaglia (System Manager) |  "The past explained,
Medical College of Wisconsin    |   the future fortold,
8701 W. Watertown Plank Rd.     |   the present largely appologized for."
Milwaukee, WI 53226             |   Organon to The Doctor
[phone]                   |
[e-mail]

#
# SOUNDEX.ICN          8/28/91          TENAGLIA
#
# THIS ICON PROGRAM IMPLEMENTS A SOUNDEX CATALOGUING
# KEY COMPRESSOR.
#
procedure main()
  while map(line := input("Str:")) ~== "quit" do write(soundex(line))
  end

#
# STR IS A STRING (USUALLY A LAST NAME) PHONETICALLY SPELLED.
# NUMBER IS RETURNED WHICH IS A CATALOGUE LOOK UP KEY MADE FROM IT.
# THE STEPS ARE AS FOLLOWS :
#          1. SAVE THE FIRST CHARACTER FOR LATER USE
#          2. REMOVE W AND H
#          3. REMOVE ALL VOWELS EXCEPT WHEN IN FIRST POSITION
#          4. MAP LEFTOVER STRING WITH A NUMBER TABLE
#          5. DELETE DUPLICATE ADJACENT DIGITS
#          6. MAKE NUMBER 6 CHARACTERS LONG (TRUNCATE OR PAD WITH 0S)
#          7. REPLACE FIRST DIGIT WITH SAVED FIRST CHARACTER
#
procedure soundex(str)
  static vowels, tbl
  initial
    {
    vowels := 'aeiouy'
    tbl    := "0123012 02245501262301 202"
    }
  str := map(str)
  first := str[1] ; tmp := first ; tmp2 := ""
  while i := find("w"|"h",str) do str[i] := ""
  every i := 2 to *str do tmp ||:= if any(vowels,str,i) then "" else str[i]
  str2 := map(tmp,&lcase,tbl) || "?"
  every i := 1 to *str2-1 do
    if str2[i] ~== str2[i+1] then tmp2 ||:= str2[i]
  number := if *tmp2 < 6 then left(tmp2,6,"0") else tmp2[1+:6]
  number[1] := first
  return number
  end

#
# GET A STRING OF INPUT FROM THE KEYBOARD
#

procedure input(prompt)
  writes(prompt)
  return read()
  end


From [e-mail]  Fri Mar 13 07:47:43 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 13 Mar 92 07:47:43 MST
Received: from hilbert.math.grin.edu (HILBERT-GW.MATH.GRIN.EDU) by optima.cs.arizona.edu (4.1/15)
    id AA25589; Fri, 13 Mar 92 07:47:40 MST
Received: from russell.math.grin.edu by hilbert.math.grin.edu (4.1/Stone-5);
    id AA10637; Fri, 13 Mar 92 08:47:02 CST
Date: Fri, 13 Mar 92 08:47:02 CST
From: John David Stone <[e-mail]>
Message-Id: <[e-mail]>
Received: by russell.math.grin.edu (4.1/Stone-2);
    id AA04081; Fri, 13 Mar 92 08:46:59 CST
To: [e-mail]
Subject: Soundex algorithm

        I'm not the original poster of the Soundex algorithm, but I have
a version that should serve your purpose:

----------------------------------------------------------------------------
# When names are communicated by telephone, they are often transcribed
# incorrectly.  An organization that has to keep track of a lot of names has
# a need, therefore, for some system of representing or encoding a name that
# will mitigate the effects of transcription errors.  One idea, originally
# proposed by Margaret K. Odell and Robert C. Russell, uses the following
# encoding system to try to bring together occurrences of the same surname,
# variously spelled:
#
# Encode each of the letters of the name according to the
# following equivalences:
#
#       a, e, h, i, o, u, w, y -> *
#       b, f, p, v             -> 1
#       c, g, j, k, q, s, x, z -> 2
#       d, t                   -> 3
#       l                      -> 4
#       m, n                   -> 5
#       r                      -> 6
#
#
# If any two adjacent letters have the same code, change the code for the
# second one to *.
#
# The Soundex representation consists of four characters: the initial letter
# of the name, and the first three digit (non-asterisk) codes corresponding
# to letters after the initial.  If there are fewer than three such digit
# codes, use all that there are, and add zeroes at the end to make up the
# four-character representation.
#
# This program reads in surnames from standard input, one to a line, and
# echoes them with their Soundex representations attached, in the following
# format:
#
# Stone                         S350
#
# Programmer: Exotic Programming Languages Study Group, Grinnell College.
# Original version: November 26, 1991.

procedure main()
local
    name

    while name := read() do
        write(name, repl(" ", 40 - *name), soundex(name))
end

procedure soundex(name)
local
    coded_name, new_name

    coded_name := encode(strip(name))
    new_name := name[1]
    every pos := 2 to *coded_name do {
        if coded_name[pos] ~== "*" then
            new_name := new_name || coded_name[pos]
        if *new_name = 4 then
            break
    }
    return new_name || repl ("0", 4 - *new_name)
end

procedure encode(name)

    name := map(name, &ucase, &lcase)
    name := map(name, "aehiouwybfpvcgjkqsxzdtlmnr",
        "********111122222222334556")
    every pos := *name to 2 by -1 do
        if name[pos - 1] == name[pos] then
            name[pos] := "*"
    return name
end

------------------------------------------------------------------------------
        John David Stone - Lecturer in Computer Science and Philosophy
                Manager of the Mathematics Local-Area Network
                Grinnell College - Grinnell, Iowa 50112 - USA
          [e-mail] - [phone] - [e-mail]
------------------------------------------------------------------------------


From [e-mail]  Fri Mar 13 08:24:55 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 13 Mar 92 08:24:55 MST
Received: from hilbert.math.grin.edu (HILBERT-GW.MATH.GRIN.EDU) by optima.cs.arizona.edu (4.1/15)
    id AA27079; Fri, 13 Mar 92 08:24:51 MST
Received: from russell.math.grin.edu by hilbert.math.grin.edu (4.1/Stone-5);
    id AA10645; Fri, 13 Mar 92 09:24:09 CST
Date: Fri, 13 Mar 92 09:24:09 CST
From: John David Stone <[e-mail]>
Message-Id: <[e-mail]>
Received: by russell.math.grin.edu (4.1/Stone-2);
    id AA04092; Fri, 13 Mar 92 09:24:07 CST
To: [e-mail]
Subject: Missing procedure from Soundex algorithm

        I see I dropped one procedure from the Soundex algorithm I sent
earlier.  Here's the missing part:

-------------------------------------------------------------------------
procedure strip(name)
local
    result
static
    alphabet
initial alphabet := string(&letters)

    result := ""
    every ch := !name do
        if find(ch, alphabet) then
            result ||:= ch
    return result
end

------------------------------------------------------------------------------
        John David Stone - Lecturer in Computer Science and Philosophy
                Manager of the Mathematics Local-Area Network
                Grinnell College - Grinnell, Iowa 50112 - USA
          [e-mail] - [phone] - [e-mail]
------------------------------------------------------------------------------


From ralph  Fri Mar 13 16:33:16 1992
Date: Fri, 13 Mar 92 16:33:16 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by cheltenham.cs.arizona.edu; Fri, 13 Mar 92 16:33:16 MST
To: icon-group
Subject: Icon electronic mail and news


Normally, e-mail to icon-group is passed on to comp.lang.icon newsgroup and
news posted to comp.lang.icon is passed on to the icon-group mailing list.

At present, however, it appears that news posted to comp.lang.icon is
not coming to icon-group.

We are looking into the problem.  But until it's solved, if you want your
postings to get to icon-group, send e-mail to [e-mail]
(or uunet!arizona!icon-group) rather than posting news to comp.lang.icon.

    Ralph Griswold / Department of Computer Science
    The University of Arizona / Tucson, AZ 85721

    [e-mail] / uunet!arizona!ralph

    voice: 602-621-6609 / fax: [phone]

From [e-mail]  Sat Mar 14 19:12:39 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 14 Mar 92 19:12:39 MST
Received: from midway.uchicago.edu by optima.cs.arizona.edu (4.1/15)
    id AA01733; Sat, 14 Mar 92 19:12:34 MST
Received: from ellis.uchicago.edu by midway.uchicago.edu Sat, 14 Mar 92 20:12:32 CST
Date: Sat, 14 Mar 92 20:12:32 CST
From: "Richard L. Goerwitz" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: newer puzzle maker

I have received some requests for the latest version of the
puzzle making toy I posted a while back.  Seems sensible just
to post it at this point.

-Richard

############################################################################
#
#    Name:     makepuzz.icn
#
#    Title:     find-the-word puzzle maker
#
#    Author:     Richard L. Goerwitz
#
#    Version: 1.18
#
############################################################################
#
#     This program doesn't do anything fancy.  It simply takes a list
#  of words, and constructs out of them one of those square
#  find-the-word puzzles that some people like to bend their minds
#  over.  Usage is:
#
#      makepuzz [-f input-file] [-o output-file] [-h puzzle-height]
#         -w puzzle-width] [-t how-many-seconds-to-keep-trying]
#         [-r maximum-number-of-rejects] [-s] [-d]
#
#  where input-file is a file containing words, one to a line
#  (defaults to &input), and ouput-file is the file you would like the
#  puzzle written to (defaults to &output).  Puzzle-height and width
#  are the basic dimensions you want to try to fit your word game into
#  (default 20x20).  If the -s argument is present, makepuzz will
#  scramble its output, by putting random letters in all the blank
#  spaces.  The -t tells the computer when to give up, and construct
#  the puzzle (letting you know if any words didn't make it in).
#  Defaults to 60 (i.e. one minute).  The -r argument tells makepuzz to
#  run until it arrives at a solution with number-of-rejects or less
#  un-inserted words.  -d turns on certain diagnostic messages.
#
#      Most of these options can safely be ignored.  Just type
#  something like "makepuzz -f wordlist," where wordlist is a file
#  containing about sixty words, one word to a line.  Out will pop a
#  "word-find" puzzle.  Once you get the hang of what is going on,
#  try out the various options.
#
#      The algorithm used here is a combination of random insertions
#  and mindless, brute-force iterations through possible insertion
#  points and insertion directions.  If you don't like makepuzz's per-
#  formance on one run, run it again.  If your puzzle is large, try
#  increasing the timeout value (see -t above).
#
############################################################################
#
#  Links: options, irandom, colmize
#  Requires:  An up-to-date IPL (2/10/92)
#
############################################################################

link options, irandom, colmize
global height, width, _debug_

procedure main(a)

    local usage, opttbl, inputfile, outputfile, maxrejects, puzzle,
    wordlist, rejects, master_list, word, timeout, x, y, l_puzzle,
    l_wordlist, l_rejects, no_ltrs, l_no_ltrs, try

    # Filename is the only mandatory argument; they can come in any order.
    usage := "makepuzz [-f infile] [-o outfile] [-h height] [-w width] _
    [-t secs] [-r rejects] [-s]"

    # Set up puzzle height and width (default 20x20); set up defaults
    # such as the input & output files, time to spend, target reject
    # count, etc.
    opttbl := options(a, "w+h+f:o:t+sr+d") # stop(usage)
    width  := \opttbl["w"] | 20
    height := \opttbl["h"] | 20
    timeout := &time + (1000 * (\opttbl["t"] | 60))
    inputfile := open(\opttbl["f"], "r") | &input
    outputfile := open(\opttbl["o"], "w") | &output
    maxrejects := \opttbl["r"] | 0
    _debug_ := \opttbl["d"] & try := 0

    # Set random number seed.
    irandom()

    # Read, check, and sort word list hardest to easiest.
    master_list := list()
    every word := "" ~== trim(map(!inputfile)) do {
    upto(~(&lcase++&ucase), word) &
        stop("makepuzz:  non-letter found in ", word)
    write(&errout, "makepuzz:  warning, ",3 > *word,
          "-letter word (", word, ")")
    put(master_list, word)
    }
    master_list := sort_words(master_list)
    if \_debug_ then write(&errout, "makepuzz:  thinking...")

    # Now, try to insert the words in the master list into a puzzle.
    # Stop when the timeout limit is reached (see -t above).
    until &time > timeout do {

    wordlist := copy(master_list); rejects := list()
    puzzle := list(height); every !puzzle := list(width)
    blind_luck_insert(puzzle, wordlist, rejects)
    brute_force_insert(puzzle, wordlist, rejects, timeout)

    # Count the number of letters left over.
    no_ltrs := 0; every no_ltrs +:= *(!wordlist | !rejects)
    l_no_ltrs := 0; every l_no_ltrs +:= *(!\l_wordlist | !\l_rejects)
    # If our last best try at making a puzzle was worse...
    if /l_puzzle |
        (*\l_wordlist + *l_rejects) > (*wordlist + *rejects) |
        ((*\l_wordlist + *l_rejects) = (*wordlist + *rejects) &
         l_no_ltrs > no_ltrs)
    then {
        # ...then save the current (better) one.
        l_puzzle   := puzzle
        l_wordlist := wordlist
        l_rejects  := rejects
    }

    # Tell the user how we're doing.
    if \_debug_ then
        write(&errout, "makepuzz:  try number ", try +:= 1, "; ",
          *wordlist + *rejects, " rejects")

    # See the -r argument above.  Stop if we get to a number of
    # rejects deemed acceptable to the user.
    if (*\l_wordlist + *l_rejects) <= maxrejects then break
    }

    # Signal to user that we're done, and set puzzle, wordlist, and
    # rejects to their best values in this run of makepuzz.
    write(&errout, "makepuzz:  done")
    puzzle   := \l_puzzle
    wordlist := \l_wordlist
    rejects  := \l_rejects

    # Print out original word list, and list of words that didn't make
    # it into the puzzle.
    write(outputfile, "Original word list (sorted hardest-to-easiest): \n")
    every write(outputfile, colmize(master_list))
    write(outputfile, "")
    if *rejects + *wordlist > 0 then {
    write(outputfile, "Couldn't insert the following words: \n")
    every write(outputfile, colmize(wordlist ||| rejects))
    write(outputfile, "")
    }

    # Scramble (i.e. put in letters for remaining spaces) if the user
    # put -s on the command line.
    if \opttbl["s"] then {
    every y := !puzzle do
        every x := 1 to *y do
            /y[x] := ?&ucase

        # Print out puzzle structure (answers in lowercase).
    every y := !puzzle do {
        every x := !y do
        writes(outputfile, \x | " ", " ")
        write(outputfile, "")
    }
    write(outputfile, "")
    }

    # Print out puzzle structure, all lowercase.
    every y := !puzzle do {
    every x := !y do
        writes(outputfile, map(\x) | " ", " ")
        write(outputfile, "")
    }

    # Exit with default OK status for this system.
    every close(inputfile | outputfile)
    exit()

end


procedure sort_words(wordlist)

    local t, t2, word, sum, l

    # Obtain a rough character count.
    t := table(0)
    every t[!!wordlist] +:= 1
    t2 := table()

    # Obtain weighted values for each word, essentially giving longer
    # words and words with uncommon letters the highest values.  Later
    # we'll reverse the order (-> hardest-to-easiest), and return a list.
    every word := !wordlist do {
    "" == word & next
    sum := 0
    every sum +:= t[!word]
    insert(t2, word, (sum / *word) - (2 * *word))
    }
    t2 := sort(t2, 4)
    l := list()

    # Put the hardest words first.  These will get laid down when the
    # puzzle is relatively empty.  Save the small, easy words for last.
    every put(l, t2[1 to *t2-1 by 2])
    return l

end


procedure blind_luck_insert(puzzle, wordlist, rejects)

    local s, s2, s3, begy, begx, y, x, diry, dirx, diry2, dirx2, i
    # global height, width

    # Try using blind luck to make as many insertions as possible.
    while s := get(wordlist) do {

    # First try squares with letters already on them, but don't
    # try every direction yet (we're relying on luck just now).
    # Start at a random spot in the puzzle, and wrap around.
    begy := ?height; begx := ?width
    every y := (begy to height) | (1 to begy - 1) do {
        every x := (begx to width) | (1 to begx - 1) do  {
        every i := find(\puzzle[y][x], s) do {
            diry := ?3; dirx := ?3
            s2 := s[i:0]
            diry2 := 4 > (diry + 2) | 0 < (diry - 2) | 2
            dirx2 := 4 > (dirx + 2) | 0 < (dirx - 2) | 2
            s3 := reverse(s[1:i+1])
            if insert_word(puzzle, s2, diry, dirx, y, x) &
            insert_word(puzzle, s3, diry2, dirx2, y, x)
            then break { break break next }
        }
        }
    }

    # If the above didn't work, give up on spaces with characters
    # in them; use blank squares as well.
    every 1 to 512 do
        if insert_word(puzzle, s, ?3, ?3, ?height, ?width) then
           break next
    # If this word doesn't submit to easy insertion, save it for
    # later.
    put(rejects, s)
    }

    # Nothing useful to return (puzzle, wordlist, and rejects objects
    # are themselves modified; not copies of them).
    return

end


procedure brute_force_insert(puzzle, wordlist, rejects, timeout)

    local s, start, dirs, begy, begx, y, x

    # Use brute force on the remaining forms.
    if *rejects > 0 then {
    wordlist |||:= rejects; rejects := []
    while s := pop(wordlist) do {
        start := ?3; dirs := ""
        every dirs ||:= ((start to 3) | (1 to start-1))
        begy := ?height; begx := ?width
        every y := (begy to height) | (1 to begy - 1) do {
        if &time > timeout then fail
        every x := (begx to width) | (1 to begx - 1) do  {
            if insert_word(puzzle, s, !dirs, !dirs, y, x) then
            break { break next }
        }
        }
        # If we can't find a place for s, put it in the rejects list.
        put(rejects, s)
    }
    }

    # Nothing useful to return (puzzle, wordlist, and rejects objects
    # are themselves modified; not copies of them).
    return

end


procedure insert_word(puzzle, s, ydir, xdir, y, x)

    local incry, incrx, firstchar

    # If s is zero length, we've matched it in it's entirety!
    if *s = 0 then {
    return

    } else {

    # Make sure there's enough space in the puzzle in the direction
    # we're headed.
    case ydir of {
        "3":  if (height - y) < (*s - 1) then fail
        "1":  if y < (*s - 1) then fail
    }
    case xdir of {
        "3":  if (width - x) < (*s - 1) then fail
        "1":  if x < (*s - 1) then fail
    }

    # Check to be sure everything's in range, and that both the x and
    # y increments aren't zero (in which case, we aren't headed in any
    # direction at all...).
    incry := (ydir - 2); incrx := (xdir - 2)
    if incry = 0 & incrx = 0 then fail
    height >= y >= 1 | fail
    width >= x >= 1 | fail

    # Try laying the first char in s down at puzzle[y][x].  If it
    # works, head off in some direction, and try laying down the rest
    # of s along that vector.  If at any point we fail, we must
    # reverse the assignment (<- below).
    firstchar := !s
    ((/puzzle[y][x] <- firstchar) | (\puzzle[y][x] == firstchar)) &
        insert_word(puzzle, s[2:0], ydir, xdir, y + incry, x + incrx) &
        suspend
    fail
    }

end

From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:[e-mail]  Thu Mar 19 19:20:50 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 19 Mar 92 19:20:50 MST
Received: from  by optima.cs.arizona.edu (4.1/15)
    id AB12498; Thu, 19 Mar 92 19:20:39 MST
Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET
          with NIFTP id <[e-mail]>;
          Wed, 18 Mar 1992 17:01:28 +0000
Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa16668;
          18 Mar 92 16:58 WET
Date: 18 Mar 92 16:58:56 gmt
From: [e-mail]
Subject: Matchhing of place names
To: [e-mail]
Message-Id: <18 Mar 92 16:58:56 gmt 320503@EMAS-A>
Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:[e-mail]>

I'm writing a program to extract map number and grid references from a
gazeteer of place names. I want to allow for 'mis-spellings' on entering the
place names. I am currently trying soundex as a 'fuzzy' matching procedure for
this, but it is not working well, for example, 'Milhill' (a misspelling of
Millhill) is turning up only 'Millwell' when doing a soundex match.

Is anyone out there aware of any more sophisticated methods of doing this sort
of thing?

Thanks.

Roger Hare.

From icon-group-request  Thu Mar 19 19:49:18 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 19 Mar 92 19:49:18 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA13569; Thu, 19 Mar 92 19:49:16 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA27989; Thu, 19 Mar 92 18:41:50 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 11 Mar 92 07:41:35 GMT
From: att!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: Re: puzzle maker #3
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Did anyone notice the two minor, but annoying bugs in puzzle maker
#3 (posted a week or so ago)?  If you noticed them, you get a cigar.
The first is that some words occasionally got inserted l
                                                          i
                                                             k
                                                                e
that, instead of l
                   i
                     k
                       e that.  The other prevented certain attempts
at creating intersecting words from working properly, and under certain
rare circumstances brought about the formation of unusual sequences
like "tortract" (from "tractor").

Sorry about these bugs.  They are fixed in the most recent puzzle-maker
version.  If anyone wants this version, please contact me directly.
My son's diligence in uncovering obscure bugs is what drives the re-
vision process onward....

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]         rutgers!oddjob!gide!sophist!goer

From [e-mail]  Fri Mar 20 05:07:28 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 20 Mar 92 05:07:28 MST
Received: from ADM.MIS.MCW.EDU ([141.106.64.10]) by optima.cs.arizona.edu (4.1/15)
    id AA02759; Fri, 20 Mar 92 05:07:24 MST
Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12865) id
 <[e-mail]>; Fri, 20 Mar 1992 06:08 CST
Date: Fri, 20 Mar 1992 06:08 CST
From: Chris Tenaglia - 257-8765 <[e-mail]>
Subject: Re: Matchhing of place names
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Organization: Medical College of Wisconsin (Milwaukee, WI)
X-Vms-To: IN%"[e-mail]"
X-Vms-Cc: IN%"[e-mail]"

> From:    IN%"[e-mail]" 19-MAR-1992 20:28:57.50
> To:    IN%"[e-mail]"
> Subj:    Matchhing of place names

> I'm writing a program to extract map number and grid references from a
> gazeteer of place names. I want to allow for 'mis-spellings' on entering the
> place names. I am currently trying soundex as a 'fuzzy' matching procedure for
> this, but it is not working well, for example, 'Milhill' (a misspelling of
> Millhill) is turning up only 'Millwell' when doing a soundex match.

> Is anyone out there aware of any more sophisticated methods of doing this sort
> of thing?
> Thanks.
> Roger Hare.

It almost sounds like a spell checker. If you could redirect the dictionary
to point to your place table with some kind of spell check software. Well
that may or may not be possible.

I wrote I spelling test program for my daughter, that tries to guess which
word was wrong. It works as long as the misspelling isn't too lexically
different and the list of words aren't too lexically similar. Again, this
might not be appropriate to your goals. I am including it, as it might give
you other ideas. Good luck!

Chris Tenaglia (System Manager) |  "The past explained,
Medical College of Wisconsin    |   the future fortold,
8701 W. Watertown Plank Rd.     |   the present largely appologized for."
Milwaukee, WI 53226             |   Organon to The Doctor
[phone]                   |
[e-mail]

#
# SPELLTEST.ICN          11/26/90          BY TENAGLIA
#
# THIS SIMPLE PROGRAM ADMINISTERS A SPELLING TEST. THE WORDS SHOULD BE LISTED
# ONE PER LINE IN AN ANSWER FILE. THE TEACHER CAN ISSUE THE WORDS IN ANY ORDER
# AS THE TRIES AND ANSWERS ARE FINALY SORTED AND COMPARED IN PARALLEL. THIS
# SORT OF IMPLIES THAT THE WORDS SHOULD NOT BE TOO LEXICALLY ALIKE. THE GOOF
# UPS AND SCORES ARE OUTPUT AT THE END OF THE TEST. THE ANSWER FILE IS PIPED
# INTO STDIN. USAGE : ICONX SPELLTEST <ANSWERS
#
global tty
procedure main()

  answers := []          # THE CORRECT WORDS LOADED HERE
  words   := []          # THE STUDENTS TRIES STORED HERE
  tally   := table(0)    # SCORE KEEPER
  tty     := open("tt:","b")
#
# INITIAL DIALOG
#
  write("\e[2J\e[H\e#3Spelling Test")
  write("\e#4Spelling Test")
  write("\nLoading spelling words...")
  while put(answers,map(read()))
  write("Spelling words loaded. Commencing test. ",*answers," problems.\n")

#
# ADMINISTER THE TEST
#
  every i := 1 to *answers do
    put(words,map(input("\e#6" || i || ". ")))

#
# SORT FOR CORRECTING
#
  first  := sort(answers)
  second := sort(words)

#
# CORRECT THE RESULTS
#
  every i := 1 to *first do
    {
    result := if first[i] == second[i] then "correct" else "incorrect"
    tally[result] +:= 1
    (first[i] == second[i]) | write("\e[1;5m",second[i],"\e[m is wrong. It should have been spelled \e[1;5m",first[i],"\e[m")
    }

#
# SUMMARY OF PERFORMANCE
#
  write("\n",tally["incorrect"]," were incorrect.")
  write(tally["correct"]," were correct out of ",*answers," words.")
  write("Final score is ",tally["correct"]*100/(*answers),"%.")
  end

#
# THIS PROCEDURE TAKES A PROMPTED STRING INPUT
#
procedure input(prompt)
  writes(prompt)
  return read(tty)
  end



From [e-mail]  Fri Mar 20 13:12:51 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 20 Mar 92 13:12:51 MST
Received: from timbuk.cray.com by optima.cs.arizona.edu (4.1/15)
    id AA22598; Fri, 20 Mar 92 13:12:42 MST
Received: from cherry04.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ac)
    id AA01991; Fri, 20 Mar 92 14:12:38 CST
Received: by cherry04.cray.com
    id AA07859; 4.1/CRI-5.6; Fri, 20 Mar 92 14:12:37 CST
Date: Fri, 20 Mar 92 14:12:37 CST
From: [e-mail] (David S. Cargo)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Recognizer Generator

The February issue of the Icon Analyst had a good, in-depth article
about a recognizer generator.  The last couple of paragraphs in the
article said, "Having posed these problems, we'll now have to solve
them ourselves.  The result may be in the Icon program library before
this issue of the Analyst is published."

I've looked through the library and not found a sign of the original
program, much less the one that solves the problems mentioned in
the article.  Anybody know if such a program (or even the original)
is forthcoming?          o       o
[e-mail]  \_____/
[phone]           /=O=O=\     _______
DDDD      SSSS   CCCC   /   ^   \   /\\\\\\\\
D   D    S      C       \ \___/ /  /\   ___  \
D   D     SSS   C        \_ V _/  /\   /\\\\  \
D   D        S  C          \  \__/\   /\ @_/  /
DDDDavid SSSS.   CCCCargo   \____\____\______/

From [e-mail]  Fri Mar 20 17:48:46 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 20 Mar 92 17:48:46 MST
Received: from ucsd.edu by optima.cs.arizona.edu (4.1/15)
    id AA18306; Fri, 20 Mar 92 17:48:43 MST
Received: from odin.ucsd.edu by ucsd.edu; id AA28325
    sendmail 5.64/UCSD-2.2-sun via SMTP
    Fri, 20 Mar 92 16:48:31 -0800 for [e-mail]
Received: from gremlin.ucsd.edu by odin.ucsd.edu (4.1/UCSDPSEUDO.4)
    id AA23150 for [e-mail]; Fri, 20 Mar 92 16:48:30 PST
Received: by gremlin.ucsd.edu (4.1/UCSDPSEUDO.4)
    id AA10028 for [e-mail]; Fri, 20 Mar 92 16:48:29 PST
Date: Fri, 20 Mar 92 16:48:29 PST
From: [e-mail] (William Griswold)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: converting troff bib information to bibtex (and vv)

Any of you consummate Icon programs out there have a program for converting
from the troff bib format to latex's bibtex format, or vice versa?

Thanks.

                        bill

From icon-group-request  Sat Mar 21 09:44:08 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 21 Mar 92 09:44:08 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA16774; Sat, 21 Mar 92 09:44:06 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA04848; Sat, 21 Mar 92 08:41:29 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 20 Mar 92 02:32:58 GMT
From: rudy.rutgers.edu!pilot.njin.net![e-mail]  (Bob Gajarsky)
Organization: Somewhere in Hoboken
Subject: SURVEY:Please read, for scholastic purposes.
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]


    Please note this message is being crossposted to a large number
of groups.  I am sorry for any inconvenience, but there are members of
many newsgroups that I wish to reach , and this is the only way that
I can accomplish this.  Thank you for your understanding.

=========================================================================

    My name is Bob Gajarsky.  I am a graduate level management student,
and am conducting a survey for one of my classes.  It would greatly help my
studies if you could take a few minutes and complete the following survey.
All results will be kept completely confidential, and your e-mail addresses
will not be seen by anyone but me.

    Also, I am only looking for complete surveys from people who are
actually out in the workplace as computer programmers, as opposed to those
(like me) who are students.  Additionally, I would request that only people
who work in the United States reply to this.  Thank you in advance for your
responses.

--------------------------- BEGINNING OF SURVEY -----------------------------

What city is your place of work?    -
(OPTIONAL) What company do you work at?    -

How many years of programming experience do you have?

How many years of post-high school education have you had?

How many computer languages do you know?
    If you program in any of the following languages, please check it:

    Ada        APL        Cobol
    C        C++        Fortran
    Lisp        Pascal

How many software packages do you know how to use (ie. Lotus, MS-Works, etc.)

    1-2        3-5        6-8
    9-10        over 10

Do you know any databases? (Y/N)
    If so, which ones?

On the average, how many hours does it take you to learn a application (ie.
    Word Processor, Graphics Package, etc.)?

How do you prefer to learn new applications?  More than one may be checked:
    Tutorials
    Videos
    Self-Instruction
    Other  _________________________

Do you personally have a VCR? (Y/N)

Does your workplace have a VCR? (Y/N)

Have you ever used a video to learn an application before? (Y/N)
    If so, how would you rate it?
    (10 is an excellent experience, 1 is an awful experience)
    Based on your past experiences, would you be receptive to learning
        another application via video?
        (10 is very receptive; 1 is not receptive at all)

    If not, how receptive would you be to learning a application via video?
        (10 is very receptive; 1 is not receptive at all)

How many hours of video would you be able to successfully watch for
    a specific application?

How much would you or your company pay for the following:
    A) A 15 hour video that teaches how to generally work with databases,
        program in them, and utilize them.  (Between 40$ and 150$)
    B) A 3 hour video that teaches a specific database, (Oracle, etc.)
        (Between 15$ and 75$).
    C) A packaged of both (A) and (B).
        (Between 50$ and 225$).

Which systems do you have a familiarity with?
    VAX/VMS        UNIX
    Macintosh    IBM Compatible
    Other

-------------------   END OF SURVEY ---------------------------------

Thanks! - Bob Gajarsky

From [e-mail]  Thu Mar 26 09:33:02 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 26 Mar 92 09:33:02 MST
Message-Id: <[e-mail]>
Received: from socrates.umd.edu by optima.cs.arizona.edu (4.1/15)
    id AA05499; Thu, 26 Mar 92 09:32:58 MST
Received: by socrates.umd.edu
    (16.6/16.2) id AA02735; Thu, 26 Mar 92 11:31:33 -0500
From: John Kohl <[e-mail]>
Subject: Windows 3.0
To: [e-mail]
Date: Thu, 26 Mar 92 11:31:31 EST
X-Mailer: ELM [version 2.3 PL11]


A friend of mine is developing a game under Windows 3.0 using
Microsoft's QuickC.  We would like to use Icon for prototyping
the computer playing the game.

Icon is capable of calling and being called by C.  (I haven't
tried this yet.)  Understandably, Icon hasn't been ported to
Windows 3.0.  With XIcon there is no serious reason to port.

Is there a way to have to have a QuickC Windows 3 program invoke
MS-DOS Icon as a subprogram?  If so, how.

        Thanks,

        John Kohl

        [e-mail]


From cjeffery  Thu Mar 26 11:40:15 1992
Received: from chuckwalla.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 26 Mar 92 11:40:15 MST
Date: Thu, 26 Mar 92 11:40:13 MST
From: "Clinton Jeffery" <cjeffery>
Message-Id: <[e-mail]>
Received: by chuckwalla.cs.arizona.edu; Thu, 26 Mar 92 11:40:13 MST
To: [e-mail]
Cc: [e-mail]
In-Reply-To: John Kohl's message of Thu, 26 Mar 92 11:31:31 EST <[e-mail]>
Subject: Windows 3.0

   John Kohl, [e-mail], writes:
   > Understandably, Icon hasn't been ported to Windows 3.0.
   > With XIcon there is no serious reason to port.

Well, there are "good" reasons to port to Windows 3.0, Macintosh, Amiga, etc.
Icon runs on all these machines, but can't access the graphics and mouse
capabilities on them.  Unfortunately, this is not a matter of research.

It is up to commercial implementors or dedicated users of each particular
window system to add graphics access to Icon.  X-Icon proves such a task
can be done, but does not purport to be "complete" and implementors on
other window systems are likely to add system-specific features.  I am
always interested in talking to people doing graphics access for Icon.

Clint Jeffery

From icon-group-request  Sat Mar 28 22:05:59 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 28 Mar 92 22:05:59 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA21623; Sat, 28 Mar 92 22:05:55 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA24267; Sat, 28 Mar 92 21:03:09 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 Mar 92 11:06:46 GMT
From: mcsun!uknet!pcl![e-mail]  (John Ditrolio)
Organization: Polytechnic of Central London
Subject: Tree Implementation
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

To whoever can help,

I am trying to write a grammar checking program and I am intendingto set up a
dictionary file with corresponding tokens for each word.

Can anyone tell me what is the most efficient way of handling the large amount
of data? I could possibly pull the contents of a dictionary file into a tree
structure of some sort (maybe records) which I will need to access
continuously.

I've looked in the Icon "bible" (Icon Programming Language Manual) and I cannot
see how I can implement a binary tree structure similar to that in C.

Please can someone help ????

I am relatively new to Icon and so beg forgiveness for my stupidity.




John Ditrolio.

From [e-mail]  Sun Mar 29 07:20:04 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 29 Mar 92 07:20:04 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA06924; Sun, 29 Mar 92 07:19:58 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA10682; Sun, 29 Mar 92 16:20:50 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA03440; Sun, 29 Mar 92 16:18:53 +0200
Date: Sun, 29 Mar 92 16:18:53 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], mcsun!uknet!pcl![e-mail]
Subject: Re:  Tree Implementation

Hi,

I'm new to the ICON group as well, but I think I might have a useful
suggestion for the representation of a lexicon (the problem that John
Ditrolio has in his parser).

The problem he stated has not much to do with computer languages, but
with representation techniques in general. Once a useful representation
is decided upon, implementing it in ICON will probably be not very hard,
given the tremendous flexibility of ICON data structures.

One of the most efficient techniques for "lexical lookup" is the use of the
so called "TRIE" data structure [Fredkin, 1960]. I'll give a reference
below, but the basic idea is the following:

Suppose (for simplicity) that we want to store the items "apple", "ape",
"an" and "bee". The trie then looks like this:

                        [ROOT]
                        /    \
                      [a]     [b]
                    /    \       \
                  [p]    [n]*     [e]
                /    \              \
             [p]     [e]*           [e]*
            /
          [l]
         /
       [e]*

The algorithm to build and search a TRIE is not very complicated, so
I won't waste space and time on that. I use this representation for
fast lookup in large lexical databases, but i've written that program
in C. If any one of you has an implementation of 'TRIES' in ICON, I
would be interested!.

REFERENCE: Fredkin, E.H. 1960. Trie memory, CACM 3:9 (sept), 490-500.

Jan Peter de Ruiter
Netherlands (Europe)
email: [e-mail]



From [e-mail]  Sun Mar 29 11:13:33 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 29 Mar 92 11:13:33 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA12070; Sun, 29 Mar 92 11:13:28 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA11456; Sun, 29 Mar 92 20:14:21 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA03709; Sun, 29 Mar 92 20:12:24 +0200
Date: Sun, 29 Mar 92 20:12:24 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: tree implementation.

Hi,

I'm new to the ICON group as well, but I think I might have a useful
suggestion for the representation of a lexicon (the problem that John
Ditrolio has in his parser).

The problem he stated has not much to do with computer languages, but
with representation techniques in general. Once a useful representation
is decided upon, implementing it in ICON will probably be not very hard,
given the tremendous flexibility of ICON data structures.

In chapter 15 of the "Bible" (second edition) a very clear explanation
can be found on how to implement trees in ICON.

One of the most efficient techniques for "lexical lookup" is the use of the
so called "TRIE" data structure [Fredkin, 1960]. I'll give a reference
below, but the basic idea is the following:

Suppose (for simplicity) that we want to store the items "apple", "ape",
"an" and "bee". The trie then looks like this:

                        [ROOT]
                        /    \
                      [a]     [b]
                    /    \       \
                  [p]    [n]*     [e]
                /    \              \
             [p]     [e]*           [e]*
            /
          [l]
         /
       [e]*

One can also choose to explicitly store whole items at the 'leaves'
instead of a marker (like '*') but that is wasting storage.

The algorithm to build and search a TRIE is not very complicated, so
I won't waste space and time on that. I use this representation for
fast lookup in large lexical databases, but I've written that program
in C. If any one of you has an implementation of 'TRIES' in ICON, I
would be interested!.

REFERENCE: Fredkin, E.H. 1960. Trie memory, CACM 3:9 (sept), 490-500.

Jan Peter de Ruiter
Netherlands (Europe)
email: [e-mail]



From gmt  Sun Mar 29 18:22:10 1992
Received: from owl.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 29 Mar 92 18:22:10 MST
Date: Sun, 29 Mar 92 18:22:14 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by owl.cs.arizona.edu; Sun, 29 Mar 92 18:22:14 MST
To: [e-mail], mcsun!uknet!pcl![e-mail]
Subject: Re:  Tree Implementation

I think some people can't see the forest for the trees (groan).  While you
can certainly implement tree structures in Icon, the original question asked
for the best way to hold a dictionary for use in a grammar checking program.
For that, a table indexed by words is the obvious solution.  Internally,
it's implemented efficiently by a hash table.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    [phone]     [e-mail]     110 57 16 W / 32 13 45 N / +758m

From icon-group-request  Tue Mar 31 01:01:04 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 31 Mar 92 01:01:04 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA07738; Tue, 31 Mar 92 01:01:01 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA13393; Mon, 30 Mar 92 23:45:44 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 30 Mar 92 15:45:57 GMT
From: mcsun!unido!infbssys![e-mail]  (Martin Neitzel)
Organization: Inst. f. Informatik, TU Braunschweig, FRG
Subject: old startup header in icode files
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

I just installed Icon (v8) on a second architecture at our site.
Which made me ask myself:  Would icode files with old v7-style headers
give me architecure independent executables?

(For those who need to know: icode files were made executable by
directing the unix kernel with the first line '#!/usr/local/bin/iconx'
to the proper interpreter for the rest of the file, ie. the icode.
Given that there no troubles due to, say, byte sex, you could develop
and share icon programs across architectures.)

My questions to the experts: Would #defining NoHeader help?  And: why
were the new machine specific headers introduced, anyway?

                        Martin Neitzel

From [e-mail]  Tue Mar 31 06:13:28 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 31 Mar 92 06:13:28 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA19607; Tue, 31 Mar 92 06:13:20 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA02448; Tue, 31 Mar 92 14:27:07 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA02399; Tue, 31 Mar 92 14:25:20 +0200
Date: Tue, 31 Mar 92 14:25:20 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: ICON-C INTERFACE

I have as yet been unable to figure out how to call C from ICON. Speci-
fically, I don't know how to build c modules that are callable. Of course
the infamous document tr90-8.doc is in my possession, but it is beyond my
intellectual capacity to figure out from that document how to do it.

Is there any document available that explains the ICON->C interface (I don't
care about C->ICON, unless I need that one for ICON->C) to someone who can
program in ICON and C, but has no knowledge of how icon is implemented?

Greetings,

Jan Peter de Ruiter
email: [e-mail]

From ralph  Tue Mar 31 06:47:07 1992
Date: Tue, 31 Mar 92 06:47:07 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by cheltenham.cs.arizona.edu; Tue, 31 Mar 92 06:47:07 MST
To: [e-mail], [e-mail]
Subject: Re:  ICON-C INTERFACE

Unfortunately, you cannot, except in the most trivial cases, call C
functions from Icon without knowing something about both Icon and C
data structures.  The two have different representations of data,
and it's necessary to convert between them.

TR90-8 lists the functions that are available for conversion and gives
examples.  Admittedly, it's not trivial.  But it's the only interface
available at the moment.

By the way, it is not necessary to know anything about calling Icon
from C to call C from Icon; the two facilities are independent.

    Ralph Griswold / Department of Computer Science
    The University of Arizona / Tucson, AZ 85721

    [e-mail] / uunet!arizona!ralph

    voice: 602-621-6609 / fax: [phone]

From [e-mail]  Tue Mar 31 14:39:32 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 31 Mar 92 14:39:32 MST
Received: from Princeton.EDU by optima.cs.arizona.edu (4.1/15)
    id AA14201; Tue, 31 Mar 92 14:39:29 MST
Received: from fs.Princeton.EDU by Princeton.EDU (5.65b/2.88/princeton)
    id AA14036; Tue, 31 Mar 92 16:39:26 -0500
Received: from cs.Princeton.EDU (elan.Princeton.EDU) by fs.Princeton.EDU (4.0/1.105)
    id AA22299; Tue, 31 Mar 92 16:39:24 EST
Received: by cs.Princeton.EDU (5.57/1.105)
    id AA05809; Tue, 31 Mar 92 16:39:23 -0500
Date: Tue, 31 Mar 92 16:39:23 -0500
From: Mary F. Fernandez <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Interpreting expressions in strings


Version 8 allows the application of an operator
represented by a string (e.g. "*"(2,4) === 2*4),
but it does not appear to interpret operands which
are represented as string (e.g. "*(2,4)" is not 2*4).
I thought there was a facility for interpreting
an expression read as input.  Does this exist?  Is
it built-in?  If not, if you have such an interpreter,
could you post it?
Thanks,
Mary Fernandez
[e-mail]
Dept. of Computer Science
Princeton University
35 Olden St.
Princeton, NJ 08544-2087

From ralph  Wed Apr  1 17:02:02 1992
Date: Wed, 1 Apr 92 17:02:02 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by cheltenham.cs.arizona.edu; Wed, 1 Apr 92 17:02:02 MST
To: icon-group
Subject: Version 8.6 of Icon for UNIX platforms

Version 8.6 of Icon is now available for UNIX platforms. Both the interpreter
and the optimizing compiler are included.

Version 8.6 adds a few functions to Icon as described in Icon Newsletter 38
and provides support for keyboard functions for some UNIX platforms. The
most significant language extension in Version 8.6, however, is the addition
of graphics capabilities for platforms that have X Window facilities.

The UNIX distribution includes source code, documentation in machine-readable
form, the Icon program library, and support for variant translators.

The new version is available via anonymous FTP from cs.arizona.edu.
cd /icon/packages/unix and get unix_tar.Z in binary (image) mode.

Version 8.6 of Icon for UNIX also is available on magnetic media together
with printed documentation. Tapes and cartridges can be ordered as
described in recent Icon Newsletters. It also is available on three 1.44MB
MS-DOS format diskettes. The price for diskettes is $25. Add $5 for
shipping to countries other than the United States, Canada, and Mexico.

Direct any questions about Version 8.6 of Icon for UNIX to

    [e-mail]


    Ralph Griswold / Department of Computer Science
    The University of Arizona / Tucson, AZ 85721

    [e-mail] / uunet!arizona!ralph

    voice: 602-621-6609 / fax: [phone]

From [e-mail]  Thu Apr  2 06:48:38 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Apr 92 06:48:38 MST
Received: from ixgate.gmd.de by optima.cs.arizona.edu (4.1/15)
    id AA24102; Thu, 2 Apr 92 06:48:02 MST
Received: by ixgate.gmd.de id AA14751; Thu, 2 Apr 92 15:48:08 +0200
Date: 2  Apr 92  9:57
From: "(Michael Sperber)" <[e-mail]>
Message-Id: <RFC-822:>
Subject: Icon 8.5 /386 problems
Apparently-To: [e-mail]

RFC-822-HEADERS:
Return-Path: <@CDC2.RRZN.UNI-HANNOVER.DE:[e-mail]>
To: @CDC2:[e-mail]

==================
I've been playing around with the 386 version of Icon 8.5
(the one out of Intel's Code Builder). I've written a
disk cataloguing system for MSDOS that can look into compressed
archives (LHARC, ARJ, PKZIP, PKARC). It shells out to
external programs both to get the directory contents and
the archive contents. However, bizarre non-reproducible
things happen to my output files after any external program has
been called (looks like memory dump right in the middle of things).
Has anyone else encountered problems like that? Also, Icon/386 doesn't
seem to work with GNUish make 3.58. Any comments?

Chipsy Sperber :-> [e-mail]

In case anyone is interested in the cataloguing system, please
mail me. It's free for anyone.

From kwalker  Thu Apr  2 13:58:08 1992
Received: from ponderosa.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Apr 92 13:58:08 MST
Date: Thu, 2 Apr 92 13:58:07 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
Received: by ponderosa.cs.arizona.edu; Thu, 2 Apr 92 13:58:07 MST
To: icon-group
Subject: Re:  old startup header in icode files

I didn't see anyone respond to this, so I'll give it a try:

> Date: 30 Mar 92 15:45:57 GMT
> From: mcsun!unido!infbssys![e-mail]  (Martin Neitzel)
>
> I just installed Icon (v8) on a second architecture at our site.
> Which made me ask myself:  Would icode files with old v7-style headers
> give me architecure independent executables?
>
> (For those who need to know: icode files were made executable by
> directing the unix kernel with the first line '#!/usr/local/bin/iconx'
> to the proper interpreter for the rest of the file, ie. the icode.
> Given that there no troubles due to, say, byte sex, you could develop
> and share icon programs across architectures.)
>
> My questions to the experts: Would #defining NoHeader help?  And: why
> were the new machine specific headers introduced, anyway?

If the C data types, including some structs, used in the implemention of
Icon (or at least those stored in the icode file) are implemented the same
on both systems, it should work.

Defining NoHeader will force you to explicitly call iconx.

Here is an untested suggestion:

    change MaxHdr in h/define.h to 24 (double check this number, it must
       match the size of array changed in the next step)

    change the contents of the iconxhdr array in icont/hdr.h to
       "#!/usr/local/bin/iconx\n"

    change icont/Makefile so it does not rebuild hdr.h from ixhdr.c

    rebuild icont and iconx

Good luck.

  Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
  [phone]  [e-mail]   uunet!arizona!kwalker

From cjeffery  Thu Apr  2 17:06:12 1992
Received: from chuckwalla.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Apr 92 17:06:12 MST
Date: Thu, 2 Apr 92 17:06:11 MST
From: "Clinton Jeffery" <cjeffery>
Message-Id: <[e-mail]>
Received: by chuckwalla.cs.arizona.edu; Thu, 2 Apr 92 17:06:11 MST
To: icon-group
In-Reply-To: "Kenneth Walker"'s message of Thu, 2 Apr 92 13:58:07 MST <[e-mail]>
Subject:  old startup header in icode files

Martin Neitzel recently asked why #!/usr/local/bin/iconx was dropped
in favor of the current scheme.  I can't speak for the people who made
this decision, but I would note that the #! syntax for redirecting
"shell scripts" to the appropriate interpreter is not portable and just
doesn't work on a lot of UNIX systems.

On the other hand, a VERY plain shell script that asks to run iconx on
the "shell script" itself ought to be fairly portable if done correctly.
I would love to see this if anyone did it well.

As another aside, the executable headers we are using now do various
interesting things before calling iconx, such as looking at environment
variables and allowing patches (in Version 8.5 and above) to override
the default name of iconx that icont uses.

Martin's questions also raise the possibility of a truly portable icode
file format that would run unmodified on *any* iconx.  This is in principle
not very difficult and should be implemented by someone who needs it, or
a commercial Icon implementor who wants to add value to their product.

Icode files already contain interesting offset-based instructions that
modify themselves into direct pointer-based instructions the first time
they are executed.  The same approach could be applied to the job of
making icode portable, adding extra instructions for things like
architecture-neutral integers that convert themselves into machine
integers the first time they are executed.  Network-knowledgable
hackers would see this as simply a matter of adding some calls to ntohl()
to the interpreter, and it likely wouldn't slow performance significantly.

From [e-mail]  Thu Apr  2 17:55:46 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Apr 92 17:55:46 MST
Received: from relay.metaphor.com by optima.cs.arizona.edu (4.1/15)
    id AA24380; Thu, 2 Apr 92 17:55:43 MST
Received: from laguna.Metaphor.COM by relay.metaphor.com (4.1/SMI-4.1)
    id AA07769; Thu, 2 Apr 92 16:52:37 PST
Received: by laguna.Metaphor.COM (4.1/SMI-4.0)
    id AA07885; Thu, 2 Apr 92 16:56:13 PST
Date: Thu, 2 Apr 92 16:56:13 PST
From: [e-mail] (Bob Alexander)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: old startup header in icode files

> On the other hand, a VERY plain shell script that asks to run iconx on
> the "shell script" itself ought to be fairly portable if done correctly.
> I would love to see this if anyone did it well.

Your request granted:

    #!/bin/sh
    exec "${ICONX-iconx}" "$0" "$@"

How "well" this is done is probably a subject for debate!

The Icon Newsletter recently had an article on alternative iconx
headers (written by me).  Included in the article is this shell script
approach.  The text of the article is attached.

This article was printed with a disclaimer stating that the #! approach
was once used for icode files, but was discarded because of numerous
problems.  I think the worst was that the path length is quite limited
-- something like 32 characters in Sun UNIX -- which caused a support
headache for the Icon Project.

Wierdly, if the #! line is omitted from this script (in sun4 UNIX, at
least) it won't work.  With the #! line, $0 produces the full path name
of the command used to invoke the script (which is the icode file
name); without the #! only the command name is substituted.  The full
path is necessary for the script to be able to find the icode file
(i.e. itself) if it does not reside in the current working directory.
This subtle behavior difference is a likely source of incompatiblilties
among UNIX variants.

On sun3 and sun4 systems, each icode file is over 10K smaller using
this approach!  That makes a big difference to me since I have over 100
misc Icon programs around -- a total of over 1M saved.

Anyway, header fans, enjoy:

-- Bob Alexander

Metaphor Computer Systems   [phone] x751   [e-mail]
====^=== Mountain View, CA  ...{uunet}!{decwrl,apple}!metaphor!alex

============================================================

Smaller Icode Files for UNIX-based Icon Implementations
-------------------------------------------------------

In this article, a method is discussed that can decrease the size of
Icon icode files (the "executable" files produced by icont).  The
techniques discussed here apply only to Icon implementations that
support the "direct execution" feature.  Implementations that do not
support direct execution, such as MS-DOS, cannot benefit from these
techniques.  In particular, this discussion applies to UNIX
implementations, but the techniques may apply to other platforms (they
are currently used in the standard Macintosh Programmer's Workshop
implementation).

An icode file consists of a header part and an icode part.  The icode
part contains the operations and data specifications that make up an
Icon program.  The header is the part that allows the icode file to be
directly executable as a command, without having to type "iconx".

    +---------------+    Beginning of icode file
    |        |
    |    header    |
    |        |
    +---------------+
    |        |
    |        |
    |    icode    |
    |        |
    |        |
    +---------------+    End of icode file

In UNIX implementations of Icon, the header takes the form of a small
program that invokes the iconx interpreter to execute the icode part of
itself.  In some versions of UNIX, the small header program ends up
being disturbingly large once all the needed library code is linked in
(something like 16K bytes on a Sun 3!).  Since the Icon program is
contained in the icode part, the header is just an overhead part of the
file.  For that reason, and since the header is replicated in each
icode file, it is desirable that the header be as small as possible.
This article discusses some alternative approaches to the header that
can result in significantly smaller icode files.

The header program as implemented in the current Icon UNIX distribution
is a C program.  The header itself is the executable code produced by
the C compiler and linker.  Two other approaches are examined here:
(1) using UNIX's shell-invocation format in place of a header, and (2)
using a shell script as a header.


Shell Invocation Line Approach
------------------------------

A "shell" program to execute a script file can be specified in UNIX by
beginning the file with a line of the following format:

    #!shell-command-name<carriage return>

When such a file MyScript is executed as a command (it must have
execute permission), the system behaves as if the following command had
been issued:

    shell-command-name MyScript

Viewing iconx (the Icon executor program) as a "shell" that executes
icode files, the header can consist of a #! line instead of executable
machine code.

    #!/usr/icon/v8/bin/iconx
    .........icode..........

Advantages:

    - Very small
    - Fast execution

Disadvantages:

    - Length of iconx file path name is limited (max of 32
      characters in SunOS)
    - Doesn't fully support the documentation (e.g. doesn't
      recognize the ICONX environment variable)
    - Requires full path specification of the iconx interpreter
      (no variables permitted)


Shell Script Approach
---------------------

A shell script as a header can match the documentation, but is not as
streamlined as the Shell Invocation approach.  However, it is the
solution that I have adopted, and I've found it to be quite
satisfactory in my SPARCstation 2 environment.

Advantages:

    - Small
    - Fully lives up to the documented behavior
    - Finds iconx interpreter in PATH directories

Disadvantages:

    - Not quite as fast as the #! method

I wanted the script to be for the Bourne shell, since that is the
ubiquitous shell available with all UNIX systems.

Here is a Bourne shell version that does the job nicely (thanks to
Gregg Townsend for suggesting this elegant and compact solution):

    #!/bin/sh
    exec "${ICONX-iconx}" "$0" "$@"

If the ICONX shell variable is undefined, the iconx executable is
located via the current PATH variable.  A small variation to this
script could point to an iconx executor in a specific hard-wired
location; change the second line to:

    exec "${ICONX-/usr/icon/v8/bin/iconx}" "$0" "$@"

Be warned:  the first line, "#!/bin/sh", MUST BE PRESENT for this
script to work properly under all circumstances.  Even though UNIX will
default to executing the Bourne shell if no "#!" line is present, the
shell behaves somewhat differently depending on whether or not the "#!"
line is included.

Even if you prefer another shell for interactive command entry (such as
the C or Korn shell), usage of the above Bourne shell header presents
no conflict.  However, just for fun, the following slightly longer
C-shell script could be used and is functionally equivalent:

    #!/bin/csh -f
    if ($?ICONX) set ICONX=iconx
    exec "$ICONX" "$0" $*:q

Note the -f option provided to csh in the first line of the C shell
script.  The -f option (for "fast") bypasses the usual act of executing
the .cshrc startup script, making it quicker.


How do I convert my Icon system to use small headers?
-----------------------------------------------------

The required steps are as follows:

    1. Modify the icont makefile to omit construction of
       the C header.
    2. Hand-code a .h file for the script header.
    3. Reduce the space reserved in each output icode file for
       the header.

The header that is copied to every icode file resides in the the
translator/linker tool, icont.  The makefiles provided with the Icon
distribution compile the C program that comprises the header portion of
normal icode files.  A utility program is then executed that converts
the resulting executable machine code to a .h text file that is #included
in icont.

The makefile for icont (in the src/icont directory) should be modified:

    - omit the compile and link of the C header
      (ixhdr.c -> ixhdr.o -> iconx.hdr)
    - omit the conversion of the resulting executable to a .h file
      (iconx.hdr -> hdr.h)

Then a hand-coded hdr.h file is constructed containing the desired
script; e.g. (note that all lines in this example must be flush against
the left margin):

    static char iconxhdr[MaxHdr+1] = "\
    #!/bin/sh\n\
    exec \"${ICONX-iconx}\" \"$0\" \"$@"\n";

Be careful; if you didn't modify your makefile correctly, the build
could clobber your painstakingly hand-written hdr.h file.

Finally, adjust the size of the area reserved for the header in the
file src/h/define.h.

    #define MaxHdr 256

The script I use (the example above) is fewer than 100 characters, but
I specify a size of 256 to allow room for, dare I say, future expansion
(for example, adding commands to set the region size environment
variables).  It's still a lot smaller than 16K!

Now, rebuild icont, and enjoy smaller icode files!

From [e-mail]  Fri Apr 10 04:26:27 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 10 Apr 92 04:26:27 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA29573; Fri, 10 Apr 92 04:26:20 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA08740; Fri, 10 Apr 92 13:27:26 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA20777; Fri, 10 Apr 92 13:25:20 +0200
Date: Fri, 10 Apr 92 13:25:20 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: ICON debugger

Is an interactive debugger available for ICON? Sometimes, playing
around with &trace and putting in al lot of write() statements just
is not convenient anymore. I gather, people who test and debug large
ICON programs must have some means to help their debugging. I would be
interested to know how other people debug their ICON programs.

Jan Peter de Ruiter
Max Planck Institute for Psycholinguistics
EMAIL: [e-mail]


From icon-group-request  Sat Apr 11 10:58:43 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 11 Apr 92 10:58:43 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA08205; Sat, 11 Apr 92 10:58:41 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA17253; Sat, 11 Apr 92 10:46:16 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 9 Apr 92 20:05:49 GMT
From: micro-heart-of-gold.mit.edu!wupost!uwm.edu!linac!convex!convex![e-mail]  (Tom Christiansen)
Organization: CONVEX Realtime Development, Colorado Springs, CO
Subject: Re: should I use ICON for a specific problem ?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

From the keyboard of [e-mail]:
:
:There's no reason to worry about flames here.  PERL is a system adminis-
:trator's tool par excellance, with a C interface that's actually much bet-
:ter than Icon's.  Icon is a much cleaner and more disciplined language,
:with a lot more options for control and data structures, coexpressions,
:and what not.  I find PERL a mess, but that's just me.  Probably I just
:don't know it well enough.

Nope, you're right -- in more ways than I care to enumerate, it *is* a
mess.  The amazing thing is how well it gets the job done anyway.

--tom

From icon-group-request  Sat Apr 11 15:14:43 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 11 Apr 92 15:14:43 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA15023; Sat, 11 Apr 92 15:14:36 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA26737; Sat, 11 Apr 92 15:04:00 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 9 Apr 92 12:50:13 GMT
From: mailer.cc.fsu.edu!sun13!sun8.scri.fsu.edu![e-mail]  (John Nall)
Organization: SCRI, Florida State University
Subject: Re: should I use ICON for a specific problem ?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] writes:

   [ ... stuff deleted ... ]
>
>There's no reason to worry about flames here.  PERL is a system adminis-
>trator's tool par excellance, with a C interface that's actually much bet-
>ter than Icon's.  Icon is a much cleaner and more disciplined language,
>with a lot more options for control and data structures, coexpressions,
>and what not.  I find PERL a mess, but that's just me.  Probably I just
>don't know it well enough.

   It is so refreshing to see a well reasoned discussion of ICON vs PERL
   that I can't resist the temptation to say "WELL PUT!!"  I agree with
   everything that Richard said, completely, even to the part of "I find
   PERL a mess, but that's just me".  But it is certainly a gawdawful
   powerful tool in the hands of those who can deal with it :-)

John


--
John W. Nall              | Supercomputer Computations Research Institute
[e-mail]  | Florida State University, Tallahassee, FL 32306

 "Disclaimer:  A world which requires disclaimers has too many lawyers."

From icon-group-request  Sun Apr 12 06:18:10 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 12 Apr 92 06:18:10 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA12340; Sun, 12 Apr 92 06:18:07 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA01492; Sun, 12 Apr 92 06:03:33 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 Mar 92 11:06:46 GMT
From: mcsun!uknet!pcl![e-mail]  (John Ditrolio)
Organization: Polytechnic of Central London
Subject: Tree Implementation
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

To whoever can help,

I am trying to write a grammar checking program and I am intendingto set up a
dictionary file with corresponding tokens for each word.

Can anyone tell me what is the most efficient way of handling the large amount
of data? I could possibly pull the contents of a dictionary file into a tree
structure of some sort (maybe records) which I will need to access
continuously.

I've looked in the Icon "bible" (Icon Programming Language Manual) and I cannot
see how I can implement a binary tree structure similar to that in C.

Please can someone help ????

I am relatively new to Icon and so beg forgiveness for my stupidity.




John Ditrolio.

From icon-group-request  Sun Apr 12 08:03:22 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 12 Apr 92 08:03:22 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA14353; Sun, 12 Apr 92 08:03:19 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA05256; Sun, 12 Apr 92 07:57:01 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 10 Apr 92 17:39:51 GMT
From: micro-heart-of-gold.mit.edu!wupost!csus.edu!netcomsv!mork![e-mail]  (John Nagle)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Subject: Re: lang comparison (not war)
Message-Id: <0#[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] (Victor A. Holen ) writes:

>Is there somewhere (book, ftp, ...) a reasonably objective
>comparison of icon with eiffel with a few other (perhaps c++,
>smalltalk, mainsail..).

       I haven't heard much about Icon in years.  It was intended as
a replacement for Snobol, and perhaps as an alternative to the horrible
"string languages" ("awk", "sed") that come with UNIX.  Icon offers
Snobol-like matching with C-like syntax.  It's intended for a
different class of applications than is Eiffel.

                    John Nagle

From ames.arc.nasa.gov!amdcad!cpsolv!para![e-mail]  Mon Apr 13 21:48:50 1992
Received: from univers.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Apr 92 21:48:50 MST
Received: from hellgate.utah.edu by univers.cs.arizona.edu; Mon, 13 Apr 92 21:48:49 MST
Received: from ames.arc.nasa.gov by hellgate.utah.edu (5.65/utah-2.19s-cs)
    id AA21107; Mon, 13 Apr 92 22:48:34 -0600
Received: from amdcad.UUCP by ames.arc.nasa.gov (5.65c/1.21)
    with UUCP id AA11010 for hellgate.utah.edu!arizona!icon-group
    on Mon, 13 Apr 1992 21:48:27 -0700
Received: from cpsolv.UUCP by amd.com (5.65c/AMD-1.27)
    with UUCP id AA08329 for ames!hellgate.utah.edu!arizona!icon-group;
    Mon, 13 Apr 1992 21:46:05 -0700
Received: by cpsolv.CPS.COM (smail2.5rhg)
    id AA10278; Mon, 13 Apr 1992 20:44:52 CDT
Received: by para.UUCP (smail2.5rhg)
    id AA01808; Mon, 13 Apr 1992 20:37:17 CST
Subject: unsub
To: [e-mail]
Date: Mon, 13 Apr 92 20:37:13 CST
From: John O'Brien <para.cps.com![e-mail]>
X-Mailer: ELM [version 2.3 PL6]
Message-Id: <[e-mail]>

Thanks for the mail the last few months.  I don't need this list
as I have regained USENET access.  See you on the net!
[e-mail]  also  [e-mail]


From cliff  Wed Apr 15 09:08:42 1992
Received: from javelina.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 15 Apr 92 09:08:42 MST
Date: Wed, 15 Apr 92 09:08:42 MST
From: "Cliff Hathaway" <cliff>
Message-Id: <[e-mail]>
Received: by javelina.cs.arizona.edu; Wed, 15 Apr 92 09:08:42 MST
To: icon-group
Subject: address for administrative matters


If you wish to subscribe/unsubscribe/change your address for the icon-group
mailing list, the correct "place" to send it is:

    [e-mail]

This will ensure that it receives prompt attention, and keep it from being
broadcast out to everyone else on the list, and the comp.lang.icon newsgroup,
too!

Thanks.



    Cliff Hathaway
    Dept. of Computer Science [phone]
    University of Arizona     [e-mail]             (internet)
    Tucson, Ariz. 85721          {cmcl2,noao,uunet}!arizona!cliff    (uucp)



From icon-group-request  Thu Apr 16 14:25:05 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 16 Apr 92 14:25:05 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA21088; Thu, 16 Apr 92 14:25:02 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA23155; Thu, 16 Apr 92 14:13:06 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 15 Apr 92 16:43:14 GMT
From: micro-heart-of-gold.mit.edu!wupost!uwm.edu!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: Re: features from Icon Language in lisp
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>My first exposure to a seriously higher level language than C
>was Icon.  (Thank you Ralph Griswold, et al.)  Finally, I got around
>to learning lisp, where I wish I had started, and found that much
>of what I liked about Icon (automatic storage, everything is an
>expression, lists, tables, success->value/failure->nil) was there
>in Common Lisp with a (shall we say) different syntax (and a whole
>lot more, of course).
>
>Has anyone implemented any other of our favorite iconish things
>in Common Lisp or Scheme?  Like goal-directed evaluation,
>string scanning, ... ?

Personally, I feel good about Common LISP.  It's even more bloated than
Icon, though, and people who are really into clean LISP dialects seem
to prefer Scheme.  LISP, of course, isn't object-oriented (yes, another
level of indirection that seems to be the rage these days).  LISP
people are always quick to point out that you can do object-oriented pro-
gramming in LISP, but this is also true of C, Pascal, or even assembler.

The bottom line, I guess, is that we have to be bi- or better yet tri-
lingual, if not quadrilingual+ (e.g. Icon, C, LISP, and perhaps a func-
tional or object-oriented language, and PERL, sed, awk, etc.).  You'll
never get into AI (or Emacs :-)) without LISP, and you'll never run any
thing in real time without C.  You won't get elegant string scanning
outside of Icon.  You won't get your system adminstration work done un-
less you can do shell and awk/sed programming (or PERL).

My gut feeling is that you'll be better off using Icon and LISP, Dave,
when either is appropriate.

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]           rutgers!oddjob!ellis!goer

From [e-mail]  Thu Apr 16 14:53:24 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 16 Apr 92 14:53:24 MST
Received: from hpfcla.fc.hp.com by optima.cs.arizona.edu (4.1/15)
    id AA21778; Thu, 16 Apr 92 14:53:19 MST
Received: from hpfcbig.sde.hp.com by hpfcla.fc.hp.com with SMTP
    (15.11.1.6/15.5+IOS 3.20) id AA05338; Thu, 16 Apr 92 15:52:17 -0600
Received: from hpfcnml.sde.hp.com by hpfcbig.sde.hp.com with SMTP
    (16.6/15.5+IOS 3.12) id AA23657; Thu, 16 Apr 92 15:52:48 -0600
Received: by hpfcase.sde.hp.com
    (16.6/15.5+IOS 3.12) id AA26026; Thu, 16 Apr 92 15:52:46 -0600
From: Robert Heckendorn <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: features from Icon Language in lisp
To: micro-heart-of-gold.mit.edu!wupost!uwm.edu!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz) (Richard L. Goerwitz)
Date: Thu, 16 Apr 92 15:52:44 MDT
Cc: [e-mail]
In-Reply-To: <[e-mail]>; from "Richard L. Goerwitz" at Apr 15, 92 4:43 pm
Physical-Location:
Mailer: Elm [revision: 66.25]

> In article <[e-mail]> [e-mail] writes:
> >My first exposure to a seriously higher level language than C
> >was Icon.  (Thank you Ralph Griswold, et al.)  Finally, I got around
> >to learning lisp, where I wish I had started, and found that much
> >of what I liked about Icon (automatic storage, everything is an
> >expression, lists, tables, success->value/failure->nil) was there
> >in Common Lisp with a (shall we say) different syntax (and a whole
> >lot more, of course).
> >
> >Has anyone implemented any other of our favorite iconish things
> >in Common Lisp or Scheme?  Like goal-directed evaluation,
> >string scanning, ... ?

I haven't done this yet, but I have thought about it.  I think it is
an excellent idea.  Lisp is a *tremendously* flexible language and
adapts well to having layered systems added into it without scrambling
the syntax. (It helps that the syntax is simplistic :-)) The CLOS OO
extensions are an example of how far you can go.  It is great to add
on systems to LISP.  Go for it!

> Personally, I feel good about Common LISP.  It's even more bloated than
> Icon, though, and people who are really into clean LISP dialects seem
> to prefer Scheme.  LISP, of course, isn't object-oriented (yes, another

There is CLOS for OO LISP.  This is a fantastical [sic] OO package.

> level of indirection that seems to be the rage these days).  LISP
> people are always quick to point out that you can do object-oriented pro-
> gramming in LISP, but this is also true of C, Pascal, or even assembler.

I think it is almost debateable if C++ is OO.  :-P

> The bottom line, I guess, is that we have to be bi- or better yet tri-
> lingual, if not quadrilingual+ (e.g. Icon, C, LISP, and perhaps a func-
> tional or object-oriented language, and PERL, sed, awk, etc.).  You'll
> never get into AI (or Emacs :-)) without LISP, and you'll never run any
> thing in real time without C.  You won't get elegant string scanning
> outside of Icon.  You won't get your system adminstration work done un-
> less you can do shell and awk/sed programming (or PERL).
>
> My gut feeling is that you'll be better off using Icon and LISP, Dave,
> when either is appropriate.

My feeling is that Lisp offers a great playground for experimenting
with new ideas in programming functionality.  Note that I say
functionality and not syntax.  If you want to have your cake and eat
it to, build a package for the Icon features you like in Lisp and play
with it.  You may be able to take the knowledge back with you to Icon
and suggest changes in the language.  Coming up with as elegant an
expression in Lisp for the icon expressions may be a little more
difficult.

    Robert Heckendorn
    [e-mail]

>    -Richard L. Goerwitz              [e-mail]
>    [e-mail]           rutgers!oddjob!ellis!goer

From [e-mail]  Thu Apr 16 15:07:56 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 16 Apr 92 15:07:56 MST
Received: from enet-gw.pa.dec.com by optima.cs.arizona.edu (4.1/15)
    id AA22285; Thu, 16 Apr 92 15:05:37 MST
Received: by enet-gw.pa.dec.com; id AA01193; Thu, 16 Apr 92 15:03:26 -0700
Message-Id: <[e-mail]>
Received: from eris.enet; by decwrl.enet; Thu, 16 Apr 92 15:03:50 PDT
Date: Thu, 16 Apr 92 15:03:52 PDT
From: What good is rain that falls up?  16-Apr-1992 1800 <[e-mail]>
To: [e-mail]
Apparently-To: [e-mail]
Subject: Lisp, Icon, and OO

    "LISP, of course, isn't object-oriented (yes, another level of indirection
    that seems to be the rage these days)."

Well, actually, it is. The definition of CLOS (Common Lisp Object System) in
CLtL2 (Common Lisp : the Language, second edition) and the soon-to-be-ANSI
standard make it object oriented.

All Lisp objects are in a class hierarchy, and you can write methods that
handle ordinary Lisp objects, defstruct structures, and of course CLOS objects.

Anyone who isn't writing completely OO Lisp is doing so because they choose to,
or they have an old Lisp system.

    Jon

From icon-group-request  Thu Apr 16 17:37:17 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 16 Apr 92 17:37:17 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA29194; Thu, 16 Apr 92 17:37:13 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA04367; Thu, 16 Apr 92 17:26:46 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 9 Apr 92 04:57:25 GMT
From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: Re: should I use ICON for a specific problem ?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] (Erik E. Rantapaa) writes:
>>>
>>>I wrote a long nawk-file for a machine where no awk-compiler is available.
>>>Now I'm searching for a language with the following spezifications:
>
>Not wishing to get into a Perl vs. Icon flame fest, I would suggest that
>you seriously consider using Perl.  Not only does Perl have many of the
>features that you require, but it also comes with a program called 'a2p'
>which converts awk programs to Perl.

This is probably good advice.  PERL is much closer to AWK than Icon is, and
if you want familiarity from this standpoint, go with PERL.  This answer
just didn't occur to me (I'd guess because the question was phrased, "Can
I do X in Icon?").

There's no reason to worry about flames here.  PERL is a system adminis-
trator's tool par excellance, with a C interface that's actually much bet-
ter than Icon's.  Icon is a much cleaner and more disciplined language,
with a lot more options for control and data structures, coexpressions,
and what not.  I find PERL a mess, but that's just me.  Probably I just
don't know it well enough.

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]           rutgers!oddjob!ellis!goer

From [e-mail]  Fri Apr 17 05:00:28 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 05:00:28 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA19956; Fri, 17 Apr 92 05:00:23 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA26259; Fri, 17 Apr 92 14:01:02 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA02910; Fri, 17 Apr 92 13:59:26 +0200
Date: Fri, 17 Apr 92 13:59:26 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: icon/awk

I don't know excactly how relevant this is to the discussion of ICON vs
PERL vs AWK, but in order to convince colleagues at our institute of the
usefulness of ICON, (they're all AWK freaks) I wrote an ICON lib that
emulates AWK. Once you load this library into an ICON program, you can
do "AWK" and ICON in the same program. Of course, some names (like the $
operator in AWK) have different names in my LIB, but who cares?

Of course, is is not exactly the same as AWK. For instance, you cannot
use (literally) the /pattern/ { action ... } form of AWK. But this is
something ICON is especially suited for, so why not do *that* in ICON
qua ICON? So functionally, what you end up with (in my
opinion) is a mixture of advanced pattern matching, and the ease of
having files conveniently split up in addressable columns. These
programs are of course somewhat slower than original gawk or nawk
programs, unless you compile them, perhaps.

A nice thing about this mixture (seen from the viewpoint of an AWK user)
is that you can use CSETs as field separators and that you can use the
(beautiful) ICON SET datatype.

Currently, I'm trying to implement this module using co-expressions,
which would in principle mean that you can open many AWK-streams at
the same time, which would make the combination even more fruitful.

I'm interested in some comments.

Jan Peter de Ruiter
Max Planck Institute for Psycholinguistics
Nijmegen
The Netherlands
[e-mail]

From icon-group-request  Fri Apr 17 06:38:37 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 06:38:37 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA23021; Fri, 17 Apr 92 06:38:35 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA18607; Fri, 17 Apr 92 06:29:10 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 26 Mar 92 20:15:56 GMT
From: dog.ee.lbl.gov!network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: Re: Windows 3.0
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] ("Clinton Jeffery") writes:
>
>   John Kohl, [e-mail], writes:
>   > Understandably, Icon hasn't been ported to Windows 3.0.
>   > With XIcon there is no serious reason to port.
>
>It is up to commercial implementors or dedicated users of each particular
>window system to add graphics access to Icon.  X-Icon proves such a task
>can be done, but does not purport to be "complete" and implementors on
>other window systems are likely to add system-specific features.  I am
>always interested in talking to people doing graphics access for Icon.

I just want to add to this that, if anyone is considering adding such
functionality to a specific platform, it might be nice to keep
close to the X-Icon specs.  One of the great virtues of Icon is its
portability.

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]         rutgers!oddjob!gide!sophist!goer

From icon-group-request  Fri Apr 17 09:23:58 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 09:23:58 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA28353; Fri, 17 Apr 92 09:23:51 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA27698; Fri, 17 Apr 92 09:17:19 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 15 Apr 92 20:55:38 GMT
From: adobe![e-mail]  (David Yost)
Organization: Adobe Systems Incorporated
Subject: Re: features from Icon Language in lisp
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>LISP, of course, isn't object-oriented

Heavens!  I guess you haven't hear of Common Lisp Object System, which is
IMHO considerably more advanced than the usual other suspects.  Anyone
interested in OO programming in any language should read Object Oriented
Programmin in Lisp by Sonya Keene.  CLOS is a standard part of Common Lisp
now.

 --dave yost

From [e-mail]  Fri Apr 17 11:37:21 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 11:37:21 MST
Received: from ALPHA.SUNQUEST.COM by optima.cs.arizona.edu (4.1/15)
    id AA03779; Fri, 17 Apr 92 11:37:12 MST
Received: from sunquest.sunquest.com by ALPHA.SUNQUEST.COM with SMTP;
          Fri, 17 Apr 1992 11:37:00 -0700 (MST)
Received: from shepard.sunquest.com by sunquest.sunquest.com (4.1/SMI-4.1)
    id AA22970; Fri, 17 Apr 92 11:35:48 MST
Received: by shepard.sunquest.com (4.1/SMI-4.1)
    id AA10232; Fri, 17 Apr 92 11:36:33 MST
Date: Fri, 17 Apr 92 11:36:33 MST
From: [e-mail] (Bill Mitchell)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Icon bloated?


    Richard L. Goerwitz wrote:

    ...

    Personally, I feel good about Common LISP.  It's even more bloated than
    Icon, though, and people who are really into clean LISP dialects seem
    to prefer Scheme.  ...

I just can't let this comment pass.  "[Common Lisp is] even more bloated
than Icon" implies that Icon is bloated.  The reference manual in the 2e of
the Icon book is a slim forty pages.  Icon is certainly not a small language
and I've heard Ralph say it's big, but "bloated" goes too far.  I think just
the opposite -- Icon has very good ratio of expressability to size of
language specification.

From icon-group-request  Fri Apr 17 12:45:40 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 12:45:40 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA06472; Fri, 17 Apr 92 12:45:38 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA06009; Fri, 17 Apr 92 11:43:16 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 7 Apr 92 21:21:44 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!ispd-newsserver!psinntp!xilinx![e-mail]  (Victor A. Holen )
Organization: Xilinx Inc.
Subject: lang comparison (not war)
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Is there somewhere (book, ftp, ...) a reasonably objective
comparison of icon with eiffel with a few other (perhaps c++,
smalltalk, mainsail..). Comparison of features, robustness (
maturity of compilers), clarity in use, availability, standard-status (!),
development environment (debuger +...), performance, suitability for
large CAD (and  other) projects ..   ?
Just the basics :)  ?
Thanks.

--
 victor ....  ___  ._..  .  _.     [e-mail]

From icon-group-request  Fri Apr 17 15:17:48 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 15:17:48 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA11991; Fri, 17 Apr 92 15:17:44 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA14507; Fri, 17 Apr 92 14:15:01 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 9 Apr 92 12:50:13 GMT
From: mailer.cc.fsu.edu!sun13!sun8.scri.fsu.edu![e-mail]  (John Nall)
Organization: SCRI, Florida State University
Subject: Re: should I use ICON for a specific problem ?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] writes:

   [ ... stuff deleted ... ]
>
>There's no reason to worry about flames here.  PERL is a system adminis-
>trator's tool par excellance, with a C interface that's actually much bet-
>ter than Icon's.  Icon is a much cleaner and more disciplined language,
>with a lot more options for control and data structures, coexpressions,
>and what not.  I find PERL a mess, but that's just me.  Probably I just
>don't know it well enough.

   It is so refreshing to see a well reasoned discussion of ICON vs PERL
   that I can't resist the temptation to say "WELL PUT!!"  I agree with
   everything that Richard said, completely, even to the part of "I find
   PERL a mess, but that's just me".  But it is certainly a gawdawful
   powerful tool in the hands of those who can deal with it :-)

John


--
John W. Nall              | Supercomputer Computations Research Institute
[e-mail]  | Florida State University, Tallahassee, FL 32306

 "Disclaimer:  A world which requires disclaimers has too many lawyers."

From icon-group-request  Fri Apr 17 18:31:09 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 18:31:09 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA18601; Fri, 17 Apr 92 18:31:07 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA27572; Fri, 17 Apr 92 18:09:38 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 9 Apr 92 20:05:49 GMT
From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!convex![e-mail]  (Tom Christiansen)
Organization: CONVEX Realtime Development, Colorado Springs, CO
Subject: Re: should I use ICON for a specific problem ?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

From the keyboard of [e-mail]:
:
:There's no reason to worry about flames here.  PERL is a system adminis-
:trator's tool par excellance, with a C interface that's actually much bet-
:ter than Icon's.  Icon is a much cleaner and more disciplined language,
:with a lot more options for control and data structures, coexpressions,
:and what not.  I find PERL a mess, but that's just me.  Probably I just
:don't know it well enough.

Nope, you're right -- in more ways than I care to enumerate, it *is* a
mess.  The amazing thing is how well it gets the job done anyway.

--tom

From icon-group-request  Fri Apr 17 18:33:45 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 18:33:45 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA18792; Fri, 17 Apr 92 18:33:41 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA27458; Fri, 17 Apr 92 18:08:07 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 9 Apr 92 20:02:08 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!convex![e-mail]  (Tom Christiansen)
Organization: CONVEX Realtime Development, Colorado Springs, CO
Subject: Re: should I use ICON for a specific problem ?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

From the keyboard of [e-mail] (Erik E. Rantapaa):

At the risk of raising Richard's ire, I'm going to clarify
a couple of Erik's points.

:>>2. multidimension arrays should be available   (nawk-synax:  array[1,2])
:
:--- Perl loses here.  Only singly dimensioned arrays are supported, but
:multi-dimensional arrays can be simulated, e.g. array["1,2"].

Not precisely correct: simulated multi-dimensional arrays via index
concatenation are directly supported syntactically you can say $array{$x}
or $array{$x, $y} or $array{$x, $y, $z}, etc.

:>>5. same loops as for, do and while in C should be available (not the
:>>   same syntax is needed ...)
:
:+++ Perl has loops with equivalents for 'continue' and 'break'.

Furthermore, since loops can be labeled, you can name which loop
you want to break or continue, something you can't do in C.  There's
also a third form of loop control, redo, which is like continue
without doing the 3rd for of the for loop (the re-init portion).
Furthermore, there's a "foreach elt (list)" looping construct as well.

:>>6. total computer-readable documentation is needed (I don't want to buy a
:>>   book of a thing, that maybe don't do it ...)
:
:+++ Perl comes with lots of free documentation -- in texinfo format.

You can also use the online man page, which is nearly booklength.
Also, the book examples are available on-line, as is all of
comp.lang.perl from all time, as well as various database and
retrieval methods for perusing it.

:Perl has its roots in the Unix utilities sed, ed, grep, sh and, yes, awk.
:(Yes, yes is a Unix utility; no, it's not related to Perl :) My knowledge
:of genealogical terminalogy is not that great, so maybe someone else can
:fill in what relationship Perl, awk and Icon have with each other.

The current list of tools from which perl derives something of its
eclectic nature includes but is not limited to the Bourne shell, csh,
awk, sed, tr, cpp, C (classic and ANSI), BASIC-PLUS, Pascal, Ada, Lisp,
APL, Fortran, Algol, egrep, nroff, /bin/test, vi, and emacs.  Seriously.

:Perl arrays function for the most part just like awk's.

Well, Perl has two kinds of things you might call arrays, but are perhaps
better characterized as lists and tables.  Lists one uses numeric indices
on as well as push and pop kinds of operations, whereas tables are generic
hash tables employing arbitrary indices.  Both data structures dynamically
resize internally to avoid performance degradations.  Tables can also be
bound directly to dbm files for rapid-access persistent data.

:In general, Icon has better support for data structures than Perl does.
:It's not real easy to implement 'recursive' data structures in Perl, although
:it can be done (although usually a way is found to get around it.)

True enough.  The major hurdle is lack of syntactic sugar.  You can
make a table of pointers to lists of pointers to lists of pointers
to tables, but the dereferencing requires a temporary variable for
each dereference.

:Icon wins with the arbitrarily large integers.

Perl has arbitrarily large integers, rationals, and floats
available via the libbig (bigfloat, bigint, bigrat) library package,
with normal arithmetic operations on them supported via library
routines.  Of course, these haven't a change of being as fast
as binary machine floats, since they're stored as strings.

:>Question #4:  Does Icon have subroutines?  If by this you mean that you can
:>define your own procedures, then yes.  If you mean, "does it let you use
:>labels," then the answer is "no."
:
:Perl has labels like C does.  Icon has more powerful subroutines, however.
:They are, in fact, more like co-routines, something I wish Perl had.

Well, perl labels are a little neater than C's because of the way you can
use them to label loops and as operands for loop-control statements, as
previously explained.

Subroutines in perl can also be called indirectly; recursion is
supported; they can be autoloaded; they can live in protected
namespaces (somewhat like file statics in C); they can for
good or evil be overridden via dynamic scoping.

--tom

From icon-group-request  Sat Apr 18 02:47:17 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 18 Apr 92 02:47:17 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA04963; Sat, 18 Apr 92 02:47:13 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA01534; Sat, 18 Apr 92 02:40:35 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 10 Apr 92 03:05:33 GMT
From: att!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: upto() with backslash escaping
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]


Anybody else need one of these?
-Richard

############################################################################
#
#    Name:     slashupto.icn
#
#    Title:     slashupto (upto with backslash escaping)
#
#    Author:     Richard L. Goerwitz
#
#    Version: 1.1
#
############################################################################
#
#  Slashupto works just like upto, except that it ignores backslash
#  escaped characters.  I can't even begin to express how often I've
#  run into problems applying Icon's string scanning facilities to
#  to input that uses backslash escaping.  Normally, I tokenize first,
#  and then work with lists.  With slashupto() I can now postpone or
#  even eliminate the traditional tokenizing step, and let Icon's
#  string scanning facilities to more of the work.
#
#  If you're confused:
#
#  Typically UNIX utilities (and probably others) use backslashes to
#  "escape" (i.e. remove the special meaning of) metacharacters.  For
#  instance, UNIX shells normally accept "*" as a shorthand for "any
#  series of zero or more characters.  You can make the "*" a literal
#  "*," with no special meaning, by prepending a backslash.  The rou-
#  tine slashupto() understands these backslashing conventions.  You
#  can use it to find the "*" and other special characters because it
#  will ignore "escaped" characters.
#
############################################################################
#
#  Links: none
#
#  See also: slashbal.icn
#
############################################################################

#
# slashupto:  cset x string x integer x integer -> integers
#             (c, s, i, j) -> Is (a generator)
#    where Is are the integer positions in s[i:j] before characters
#    in c that is not preceded by a backslash escape
#
procedure slashupto(c, s, i, j)

    if /s := &subject
    then /i := &pos
    else /i := 1
    /j := *s + 1

    /c := &cset
    c ++:= '\\'
    s[1:j] ? {
        tab(i)
        while tab(upto(c)) do {
            if (="\\", move(1)) then next
            suspend .&pos
            move(1)
        }
    }

end

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]           rutgers!oddjob!ellis!goer

From icon-group-request  Sun Apr 19 05:33:58 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 05:33:58 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA14073; Sun, 19 Apr 92 05:33:55 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA19963; Sun, 19 Apr 92 05:32:40 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 10 Apr 92 17:39:51 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!wupost!csus.edu!netcomsv!mork![e-mail]  (John Nagle)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Subject: Re: lang comparison (not war)
Message-Id: <0#[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

[e-mail] (Victor A. Holen ) writes:

>Is there somewhere (book, ftp, ...) a reasonably objective
>comparison of icon with eiffel with a few other (perhaps c++,
>smalltalk, mainsail..).

       I haven't heard much about Icon in years.  It was intended as
a replacement for Snobol, and perhaps as an alternative to the horrible
"string languages" ("awk", "sed") that come with UNIX.  Icon offers
Snobol-like matching with C-like syntax.  It's intended for a
different class of applications than is Eiffel.

                    John Nagle

From icon-group-request  Sun Apr 19 06:49:40 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 06:49:40 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA16210; Sun, 19 Apr 92 06:49:38 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA22845; Sun, 19 Apr 92 06:44:54 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 10 Apr 92 18:32:35 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!nic!netlabs![e-mail]  (Larry Wall)
Organization: NetLabs, Inc.
Subject: Re: should I use ICON for a specific problem ?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] (Tom Christiansen) writes:
: From the keyboard of [e-mail]:
: :
: :There's no reason to worry about flames here.  PERL is a system adminis-
: :trator's tool par excellance, with a C interface that's actually much bet-
: :ter than Icon's.  Icon is a much cleaner and more disciplined language,
: :with a lot more options for control and data structures, coexpressions,
: :and what not.  I find PERL a mess, but that's just me.  Probably I just
: :don't know it well enough.
:
: Nope, you're right -- in more ways than I care to enumerate, it *is* a
: mess.  The amazing thing is how well it gets the job done anyway.

Perl was intended to be a mess from the start, so it's a very, um,
systematic mess...  :-)

Larry

From icon-group-request  Sun Apr 19 09:33:55 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 09:33:55 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA19416; Sun, 19 Apr 92 09:33:53 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA01725; Sun, 19 Apr 92 09:20:34 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 18 Apr 92 17:37:43 GMT
From: sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!uicvm.uic.edu![e-mail]
Organization: University of Illinois at Chicago
Subject: wanted:ftp sites for icon
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

helo folks, i used snobol for a while and seems its time for the
next one. can anyone tell me where can i ftp

icon( for pc's and unix)?
thanx in advance

[e-mail]
[e-mail]

From icon-group-request  Sun Apr 19 13:06:21 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 13:06:21 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA25497; Sun, 19 Apr 92 13:06:18 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA12880; Sun, 19 Apr 92 12:56:55 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 19 Apr 92 01:02:53 GMT
From: dog.ee.lbl.gov!network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast![e-mail]  (Brandon S. Allbery KF8NH)
Organization: North Coast Public Access *NIX, Cleveland, OH
Subject: Re: Icon bloated?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

As quoted from <[e-mail]> by [e-mail] (Bill Mitchell):
+---------------
|
|     Richard L. Goerwitz wrote:
|
|     Personally, I feel good about Common LISP.  It's even more bloated than
|     Icon, though, and people who are really into clean LISP dialects seem
|     to prefer Scheme.  ...
|
| I just can't let this comment pass.  "[Common Lisp is] even more bloated
| than Icon" implies that Icon is bloated.  The reference manual in the 2e of
| the Icon book is a slim forty pages.  Icon is certainly not a small language
| and I've heard Ralph say it's big, but "bloated" goes too far.  I think just
| the opposite -- Icon has very good ratio of expressability to size of
| language specification.
+---------------

Very much agreed.  In fact, I've currently encountered only *one* thing that
might make a worthwhile extension to Icon; and it looks like a logical
extension of existing features, so it's not exactly out of place.  I
encountered an application where I wanted to use something like Icon's pattern
matching on what amounted to token streams.  The generalized form is "pattern
matching" on types other than strings; I've implemented it (well, sort of) as
a library loosely modeled on Icon's string pattern matching and using
coroutines.  But I think it also needs a lot more though before it can be
considered for inclusion into Icon.  (The problem with the library is it's
still rather type-dependent.)

Other than that one possible future extension (again, ONLY when it's ready,
which it very much isn't in at least my current visualization) it seems to me
that Icon is quite expressive for all its essential simplicity.  It's amazing
(at least to those of us accustomed to "conventional" programming languages)
how much cruft can be avoided by the use of Iconisms such as goal-directed
evaluation, etc.

++Brandon
--
Brandon S. Allbery, KF8NH [44.70.4.88]        [e-mail]
Senior Programmer, Telotech, Inc. (if I may call myself that...)

From [e-mail]  Sun Apr 19 13:43:03 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 13:43:03 MST
Received: from ucsd.edu by optima.cs.arizona.edu (4.1/15)
    id AA26642; Sun, 19 Apr 92 13:43:00 MST
Received: from odin.ucsd.edu by ucsd.edu; id AA04163
    sendmail 5.64/UCSD-2.2-sun via SMTP
    Sun, 19 Apr 92 13:42:44 -0700 for [e-mail]
Received: from gremlin.ucsd.edu by odin.ucsd.edu (4.1/UCSDPSEUDO.4)
    id AA29599 for dog.ee.lbl.gov!network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast![e-mail]; Sun, 19 Apr 92 13:42:43 PDT
Received: by gremlin.ucsd.edu (4.1/UCSDPSEUDO.4)
    id AA24368 for [e-mail]; Sun, 19 Apr 92 13:42:42 PDT
Date: Sun, 19 Apr 92 13:42:42 PDT
From: [e-mail] (William Griswold)
Message-Id: <[e-mail]>
To: dog.ee.lbl.gov!network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast![e-mail],
        [e-mail]
Subject: Re: Icon bloated?

Icon is tiny compared to Common Lisp (CL).  The recent 2nd edition manual
for CL is some 1000 pages, in smaller print than the Icon book.  Fortunately
for programmers, Icon and CL subset nicely, allowing a gentle introduction
to each.  However, there is still the problem that it is often faster to
code a function yourself than to find the Icon/CL function that does the
equivalent thing.

Another problem with language bloating is implementing programming tools
for a language.  Although a programmer can learn one feature at a time,
few tools will work at all unless they support the whole language.  I would
guess that much of Ralph's objection to the size of Icon is due to the cost
of maintaining the Icon Project's language systems, not the learning curve.

As software engineers push for ever-higher programmer productivity, they
are increasingly looking at tool solutions to programming problems, rather
than languages.  However, language size is a considerable barrier when
moving from research into practice.  For example, I have a program
restructuring tool for a subset of the LISP dialect Scheme.  To move this
system to CL is such a monumental task that I cannot consider it in a
research environment.  For the same reason DARPA/DoD is looking for Ada
subsets that researchers can use for their tools research.  No sane
researcher would ever build a tool for a complete language as complex as Ada.

                    Bill Griswold
                    UC San Diego

From icon-group-request  Sun Apr 19 19:35:17 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 19:35:17 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA06041; Sun, 19 Apr 92 19:35:14 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA05043; Sun, 19 Apr 92 19:26:55 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 13 Apr 92 18:33:36 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!sun1.ruf.uni-freiburg.de!news.belwue.de!news.uni-stuttgart.de!helpdesk.rus.uni-stuttgart.de![e-mail]  (MUFTI)
Organization: User Helpdesk Comp. Cent. (RUS) U of Stuttgart, FRG
Subject: Why I can't use perl
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Dear Sirs,

Unfortunatly I started a icon vs. perl language war with my question if
I should use icon for my awk-script.

I thougth about using perl, before I thougth about icon, but perl seams to be
too slow:

 1. Cause perl don't support "dump" on my system, the program needs with
    perl the same big amount of time to startup, as with nawk/gawk. In this
    point wins the semicompiling concect of icon.

 2. So I know perl doesn't support integer. Cause my machine has no
    Floating Point Unit, a perl program is slower than a "tuned" gawk-version
    where
    #define AWKTYPE long    (instead of double)

thanks to all for help

yours
MUFTI

ps: the a2p -program doesn't work for my program, cause it don't know some-
    thing about the "do { } while()" -loop, which is a nawk-special feature

From icon-group-request  Sun Apr 19 20:22:03 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 20:22:03 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA07247; Sun, 19 Apr 92 20:22:01 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA07843; Sun, 19 Apr 92 20:17:45 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 19 Apr 92 21:22:01 GMT
From: [e-mail]  (David Shackelford)
Organization: U of Arizona CS Dept, Tucson
Subject: Re: wanted:ftp sites for icon
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>helo folks, i used snobol for a while and seems its time for the
>next one. can anyone tell me where can i ftp

Icon is available by anonymous FTP from the University of Arizona
at cs.arizona.edu.  Versions are available for many op. systems including
UNIX, VMS, DOS, and OS/2.

From [e-mail]  Tue Apr 21 05:55:54 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 21 Apr 92 05:55:54 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA27238; Tue, 21 Apr 92 05:55:45 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA05307; Tue, 21 Apr 92 14:57:00 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA06445; Tue, 21 Apr 92 14:54:49 +0200
Date: Tue, 21 Apr 92 14:54:49 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: icon/awk

Since I received many reactions concerning my "icon/awk" library, I will
send it to the group-adress (see below).

However, I think it is appropriate to add a disclaimer: like I said
in my previous mail on the subject, the /pattern/ { action } form is not
emulated, for obvious reasons. ICON itself is (in my opinion) better
equipped to handle pattern scanning, and I wouldn't like to spend long
nights hacking away to emulate grep-type regular expressions, when ICON
already has equivalent facilities. Besides, the lib would then become
even slower than it is already. However, for some AWK users, exactly
this feature (grep-type expressions) is their reason for using AWK.

What I like about AWK is the possibility of adressing the columns in a stream,
given a certain set of separator characters. It is that aspect that I wanted to
use in ICON, and it is that functionality that I've tried to implement in a LIB.

If anyone of you improves upon the library, I'd appreciate hearing about it.

[e-mail] has suggested that the $ symbol *could* be used instead of
"FLD" for field identifyers. I do not know, however, how this can be done.
Has any of the ICON guru's a suggestion?

The lib:

#   AWK emulation library.
#
#   USAGE:
#
#   compile AWEKA.ICN with the -c option.
#   At the top of your program declare:
#
#       link aweka
#
#   You can now open a stream (say, "instream") and pass this as
#   an argument to the procedure awk(). If the stream is at EOF,
#   the function awk() fails, so the following form is useful:
#
#       while awk(instream) do {
#           ...
#       }
#
#   Every time awk(stream) is called, it reads a line from stream, and
#   sets the global variables FLD, NR, and NF. awk() returns the whole line
#   that was read from the stream (cf. $0 in AWK).
#
#   FLD is a list, where FLD[n] corresponds to the nth column in the input
#   line, separated by characters from FS. Note that you can therefore use
#   FLD as a generator, or with the pop() function, or what have you.
#
#   NR is the number of records read from the input stream.
#   NF is the number of fields read.
#
#   The global var FS is a cset, specifying the whitespace characters. If you
#   do not set FS, awk() uses the space and tab character as default. If you
#   want another set of separator-chars, you can set FS to the desired
#   cset before calling awk(). It is also possible to change FS
#   between successive calls to awk() with the same stream. (see example)
#
#   If you call awk() with another stream argument than the one you used in
#   the previous call to awk(), it resets the value of NR to 0.
#
#   The caller (your icon program) is responsible for opening and closing
#   the streams.
#
#
#   An example program to print out all words in an ascii text on a separate
#   line. It changes the value of FS from ' ;' to ' ,.;:?!' if the string
#   "TEXT" is processed, and it sets the value of FS to ' ;' again if the
#   string "PROGRAM" is encountered. It then opens a new file, and does the
#   same thing with the default character set, without changing FS. It shows
#   some of nice awk*icon mixtures that can be used.
#
#   # example and test program for AWEKA lib
#   link aweka
#   procedure main()
#       instream := open("awktest.dat")
#       FS := ' ;'
#
#       while(awk(instream)) do {
#           every(i := 1 to NF) do {
#               case FLD[i] of {
#                "TEXT"    : FS := ' ,.;:?!'
#                "PROGRAM" : FS := ' ;'
#               }
#               write(FLD[i])
#           }
#       }
#
#       secondstream := open("awktest2.dat")
#       FS := &null   # in order to restore the default charset
#       while awk(secondstream) do every(write(!FLD))
#
#       close(instream)
#       close(secondstream)
#   end
#
#
#
global NF, NR, FLD, FS
procedure awk(file)
    static oldfile
    initial { oldfile := &null }

    if (oldfile ~=== file) then {
        NR := 0
        oldfile := file
    }

    if (/FS) then FS := ' \t'
    charset := &cset -- cset(FS)
    NF := 0
    FLD := list()

    if(LSTR := !file) then NR +:= 1 else fail
    LSTR ? while(tab(upto(charset))) do put(FLD,tab(many(charset)))
    NF := *FLD
    suspend LSTR
end

From [e-mail]  Tue Apr 21 10:52:09 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 21 Apr 92 10:52:09 MST
Received: from Arizona.edu (Osprey.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15)
    id AA09366; Tue, 21 Apr 92 10:51:30 MST
Received: from RMC.CA (MAILER@RMC) by Arizona.edu (PMDF #12663) id
 <[e-mail]>; Tue, 21 Apr 1992 10:51 MST
Received: by RMC (Mailer) id 45140317390; Tue, 21 Apr 92 13:47:10 EST
Date: Tue, 21 Apr 92 13:22:16 EST
From: [e-mail]
Subject: References please ....
To: [e-mail]
Reply-To: [e-mail]
Message-Id: <[e-mail]6>
X-Envelope-To: [e-mail]

        One would not expect the current PERL-AWK-NAWK-&c controversy on THIS
board.  However, since it's there, would someone please post a list of
references to PERL, AWK, NAWK, &c., preferrably including any sort of definitive
documents or standards documents and some introductory material.  The "perl"
that I have references to is plainly not the PERL being discussed here, and my
AWK material must be very out of date.  It would be a good place to list any
sort of comparative document too.

                                        Thanks.

--------------------------------------------------------------------------------

            John H. Lindsay,
            Department of Mathematics and Computer Science,
            Royal Military College of Canada,
            Kingston, Ontario, Canada, K7K 5L0.

            Phones: Office,                          [phone]
                    Messages,                              541-6343 or 541-6458
                    Home,                                  546-6988
            E-Mail: From Bitnet, NetNorth, ONet:     [e-mail]
                    From Canadian Military Colleges: LINDSAY JH@RMC
            Fax:                                     [phone]

From [e-mail]  Tue Apr 21 13:24:56 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 21 Apr 92 13:24:56 MST
Received: from Arizona.edu (Merlin.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15)
    id AA17503; Tue, 21 Apr 92 13:24:46 MST
Received: from RMC.CA (MAILER@RMC) by Arizona.edu (PMDF #12663) id
 <[e-mail]>; Tue, 21 Apr 1992 13:24 MST
Received: by RMC (Mailer) id 45141254084; Tue, 21 Apr 92 16:23:12 EST
Date: Tue, 21 Apr 92 16:22:17 EST
From: [e-mail]
Subject: Algol 60 Call-by-Name & SNOBOL4 & ICON .... ?
To: [e-mail]
Reply-To: [e-mail]
Message-Id: <[e-mail]6>
X-Envelope-To: [e-mail]

        The ideas of passing a SNOBOL4 (delayed) expression or an ICON
co-expression as an argument to a procedure present the thought that these are
"almost" like the Algol 60 Call-by-Name facility, painfully so if one wants to
use a facility of that sort, but can't because these are not quite like it, and
enragingly so if one finds such a facility too mind-boggling to be a part of a
readable reliable program.

        For the Johnny-and-Suzie-come-latelies, in Algol 60 and some related
languages, an actual parameter (= argument) of a procedure call which does not
correspond to a formal VALUE parameter is reevaluated every time it's referenced
in the called procedure, but in the context of the block containing the call.
This means that even as simple an argument as an array element can change its
meaning or value from reference to reference in the called routine because the
subscripting is redone, and reflects any changes in the value of the subscript.
The situation shows up well in Algol W (an "Algol 67" -- a step looking forward
to Algol 68, and done by Nick Wirth, associates and students at Stanford); that
Algol also allowed <statement>s to be actual parameters, but the corresponding
formal parameters were then declared as parameterless procedures, and one might
infer that other types of formal parameters corresponding to a <Type> expression
as an actual parameter were thought of, if not declared, in that way.

        The notable "deficiencies" (useful roadblocks ?) that inhibit or prevent
the use of delayed expressions and co-expressions in SNOBOL4 and ICON as actual
Call-by-Name parameters, as I see it, are:
    The inability of a SNOBOL4 expression to NRETURN like a function so that
        such a parameter can't be used as the target of an assignment without
        doing an indirect,
    The semantics of the SNOBOL4 save-and-replace formal parameter handling
        mechanism for function calls which may inhibit anything like evaluation
        in a context,
    The one-level procedure nesting of ICON and the semantics of co-expression
        creation which limit useful contexts to global variables and COPIES of
        contexts of procedures (without the possibility of sharing local
        procedure variables between the copies), and
    The lack of an indirect reference mechanism in ICON.

        I'd like to swap notes with anyone who has tried anything like this sort
of thing:  Could you use it?  What roadblocks did you find?  Could you get
around them?  How painfully?  Would you try it again?

--------------------------------------------------------------------------------

            John H. Lindsay,
            Department of Mathematics and Computer Science,
            Royal Military College of Canada,
            Kingston, Ontario, Canada, K7K 5L0.

            Phones: Office,                          [phone]
                    Messages,                              541-6343 or 541-6458
                    Home,                                  546-6988
            E-Mail: From Bitnet, NetNorth, ONet:     [e-mail]
                    From Canadian Military Colleges: LINDSAY JH@RMC
            Fax:                                     [phone]

From [e-mail]  Wed Apr 22 09:12:38 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 22 Apr 92 09:12:38 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA04244; Wed, 22 Apr 92 09:12:33 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA05231; Wed, 22 Apr 92 17:21:18 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA08390; Wed, 22 Apr 92 17:19:01 +0200
Date: Wed, 22 Apr 92 17:19:01 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: ICON/AWK disclaimer

I keep getting email from people asking if I can send my ICON/AWK lib
to them, and if there are any charges involved. I think that there must
be some misunderstanding, for I have *already* sent the lib to the ICON
group, and charges are of course out of the question. Perhaps I've used
too big a word for it ("library") for which I hereby apologise.

Perhaps it would be a good idea to spell things out quite clearly:

The lib i've written is a modest 20 line ICON procedure (and some
global variables) that enables one to do AWKish processing (using $,
NF, NR and FS) on a specified stream. I've already sent the lib to
the icon-group, but anyone who's accidentally deleted it and is still
interested can mail me to ask for a (free) copy.

I use this library extensively (being an ex awk-user), and consider it
quite handy. That's why I wanted to mention it in the ICON group.

Charges are (of course) out of the question for an almost
trivial procedure like the one I've written. Maybe some of you would
have liked a "real" icon-to-awk interface, but alas, that's not what
I meant.  For me it is enough to have the $n-style functionality of
AWK in an otherwise ICONic environment.

Jan Peter de Ruiter
Max Planck Institute for Psycholinguistics
Nijmegen
The Netherlands
EMAIL: [e-mail]

From [e-mail]  Thu Apr 23 05:33:15 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 05:33:15 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA01033; Thu, 23 Apr 92 05:33:10 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA22294; Thu, 23 Apr 92 14:34:23 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA09955; Thu, 23 Apr 92 14:32:15 +0200
Date: Thu, 23 Apr 92 14:32:15 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: $ as identifyer

In ICON one can use only identifyers that consist of underscores, digits,
and letters. Why is this? The '$' character is not an ICON operator
(to my surprise, I must add), and it would be nice to be able to use
all non-operator ascii-characters.

Another point is that someone has recently suggested to me that is would
be possible to circumvent this problem; unfortunately he only thought
*that* it was possible, but didn't know to do it.

Any tips, hints, or comments?

Jan Peter de Ruiter
Max Planck Institute for Psycholinguistics, Nijmegen, Netherlands
EMAIL: [e-mail]

From ralph  Thu Apr 23 05:41:11 1992
Date: Thu, 23 Apr 92 05:41:11 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 05:41:11 MST
To: [e-mail], [e-mail]
Subject: Re:  $ as identifyer

The character $ is not an operator in Icon, but it is used in digraphs
for alternative representations for a few characters that are not
available on some EBCDIC terminals.  For example, $< and [ are
equivalent in Icon.  (See page 293 of the second edition of the Icon
language book.)

    Ralph Griswold / Department of Computer Science
    The University of Arizona / Tucson, AZ 85721

    [e-mail] / uunet!arizona!ralph

    voice: 602-621-6609 / fax: [phone]

From [e-mail]  Thu Apr 23 08:49:42 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 08:49:42 MST
Received: from ixgate.gmd.de by optima.cs.arizona.edu (4.1/15)
    id AA07163; Thu, 23 Apr 92 08:49:38 MST
Received: by ixgate.gmd.de id AA19527; Thu, 23 Apr 92 17:49:50 +0200
Date: 23 Apr 92 15:45
From: "(Michael Sperber)" <[e-mail]>
Message-Id: <RFC-822:>
Subject: $ in identifiers
Apparently-To: [e-mail]

RFC-822-HEADERS:
Return-Path: <@CDC2.RRZN.UNI-HANNOVER.DE:[e-mail]>
To: @CDC2:[e-mail]

==================
It's even nicer to have an at least on character left over
for potential language extensions.  One of those is Idol from
the IPL.

:-> Chipsy

From [e-mail]  Thu Apr 23 12:48:16 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 12:48:16 MST
Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15)
    id AA18730; Thu, 23 Apr 92 12:48:11 MST
Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12865) id
 <[e-mail]>; Thu, 23 Apr 1992 14:48 CST
Date: Thu, 23 Apr 1992 14:48 CST
From: Chris Tenaglia - 257-8765 <[e-mail]>
Subject: Re: $ as identifyer
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Organization: Medical College of Wisconsin (Milwaukee, WI)
X-Vms-To: IN%"[e-mail]"
X-Vms-Cc: in%"[e-mail]"


> In ICON one can use only identifyers that consist of underscores, digits,
> and letters. Why is this? The '$' character is not an ICON operator
> (to my surprise, I must add), and it would be nice to be able to use
> all non-operator ascii-characters.

> Another point is that someone has recently suggested to me that is would
> be possible to circumvent this problem; unfortunately he only thought
> *that* it was possible, but didn't know to do it.

> Any tips, hints, or comments?

> Jan Peter de Ruiter
> Max Planck Institute for Psycholinguistics, Nijmegen, Netherlands
> EMAIL: [e-mail]

I also noticed that lonely $ character. I started a flame war sometime
back suggesting it be used as a user defined operator and I proposed a
syntax for defining it.

operator {
         &operand[1] : bits
         &operand[2] : test_bits
         &operand[3] : etc,...
         }

  val := 192                           |  procedure bits(n)
  mask:= 160                           |    binary := radcon(n,10,2)
  tmp := $ val                         |    count  := 0
  write(tmp)         2                 |    every bit := !binary do
  tmp := mask $ val                    |      count +:= 1
  write(tmp)         "partial match"   |    return count
                                       |    end
                                       etc,...

The argument for this is that certain kinds of operations can be made
clearer to understand using this notation rather than procedural. It
can be argued that the procedural notation is sufficiently powerful
to handle currently known contingencies. I thought about defining
compound operators like $+ which would be a conceptual analog to an
addition operation.

However the whole thing seemed to be shot down from the OOPs camp
since apparently IDOL uses the character. I also think IBM mainframe
ICON uses $( and $) for curly braces, and quoting other non-ibm
characters. The thought was fun to toy with for a while.

Chris Tenaglia (System Manager) |  "The past explained,
Medical College of Wisconsin    |   the future fortold,
8701 W. Watertown Plank Rd.     |   the present largely appologized for."
Milwaukee, WI 53226             |   Organon to The Doctor
[phone]                   |
[e-mail]


From [e-mail]  Thu Apr 23 15:00:15 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 15:00:15 MST
Received: from amway.ch.apollo.hp.com by optima.cs.arizona.edu (4.1/15)
    id AA24886; Thu, 23 Apr 92 15:00:06 MST
Received: from xuucp.ch.apollo.hp.com by amway.ch.apollo.hp.com id <[e-mail]> Thu, 23 Apr 92 17:57:57 EDT
Received: by xuucp.ch.apollo.hp.com id <[e-mail]>; Thu, 23 Apr 92 17:45:37 EDT
Message-Id: <[e-mail]>
Received: by daphne.ch.apollo.hp.com  id AA04182; Thu, 23 Apr 92 17:50:48 EDT
From: [e-mail]
Date: Thu, 23 Apr 92 17:16:10 EDT
Subject: How tu use $ as identifyer
To: [e-mail]
Cc: [e-mail]

Folks:

  I suppose I started this by mentioning this to Jan...

  SO, here is how I did it.

  I added the define:

#define DollarIdent                     /* allow $ character as an identifier */

  to define.h

  And then I made the following changes to tlex.c (see below)

  I had no problems with this change. I used it for procedure names
  of the form name1_$name2. (I did this because I wanted to make
  system call visible to the icon program through the external interface,
  and the system call had the form name1_$nane2)

  Since I didn't use digraphs, I don't know if it affects their use.
  Since there is a define to control it, the change can be made invisable
  to those that don't want it.

  You can add this to standard ICON if you want to Ralph.

-Mark


The following comprares were off a august 1990 snapshot of version 8
It should not differ much from the present version 8   (I think...)

The Apollo compare (cmf) shows the change in context

$ cmf /keil/icon/v8.x6/src/icont/tlex.c.orig /keil/icon/v8.x6/src/icont/tlex.c

A254         if (isalpha(c) || (c == '_')) {   /* gather ident or reserved word */
changed to
B254      #ifdef DollarIdent
B255         if (isalpha(c) || (c == '_') || (c == '$')) {   /* gather ident or reserved word */
B256      #else
B257         if (isalpha(c) || (c == '_')) {   /* gather ident or reserved word */
B258      #endif                    /* VarTran */


A330            } while (isalnum(c) || (c == '_'));
changed to
B334      #ifdef DollarIdent
B335            } while (isalnum(c) || (c == '_') || (c == '$'));
B336      #else
B337            } while (isalnum(c) || (c == '_'));
B338      #endif



The diff version for those that like and grok diff ;-)

$ diff /keil/icon/v8.x6/src/icont/tlex.c.orig /keil/icon/v8.x6/src/icont/tlex.c
253a254,256
> #ifdef DollarIdent
>    if (isalpha(c) || (c == '_') || (c == '$')) {   /* gather ident or reserved word */
> #else
254a258
> #endif                    /* VarTran */
329a334,336
> #ifdef DollarIdent
>       } while (isalnum(c) || (c == '_') || (c == '$'));
> #else
330a338
> #endif



From cjeffery  Thu Apr 23 16:56:10 1992
Received: from chuckwalla.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 16:56:10 MST
Date: Thu, 23 Apr 92 16:56:08 MST
From: "Clinton Jeffery" <cjeffery>
Message-Id: <[e-mail]>
Received: by chuckwalla.cs.arizona.edu; Thu, 23 Apr 92 16:56:08 MST
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Chris Tenaglia - 257-8765's message of Thu, 23 Apr 1992 14:48 CST <[e-mail]>
Subject: $ as identifyer

Chris Tenaglia writes about his proposed $ for a user-defined operator:
    > However the whole thing seemed to be shot down from the OOPs camp
    > since apparently IDOL uses the character.

It is true that the first implementation of Idol uses the $ operator.
I don't think you can blame the OOP camp for shooting down your idea
though; you can use $ to do whatever you want, if you don't use Idol.

The two best ways to try out extensions to Icon that are too complex to
code in C, are (a) use a variant translator if your system supports it,
or (b) write an Icon program that translates your extended language
into Icon and then calls icont.  Idol proves that the latter approach
is viable, and can be very portable (it even runs on MS-DOS :-).

I should warn you, though, that language design is *very hard*, so don't
take it personally if people aren't interested in your extension.  You
might discover its the best thing since sliced bread, but if other
people can't immediately grasp its usefulness, it will get ignored.
And if its a good idea, but the design is not general enough, or the
syntax is clumsy, it will still get ignored.  And lastly, you may learn
how to do it right, if you do it wrong, and gain experience with it.
Good luck.

Clint Jeffery

From icon-group-request  Fri Apr 24 09:54:50 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Apr 92 09:54:50 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA09730; Fri, 24 Apr 92 09:54:48 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA08944; Fri, 24 Apr 92 09:48:47 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 Apr 92 16:20:06 GMT
From: wupost!dsuvax.dsu.edu![e-mail]  (Guy Helmer)
Organization: Dakota State University, Madison, SD
Subject: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]


      [ The following is a description of an offering of a course via
    electronic mail by Dakota State University's College of Liberal
    Arts.  Reply-To: is set to [e-mail], which
    is where queries regarding the course should be sent.

    Flames regarding this massive cross-post should be directed to
    [e-mail] :-) ]

     Following is information about a three-credit graduate course
in programming for the humanities offered by Dakota State
University via BITNET (and other interconnected networks).
Students in the course can be anywhere in the world if they can
send and receive electronic mail.

     CHUM 650, COMPUTER PROGRAMMING FOR THE HUMANITIES, is an
introduction to programming using SNOBOL4 for applications in the
humanities such as analysis of texts, arranging data from research,
and formatting for printing and desktop publishing.  The primary
emphasis in the course will be on computer applications with texts.

     The course is designed for humanists who want to learn to
write useful computer programs for research and teaching.  The
language of choice for this course is SNOBOL4 because it is a
powerful language designed for non-numeric computing; students can
write useful programs in SNOBOL4 almost from the start.  The course
will begin with an introduction to programming, then cover
techniques of structuring SNOBOL4 programs, and it will finish with
students completing individual projects of their own creation.

     Students in the course can work at their own pace; they can
begin immediately.  Students should plan to finish all course
requirements by August 1.

     Programming assignments for the course will be designed for
MS-DOS microcomputers.  Although most assignments can be modified
for Macintosh users, students using a Macintosh would have to
purchase MaxSPITBOL, and they would need an understanding of
Macintosh file structures.

     It is a prerequisite for the course that students have a sound
understanding of how to upload and download files from the
mainframe that runs electronic mail to the DOS microcomputer used
for the programming assignments.  In addition, students must be
familiar with DOS commands.

     The total cost of the course is $239.82.  No textbook is
required.  Students will be sent a disk containing a public-domain
SNOBOL4 compiler and a text editor.  Lectures and data files will
be sent electronically.

     Students may audit the course or enroll for credit and receive
a grade of Pass or Fail.  The cost to audit the course is the same
as enrolling for credit.

     Those who want an electronic registration form or who have
questions about the course should send a message to

             Eric Johnson
             [e-mail]
--
Guy Helmer, Dakota State University Computing Services - [e-mail]
"Often you fix the wrong thing first." - Karl Auerbach, Interop 91

From icon-group-request  Sat Apr 25 07:57:29 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Apr 92 07:57:29 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA00354; Sat, 25 Apr 92 07:57:27 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA28185; Sat, 25 Apr 92 07:41:27 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 25 Apr 92 05:53:27 GMT
From: cs.utexas.edu!qt.cs.utexas.edu!yale.edu!cs.yale.edu![e-mail]  (Scott Horne)
Organization: Computer "Science" Dept, Yale University
Subject: Re: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]>, [e-mail] (Allan Adler) writes:
<In article <[e-mail]> [e-mail] (Guy Helmer) writes:
<
<   Students will be sent a disk containing a public-domain
<   SNOBOL4 compiler and a text editor.

HA!  Why not send them vacuum tubes and copper wire?

<I think this counts as commercial advertising.  <...>

Yes.

<Aren't there rules about this sort of thing?

Yes, and it's specifically disallowed.  Complain to
`[e-mail]'.

                    --Scott

--
Scott Horne                               ...!{harvard,cmcl2,decvax}!yale!horne
[e-mail]      SnailMail:  Box 7196 Yale Station, New Haven, CT   06520
203 436-1848                Residence:  Rm 1848 Silliman College, New Haven, CT
Shao2shan1 sheng1-qi3 de tai4yang2 yong3 bu2 luo4!

From icon-group-request  Sat Apr 25 12:28:31 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Apr 92 12:28:31 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA06577; Sat, 25 Apr 92 12:28:27 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA17709; Sat, 25 Apr 92 12:14:17 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 25 Apr 92 18:58:54 GMT
From: [e-mail]  (Jonathan Rees)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Subject: Re: features from Icon Language in lisp
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]


In this discussion of Icon features in Lisp, I'm surprised that no one
has mentioned the obvious embedding of Icon-like control in Scheme.
(If someone did, I missed it.)


; For Icon's alternation operator a | b | c, write (either a b c).

(define-syntax either
  (syntax-rules ()
    ((either x) x)
    ((either x y ...)
     (%either (lambda () x) (lambda () (either y ...))))))

(define (%either thunk1 thunk2)        ;Macro axuiliary
  (let ((save *fail*))
    ((call-with-current-continuation
       (lambda (k)
     (set! *fail*
           (lambda ()
         (set! *fail* save)
         (k thunk2)))
     thunk1)))))

; (accumulate a) returns a list of all the possible values of the
; expression a.  Prolog calls this "bagof"; I forget what Icon calls it.

(define-syntax accumulate
  (syntax-rules ()
    ((accumulate x) (%accumulate (lambda () x)))))

(define (%accumulate thunk)
  (let ((results '()))
    (either (begin (set! results (cons (thunk) results))
           (fail))
        (reverse results))))


; Generate all the members of list l.  E.g.
;   (accumulate (+ (member-of '(10 20 30)) (member-of '(1 2 3))))
;     => '(11 12 13 21 22 23 31 32 33)

(define (member-of l)
  (if (null? l)
      (fail)
      (either (car l) (member-of (cdr l)))))


; Internal variable representing the failure stack.

(define (fail) (*fail*))

(define *fail* (lambda () (error "You didn't do (init).")))


; Crufty initialization hack that allows you to type failing
; expressions at the R-E-P loop (if there is an R-E-P loop).  E.g. try
; evaluating the sequence
;  (either 1 2)
;  (fail)
;  (+ (fail) 10)

(define (init)
  (call-with-current-continuation
    (lambda (k)
      (set! *fail* (lambda () (k 'failed)))
      'initialized)))

(display "Type (init) at the read-eval-print loop.")
(newline)


--
-- Jonathan Rees  [e-mail]
member, Cambridge Entomological Club / member, League for Programming Freedom

From icon-group-request  Sat Apr 25 19:30:16 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Apr 92 19:30:16 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA17509; Sat, 25 Apr 92 19:30:09 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA16070; Sat, 25 Apr 92 19:22:03 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 Apr 92 21:27:53 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!hri.com!noc.near.net!chaos!random.ccs.northeastern.edu![e-mail]  (mitchell wand)
Organization: College of Computer Science, Northeastern University
Subject: Re: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

I didn't think there were any living SNOBOL programmers left!

But seriously, I can't imagine doing

  applications in the
  humanities such as analysis of texts, arranging data from research,
  and formatting for printing and desktop publishing.

in SNOBOL, which is hardly an industrial-strength language with widespread
support!

If you want to teach humanists about programming, use Friedman and Felleisen's
{Little Lisper}, which converts everything to the kind of game even humanists
can understand (:-).

If you want to do quick-and-dirty text processing, you can either use Scheme
or awk or Icon (or even C!), all of which are widely supported.

If you want to do formatting and desktop publishing, you'd be far better off
using all the good tools that are available for that, rather than struggling
to do it in SNOBOL.

[OK, my flameproof suit is on now.]

--Mitch



--
Mitchell Wand
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115     Phone: [phone]
Internet: wand@{corwin|flora}.ccs.northeastern.edu   Fax: [phone]

From @um.cc.umich.edu:[e-mail]  Sun Apr 26 11:11:55 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 26 Apr 92 11:11:55 MST
Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15)
    id AA10847; Sun, 26 Apr 92 11:11:52 MST
Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0)
    id AA26427; Sun, 26 Apr 92 14:07:50 -0400
Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Sun, 26 Apr 92 14:09:23 EDT
Date: Sun, 26 Apr 92 14:08:36 EDT
From: [e-mail]
To: [e-mail]
Message-Id: <[e-mail]>
Subject: Icon versus Snobol for the humanities

I agree with Mitch Wand's statement that Icon is far superior to Snobol
for the kinds of stuff that people do in the humanities (or for nearly
anything else, for that matter).  (I wouldn't inflict Lisp on anyone
with no ambitions to be a professional programmer, however.)  But I think
Mitch overlooks one important consideration: if you're used to using
Language A, there's a considerable cost in switching to Language B even
if Language B is better.  If programming is not your main ambition in
life, you may be far better off sticking with the devil you know than
the one you don't.  The arguments for switching from Snobol to Icon are
much like the arguments for replacing your old clunker with a new car.
If the clunker gets you where you want to go and the repair bills aren't
too high, sticking with it is probably your most rational choice.
On the other hand, if you know you're going to have to switch eventually,
it's better to do it sooner than later.

Paul Abrahams
[e-mail]

From [e-mail]  Mon Apr 27 01:22:36 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 01:22:36 MST
Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15)
    id AA06758; Mon, 27 Apr 92 01:22:30 MST
Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET
     id AA29188; Mon, 27 Apr 92 10:23:26 +0200
Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET
     id AA04874; Mon, 27 Apr 92 10:22:58 +0200
Date: Mon, 27 Apr 92 10:22:58 +0200
From: Jan Peter de Ruiter <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: snoboldtimer

I do entirely agree with what Mitch wrote about Snobol, although there is
a certain "oldtimer" feeling connected to SNOBOL programming. Like people
driving around in old cars, just because they are old. Besides, SNOBOL is
to my knowledge the only computer language that combines the speed of
LISP with the elegance of assembly language.

Jan.

Jan Peter de Ruiter
Max Planck Institute for Psycholinguistics
The Netherlands
[e-mail]


From icon-group-request  Mon Apr 27 08:47:11 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 08:47:11 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA22083; Mon, 27 Apr 92 08:47:09 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA27876; Mon, 27 Apr 92 08:33:55 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 27 Apr 92 14:50:08 GMT
From: sdd.hp.com!wupost!dsuvax.dsu.edu![e-mail]  (Guy Helmer)
Organization: Dakota State University
Subject: Re: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In <[e-mail]> [e-mail] (Allan Adler) writes:

>In article <[e-mail]> [e-mail]
> (Guy Helmer) posted:

>>    Following is information about a three-credit graduate course
>>   in programming for the humanities offered by Dakota State
>>   University via BITNET (and other interconnected networks).
>>     [ details of the course deleted]
>>    The total cost of the course is $xxx.xx.  No textbook is
                                         ^^^^^^
Actual cost deleted to avoid affending even more readers. :-)

>>   required.  Students will be sent a disk containing a public-domain
>>   SNOBOL4 compiler and a text editor.  Lectures and data files will
>>   be sent electronically.

>I think this counts as commercial advertising. If someone wants to make the
>course materials available to people via anonymous ftp, that is one thing.
>If someone wants to organize a network of volunteers to help people in the
>humanities learn computers, that is still ok. But this is pure commerce.

OK, this may be considered "commercial" advertising by some, but I submit it
it not "pure commerce", because:

    1) This is an experimental program offering, where the experiment
    is to offer an unusual course worldwide to users of the net, who,
    without benefit of the Internet, would not be able to take advantage
    of the offering.

    2) In the spirit of the course (using Internet as the delivery
    medium), the best method to contact potential "virtual attendees"
    is Usenet.  A very large share of the Internet is funded this
    moment to promote communication between research and educational
    institutions, which is what this course is based on.

    3) Given tight budgets, lack of support, and funding of time,
    the academic community must develop "free courses" so that we
    may post announcements of innovative, experimental,
    one-of-a-kind opportunities to Usenet?

>Aren't there rules about this sort of thing?

:-)  Rules on Usenet?

Seriously, I will grant that perhaps it would have been "more proper"
and "less offending" to have posted summary information.  However, I
have a very hard time finding differences between my posting and the
postings you will find in news.announce.conferences, and I don't see
y'all flaming each post in n.a.c that lists course costs and materials
provided.

Followups to misc.misc, since this thread probably doesn't interest everyone.

>Allan Adler
>[e-mail]
--
Guy Helmer, Dakota State University Computing Services - [e-mail]
"Often you fix the wrong thing first." - Karl Auerbach, Interop 91

From icon-group-request  Mon Apr 27 10:01:06 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 10:01:06 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA25521; Mon, 27 Apr 92 10:01:02 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA01341; Mon, 27 Apr 92 09:55:48 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 Apr 92 21:25:52 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!ellis![e-mail]  (Richard L. Goerwitz)
Organization: University of Chicago Computing Organizations
Subject: Re: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

While we're at it, I'd like to advertize a course in COBOL and FORTRAN
programming for computer science students.  An advanced course in BASIC
will be offered as well.

--

   -Richard L. Goerwitz              [e-mail]
   [e-mail]           rutgers!oddjob!ellis!goer

From icon-group-request  Mon Apr 27 14:32:41 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 14:32:41 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA09622; Mon, 27 Apr 92 14:32:38 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA12719; Mon, 27 Apr 92 14:15:42 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 25 Apr 92 01:41:36 GMT
From: mintaka.lcs.mit.edu!zurich.ai.mit.edu![e-mail]  (Allan Adler)
Organization: M.I.T. Artificial Intelligence Lab.
Subject: Re: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] (Guy Helmer) writes:


    Following is information about a three-credit graduate course
   in programming for the humanities offered by Dakota State
   University via BITNET (and other interconnected networks).
   Students in the course can be anywhere in the world if they can
   send and receive electronic mail.
     [ details of the course deleted]
    The total cost of the course is $239.82.  No textbook is
   required.  Students will be sent a disk containing a public-domain
   SNOBOL4 compiler and a text editor.  Lectures and data files will
   be sent electronically.

    Students may audit the course or enroll for credit and receive
   a grade of Pass or Fail.  The cost to audit the course is the same
   as enrolling for credit.

    Those who want an electronic registration form or who have
   questions about the course should send a message to



I think this counts as commercial advertising. If someone wants to make the
course materials available to people via anonymous ftp, that is one thing.
If someone wants to organize a network of volunteers to help people in the
humanities learn computers, that is still ok. But this is pure commerce.

Aren't there rules about this sort of thing?

Allan Adler
[e-mail]

From icon-group-request  Mon Apr 27 15:16:23 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 15:16:23 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA11850; Mon, 27 Apr 92 15:16:22 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA15775; Mon, 27 Apr 92 15:12:45 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 25 Apr 92 01:37:07 GMT
From: s5![e-mail]  (Seth Breidbart)
Organization: Morgan Stanley & Co., New York, NY
Subject: Re: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]>
[e-mail] writes:
>I didn't think there were any living SNOBOL programmers left!

Well, I was once paid for programming in SNOBOL.  Does that count?
(But I remember how surprised I was the only time I saw a "help
wanted" ad for a SNOBOL programmer!)

>in SNOBOL, which is hardly an industrial-strength language with widespread
>support!

No, but it's a lot of fun!

Seth        [e-mail]

From [e-mail]  Tue Apr 28 13:43:08 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 28 Apr 92 13:43:08 MST
Received: from eos.arc.nasa.gov by optima.cs.arizona.edu (4.1/15)
    id AA03700; Tue, 28 Apr 92 13:43:06 MST
Received: Tue, 28 Apr 92 13:42:28 -0700 by eos.arc.nasa.gov (5.57/1.2)
Date: Tue, 28 Apr 92 13:42:28 -0700
From: Michael Shafto <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], s5![e-mail]
Subject: Re: Computer Programming for the Humanities Course Offering
Cc: [e-mail]

s5![e-mail]  (Seth Breidbart):
"[e-mail] writes:
 ' ... SNOBOL, which is hardly an industrial-strength language ... '"

It's sure no PL/I or Ada!

To paraphrase a phrase, "To really mess things up, you
need an international standards committee!"

Mike

From icon-group-request  Tue Apr 28 19:33:46 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 28 Apr 92 19:33:46 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA16798; Tue, 28 Apr 92 19:33:44 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA28705; Tue, 28 Apr 92 19:24:29 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 27 Apr 92 04:41:35 GMT
From: mips!munnari.oz.au!goanna![e-mail]  (Richard A. O'Keefe)
Organization: Comp Sci, RMIT, Melbourne, Australia
Subject: Re: features from Icon Language in lisp
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]>, [e-mail] (Jonathan Rees) writes:
> In this discussion of Icon features in Lisp, I'm surprised that no one
> has mentioned the obvious embedding of Icon-like control in Scheme.
Thanks for posting it.

> ; (accumulate a) returns a list of all the possible values of the
> ; expression a.  Prolog calls this "bagof"; I forget what Icon calls it.

Wrong.

Prolog calls it findall/3.  There is a *MAJOR* difference between findall/3
and bagof/3, which is not relevant to Scheme.

For what it's worth, some functional languages call this "list comprehension".
A stream-based version can be found in SICP, of course.
--
I am writing a book on debugging aimed at 1st & 2nd year CS students using
C/Modula/Pascal-like languages.  Please send suggestions (other than "you
_must_ cite "C Traps and Pitfalls") to [e-mail]

From [e-mail]  Wed Apr 29 04:23:53 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 29 Apr 92 04:23:53 MST
Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15)
    id AA08177; Wed, 29 Apr 92 04:23:49 MST
Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12865) id
 <[e-mail]>; Wed, 29 Apr 1992 06:24 CST
Date: Wed, 29 Apr 1992 06:24 CST
From: Chris Tenaglia - 257-8765 <[e-mail]>
Subject: Icon Performance Tuning
To: [e-mail]
Message-Id: <[e-mail]>
X-Organization: Medical College of Wisconsin (Milwaukee, WI)
X-Vms-To: IN%"[e-mail]"


I've enjoyed the Icon Newsletter and Icon Analyst and their mentioning
of tuning and profiling iconware from algorythmic, and implementation
viewpoints. But I'm wondering if there has been much done from the host
OS point of view to make things run more smoothly.

------------------------------------------------------------------------
VMS : Has several hundred parameters that control memory and disk use.
      You change a parameter by editing a file, run a utility, and then
      rebooting.

Unix: I think has a similar operation. You edit a parameter file (actually
      part of a C program) and then 'rebuild' the kernel.

DOS : Has CONFIG.SYS with things like FILES, BUFFERS, and other possible
      memory management doodads.

MAC and others : I haven't the foggiest idea
------------------------------------------------------------------------

I'm most interested in DOS at the moment. I'm wondering if anyone has
tinkered with FILES, BUFFERS, or running Icon in a LAN (PathWorks mostly,
but Novell and Banyan comments are also welcome). Perhaps one has had
to actually be in the guts of Icon to know what to do? I have some IO
intensive programs, and they actually run slower than interpreted BASICA.
(and it's not just inefficient icon code). Any pointers or hints would be
greatly appreciated. I use Icon 5.9 (mostly) & 8.0 (sometimes) on DOS 3.3,
but I don't think IO methods have changed that much.

Chris Tenaglia (System Manager) |  "The past explained,
Medical College of Wisconsin    |   the future fortold,
8701 W. Watertown Plank Rd.     |   the present largely appologized for."
Milwaukee, WI 53226             |   Organon to The Doctor
[phone]                   |
[e-mail]


From icon-group-request  Fri May  1 10:46:31 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 1 May 92 10:46:31 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA20861; Fri, 1 May 92 10:46:28 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA01504; Fri, 1 May 92 10:33:13 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 29 Apr 92 15:22:35 GMT
From: ogicse!mintaka.lcs.mit.edu!zurich.ai.mit.edu![e-mail]  (Allan Adler)
Organization: M.I.T. Artificial Intelligence Lab.
Subject: Re: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] (John Leslie) writes:


   In article <[e-mail]> [e-mail] (Stephen P Spackman) writes:
   >
   >A society that makes charging for sex illegal and considers charging
   >for information only proper is *very seriously twisted*.
   >
      As it turns out, there's a very good reason for governments to prohibit
   free market sex -- the extreme costs of AIDS treatment make it entirely
   impractical to regulate such a market and allocate the true costs.  Surely
   today's Internetters don't _still_ believe that *information* is as
   harmful? :)

   John Leslie <[e-mail]>


The cost of ignorance is also quite high. That is a good argument for free
information.

Allan Adler
[e-mail]

From icon-group-request  Fri May  1 18:32:50 1992
Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 1 May 92 18:32:50 MST
Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15)
    id AA07779; Fri, 1 May 92 18:32:46 MST
Received: by ucbvax.Berkeley.EDU (5.63/1.43)
    id AA00208; Fri, 1 May 92 18:20:23 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 28 Apr 92 04:38:48 GMT
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!hardy.u.washington.edu![e-mail]  (Eric F.)
Organization: University of Washington, Seattle
Subject: Re: Computer Programming for the Humanities Course Offering
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] (John Hughes) writes:
>In article <[e-mail]> [e-mail] (Guy Helmer) writes:
>>In <[e-mail]> [e-mail] (Allan Adler) writes:
>>
>>>In article <[e-mail]> [e-mail]
>>> (Guy Helmer) posted:
>>
>>>>    Following is information about a three-credit graduate course
>>>>   in programming for the humanities offered by Dakota State
>>>>   University via BITNET (and other interconnected networks).
>>>>     [ details of the course deleted]
>>>>    The total cost of the course is $xxx.xx.  No textbook is
>>                                         ^^^^^^
>>Actual cost deleted to avoid affending even more readers. :-)

[arguments concerning whether this is or is not commercial advertising]

>>>Aren't there rules about this sort of thing?
>>
>>:-)  Rules on Usenet?
>>

[more deletia]

>
>I've been watching the various reactions to the original posting with some
>mixed feelings. It is a source of puzzlement to me as to why there aren't
>more readily accessible venues for this type of "alternative" education
>(please spare me the comments about the comp. sci. degrees by mail in the
>Popular Mechanics ads). I, for one, would welcome the opportunity to acquire
>additional education in a form that wouldn't tax my already overloaded
>school and work schedules. Also, since this is a course offered for credit
>by a (presumably) accredited, non-profit academic institution, I don't
>really see where it fits into the same category as, say, IBM or DEC trying
>to use the Internet to sell their latest workstations. And, as Guy points
>out, there really isn't much difference between the posting for the course
>offering and those seen regularly for various and sundry conferences.
>Perhaps there should be a move to ban conference notices which go into
>long and gory detail (including costs).
>
>But seriously, the technolgy and resources now exist to allow this type of
>"electronic classroom" to exist in a way never before possible. I would
>suggest that the collective minds of the Internet consider the possibilities
>and weigh the benefits before hastily brandishing the "non-commercial"
>club and beating such postings senseless.

I can make a suggestion: Advertising 'products' that are in whole or in
major part information is OK, advertising tangible goods is out. For example,
the following could be sold through the net:
Software, counseling, on-line magazines and periodicals, training, legal
advice, etc.

The following would not be OK:
Computers, cars, food, booze, condominiums, condoms....etc.

The usual classified ad type stuff would still be OK(by the way, I have a
used AT for sale ;->).

Just a suggestion from off the top of my head. Flame away; I am interested in
comments. Especially interested in counter-suggestions.
=Eric