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

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

From ralph  Sat Jan 24 16:52:26 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: Book on the implementation of Icon
Status: RO

The book on the implementation of the Icon programming language been published.
It corresponds to Version 6 of Icon, which is currently running on UNIX, VMS,
and MS-DOS computers.  The book concentrates on the run-time system and
describes data structures, the Icon virtual machine, the interpreter,
how generators work, and the techniques for storage allocation and garbage
collection. Its appendices include information on modifying and extending the
implementation.

The publication information is:

    title: The Implementation of the Icon Programming Language
    authors: Ralph E. Griswold and Madge T. Griswold
    publisher: Princeton University Press
    ISBN 0-691-08431-9
    Hardbound, 336 pages, $39.50.

The book may be ordered from local bookstores or directly from the publisher:

    Princeton University Press
    3175 Princeton Pike
    Lawrenceville, NJ   08648

    [phone]

There is no shipping charge for orders sent fourth class. UPS delivery
is available for a small additional charge that depends on the destination.
There is sales tax of 6.5% in California and 6% in New Jersey.

Note: This book is not available from the Icon Project.

From [e-mail]  Fri Jan 30 08:52:35 1987
From: Wyle <[e-mail]>
To: [e-mail]
Mmdf-Warning:  Parse error in original version of preceding line at SWITZERLAND.CSNET
Cc: [e-mail]
Subject: icon programming
Status: RO

I have a student project under design here in which
a palatte of icons will be developed for higher level
modules in a visual information retrieval system.

I am interested in your mailing list.  Can you send
more information?
--
                      M i t c h e l l     F     W y l e

    EEEEE TTTTTT H   H  Eidgenoessische      | wyle%ifi.ethz.chunet@csnet-relay
   E       T    H   H  Technische Hochschule | [e-mail]
  EEEE    T    HHHHH  Zuerich                | ...!cernvax!ethz!wyle
 E       T    H   H  Institut fuer Informatik| Telephone: [phone]
EEEEE   T    H   H  8092 Zuerich, Switzerland| "Ignore alien orders"

From ralph  Mon Feb  9 14:26:13 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: Status of icon-group
Status: RO

Several years ago we set up icon-group as a mail-redistribution
system whereby addressees on a list kept at the University of
Arizona could recieve electronic mail about the Icon programming
language and in turn have their mail to icon-group redistributed to
others on the list.

The idea was to encourage the exchange of information. Historically,
most of the mail has originated at the University of Arizona and has
consisted mostly of announcements. Relatively few messages have come in
from outside the University of Arizona for redistribution.

Last July a mail-server bug caused some addressees to receive
multiple copies of the same message. Since this was a comparatively
serious problem, we disconnected icon-group service.  We now have a
a way around for the problem.

However, the usefulness of icon-group depends on the active participation
of its members. Let us hear from you. If you have questions, ask.
If you have problems with programming in Icon, try icon-group; perhaps
someone can help.

For reference, here are the relevant addresses:

    [e-mail]    mail just to the Icon Project
    [e-mail]        mail for redistribution icon-group list
    [e-mail]    requests to be added to icon-group

From naucse!sbw  Mon Feb  9 16:29:03 1987
From: naucse!sbw (Steve Wampler)
To: arizona!icon-group
Subject: formatting (shudder) in Icon
Status: RO


I'm looking for nice ways to format floating point numbers in Icon.
Something along the lines of:

   write(format(x,"5.2"))

or

   Write("f5.2  f5.2",x,y)

say.  Any ideas are welcome, as are other approaches.  However, I
am not particularly interested in FORTRAN- (or C-)style solutions.

    -Steve Wampler

From amdcad![e-mail]  Tue Feb 10 00:23:43 1987
From: amdcad![e-mail] (Andy Beals)
To: [e-mail]
Subject: status of icon group
Status: RO

>From amdcad![e-mail] Mon Feb  9 16:48:20 1987
To: [e-mail]
Subject: Re:  Status of icon-group

I admit it!  I haven't been using icon at all - I haven't written
a single line of code - I'm wasting my time working on a portable c-based
snobol4 interpreter.  Ouch!  Hit me hit me!

Seriously though, I think that one of the reasons that the icon-group hasn't
gotten much traffic is because there are very few people using it -- imagine
how it would be if Icon got the publicity and coverage (in cs courses (they're
still teaching snobol in every computing languages survey course I've seen!)
as well as useful / fun programs posted to the net) that say (ugh) Modula2
has.

How does the current vax (or sun) implementation of icon compare to awk
in terms of speed when you use it for reading and decoding uucp LOGFILES
or netnews' log file?  I think that if you could take Erik Fair's popular
scripts that do just these things and convert them to Icon and show that
they're faster than the scripts in awk, I'm sure that you could get a lot
of system-hacker types interested -- I still manage to write a coupld little
awk programs a month, again mostly state-machine file summarizers.

ramble ramble ramble
andy




From ralph  Tue Feb 10 04:31:57 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: Icon for the Atari ST
Status: RO

O. Rick Fonorow and Jerry D. Nowlin report that they have completed
an implementation of Version 6.3 of Icon for the Atari ST computer family.

The Lattice C compiler was used for the port (giving 32-bit ints). This
version takes all available memory, but uses fixed-sized regions for Icon's
data.  It will run on the 520ST with no other programs (i.e. desk
accessories) resident.

This implementation is available on the Atari Base BBS: [phone].

From @po3.andrew.cmu.edu:mss#@andrew.cmu.edu  Tue Feb 10 06:56:17 1987
X-Trace: MS Version 3.21 on ibm032 host westchester, by mss (1342).
From: mss#@andrew.cmu.edu (Mark Steven Sherman)
To: [e-mail]
Subject: Use in CS classes
Cc: amdcad![e-mail]
Status: RO

It may have been a while since you were in a comparative languages course. I
taught it several times at Dartmouth and we used Icon, not Snobol, and one of
the three sections of it here at CMU is also using Icon (the other two are
using neither Icon nor Snobol). I think you overestimate the fall-out of
usage from these classes of any language. A language gets used by undergrads
when their part-time workstudy employer tells them to use it.
                -Mark



From [e-mail]  Tue Feb 10 10:12:06 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: reads(&input,1) under MSDOS Icon
Status: RO


Using SNOBOL4+ under MSDOS, I can define keyboard input
to be "R,B,Q,1" = Read, Binary, Quiet, 1-character,
and I have 1-character input from the keyboard, without echo,
which is useful for control characters, function keys, etc.,
in interactive programs.

In Icon under MSDOS, I try to get the same effect by asking
for the result of reads(&input,1), but I do NOT get the
same effect.  reads() waits for a CR.

Is anyone else bothered by this problem, and better
yet, has anyone fixed it?

(You can use the ANSI.SYS-dependent key-redefinition to make
control- and function-keys generate a code followed by
a CR, but this is inelegant.)

Mike Shafto
shafto@nprdc
Office of Naval Research, Code 1142CS
800 N. Quincy St.
Arlington, VA   22217-5000
202/696-4596


From ralph  Tue Feb 10 10:20:48 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: reading single characters in MS-DOS Icon
Status: RO

In response to Mike Shafto's query, there are a number of extensions to
MS-DOS Icon that are in the works to solve this problem and in general
give the MS-DOS programmer access to almost anything from the Icon
source level.

I'm not sure how long it will take to get these completed, tested,
documented, and packaged for distribution. Perhaps a month.

I'll try to get a preliminary description of what's in the works
out to icon-group within a week.

    Ralph Griswold

From naucse!sbw  Tue Feb 10 10:47:24 1987
From: naucse!sbw (Steve Wampler)
To: arizona!mss#@andrew.cmu.edu
Subject: Re:  Use in CS classes
Cc: arizona!icon-group
Status: RO

I agree.  My feeling is that the way to increase the popularity of Icon
is by distributing some really useful programs that also show off the
power of the language.  Icon-group could help do this.

From [e-mail]  Tue Feb 10 14:25:54 1987
From: vijay <[e-mail]>
Subject: Increasing the popularity of ICON
To: [e-mail]
Cc: [e-mail]
Status: RO

Or have some country like S.Korea pick it up as the basis for their
Next Generation Software Miracle! :-)
-------

From [e-mail]  Tue Feb 10 16:29:01 1987
To: [e-mail]
Cc: amdcad![e-mail], [e-mail]
Subject: icon in courses
From: David Notkin <[e-mail]>
Status: RO

Here at the University of Washington we also teach Icon as part of a
junior-level comparative languages class (this year, the other languages we
are teaching are Lisp, Prolog, and Smalltalk).  It's at least the fourth
quarter we are using Icon in this course.

David

From whm  Thu Feb 12 13:45:56 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: Re:  formatting (shudder) in Icon
In-Reply-To: <8702092256.AA17254@naucse>
Status: RO

I think that Icon's output facilities are really weak with respect to
the rest of the language -- all there is a function that concatenates
a bunch of strings and prints the result.  Purists will no doubt cringe,
but I think that C's printf is vastly more usable.  For a couple of large
projects in Icon I added a C function called format that was really just a
front-end to printf's internal routine doprnt, which really does the work.

To wit:

    format(s, x1, ... xn)

Returns a string produced by formatting the values x1-xn according the
printf-style specification s.

For example,

    write(format("i = %d, hex: %x, octal: %o", i, i, i))


From ralph  Thu Feb 12 15:30:30 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: Formatting (shudder)
Status: RO


I wouldn't argue that a printf-like facility in Icon would not be
useful.  However, from a language-design viewpoint, I'd rather see
something at a higher level. In fact, the real problem is not
just output formatting, but the synthesis of strings (witness the
usefulness of sprintf in C).

I've thought about abstractions for synthesis comparable to the
pattern abstractions for analysis. It's possible to formulate some
of these in Icon itself, much in the fashion that string scanning
and pattern matching can be formulated in Icon to model the built-in
facilities.

However, while you can argue that analysis and synthesis should be
treated symmetrically, it seems there are many more problems that
require string analysis than there are that require string synthesis.
Hence, it is hard to justify such an elaborate mechanism for synthesis.

Of course, if high-level analysis and synthesis could be unified ...

From @po3.andrew.cmu.edu:mss#@andrew.cmu.edu  Thu Feb 12 17:47:41 1987
X-Trace: MS Version 3.21 on ibm032 host cmu-ws-ardara, by mss (1342).
From: mss#@andrew.cmu.edu (Mark Steven Sherman)
To: [e-mail]
Subject: MacIcon
Status: RO


I think purely by coincidence, the Usenet Macintosh newsgroup started
discussing Icon on the Mac. Last I heard, someone was working on it, but I
never heard of a release being available from Arizona or anywhere else (there
was a suggestion to check on Sumex, which I will do). What is the current
status of Icon on the Macintosh?



From ralph  Thu Feb 12 18:02:36 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: Icon for the Macintosh
Status: RO

In response to Mark Steven Sherman's query about Icon for the Macintosh:

Funny you should ask, as they say; I was preparing an announcement.
Here it is:

Bob Alexander has completed an implementation of Version 6 of Icon that runs
under MPW.  It is not a stand-alone application; MPW is required.

It is a large-memory model implementation that requires at least a 512K Mac.

This implementation is in the public domain and eventually will be
available from a variety of sources.  We will provide a copy along
with printed documentation for $15, payable to the University of
Arizona.  Add $5 for air mail delivery outside the United States and
Canada.

Source code and the Icon program library will be available at a later date.

Please note: MPW is *required* to run this application. MPW is
a window-oriented development system available exclusively through

    Apple Developer's and Programmer's Association
    290 SW 43rd Street
    Renton, WA   98055

    [phone]

The fee to join APDA is $20 and MPW costs $150.  There also is a C
compiler, but it is not needed to run Icon.

From ralph  Thu Feb 12 18:44:13 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: Our Postal Mailing Address
Status: RO

It only occurred to me after sending information on getting
Icon for the Macintosh from us that some of you may not
know our postal address.  In fact, it recently has acquired
an adornment, courtesy of the relocation of our department
to a newly constructed building.  Here's the best address:

    Icon Project
    Department of Computer Science
    Gould-Simpson Science Building
    The University of Arizona
    Tuscon, AZ   87521

Our telephone number remains the same:  [phone]

From [e-mail]  Thu Feb 12 22:11:44 1987
From: Gus Fernandez <[e-mail]>
Subject: Re:  Icon for the Macintosh
To: [e-mail], [e-mail]
Status: RO



From [e-mail]  Thu Feb 12 22:12:05 1987
From: Gus Fernandez <[e-mail]>
Subject: Re:  Icon for the Macintosh
To: [e-mail], [e-mail]
Status: RO



From [e-mail]  Thu Feb 12 22:29:08 1987
From: Gus Fernandez <[e-mail]>
Subject: 8 queens revisited.
To: [e-mail]
Status: RO

Hello, I am new to this group, and to ICON, but I would like to discuss two
objecttions which I have to the "8 queeens" problem implementation which
appears on page 153 of Griswold's book. As a refresher, here it is...

procedure main()
   every write(q(1),q(2),q(3),q(4),q(5),q(6),q(7),q(8))
end

procedure q(c)
   suspend place(1 to 8,c)            # Look for a row
end

procedure place(r,c)
   static up,down,row
   initial {
      up:= list(15,0)
      down := list(15,0)
      row := list(8,0)
      }
   if row[r] = down[r+c-1] = up[8+r-c] = 0
   then suspend row[r] <- down[r+c-1] <-
     up[8+r-c] <- r                    # Place if free
end

My first objection seems to be the necessity of having to explicitly invoke
q() 8 times in the main() procedure. Just typing every q(1 to 8) does not work
since q(1) immediately succeeds after placing the first queen. Perhaps what I
want is a more general itterator which applies the output of a generator to
a co-expression and backtracks when necessary. How would one write something
like that in ICON?

My second objection is to the use of static variables in the place routine. I
may have just answered my own question. Make an instance of place into a co-
expression, and use it instead of the static variables, but I will have
to try it out to see if it works. Does anyone have an elegant way of having
two or more queens sequences active, and being able to call on either one to
get the next valid queen configuration for that list? This seems easy in a
language like smalltalk, but I am convinced that with little work, it should
be possible in ICON as well

                            Gus Fernandez

From icon-group-request  Fri Feb 13 17:41:49 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: Testing Icon-Group
Errors-To: icon-group-request
Status: RO

This test should be local only -- my apologies if it goes further.

From icon-group-request  Fri Feb 13 18:04:23 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: mailer improvements
Errors-To: icon-group-request
Status: RO

We've made some changes in the local processing of the list that will
hopefully cause failed mail to be redirected back to the icon-group-request
address rather than going to the sender of the particular message.

If you send a message after today (2/13) and get back failed mail from it,
we'd appreciate it if you'd forward the failed messages to icon-group-request.

From ralph  Sat Feb 14 15:38:01 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: N Queens
Errors-To: icon-group-request
Status: RO

As a partial response to Gus Fernandez' query about the n-queens problem,
here is a version from the Icon program library that approaches the
situation a little differently from the approach in the Icon book (which
is designed to illustrate goal-directed evaluation and data backtracking,
rather than the issues Gus Fernandez raised):
=========================================================================
#    QUEENS
#
#    Solutions to n nonattacking queens
#
#    Stephen B. Wampler
#
#    Last modified 8/14/84
#

global n, solution

procedure main(args)
   local i
   n := args[1] | 6        # 6 queens by default
   if not(0 < integer(n)) then stop("usage [ n ]")
   solution := list(n)        # ... and a list of column solutions
   write(n,"-Queens:")
   every q(1)            # start by placing queen in first col.
end

# q(c) - place a queen in column c.
#
procedure q(c)
   local r
   static up, down, rows
   initial {
      up := list(2*n-1,0)
      down := list(2*n-1,0)
      rows := list(n,0)
      }
   every 0 = rows[r := 1 to n] = up[n+r-c] = down[r+c-1] &
      rows[r] <- up[n+r-c] <- down[r+c-1] <- 1        do {
         solution[c] := r    # record placement.
         if c = n then show()
         else q(c + 1)        # try to place next queen.
         }
end

# show the solution on a chess board.
#
procedure show()
   static count, line, border
   initial {
      count := 0
      line := repl("|   ",n) || "|"
      border := repl("----",n) || "-"
      }
   write("solution: ", count+:=1)
   write("  ", border)
   every line[4*(!solution - 1) + 3] <- "Q" do {
      write("  ", line)
      write("  ", border)
      }
   write()
end

From icon-group-request  Sun Feb 15 00:27:18 1987
Return-Path: <kinner@wsu>
From: Bill Kinnersley  <[e-mail]>
To: [e-mail]
Errors-To: icon-group-request
Status: RO



Well OK, Ralph.  I too would like to see more active discussion of
Icon in this group.  Let me help to start the ball rolling.

I am certainly not an Icon expert.  I have been fascinated with the
language for the past two years, and I taught it to my class in
Programming Language Design.  What puzzles me is how little I use
it.  Our conclusion in class was that Icon was much more in the
experimental stage than Smalltalk, Prolog, etc.

According to the book, Icon is good for string processing, quick
one-shot programs, and heuristic solutions to complex problems.
In other words, AI.

From an internal point of view, surely the central feature of the
language is generators.  Most of the cost of Icon implementation
must be allowing each and every expression to be a generator.  One
needs to ask, therefore, whether that feature is worth the cost.

From my own ignorant and biased perspective, let's list some good
points and some bad...

Syntax - I find the syntax natural, and the innovations particularly
    appealing.  :=: and "break break" should be in every language.

Csets - No use for this, myself.

Lists - One of Icon's best aspects.  Much easier to use than Lisp.
    I do get confused between get(), put(), push(), and pop().  My
    impression is that many of the things that used to be done using
    string manipulation are better done with lists anyway.

Implicit type conversion - not such a great idea.  Mainly it's the
    conversion to and from strings that's unusual, and I'd
    rather do it explicitly when I really need to.

    Typelessness of variables has an unpleasant side effect--
    It puts the burden on the operators to decide the type of an
    outcome, and as a result there are FAR TOO MANY operators.
    Mentioning ~===:= to the class is always good for a giggle.

Procedure invocation - again very nicely done.

Generators - outside the string-search context, I find it a little
    hard to explain what these are, and what they're good for.

    Me: "Well, they're like a generalized for loop.  Suppose you
      didn't want to just go 1, 2, 3, ... say, but for every number
      obeying some complicated condition..."
    Student: "Well then, I'd use a while loop, and write a subroutine
      with some static variables, and I'd just keep calling that to
      get the next number."
    Me: "Yes, but this is cleaner conceptually.  And more general.
      And you can write your own generators...and, uh, in fact they
      look just like subroutines, only they suspend."
    (Student stares at me, and whispers something to his neighbor.
     Other student smiles and nods his head.)

    Seriously, as the heart and soul of Icon, generators need a strong
    sales push.  Do they really open up new worlds, or are they
    rarely used and easy to simulate?  Go through a book on algorithms
    and count how many times a generator would come in handy.

Backtracking - this is great!  One of the real reasons for choosing
    Icon to program in.  The Eight Queens problem deserves its place
    on the cover, and it's not too hard to produce other examples
    which are equally impressive.

Suggestion: Here's a common situation that needs to be handled better.
    Where it says

       write (q(1), q(2), q(3), q(4), q(5), q(6), q(7), q(8))

    Remember that?   This is a trick we use to get the q's to mutually
    succeed.  Or, we could have used q(1) & q(2) & ...  This does come
    up a lot, and it can get out of hand pretty quickly if there are more
    than 8 items.  Maybe what we need is a new construct:

       all q(1 to 8)

Summary - We teach that a well designed programming language is more
    than a collection of useful features.  It must have a uniform
    syntax, an easily-expressed purpose and philosophy, and a set of
    features which are consistent, powerful, and thrifty.  Often as not,
    a language can be improved by removing features, not just adding.

    Object-oriented languages are all the rage these days.  People are
    diligently putting objects into Pascal, C, Lisp, etc.  For heavens
    sakes, don't anyone try to do that to Icon!



From mark  Sun Feb 15 09:41:19 1987
From: "Mark L. Langley" <mark>
To: [e-mail], [e-mail]
Subject: Kinnersley Comments
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

I enjoyed the comments of Bill Kinnersley.  I would like to add
to them with my own perspective remarks...

    According to the book, Icon is good for string processing, quick
    one-shot programs, and heuristic solutions to complex problems.
    In other words, AI.

    >From an internal point of view, surely the central feature of the
    language is generators.  Most of the cost of Icon implementation
    must be allowing each and every expression to be a generator.  One
    needs to ask, therefore, whether that feature is worth the cost.

My experience is that the central feature or the language is data structures
and the unique control mechanisms exist to manipulate them with idiomatic
operations!  I acknowledge that generators-in-a-vacuum seem kind of odd.
But the key is that I always use generators with something particular in
mind.  For example emumerating the elements of a list or string with '!'.
The non-icon way of enumerating the elements of some data structure is
by producing successive subscripts or dereferencing consecutive pointers.
In Icon, you just say
    every i := !Thing do
       do_something(i)
Thus one can eliminate the subscript-scaffolding present in other flavors of
solutions.

The word-parsing programs in the book are another good example.  You just
want to say -- "Yea, I figured out how to get the first one, you go
get the next one..."

    Csets - No use for this, myself.

The key to Csets is that most string-functions take a cset as an
argument.  They simply represent a character class in pattern matching,
I've found.

    Implicit type conversion - not such a great idea.  Mainly it's the
        conversion to and from strings that's unusual, and I'd
        rather do it explicitly when I really need to.

        Typelessness of variables has an unpleasant side effect--
        It puts the burden on the operators to decide the type of an
        outcome, and as a result there are FAR TOO MANY operators.
        Mentioning ~===:= to the class is always good for a giggle.

Interesting point.  As for the string-to-number property,
It is nice to be able to read something in and have it
be added to at the same time.  It would be nice if you
could trap errors though, rather than have to check explicitly in advance...
   ie
    t := 0
    while (t +:= read())
    write (t)
  and
    t := 0
    while (t +:= number(read()) | tilt())
    write (t)

My own personal objections are that functions can be overwritten
but not defined on the fly.  And there are severe performance
penalties for having to check the type of an object (which is syntacticaly
a function) before calling it.  (ie someone may overwrite "write"...)
I particularly don't like the global side effect of overwriting "write".
ie if I say
    write := foonley
Then it tries to call foonley the next time I call write, since functions
are first class objects with global scope.

From gudeman  Sun Feb 15 14:19:52 1987
From: "David Gudeman" <gudeman>
To: [e-mail]
In-Reply-To: Bill Kinnersley's message of Sat, 14 Feb 87 10:36:44 PST
Subject: generators and backtracking
Errors-To: icon-group-request
Status: RO

   Date: Sat, 14 Feb 87 10:36:44 PST
   From: Bill Kinnersley  <[e-mail]>
   ...
       Seriously, as the heart and soul of Icon, generators need a strong
       sales push.  Do they really open up new worlds, or are they
       rarely used and easy to simulate?  Go through a book on algorithms
       and count how many times a generator would come in handy.

   Backtracking - this is great!  One of the real reasons for choosing
       Icon to program in.  The Eight Queens problem deserves its place
       on the cover, and it's not too hard to produce other examples
       which are equally impressive.

It seems that a lot of people think of generators as "just a sort of
implicit loop".  They are actually much more than that, specifically,
they are the mechanism on which backtracking is based.  It is hard to
imagine how there could be backtracking without generators.  So if you
think backtracking is great, you should like generators.

From icon-group-request  Sun Feb 15 14:58:51 1987
From: [e-mail] (Doug Alan)
To: [e-mail]
Subject: Re:  generators and backtracking
Errors-To: icon-group-request
Status: RO

Personally, I think that generators are much more important than
backtracking.  Generators are a good form "control abstraction", which
is just as essential, but much more often neglected than, procedural
abstraction and data abstraction.  Saying "I don't need generators --
I could do that in a for loop," is like saying "I don't need
procedures -- I can just stick the code for that right in here."
Control abstraction allows you to provide, for example, a way of
iterating through all the components of an abstract data type in a way
that may not be possible otherwise without violating the interface of
the abstract data type.  It provides a clean and simple mechanism for
doing co-routining.  Generators are a clean generalization of data
streams.  Instead they are computation streams.

                |>oug  /\lan

--
[e-mail]
{allegra,seismo,decvax!genrad}!mit-eddie!nessus
MIT, E40-358a, Cambridge, MA 02139 [phone]


From icon-group-request  Sun Feb 15 16:21:01 1987
From: [e-mail] (William Griswold)
Return-Path: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  generators and backtracking
Errors-To: icon-group-request
Status: RO


I like Doug Alan's comments on generators supporting computation streams.
One thing I would like to point out is that computation streams, unlike
data streams, experience false dead-ends.  To generate all possible results
in a computation stream it is absolutely necessary to backtrack from a
given result and find another one.  Even the simplist case of generating
all the elements in a list requires this.  The concept of a generator is
a control structure for implementing backtracking.  The two are in fact the
same thing.  The Icon book describes Icon's evaluation method as
``goal directed''.  When thought of this way, the duality of generators
versus backtracking should vanish.

                        Bill Griswold

From ralph  Mon Feb 16 10:54:26 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: Enhancements to Version 6 of Icon for MS-DOS
Errors-To: icon-group-request
Status: RO

What follows is a condensed version of working notes from Cheyenne Wills
for the enchancements he has implemented for MS-DOS Icon. I've left out
details of error and failure conditions, examples, and so forth, in
the interests of brevity.  I'll be happy to mail a copy of the complete
notes to ineterested persons.

Comments are welcome and will be passed on to Cheyenne.

    - Ralph Griswold
      [e-mail]

=========================================================================
Console input routines:

getch()        Wait until a keyboard character is available. Then return
        a one-character string containing it. The character is not
        displayed on the screen. getch() returns a "\0" value for
        a character that doesn't have a ASCII equivalent. The next
        call to getch returns the keyboard scan code.

getche()    Same as getch() except that characters are echoed as they
        are typed.

kbhit()        Succeeds if there is a character available for getch or
        getche. Otherwise it fails.

=========================================================================
Miscelaneous functions:

getenv(s)    Return contents of environment variable s. It fails if s is
        not in environment.

seek(f,i1,i2)    Seek to offset byte from start in file.  Returns byte offset
        within file.
        fails if an error occurs.

=========================================================================
MS-DOS interface routines:

Disclaimer: The following routines are included as a "gateway" to functions
provided by MS-DOS and ROM BIOS. They should be used with care, as Icon
maintains a strict control on its environment (although it uses standard MS-DOS
interfaces and doesn't bypass MS-DOS or ROM BIOS in any way).

The descriptions that follow are low-level descriptions. They assume knowlege
of the Intel 8086 (8088, 80x86 etc.) architecture.

Int86(l)    Generate a hardware interrupt. The input (l) is a list of
        integer values [interrupt #, ax, bx, cx, dx, si, di, es, ds]
        It returns a list: [flags, ax, bx, cx, dx, si, di, es, ds].

GetSpace(i)    Allocate a static block of storage outside of Icon's direct
        control (i.e., it will not be affected by garbage collection).

FreeSpace(A)    Free a static block of storage. A is the value returned by
        GetSpace.

Peek(A,i)    Build a string pointing to the address specified
        by A with a length of i.

Poke(A,s)    Copy a string s to location A


From icon-group-request  Mon Feb 16 16:08:51 1987
From: "Bill Mitchell" <whm>
To: ralph
Subject: Re:  Enhancements to Version 6 of Icon for MS-DOS
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

Gosh, those MS-DOS guys have it made.  I've been wanting a getenv in
UNIX Icon for years and still no luck.

From icon-group-request  Mon Feb 16 18:15:11 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: Re:  Formatting (shudder)
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

   From ralph Thu Feb 12 15:30:48 1987
   To: [e-mail]
   Subject: Formatting (shudder)

   I wouldn't argue that a printf-like facility in Icon would not be
   useful.  However, from a language-design viewpoint, I'd rather see
   something at a higher level. In fact, the real problem is not
   just output formatting, but the synthesis of strings (witness the
   usefulness of sprintf in C).

String synthesis is an interesting problem, but I don't often find myself
wanting more string synthesis facilities, but the lack of formatting
capabilities darkens my Icon programs on very regular basis.

It seems that the printf syntax is really fairly good -- it's concise,
it doesn't try to do everything, and it usually covers all the bases.
I don't recall anything that I like better than printf; are there simple
formatting methods that are preferred by others?

I'd imagine that the printf syntax was inspired by FORTRAN's FORMAT.
Was FORMAT in the very first FORTRAN?  If so, is that to say that we
really haven't had any advances in this area?

From icon-group-request  Tue Feb 17 07:55:27 1987
From: Guy Lapalme <[e-mail]>
To: [e-mail]
Subject: string formatting
Errors-To: icon-group-request
Status: RO

I think that people that are only considering C and Fortran like formatting
facilities should look at what is done in COBOL using the "PICTURE"
specifications. Given that icon is not in the same class as COBOL, but
the formatting specifications are very well done.

Should somebody really want high level formatting specifications, go
and see what was done in Algol-68, you'll see a quite simple and efficient
way (and very systematic too) approach to formatting. It would surely be
interesting to write and Icon procedure that implements Algol68 IO.
As Algol68 was meant to be compiled, it does not need to be all interpreted
at run-time.

I also want to point out that Common Lisp has a very extensive (if not too
much) set of formatting commands in which you can even write number in
roman or in letters, you can right justify paragraphs etc...

Guy Lapalme
Universite de Montreal


From icon-group-request  Tue Feb 17 14:03:33 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Rolling the ball
Cc: [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO

Original message From: Bill Kinnersley  <[e-mail]>
To: [e-mail]
Errors-To: [e-mail]

I am certainly not an Icon expert.  I have been fascinated with the
language for the past two years, and I taught it to my class in
Programming Language Design.  What puzzles me is how little I use
it.  Our conclusion in class was that Icon was much more in the
experimental stage than Smalltalk, Prolog, etc.

-----
I'm not sure what "experimental" means.  All I know is that
I have some very practical programs which I use every day for
budget-management and for managing a volatile set of distribution
lists.  I maintain these programs myself, even though I'm far
from being a professional programmer, and I really have zero time
to devote to software development/maintenance.  The exact same
programs run on a Zenith 120 (not IBM compatible), IBM-XT,
Leading Edge, KayPro, Vax 11/780 running Unix, Vax 11/750
running VMS, and an Apollo.  For general usability and portability,
what language compares with Icon?
Smalltalk?  Prolog??  Lisp???  Get serious.
-----

According to the book, Icon is good for string processing, quick
one-shot programs, and heuristic solutions to complex problems.
In other words, AI.

-----
I think Icon falls a little short as an "AI language," due to the
fact that -- for example -- there aren't full-fledged analogues
to SNOBOL4's EXPRESSION, PATTERN, and CODE datatypes.  I believe
SNOBOL4 and LISP are the only generally available languages which
support the full range of atrocities needed for he-man AI.
-----

>From an internal point of view, surely the central feature of the
language is generators.  Most of the cost of Icon implementation
must be allowing each and every expression to be a generator.  One
needs to ask, therefore, whether that feature is worth the cost.

>From my own ignorant and biased perspective, let's list some good
points and some bad...

Syntax - I find the syntax natural, and the innovations particularly
    appealing.  :=: and "break break" should be in every language.

-----
I did an experiment recently in which I sent a 25-line
Icon program to a friend who was familiar with Pascal
but not Icon.  My program was uncommented & I challenged
him to figure out what it did & insert comments.  He wass able
to do this perfectly (Except:  he enclosed the comments
in /* */) and even to provide one slight re-write.  Since I
did this as an afterthought, having written the program for
a typically Icon-ish ad hoc purpose, I think it provides a fair
demonstration of what one might mean by "natural syntax."
-----

Csets - No use for this, myself.

Lists - One of Icon's best aspects.  Much easier to use than Lisp.
    I do get confused between get(), put(), push(), and pop().  My
    impression is that many of the things that used to be done using
    string manipulation are better done with lists anyway.

Implicit type conversion - not such a great idea.  Mainly it's the
    conversion to and from strings that's unusual, and I'd
    rather do it explicitly when I really need to.

    Typelessness of variables has an unpleasant side effect--
    It puts the burden on the operators to decide the type of an
    outcome, and as a result there are FAR TOO MANY operators.
    Mentioning ~===:= to the class is always good for a giggle.

-----
Agree re: lists.  Disagree re: implicit type conversion.  In my
opinion, you leave the realm of byte-pushing and enter the
realm of high-level programming languages when memory
management and typing are handled as transparently as possible.
-----

Procedure invocation - again very nicely done.

Generators - outside the string-search context, I find it a little
    hard to explain what these are, and what they're good for.

    Me: "Well, they're like a generalized for loop.  Suppose you
      didn't want to just go 1, 2, 3, ... say, but for every number
      obeying some complicated condition..."
    Student: "Well then, I'd use a while loop, and write a subroutine
      with some static variables, and I'd just keep calling that to
      get the next number."
    Me: "Yes, but this is cleaner conceptually.  And more general.
      And you can write your own generators...and, uh, in fact they
      look just like subroutines, only they suspend."
    (Student stares at me, and whispers something to his neighbor.
     Other student smiles and nods his head.)

    Seriously, as the heart and soul of Icon, generators need a strong
    sales push.  Do they really open up new worlds, or are they
    rarely used and easy to simulate?  Go through a book on algorithms
    and count how many times a generator would come in handy.

-----
I generally disagree with the above, but it raises an interesting
issue in conjunction with the earlier "multiplicity of
operators" observations:  Why are there so many different
operators in a language in which you get so much mileage
out of the humble "!" operator?
Or, why isn't == as generic as !?
-----

Backtracking - this is great!  One of the real reasons for choosing
    Icon to program in.  The Eight Queens problem deserves its place
    on the cover, and it's not too hard to produce other examples
    which are equally impressive.

Suggestion: Here's a common situation that needs to be handled better.
    Where it says

       write (q(1), q(2), q(3), q(4), q(5), q(6), q(7), q(8))

    Remember that?   This is a trick we use to get the q's to mutually
    succeed.  Or, we could have used q(1) & q(2) & ...  This does come
    up a lot, and it can get out of hand pretty quickly if there are more
    than 8 items.  Maybe what we need is a new construct:

       all q(1 to 8)

Summary - We teach that a well designed programming language is more
    than a collection of useful features.  It must have a uniform
    syntax, an easily-expressed purpose and philosophy, and a set of
    features which are consistent, powerful, and thrifty.  Often as not,
    a language can be improved by removing features, not just adding.

    Object-oriented languages are all the rage these days.  People are
    diligently putting objects into Pascal, C, Lisp, etc.  For heavens
    sakes, don't anyone try to do that to Icon!

-----
That's a big 10-4!
Although I've found the added feature of true sets
to be enormously useful.  Oddly, tables and lists
can be quite awkward (at least conceptually) when what
you want is sets.
-----
-----



From icon-group-request  Tue Feb 17 14:04:12 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Enhancements to Version 6 of Icon for MS-DOS
Cc: [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO



I'm an interested person.  You can mail me a copy of Wills's complete
notes at the following address:

Dr. Michael G. Shafto
Office of Naval Research, Code 1142CS
800 N. Quincy Street
Arlington, VA   22217-5000

Also, I'm ready to mail in my 25 bucks or whatever
when these enhancements are released.

Mike

From icon-group-request  Fri Feb 20 19:10:34 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: .2 + .2 = 4
Errors-To: icon-group-request
Status: RO

It's true that in the Icon book a decimal literal, a type of real constant,
is defined as:

    digit+ . digits*

but it seems to me that it's not hard to imagine someone writing something
like x := y * .9 and then being surprised that x = y * 9 .  I just did this
and must admit that I was mystified for an embarrassing length of time.

A quick look at tran/lex.c seems to indicate that this wouldn't be hard
to arrange -- if the current character is '.', peek at the next character
and if it's a digit, call getnum instead of gathering an operator.  getnum
would also need a little work, but considering the likelihood of others
falling over this (any victims out there?), it seems like a reasonable
thing to do.

From icon-group-request  Fri Feb 20 19:14:51 1987
From: "Ralph Griswold" <ralph>
To: icon-group, whm
Subject: Re:  .2 + .2 = 4
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

Since the unary prefix operator does dereferencing, there is a fundamental
ambiguity.  SNOBOL4 has it too.

I, for one, while I realize the pitfall, would have trouble with .2 and .x
(not to mention ."2") being treated in fundamentally different ways.

cheer up ... .2 + .2 = .4

From icon-group-request  Sat Feb 21 01:45:38 1987
To: [e-mail]
From: [e-mail]
Subject: Icon in Holland
Errors-To: icon-group-request
Status: RO

Date: 19 February 1987, 13:33:41 MET
From: Jan Blom                                       U249101  at HNYKUN11
To:   ICON-GROUP at ARIZONA.EDU

I'm glad to see that the Icon-group functions after all!
We use Icon here on a VAX/750 (VMS), and it also appears to run on
a Microvax II under MicroVMS.
I would like to know what implementations are available for Atari/ST and
MS/DOS machines, and how I can obtain them here in Europe (Holland).

                                                         Jan Blom

From icon-group-request  Sat Feb 21 06:13:19 1987
From: "Ralph Griswold" <ralph>
To: [e-mail], icon-group
Subject: Re:  Icon in Holland
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

Thanks for letting us know about your use of Icon.

Icon is available both for the Atari ST and for MS-DOS.

The Atari implementation is available for downloading frm the Atari Base BBS
in this country.  I don't know if there is a corresponding service in Europe.
We do not have an Atari ST locally and did not do the implementation of Icon
for it, so our ability to help you is limited.  I will, however, forward your
request to the person who did the implementation.

We distribute the MS-DOS implementation and I'll send you a recent Icon
Newletter describing how you can get this implementation from us.  We have
no "distributors" in Europe, although there are many persons there who
have Icon, including a good number in your country.

You raise a question that has come up several times -- how persons in countries
that are inconveniently distant from ours can get Icon locally.  We encourage
persons to install Icon on electronic bulletin boards and since the implement-
ations are in the public domain, anyone can serve as a distributor.  We would
welcome volunteers and will pass along information that we get about such
services.

From icon-group-request  Sat Feb 21 12:23:05 1987
From: "Gregg Townsend" <gmt>
To: icon-group
Subject: Re: .2 + .2 = 4
Errors-To: icon-group-request
Status: RO

I've also been bitten by the problem of trying to write a real as .nnn and
instead finding that I was really dereferencing an integer.  I had a little
one-shot program which went

    every r := 0 to 7 do
    every g := 0 to 7 do
        every b := 0 to 7 do
        write ((.30 * r + .59 * g + .11 * b) / 7.0)

and when the output began coming out

    0.0
    1.5714286
    3.1428571
    4.7142857
    6.2857143
       ...

I began wondering why I was getting multiples of pi/2.  Had I somehow connected
with some trigonometric functions?  After quite a bit of head-scratching I
figured out the real problem and realized that the red herring came from
inadvertent calculation of the common approximation of pi as a fraction,
namely 22/7.

I'd favor a change if it could be done cleanly.  I doubt that any existing
programs would be invalidated.  As for ambiguity, it's already there in people's
minds, and is resolved the wrong way.  In the statement
    off := .47
most people wouldn't notice "." as an operator any more than they'd notice that
the variable name begins with a reserved word.  People look at things in
context.

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

From icon-group-request  Sat Feb 21 13:03:29 1987
From: "Ralph Griswold" <ralph>
To: gmt, icon-group
Subject: Re: .2 + .2 = 4
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

Gregg has a good point about the more important ambiguity.  I'd be willing
to make the change if it is strictly limited to a period followed by a
digit meaning a real literal. (Documenting the syntax will be unpleasant,
however.)

Or, to be more accurate, I'll add it to the huge pile of things that ought
to be done to Icon.

I have a program that this change will affect.  Not that it's an important
program.  Can anyone guess what it might be?

As another exercise, would anyone care to catalog all the changes that
need to be made to distributed Icon material when/if this change is made?

From icon-group-request  Sat Feb 21 14:54:25 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: Re: .2 + .2 = 4
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

I thought about this some more and making .digits into a decimal literal
could be a bad idea since programs developed under the new version that
have constants of this type would then mysteriously malfunction when run on
earlier versions.

How about just arranging for .digits to produce a warning message?  This
would serve to alert the programmer to the problem, but wouldn't produce
any inter-version incompatibilities.  This could be done in either the
lexical analyzer or during the code generation tree walk.  The former would
allow `. n' to be used for `.n' and not draw a warning, but it might be
hard to localize the overhead for that check.  Checking during the tree
walk would probably be a little cleaner, but the `. n' ruse wouldn't work.

This approach would seem to require a minimum of changes outside the code --
just a note in the Version N document saying that .digits now produces a
warning.

Thus, in the worst case you have a program that generates warning messages
and in the best case, a programmer's sanity is saved.

From icon-group-request  Sun Feb 22 08:05:39 1987
From: "Mark L. Langley" <mark>
To: icon-group, whm
Subject: Re: .2 + .2 = 4
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

    From icon-group-request Sat Feb 21 14:54:39 1987
    Received: by megaron.arizona.edu; Sat, 21 Feb 87 14:54:27 MST
    Date: Sat, 21 Feb 87 14:54:25 MST
    From: "Bill Mitchell" <whm>

    I thought about this some more and making .digits into a decimal literal
    could be a bad idea since programs developed under the new version that
    have constants of this type would then mysteriously malfunction when run on
    earlier versions.

I think I disagree.  First of all, when was the last time you dereferenced
a constant?  Second when was the last time you dereferenced a constant
that began with a digit?  (Obviously you can't dereference a variable
that begins with a digit...)

I think one usually dereferences variables unless the object of the
program is to find bugs in the compiler.

Other languages enforce the "Floats must begin with a digit" rule, (ie
Pascal) but I always thought Icon was supposed to suggest improvements.
Furthermore the incompatible version argument has been violated before,
for example when versions of Icon were distributed without co-expressions.
And I don't think Icon is ready to have an ANSI standard...

From icon-group-request  Thu Feb 26 16:52:44 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: % operator
Errors-To: icon-group-request
Status: RO

I was just noticing that in the Icon book on page 20, n % m is defined
as being the remainder of n divided by m with the sign of m, but the
code that implements % just uses the C % operator and when a negative
operand is involved, different implementations of C do different things
when remaindering.

From icon-group-request  Wed Mar  4 10:40:17 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: fyi
In-Reply-To:
    From [e-mail] Wed Mar  4 10:35:45 1987
    Received: by megaron.arizona.edu; Wed, 4 Mar 87 10:35:43 MST
    Received: by arizona.arizona.edu; Wed, 4 Mar 87 10:34:46 MST
    Received: by nprdc.arpa (5.51/ 1.1)
        id AA13801; Wed, 4 Mar 87 09:35:17 PST
    Message-Id: <[e-mail]>
    Date: 4 March 1987 0935-PST (Wednesday)
    From: [e-mail]
    Reply-To: [e-mail]
    To: [e-mail]
    Subject: MS-DOS Icon goodies



    I received the hard-copy of Cheyenne Wills's notes.  Thanks.
    (You have my correct net address -- I guess
    something somewhere was just down.)

    One thing that us psychologists like to use microcomputers
    for is running experiments.  Reaction time is one of our
    favorite dependent variables.  Software evaluation is
    another area where people like to get fine-grained timing
    information in the microsecond to millisecond range.

    Three recent articles have pointed out that it is possible to
    use the IBM-PC and similar machines to get accurate
    microsecond-level times without any special hardware or
    software.  The three articles are the following:

    Smith, B., & Puckett, T.  (April, 1984).  Life in the
    fast lane.  PC Tech Journal, 63-74.

    Sheppard, B.  (January, 1987).  Programming insight:  High-
    performance software analysis on the IBM PC.  Byte, 12(1),
    157-168.

    Graves, R., & Bradley, R.  (Fedruary, 1987).  Millisecond
    interval timer and auditory reaction time programs for the IBM PC.
    Behavior Research Methods, Instruments, and Computers, 19(1), 30-35.


    All these articles use the same method:  The system timing
    chip is re-programmed (software programmable) to "Mode 2"
    rather than the BIOS setting of "Mode 3."

    Without getting into the mysteries of the timing chip and
    its associated ports and counters, suffice it to say that
    I've experimented extensively with this gimmick.  It does
    not require any assembly-level programming (contrary to
    what the articles above would suggest).  You can do it all
    with Turbo Pascal.

    Which brings me to my point:  Turbo Pascal has two
    capabilities which are not represented in Cheyenne's notes
    and which are necessary to get this no-fuss microsecond
    hardware timer:

    1)  The ability to read and write ports.  This is
    represented in Turbo Pascal as the pseudo-arrays Port and
    PortW.  You read a port by reading Port[i] & write a port
    by assigning a value to Port[i] (or PortW for 2-byte
    reads and writes).

    2)  A limited capability to exec
Status: RO

Errors-To: icon-group-request

ute in-line machine code.
    Specifically, CLI and STI instructions must be placed
    around the code that reads the memory locations which
    maintain the timer interrupt count.

    In addition, the Peek() function would be used.

    I realize that both of these "features" -- especially #2 --
    might be hard to justify as additions to MS-DOS Icon.  An
    alternative would be to implement three functions, say,
    time_start, time_stop, and delay.

    time_start would start a 1.19 Mh stopwatch, and subsequent
    references to &time would return the elapsed time in
    (floating-point) milliseconds since the call to time_start.
    The system clock would be operating in Mode 2 (fast,
    nonstandard).

    time_stop would stop the fast clock and re-set the system
    clock to Mode 3 (slow, 55-msec interrupts; BIOS standard
    setting);

    delay(n) would delay for n milliseconds.


    Potential problems:  I've found that it's important to
    run the clock in Mode 2 only when really necessary.  For
    some reason, the system tends to hang occasionally and'
    unpredictably when the clock is in Mode 2 (and i/o is
    performed? -- I still don't know the cause, but I do know
    that the problem can be managed for practical purposes and
    programs that use this feature can be highly reliable).

    Another problem -- having delay(n) call time_init
    and then monitor &time until it goes above n is not
    as good an idea as it might seem.  If this approach is
    used and there are a lot of "long" 1-2 sec delays in a
    run (as there would be in the typical psychological
    experiment) the hang-up problem emerges.  Thus, the
    practical approach is to calibrate a loop (figure out
    how many iterations are required to produce the
    desired delay -- using the fast clock for the calibration
    only), then use the calibrated loop to produce the
    actual delays during long runs.

    I know this is special pleading for psychologists -- but
    maybe there is enough interest among software people to
    justify some kind of fast-clock feature in MS-DOS
    Icon.

    Mike Shafto

    PS:  I fogot another problem I've found:
    KayPro PC's and perhaps some others have a 4.77Mh/8 Mh
    dual clock-speed option controlled by a toggle switch.
    If the 8 Mh, nonstandard clock option is in effect, the
    timer routines cited above go to hell.

    mgs


From icon-group-request  Wed Mar  4 11:24:11 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: bogus mail
Errors-To: icon-group-request
Status: RO

For some as yet unknown reason, a portion of a message that I was
remailing to persons here on the Icon Project wound up in the
outgoing icon-group mail.  It's subject is "fyi" and its
contents will no doubt appear mysterious.  Ignore it.

My apologies for the bother.

From icon-group-request  Wed Mar  4 12:56:04 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: micro- to millisecond timing in MS-DOS Icon?
Cc: [e-mail]
Errors-To: icon-group-request
Status: RO

NOTE:  THIS IS A REBROADCAST OF A NOTE THAT I SENT TO
RALPH GRISWOLD.  PART OF THAT PREVIOUS MESSAGE WAS ACCIDENTALLY
DISTRIBUTED TO ICON-GROUP.

MGS


One thing that us psychologists like to use microcomputers
for is running experiments.  Reaction time is one of our
favorite dependent variables.  Software evaluation is
another area where people like to get fine-grained timing
information in the microsecond to millisecond range.

Three recent articles have pointed out that it is possible to
use the IBM-PC and similar machines to get accurate
microsecond-level times without any special hardware or
software.  The three articles are the following:

Smith, B., & Puckett, T.  (April, 1984).  Life in the
fast lane.  PC Tech Journal, 63-74.

Sheppard, B.  (January, 1987).  Programming insight:  High-
performance software analysis on the IBM PC.  Byte, 12(1),
157-168.

Graves, R., & Bradley, R.  (Fedruary, 1987).  Millisecond
interval timer and auditory reaction time programs for the IBM PC.
Behavior Research Methods, Instruments, and Computers, 19(1), 30-35.


All these articles use the same method:  The system timing
chip is re-programmed (via software) to "Mode 2"
rather than the BIOS setting of "Mode 3."

Without getting into the mysteries of the timing chip and
its associated ports and counters, suffice it to say that
I've experimented extensively with this gimmick.  It does
not require any assembly-level programming (contrary to
what the articles above would suggest).  You can do it all
with Turbo Pascal.

(You have to cheat and use the Turbo inline() function
in order to disable and enable interrupts -- see below).


Which brings me to my point:  Turbo Pascal has two
capabilities which are not represented in
the working notes for additions to MS-DOS Icon (Cheyenne Wills)
and which are necessary to get this no-fuss microsecond
hardware timer:

1)  The ability to read and write ports.  This is
represented in Turbo Pascal as the pseudo-arrays Port and
PortW.  You read a port by referencing Port[i] & write a port
by assigning a value to Port[i] (or PortW[i] for 2-byte
reads and writes).

2)  A limited capability to execute in-line machine code.
Specifically, CLI and STI instructions must be placed
around the code that reads the memory locations which
maintain the timer interrupt count.

In addition, the Peek() function would be used.

I realize that both of these "features" -- especially #2 --
might be hard to justify as additions to MS-DOS Icon.  An
alternative would be to implement three functions, say,
time_start, time_stop, and delay.

time_start would start a 1.19 Mh stopwatch, and subsequent
references to &time would return the elapsed time in
(floating-point) milliseconds since the call to time_start.
The system clock would be operating in Mode 2 (fast,
nonstandard).

time_stop would stop the fast clock and re-set the system
clock to Mode 3 (slow, 55-msec interrupts; BIOS standard
setting);

delay(n) would delay for n milliseconds.


Potential problems:  I've found that it's important to
run the clock in Mode 2 only when really necessary.  For
some reason, the system tends to hang occasionally and'
unpredictably when the clock is in Mode 2 (and i/o is
performed? -- I still don't know the cause, but I do know
that the problem can be managed for practical purposes and
programs that use this feature can be highly reliable).

Another problem -- having delay(n) call time_init
and then monitor &time until it goes above n is not
as good an idea as it might seem.  If this approach is
used and there are a lot of "long" 1-2 sec delays in a
run (as there would be in the typical psychological
experiment) the hang-up problem emerges.  Thus, the
practical approach is to calibrate a loop (figure out
how many iterations are required to produce the
desired delay -- using the fast clock for the calibration
only), then use the calibrated loop to produce the
actual delays during long runs.
This might mean that the delay() function is not a good
candidate for a built-in function & should be implemented
and calibrated as a user-defined function.
I've been using the hardware clock on my PC to
calibrate the built-in delay procedure in Turbo.

I know this is special pleading for psychologists -- but
maybe there is enough interest among software people to
justify some kind of fast-clock feature in MS-DOS
Icon.

Mike Shafto

PS:  I forgot another problem I've found:
KayPro PC's and perhaps some others have a 4.77Mh/8 Mh
dual clock-speed option controlled by a toggle switch.
If the 8 Mh, nonstandard clock option is in effect, the
timer routines cited above go to hell.

mgs


From icon-group-request  Wed Mar  4 16:18:27 1987
From: "David Gudeman" <gudeman>
To: icon-group
Subject: proof-reader
Errors-To: icon-group-request
Status: RO

I've been thinking about writing a proof-reading program in Icon.
The program would check spelling, punctuation, word choice, phrase
choice, sentence structure, and paragraph structure.  It would need to
store an entire English dictionary in a table cross-referenced with
various information such as synonyms, syntactic category, aesthetic
quality, etc.  I think that such a program would be very useful for us
careless writers.

This is a fairly major project, and I am hoping for some opinion on
the feasibility and best procedure.  Also, does anyone know of other
programs that do this?  (I am aware of the Unix utilities.)  I would
also like to find a dictionary that is already on a computer.  I know
about word-lists, I need a dictionary with syntactic category and
synonym information.

Here is my general idea.  I guess (without much evidence) that there
are less than 256 legal syllables in English words.  If this is the
case, then it is possible to represent words as strings where each
character represents a whole syllable.  Otherwise (if there are too
many syllables for this), words could be represented as lists of
strings where each string is a syllable.

The reason I want to represent words as strings of syllables is to
help in identifying misspelled words.  When a word is not recognized,
the program will try replacing syllables with other syllables that
might represent the same sound, then check if that is a real word.  If
syllables can be represented as characters, then I could use csets to
represent equivalence classes of syllables.

English sentences could be parsed as a context-sensitive grammar,
incomplete of course, but I think I could get one complete enough for
most sentences that are written in semi-formal style.  To detect
errors in sentence structure and punctuation, I need information on
what kinds of errors are most often made.  Then I can include these
errors in the grammar as a kind of error production.

The program will have to read words, selecting one syntactic category
for those words that have multiple categories.  If the sentence cannot
be parsed, the program must backtrack to the selection point and chose
a different syntactic category for the word.  In other words, the
program must be able force backtracking of lexical analysis by failure
in syntactic analysis.

Even more difficult than this, I have to specify some sort of grammar
to describe paragraphs.  It is not enough to say that a paragraph is a
sequence of sentences.  There must be some sort of context similarity
in the sentences of a paragraph.  I don't know whether this is
formally specifiable, but I would like to try.

More questions: Is Icon going to be able to handle all of this without
spending ten minutes on each paragraph?  Do I need to change Icon's
internal table functions to make this sort of program efficient?  Has
anyone done something similar in Icon?



From icon-group-request  Wed Mar  4 18:25:40 1987
From: "Ralph Griswold" <[e-mail]>
To: [e-mail]
Subject: bogus mail
Errors-To: [e-mail]
Errors-To: icon-group-request
Status: RO

For some as yet unknown reason, a portion of a message that I was
remailing to persons here on the Icon Project wound up in the
outgoing icon-group mail.  It's subject is "fyi" and its
contents will no doubt appear mysterious.  Ignore it.

My apologies for the bother.


From icon-group-request  Wed Mar  4 18:39:17 1987
From: "David Gudeman" <[e-mail]>
To: [e-mail]
Subject: proof-reader
Errors-To: [e-mail]
Errors-To: icon-group-request
Status: RO

I've been thinking about writing a proof-reading program in Icon.
The program would check spelling, punctuation, word choice, phrase
choice, sentence structure, and paragraph structure.  It would need to
store an entire English dictionary in a table cross-referenced with
various information such as synonyms, syntactic category, aesthetic
quality, etc.  I think that such a program would be very useful for us
careless writers.

This is a fairly major project, and I am hoping for some opinion on
the feasibility and best procedure.  Also, does anyone know of other
programs that do this?  (I am aware of the Unix utilities.)  I would
also like to find a dictionary that is already on a computer.  I know
about word-lists, I need a dictionary with syntactic category and
synonym information.

Here is my general idea.  I guess (without much evidence) that there
are less than 256 legal syllables in English words.  If this is the
case, then it is possible to represent words as strings where each
character represents a whole syllable.  Otherwise (if there are too
many syllables for this), words could be represented as lists of
strings where each string is a syllable.

The reason I want to represent words as strings of syllables is to
help in identifying misspelled words.  When a word is not recognized,
the program will try replacing syllables with other syllables that
might represent the same sound, then check if that is a real word.  If
syllables can be represented as characters, then I could use csets to
represent equivalence classes of syllables.

English sentences could be parsed as a context-sensitive grammar,
incomplete of course, but I think I could get one complete enough for
most sentences that are written in semi-formal style.  To detect
errors in sentence structure and punctuation, I need information on
what kinds of errors are most often made.  Then I can include these
errors in the grammar as a kind of error production.

The program will have to read words, selecting one syntactic category
for those words that have multiple categories.  If the sentence cannot
be parsed, the program must backtrack to the selection point and chose
a different syntactic category for the word.  In other words, the
program must be able force backtracking of lexical analysis by failure
in syntactic analysis.

Even more difficult than this, I have to specify some sort of grammar
to describe paragraphs.  It is not enough to say that a paragraph is a
sequence of sentences.  There must be some sort of context similarity
in the sentences of a paragraph.  I don't know whether this is
formally specifiable, but I would like to try.

More questions: Is Icon going to be able to handle all of this without
spending ten minutes on each paragraph?  Do I need to change Icon's
internal table functions to make this sort of program efficient?  Has
anyone done something similar in Icon?




From icon-group-request  Wed Mar  4 18:54:14 1987
From: "Ralph Griswold" <[e-mail]>
To: [e-mail]
Subject: fyi
In-Reply-To:
        From [e-mail] Wed Mar  4 10:35:45 1987
        Received: by megaron.arizona.edu; Wed, 4 Mar 87 10:35:43 MST
        Received: by arizona.arizona.edu; Wed, 4 Mar 87 10:34:46 MST
        Received: by nprdc.arpa (5.51/ 1.1)
                id AA13801; Wed, 4 Mar 87 09:35:17 PST
        Message-Id: <[e-mail]>
        Date: 4 March 1987 0935-PST (Wednesday)
        From: [e-mail]
        Reply-To: [e-mail]
        To: [e-mail]
        Subject: MS-DOS Icon goodies
Errors-To: icon-group-request
Status: RO



        I received the hard-copy of Cheyenne Wills's notes.  Thanks.
        (You have my correct net address -- I guess
        something somewhere was just down.)

        One thing that us psychologists like to use microcomputers
        for is running experiments.  Reaction time is one of our
        favorite dependent variables.  Software evaluation is
        another area where people like to get fine-grained timing
        information in the microsecond to millisecond range.

        Three recent articles have pointed out that it is possible to
        use the IBM-PC and similar machines to get accurate
        microsecond-level times without any special hardware or
        software.  The three articles are the following:

        Smith, B., & Puckett, T.  (April, 1984).  Life in the
        fast lane.  PC Tech Journal, 63-74.

        Sheppard, B.  (January, 1987).  Programming insight:  High-
        performance software analysis on the IBM PC.  Byte, 12(1),
        157-168.

        Graves, R., & Bradley, R.  (Fedruary, 1987).  Millisecond
        interval timer and auditory reaction time programs for the IBM PC.
        Behavior Research Methods, Instruments, and Computers, 19(1), 30-35.


        All these articles use the same method:  The system timing
        chip is re-programmed (software programmable) to "Mode 2"
        rather than the BIOS setting of "Mode 3."

        Without getting into the mysteries of the timing chip and
        its associated ports and counters, suffice it to say that
        I've experimented extensively with this gimmick.  It does
        not require any assembly-level programming (contrary to
        what the articles above would suggest).  You can do it all
        with Turbo Pascal.

        Which brings me to my point:  Turbo Pascal has two
        capabilities which are not represented in Cheyenne's notes
        and which are necessary to get this no-fuss microsecond
        hardware timer:

        1)  The ability to read and write ports.  This is
        represented in Turbo Pascal as the pseudo-arrays Port and
        PortW.  You read a port by reading Port[i] & write a port
        by assigning a value to Port[i] (or PortW for 2-byte
        reads and writes).

        2)  A limited capability to e


Errors-To: icon-group-request

ute in-line machine code.
        Specifically, CLI and STI instructions must be placed
        around the code that reads the memory locations which
        maintain the timer interrupt count.

        In addition, the Peek() function would be used.

        I realize that both of these "features" -- especially #2 --
        might be hard to justify as additions to MS-DOS Icon.  An
        alternative would be to implement three functions, say,
        time_start, time_stop, and delay.

        time_start would start a 1.19 Mh stopwatch, and subsequent
        references to &time would return the elapsed time in
        (floating-point) milliseconds since the call to time_start.
        The system clock would be operating in Mode 2 (fast,
        nonstandard).

        time_stop would stop the fast clock and re-set the system
        clock to Mode 3 (slow, 55-msec interrupts; BIOS standard
        setting);

        delay(n) would delay for n milliseconds.


        Potential problems:  I've found that it's important to
        run the clock in Mode 2 only when really necessary.  For
        some reason, the system tends to hang occasionally and'
        unpredictably when the clock is in Mode 2 (and i/o is
        performed? -- I still don't know the cause, but I do know
        that the problem can be managed for practical purposes and
        programs that use this feature can be highly reliable).

        Another problem -- having delay(n) call time_init
        and then monitor &time until it goes above n is not
        as good an idea as it might seem.  If this approach is
        used and there are a lot of "long" 1-2 sec delays in a
        run (as there would be in the typical psychological
        experiment) the hang-up problem emerges.  Thus, the
        practical approach is to calibrate a loop (figure out
        how many iterations are required to produce the
        desired delay -- using the fast clock for the calibration
        only), then use the calibrated loop to produce the
        actual delays during long runs.

        I know this is special pleading for psychologists -- but
        maybe there is enough interest among software people to
        justify some kind of fast-clock feature in MS-DOS
        Icon.

        Mike Shafto

        PS:  I fogot another problem I've found:
        KayPro PC's and perhaps some others have a 4.77Mh/8 Mh
        dual clock-speed option controlled by a toggle switch.
        If the 8 Mh, nonstandard clock option is in effect, the
        timer routines cited above go to hell.

        mgs



From icon-group-request  Wed Mar  4 18:55:46 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: micro- to millisecond timing in MS-DOS Icon?
Cc: [e-mail]
Errors-To: [e-mail]
Errors-To: icon-group-request
Status: RO

NOTE:  THIS IS A REBROADCAST OF A NOTE THAT I SENT TO
RALPH GRISWOLD.  PART OF THAT PREVIOUS MESSAGE WAS ACCIDENTALLY
DISTRIBUTED TO ICON-GROUP.

MGS


One thing that us psychologists like to use microcomputers
for is running experiments.  Reaction time is one of our
favorite dependent variables.  Software evaluation is
another area where people like to get fine-grained timing
information in the microsecond to millisecond range.

Three recent articles have pointed out that it is possible to
use the IBM-PC and similar machines to get accurate
microsecond-level times without any special hardware or
software.  The three articles are the following:

Smith, B., & Puckett, T.  (April, 1984).  Life in the
fast lane.  PC Tech Journal, 63-74.

Sheppard, B.  (January, 1987).  Programming insight:  High-
performance software analysis on the IBM PC.  Byte, 12(1),
157-168.

Graves, R., & Bradley, R.  (Fedruary, 1987).  Millisecond
interval timer and auditory reaction time programs for the IBM PC.
Behavior Research Methods, Instruments, and Computers, 19(1), 30-35.


All these articles use the same method:  The system timing
chip is re-programmed (via software) to "Mode 2"
rather than the BIOS setting of "Mode 3."

Without getting into the mysteries of the timing chip and
its associated ports and counters, suffice it to say that
I've experimented extensively with this gimmick.  It does
not require any assembly-level programming (contrary to
what the articles above would suggest).  You can do it all
with Turbo Pascal.

(You have to cheat and use the Turbo inline() function
in order to disable and enable interrupts -- see below).


Which brings me to my point:  Turbo Pascal has two
capabilities which are not represented in
the working notes for additions to MS-DOS Icon (Cheyenne Wills)
and which are necessary to get this no-fuss microsecond
hardware timer:

1)  The ability to read and write ports.  This is
represented in Turbo Pascal as the pseudo-arrays Port and
PortW.  You read a port by referencing Port[i] & write a port
by assigning a value to Port[i] (or PortW[i] for 2-byte
reads and writes).

2)  A limited capability to execute in-line machine code.
Specifically, CLI and STI instructions must be placed
around the code that reads the memory locations which
maintain the timer interrupt count.

In addition, the Peek() function would be used.

I realize that both of these "features" -- especially #2 --
might be hard to justify as additions to MS-DOS Icon.  An
alternative would be to implement three functions, say,
time_start, time_stop, and delay.

time_start would start a 1.19 Mh stopwatch, and subsequent
references to &time would return the elapsed time in
(floating-point) milliseconds since the call to time_start.
The system clock would be operating in Mode 2 (fast,
nonstandard).

time_stop would stop the fast clock and re-set the system
clock to Mode 3 (slow, 55-msec interrupts; BIOS standard
setting);

delay(n) would delay for n milliseconds.


Potential problems:  I've found that it's important to
run the clock in Mode 2 only when really necessary.  For
some reason, the system tends to hang occasionally and'
unpredictably when the clock is in Mode 2 (and i/o is
performed? -- I still don't know the cause, but I do know
that the problem can be managed for practical purposes and
programs that use this feature can be highly reliable).

Another problem -- having delay(n) call time_init
and then monitor &time until it goes above n is not
as good an idea as it might seem.  If this approach is
used and there are a lot of "long" 1-2 sec delays in a
run (as there would be in the typical psychological
experiment) the hang-up problem emerges.  Thus, the
practical approach is to calibrate a loop (figure out
how many iterations are required to produce the
desired delay -- using the fast clock for the calibration
only), then use the calibrated loop to produce the
actual delays during long runs.
This might mean that the delay() function is not a good
candidate for a built-in function & should be implemented
and calibrated as a user-defined function.
I've been using the hardware clock on my PC to
calibrate the built-in delay procedure in Turbo.

I know this is special pleading for psychologists -- but
maybe there is enough interest among software people to
justify some kind of fast-clock feature in MS-DOS
Icon.

Mike Shafto

PS:  I forgot another problem I've found:
KayPro PC's and perhaps some others have a 4.77Mh/8 Mh
dual clock-speed option controlled by a toggle switch.
If the 8 Mh, nonstandard clock option is in effect, the
timer routines cited above go to hell.

mgs



From icon-group-request  Wed Mar  4 23:47:34 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: duplicates
Errors-To: icon-group-request
Status: RO

We had a problem earlier today with several messages appearing twice,
but it has been corrected.  Sorry about that.

From icon  Wed Dec 31 11:37:36 1986
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: mathematics vs. computer science
Errors-To: icon-group-request
Status: RO



The Icon Newsletter (Number 23 -- February 3, 1987) contains
a puzzling statement on page 5 regarding the "Knuth method"
for shuffling a deck of cards:

"Whether or not this produces a 'good' shuffle is somewhat
of an open question, but it seems to work well in practice."

Perhaps this was intended as a subtle joke; if so, my
apologies.

In any case, it's easy to prove that the method produces a truly
random shuffle (if the Icon random number generator is truly
random).  A truly random shuffle is one in which any arbitrarily
chosen card (c) has a probability of 1/N of appearing in the
k-th position in the shuffled deck (N = number of cards in
deck; k in [1..N]).

Let c be any card in the original deck.  The first time through
the loop, c is moved to position N with probability 1/N; this
takes into account the possibility that c is already in position
N and is left there.

The probability that c is moved to position N-1 on the second
iteration is the product of two probabilities: the probability
that c was NOT moved to position N on the first pass; the
probability that it IS moved to position N-1 on the
second pass, i.e.,

((N-1)/N) * (1/(N-1)) = 1/N

The argument continues, leading to the conclusion that

the probability c ends up in the k-th position in the
shuffled deck is

((N-1)/N) * ((N-2)/(N-1)) * ... * ((N-k)/(N-k+1)) * (1/(N-k))

= 1/N


So if the random number generator is nice and uniform, the shuffle
is completely fair (completely random), and every possible permutation
of the cards is equally likely.

Mike Shafto

From icon  Tue Mar 10 13:13:13 1987
From: "David Gudeman" <gudeman>
To: icon-group
Subject: opendir for Icon
Errors-To: icon-group-request
Status: RO

Here are some useful procedures for Unix programming in Icon.  It
would be nice if there were also a procedure that runs "ls -dgl" on a
file and parses the output to create a record of file attributes.
I'll probably do that sometime, unless someone else does it first and
posts it to icon-group.  Procedures readfile() and tempfile() will
probably work on non-Unix machines.

# Return a set of all the file names in dir (except . and ..).  If
#   dir is not the name of a directory, fail.  If dir is not a string
#   or is "", then an error occurs.
#
procedure opendir(dir)
    local pipe, file_names, name_set, s

    (dir := string(dir), dir ~== "") |
        stop("opendir: ", image(dir), " is not a name")

    if dir[-1] ~== "/" then dir ||:= "/"
    pipe := open("echo " || dir || ".* " || dir || "*", "pr")
    file_names := readfile(pipe)
    close(pipe)

    if file_names[*dir+:3] == "/.*" then fail      # not a directory

    name_set := set([])
    file_names ?
    while s := tab(find(" ")) do {
        move(1)
        if s[-2:0] == "/." | s[-3:0] == "/.." then next
        insert(name_set, s)
        }
    return name_set
end
#Read the entire file, f, into a single string, and return the string.
# (the constant 1000000 may have to be reduced on machines with small
#   word sizes)
procedure readfile(f)
    local s

    s := ""
    while s ||:= reads(f,1000000)
    return s
end

# Find an unused file name beginning with prefix, open it for
#   writing, and return the file.  The name of the file can be found
#   with image(file)[6:-1].  If a temporary file cannot be found,
#   then an error occurs.
#
procedure tempfile(prefix)
    local name

    prefix ||:= map(&clock[4:0],":",".")
    (every name := prefix || (1 to 20) do
        close(open(name, "r")) | break) |
    stop("can't open a temporary file")
    return open(name, "c")
end

From icon  Tue Mar 10 14:44:19 1987
From: "Bill Mitchell" <whm>
To: gudeman
Subject: Re:  proof-reader
Cc: icon-group
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

AT&T's "Writer's Workbench" has some programs that supposedly do some
non-trivial sentence analysis, but I don't really have any more details at
my fingertips.  Is anyone on the list familar with the WWB programs?

Personally speaking, a tool that could just find omitted words would be
wonderful.

From icon  Tue Mar 10 14:49:57 1987
From: "Ralph Griswold" <ralph>
To: gudeman, whm
Subject: Re:  proof-reader
Cc: icon-group
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

    From icon Tue Mar 10 14:44:31 1987
    Received: by megaron.arizona.edu; Tue, 10 Mar 87 14:44:22 MST
    Date: Tue, 10 Mar 87 14:44:19 MST
    From: "Bill Mitchell" <whm>
    Message-Id: <[e-mail]>
    Received: by megaron.arizona.edu; Tue, 10 Mar 87 14:44:19 MST
    To: gudeman
    Subject: Re:  proof-reader
    Cc: icon-group
    In-Reply-To: <[e-mail]>
    Errors-To: icon-group-request

    AT&T's "Writer's Workbench" has some programs that supposedly do some
    non-trivial sentence analysis, but I don't really have any more details at
    my fingertips.  Is anyone on the list familar with the WWB programs?

    Personally speaking, a tool that could just find omitted words would be
    wonderful.


No doubt you'd like to start with an empty file and have it fill
in the document for you ...


From icon  Tue Mar 10 14:51:45 1987
From: "Ralph Griswold" <ralph>
To: whm
Subject: Re:  proof-reader
Cc: icon-group
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

IBM Research at Yorktown Heights has done a lot of work in this area.
Their system parses input text, does spelling and other checks, and
suggests corrections.  I don't know how much about their work is
in the public literature -- perhaps someone in icon-group knows and
will respond.

From icon-group-request  Tue Mar 10 15:20:05 1987
From: "Bill Mitchell" <whm>
To: ralph
Subject: Re:  proof-reader
Cc: icon-group
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

   From: "Ralph Griswold" <ralph>
   To: gudeman, whm
   Subject: Re:  proof-reader
   Cc: icon-group

   No doubt you'd like to start with an empty file and have it fill
   in the document for you ...

I'd be willing to supply the title of the document as the command line
argument, naturally.  The program would also need to be able to produce
at least 100 words a day.  Otherwise, would be faster for me to do it myself.

From icon-group-request  Tue Mar 10 16:31:50 1987
From: naucse!sbw (Steve Wampler)
To: arizona![e-mail]
Subject: Re:  mathematics vs. computer science
Cc: arizona!icon-group
Errors-To: icon-group-request
Status: RO

I'm not sure that the statement is one of whether the shuffle
produces a mathematically 'good' shuffle, but whether a
mathematically 'good' shuffle is a 'good' shuffle when
simulating shuffling a deck of playing cards.  That is,
normal human shuffling techniques do not typically produce
truly random shuffles.

From icon-group-request  Tue Mar 10 23:21:38 1987
From: amdcad![e-mail] (Andy Beals)
To: [e-mail]
Subject: article generator (whm)
Errors-To: icon-group-request
Status: RO

Have you looked at "markov3" by jbuck@epicen?  Perhaps someone could
re-implement it (or do better!) in icon?
    andy

From icon-group-request  Wed Mar 11 11:24:44 1987
From: ihnp4!iwsam!orf
Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf
To: arizona!icon-group
Subject: Re:  proof-reader
Errors-To: icon-group-request
Status: RO

>
>IBM Research at Yorktown Heights has done a lot of work in this area.
>Their system parses input text, does spelling and other checks, and
>suggests corrections.  I don't know how much about their work is
>in the public literature -- perhaps someone in icon-group knows and
>will respond.
>
I have used both the IBM "Proof" system (described above) and the
AT&T WWB programs. I don`t really know how much of the AT&T stuff
is in the "public domain" so I will confine my comments to the
I.B.M. system - which I thought was terrific!

The system I used was running on a mainframe and was a tool for their
technical writing department. The user interface was marvelous. It
would high-lite misspelled words (and words that were too "complicated"
for the education level of the expected audience of the document.)

A page at a time is displayed, and the user hits an arrow key to move
the cursor to the next hi-lited word.  A function key is then depressed
and a box (window) is displayed showing suggested spellings or authorized
replacements (synonyms). I was amazed because of all my misspellings,
the correct spelling was *always* one of the alternatives in the box.
To replace a word, a single key was hit corresponding to the number of
the alternative in the box.  It was very very good. A large document
can be "proofed" in a matter of minutes..

I was amazed to read a couple of years ago that IBM started marketing
this system on their PC's -- for $30 BUCKS!!!  I don't have an IBM
PC, but if it is 1/2 as good as the mainframe system, it is worth a
lot more than $30 bucks.. They call it "proof".

O. R. Fonorow
IW 1Z-261 x7173
iwsam!orf



From icon-group-request  Wed Mar 11 13:45:23 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: article generator (whm)
Cc: [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO



Check out RPOEM in Jim Gimpel's book
Algorithms in SNOBOL4 (Wiley, 1976?)


From icon-group-request  Wed Mar 11 13:48:17 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Re:  proof-reader
Cc: [e-mail], [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO



Someone who has done serious work on more semantically based
text parsing, especially technical material, is

Dr. David Kieras
[e-mail]


From icon-group-request  Wed Mar 11 13:51:19 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Re:  proof-reader
Cc: [e-mail], [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO



There's a lot of interest in applied text-processing research
at the Navy Personnel R&D Center, San Diego.

A good contact person, and old-time SNOBOLler, is
Dr. Wallace Wulfeck
[e-mail]


From icon-group-request  Wed Mar 11 13:54:54 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Re:  proof-reader
Cc: [e-mail], [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO



Here are two people with relevant knowledge:

Dr. Fred Chang
Pacific Bell
pdsfac!ptsfa!tricep!ptsrat!frc@sdcsvax

Dr. George Miller
Princeton University
princeton!mind![e-mail]


From icon-group-request  Wed Mar 11 15:44:25 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Re:  proof-reader
Cc: [e-mail], [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO



Someone who has done serious work on more semantically based
text parsing, especially technical material, is

Dr. David Kieras
[e-mail]


From icon-group-request  Wed Mar 11 15:55:10 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: proof-readers and such
Errors-To: icon-group-request
Status: RO

A friend at IBM Reseach sent me the following information from their
brochure "Computer Science at the Thomas J. Watson Research Center":

The CRITIQUE Advanced Text Critiquing System

CRITIQUE is an experimental system that aids in the preparation of written
text. It is based on state-of-the-art natural language processing techniques
and combines theoretical work in computational linguistics with practical
work in systems design.  It currently diagnoses about 25 grammar errors, such
as subject-verb number disagreement and wrong case of pronouns, and diagnoses
about 50 style errors, such as split infinitives and too many premodifiers in
a noun phrase. The system also can provide about 40 word and phrase critiques,
such as misspelled words, and it produces about 50 summary analysis critiques,
including the Flesch/Kincaid readability score.

The central component of CRITIQUE is a natural language parser and its
associated English grammar, both of which are written in PLNLP (Programming
Language for Natural Language Processing), developed at IBM Research.
PLNLP is a procedural programming language, with LISP-style semantics, and
a rule language for writing grammars. The PLNLP English Grammar (PEG) is a
broad-coverage, computational grammar of ordinary English, with special
features for detecting common grammatical errors. It consists of about 250
rules, which comprise about 7,000 lines of PLNLP code. An on-line dictionary
of over 100,000 entries gives it an essentially unlimited vocabulary.

From icon-group-request  Wed Mar 11 16:14:20 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Re:  proof-reader
Cc: [e-mail], [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO



There's a lot of interest in applied text-processing research
at the Navy Personnel R&D Center, San Diego.

A good contact person, and old-time SNOBOLler, is
Dr. Wallace Wulfeck
[e-mail]


From icon-group-request  Wed Mar 11 16:44:22 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Re:  proof-reader
Cc: [e-mail], [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO



Here are two people with relevant knowledge:

Dr. Fred Chang
Pacific Bell
pdsfac!ptsfa!tricep!ptsrat!frc@sdcsvax

Dr. George Miller
Princeton University
princeton!mind![e-mail]


From icon-group-request  Sat Mar 21 08:50:34 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: pattern words
Errors-To: icon-group-request
Status: RO

Here is a simple problem in string manipulation that you might try
to program in Icon.

The "pattern" for a word (take a word to be a string of letters
for simplicity) displays its structure by representing all
occurrences of the first letter of the word by "a", all the
occurrences of the second letter of the word by "b", and so on.
Thus, the pattern of "proposals" is "abcacdefd".

The problem is to write a procedure whose argument is a word and
whose value is the corresponding pattern.  Assume the argument
consists of letters if you wish, although the problem clearly
generalizes to any string of characters.  For simplicity,
assume that upper- and lowercase letters are distinct. You can
assume that no more that 26 distinct characters occur in the word,
corresponding to the pattern characters "a", "b", ..., "z", although
there again are obvious generalizations.

Aim for clarity and the best use of the features of Icon, but don't
ignore efficiency (imagine your procedure is going to be used on a
large word list).

Lest you think this problem is totally frivilous, two books of
pattern words are currently being offered by the Aegean Park Press,
a company that sells a large selection of works on cryptography.


From icon-group-request  Tue Mar 24 12:27:28 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: an object of ridicule for group amusement
Errors-To: icon-group-request
Status: RO



I'll bite.  Here's my response to Ralph Griswold's
problem of 21 March:


procedure pattern(x)
    static letters,cletters,rep,corep
    initial {
        letters := &lcase || &ucase
        cletters := cset(letters)
        rep := &cset[0-:*letters]
        corep := create !rep
        }
    corep := ^corep
    while x := map(x, x[upto(cletters,x)], @corep)
    return map(x, rep, letters)
end


From icon-group-request  Tue Mar 24 12:28:08 1987
From: vijay <[e-mail]>
Subject: Re: pattern words
To: [e-mail]
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

There is considerable similarity in the elegance, economy of concepts,
the use of generators, pattern matching driven control structures etc
in ICON and in logic programming languages. Perhaps some of you may be
interested in a simple solution to Prof. Griswold's little programming exercise
in Prolog --- no specific features of Prolog are used, and with very minor
modifications the program is a valid CP(!,|) (which is a concurrent logic
programming language) program in which considerable use of pipelining
is made.

The basic idea is to use a symbol table to identify repetitions of chars in
the input word. In detail, with every character C[i] (say, 1 =< i =< n)
in the input word, we associate a distinct variable V[i], which is initially
unbound, but will ultimately be bound to the translation of C[i], i.e.
the pattern of the input word will be V[i] (1 =< i =< n).

Having initially created a list V of n unbound variables,
we need to do two things: first we need to unify
two variables V[i] and V[j] iff C[i] and C[j] are the same character; and then
we need to pair off the variables V[i] with the list of
the alphabet letters, unifying V[i] with the next available alphabet if V[i]
is not already bound, and doing nothing if V[i] is already bound.

For example, consider the word C='proposals'. We create V as the list
[V1, V2, V3, V4, V5, V6, V7, V8, V9] (9 distinct variables). Now, because
C[1]=C4], we unify V1 with V4. Similarly we unify V3 with V5 and V6 with V9.
This causes the list V to become [V1, V2, V3, V1, V3, V6, V7, V8, V6].
Now we pair up the elements in V1 with the list [a, b, c, ... z]. V1 pairs
up with a, V2 with b, V3 with c. V4 is already unified with V1, which is
already unified with a. Hence we skip it and look at V5, which is bound to
V3, which is bound to c, and is also skipped. V6 next becomes bound to d, and
so on, causing V to become 'abcacdefd'.

There remains the question of figuring out the values of i and j such that
C[i]=C[j].  For this we use a symbol table. For every character C[i], we insert
the pair alpha(C[i], V[i]) in the symbol table. If subsequently, the pair
alpha(C[j], V[j]) is inserted such that C[i]=C[j], V[i] and V[j] will be
automatically unified.

Here is the program: we iterate down the characters in Word, pairing
each with a fresh variable (the list of fresh variables is Pattern), inserting
the pair alpha(Char, Out_Char) in Sym_Table producing  New_Sym_Table, and
having done this for all the characters in the input word, alphabetizing
the list Pattern.

pattern(Word, Pattern):-
  pattern(Word, Null_Sym_Table, Pattern), alphabetize(Pattern).
pattern([Char | Word], Sym_Table, [Out_char | Pattern]):-
  insert(alpha(Char, Out_char), Sym_Table, New_Sym_Table),
  pattern(Word, New_Sym_Table, Pattern).
pattern([], Sym_Table, []).

To alphabetize List, we pick up A (the list of alphabets), and pair List with
A. The pairing operation consists of taking the next 'variable' in List and
unifying it with the next letter in A. If this succeeds then continue with the
tail of the two lists. Else, skip the variable in List becuase it already has a
value. Continue until there are no more 'variables' left in List.

alphabetize(List):- alphabet(A), pair(List, A).
pair([],A).
pair([Char | List], [Letter | Alphabets]):- pair(List, Alphabets).
pair([Char | List], [Letter | Alphabets]):-
 Char \== Letter, pair(List, [Letter | Alphabets]).

alphabet([a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z]).

It remains to define the insert operation on the symbol-table. The best
way to implement a symbol table in Prolog (that I know of) is to use the
Sleator and Tarjan splay trees. For those of you interested in details,
I am posting the (simple!) program  on the Prolog Digest. For this example
it will suffice to use a simple list as a symbol table:

insert(alpha(Char, OutChar), Table, Table):-
  Table = [alpha(Char, OutChar) | Rest].
insert(alpha(Char, OutChar), Table, Table):-
  Table = [alpha(Char_1, Out1) | Rest]
  Char \== Char_1, insert(alpha(Char, OutChar), Rest,).


This is the entire program: it will run on any Dec-10/20  Prolog system.

Vijay Saraswat.

-------

From icon-group-request  Tue Mar 24 14:18:54 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: somewhat faster pattern procedure
Errors-To: icon-group-request
Status: RO



I believe this is 25-30% faster than my earlier effort.

procedure pattern(x)
    local rep
    static letters
    initial letters := &lcase || &ucase

    if *x = 0 then return ""
    rep := ""
    while rep ||:= x[upto(~rep,x)]
    return map(x, rep, letters[1+:*rep])
end

From icon-group-request  Tue Mar 24 14:44:36 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: pattern words
Errors-To: icon-group-request
Status: RO

Here is a solution that came to me personally from a member of icon-group
who prefers to be anonymous:

    To: [e-mail]
    Subject: word patterns
    Status: R

    How about: ?

    procedure pat(x)
      z:=reverse(x)
      z:=map(z,z,reverse(&ascii)[1:*z + 1])
      cz:=cset(z)
      return reverse(map(z,cz,map(cz,cz,&lcase[1:*cz + 1])))
    end

From icon-group-request  Wed Mar 25 07:39:31 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: Re: pattern words
Cc: [e-mail], [e-mail], [e-mail],
        [e-mail]
Errors-To: icon-group-request
Status: RO



Does it run or walk?


From icon-group-request  Wed Apr  1 03:20:34 1987
Return-Path: <kinner@wsu>
From: Bill Kinnersley  <[e-mail]>
To: [e-mail]
Errors-To: icon-group-request
Status: RO

    Here are some more observations and opinions about Icon.  I
have no qualifications except a) an intense interest in the
language and b) being a newcomer.  A newcomer may sometimes focus
on inconsistencies that an expert has already come to accept.
(And a cat may look at a king.)  Also, expressing controversial
opinions is a good way to encourage others to straighten you out!

    It seems to me that much of the Icon philosophy is a
duality: two levels of flow control.  In addition to the
conventional explicit flow: if-then-else, while-do and call-
return, Icon has added an implicit flow control: suspend, resume,
iterate and backtrack.  They parallel one another, and to some
extent they're interchangeable.  For example

    (A & B) | C

may be used (with qualifications) instead of

    if A then B else C

The parallelism is what makes the scheme logical and consistent,
while the qualifications are what make it worth having both.

    But there's something missing from the language that I'd
like to put back in.  Real, honest-to-gosh Booleans.  (No,
seriously.)  This is the one place where the two parallel tracks
have been allowed to intersect.  I think the important concept of
success-failure needs to be kept distinct from the even more
fundamental idea of true and false.  It's neat that they can be
treated as one, but we really need both.

    Booleans are everywhere in Computer Science.  There are
Boolean flags, Boolean arrays, Boolean matrices, and don't forget
some people use bit fields.  Hey, I might even want to generate a
result sequence of Booleans.  Should a modern language like Icon
really force us to simulate Booleans with integer 0's and 1's?
Or strings "0" and "1"?  Or "true" and "false"?  Did you ever try
to XOR "01001" with "11100"?

    Implicit flow control is useful in a restricted class of
programming problems, but where it does apply, it is very useful.
On the other hand it can be tricky to get right, and this is
where being a novice comes in.

    A problem I repeatedly run up against is the rule delimiting
resumption.  In Icon, backtracking is limited to an expression.
The result is that expressions are sometimes forced to become
overly complex.  This distorts the appearance of our programs and
makes their intended action quite subtle.  We may need to cram as
much as possible into one poor expression.  (And it can't even be
compound.)

Exhibit A:

    "If a procedure fails, its arguments are resumed", so we
write C(B(A())) and claim it's because we *like* to be concise!

Exhibit B:

    Instead of {A(); B(); C()} we may need to write A() & B() &
C().  I guess this is not too bad if you think of the & as a sort
of "reversible semicolon".

Exhibit C:

    When a procedure is resumed, the resumption starts with the
expression following the suspend.  In order to make use of data
backtracking therefore, much of your procedure may have to be
written in that single expression:

    suspend(A <- B & C <- D & E <- F & G <- H)

    The issue here is not one of style.  Not even clarity.  The
issue is designing the language to let the power come through
without forcing your program to stand on its head.  The cleaner
it looks, the more people will use it.  Any suggestions?

    Here are some minor wishes:

1) Empty if-then-else clauses.  We can say

    break ;                 # empty, producing &null

and

    return ;        # empty, producing &null

We should be able (currently illegal) to say

    if A then B else ;        # if A fails, produces &null

    if A then ; else B        # similarly

2) Tables.

    !t generates the entries of a table.  There needs to be a
way of generating the *keys*.  As it is, I use sort() to produce
a list of pairs, then pick the keys out of that by hand.  (Since
tables are in principle unordered, perhaps the keys in a table
should be made available as a set.)

3) Built-in functions

    I still say we need:

a)    all P(1 to n)        # P(1) & P(2) & ... & P(n)

and

b)    any P(1 to n)        # P(1) | P(2) | ... | P(n)

I've tried simulating them with procedures, and come close, but
only close.



From icon-group-request  Wed Apr  1 15:53:55 1987
From: "David Gudeman" <gudeman>
To: [e-mail]
In-Reply-To: Bill Kinnersley's message of Tue, 31 Mar 87 11:39:55 PST
Subject: Suggestions for Icon
Errors-To: icon-group-request
Status: RO

   Date: Tue, 31 Mar 87 11:39:55 PST
   From: Bill Kinnersley  <[e-mail]>
   Errors-To: icon-group-request

       It seems to me that much of the Icon philosophy is a
   duality: two levels of flow control.  In addition to the
   conventional explicit flow: if-then-else, while-do and call-
   return, Icon has added an implicit flow control: suspend, resume,
   iterate and backtrack.

That's an interesting point, it corresonds to my idea that Icon
contains two different "paradigms": the procedural paradigm and the
goal-directed paradigm.  Icon also incorporates the functional
paradigm, in the sense that expressions return values.  (This may seem
like a peculiar way to define the functional paradigm, but notice that
pure procedural languages, pure goal-directed languages, pure logic
languages, etc. _don't_ have expressions that return values.)

       But there's something missing from the language that I'd
   like to put back in.  Real, honest-to-gosh Booleans.  (No,
   seriously.)  This is the one place where the two parallel tracks
   have been allowed to intersect.  I think the important concept of
   success-failure needs to be kept distinct from the even more
   fundamental idea of true and false.  It's neat that they can be
   treated as one, but we really need both.

Actually, success/failure is not meant to take the place of the
boolean data type.  It's just that it's not obvious that control
structures should be driven by booleans rather than something else.
Lisp uses null/`any other value', C uses 0/`any other value', Pascal
uses True/False.  The Pascal solution is actually the _least_ useful,
and was chosen more for security than for expressiveness.  The Icon
solution has its disadvantages, but it seems to fit the language very
well.

If I need a boolean that will be used to drive control structures, I
usually use &null for false and "" for true.  Then if x is the
variable containing one of these two values, I can write

    if \x then ...

When I do this a lot, I even get to the point where I can remember
which of the unary \ and / operators does what.  Here is how I would
add booleans to Icon: add the keyword &true, which returns a unique
object like &null.  Add the keyword &false which is identical to
&null.  Add the function boolean(x) which returns x if it is &null or
&true, and fails otherwise.  Would that be sufficient?

       A problem I repeatedly run up against is the rule delimiting
   resumption.  In Icon, backtracking is limited to an expression.
   The result is that expressions are sometimes forced to become
   overly complex.  This distorts the appearance of our programs and
   makes their intended action quite subtle.  We may need to cram as
   much as possible into one poor expression.  (And it can't even be
   compound.)

Try using the mutual-evaluation operator ",".  It has to occur inside
parentheses, but otherwise it does pretty much what you seem to want.
It would be possible to take make _all_ Icon expressions backtrack
into previous expressions, but this would make programs much more
interconected and much harder to understand.

       Here are some minor wishes:

   1) Empty if-then-else clauses.  We can say
   We should be able (currently illegal) to say

       if A then B else ;        # if A fails, produces &null

       if A then ; else B        # similarly

   2) Tables.

       !t generates the entries of a table.  There needs to be a
   way of generating the *keys*.

Ditto for me, I think we need both of these.

   3) Built-in functions

   b)    any P(1 to n)        # P(1) | P(2) | ... | P(n)

Will (i := 1 to n, P(i)) work?

We also need a control structure:

    E1 reduce E2

where E1 returns a binary function, and the results of E2 are combined
pairwise with the function.  For example

    "+" reduce !"123"  ==>  "+"("+"("1","2"),"3")  ==> 1+2+3  ==> 6
    "||" reduce 1 to 3  ==> "||"("||"(1,2),3) ==> 1 || 2 || 3 ==> "123"

From icon-group-request  Wed Apr  1 16:00:24 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: control structures
Errors-To: icon-group-request
Status: RO


A small comment:  the result sequence for P(1 to n) is the same as
the result sequence for P(1) | P(2) | ... | P(n) (assuming no bizzare
side effects).

Result sequences, which represent the *capability* of expressions to
produce results, are very useful in understanding generative control
structures and how to formulate programs using generators.  We have
a technical report that discusses them (TR 85-25, Programming with
Generators).  We'll be happy to send a copy to anyone who does not
already have it -- just mail your *postal* address to me.

    [e-mail]

    Ralph Griswold

From icon-group-request  Thu Apr  2 11:39:33 1987
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: Suggestions for Icon
Errors-To: icon-group-request
Status: RO

    Date: Tue, 31 Mar 87 11:39:55 PST
    From: Bill Kinnersley  <[e-mail]>

        It seems to me that much of the Icon philosophy is a
    duality: two levels of flow control.  In addition to the
    conventional explicit flow: if-then-else, while-do and call-
    return, Icon has added an implicit flow control: suspend, resume,
    iterate and backtrack.

I tend to view sequential execution with backtracking as the underlying
control mechanism of Icon. The various control structures: ";",
if-then-else, while-do, etc. are added on top of this underlying
mechanism to give added control over it and to add to the expressive
power of the language. Most of these control structures were inspired
by counter parts in traditional languages, but if you look closely at
what there are doing, they are different - indeed, in the presence of
backtracking they must be.


        But there's something missing from the language that I'd
    like to put back in.  Real, honest-to-gosh Booleans.  (No,
    seriously.)  This is the one place where the two parallel tracks
    have been allowed to intersect.  I think the important concept of
    success-failure needs to be kept distinct from the even more
    fundamental idea of true and false.  It's neat that they can be
    treated as one, but we really need both.

I have used Dave Gudeman's solution to the lack of Booleans by using
&null, with the operators / and \, but I find it inelegant. A nicer,
though less efficeint solution would be to capture success and failure
in a procedure or co-expression and use these to represent true and
false:

        procedure true()
           return
        end

        procedure false()
           fail
        end

        procedure main()
           local x, y
           x := true
           y := false
           if x() then write("true") else write("false")
           if y() then write("true") else write("false")
        end

or

       global true, false

       procedure main()
          local x, y
          true := create |&null
          false := create &fail
          x := true
          y := false
          if @x then write("true") else write("false")
          if @y then write("true") else write("false")
       end

prehaps there should be keywords &true and &false which use one of these
two schemes.

    1) Empty if-then-else clauses.

        if A then B else ;        # if A fails, produces &null

        if A then ; else B        # similarly

You can say

    if A then {} else B

you should be able to say

    if A then B else {}

but there seems to be a bug in the compiler so that it gets translated into

    if A then B

Note that {} can also be used in a case expression:

    case A of {
        B: C
        D: {}
        default: E
        }

also (rambling on) another useful programming technique with the case
expression is to use | to create the effect of multiple ``case labels''
on one expression:

   case A of {
        B | C | D: E
        F: G
        }

    2) Tables.

        !t generates the entries of a table.  There needs to be a
    way of generating the *keys*.  As it is, I use sort() to produce
    a list of pairs, then pick the keys out of that by hand.  (Since
    tables are in principle unordered, perhaps the keys in a table
    should be made available as a set.)

I agree that there is a deficiency here.

    3) Built-in functions

        I still say we need:

    a)    all P(1 to n)        # P(1) & P(2) & ... & P(n)

Problems arise with the interpretation of all when an expression contains
more than one generator. Suppose we have two procedures, p and q, where
q(1) generates i1, i2, ..., im. Does

   all p(q(1 to n))

mean

   p(q(1)) & p(q(2)) & ... & p(q(n))

or

   p(i1) & p(i2) & ... & p(im)

or something else and why? What happens if p is also a generator?

From icon-group-request  Thu Apr  2 13:32:36 1987
From: naucse!sbw (Steve Wampler)
To: arizona!gudeman
Subject: Re:  Suggestions for Icon
Cc: [e-mail]
Errors-To: icon-group-request
Status: RO

       <Bill Kinnersley writes...>
       But there's something missing from the language that I'd
       like to put back in.  Real, honest-to-gosh Booleans.  (No,...

    <Dave Gudeman writes...>
    If I need a boolean that will be used to drive control structures, I
    ...
    add booleans to Icon: add the keyword &true, which returns a unique
    object like &null.  Add the keyword &false which is identical to
    &null.  Add the function boolean(x) which returns x if it is &null or
    &true, and fails otherwise.  Would that be sufficient?

I suspect Bill is not interested in booleans so much for control flow, as
as data objects (bitmaps, etc.).  Csets give a limited form of bitmap,
but is limited by the size of &cset.  For example, I would love to run
(personally) some graphics simulations in Icon, and being able to twiddle
bits would be nice.  However, I'm also not sure if that should be
considered within the domain of Icon.


       1) Empty if-then-else clauses.  We can say
       We should be able (currently illegal) to say

           if A then B else ;        # if A fails, produces &null

           if A then ; else B        # similarly

Why doesn't this work?  Aren't null statements legal in such places?
Sigh.  Bill is correct, though one could argue that is it 'clearer'
to write:

           if A then B else &null
           if A then &null else B

(see, Icon really *is* police state programming!)

       2) Tables.

           !t generates the entries of a table.  There needs to be a
       way of generating the *keys*.

Ditto for me, I think we need both of these.
I'd really like a way to generate the table elements, and
then pull either(both) the key and entry values from each element.

       3) Built-in functions

       b)    any P(1 to n)        # P(1) | P(2) | ... | P(n)

    Will (i := 1 to n, P(i)) work?

This *is* just P(1 to n), and 'all P(1 to n)' is almost 'every P(1 to n)'.
I suspect what Bill means by 'all P(1 to n)' is the ability to
spread results of an expression out (into a list?).

    We also need a control structure:

        E1 reduce E2

    where E1 returns a binary function, and the results of E2 are combined
    pairwise with the function.  For example

        "+" reduce !"123"  ==>  "+"("+"("1","2"),"3")  ==> 1+2+3  ==> 6
        "||" reduce 1 to 3  ==> "||"("||"(1,2),3) ==> 1 || 2 || 3 ==> "123"

This is fairly simple to model with PDCO (programmer-defined control
operations), and in fact, makes a good homework exercise on the
subject.  Of course, using a PDCO has its drawbacks.

By the way, assignment is a binary operator,  could one
":=" reduce (x|y|z)?  (Why not? - maybe there should be a 'reduceleft'
and a 'reduceright'.)

From icon-group-request  Sat Apr  4 12:16:11 1987
From: [e-mail] (Bob Alexander)
To: [e-mail]
Subject: Re:  MS-DOS Icon suggestion
Cc: [e-mail]
Errors-To: icon-group-request
Status: RO

Cheyenne -- I'm going to copy this message to icon-group, since the
ideas presented might be of general interest.

Icon-groupies -- for background:  this is a discussion of a technique
for making icode files executable as commands on non-UNIX machines.
The method is to place shell commands into the header portion of the
icode file that invoke iconx with the icode file as parameter.  This
technique is currently used in the Macintosh MPW version, and is being
suggested for the MS-DOS version.

----------------------------------

Speaking of the perils of possibly rewriting edited icode files ... let
me mention an idea I had but never did anything with.

Since my MPW icode headers are text commands, maybe they could actually
be user-modifiable.  Additional stuff could be put in there
(occasionally); in particular manipulation of environment variables.
Wouldn't it be nice it the memory region sizes could be properties of
the programs themselves, rather than part of a global environment.  Of
course, there are other ways to do this, but I can't think of any where
the parameters would be integral to the program file.

Users couldn't be allowed to just edit the icode files though, because
the size of the header would have to be prevented from changing.  A
utility would have to be provided to help them out.

Since the environment changes would occur in a sub-shell, the global
environment would not be affected.

I went as far as leaving extra space in the header for MPW, but never
provided the utility.

On a different subject, but still related to executable icode files,
the MPW version of Icon gets its iconx path info from an environment
variable instead of having it "hard-coded" into the header.  I think
that feature would be useful in all versions of Icon.  It makes it much
easier for someone to copy a personal copy of Icon to his machine
(which doesn't already have Icon installed globally) , into his own
area of the file system.  As it is, he would usually have to either
talk to a system administrator to put it into /usr, or build his own
Icon (difficult for many users who aren't allowed to consume the amount
of file space required to build Icon).  And it just seems like a good
idea that makes life easier all around.  It could default to a
hard-coded path if the environment variable is missing.

In the case of MPW, where the ability to build Icon is currently not
provided, specification of the iconx path by environment variable is
the only way to allow users to choose where they want to locate Icon.

From icon-group-request  Mon Apr  6 12:14:40 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Errors-To: icon-group-request
Status: RO

A couple of weeks ago I posed the following Icon programming problem:

   The "pattern" for a word ... displays its structure by representing all
   occurrences of the first letter of the word by "a", all the occurrences
   of the second letter of the word by "b", and so on.  Thus, the pattern
   of "proposals" is "abcacdefd".

   The problem is to write a procedure whose argument is a word and
   whose value is the corresponding pattern ... .

   Aim for clarity and the best use of the features of Icon, but don't
   ignore efficiency ... .

Experienced Icon programmers naturally turn to map(s1,s2,s3) when there
is a hint of character substitution or rearrangement in the air.  The
problem above is a natural for map -- the difficulty is finding the
unique characters on which to base a substitution.

Most solutions we received (not all of which were posted to icon-group) were
based on removing duplicate characters in the word by "conventional"
string processing, followed by a straightforward use of map.  These
solutions had the following form:

procedure patternword(s)        # Solution 1
   static letters            #   based on program by Gregg Townsend

   initial letters := string(&lcase)

   out := ""
   every c := !s do
    if not find(c,out) then
        out ||:= c
   return map (s, out, letters[1+:*out]))
end

The static identifier is used to avoid cset-to-string conversion every time
the function is called.  This makes a noticeable difference, as does the
use of find() instead of upto() -- the latter requires a string-to-cset
conversion in the loop.

Ardent Icon programmers try to find a way to do it entirely with map --
both because of the challenge and because of the knowledge that map operates
on all characters of its arguments in each call, avoiding loops over the
characters at the source level.

Here is such a solution:

procedure patternword(s)        # Solution 2
                    #   based on program by Ken Walker
    local numbering, orderS, orderset, patlbls
    static labels, revnum

    initial {
    labels := &lcase || &lcase
    revnum := reverse(&cset)
    }

    # 1: Map each character of s into another character, such that the
    #    the new characters are in increasing order left to right (note
    #    that the map function chooses the rightmost character of its second
    #    argument so things must be reversed).
    # 2: Map each of these new characters into contiguous letters.

    (numbering := revnum[1 : *s + 1]) | stop("word too long")
    orderS := map(s, reverse(s), numbering)
    orderset := string(cset(orderS))
    (patlbls := labels[1 : *orderset + 1]) | stop("too many characters")
    return map(orderS, orderset, patlbls)
end

Yet another all-map solution is:

procedure patternword(s)        # Solution 3
   static backwards, letters

   initial {
      backwards := reverse(&ascii)
      letters := string(&lcase)
      }

   z := reverse(s)
   z := map(z,z,backwards[1:*z + 1])
   cz := cset(z)
   return reverse(map(z,cz,map(cz,cz,letters[1:*cz + 1])))
end

I'll leave you to figure it out.

The concept of "good style" is more controversial in Icon than in many
other programming languages.  I personally prefer the first solution
for clarity and the second for cleverness.  Timing is more objective.
Solution 2 is fastest.  Here are comparative timings from processing
10,000 words from the word list from Webster's 2nd. The results are
normalized to Solution 2:

    Solution 1    1.15
    Solution 2    1.00
    Solution 3    1.51

It's worth noting that the timing is very sensitive to the method
used. Solutions that use table-lookup instead of mapping typically
are in the 3 - 5 times range compared to Solution 1.  Even putting
the cset-to-string conversion in the body of the procedure in
Solution 1 adds about 20% to its running time.




From icon-group-request  Tue Apr  7 17:40:23 1987
From: Gus Fernandez <[e-mail]>
Subject: comments from a skeptic
To: [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO

Having seen the responses over the past few weeks regarding the string
mapping problem, I begin to question the true power of the language

Given that a problem is needed to be solved, one must set forth certain
measures regarding the effectiveness of the solution. The best measure
I know of is some linear combination of the speed of the resulting code
and the speed with which the programmer implemented the solution. (code
readability, and monetary cost may be other factors but I won't go into
those here.) One must also note how these factors change as the complexity
of the problem increases.

Icon is generally considered a slow language, certainly slower than
equivalent code written in C. Icon thus loses on this ground.

Speed of implementation is my main bone of contention.
The fact that a "simple" problem was stated and it raised the curiosity
of several to implement either "standard" or "clever" solutions leads me
to believe that too much effort is required to come up with such "simple"
solutions over and above that which is needed to implement them in a
conventional language. Moreover, the resulting code would probably be faster.

Problems such as these are reminiscent of the same sorts of things I saw
being done years ago with APL. We have a programming model quite different
from that with which we are used to and are challenged to see how we can
apply it in clever ways to problems which we used to solve with conventional
languages.

To a certain extent, this is good, especially when first learning how to
program, and discovering the similarities and differences in syntax and
semantics between different languages. If this sort of thing goes on for
too long, however, we must question whether any language is an effective
tool for the job.

I consider a language to be "useful" only when I can sit down at a keyboard
and hammer out a working algorithm to a simple problem without much
forethought and have it work more or less the first time without any glaring
logical errors.

Certainly, one is not "proud" of this sort of code. It is something you
needed to do to get the job done. If one thinks for a minute that this is
any sort of accomplishment, then I would like to see this person tackle
a much more complex job.

So far, I have only seen fairly trivial examples of ICON code. Certainly
they do well to illustrate some of the interesting features of the language,
but if I cannot rely on it to help me substantially when writing larger
systems, I see little reason to invest the time and effort required to
master a complex language such as ICON.

Perhaps, I am too used to the Von Neuman model to see the "obvious" advantage
of using alternative models. I can certainly see where certain "kernels" of
programs could be implemented quite effectively in languages such as ICON,
SNOBOL4, APL, or PROLOG, but when 99% of the rest of the problem requires
little more than what we already have in C, Pascal, or LISP, we are tempted
to move toward homogeneity.

Perhaps certain languages are best suited to proving that certain key
algorithms work, which are required in a larger system. This is a legitimate
use for specialized languages, as long as the programmer is prepared to
either re-write his code in a conventional language for speed or
compatibility, or suffer the consequences of slow code or clumsy and error
prone interfaces.

I believe that this is the main reason that I read about so many people
"interested in learning" about ICON, but fewer actually making effective
use of it. I would like to hear from anyone who thinks otherwise.

                        Gustavo A. Fernandez


From icon-group-request  Tue Apr  7 18:45:49 1987
From: "Ralph Griswold" <ralph>
To: [e-mail]
Subject: in reponse to "comments from a skeptic"
Errors-To: icon-group-request
Status: RO


The problem posed was designed to encourage persons interested in Icon
to think about some of its features as they apply to certain kinds of
programming problems.

I tried it out on local folks first to see what kind of reactions I'd
get.  Most produced something corresponding to "Solution #1" from
my recent mail without any noticeable difficulty; in fact, I got back
one solution almost instantly.  So I do not think there is anything
particularly difficult or arcane about the problem to programmers
who are reasonably familiar with Icon.

I don't see any connection between this kind of exercise, which admittedly
is of interest mostly as a puzzler, and the use of Icon for "real"
programming problems.  There certainly are plenty of the latter, although
as for any programming language, persons usually don't publish their
programs.  We know of very successful production uses of Icon for rapid
prototyping in industry, and the regular use of Icon at many sites for all
kinds of utilities, including things like one-of-a-kind data transformations
and text generation.

In fact, I've been surprised to learn in recent months that some Icon sites
we didn't even know about are using the language regularly for certain kinds
of tasks.  In many cases these are commercial organizations that use languages
like C also, so I presume they feel that Icon offers economy in the balance
between program development time and programmer costs versus execution
efficiency.

Results from a reader survey taken last fall show all kinds of applications.
We haven't tabulated them yet, but my impression is that the bulk are
in natural language applications and prototyping.  When these are tabulated,
we'll post the results.

From icon-group-request  Tue Apr  7 23:09:09 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: Gus Fernandez's message of Tue, 7 Apr 87 17:13:36 PST
Subject: Re: comments from a skeptic
Errors-To: icon-group-request
Status: RO

The statement that Icon is too slow is not a valid critism of Icon, it
is a critism of a particular implementation.  A lot of people once
criticized Lisp on the same grounds (some uninformed people still do)
but today there are Lisp compilers comparable to C compilers in
efficiency.

It took me less than 10 minutes to code the solution to the puzzle
(with complete error checking), and I am a fairly slow programmer.  If
the puzzle were supposed to be solved in C I would not have even tried
it, it would not have been worth the time and effort.  By this
measurement, Icon is superior to C.

Of course, if you are considering which language to use for a
particular project, you have to take into acount the implemenations
available.  But in this case, you are not judging a "language", you
are judging a program (the translator).  There are still a lot of C
programmers writing Fortran code because Fortran has better optimizing
compilers on certain machines.

From icon-group-request  Wed Apr  8 14:18:26 1987
From: ks26#@andrew.cmu.edu (Kenneth Sykes)
To: [e-mail]
Subject: Re: comments from a skeptic
Errors-To: icon-group-request
Status: RO


Like many other people said, the program was a puzzle, the type of thing a
group of people come up with during coffee break.  So the time needed to
write the most efficient version is irrelevant.

As to real applications in ICON, I am writing a Pascal to C translator in
ICON
as a semester project.  I would consider this a "real" application.  I have
written
a simplified YACC compiler, and am currently working on a LEX compiler.  Both
programs are small, compact and easy to read.  Development time was
considerably
less than a C version, despite the fact that I am proficient in C.

This leads me to a question:  I would like to simulate regular expressions in
ICON,
and would be glad to hear suggestions anyone has.  I have a copy of Mr.
Griswold's
book, which gave me a starting point.  The problem is I would *ideally* like
to pass
either a matching expression or a matching procedure to a function, say
arbno, to
simulate regular expression operators.   I have not figured out a way to
invoke
a code fragment in a string, although I do know how to invoke a procedure
stored in
a string (i.e. "write"("hello")).  An Eval() primitive would be ideal for
this...

Any help would be appreciated.  ICON is a slick language (esp. on a VAX!);
keep up
the good work!

Sincerely,

Ken Sykes

From icon-group-request  Wed Apr  8 15:43:39 1987
From: ihnp4!iwsam!orf
Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf
To: arizona!icon-group
Cc: arizona!ralph
Subject: Re: comments from a skeptic
Errors-To: icon-group-request
Status: RO

My "on-the-fly" response..

>Given that a problem is needed to be solved, one must set forth certain
>measures regarding the effectiveness of the solution. The best measure
>I know of is some linear combination of the speed of the resulting code
>and the speed with which the programmer implemented the solution.
Yes, empirical evidence would be nice. My intuition, having used Icon
for about 1 1/2 years in my "real" work here at AT&T, is that it is
easy for experienced programmers to learn, and few languages would
be able to better it -- using your limited criteria.

>
>Icon is generally considered a slow language, certainly slower than
>equivalent code written in C. Icon thus loses on this ground.
Slower than what??? Slower than UNIX shell? Slower than Lisp?
Slower than prolog??

I don't consider it a "slow" language (although it is true that its
speed is sensitive to the experience and ability of the programmer).
We used it to prototype a complex system. We gave the prototype to our
customers less than 2 months after we started programming. We iterated
through 5 prototype releases trying to "please" our customers. There
were remarkably few (if any) concerns or issues raised about system
performance. Our departments UNIX shell based tools (scripts), of which
there are many "because they were easier to implement than C" are a
constant source of customer complaints about performance. I don't see
any difference, on our UNIX systems, between Icon and C in user interfaces.

I also recommend you try Icon on an Amdahl 580 (3081 equivalent) running
pure System V - You will never think speed is an issue or important in
regard to Icon again. The hardware technology today is lightyears
past the software technology.
>
>Speed of implementation is my main bone of contention.
I think the main "niche" Icon will find is providing quick "models" of
proposed software.  Icon's speed is not an important factor as far as
I am concerned in my work. What kind of system are you using it on?
A PC???

>The fact that a "simple" problem was stated and it raised the curiosity
>of several to implement either "standard" or "clever" solutions leads me
>to believe that too much effort is required to come up with such "simple"
>solutions over and above that which is needed to implement them in a
>conventional language. Moreover, the resulting code would probably be faster.
Icon, in general, is the easiest language I've ever used.  It is the only
language I have used that over %50 of my programs run the first time - and
I no longer even consider that surprising.

I (we) have experience with large "real" programs. The most interesting
aspect is that by following a "mild" discipline (trying to make the code
look like psuedo code, declaring all variables, etc.) people who came on
board in the middle of the project had no problem understanding and adapting
the Icon programs. No such thing can be said about the C programs after the
conversions. Our management is convinced that Icon is easier to maintain,
and depending on the application, not a performance dog (much better than
shell). Their primary concern now is support for the language.
>
>Problems such as these are reminiscent of the same sorts of things I saw
>being done years ago with APL. We have a programming model quite different
>from that with which we are used to and are challenged to see how we can
>apply it in clever ways to problems which we used to solve with conventional
>languages.
I will steal this line from Joe Hall (AT&T Bell Labs): "The difference
between a language like APL and a language like Icon is that nothing you
can do can make an APL program readable."

In my opinion, Icon is the most readable language (potentially) available.
>
>To a certain extent, this is good, especially when first learning how to
>program, and discovering the similarities and differences in syntax and
>semantics between different languages. If this sort of thing goes on for
>too long, however, we must question whether any language is an effective
>tool for the job.
I can understand your "concern" if the only experience you have with the
language are these esoteric solutions that came across the net. Again,
there is a certain intellectual pleasure in "breaking new ground" and
thinking in new ways, but that doesn't diminish the general usefulness
of the language.
>
>I consider a language to be "useful" only when I can sit down at a keyboard
>and hammer out a working algorithm to a simple problem without much
>forethought and have it work more or less the first time without any glaring
>logical errors.
Bingo!  I'll match Icon against any language you care to name in this
regard. SNOBOL4 was close - in my estimation...

>
>Certainly, one is not "proud" of this sort of code. It is something you
>needed to do to get the job done. If one thinks for a minute that this is
>any sort of accomplishment, then I would like to see this person tackle
>a much more complex job.
The reason Icon can succeed here is that it is capable of giving a "high
level" - yet efficient - representation of the solution to a given problem.
In any case, these "one-shot" programs can be extremely valuable.
>
>So far, I have only seen fairly trivial examples of ICON code. Certainly
>they do well to illustrate some of the interesting features of the language,
>but if I cannot rely on it to help me substantially when writing larger
>systems, I see little reason to invest the time and effort required to
>master a complex language such as ICON.
Suit yourself. This is a "technology transfer" problem. You are not much
different that a lot of people who generally feel "overloaded" with too
many languages and tools... In my case, not having Icon (when I first got
here) was like having to go back to "ed" after learning "vi", or going
back to "sh" after using "ksh", etc...  Any environment without it seems
primitive to me..
>
>Perhaps, I am too used to the Von Neuman model to see the "obvious" advantage
>of using alternative models. I can certainly see where certain "kernels" of
>programs could be implemented quite effectively in languages such as ICON,
>SNOBOL4, APL, or PROLOG, but when 99% of the rest of the problem requires
>little more than what we already have in C, Pascal, or LISP, we are tempted
>to move toward homogeneity.
Not to "nit-pick" but we have "everything we need in assembly language"...

>
>Perhaps certain languages are best suited to proving that certain key
>algorithms work, which are required in a larger system. This is a legitimate
>use for specialized languages, as long as the programmer is prepared to
>either re-write his code in a conventional language for speed or
>compatibility, or suffer the consequences of slow code or clumsy and error
>prone interfaces.
I suppose. But prototyping is a very valuable tool in the area of software
development. Don't slight it.
>
>I believe that this is the main reason that I read about so many people
>"interested in learning" about ICON, but fewer actually making effective
>use of it. I would like to hear from anyone who thinks otherwise.
>
>                        Gustavo A. Fernandez
>
I can't give any more specifics other than we spent 9 months and iterated
through 5 Icon releases of a prototype automated testing system. The system
is quite large now, probably because it seemed so "easy" that we were willing
to tackle more. It definitely was easier to maintain in Icon - and I was
the only person originally who knew the language. Now my entire group knows
it. When we turned (most) of it into "C", that effort alone spanned 6 months.
We are not nearly so "happy" now, and looking for something else to prototype..

O. R. Fonorow
AT&T Informat Systems
Software Technology Department
IW 1Z-261
ihnp4!iwsam!orf



From icon-group-request  Wed Apr  8 15:52:11 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: ks26#@andrew.cmu.edu's message of Wed,  8 Apr 87 16:12:05 est
Subject: comments from a skeptic
Errors-To: icon-group-request
Status: RO

   Date: Wed,  8 Apr 87 16:12:05 est
   From: ks26#@andrew.cmu.edu (Kenneth Sykes)

   ...  I have written a simplified YACC compiler, and am currently
   working on a LEX compiler...

Well don't keep us in suspense.  Do they compile to Icon or C?  Are
you willing to post them?

If they compile to Icon, they would be great to include in the Icon
program library.

From icon-group-request  Wed Apr  8 21:20:06 1987
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: regular expressions
Errors-To: icon-group-request
Status: RO

    Date: Wed,  8 Apr 87 16:12:05 est
    From: ks26#@andrew.cmu.edu (Kenneth Sykes)
    Subject: Re: comments from a skeptic

    ...

    This leads me to a question:  I would like to simulate regular expressions
    in ICON,
    and would be glad to hear suggestions anyone has.  I have a copy of Mr.
    Griswold's
    book, which gave me a starting point.  The problem is I would *ideally* like
    to pass
    either a matching expression or a matching procedure to a function, say
    arbno, to
    simulate regular expression operators.

I have simulated regular expressions, but I used an experimental feature
of Icon (described in "TR86-20  An Expression Data Type for Icon") and the
feature probably will not be incorporated in a release of Icon in the
immediate future. It is possible to simulate most aspects of the feature
with co-expressions, but it is not elegant. Recursive "patterns" like
those created by an arbno procedure are particularly ugly to implement. The
simulation with co-expressions is not particularly difficult, but it is
**not** pretty. If you really think you want to see it, I can give you
details.

The only other approach that comes to mind is the standard set of
transformations:
   regular expression
     -->  non-deterministic finite state autamata (NFA) with epsilon moves
     -->  NFA without epsilon moves
     -->  deterministic finite state autamata (DFA)
     -->  minimal DFA
then interpret the DFA. Of course, you can stop with the NFA and interpret
it. I haven't thought much about it, but interpreting an NFA in Icon
is probably easy because of goal directed evaluation. The question is
do you want a simple construction routine or a fast regular expression.
By the way, the co-expression approach is  non-deterministic , i.e. it
uses backtracking, and is probably significantly slower, in general, than
interpreting a minimal DFA.

The performance of a DFA or NFA interpreter will of course depend on your
representation of the the autamata. You will probably want to use strings
rather than individual characters as symbols.

From icon-group-request  Thu Apr  9 09:10:24 1987
From: ks26#@andrew.cmu.edu (Kenneth Sykes)
To: [e-mail]
Subject: YACC/LEX in ICON
Errors-To: icon-group-request
Status: RO


The YACC compiler I mentioned in my previous post generates ICON code.
I would be more than happy to submit it to your program library - all I need
is instructions on how to do it.  I would rather wait a couple weeks until I
finish
my project before I submit it, however.  By then I will have finished the LEX
compiler (which will also generate ICON code), grammars for a Pascal to C
translator, and documentation.

-- Ken

P.S.  Thanks for the reply regarding regular expressions.  I have considered
converting the RE to a FSM, but I was hoping to exploit ICONs string features
if at all possible.  If it's not too much trouble, I would like to see how
you would
use co-expressions to simulate REs.

From icon-group-request  Thu Apr  9 11:16:09 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: comments from a skeptic
Cc: [e-mail], [e-mail], [e-mail]
Errors-To: icon-group-request
Status: RO


-----
Without rebroadcasting Gustavo's courageous -- foolhardy?? --
message yet again, I do want to respond to a few snippets.  The
reason I think my two cents' worth might be worth two cents is
that I represent a certain class of computer user:  I have been
programming since 1968, starting with Fortran II on an IBM 1620
BCD machine.  I've used mainframes, minis, & micros; languages
ranging from assembler to C & Pascal, SNOBOL4, PL/1, and a
whole bouquet of LISP dialects -- including Interlisp on a
Xerox 1109, in case anyone thinks I can't stand up to
serious self-flagellation.  But I'm NOT a professional
programmer, much less a computer scientist.  I started programming
because it was fun & continued because programming became an
indispensible day-to-day tool.

I must admit that I got a bit hostile when I saw the all-map
solution.  map was the first thing I thought of, and I even
got some fragments of the all-map solution, e.g., I realized
that reverse would have to in there somewhere; but I couldn't see
how to put it all together.

Given that I did see the "standard" solution pretty fast, I guess
I wouldn't leap to the conclusion that Icon is slow and/or
obscure.  It's a bit like faulting Fortran because it isn't
immediately obvious how to write Quickersort.
-----


 ...  some linear combination of the speed of the resulting code
and the speed with which the programmer implemented the solution ...
  ... readability & monetary cost ...
  ... complexity of the problem ...
  ... speed of execution ...
Speed of implementation is my main bone of contention.
 ... comparison with APL ...

-----
Icon is a winner according to any of the above criteria
except perhaps sheer execution speed.  Conclusion:  Don't
use Icon if sheer execution speed is your sole performance
criterion.  But how many of us fit that description?
The comparison with APL is a complete bum rap; Icon code is
so clear that people can read and understand Icon
code even when they don't know Icon at all.
-----


I consider a language to be "useful" only when I can sit down at a keyboard
and hammer out a working algorithm to a simple problem without much
forethought and have it work more or less the first time without any glaring
logical errors.

-----
The above is exactly my criterion.  That's why I now program
exclusively in Icon unless (a) I need very precise timing
[use Turbo Pascal] or (b) I need to enter SNOBOL4 patterns
as parts of commands at run-time [use SNOBOL4].  For fast
working code that you can go back to six months later and
still comprehend, Icon wins over any other language.  For my
money (i.e., $15), it beats C, Pascal, LISP, and everything
else for a combination of reasons, but NOT primarily because
of its unique, nonstandard features.  The particular things I
like for sheer usability are:  standardization -- unsurpassed;
link directive -- write it and forget it libraries; telescoping
code -- algebraic, C-looking stuff can be telescoped down to
Lisp-looking stuff, sometimes actually improving clarity (and
the reverse can be done if THAT improves clarity); I find it
a much more "write as you think" language than any other;
finally, most importantly, it supports the datatypes and data
structures I find most useful, especially list/arrays, tables,
and true sets (and of course strings).  To me, this is what a
high-level programming language should be:  C and Pascal do not
qualify as high-level languages because they don't support a useful
range of high-level data structures.
My criteria relate mainly to this central theme:  I want a
language that DOES work, not one that MAKES work.
-----


little more than what we already have in C, Pascal, or LISP, we are tempted
to move toward homogeneity.

-----
Yes, I am awe-struck at the homogeneity of LISP.
-----

From: "Ralph Griswold" <[e-mail]>

In fact, I've been surprised to learn in recent months that some Icon sites
we didn't even know about are using the language regularly for certain kinds
of tasks.  In many cases these are commercial organizations that use languages
like C also, so I presume they feel that Icon offers economy in the balance
between program development time and programmer costs versus execution
efficiency.

-----
This has been my experience.  I've used Icon for a range
of tasks from experiments with text analysis to maintaining
mailing lists and budgetary databases.  Not only does Icon have
a very favorable programming+execution time (winning on very
short programming-debugging time), but I think it is very easy to
learn, given its usefulness.  Of course, I already knew a lot of
languages, but could Icon be much harder to learn as a first
language than, say, Pascal?
-----


From: "David Gudeman" <[e-mail]>

Of course, if you are considering which language to use for a
particular project, you have to take into acount the implemenations
available.  But in this case, you are not judging a "language", you
are judging a program (the translator).  There are still a lot of C
programmers writing Fortran code because Fortran has better optimizing
compilers on certain machines.

-----
Carefully choosing a language for an application is only a concern
for certain kinds of applications.  For do-it-yourselfers like
me, it is very useful to have one language that "satisfices,"
using Herb Simon's term, for almost all applications.  That's where
Icon is a winner:  it's acceptably good for a wide range of tasks,
even though some other language might be better on a given task,
especially if execution speed is extremely important and
development and maintenance time aren't.
-----


From: ihnp4!iwsam![e-mail]
Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf

>I consider a language to be "useful" only when I can sit down at a keyboard
>and hammer out a working algorithm to a simple problem without much
>forethought and have it work more or less the first time without any glaring
>logical errors.
Bingo!  I'll match Icon against any language you care to name in this
regard. SNOBOL4 was close - in my estimation...

-----
I completely agree with all of orf's comments down to this point,
which is why I deleted them.
But I must inject a word of disagreement here:
I am certainly a SNOBOL4 fan; in fact, I think the
continued survival of LISP disproves the principle of
natural selection.  BUT -- let's be honest.  There are trade-offs;
you can simply DO things in SNOBOL4 that you can't do in
Icon.  That is granted.  But SNOBOL4 is highly idiosyncratic and opaque
compared with Icon.  I don't think this is debatable, since two
of SNOBOL4's best advocates, Griswold and Gimpel, are on record also
as its ablest critics.
SNOBOL4, like PROLOG and LISP, are high-level languages, but for
practical purposes I refuse to consider them general-purpose
programming languages, nor is APL.  Icon rules as the
highest-level, generalest-purpose language available.  PL/1
is disqualified on grounds of ugliness.
-----


From icon-group-request  Thu Apr  9 12:01:07 1987
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: co-expressions & REs
Errors-To: icon-group-request
Status: RO

The basic idea for simulating regular expressions is capture matching
expressions in co-expressions. For example

   p := create ="hi"
   "high" ? write(@p)

There are two problems. One is that the co-expression must be refreshed
between uses and the other is that it must be forced to produce all
alternatives during backtracking. This can be acomplished by invoking
it with the following procedure.

   procedure eval(e)
      e := ^e
      suspend |@e
   end

for example

   p := create =("hi" | "low")
   "low" ? every  write(eval(p))
   "hi" ? every  write(eval(p))

The procedure eval is circumventing most of what makes a co-expression a
co-expression.

If you look at what is going on in the run-time system, stacks are being
allocated and execution is switching back and forth between stacks. None of
this is needed for this problem; the stack of the caller would could be
used for all evaluation (see TR86-20).

To see how to create more complex matching co-expressions from simpler
ones, recall that a co-expression gets a copy of all local variables,
including parameters. The following procedure constructs the alternation
of two co-expressions.

   procedure alt(e1, e2)
     return create eval(e1) | eval(e2)
   end

The following co-expression is functionally equivalent to the one given
above.

   p := alt(create ="hi", create ="low")

In order to take a Kleene closure you needed to be able to do something
like

   p := arbno(create ="hi")

This can be done by creating a recursive co-expression, but the following
will not work

   arbe := create "" | (eval(e) || eval(arbe))  # WRONG

The idea is basically right: an arbitrary number of applications of e
is either no application (the null string) or one application followed by
and arbitrary number of applications. The problem is that the co-expression
gets a **copy** of arbe before the assignment and thus it contains the null
value not the co-expression. The following solution is better than the
one I had come up with before - it is not quite as ugly. The  idea here
is to make use of the pointer semantics of Icon records. arbe is assigned
a record. The co-expression gets a copy of arbe and thus a reference to
the record. The co-expression is then assigned to the field of the
record.

record r(a)

procedure arbno(e)
   local arbe

   arbe := r()
   arbe.a := create "" | (eval(e) || eval(arbe.a))
   return arbe.a
end

You also need a procedure to implement concatination and prabably one
to convert a string to the corrosponding matching co-expression. They
are easy once you see what is going on. I will leave them as an
exercise.

From icon-group-request  Thu Apr  9 12:41:48 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: "Kenneth Walker"'s message of Thu, 9 Apr 87 12:01:07 MST
Subject: co-expressions & REs
Errors-To: icon-group-request
Status: RO

Ken's solution to regular expressions in Icon (using co-expressions)
is rather elegant, but it really eats up memory.  You might be able to
reduce this problem considerably by careful choice of co-expression
stack size since presumably the stacks needed for these co-expression
will be quite small.  The size of co-expression stacks can be set by
the environment variable COEXPSIZE.

Be careful that the stack is large enough for any possible execution
of the program, because stack overflow checking is not perfect in
Icon.  Also, you will want to avoid any recursive co-expressions or
any co-expressions that can make recursive function calls.  For arbno
try:

    procedure arbno(e)
    return create |eval(e)
    end

(no guarantees on this, I havn't tried it.)

From icon-group-request  Thu Apr  9 13:17:43 1987
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: Re:  co-expressions & REs
Errors-To: icon-group-request
Status: RO

    Date: Thu, 9 Apr 87 12:41:48 MST
    From: "David Gudeman" <gudeman>

    Ken's solution to regular expressions in Icon (using co-expressions)
    is rather elegant, but it really eats up memory.  You might be able to
    reduce this problem considerably by careful choice of co-expression
    stack size since presumably the stacks needed for these co-expression
    will be quite small.  The size of co-expression stacks can be set by
    the environment variable COEXPSIZE.

    Be careful that the stack is large enough for any possible execution
    of the program, because stack overflow checking is not perfect in
    Icon.

Note that COEXPSIZE does not affect the main stack.

    Also, you will want to avoid any recursive co-expressions or
    any co-expressions that can make recursive function calls.

Calling recursive functions from co-expressions could certainly cause
problems, but recursive co-expressions should be ok. Each recursion gets
its own stack, so lots of small stacks are needed.

    For arbno try:

        procedure arbno(e)
        return create |eval(e)
        end

    (no guarantees on this, I havn't tried it.)

I don't think this will work for "matching co-expressions" because &pos will
be reset during the backtracking that occurs between repetitions.

From icon-group-request  Fri Apr 10 13:19:51 1987
From: ks26#@andrew.cmu.edu (Kenneth Sykes)
To: [e-mail]
Subject: Re:  co-expressions & REs
Errors-To: icon-group-request
Status: RO


I have a couple of questions concerning Ken's post on REs:
   1) Is the use of every in the main code (i.e. "low" ? every
write(eval(p)))
       used to get at the alternatives of p (i.e. "hi", "low") or is it used
for
       some reason relating to the co-expressions?

   2) Is the correct way to use arbno

                  p := arbno(create ="hi")
                  "hihihi there!" ? every write(eval(p))
                             or
                  "hihihi there!" ? write(eval(p))
                             or something completely different?

        None of the above ways works - one gives me the null string and
        the other runs out of memory.  I'm really not sure how the arbno()
        code could work:

record r(a)

procedure arbno(e)
   local arbe

   arbe := r()
   arbe.a := create "" | (eval(e) || eval(arbe.a))
   return arbe.a
end

how can you run eval(arbe.a) when arbe.a is not defined on entry?  Does
it make use of &null somehow?

     3)  I tried to write a concat() procedure, to simulate an RE of the form
          A B:

procedure concat(e1, e2)
      return create eval(e1) || eval(e2)
end

this seems like a logical way to me, but it does not work (another out of
memory
error).


I have not tried the COEXPSIZE variable yet, which may help here.  I am
running
the Large model version of ICON on a PC with 448k of memory.

Again, any help would be appreciated.

-- Ken

P.S.  More explanation of co-expressions in the ICON book would be nice
(hint)


From icon-group-request  Fri Apr 10 14:46:04 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: re: co-expressions & REs
Errors-To: icon-group-request
Status: RO


Co-expressions were added to Icon rather late in its initial
design.  In fact, theey almost were left out of the Icon book
and the chapter on them was put in near the end of all the writing.

Since that time, we've developed a better understanding of how
co-expressions can be used in the context of Icon's kind of expression
evaluation, and co-expression features have been added (programmer-defined
control operation syntax).

I'm presently writing (slowly) a technical report on co-expressions
to fill in what's lacking in the present literature.

In the process, I've added co-expression tracing and the keyword ¤t,
whose value is the current co-expression (so you can tell who you are,
as it were).  Bill Mitchell is fixing a "hole" in the implementation
with respect to return points.  Out of all of this, we hope to have
a  more robust, better documented, and easier to use facility.
Unfortunately, it's going to take another release of the implementation
to bring things into sync.

From icon-group-request  Sat Apr 11 08:44:22 1987
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: Re:  co-expressions & REs
Errors-To: icon-group-request
Status: RO

    Date: Fri, 10 Apr 87 15:19:40 est
    From: ks26#@andrew.cmu.edu (Kenneth Sykes)
    Subject: Re:  co-expressions & REs


    I have a couple of questions concerning Ken's post on REs:
       1) Is the use of every in the main code (i.e. "low" ? every
    write(eval(p)))
           used to get at the alternatives of p (i.e. "hi", "low") or is it used
    for
           some reason relating to the co-expressions?

oops, I borrowed the code from another test. The every interates over all
matches, but in this case there is only one match.

       2) Is the correct way to use arbno

                      p := arbno(create ="hi")
                      "hihihi there!" ? every write(eval(p))
                                 or
                      "hihihi there!" ? write(eval(p))
                                 or something completely different?

            None of the above ways works - one gives me the null string and
            the other runs out of memory.

The first result should be the null string - it is the result of zero
matches. every should iterate over all the solutions:
""
"hi"
"hihi"
"hihihi"
I have no problems running these examples here on a VAX. Here are some
suggestions for environment variables which should help your out of memory
problems:
COEXPRSIZE 1000
STRSIZE    5000
HEAPSIZE   5000
MSTKSIZE   3000
If they don't help let us know.

            I'm really not sure how the arbno() code could work:

    record r(a)

    procedure arbno(e)
       local arbe

       arbe := r()
       arbe.a := create "" | (eval(e) || eval(arbe.a))
       return arbe.a
    end

    how can you run eval(arbe.a) when arbe.a is not defined on entry?  Does
    it make use of &null somehow?

The create is just capturing the code, eval(arge.a) is not executed until
the result returned by arbno is evaluated by eval. By that time arbe.a
has been assigned the co-expression.

         3)  I tried to write a concat() procedure, to simulate an RE of the form
              A B:

    procedure concat(e1, e2)
          return create eval(e1) || eval(e2)
    end

    this seems like a logical way to me, but it does not work (another out of
    memory error).

That is the correct. I ran it here without any problems.

From icon-group-request  Sat Apr 11 10:36:29 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: solitaire program
Errors-To: icon-group-request
Status: RO

An Icon program for playing solitaire (s.icn) showed up in our
uucp area a few days ago -- but with no origin or indication
of authorship.  Will anyone acknowledge it?

From icon-group-request  Mon Apr 13 23:12:51 1987
From: ihnp4!ihuxy!nowlin
Message-Version: 2
>To: /addr=iwsam!orf, /addr=ihnp4!arizona!icon-group
Message-Service: Mail
Message-Protocol: EMail
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: pattern words
Ua-Message-Id: <post.nowlin.Mon, 13 Apr 1987 10:23 CDT>
End-Of-Protocol:
Errors-To: icon-group-request
Status: RO

 > Here is a simple problem in string manipulation that you might try
 > to program in Icon.

 > The "pattern" for a word (take a word to be a string of letters
 > for simplicity) displays its structure by representing all
 > occurrences of the first letter of the word by "a", all the
 > occurrences of the second letter of the word by "b", and so on.
 > Thus, the pattern of "proposals" is "abcacdefd".
 .
 .
 .
 > Aim for clarity and the best use of the features of Icon, but don't
 > ignore efficiency (imagine your procedure is going to be used on a
 > large word list).

I had to try this.  Especially after seeing some solutions fly by with
co-expressions in them.  One of the criteria was supposed to be "clarity"
and another "efficiency".  This is about as straight forward as you can
get.  It just assumes a knowledge of the test for null (/).  After trying
this and the other solutions I received with a list of 23739 words it
seems to be about as fast as the others.

procedure change(word)

    ctab := table()
    pattern := ""

    every c := !word do {
        /ctab[c] := &lcase[*ctab+1]
        pattern ||:= ctab[c]
    }

    return pattern
end

It could be made more efficient by putting a dummy value in the ctab table
before generating characters.  That way the addition in the calculation of
an index into &lcase could be avoided.  For long lists of long words it
would be worth doing.

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)

From icon-group-request  Tue Apr 14 13:41:37 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: Re: comments from a skeptic
Errors-To: icon-group-request
Status: RO

Forwarded message follows...

   From ihnp4!ihuxy!nowlin  Thu Apr  9 14:52:19 1987
   >To: /addr=ihnp4!arizona!icon-group-request
   X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin
   To: arizona!icon-group-request
   Subject: Re: comments from a skeptic

   I just had to respond to this message.  It was too much for me to take.

    > Having seen the responses over the past few weeks regarding the string
    > mapping problem, I begin to question the true power of the language.
    > ...
    > Icon is generally considered a slow language, certainly slower than
    > equivalent code written in C. Icon thus loses on this ground.

   Nobody I know will argue the point that Icon is slower than good C but I
   wouldn't generalize and call Icon a slow language.  It can't compare with C
   and assembler but it flys by any shell scripts I've ever seen and passes
   BASIC on the PC like it was standing still.

    > Speed of implementation is my main bone of contention.
    > The fact that a "simple" problem was stated and it raised the curiosity
    > of several to implement either "standard" or "clever" solutions leads me
    > to believe that too much effort is required to come up with such "simple"
    > solutions over and above that which is needed to implement them in a
    > conventional language. Moreover, the resulting code would probably be
    > faster.

   Your previous comments lead me to believe you've never bothered to learn
   Icon at even a rudimentary level.  Don't argue religion if you can't read
   the bible.  Most of the time shell won't do what I want I resort to Icon.
   It's much faster to solve little problems in it than in C.  For example, I
   wanted to add carriage returns to the end of each line in ascii files so I
   could transfer some files to an MS-DOS machine and be able to use them.  A
   three line Icon program that took about 30 seconds to type in and translate
   did the trick.

       procedure main()
           while write(read(),"\r")
       end

   I then invoked the program from a shell script that looped and fixed a
   whole batch of files.  To do the same program in shell would be cumbersome
   to say the least.  It's also incredibly slow!  To do the same in C would
   take more time and be more prone to error.  Icon is the best solution for
   these kinds of problems.  It's exactly the speed of implementation that
   makes Icon so useful for small problems like this.

    > Problems such as these are reminiscent of the same sorts of things I saw
    > being done years ago with APL. We have a programming model quite different
    > from that with which we are used to and are challenged to see how we can
    > apply it in clever ways to problems which we used to solve with conventional
    > languages.
    >
    > To a certain extent, this is good, especially when first learning how to
    > program, and discovering the similarities and differences in syntax and
    > semantics between different languages. If this sort of thing goes on for
    > too long, however, we must question whether any language is an effective
    > tool for the job.

   Once again your naivete is showing.  I've been using C for a long time and
   I still enjoy trying to do "clever" thing with it from time to time.  Don't
   hold a language responsible if novice programmers (or even experienced
   ones) want to experiment from time to time.  Would you consider C an
   ineffective tool just because some people try to push it to the limits?
   One of the nice things about Icon is that it can be used in a purely
   conventional style if that's what you want.  If you want to take the time
   to learn some of the more advanced features of the language you can program
   circles, in terms of implementation speed, around C for lots of applications.

    > I consider a language to be "useful" only when I can sit down at a keyboard
    > and hammer out a working algorithm to a simple problem without much
    > forethought and have it work more or less the first time without any glaring
    > logical errors.
    >
    > Certainly, one is not "proud" of this sort of code. It is something you
    > needed to do to get the job done. If one thinks for a minute that this is
    > any sort of accomplishment, then I would like to see this person tackle
    > a much more complex job.
    >
    > So far, I have only seen fairly trivial examples of ICON code. Certainly
    > they do well to illustrate some of the interesting features of the language,
    > but if I cannot rely on it to help me substantially when writing larger
    > systems, I see little reason to invest the time and effort required to
    > master a complex language such as ICON.

   I work at AT&T Bell Labs and there are lots of trivial program that you can
   quickly become dependent on in this and many other programming
   environments.  I wouldn't discard a programming language out of hand just
   because it does a whiz bang job on trivial programs.  Icon also does very
   well at large programs.

   I'll give you an example.  The area I work in develops very large databases
   that change on a regular basis.  There's a system of C programs that check
   the integrity of the database after changes are made.  The process of
   running this system on a medium sized database took almost half a day and
   generated a error report that only identified tuples that were bad.  One of
   the engineers working on the database tools wrote an Icon program to do the
   same task.  His main goal was to generate a more detailed error report so
   that the database could be fixed.  His program prints the bad records in
   each bad tupple and exactly what's wrong with them.  This Icon program took
   several hours to do the same task that took the C programs six to eight
   hours.  He programmed his tool using standard procedural programming
   techniques so when it was slower than he liked came to me to see if I could
   speed up his code a little.  When we were done his tool could check the
   same database in about 15 minutes.  He not only improved the reports
   generated, he speeded up the process by more than a factor of 20.  Icon is
   NOT a trivial language.

    > Perhaps, I am too used to the Von Neuman model to see the "obvious" advantage
    > of using alternative models.

   Perhaps you're too comfortable with what you already know and it's easier
   to argue against new languages and programming techniques than it is to
   learn them.

    >                         Gustavo A. Fernandez

   Jerry Nowlin
   (...!ihnp4!ihuxy!nowlin)



From icon-group-request  Thu Apr 16 13:33:14 1987
From: [e-mail] (Bob Alexander)
To: [e-mail]
Subject: Icon close() function
Errors-To: icon-group-request
Status: RO

I've been doing a fair amount of shell script type stuff in Icon
recently (under UNIX), and there is a "shortcoming" that is rather
bothersome sometimes.

Background
----------

In UNIX versions of Icon, using open() with the "p" option invokes the
C function popen(). Popen(command,<read or write>) allows execution of
any UNIX command, with the popen caller either providing "standard
input" to the command, or receiving its "standard output", depending on
whether the "command" wass opened for write or read.  (Bear with me if
you're a UNIX/Icon whiz and already know this stuff.  I thought I was,
and I only recently discovered this powerful capability!)

The Icon system() function invokes a UNIX command, and returns the
command's exit status value to the system() function's caller.  That's
nice, because it is sometimes necessary to check that value.

However, when using open() with the "p" option (invoking popen()),
there is no way to check the command's exit status.  In C, the status
is returned by the corresponding pclose().  In Icon, close() always
returns the "file" that was closed.  Open(...,"p") is an extremely
useful facility with a nasty limitation that it can't be used if one
needs to know the exit status of the command.

Proposal
--------

    It would be more useful if a close() corresponding to an
    open(...,"p") would return the command's exit value as an
    integer, (similar to system()), rather than the file.

Of course, that would create an inconsistency (sort of) in the close()
function (unless all Icon closes returned integers, but that wouldn't
make much sense for files).  But I contend that open(...,"p")/close()
is really more parallel to system() than it is to
open(<file>)/close().  (And I've never found much useful to do with the
file returned by close() anyway).

I'd be interested in hearing comments or debate on this matter.

From icon-group-request  Thu Apr 16 14:00:11 1987
From: [e-mail] (Bob Alexander)
To: [e-mail]
Subject: More on Icon for shell script applications
Errors-To: icon-group-request
Status: RO

Oh yeah, I just remembered another limitation I bumped up against while
using Icon for shell script type applications.

The string length limit of 256 (MacCvtLen) for the system() function is
too short for some uses.  In particular, there are times when it is
desirable to build long parameter lists consisting of many file names.
In such cases I was able to work around the limitation by repetitive
calls to the command, a much less efficient alternative.  There are
other cases where it could prevent a desired operation from being
performed at all.

UNIX generally allows command strings to be much longer than 256
characters; into the tens of thousands, I think.

Icon's philosophy is to be free of any size limits that one would
really ever run up against.  It seems contrary to the spirit of Icon to
have such a limit on the lengths of commands passed to the operating
system.

I propose that the string length limit be removed for system() and
open() calls (open(...,"p") in particular).

From icon-group-request  Thu Apr 16 14:37:26 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: [e-mail]'s message of Thu, 16 Apr 87 13:29:37 pst
Subject: Icon close() function
Errors-To: icon-group-request
Status: RO

Another thing that would be nice for the system() and open(...,"p")
functions is a way to specify a direct execution instead of execution
through the shell.  That is, system(s) starts a shell process and
passes s to it as input.  I would like to write system(s,s1,...,sn)
where s is the name of a program that is executed, and s1 to sn are
arguments passed to the program.  This would in general be much faster
than starting a shell.

From icon-group-request  Fri Apr 17 11:54:36 1987
From: ihnp4!iwsam!orf
Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf
To: arizona!icon-group
Subject: Implementation
Errors-To: icon-group-request
Status: RO


One thing I forget to add to my preview message. I am now reading
Griswolds' Implementation book -- and enjoying it thoroughly! I
highly recommend it to anyone considering changes to the present
implementation, or wondering about various idiosyncracies..

orf



From icon-group-request  Fri Apr 17 11:54:32 1987
From: ihnp4!iwsam!orf
Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf
To: arizona!icon-group
Cc: ihcup!pax, ihuxy!nowlin
Subject: Internal Limits
Errors-To: icon-group-request
Status: RO

And the litany goes on... Another "limitation" many of you may not be
aware of is that there is an internal limit on the read() function.

We "discovered" the read() limit while using Icon programs as "front-ends"
to a DBMS. The database may contain records of 4096 chars. I don't
remember exactly, but the "delivered" Icon internal buffer limit for the read
function is about 2200 chars.

Because of this limit, the aforementioned system() limit and a few limitations
I will mention in a moment, we simply wound up using a personal Icon interpreter
and increased the limits as necessary.  Remember, you have the source and
can control these limits at your site - with or without resorting to a PI.

By the way, as an aside, our first attempt was simply to increase MaxCvtLen to
512. I don't remember exactly what happened, but we started hitting the process
ulimit on a 3B2, i.e. MaxCvtLen is used in a *lot* of places. So we finally
just hard-coded 512 into the buffer declaration for the system() function.
Also, I don't know what internal UNIX limits there are - but command lines
are not (at least under System 5) allowed to be "10s of thousands of chars..."
I think the limit is probably 1024 (see xargs(1)).

As far as returning "useable" values with the close() function, I don't
see a problem (other than existing documentation) with that idea.  We also
ran into problems in that the UNIX write/close/flush would fail - and there is
currently no way to detect this in Icon.  (Under certain circumstances when
there is no more space on a device, (under system V) the only way to detect
whether or not the write failed is if the C close() library routine returns
an error value.)

I guess my "requirement" is that if a write() or close() fails - that
a run-time error be issued. (So we don't have to always check
for failure in our programs). I'd also like to see a run-time error
if the internal read() buffer (or any for that matter) over-flows.

As far as returning the return code from open(..,"p")  through close()
.. sounds reasonable.  Keep in mind that with popen() or system()
something like:

    open("sort <JuNk | uniq | tr ","p")

where "JuNk" doesn't exist will return 0. That is, the return code of
the "tr" command is returned even though the entire pipe didn't do what
you expected... (i.e. sort returned 1)

Finally, I oppose changing the semantics of "system()" (to be more like an
"exec()") because of the parallel to the C system() function.  Sounds like
a good design for a PI function however!

O. R. Fonorow
IW 1Z-261 x7173
iwsam!orf



From icon-group-request  Sun Apr 19 23:19:32 1987
Return-Path: <kinner@wsu>
From: Bill Kinnersley  <[e-mail]>
To: [e-mail]
Errors-To: icon-group-request
Status: RO


    Regarding the question of whether Icon is easy or hard to
learn, I would say easy to learn, hard to master.  In my
Programming Languages course, I teach Icon as the first "new"
language, right after surveys of Fortran and Pascal.  It is
presented at first as a dialect of Pascal with high-level data
types: lists, strings, etc.  (Records aren't mentioned--these
Pascalers would use them and nothing else.)  The students write
their first programs, and build up confidence.  THEN we kick the
props out! *-)

    Someone mentioned confusion between the two null-testing
operators / and \.  Here's a way to remember which is which.
Associate them with the crossbar appearing in their names.  \
stands for Notnull and / stands for iZnull.

    Has anyone noticed the striking similarity between Icon and
this other language called Lucid?  Lucid has a totally different
ancestry, but it wound up with many of the same features.  In
Lucid, the idea of a result sequence is even more pervasive than
in Icon.  Every variable has a "history" of values.  In Icon, an
ordinary variable produces one result, say 2.  In Lucid, it would
produce <2, 2, 2...>  Every expression automatically resumes the
variables appearing in it.  Histories may be terminated with the
symbol eod ("end-of-deck"), which corresponds to our failure.
    Other special symbols found in Lucid are true, false, nil,
and error.  An inappropriate calculation results in the error
object.  Thus, the Icon concept of failure has been split into
three: false, eod, and error.
    Once result sequences like <true, false, true, ...> are
available, it is possible to have one sequence control another.
Operators asa ("as-soon-as") and wvr ("whenever") let you select
values from result sequence A depending on the Boolean values in
sequence B.  Wouldn't something like this be useful in Icon?

----
"If at first you do not fail, try try again."
                                      --Bill Kinnersley
    USENET: ...!ucbvax!ucdavis!egg-id!ui3!wsucshp!kinner
    INTERNET: [e-mail]
    CSNET: kinner@wsu
    MAIL: CS Dept, Washington State Univ, Pullman WA 99164-1210
    PHONE: [phone]


From icon-group-request  Mon Apr 20 18:32:45 1987
From: [e-mail] (Bob Alexander)
To: [e-mail]
Subject: Re: Internal Limits
Errors-To: icon-group-request
Status: RO

Oops, I guess I did exaggerate a bit when I said the shell could handle
command lines in the tens of thousands of characters.  I did some
experimentation, though, and found that our Ultrix (DEC Berkeley UNIX)
maxes out at just under 10,000 characters, considerably more than the
System V limit (according to orf) of 1024.  It wouldn't surprise me if
that's a "sysgenable" parameter that varies from installation to
installation.  In any case, 256 is a rather uncomfortable limit that
apparently a few of you have run up against.

I didn't know about the read() limit.  Again, some experimentation
showed this to be 2049 -- and a look at the code confirmed it
(MaxReadStr).

I've mounted an attack on some of these limits, and my version of Icon
currently supports:

    Infinitely long strings for:
        open() first argument (mainly for open(...,"p")
        system() argument
        result of read()

    Close of a file opened by open(...,"p") returns the integer
    status of the command, just like system() does.  Close of a
    regular file still returns the file.

The long string changes were done not by increasing any internal buffer
sizes, but by modifying the algorithms to build their strings in
dynamic string space if necessary.  I've mailed my code changes to
R.G., so maybe we'll see these limits lifted in standard Icon in the
near future.

I agree with the suggestions that run-time errors for write() and
close() would be desirable.  Currently there doesn't appear to be any
error detection at all for write errors.

I also support the statement that a way to invoke processes without
going through a shell is a nice idea, but is a little too UNIXy to be a
standard Icon function.  A good candidate for the Icon Program Library
for PIs, or for the "fxtra.c" collection.  Then the next thing we'll
want is a popen() equivalent that calls processes directly, etc.,
etc. ...

From icon-group-request  Wed May 13 12:03:11 1987
From: naucse!sbw (Steve Wampler)
To: arizona!whm
Subject: Re:  more co-expression questions...
Cc: arizona!icon-group
Errors-To: icon-group-request
Status: RO

    From arizona!whm Wed May 13 07:06:42 1987
    Received: by arizona.arizona.edu; Tue, 12 May 87 17:13:59 MST
    Date: Tue, 12 May 87 17:13:50 MST
    From: "Bill Mitchell" <arizona!whm>
    Message-Id: <[e-mail]>
    Received: by megaron.arizona.edu; Tue, 12 May 87 17:13:50 MST
    To: naucse!sbw
    Subject: Re:  more co-expression questions...
    Cc: icon-project

    Assuming that you're talking about co-expressions...

    This program:

    global A,B,C
    procedure main()
        A := create write(@B)
        B := create @C
        C := create "foo"@A
        @A
    end

    prints "foo" when run under the development version of Version 6.

good, that makes sense...

    Ditto for:

    global A,B,C
    procedure main()
        A := create @C & @B & @B & write(@B)
        B := create @A & @C & @C & @B & @C
        C := create @C & @A & @B & @A & "foo"@A
        @A
    end

wow! what a great exam question.  note that both these still work
under the lrao model....

an internal ADT is one where the user of the ADT sees only the
operations on the ADT (in an external ADT, the operations and
the data structure are visible.)  if there is an expression
data type that executes in the environment of definition, and
if such expressions can share the same environment (hence the
restriction that they not be co-expressions, then the following
is a sketch of a internal ADT 'stack':

    procedure makestack()
        local stkstore

       stkstore := []

       suspend {expression for push on stkstore}
       suspend {expression for pop on stkstore}

        # sorry, i don't know the syntax for the above
    end

    .
    .
    .
    getstack := create |makestack()

    every (spush1|spop1) := @getstack
    every (spush2|spop2) := @getstack
    .
    .
    .
    5 @ spush1
    write( @spop1)

it occurs to me that, since i haven't kept up on your organization of
all this, that my view is probably a bit off.

my view of the world (feel free to trash):

    @ --> activates either an expression data type or
        a co-expression, either as unary or binary

    x := coexpression(e)

        converts an expression data type into a co-expression

(i'm not comfortable with the automatic conversion of an expression
into a co-expression on activation - just doesn't seem orthogonal.)

i do not know very much about c-expressions.  perhaps they permit this.

From icon-group-request  Thu May 21 16:17:53 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: RO


From [e-mail] Thu May 21 14:28:03 1987
From: "Mail Delivery Subsystem" <[e-mail]>
Subject: Returned mail: Service unavailable
To: <shafto>
Status: RO

   ----- Transcript of session follows -----
>>> HELO arizona.arizona.edu
<<< 553 arizona.arizona.edu I refuse to talk to myself
554 <arizona![e-mail]>... Service unavailable: Bad file number

   ----- Unsent message follows -----
Received: by arizona.arizona.edu; Thu, 21 May 87 14:23:25 MST
Received: by nprdc.arpa (5.54/ 1.1)
    id AA25008; Thu, 21 May 87 14:23:32 PDT
Message-Id: <[e-mail]>
Date: 21 May 1987 1423-PDT (Thursday)
From: [e-mail]
Reply-To: [e-mail]
To: arizona![e-mail]
Subject: net address change



I'm not sure whether I'm sending this request to the
right address but ...

Please change my net address to

[e-mail]

my phone number to

415/694-6170

and my snail-mail address to

Dr. Michael G.  Shafto
NASA-Ames Research Center
Aerospace Human Factors Lab
Mail Stop 239-1
Moffett Field, CA   94035

Thanks.



From icon-group-request  Tue Jun 23 09:29:18 1987
From: [e-mail] (Jay Mathew Libove)
To: [e-mail]
Subject: Icon source for Xenix
Cc:
Errors-To: icon-group-request
Status: RO

Hi - I have an IBM PC/AT running Santa Cruz Operation (SCO) Xenix System V
release 2 kernel 2.1.3 on which I would like to run Icon. Is there an
ARPAnet / Internet FTPable site from which I can get the sources to Icon?
Is there a version specific to Xenix that will be pretty much guaranteed
to compile?
Thanks for any and all help!


Jay Libove
Arpa:   [e-mail]    Bitnet: [e-mail]
UUCP:   ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP:   ...!{pitt | bellcore} !darth!libove!libove

Disclaimer: My employers really don't care what I say...

From icon-group-request  Tue Jun 23 09:33:41 1987
From: "Ralph Griswold" <ralph>
To: [e-mail], [e-mail]
Subject: Re:  Icon source for Xenix
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: RO

Our FTPable UNIX distribution contains configuration information for
SCO XENIX.  It runs here, both SMM and LMM.  Do an anonymous FTP from
arizona.edu.  cd to icon and get README -- it tells what is available.
You want one of UNIX distribution files (it comes in several forms).
Documentation is included.  Check out v6/setup/pc_xenix_smm and
v6/setup/pc_xenix_lmm, which contains the configuration.

From icon-group-request  Tue Jun 23 10:55:20 1987
From: [e-mail] (Jay Mathew Libove)
To: [e-mail]
Subject: Message of 23-Jun-87 09:59:07
Errors-To: icon-group-request
Status: RO

Someone has a mail forwarding address that isn't working. Here's the
returned stuff.
-Jay

Forwarded message follows:
Return-path: <[e-mail]>
X-Andrew-Authenticated-as: UID422
Received: FROM andrew.cmu.edu VIA trymail
          ID </cmu/math/jl42/Mailbox/andrew.cmu.edu.1872.0.0>;
          Tue, 23 Jun 87 13:05:10 edt
Received: by andrew.cmu.edu (5.54/3.15) id <AA01866> for jl42+; Tue, 23 Jun 87 13:04:33 EDT
Date: Tue 23 Jun 87 10:01:55-PDT
From: The Mailer Daemon <[e-mail]>
To: [e-mail]
Subject: Message of 23-Jun-87 09:59:07

Message failed for the following:
[e-mail].#Internet: No such mailbox
        ------------
Received: from ARIZONA.EDU (for arizona.arizona.edu) by ECLA.USC.EDU; Tue 23 Jun 87 09:59:17-PDT
Received: by arizona.arizona.edu; Tue, 23 Jun 87 09:31:47 MST
Received: by megaron.arizona.edu; Tue, 23 Jun 87 09:29:20 MST
Received: by megaron.arizona.edu; Tue, 23 Jun 87 09:29:18 MST
Received: by arizona.arizona.edu; Tue, 23 Jun 87 09:25:07 MST
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA00707> for [e-mail]; Tue, 23 Jun 87 12:21:50 EDT
Received: via switchmail; Tue, 23 Jun 87 12:21:47 edt
Received: FROM stewartstown VIA queuemail
          ID </cmu/common/mailqs/q007/QF.stewartstown.20deaaa3.6a>;
          Tue, 23 Jun 87 12:19:49 edt
Received: FROM stewartstown VIA qmail
          ID </cmu/math/jl42/.Outgoing/QF.stewartstown.20deaa9f.4695268>;
          Tue, 23 Jun 87 12:19:44 edt
Received: from stewartstown by MS.3.32 via sun3; Tue, 23 Jun 87 12:19:42 edt
Message-Id: <[e-mail]>
Date: Tue, 23 Jun 87 12:19:42 edt
From: [e-mail] (Jay Mathew Libove)
To: [e-mail]
Subject: Icon source for Xenix
Cc:
Errors-To: [e-mail]

Hi - I have an IBM PC/AT running Santa Cruz Operation (SCO) Xenix System V
release 2 kernel 2.1.3 on which I would like to run Icon. Is there an
ARPAnet / Internet FTPable site from which I can get the sources to Icon?
Is there a version specific to Xenix that will be pretty much guaranteed
to compile?
Thanks for any and all help!


Jay Libove
Arpa:   [e-mail]    Bitnet: [e-mail]
UUCP:   ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP:   ...!{pitt | bellcore} !darth!libove!libove

Disclaimer: My employers really don't care what I say...
-------

From icon-group-request  Tue Jun 23 12:53:57 1987
To: Jay Mathew Libove <[e-mail]>
Cc: [e-mail]
Subject: Re: Message of 23-Jun-87 09:59:07
In-Reply-To: Your message of Tue, 23 Jun 87 13:18:26 -0400.
             <[e-mail]>
From: Dave Farber <[e-mail]>
Errors-To: icon-group-request
Status: RO

I am slowly VERY slowly ftping the SCO Xenix version of icon.
I suggest that you all wait till I get it and I will then announce

From icon-group-request  Tue Jun 23 15:56:50 1987
From: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: RO

Icon mailing list

Dear icon-group:
    Please add me to your mailing list.

        Thank you,

--------
William B. McCormick
uucp: !{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!mdc14!wbm


From icon-group-request  Wed Jun 24 01:27:41 1987
From: [e-mail] (Jay Mathew Libove)
To: [e-mail]
Subject: Icon source for Xenix
Errors-To: icon-group-request
Status: RO

Hi - I have an IBM PC/AT running Santa Cruz Operation (SCO) Xenix System V
release 2 kernel 2.1.3 on which I would like to run Icon. Is there an
ARPAnet / Internet FTPable site from which I can get the sources to Icon?
Is there a version specific to Xenix that will be pretty much guaranteed
to compile?
Thanks for any and all help!


Jay Libove
Arpa:   [e-mail]    Bitnet: [e-mail]
UUCP:   ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP:   ...!{pitt | bellcore} !darth!libove!libove

Disclaimer: My employers really don't care what I say...

From icon-group-request  Thu Jun 25 13:24:05 1987
From: [e-mail]
Subject: FTPing Xenix sources to Icon
To: [e-mail]
X-Vms-To: IN%"[e-mail]"
Errors-To: icon-group-request
Status: RO

[ This may be a repost, if so, please forgive- our mailers (whole network)
had a serious problem yesterday...]
I FTP'd to arizona.edu and went looking for the v6/ directory and the
xenix sources to icon, but the directory wasn't there, and the sources
for xenix (in fact sources at all) didn't seem to exist.
Could someone please mail me back and tell me where they are?
Mail addresses to use: [e-mail] [e-mail] arpanet.
Thanks very much
-Jay Libove

From icon-group-request  Thu Jun 25 14:42:59 1987
From: "Kelvin Nilsen" <kelvin>
In-Reply-To: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  Icon source for Xenix
Errors-To: icon-group-request
Status: RO

you can ftp icon materials from arizona.edu using anonymous login.

cd to icon, and get README before proceeding.  source code configurable
for SCO Xenix is available in v6.cpio (or the tar and compressed versions
of the same).  we haven't emphasized the availability of Xenix source
because we had to work around some compiler bugs to make it work, and
weren't sure we wanted to even distribute the code as it currently stands.

Xenix has compiled for release 2.1.3 of the kernel.  i believe we
are currently using release G of the development system.  let me know
if you have any problems with this.


From icon-group-request  Thu Jun 25 14:45:43 1987
From: "Kelvin Nilsen" <kelvin>
In-Reply-To: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  FTPing Xenix sources to Icon
Errors-To: icon-group-request
Status: RO

try cd icon, get README.  source code configurable for xenix is found in
v6.cpio|tar[.Z]


From icon-group-request  Thu Jun 25 18:18:24 1987
From: [e-mail] (Jay Mathew Libove)
To: [e-mail]
Subject: apologies
Errors-To: icon-group-request
Status: RO

My apologies for sending too many posts to too many places of late in
reference to getting icon sources. I didn't realize that the v6/
directory was actually just the v6.* files - and we had some trouble
with the systems on campus here so I wasn't sure what was getting
where when etc..... Anyway, I am currently FTPing... slowly... and I
hope I will be able to post a message soon saying "I got it, it
works!"

Thanks for all the support I have received!

Jay Libove
Arpa:   [e-mail]    Bitnet: [e-mail]
UUCP:   ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP:   ...!{pitt | bellcore} !darth!libove!libove

Disclaimer: My employers really don't care what I say...

From icon-group-request  Thu Jun 25 18:42:44 1987
From: [e-mail] (Jay Mathew Libove)
To: [e-mail]
Subject: No such luck
Cc:
Errors-To: icon-group-request
Status: RO

Well, I said in my last post that I hoped I could soon send a post
saying "I got it and it works!" but I can not. I have tried and failed
three FTP attempts so far. It would be extremely helpful if the files
in question here (specifically the rather large tar and cpio files) were
broken down in to smaller pieces, of say 50 to 100K each. FTPing a 900K
files (or a 2meg file!) over a connection like arizona.edu's is an almost
hopeless adventure...


Jay Libove
Arpa:   [e-mail]    Bitnet: [e-mail]
UUCP:   ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP:   ...!{pitt | bellcore} !darth!libove!libove

Disclaimer: My employers really don't care what I say...

From icon-group-request  Fri Jun 26 08:24:11 1987
From: David Farber <[e-mail]>
Subject: Re:  Icon source for Xenix
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Your message of Thu, 25 Jun 87 14:42:59 MST
Errors-To: icon-group-request
Status: RO

I would recommend you ftp from Udel. The effective rate via the arizona
link is about 1 bit per year. Ask [e-mail] where the stuff is.
We brought it over to help.


From icon-group-request  Fri Jun 26 09:05:31 1987
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: distribution list revision request
Errors-To: icon-group-request
Status: RO



It occurred to me after I sent my previous
net-note that I'm probably getting Icon
e-mail at NPRDC because I'm on a local
redistribution list.

If so, I'll handle that at NPRDC.

Mike S

From icon-group-request  Fri Jun 26 12:25:14 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: Re:  Icon source for Xenix
Errors-To: icon-group-request
Status: RO

I hesitate to contribute to this overblown discussion of FTPing Icon, but
if you have trouble with 192.12.69.1, try 128.196.6.1.

From icon-group-request  Tue Jun 30 21:23:51 1987
From: Michael Shafto <[e-mail]>
Organization: NASA Ames Research Center, Mt. View, Ca.
Subject: Help requested re GC strategy
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: RO

I'm forwarding this from the lisp bb.  I know Icon
incorporates some careful thinking about garbage
collection.

From seismo.css.gov!reed.UUCP!keith Mon Jun 29 00:34:42 1987
Path: aurora!ames!ll-xn!husc6!mit-eddie!uw-beaver!tektronix!reed!keith
From: [e-mail] (Keith Packard)
Newsgroups: comp.lang.lisp
Subject: when to garbage collect
Keywords: mark-sweep, non-incremental
Organization: Reed College, Portland OR
Lines: 17
Status: RO

I am looking for references on algorithms for deciding when to garbage
collect a non-incremental mark/sweep lisp interpreter.  I expect this sort
of thing has been well hashed out by many designers of memory management
software, but I've been unable to locate any reasonable discussion of the
basics.

I don't know how important the architecture of the system is, but it's
designed for a VM system but doesn't pack memory upon completion so this
question is rather important.  If memory isn't swept often enough, large
gaps will in general exist with the resultant loss of locality-of-reference.
But, because the system is not incremental, the cost of calling the
garbage-collector is rather substantial.  So the obvious solution is a
clever algorithm to decide when to GC.


keith packard
tektronix!reed!keith

From icon-group-request  Sat Jul  4 17:57:59 1987
From: naucse!sbw (Steve Wampler)
To: arizona!icon-group
Subject: failing memory...
Cc: arizona!icon-project, arizona!ralph
Errors-To: icon-group-request
Status: RO


I was wondering what people thought the best way was to handle
the following problem:

   I have a a series of book title,author,publisher, etc... sequences
    that I'd like to sort by title, or author, or publisher.  What
    is the best way to handle this multi-keyed sort.  One solution,
    to put records of the information into a table keyed by the
    sort field, fails pretty miserably.  I suppose that one
    could build a list of lists (ideally a list of book records),
    but I've forgotten if any of the new options to sort() allow
    one to sort a list of lists (or records) by any field.

   Any suggestions on how to proceed?  Of course, it would also be
   nice to be able to do a multikeyed sort (all books, sorted by
   title within author within publisher [say]), but as it stands
   now, sort() is not guaranteed to be stable.

   I'd rather not do my own sort procedure...

    -Thanks, responses to Icon-group, please

From icon-group-request  Sun Jul 26 13:42:22 1987
From: olson <[e-mail]>
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Subject: Icon on Sun3
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: RO


(Sorry to bother you, but my addresses seem to be out of date.)

Is there a version of Icon that runs on Sun3 workstations?
Who do I contact?

Thanks,
Todd Olson

ARPA: [e-mail]
UUCP: {ihnp4,allegra,...}!cornell!lasspvax!olson
US Mail: Dept Physics, Clark Hall, Cornell University,
     Ithaca, New York 14853-2501

From icon-group-request  Fri Oct  2 16:38:55 1987
From: Ken Yap <[e-mail]>
Organization: U of Rochester, CS Dept, Rochester, NY
Subject: Re: Seeking Humanities Programming Texts (Pascal Preferred)
References: <21261XBQ@PSUVM>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

This appeared in comp.lang.pascal so you Iconers should have a go
at disabusing this person's misconceptions.

In article <21261XBQ@PSUVM> [e-mail] (Ed Winograd) writes:
|I'm looking for a good beginning programming text for my students
|in Liberal Arts 482 at Penn State.  The course focuses on TEXT PROCESSING
|rather than on number crunching and is designed for humanities majors
|who have no previous programming experience.
|
|I'm currently teaching my class PL/C, a somewhat stripped-down version
|of PL/1.  However, since this language is generally available only on
|IBM mainframe systems, it's not the optimal language to use.  Although
|I know that Digital Research puts out a PL/1 for IBM PC's, it's very
|expensive, and I have never seen ANY references to it (if anyone has
|used it, what's it like?  Is it compatible with mainframe PL/1?).
|
|I realize that SNOBOL and ICON are widely used for text processing,
|but SNOBOL is so radically different from any other language that
|I hesitate to use it (but am willing to be convinced otherwise, if
|there's a good TEXT to go with it -- the Green Book is MUCH too
|hard for beginners).  And I'm a little hesitant to use ICON, since
|so many of the implementations seem to be public domain ones of
|unknown quality and robustness.
|
|The best language to teach seems to be Pascal, since it's a structured
|language which is widely available, and not as dangerous as C for
|beginning programmers.  But the lack of string primitives in ISO
|Standard Pascal is a major problem.
|
|So, my main question is if anyone knows of a Pascal text for
|humanities programming that uses a version such as UCSD Pascal or Turbo
|Pascal.  If so, I'd very much like to hear from you.  Otherwise,
|I'm open to considering other languages if there's a GOOD text for them
|that my beginners/humanities students could use.  The machines available
|to me are an IBM mainframe using VM/CMS, IBM PC's, and Macintoshes.
|

Icon of dubious quality and not robust? Nonsense. Most of the
implementations are of U of Arizona descent, and are written in C.
Works real well.  There are IBM PC and Mac versions. I don't know about
those implementations but I'm very happy with the Unix implementation.
I can prototype an application faster than in Pascal or C. And I don't
mean text processing only, I test out search algorithms with Icon.

    Ken

From icon-group-request  Fri Oct  2 19:55:09 1987
From: Adam Beguelin <sunybcs!boulder![e-mail]>
Organization: University of Colorado, Boulder
Subject: What is Icon Anyway?
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

So what is Icon anyway?  Is it a graphical programming language?
I just subscribed to this group but from the one article I read there
are public domain versions out for unix, ibm-pcs and macs.  Could
someone fill me in on what icon is and maybe even point me to a
public domain unix or mac version?

Thanks in advance for the education.

Adam Beguelin
[e-mail]
University of Colorado
Boulder, CO

From icon-group-request  Fri Oct  2 23:02:08 1987
From: "Richard L. Goerwitz III" <[e-mail]>
Organization: U Chicago Computation Center
Subject: Speeding up Icon prgms.
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

I always hate to post my code, since it's usually not very good (I strive for
readability more than anything else).

What I'd like to know is whether there is somewhere in this program that I
might have written things in such a way as to get increased speed.  I'm not an
experienced Icon programmer, so any ideas would be welcome.

What this procedure does is split up texts formatted according to the standards
followed in the Thesaurus Linguae Graecae.  Works are marked by ~a"title",
books by ~c"bookname", chapters by ~x and verses by ~y.  A typical header looks
like this:  ~a"Bible"b"Hebrew"c"genesis".  Subsequent chapters and verses are
marked with ~x and ~y, respectively (on a line of its own).

A typical text has:
~a"Bible"b"Hebrew"c"Genesis"
GENESIS
M7493K987XCKN2892(093K2309832K 09KSKLJXC98U4KLS 9832KKXZCKJS
~x
PQOIWEUR 039854 V0-9834()LKWLJ23J $OKSLKXCPKL
etc.

The next book will begin:
~c"Exodus"
EXODUS
etc.

What I am trying to do is splitup the chapters into individual files, naming
each file after the title contained in the expression c"chapter".


procedure main()

  y := 0

  if not (outtext2 := open("junkfile","w"))
  then stop("cannot open chapter output file")

  write("input filename\:")
  if not (intext2 := open(read()))
  then stop("cannot open input file")

  write("finding first chapter")
  while line2 := reads(intext2,80) do
      {if find("\~",line2) then
          {if find("c\"",line2) then
              {close(outtext2)
              chapter := (line2[find("c\"",line2) + 2:0] ? move(upto("\"") - 1))
              outtext2 := open(chapter,"w")
              write(y +:= 1," chapters")
              }
          }
      line2 := line2[1+:find("  ",line)]
      write(outtext2,line2)
      }
end

NB:  Usually I get these things off tape, so that I need to strip trailing
blanks off of the 80 character records the files are usually arranges in.
That explains the need for "reads(intext2,80)" and at the end "line2[1+:find
..."

As I said above, my concern is for speed.  I want to write some programs to
do more complex things to these texts, among them go to specific points in
given files, and then reverse the string, so as to present natural Hebrew
left-to-right order (I use special escape sequences to signal font changes
to my terminal - a PC with a Hercules Plus card).  But anyway, I'm concerned
with questions like, "Which is faster, find or match, or upto?"  How does one
get to a specific point in a file in the least amount of time?

Thanks to whoever might answer.

                              !ihnp4!gargoyle!sphinx!goer
                              [e-mail]

                             -Richard Goerwitz



From icon-group-request  Mon Oct  5 13:13:12 1987
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re: Speeding up Icon prgms.
Errors-To: icon-group-request
Status: O

[ Caveat:  I am new to this mailgroup, and so my Icon has been self-taught.
   I'll be asking my own, similar, questions about my programs soon! ]

"Richard L. Goerwitz III"  wrote in <[e-mail]>:

> What I'd like to know is whether there is somewhere in this program
> that I might have written things in such a way as to get increased
> speed.  I'm not an experienced Icon programmer, so any ideas would be
> welcome.

First of all, have I understood the text format correctly?  I presume what
you want is to find a line beginning with a tilde "~" and a chapter name, extract the
chapter name from it, then to copy that header line and all remaining lines
up to but not including the next such line.

One problem with the existing program is it might fail on a line such as

~a"Book"b"Generic"
                ^^
because the "c\"" will be thought to refer to a chapter, so we'll try
and fix that as a by-product.

Trimming spaces is most easily done on input, using the trim() function.

I presume your junkfile only exists to throw away stuff before the first
chapter heading;  you could do this either by writing to /dev/null (on a
U**X system) , or by re-structuring the program to simply not copy that
first section.

Let's suppose we have a procedure which will identify one of the "magic
lines" and return the chapter name.  The guts of the program could then
be:

    procedure main()

    line := trim(read()) | stop("Empty input")

    until chapter := magicline(line) do
        line := trim(read()) | stop("No chapters")
    #
    #    chapter now has chapter name in it
    #
    repeat {
        outtext2 := open(chapter,"w")
        write(outtext2,line)
        while line := (trim(read()) | break break) do
            if chapter := magicline(line) then break
            else write(outtext2,line)
        close(outtext2)
    }
    close(outtext2)            #

end

The loop structure seems horrible, but I haven't written any Icon in a while.
That takes care of the main problem.  Now what about the magic lines?
Remembering that every line is checked for magicness this test needs to
be reasonably quick, but I see no way around some fairly complex checks
on the syntax to avoid the problem I outlined above:

    procedure magicline(l)
    static namechars
    initial namechars := &ucase ++ &lcase    # assumes letters only
    l ? {
        if ="~" then {            # can't be magic without "~"
        while move(1) ~== "c" do    # other bits ignored
            ( move(1) & tab(many(namechars)) & move(1) ) | fail
            ( c := (="c\"" & write("++",tab(many(namechars))))) | fail
        return c
        }
    }
    end

I tried this on some simple test data:

~a"Bible"b"Hebrew"c"Genesis"
GENESIS
M7493K987XCKN2892(093K2309832K 09KSKLJXC98U4KLS 9832KKXZCKJS
~x
PQOIWEUR 039854 V0-9834()LKWLJ23J $OKSLKXCPKL
~c"Exodus"
EXODUS

and got the following files:

Genesis:
~a"Bible"b"Hebrew"c"Genesis"
GENESIS
M7493K987XCKN2892(093K2309832K 09KSKLJXC98U4KLS 9832KKXZCKJS
~x
PQOIWEUR 039854 V0-9834()LKWLJ23J $OKSLKXCPKL

Exodus:
~c"Exodus"
EXODUS
which seems to be what you wanted.  As to whether it's any quicker or
better-structured, I leave that to you to decide.  These are the sorts
of things I'm hoping the group will help me with!

Steve

From icon-group-request  Mon Oct  5 15:14:41 1987
From: Michael Shafto <[e-mail]>
To: [e-mail], sunybcs!boulder![e-mail]
Subject: Re:  What is Icon Anyway?
Cc: [e-mail]
Errors-To: icon-group-request
Status: O

Let me know if the experts at Arizona don't reply.

Mike Shafto

From icon-group-request  Mon Oct  5 15:20:59 1987
From: Michael Shafto <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  Speeding up Icon prgms.
Cc: [e-mail]
Errors-To: icon-group-request
Status: O

Richard --

For a kindred text-processing spirit, call Jim Nye at the Regenstein
Library, 312/962-8430

Mike Shafto

From icon-group-request  Tue Oct  6 15:09:17 1987
From: ihnp4!ihlpe!orf
Message-Version: 2
>To: /addr=ihnp4!gargoyle!sphinx!goer, /addr=ihnp4!arizona!icon-group
End-Of-Header:
Email-Version: 2
X-Postmark: owen.r.fonorow attis iw1z261 xmpi4000 3129797173 ihlpe!orf
To: arizona!icon-group, gargoyle!sphinx!goer
Subject: Re: Speeding Up Icon Programs
Ua-Message-Id: <post.orf.Tue 06 Oct 1987 16:29 CDT>
End-Of-Protocol:
Content-Length: 2003
Errors-To: icon-group-request
Status: O

Richard,

You asked for some guidelines about improving the performance of Icon programs.
The following rules of thumb seem to apply to the small program you sent:

--------------------------------------------------------------------------

  o match() is in a sense an "anchored" find() - so if you don't need
    to look through the entire string (i.e. you know the sequence will
    be the first two characters) then use match().  If your data is
    representative then:

      {if find("\~",line2) then
          {if find("c\"",line2) then

    can be replaced by:

      {if match("~c",line2) then

   This should avoid *many* unnecssary string comparisons.

  o Use correct "types" in built-in functions. Since upto() expects a
    cset, then upto("\"") is better replaced by upto('"')

  o Subscripting is expensive. Avoid it.

    This implies that the following lines need to be changed:

              chapter := (line2[find("c\"",line2) + 2:0] ? move(upto("\"") - 1))
      line2 := line2[1+:find("  ",line)]


    One way is to set up a string scanning expression with line2 like this:

         while line2 := reads(intext2,80) do
         line2 ? {
             if match("~c") then
                  {close(outtext2)
                   move(3) &     # Assumes ~c"  sequence....
                   chapter :=  move(upto('\"')
                   outtext2 := open(chapter,"w")
                   write(y +:= 1," chapters")
                   }
              }
          write(outtext2,trim(line2))
          }
       end

--------------------------------------------------------------------------

Again, This may not work with your data. My intent was to answer your
question. There may be issue of getting information after the chapter
name on a ~c"  line.  To summarize:

   o Use match() if appropriate to limit string comparisons
   o Use correctly typed arguments to built-in functions
   o Avoid subscripting.

How this helps...

O. Rick Fonorow
ihnp4!ihlpe!orf
[phone]

From icon-group-request  Wed Oct  7 06:17:37 1987
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re:  Speeding up Icon prgms.
Errors-To: icon-group-request
Status: O

Ahem.  I suppose we all have our off-days.  I looked at the code I
produced and decided it just wouldn't do (my hacking days came back
to haunt me).  Here is a re-write, more in keeping with the spirit of
the Icon language.  Thanks to the group for not taking me to task (or
is no-one listening?)  The output is tha same as for the previous one.

procedure main()

    outtext2 := open("/dev/null","w") | stop("Cannot open /dev/null!!")

    while line := read() do
    line ? {
        if ="~" then            # it's text if no "~"
        while c := move(1) &        # parse a heading bit
            ="\"" & (chap := tab(many(~'"'))) & ="\"" do
        if c == "c" then {        # new chapter found
            close(outtext2)        # so open new file
            outtext2 := newchapter(chap)
            break            # stop parsing
        }
        write(outtext2,line)        # write to chapter file
    }
    close(outtext2)

end

procedure newchapter(chapname)
    return open(chapname,"w") | stop("Cannot create chapter ",chapname)
end

regards

Steve

From icon-group-request  Wed Oct  7 15:21:22 1987
From: "Mr. nEtural" <[e-mail]>
Organization: Up against the wall of SCIENCE
Subject: Re:  Speeding up Icon prgms.
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

) Richard --
) For a kindred text-processing spirit, call Jim Nye at the Regenstein
) Library, 312/962-8430
) Mike Shafto

Note:  The prefix here has changed from 962 to 702.  James Nye's
number is now 312-702-8430.

From icon-group-request  Wed Oct  7 17:47:20 1987
From: Ralph Griswold <[e-mail]>
Organization: U of Arizona CS Dept, Tucson
Subject: What is Icon?
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O


For persons who may not be familiar with the Icon programming
language, here's a brief description and a pointer to more
information.

Icon is a high-level, general-purpose programming language that is
well-suited for nonnumerical applications.

Icon supports several data types, including variable-length strings,
sets, lists with flexible access methods, and tables with associative
lookup. Storage management is automatic.

Icon has a goal-directed evaluation mechanism that allows concise
solutions of many programming tasks to be formulated easily.
Its string scanning facility is comparable to pattern matching in
SNOBOL4, but Icon allows all language operations to be used in the
analysis and synthesis of strings.

Icon is available for a wide range of computers, including most UNIX
systems, MS-DOS, VAX/VMS, the Atari ST, the Amiga, and the Macintosh
(under MPW). These implementations are in the public domain and
are available at a nominal cost from the Icon Project at the University
of Arizona. For more information, contact:

    Icon Project
    Department of Computer Science
    Gould-Simpson Building
    The University of Arizona
    Tucson, AZ   85721

    [phone]

    [e-mail]
    ... {ihnp4, allegra, noao}!arizona!icon-project

Incidentally, the the name "Icon" has nothing to do with graphic images used
to identify files on computer screens. The name was chosen before the latter
use of the word came into vogue. The confusion is unfortunately, but it's too
late to do anything about it.

From icon-group-request  Sun Oct 11 06:46:02 1987
From: [e-mail]
Subject:  New language features for Icon 7?
To: [e-mail]
Errors-To: icon-group-request
Status: O

I have a couple of suggestions for additions to Icon.  Perhaps it's not too
late to get them into Version 7, if you like them.

(1) There ought to be a notation for procedures with a variable number of
arguments, such as "write".  I propose that the argument list be put in square
brackets, just like any other list (with the restriction that there be only
one argument).  Here's how to do "write" very elegantly in this notation:

procedure write[args]
    local a, f

    f := &output
    every a := !args do
        if type(a) == "file" then
            f := a
        else
            write1(f, a)    # write1(f, v) writes the value v to the file f
    write1(f, "\n")
end

(2) The Icon scoping mechanism is very weak, and is also almost independent of
the other aspects of the language.   As my programs get large, I need some way
of restricting the scope of global variables without eliminating them
altogether.  I would like to see a "package" mechanism, where a package simply
groups a set of global declarations (including procedures) and specifies which
ones are exported to the surrounding environment.  For simplicity, a package
inherits anything known in the environment that surrounds it.  For example:

package P1 exports write_line, write_page, page_number
global current_line, page_number
record page_image(...)
procedure write_page(...); ... ; end
procedure insert_header(...); ... ; end
procedure write_line(...); ... ; end
procedure justify_line(...); ... ; end
end P1   # or perhaps "end package" or even just "end"

Although a multi-level package mechanism would be best, even a one-level
version of it would be very useful.

Paul Abrahams

From icon-group-request  Mon Oct 12 02:50:27 1987
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re: New language features for Icon 7?
Errors-To: icon-group-request
Status: O

1. Variable # of arguments:
   Seems reasonable if it's not too hard to incorporate.

2. The Icon scoping mechanism.
   I agree.  The worst feature of things as presently set up is that on
   those odd occasions when you *have* to use a global variable in a package
   there is no protection against some other (possibly imported in ucode)
   package declaring the same global and using it.  I would suggest a simpler
   syntax:

   private var1, var2, var2

   should make the named variables globally available *only* within the scope
   of the current source file.

   Steve

From icon-group-request  Mon Oct 12 08:25:36 1987
From: [e-mail]
Subject:  Packages for Icon?
To: [e-mail]
Errors-To: icon-group-request
Status: O

I hope that any package mechanism for Icon won't adopt what I consider to be
the insane C rule that associates scopes with file structure.

Steve Holden also raises an interesting question with his proposal for
"private": should the default be public or private.  I think it should be
private; things should only be public if so declared.   It would also be
useful to have an outermost global level, both to provide compatibility with
Icon as it is and to avoid any requirement that packages be used.

I believe that all this is a translation-time and link-time issue, with little
or no impact on the Icon compiler, which is the most difficult part of the
Icon implementation.  Am I right?

Paul Abrahams

From icon-group-request  Mon Oct 12 12:22:18 1987
From: Mr Binary <rhesus![e-mail]>
Organization: UW-Madison Primate Center
Subject: Re: What is Icon?
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

Ralph Griswold gave the mail and e-mail addresses for more info
on Icon.  If you want, you can just ftp anonymously from arizona.edu.
That's how I got mine.  It took a while, though, if I remember correctly.

---
Paul DuBois     UUCP: {allegra,ihnp4,seismo}!uwvax!rhesus!dubois    |
                ARPA: [e-mail]              --+--
                                                                    |
"Suffering is the finger exercising of the spirit." - Mr. Theo      |

From icon-group-request  Mon Oct 12 18:41:31 1987
From: [e-mail]
Subject:  Generating a list
To: [e-mail]
Errors-To: icon-group-request
Status: O

Is there an elegant way to generate a list containing the result sequence of a
given expression?  I can write the following procedure that does it (I think),
but perhaps there's a way to do it better:

# listgen(a,n) returns a list whose elements are the result sequence of a.
# If n is specified, then the length of the list is limited to n.

procedure listgen{a}
    local e, retval
    retval := []
    if integer(n) then
        every |(e := @a) \ n do put(retval, e)
    else
        while e := @a put(retval, e)
    return retval
end

Paul Abrahams

From icon-group-request  Thu Dec 31 11:48:51 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: <[e-mail]>
Subject: Generating a list
Errors-To: icon-group-request
Status: O

   Date:  Mon, 12 Oct 87 21:22 EDT
   From: [e-mail]

   Is there an elegant way to generate a list containing the result
   sequence of a given expression? ...

I usually use the following idiom, where expr is the expression for
which you want the result sequence.

    ls := []
    every put(ls, !expr)

From icon-group-request  Tue Oct 13 18:43:42 1987
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: variable args and packages
Errors-To: icon-group-request
Status: O


    Date:  Sun, 11 Oct 87 09:42 EDT
    From: [e-mail]

    (1) There ought to be a notation for procedures with a variable number of
    arguments, such as "write".

Version 7 of Icon (which we expect to release in a few months) will have
a mechanism for handling a variable number of arguments. It will allow you
to indicate that the last parameter should be list of the remaining
arguments. The procedure declaration will look like:

   procedure p(a, b, c[])

If this is called with

   p(1, 2, 3, 4, 5)

you will have

   a === 1
   b === 2
   c === [3, 4, 5]

If this is called with

   p(1)

you will have

   a === 1
   b === &null
   c === []


    (2) The Icon scoping mechanism is very weak ...
    I would like to see a "package" mechanism, where a package simply
    groups a set of global declarations (including procedures) and specifies
    which ones are exported to the surrounding environment.

Some of the current research here at the U of A is aimed at developing
an optimizing compiler (if this progresses to distribution, it certainly
won't be with version 7). In order to do a reasonable job of optimization
the compiler will have to know which variables are local to the
compilation unit (that is, the file), which are exported and which are
imported; so we will at least need to develop a simple "package" mechanism
at the file level. This is what C does and seems to provide adaquate
modularization for many programs. Does a more complex mechanism give enough
benifit to justify the complexity?

From icon-group-request  Fri Oct 16 02:07:52 1987
From: "J. A. \"Biep\" Durieux" <mcvax!botter!klipper![e-mail]>
Organization: VU Informatica, Amsterdam
Subject: Re: What is Icon?
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

If I read&remember well, the name Icon was chosen because the group considered
itself rather iconoclastic. Somewhat of an amazing behaviour, for an
icono*clastic* group to call a thing they love and care *Icon*.

The world is full of wonders.
--
                        Biep.  ([e-mail] via mcvax)
    Warning: this life is only an alpha test release, and will probably
    not be bug-free. No responsibility is taken for any damage that may
    result from the use of this life.  Send any bug reports or enhance-

From icon-group-request  Fri Oct 16 10:34:03 1987
From: [e-mail]
Subject:  Arglists and packages
To: [e-mail]
Errors-To: icon-group-request
Status: O

This is a reply to Ken Walker's comments on my proposals.

(1) The notation
    procedure p(a,b,c[])
is quite elegant, and more general that what I had proposed.  But why not
allow the form
    procedure[a]
as a synonym for
    procedure(a[])

(2) I'd be quite happy with a package mechanism that would provide only for
exporting procedures and not variables.  That would avoid the need to deal
with any difficulties in optimization, because the whole problem would become
very static.  That is, packages would have variables declared internal to
them, and would inherit all variables in their enclosing packages.  The
optimization problems are then no different than those we now have with global
versus local.

With this kind of packaging mechanism, the translator and compiler would not
have much more work to do; the linker would bear the brunt of the task.
The only tricky run-time issue is what the "proc" function does.  But this
could be solved by conceptually associating a run-time symbol table with every
procedure; the name in the "proc" call would be looked up in that table.
In practice, the symbol tables could be combined.

I dislike the C approach to scoping because it forces every package to reside
in a separate file and thus leads to the proliferation of files.  It also
leads to additional complications in resolving the different sets of externs,
a problem that has led to incompatibilities among C compilers.  Finally, it
excludes the possibility of nested packages, which in fact are not at all hard
to do.  (Nested procedures are a different story, and I'm not advocating
them.) Please don't do it that way.

Paul Abrahams

From icon-group-request  Fri Oct 16 13:15:35 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: <[e-mail]>
Subject: Arglists and packages
Errors-To: icon-group-request
Status: O

I rather like the package idea, but any new scoping mechanism should
be a superset of the existing mechanism.  This is necessary to insure
backward (forward, upward, downward) compatibility with previous
versions of Icon.  It may come as a surprise to those who think of
Icon as a teaching language, or a language for small one-shot
programs, but there are actually large Icon programs out there in
regular use.  It would be unkind to obsolete all of these programs by
not supporting their scoping mechanism in v7 of Icon.

As a reminder, Paul Abrahams suggested a scheme where packages are
defined by declarations of the form:

    package <name> exports <name>, <name>, ...
    <global declaration>
    <global declaration>
    ...
    end

where the <global declaration>s are local to the package unless they
appear in the export part of the declaration.  This can easily be made
a superset of the current scheme by defining all declarations that
don't occur in a package as members of package global, which exports
everything.  (Maybe Paul Abrahams had this in mind, I couldn't tell.)

Another suggestion is to make "export" a separate declaration from
package.  This allows an orthogonal "import" declaration, for packages
that want to restrict the visible name space.  For backward
compatibility, all modules would automatically import everything from
the global package.

From icon-group-request  Sat Oct 17 15:30:12 1987
From: ihnp4!ihuxy!nowlin
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: variable args and packages
Ua-Message-Id: <post.nowlin.Fri 16 Oct 1987 07:01 CDT>
End-Of-Protocol:
Content-Length: 3872
Errors-To: icon-group-request
Status: O


> Version 7 of Icon (which we expect to release in a few months) will have
> a mechanism for handling a variable number of arguments. It will allow you
> to indicate that the last parameter should be list of the remaining
> arguments. The procedure declaration will look like:
>
>    procedure p(a, b, c[])
>
> If this is called with
>
>    p(1, 2, 3, 4, 5)
>
> you will have
>
>    a === 1
>    b === 2
>    c === [3, 4, 5]
>
> If this is called with
>
>    p(1)
>
> you will have
>
>    a === 1
>    b === &null
>    c === []

Why not pass all the arguments as a list (like the command line arguments
in the main procedure) instead of having any formally declared arguments?
This isn't a purely rhetorical question.  It only seems natural to pass a
list to a procedure if you want a variable number of arguments.  The Icon
printf() procedure I've seen worked this way.

If the expression with which a procedure is called is forced to use a
notation indicating a variable number of arguments it will make for more
readable code.  One of the trickier things to explain to novice C users is
the concept of a variable number of arguments to the family of printf()
system calls.  The biggest reason is that the syntax of a calling
expression does nothing to indicate that there's a variable number of
arguments.  On the other hand take the exec() family of system calls.  The
syntax of these functions makes it clear that there is a variable number of
arguments.  (Never mind that novice C programmers never figure out how to
set them up.)

Icon already has a simple mechanism for passing a list to a procedure and
it seems like a waste of resources to make it more formal.  If you want to
call p(), from the above example, with a variable number of arguments and
there are only three formal arguments in the declaration call it like this:

   p(1, 2, [ 3, 4, 5 ])

You end up with the same kind of parsing work in the procedure itself that
exists with the proposed formal mechanism, but with this syntax what's
happening is clear from the calling expression.  It also has the advantage
that the missing third argument is &null instead of an empty list, if only
one argument is used.  That follows the current Icon missing argument
convention.

What you currently have is the need for some documentation explaining how
to use Icon in this way.  Not the need for a more formal mechanism to
provide a variable number of arguments.



>     (2) The Icon scoping mechanism is very weak ...
>     I would like to see a "package" mechanism, where a package simply
>     groups a set of global declarations (including procedures) and specifies
>     which ones are exported to the surrounding environment.
>
> Some of the current research here at the U of A is aimed at developing
> an optimizing compiler (if this progresses to distribution, it certainly
> won't be with version 7). In order to do a reasonable job of optimization
> the compiler will have to know which variables are local to the
> compilation unit (that is, the file), which are exported and which are
> imported; so we will at least need to develop a simple "package" mechanism
> at the file level. This is what C does and seems to provide adaquate
> modularization for many programs. Does a more complex mechanism give enough
> benifit to justify the complexity?

The C mechanism of scoping "static global" variables to the source file in
which they're declared is a handy thing to have.  If Icon were to provide
this type of scoping it would be useful.  A more complex scoping scheme
would be overkill.  PLEASE, don't use "static global" like C.  The
difference between "static global" and "static local" variables is another
one of those things that you're never really sure you've gotten across to
new C programmers.  Use any keyword but "static"!

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)

From icon-group-request  Sat Oct 17 15:31:57 1987
From: ihnp4!ihlpe!orf
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
End-Of-Header:
Email-Version: 2
X-Postmark: owen.r.fonorow attis iw1z261 xmpi4000 3129797173 ihlpe!orf
To: arizona!icon-group
Subject: Variable Scoping
Ua-Message-Id: <post.orf.Fri 16 Oct 1987 15:49 CDT>
End-Of-Protocol:
Content-Length: 1184
Errors-To: icon-group-request
Status: O

To: ihnp4!arizona!icon-group
Subject: Re: variable args and packages

>    (2) The Icon scoping mechanism is very weak ...
>    I would like to see a "package" mechanism, where a package simply
>    groups a set of global declarations (including procedures) and specifies
>    which ones are exported to the surrounding environment.
>
> >This is what C does and seems to provide adaquate
> >modularization for many programs. Does a more complex mechanism give enough
> >benifit to justify the complexity?


I'd just like to point out that in the case here where Icon was used to
implement a large applications program, we had from 3 to 5 developers working
on a system that ended up being about 20,000 NCLC before being translated to C.
We didn't realize there was a problem with weak scoping. That is there were
few - if any - software bugs that resulted from incorrect scoping (i.e. using
an unintended variable with the same name).

We did have to be careful about undeclared local identifiers in shared
ucode libraries, but we made it a practice to always translate with
-u flag to icont.

Rick Fonorow

p.s. Icon group: my new address is ihnp4!ihlpe!orf  (not iwsam!orf)

From icon-group-request  Sun Oct 18 14:22:35 1987
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: variable args
Errors-To: icon-group-request
Status: O

>   Date:  Fri, 16 Oct 87 13:28 EDT
>   From: [e-mail]
>
>   (1) The notation
>       procedure p(a,b,c[])
>   is quite elegant, and more general that what I had proposed.  But why
>   not allow the form
>       procedure[a]
>   as a synonym for
>       procedure(a[])

I agree that your form for the case of one argument looks nicer than
that of the general form, but I don't feel that the additional syntax
is justified when you only save 2 key strokes and the feature is not
likely to be used much.

>   From: ihnp4!ihuxy!nowlin
>   Date: Fri 16 Oct 1987 07:11 CDT
>
>   Why not pass all the arguments as a list (like the command line
>   arguments in the main procedure) instead of having any formally
>   declared arguments?

The motivation for adding variable argument lists to Icon is that
any language which has built-in functions which take a variable
number of arguments (write, writes, and stop) but does not allow
user defined procedures to take a variable number of arguments is
incomplete. This argument has been around for a long time, but it
is only recently that someone (Bill Mitchell and Dave Gudeman) has
actually implemented a variable argument feature in Icon.

From icon-group-request  Sun Oct 18 15:14:06 1987
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: packages
Errors-To: icon-group-request
Status: O

>  Date:  Fri, 16 Oct 87 13:28 EDT
>  From: [e-mail]
>
>  (2) I'd be quite happy with a package mechanism that would provide only for
>  exporting procedures and not variables.  That would avoid the need to deal
>  with any difficulties in optimization, because the whole problem would become
>  very static.  That is, packages would have variables declared internal to
>  them, and would inherit all variables in their enclosing packages.  The
>  optimization problems are then no different than those we now have with
>  global versus local.

The optimizations that I am interested in are based on type inference and
I want to be able to do them without looking outside the compilation
unit. I can accept the "outside world" sharing variables with the
compilation unit, but I want to know which ones are actually shared.
I have no way of knowing what affect an outside procedure will have
on shared variables and must assume the worst. If I can limit the
affect to a few variables I can do a better job of type inference.

>  From: ihnp4!ihlpe!orf
>  Date: Fri 16 Oct 1987 15:50 CDT
>
>  I'd just like to point out that in the case here where Icon was used to
>  implement a large applications program, we had from 3 to 5 developers working
>  on a system that ended up being about 20,000 NCLC before being translated to
>  C. We didn't realize there was a problem with weak scoping. That is there
>  were few - if any - software bugs that resulted from incorrect scoping
>  (i.e. using an unintended variable with the same name).

It seems to me that a big advantage of some kind of packaging mechanism
would be in program maintenance. It is often a good idea to look to see
how a variable or procedure is used before changing code that will
affect it (just in case you are making some false assumptions). If you
cannot limit the scope of the name, you have to look in all program
files. Even with reasonable tools, this search is a pain when more than
one file is involved.

From icon-group-request  Sun Oct 18 15:27:04 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: <[e-mail]>
Subject: variable args and packages
Errors-To: icon-group-request
Status: O

   From: ihnp4!ihuxy!nowlin
   Date: Fri 16 Oct 1987 07:11 CDT

   Why not pass all the arguments as a list (like the command line
   arguments in the main procedure) instead of having any formally
   declared arguments? ....  The Icon printf() procedure I've seen
   worked this way.

The Icon printf() procedure had to work that way because there was no
more elegant way to do it.  There is a conceptual difference between
printf([...]) and printf(...).  In the first, a single parameter is
being passed to printf() as a list, in the second an arbitrary number
of parameters is being passed.  The printf() procedure may have to
treat the cases the same, but to the caller they are different cases.

   If the expression with which a procedure is called is forced to use
   a notation indicating a variable number of arguments it will make
   for more readable code.

I would say just the opposite.

   One of the trickier things to explain to novice C users is the
   concept of a variable number of arguments to the family of printf()
   system calls.  The biggest reason is that the syntax of a calling
   expression does nothing to indicate that there's a variable number
   of arguments.

I suspect that the hard thing to explain is that arguments following
the format depend on the format.  I never had any trouble explaining
to complete novices how Pascal i/o procedures work.  These procedures
take a variable number of arguments also.

   ....  If you want to call p(), from the above example, with a
   variable number of arguments and there are only three formal
   arguments in the declaration call it like this:

      p(1, 2, [ 3, 4, 5 ])

   ... with this syntax what's happening is clear from the calling
   expression.

But we don't want what's happening to be clear from the calling
expression.  The whole point of procedure abstraction is to make it so
the calling procedure doesn't know what goes on in the called
procedure, only what the affect is.  The fact that the called
procedure has to make a list of its arguments (to handle a variable
number) should be opaque to the calling procedure.

   It also has the advantage that the missing third argument is &null
   instead of an empty list, if only one argument is used.

This ``advantage'' was decided to be a peculiar and surprising affect,
so we took deliberate steps to make a missing list argument be an
empty list instead of &null.  This lets the programmer loop directly
on the list without first checking whether it is &null or not.
Presumably, if the list is empty, then the loop will never be
executed.

   .... PLEASE, don't use "static global" like C.

Little chance of that.  Actually, there is little chance of any change
in Icon's scoping mechanism because the change would be both
non-trivial and uninteresting (from the point of view of language
research).  Of course, if someone else wanted to implement a better
scoping mechanism for Icon, I'm sure Ralph Griswold would be glad to
consider putting it in the distributed version of Icon...

From icon-group-request  Sun Oct 18 17:56:59 1987
From: [e-mail]
Subject:  Variable number of args (again)
To: [e-mail]
Errors-To: icon-group-request
Status: O

In response to Ken Walker's remark on my p[a] notation:  I realized
afterwards that p[a,b,c] is a nicer way to write what would be
p(a,b,c[]) in the other notation.  Another advantage is that it doesn't
have similar forms that are illegal, such as p(a,b[],c) or p(a[],b,c[])
(or do those indeed have a meaning)?

I agree that whatever the notation, it should be used in the procedure
definition rather than at the point of call.

Paul Abrahams

From icon-group-request  Mon Oct 19 11:37:55 1987
From: "Kenneth Walker" <kwalker>
In-Reply-To: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  Variable number of args (again)
Errors-To: icon-group-request
Status: O

>  Date:  Sun, 18 Oct 87 20:53 EDT
>  From: [e-mail]
>
>  In response to Ken Walker's remark on my p[a] notation:  I realized
>  afterwards that p[a,b,c] is a nicer way to write what would be
>  p(a,b,c[]) in the other notation.  Another advantage is that it doesn't
>  have similar forms that are illegal, such as p(a,b[],c) or p(a[],b,c[])
>  (or do those indeed have a meaning)?

Your notation is more compact, but I like the fact that p(a,b,c[])
emphasizes the asymmetry of argument handling. As for p(a,b[],c), I
suggested at one point that we allow the list to go anywhere among
the paramters with the interpretation that if there were
enough arguments, it would take up the slack in the middle so the
last parameter would get the last argument. The suggestion got
shot down however. As I recall, the reasoning was that the parameters
could always be rearranged to put the list at the end. It seems
to me that p(a[],b,c[]) is inherently ambiguous. I suppose we could
**generate** a sequence of calls, one for each valid arrangement of
arguments into the lists (however, its not clear to me that this would
be useful).

From icon-group-request  Mon Oct 19 15:42:32 1987
From: "Bill Mitchell" <whm>
To: icon-group
Subject: Re:  Variable number of args (again)
Errors-To: icon-group-request
Status: O

Having thought about this for some time, I think that what I like the best
is

    procedure p[x]

to indicate that x is a list of all the arguments.  Although I was involved
with the hacks for p(a,b,c[]), the ability to type stuff like p(a[],b,c) seems
like an indication that a better idea is required.  The above notation seems
fairly clean in contrast, but there is the possibility of typing p[x,y,z].

From icon-group-request  Tue Oct 20 04:01:24 1987
From: rosevax!ems!dayton!umn-cs![e-mail]  (Neta Amit)
Organization: University of Minnesota
Subject: Re: Arglists and packages
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

In article <[e-mail]> [e-mail] writes:
>This is a reply to Ken Walker's comments on my proposals.
>
>(1) The notation
>    procedure p(a,b,c[])
>is quite elegant, and more general than what I had proposed.

For elegance and generality, consider the solution that has been available
in many Lisp/Scheme dialects for many years:

     (define foo (a b c &optional d e &rest f) ...)

At least three args must be provided and are bound to a, b and c.
The next two args, if any, are bound to d and e.
Any additional args form a list which is bound to f.
If d, e or f args are not provided, those vars are assigned ().
--
  Neta Amit
  U of Minnesota CSci
  Arpanet: [e-mail]

From icon-group-request  Tue Oct 20 05:20:22 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: <[e-mail]>
Subject: Arglists and packages
Errors-To: icon-group-request
Status: O

   Date: 17 Oct 87 21:33:40 GMT
   From: rosevax!ems!dayton!umn-cs![e-mail]  (Neta Amit)
   ...
   For elegance and generality, consider the solution that has been available
   in many Lisp/Scheme dialects for many years:

    (define foo (a b c &optional d e &rest f) ...)

This essentially what the notation

    procedure foo(a, b, c, d, e, f[])

gives you.  The only differences being that (1) _all_ the arguments
are optional (the &optional keyword would be spurious in Icon), and
(2) Only the list argument f is replaced with an empty list if it is
missing, other missing arguments are replaced with the special value
&null.

From icon-group-request  Wed Oct 21 22:13:50 1987
From: [e-mail]  (Stuart A. Kurtz)
Organization: Dept. of Comp. Sci., The University of Chicago
Subject: Re:  The future of icon.
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

A few random thoughts.

1) Re: scoping.  Most of the suggestions about controlling the scope
   of variables has been to use C style scoping.  I.e., scope at the
   file level only, and "protect" names by explicit static declarations.
   I would prefer (although it may be too late ...) to require explicit
   export statements, i.e., the default is not to export.
     Pro:
    This is better software engineering.  Define an interface, and
        then stick with it.  I envision a style with all of the export's
        at the top of the program, documented to describe the interface.
    Static variables (i.e., variables declared as "global") would then
    not contribute by default (and silently) to the interface.
     Con:
    Existing icon programs would be invalidated.  At the very least,
    implementation of this suggestion would require adding another
    flag to icont "make all declarations external".

2) Re: varargs.
   I suspect that the syntax "procedure p[a]" is most reasonable.  There
   is comparatively little reason to have "procedure p(a,b,[c])" or whatever,
   as icon permits fewer actual parameters than formal ones.  Thus,
   "p(a,b,[c])", or its ilk, in no way "enforces" at least two parameters,
   which was the point behind the C varargs structure.


Stu

Stuart A. Kurtz
Dept Computer Science
The University of Chicago

From icon-group-request  Thu Oct 29 01:17:55 1987
From: clyde!burl!codas!mtune!lzaz![e-mail]  (BRUCE SZABLAK)
Organization: AT&T ISL Middletown NJ USA
Subject: Re: The future of icon.
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O


Is there a symbolic debugger available for Icon? If not, there should
be (or at least a true interpreter).

From icon-group-request  Mon Nov  9 11:36:32 1987
From: naucse!sbw (Steve Wampler)
To: arizona!icon-group
Subject: Not A Contest, but IconTest!
Errors-To: icon-group-request
Status: O


While proctoring part of the ACM Mountain Regional Programming Contest,
it struck me how well suited Icon was for the majority of the contest
problems.  "Hmmm," I say to myself...

Announcing:
    The First Annual Great Icon Programming Test
    (IconTest for short)

Problems will be chosen from the 1987 ACM Mountain Regional Programming
Contest, and will be presented one at a time to the Icon programming
community.

Rules: Solve the problems using Icon, and mail the source to:

    Email: Steve Wampler
        {....!arizona!naucse!sbw}
    USmail: Steve Wampler
        College of Engineering and Technology
        Box 15600
        Northern Arizona University
        Flagstaff,  AZ  86011

       Solutions must show the version of Icon used and any special
    options.  (Don't just have the source print &version and
    &option - that isn't going to do much when I try it out on
    my end.)

       Judging will be entirely subjective, and based upon such
    abstract criteria as:

        (1) Correctness
        (2) Suitability of solution to Icon
        (3) Appropriate use of Icon language features.
        (4) Readability  (note: Pascal-style Icon is not
            a priori more readable than other styles!)

        The decision of the judge(s) is final, though icon-project may
    be consulted during the judging to resolve sticky points.

       Duration:  Each problem will remain open until a "winning" entry
    is found.  Since mail times differ around the icon-group, there
    is a built-in hysteresis.  All programs collected in a two week
    period will be judged as simultaneous arrivals.

       The "winning" programs will be posted back to icon-group.

       Eligibility:  The contest is restricted to Icon programmers.
    Members of icon-project are encouraged to compete, but
    cannot win except by default (sorry, folks, life is tough).

       Prizes:  Absolutely none, unless someone *else* wants to foot
    the bill.

Now, a few comments.  Some of the problems are particularly easy in Icon,
    occasionally requiring little more than consultation of the "Icon
    Programming Language" by Griswold and Griswold.  Others might take
    a bit more design to find an appropriate solution approach for Icon.
    None are identified as being easy or hard.

    At least one of the problems is not necessarily well-formed in the
    problem statement.  Sorry, I didn't write them.  Make sure any
    assumptions you make are clearly specified - if they're incorrect
    assumptions, too bad.  Where I've made typographical changes, the
    change is enclosed in square brackets ('[' and ']').

    By the way, at the ACM contests, the programs must behave exactly
    to specs - no deviation from the specified output format is allowed.
    Just for grins, let's do that here as well.  [ A^B for you Icon]

Okay, let the games begin!

From icon-group-request  Mon Nov  9 11:39:44 1987
From: naucse!sbw (Steve Wampler)
To: arizona!icon-group
Subject: IconTest Problem #1 Statement
Cc: [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail]
Errors-To: icon-group-request
Status: O



-----------------------------------------------------------------------------
IconTest Problem #1: The Big Powers:

Your task is to read in pairs of positive numbers, A and B.  They will be
contained in two right justified fields of length and type integer.  You
are to then calculate the value of A raised to the power B,  [ A^B ] for
you [Icon] types.  The output should be of the format:

    A = ddddd
    B = ddddd

    ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd
    ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd
            .
            .
            .
    ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd
    ddddd ddddd ddddd .....

    The number should be padded on the left with leading zeros to
    ensure that the number of digits printed is divisible by 5.
    Digits are printed in groups of five, with an intervening blank
    between groups, and ten groups per line with the exception of
    the last line which may have between one and ten groups.

    The output will be 5,000 digits or less in length.

-----------------------------------------------------------------------------

    Mail source code for solution to:

    -Steve Wampler
     College of Engineering and Technology
     Box 15600
     NAU, Flagstaff, AZ 86011

    -{....!arizona!naucse!sbw}

From icon-group-request  Thu Nov 12 21:59:32 1987
Return-Path: <[e-mail]>
From: Richard L. Goerwitz III <[e-mail]>
To: [e-mail]
Subject: stripping
Errors-To: icon-group-request
Status: O


I know it's a bit late now.  But I've been wanting for some time now to see
a strip command.  Whether it be incorporated into map, or set up as a separate
command, I don't really care.

I assume that such a command has not been included in releases to date for some
logical reason.  I wonder what that reason is.  And if it still holds (i.e. a
primitive strip command will not be implemented), I wonder whether anyone could
advise me as to what the best way of accomplishing a quick strip is.  So far,
I've been using:

                     map(string,repl((char := !string),*string))
                     while i := upto(char,string)
                     do string[i:many(char,string,i)] := ""

Yuck!  What a time-waster.  A major slowup in my programs.  Any better ideas?

                                                   -Richard Goerwitz
                                                   [e-mail]

From icon-group-request  Fri Nov 13 23:59:06 1987
Return-Path: <goer>
From: Richard L. Goerwitz III <[e-mail]>
To: [e-mail]
Subject: stripping
Errors-To: icon-group-request
Status: O


Okay, okay.  I'm thoroughly chastened.  In the letter I wrote about strippint,
I asked a question:  Why no primitive strip function?  I also asked, how can
I do a strip as quickly as possible, given the present tools?

Unfortunately, I posted some code.  That was silly.  I used a reserved word
where I shouldn't have, and then forgot to assign any variable to what was
produced by map(str,...).  Silly, silly, silly.  And confusing.

All I really wanted to know was what the fastest way to accomplish in icon
what I accomplish in UNIX with "tr -d."

This is a blanket response to all the justifiably confused people who wrote
to me either telling me I was nuts, or thinking they were!

The questions still, stand, though.  Any thoughts?             -Richard

From icon-group-request  Sat Nov 14 06:23:18 1987
From: "Ralph Griswold" <ralph>
To: [e-mail], [e-mail]
Subject: Re:  stripping
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: O

   From icon-group-request Fri Nov 13 23:59:19 1987
   Return-Path: <goer>
   From: Richard L. Goerwitz III <[e-mail]>
   To: [e-mail]
   Subject: stripping
   Errors-To: icon-group-request
   Status: R


   Okay, okay.  I'm thoroughly chastened.  In the letter I wrote about strippint,
   I asked a question:  Why no primitive strip function?  I also asked, how can
   I do a strip as quickly as possible, given the present tools?

   Unfortunately, I posted some code.  That was silly.  I used a reserved word
   where I shouldn't have, and then forgot to assign any variable to what was
   produced by map(str,...).  Silly, silly, silly.  And confusing.

   All I really wanted to know was what the fastest way to accomplish in icon
   what I accomplish in UNIX with "tr -d."

   This is a blanket response to all the justifiably confused people who wrote
   to me either telling me I was nuts, or thinking they were!

   The questions still, stand, though.  Any thoughts?             -Richard


The answer to your question as to why a "stripping" function is not
included in the built-in repertoire of Icon is simply that there is
not enough need for such a function to justify it.  Every function that
is added to the repertoire of a programming language increases the
size of the language. If a function is widely useful or cannot be
written as a procedure in the language, then having it built-in is
important.  But if it is relatively special-purpose and can be written
as a procedure, then having it built-in can be a disadvantage -- it
inceases the size of the implementation, the vocabulary programmers
need to learn, the size of the documentation, and the maintenance
load.

Obviously, decisions like these are not clear cut.  They depend on
the philisophy of the design of the language, the opinions, style,
and taste of the authors, and so on.

Some folks think Icon should have a lot more built-in functions than
it does.  Others think it has many too many.

The "stripping" operation is easy to write as a procedure in Icon.
See the solution to Exercise 4.7 in the Icon Programming Language book.
Of course, it's not as efficient as a built-in function; that's part
of the trade-off.

Icon also makes it fairly easy to add to its built-in repertoire by adding
functions written in C.  Source code for Icon is in the public domain and
documentation on modifying it is extensive.  So, if you want to, you
can make a personalized version of Icon that has the built-in repertoire
you want.


From icon-group-request  Wed Nov 18 08:06:24 1987
From: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

sorry for bothering you all. pl. remove me from the mailing list. thanx.

From icon-group-request  Mon Dec 14 14:12:05 1987
To: <[e-mail]>
From: <[e-mail]>
Subject:  no mail?
Errors-To: icon-group-request
Status: O

I did not receive any mail from the Icon group since November 19. Have all
members of the group become dumb, or is there any problem in email
communications ?


From icon-group-request  Mon Dec 14 17:01:28 1987
From: Kee Hinckley <umix!apollo![e-mail]>
Subject: Re: no mail?
To: [e-mail]
Cc: [e-mail], [e-mail]
In-Reply-To: [e-mail], mon, 14 dec 87 17:10:20
Errors-To: icon-group-request
Status: O

    I did not receive any mail from the Icon group since November 19. Have all
    members of the group become dumb, or is there any problem in email
    communications ?

Well, I tried just recently but I can't seem to get through via
'[e-mail]' anymore.

                                                -kee

### {mit-erl,yale,uw-beaver}!apollo!nazgul ###   (Apple ][e ProLine BBS)    ###
###      apollo![e-mail]       ###  [e-mail]   ###
###            [e-mail]           ### [phone] 300/1200/2400 ###
I'm not sure which upsets me more; that people are so unwilling to accept       responsibility for their own actions, or that they are so eager to regulate     everyone else's.
-------

From icon-group-request  Tue Dec 15 01:12:28 1987
From: [e-mail] (Richard Goerwitz)
To: [e-mail]
Subject: superficial equivalencies
Errors-To: icon-group-request
Status: O


In a letter sent out several months ago, I noticed someone remarking on how
the expression "if expr then expr else expr" is equivalent to (expr & expr) |
expr.  Perhaps the writer knew that this was not correct, strictly speaking.
However, since it has proven a source of problems for me, and for other no-
vices I have rubbed shoulders with, the exact facts of the matter are worth
relating.

Alternation does not imply any mutual exclusivity.  The result sequence gen-
erated by expr1 | expr2 is the sequence of results for expr1 followed by
those for expr2.  So if one executes

       every write(("a" & "b") | "c")

one gets "b\nc" (b newline c).  However, if one executes

       every write(if "a" then "b" else "c")

one simply gets "b."

The confusion here is caused by the fact that the two following lines are
equivalent:

        write(("a" & "b") | "c")
        write(if "a" then "b" else "c")

Both will simply write the first result produced by the expression or con-
trol structure contained in parentheses.  In both cases, this is simply "b."
Likewise, in both cases, if "a" were to fail (impossible here), then we'd
get "c."  At first glance, therefore, the two seem to be equivalent.  As I
mentioned above, the difference only appears when write is preceded by
every, since then we see that the result sequence produced by the top
example has two members.  The if...then...else structure produces only one
result, "b" and "c" being mutually exclusive.

Note that the if..then...else structure in fact produces a result.  In contrast,

        write(every ...)

writes nothing to the terminal.  This is because while...do and every...do
loops always continue until failing, at which point they terminate.  So, in
effect, they never produce a result.

I realize that many of the more experienced ICON programmers will see this
as rather basic.  My aim here, however, is to help anyone who is still
plodding through Griswold's ICON PROGRAMMING LANGUAGE to avoid some pitfalls
that inexperienced programmers like me can easily fall into....

                                                           -Richard Goerwitz


From icon-group-request  Tue Dec 15 13:02:56 1987
From: "David Gudeman" <gudeman>
To: icon-group
In-Reply-To: Richard Goerwitz's message of Tue, 15 Dec 87 02:07:57 CST <[e-mail]>
Subject: superficial equivalencies
Errors-To: icon-group-request
Status: O

I thought I would add something to the note about the similarity of

    (expr1 & expr2) | expr3

and

    if expr1 then expr2 else expr3

Another difference not mentioned in the note is that in the first
expression, expr3 is evaluated if either expr1 or expr2 fails.  In the
second expresion, expr3 is only evaluated if expr1 fails.  So the
expression

    write(("a" & &fail) | "c")

writes out a "c", while the expression

    write(if "a" then &fail else "c")

doesn't write anything, it fails.


From icon-group-request  Wed Dec 16 20:36:40 1987
From: [e-mail] (Richard Goerwitz)
To: [e-mail]
Subject: regular expressions
Errors-To: icon-group-request
Status: O


Just wondered if anyone has attempted to write any ICON procedures that
implement regular expression-ish pattern-matching, or if anyone has extended
the interpreter to handle this sort of thing.

                                                -Richard Goerwitz

                                                !ihnp4!gargoyle!sophist!goer
                                                [e-mail]

From icon-group-request  Mon Dec 21 09:38:18 1987
From: [e-mail]
Subject: Benchmark needed.
To: [e-mail]
Errors-To: icon-group-request
Status: O

Date: 21 December 1987, 16:44:54 GMT
From: NETWORK  at FRSAC11
To:   ICON-GROUP at ARIZONA

Who can send me some Icon sources to be used as benchmark ?
I mean a/several pieces of software that exercise widely the language,
to check the implementation speed on a particular hardware.
The dhrystone of Icon ... With strings, generator, numbers, etc...
I would prefer a single file, but a serie would be OK.
(The time lo load, etc is more of a problem on several than on a single
file.)
I want to check the speed, not the implementation.
I can measure wall clock time, not CPU.
I do not have the complete port set for the current Icon (6.5), but
I may have the one in BSD 4.3 sources (A 5.x Icon if I remember well)

I have the greatest difficulty with the FTP access to megaron.arizona,
very slow, response time in the minute range, etc. I call around
1 am PST, until 6 am PST, it should be easy then. I have tried twice today
to retreive a file, and quit after 5 hours, for a 200K file.
The FTP is issued from sumex-aim.stanford.edu.
Can you check with your local network guru why am I having so much troubles ?

Regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
[e-mail] (arpanet)
[e-mail] (arpanet)

From icon-group-request  Mon Dec 21 15:32:24 1987
From: [e-mail] (Richard Goerwitz)
To: [e-mail]
Subject: variables
Errors-To: icon-group-request
Status: O

Re:  Sets of ICON variables

Seeing as variables are passed by value and not reference, it is difficult to
perform the same operation on a series of variables with any degree of elegance
or economy.  I often end up doing things like

        a := doito(a)
        b := doito(b)
        c := doito(c)
        etc...

I wonder if it would eventually be possible to include some mechanism in ICON
for manipulating variables themselves (and not just their values).

Or is there some basic problem with doing things this way...?

                                                               -Richard Goerwitz

From icon-group-request  Mon Dec 21 15:49:51 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: Suggestions for new language features for Icon
Errors-To: icon-group-request
Status: O

There have been a number of suggestions for new Icon language features
in recent mail. The lack of response from us doesn't mean we didn't get
the mail or are insensitive to the ideas. It's more a matter of being
backlogged and short-handed -- not to mention the holiday season.

It's virtually impossible for us to respond intelligently to every
suggestion that is made in a prompt manner (there are a lot more of
you than there are of us, for one thing).

At the moment, we're working hard to get Version 7 of Icon completed.
While it won't answer all the questions and suggestions, it's the
place to start.

If you have questions about Icon and don't get the Icon Newsletter, send
us a *postal* mailing address; we'll put you on our (free) subscription
list and send you the last issue. You'll find a lot of your questions
answered in the Newsletter and you'll also see what our resources are
and why we can't do everything everyone wants us to do.

From icon-group-request  Mon Dec 21 16:00:29 1987
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
In-Reply-To: "Ralph Griswold"'s message of Mon, 21 Dec 87 15:49:49 MST <[e-mail]>
Subject: Suggestions for new language features for Icon
Errors-To: icon-group-request
Status: O

My subscription to the Icon newsletter seems not to have followed me
to the Lab.  here is my address now:

    Berry Kercheval
    Lawrence Livermore National Laboratory
    P.O. Box 808, L-270
    Livermore, CA 94550

    [phone]


Thanks!

  --berry

From icon-group-request  Mon Dec 21 17:14:04 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: e-mail about Icon
Errors-To: icon-group-request
Status: O

I should have mentioned that mail to [e-mail] is
redistributed automatically to a fairly large group of persons interested
in Icon. That mail address is appropriate for matters of general interest
about Icon.

If you have a request about icon-group (such as to be added, your address
changed, or to be deleted), mail to [e-mail].  Such
mail is not redistributed.

For other specific matters (such as being added to the Newsletter mailing list),
send mail to [e-mail].  That will assure it gets handled
here but will not result in redistribution to other sites.

If you want to restrict your message to an individual here, send to
that person, not icon-project, which goes to several persons. E.g.,
if you want to give me a piece of your mind, deliver it to [e-mail].

From icon-group-request  Tue Dec 22 02:04:48 1987
From: "David Gudeman" <gudeman>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: Richard Goerwitz's message of Mon, 21 Dec 87 16:29:03 CST <[e-mail]>
Subject: variables
Errors-To: icon-group-request
Status: O

   Date: Mon, 21 Dec 87 16:29:03 CST
   From: [e-mail] (Richard Goerwitz)
   ...
   I wonder if it would eventually be possible to include some
   mechanism in ICON for manipulating variables themselves (and not
   just their values).

   Or is there some basic problem with doing things this way...?

                          -Richard Goerwitz

Offhand I would say that this is not a problem in concept or in
implementation, but it might cause problems with efficiency.  We get a
_lot_ of suggestions for additions to Icon, and many of them are
interesting and/or useful.  I would classify your suggestion as both.

Obviously we cannot implement every useful suggestion, (or even most),
since Icon is already a large language (maybe too large), and because
it has a large user community that expects continuity between
versions.  However Icon is also a vehicle for research into
programming languages, and we are always interested in how users feel
about Icon and where they feel it needs improvement.

For a more direct answer to your question: I doubt very much that such
a feature will appear in the near future, as current research is
moving in other directions.  I like to think of our research as a
traversal through a hugely branching tree of possible programming
languages, searching for the Perfect Programming Language.  It's not
at all clear that the tree is finite.

                    David Gudeman

                        Department of Computer Science
[e-mail]                Gould-Simpson Science Building
{allegra,cmcl2,ihnp4,noao}!arizona!gudeman  The University of Arizona
602-621-2858                    Tucson, AZ 85721

From icon-group-request  Tue Dec 22 06:29:13 1987
From: "Ralph Griswold" <ralph>
To: gudeman
Subject: Re:  variables
Cc: icon-group
In-Reply-To: <[e-mail]>
Errors-To: icon-group-request
Status: O

Very nicely put.

My only disagreement with you is that language research is a search
through some existing structure.  I see is as an endless architectural
endeavor, deciding what to build next and what it should look like.

From icon-group-request  Tue Dec 22 12:33:59 1987
From: ihnp4!ihuxy!nowlin
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: variables
Ua-Message-Id: <post.nowlin.Tue 22 Dec 1987 08:57 CST>
End-Of-Protocol:
Content-Length: 2005
Errors-To: icon-group-request
Status: O

> Seeing as variables are passed by value and not reference, it is difficult
> to perform the same operation on a series of variables with any degree of
> elegance or economy.  I often end up doing things like
>
>         a := doito(a)
>         b := doito(b)
>         c := doito(c)
>         etc...
>
> I wonder if it would eventually be possible to include some mechanism in
> ICON for manipulating variables themselves (and not just their values).
>
> Or is there some basic problem with doing things this way...?
>
>                                                        -Richard Goerwitz

It's easy to have doito() perform it's operation on a list of variables and
return a new list with modified variables.  I'd call that fairly elegant.
You could call doito() with an already defined list:

    l1 := [a,b,c]
    l2 := doito(l1)

or just pass the list of variables as a constant:

    l2 := doito([a,b,c])

or go even further and make doito() a generator:

    every i := doito([a,b,c]) do ...

It sounds like what you want is procedures with side effects instead
of procedures that act like functions, kind of like subroutines in
FORTRAN.  This is possible but the way that data structures like lists
are normally operated on in Icon creates new copies of the list.

The following procedure modifies the contents of a list and the
modifications stay in effect in the main procedure.  In order to avoid
making a copy of the list during the processing you have to use
subscripts. YECH!

    procedure main (args)
        dub(args)
        every write(!args)
    end
    procedure dub(lst)
        every i := 1 to *lst do
            lst[i] *:= 2
    end

The normal way I'd do this in Icon would be:

    procedure main (args)
        every write(dub(args))
    end
    procedure dub(lst)
        every suspend !lst *:= 2
    end

This is elegant to me.

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)

P.S. I tried to reply to the message about regular expressions last week
     but it didn't get out correctly.  I have a grep written in Icon if
     anyone is interested.

From icon-group-request  Tue Dec 22 12:37:57 1987
From: "Janalee O'Bagy" <janalee>
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re:  Benchmark needed.
Cc: icon-group
Errors-To: icon-group-request
Status: O



We don't have what you need here at the Icon Project.
The test suite that we use and distribute with source
code is designed to verify proper functioning of all the
language features--this suite would be inadequate for
testing execution time.

Maybe someone in the user community (i.e., icon-group) has
developed such a collection of programs.

I'll bring your troubles with FTP to the attention of our
local expert.

Janalee O'Bagy

From icon-group-request  Tue Dec 22 14:41:13 1987
From: ihnp4!ihuxy!nowlin
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: variables
Ua-Message-Id: <post.nowlin.Tue 22 Dec 1987 15:04 CST>
End-Of-Protocol:
Content-Length: 2006
Errors-To: icon-group-request
Status: O

> Seeing as variables are passed by value and not reference, it is difficult
> to perform the same operation on a series of variables with any degree of
> elegance or economy.  I often end up doing things like
>
>         a := doito(a)
>         b := doito(b)
>         c := doito(c)
>         etc...
>
> I wonder if it would eventually be possible to include some mechanism in
> ICON for manipulating variables themselves (and not just their values).
>
> Or is there some basic problem with doing things this way...?
>
>                                                        -Richard Goerwitz

It's easy to have doito() perform it's operation on a list of variables and
return a new list with modified variables.  I'd call that fairly elegant.
You could call doito() with an already defined list:

    l1 := [a,b,c]
    l2 := doito(l1)

or just pass the list of variables as a constant:

    l2 := doito([a,b,c])

or go even further and make doito() a generator:

    every i := doito([a,b,c]) do ...

It sounds like what you want is procedures with side effects instead
of procedures that act like functions, kind of like subroutines in
FORTRAN.  This is possible but the way that data structures like lists
are normally operated on in Icon creates new copies of the list.

The following procedure modifies the contents of a list and the
modifications stay in effect in the main procedure.  In order to avoid
making a copy of the list during the processing you have to use
subscripts. YECH!

    procedure main (args)
        dub(args)
        every write(!args)
    end
    procedure dub(lst)
        every i := 1 to *lst do
            lst[i] *:= 2
    end

The normal way I'd do this in Icon would be:

    procedure main (args)
        every write(dub(args))
    end
    procedure dub(lst)
        every suspend !lst *:= 2
    end

This is elegant to me.

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)

P.S. I tried to reply to the message about regular expressions last week
     but it didn't get out correctly.  I have a grep written in Icon if
     anyone is interested.


From icon-group-request  Wed Dec 23 06:53:02 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: This is a test.
Errors-To: icon-group-request
Status: O



From icon-group-request  Thu Dec 24 19:46:44 1987
From: steinmetz!ge-dab!codas!killer![e-mail]  (Paul Nanson)
Organization: The Unix(R) Connection, Dallas, Texas
Subject: dial-up
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O


I heard there is a dial system associated with the ICON project.
The number given was [phone]. The settings were 300/1200/2400-E71,
and login was guest. Is such a system in existence, and if so, are
these the correct settings, etc?

Paul Nanson

From icon-group-request  Thu Dec 24 20:44:57 1987
From: ihnp4!ihuxy![e-mail]  (Bob Lied)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: Substring positions
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

I've finally gotten enough spare time to take a
look at ICON, and I have a novice question (please
don't hit me).  In an example and a solution in
chapter 5 of the book (I assume you know the book
I refer to), the size of a substring is calculated
with
    *line[i:j]
where I would intuitively expect to use
    i-j

I am inferring from this that string positions are
like other languages' pointers in that their numerical
values are not to be trusted, and I should limit their
use to assignments, comparisons, and defined operations
like subscripting.  Am I right?

    Bob Lied    ihnp4!ihuxy!lied
    AT&T Bell Laboratories

From icon-group-request  Tue Dec 29 20:49:57 1987
From: ihnp4!ihlpf![e-mail]  (00704A-Liber)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: Transmission of results to Co-expressions (need help)
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

HELP!!  How does one transmit results of expressions to co-expressions?  I know
that the example in the Icon book section 13.4.2 no longer works (I think I
read about that in the Version 6 docs) and I tried the example given in
technical report TR 87-6 (Programming in Icon; Part II --  Programming with
Co-Expressions), but when I try to execute it I get run-time error 214 --
recursive co-expression activation.  I could probably use a global variable but
somehow that doesn't seem elegant.  Please e-mail me any sample programs or
explanations and I will summarize and post to the net.  I am using Version 6.3
under MS-DOS with the LMM/FR executable; I have also tried it under Unix (Icon
version 6.0) with the same error message.

BTW, does anyone know what's coming up in Version 7?? :-)

Here is a copy of the program found in TR 87-6 pp 10-11:


global words, lines, writer

procedure main()

    words := create word()
    lines := create reader()
    writer := create output()
    @writer

end

procedure word()
    static letters

    initial letters := &lcase || &ucase

    while line := @lines do
        line ? while tab(upto(letters)) do
            tab(many(&lcase)) @ writer

end

procedure reader()

    while read() @ words

end

procedure output()

    while write(@words)
    @&main

end


Thanks (in advance)!!
--
 _ __            NEVIN J. LIBER    ..!ihnp4!ihlpf!nevin1    [phone]
' )  )                "The secret compartment of my ring I fill
 /  / _ , __o  ____         with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_    These are solely MY opinions, not AT&T's, blah blah blah

From icon-group-request  Wed Dec 30 05:27:59 1987
From: "Ralph Griswold" <ralph>
To: icon-group
Subject: Co-Expression Transmission and Version 7
Errors-To: icon-group-request
Status: O

Co-expression transmission cannot be made to work in a useful
way in the distributed Version 6 of Icon.

We have the problem corrected, and the results will be available in
Version 7.  We presently expect Version 7 to be available for
UNIX systems late in January and for MS-DOS systems a couple of weeks
later.

The release of Version 7 will be annnounced via icon-group.

From icon-group-request  Wed Dec 30 16:19:19 1987
From: "David Gudeman" <gudeman>
To: ihnp4!ihuxy![e-mail], icon-group
In-Reply-To: (Bob Lied's message of 25 Dec 87 00:31:22 GMT <[e-mail]>
Subject: Substring positions
Errors-To: icon-group-request
Status: O

   From: ihnp4!ihuxy![e-mail]  (Bob Lied)

   ....  In an example and a solution in chapter 5 of the book (I
   assume you know the book I refer to), the size of a substring is
   calculated with

       *line[i:j]
   where I would intuitively expect to use
       i-j

   I am inferring from this that string positions are
   like other languages' pointers in that their numerical
   values are not to be trusted, and I should limit their
   use to assignments, comparisons, and defined operations
   like subscripting.  Am I right?

Well, not really.  String positions are integer positions _between_
the characters of the string, where 1 is the position at the beginning
of the string.  However, non-positive integers are also valid string
positions (with 0 at the end of the string).  So if i or j is
non-positive, it is not true that "*line[i:j] = j-i" (I assume you
meant "j-i" rather than "i-j").

In the example in the book, both i and j are guaranteed to be
positive, so "j-i" works.  Notice though, that in most languages the
positive integers refer to character positions, so the correct formula
for the length of a substring from i to j is "j-i+1".  Perhaps the
authors wanted to avoid confusing readers with this subtlety.

From icon-group-request  Thu Dec 31 09:06:28 1987
To: arizona!icon-group-request, arizona!icon-group, arizona!icon-project
Subject: Sample programs and subscription
From: noao!rutgers!gatech!rebel!dkstar!n8emr!uncle![e-mail] (John B. Milton)
Errors-To: icon-group-request
Status: O


Please add my name to the newsletter distribution and the discussion group.

Also: I am trying to get a grip on this language and what I need next is
some sample programs that are of decent size, that are not in the book.

Thank you very much
John
--
John Bly Milton IV, [e-mail], {ihnp4|cbosgd}!n8emr!uncle!jbm
home: [phone], work: [phone], FLAME via email :)


From icon-group-request  Thu Dec 31 11:53:09 1987
From: Michael Shafto <[e-mail]>
To: [e-mail], [e-mail],
        ihnp4!ihuxy![e-mail]
Subject: Re:  Substring positions
Cc: [e-mail]
Errors-To: icon-group-request
Status: RO

For what it's worth:  When I first started using Icon, I thought
the string/list subscripting conventions were extremely
counter-intuitive and confusing; and, in fact, they caused me
to make a number of annoying errors.  E.g., even if you know
better, a := el[1:3] looks like a good way to pick off the
first three elements of a list.

Now it seems to me that these conventions are unusual, but
worth getting used to.  Once you get the hang of them, they
seem pretty neat.

Mike