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

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

From icon-group-request  Fri Jan  1 02:17:02 1988
From: grand![e-mail]  (Dave Yost)
Organization: Grand Software, Inc., 213-650-1089, Los Angeles, CA
Subject: complicated sorting
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: RO

I need to sort a list of records
according to complicated sort criteria,
The standard icon sort() routine is
not making this task easy.  What I
need is something more like the C
library qsort routine that lets me
provide my own comparison routine.

Is there any hope of my finding something
like this in icon, or am I missing some
elegant way to do this with the existing
sort() routine?

  --dave yost

From icon-group-request  Sun Jan  3 13:39:43 1988
From: "Kenneth Walker" <kwalker>
In-Reply-To: <[e-mail]>
To: grand![e-mail], [e-mail]
Subject: Re:  complicated sorting
Errors-To: icon-group-request
Status: O

    Date: 1 Jan 88 05:33:51 GMT
    From: grand![e-mail]  (Dave Yost)

    I need to sort a list of records
    according to complicated sort criteria,
    The standard icon sort() routine is
    not making this task easy.  What I
    need is something more like the C
    library qsort routine that lets me
    provide my own comparison routine.

    Is there any hope of my finding something
    like this in icon, or am I missing some
    elegant way to do this with the existing
    sort() routine?

The comparison routine used by the Icon sort function is built
into the run-time system and cannot be overriden without
modifying Icon.

Sometimes a comlicated sort criterion can be handled by constructing
artifical keys for records such that a key sorts the corrosponding
record where it needs to go in the sequence. The records can then
be put in a table using the keys and the table can be sorted to
produce the desired sequence of records. The artifical keys would
typically be strings. If such keys are not easy to produce, your
best bet is probably to write a sort procedure in Icon specific to
your application.

From icon-group-request  Mon Jan  4 17:37:23 1988
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: complicated sort
Ua-Message-Id: <post.nowlin.Mon 04 Jan 1988 09:02 CST>
End-Of-Protocol:
Content-Length: 2730
Errors-To: icon-group-request
Status: O

> I need to sort a list of records according to complicated sort criteria,
> The standard icon sort() routine is not making this task easy.  What I need
> is something more like the C library qsort routine that lets me provide my
> own comparison routine.
>
> Is there any hope of my finding something like this in icon, or am I
> missing some elegant way to do this with the existing sort() routine?
>
>   --dave yost

I'm not sure this is what you had in mind but the procedure enclosed is
handy for sorting records and can be modified to work with your own
comparison routines fairly easily.  I don't know of any way to use the
builtin sort() for anything other than standard types.

This recsort() procedure only sorts on one field of a record but it
wouldn't be too hard to pass it a list of the fields in the record that
should be sorted on instead of a single value.  The way the intermediate
table of records is maintained will make it fairly easy to sort on multiple
keys.  Hope this is helpful.  (Sorry for the lack of comments.)

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

# This example program sorts a UNIX style password file.  The first
# argument to the program should be the field in each password entry to
# sort on.  The program has a limit of the first 20 entries built in but
# it can be removed to test the program on the whole password file.  The
# program uses the recsort() procedure to sort a list of records.

record    passwd(name,pass,uid,gid,info,logdir,shell)

procedure main(args)

    if *args = 0 then stop("I need a numeric field index to sort on")

    users := []

    in := open("/etc/passwd","r")

    every line := !in\20 do line ? {

        user := passwd()
        user.name := tab(upto(':')) & move(1)
        user.pass := tab(upto(':')) & move(1)
        user.uid := tab(upto(':')) & move(1)
        user.gid := tab(upto(':')) & move(1)
        user.info := tab(upto(':')) & move(1)
        user.logdir := tab(upto(':')) & move(1)
        user.shell := tab(0)
        put(users,user)

    }

    close(in)

    write("UNSORTED: ",image(users)," ",image(users[1]))
    every user := !users do write(    user.name," : ",
                    user.pass," : ",
                    user.uid," : ",
                    user.gid," : ",
                    user.info," : ",
                    user.logdir," : ",
                    user.shell)

    stuff := recsort(users,!args)

    write("\nSORTED: ",image(stuff)," ",image(stuff[1]))
    every user := !stuff do write(    user.name," : ",
                    user.pass," : ",
                    user.uid," : ",
                    user.gid," : ",
                    user.info," : ",
                    user.logdir," : ",
                    user.shell)

end

procedure recsort(recs,index)

    tempt := table()

    every rec := !recs do
        (/tempt[rec[index]] := [ rec ]) | put(tempt[rec[index]],rec)

    templ := sort(tempt,1)

    newrecs := []

    every pair := !templ do
        every put(newrecs,!pair[2])

    return newrecs

end

From icon-group-request  Tue Jan  5 01:07:52 1988
From: [e-mail] (Richard Goerwitz)
To: [e-mail]
Subject: find/upto
Errors-To: icon-group-request
Status: O


Can someone explain to me why

          str := "hello"
          write(str[find("",str):0])

writes "hello", while

          str := "hello"
          write(str[upto('',str):0])

writes nothing?

                          -Richard

From icon-group-request  Tue Jan  5 14:10:31 1988
From: Brain in Neutral <[e-mail]>
To: [e-mail]
Subject: Icon document request
Errors-To: icon-group-request
Status: O


I'd like to order IPD18 "Benchmarking Icon Expressions" and IPD41
"Tabulating Expression Activity in Icon", please.  My address is

Paul DuBois
University of Wisconsin-Madison Primate Center
1220 Capitol Court
Madison, WI 53715-1299

[phone]


Thank you,
Paul DuBois
[e-mail]    rhesus!dubois
[e-mail]    rhesus!bin

From icon-group-request  Tue Jan  5 17:25:09 1988
From: "Kenneth Walker" <kwalker>
In-Reply-To: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  find/upto
Errors-To: icon-group-request
Status: O

>  Date: Tue, 5 Jan 88 02:03:48 CST
>  From: [e-mail] (Richard Goerwitz)
>
>  Can someone explain to me why
>
>            str := "hello"
>            write(str[find("",str):0])
>
>  writes "hello", while
>
>            str := "hello"
>            write(str[upto('',str):0])
>
>  writes nothing?
>
>                            -Richard
>

find("", str) searches str for the substring "". The empty string occurs
as a substring at every point in every string (in particular at the beginning).

upto('', str) searches str for characters in the character set (cset) ''.
This set contains no characters for upto to locate, so it fails to locate
any.

From icon-group-request  Wed Jan  6 12:37:53 1988
From: grand![e-mail]
Posted-Date: Tue, 05 Jan 88 23:38:53 PST
To: [e-mail]
Cc: [e-mail]
Subject: open ("command", "wp)
Organization: Grand Software, Inc., makers of "The Grand Editor"
Domain-From: [e-mail]
Phone: [phone]
Errors-To: icon-group-request
Status: O

Consider the following /bin/sh script:

echo finished | (sleep 15 ; cat)

Compare that with the following icon program:

procedure
main (args)
    local output

    if not (output := open ("sleep 15 ; cat",  "wp")) then
    stop ("trmsg: can't open a pipe for writing")
    write (output, "finished")
    return
end

I believe they should be functionally equivalent.
They're not.  The shell script waits for the cat,
while the icon version exits immediately after
writing to the pipe, without waiting.

I think this is an obvious bug.
If you don't agree, I will be happy to explain more fully.

 --dave

From icon-group-request  Wed Jan  6 12:50:32 1988
From: "Kelvin Nilsen" <kelvin>
In-Reply-To: <[e-mail]>
To: grand![e-mail], [e-mail]
Subject: Re:  open ("command", "wp)
Cc: [e-mail]
Errors-To: icon-group-request
Status: O

>
>procedure
>main (args)
>    local output
>
>    if not (output := open ("sleep 15 ; cat",  "wp")) then
>    stop ("trmsg: can't open a pipe for writing")
>    write (output, "finished")
>    return
>end
>

in the above, add a close(output) before the return.  this works
for me.



From icon-group-request  Wed Jan  6 16:16:26 1988
From: [e-mail] (Richard Goerwitz)
To: [e-mail]
Subject: shell script vs. icon pipes
Errors-To: icon-group-request
Status: O


In response to a posting (which I have - unfortunately - rm'ed), try:

procedure main()
    local output, com
    com := "echo \'this is a message\' | (sleep 15; cat)"
    output := open(com,"rp") | stop("Try again :-)")
    write(!output)
end

This also works fine.  You could, of course, do com := arg[1] || "| (sleep
15; cat)".

From icon-group-request  Mon Jan 11 11:39:27 1988
From: ihnp4!ihuxy!nowlin
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Email-Version: 2
X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: open ("command", "wp)
Ua-Message-Id: <post.nowlin.Thu 07 Jan 1988 10:01 CST>
Content-Length: 1563
Errors-To: icon-group-request
Status: O

> Consider the following /bin/sh script:
>
> echo finished | (sleep 15 ; cat)
>
> Compare that with the following icon program:
>
> procedure
> main (args)
>     local output
>
>     if not (output := open ("sleep 15 ; cat",  "wp")) then
>     stop ("trmsg: can't open a pipe for writing")
>     write (output, "finished")
>     return
> end
>
> I believe they should be functionally equivalent.
> They're not.  The shell script waits for the cat,
> while the icon version exits immediately after
> writing to the pipe, without waiting.
>
> I think this is an obvious bug.
> If you don't agree, I will be happy to explain more fully.
>
>  --dave

I don't see why this is an Icon bug.  The real culprit is the program.  If
you'll add a close(output) to your program then the program will wait for
the process attached to the pipe to complete and you'll see the behavior
you expected.

    procedure
    main (args)
        local output

        if not (output := open ("sleep 15 ; cat","wp")) then
            stop ("trmsg: can't open a pipe for writing")
        write (output, "finished")

        close(output)  #  IMPORTANT LINE

        return
    end

If you open the pipe, write to it, and then terminate your Icon program
without waiting for the pipe to complete (sort of pull the rug out from
under it) the output to the pipe stays in the input buffer of the spawned
commands and when the sleep completes the cat will pick it up.  Learn to
program symmetrically so that files or pipes that are opened are also
closed and you will run into far fewer problems.

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

From icon-group-request  Mon Jan 11 11:39:31 1988
From: grand![e-mail]
Posted-Date: Fri, 08 Jan 88 17:33:06 PST
To: "Kenneth Walker" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: complicated sorting
In-Reply-To: Your message of Sun, 03 Jan 88 13:38:47 MST.
             <[e-mail]>
Organization: Grand Software, Inc., makers of "The Grand Editor"
Domain-From: [e-mail]
Phone: [phone]
Errors-To: icon-group-request
Status: O

    Date: Sun, 3 Jan 88 13:38:47 MST
    From: "Kenneth Walker" <arizona.edu![e-mail]>
    In-Reply-To: <[e-mail]>
    To: [e-mail], [e-mail]
    Subject: Re:  complicated sorting

    The comparison routine used by the Icon sort function is built
    into the run-time system and cannot be overriden without
    modifying Icon.

Right.

    Sometimes a comlicated sort criterion can be handled by constructing
    artifical keys for records such that a key sorts the corrosponding
    record where it needs to go in the sequence. The records can then
    be put in a table using the keys and the table can be sorted to
    produce the desired sequence of records. The artifical keys would
    typically be strings.

This is exactly what I am doing, and it's cumbersome.

    If such keys are not easy to produce, your best bet is probably
    to write a sort procedure in Icon specific to your application.

I believe the best solution is a more powerful sort function
to which the user supplies the comparison procedure, like qsort
in the C library.

The problem I am solving in icon (thank God and you people I'm
not trying to do it in C!) is the preparation of a book index.
The index is a list of entries consisting of a list of subentries
consisting of a list of page numbers.

A built-in function a la the C library qsort, would help.
It might look like this:

sortx(a, p)

    Sortlist is a stable sort which sorts list a and
    produces a new, sorted list.  Procedure p is called each
    time sortx needs to compare two list entries.  It takes
    two arguments and returns -1, 0, or 1 when the first
    argument is less than, equal to, or greater than the
    second argument, respectively.  If p is omitted, the
    standard icon sort order is used.

Since I wrote my first message on this subject, I now see
that even this proposed sortx doesn't really cut it for my
present problem.  It turns out to be the trivial case of what
I really need:

sortlist(a, p, depth)

    Sortlist is a stable sort which sorts list a and
    produces a new, sorted tree of lists of the specified
    depth.  In the simplest case, when the depth argument is
    1 or not specified, sortlist returns a simple sorted
    list.  If depth is 2, then a list of lists is returned,
    and so on for greater values of depth.

    Procedure p is called each time sortlist needs to
    compare two list entries.  If p is not specified, the
    standard icon sort order is used.

    When depth is not specified or is 1, procedure p must be
    in this form:

    procedure p(x1, x2)
       return relation_result
    end

    where relation_result return value is -1, 0, or 1 when
    x1 is less than, equal to, or greater than x2,
    respectively.

    When depth is specified and is > 1, procedure p must be
    in this form:

    record sortcompare(relation, depth)

    procedure p(x1, x2)
       return sortcompare(relation_result, depth_result)
    end

    The relation_result return value is -1, 0, or 1 when x1
    is less than, equal to, or greater than x2, respectively.

    The depth_result return value specifies how deep p had
    to go in making the comparison before deciding on the
    value for the relation field.  For efficiency, it is
    advisable to write procedure p so that it never bothers
    to compare to a depth greater than needed by its caller.

    For example, the list [ "aa", "ba", "bb", "c" ] sorted to
    a depth of 2 with the aid of a suitable comparison routine
    could yield: [ [ "aa" ], [ "ba", "bb" ], [ "c" ] ]

Such a function would be perfect for my application, and I
bet it would be a useful and powerful tool for other sorting
problems.

I don't have an algorithm to implement this.
I wish I did.  Any takers?

To be sure what I'm getting at is clear, here's an example:

procedure
cmp(x1, x2)
    if x2[1] ~== x1[1] then return sortcompare(x2[1] - x2[1], 1)
    if x2[2] ~== x1[2] then return sortcompare(x2[2] - x2[2], 2)
    return sortcompare(x2[3] - x2[3], 3)
end

Input:  ["aaa", "baa", "bba", "caa", "cab" ]

Call:   sortlist(Input, p, 1)
Output: [ "aaa", "baa", "bba", "caa", "cab" ]

Call:   sortlist(Input, cmp, 2)
Output: [
      [ "aaa" ],
      [ "baa", "bba" ],
      [ "caa", "cab" ]
    ]

Call:   sortlist(Input, cmp, 3)
Output: [
      [
        [ "aaa" ]
      ],
      [
        [ "baa" ],
        [ "bba" ]
      ],
      [
        [ "caa", "cab" ]
      ]
    ]

Call:   sortlist(Input, cmp, 4)
Output: [
      [
        [
          [ "aaa" ]
        ]
      ],
      [
        [
          [ "baa" ]
        ],
        [
          [ "bba" ]
        ]
      ],
      [
        [
          [ "caa" ],
          [ "cab" ]
        ]
      ]
    ]

etc.

 --dave yost

From icon-group-request  Tue Jan 12 07:51:30 1988
From: grand![e-mail]  (Dave Yost)
Organization: Grand Software, Inc., Los Angels, CA 213-650-1089
Subject: Re: open ("command", "wp)
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request
Status: O

Thanks.  I'm relieved to know that if I explicitly do the close,
as I agree I should have, it works properly.  Still, the book
does say that open files are closed automatically upon program
termination, so my program should have acted as if I had done
the close.  I have already mentioned this to the Icon Group.

 --dave yost

From icon-group-request  Tue Jan 12 12:35:40 1988
From: "Kenneth Walker" <kwalker>
To: icon-group
Subject: Re:  complicated sorting
Errors-To: icon-group-request
Status: O

    From: grand![e-mail]
    Date: Fri, 08 Jan 88 17:33:06 PST

        ...

    I believe the best solution is a more powerful sort function
    to which the user supplies the comparison procedure, like qsort
    in the C library.

This suggestion sounds to me like something worth putting on the list
of possible future enhancements to Icon. There is an actual list.
Inclusion in the list doesn't insure a feature will every get put in
the language, but it does mean that it will get consideration when (and if)
the next round of enhancements are implemented.

    Since I wrote my first message on this subject, I now see
    that even this proposed sortx doesn't really cut it for my
    present problem.  It turns out to be the trivial case of what
    I really need:

        [details omitted - essentially a routine to sort on multiple
         keys producing a tree structure]

I can beleive that such a routine is usefull occationally, but its need
doesn't seem to me to be wide spread enough to burden the language
with such a complex feature.

When I need to sort on multiple keys, I sometimes use multi-level tables.
Perhaps a modification of the following routine could be used for your
purposes.

#
# Sort records on 3 keys. The result is a list of lists of lists (that is,
#  a 3 level tree - one level for each key). The intermediate data structure
#  is a table of tables of tables; each level of tables is keyed on the
#  corrosponding record key.
#
record info(key1, key2, key3)

procedure main()
   local s, w_sp
   local rec
   local tbl, x
   local lst

   #
   # 1st level table
   #
   tbl := table()

   #
   # read records and store in intermediate table structure
   #
   while s := read() do {
      s ? rec := info(tab(many(&lcase)),
                      tab(upto(&lcase)) & tab(many(&lcase)),
                      tab(upto(&lcase)) & tab(many(&lcase)))
      #
      # put the record in the correct table, making sure the required 2nd
      # and 3rd level tables exist
      #
      /tbl[rec.key1] := table()
      x := tbl[rec.key1]
      /x[rec.key2] := table()
      x := x[rec.key2]
      x[rec.key3] := rec
      }

   #
   # convert each level of table into a sorted list
   #
   lst := sort_tbl(tbl)

   do_whatever(lst)
end

procedure sort_tbl(tbl)
   local l1, l2

   l1 := sort(tbl, 3)

   #
   # remove keys from list, sorting entries if they are tables
   #
   l2 := list()
   get(l1)
   if type(l1[1]) == "table" then
      while put(l2, sort_tbl(get(l1))) do
         get(l1)
   else
      while put(l2, get(l1)) do
         get(l1)
   return l2
end

From icon-group-request  Wed Jan 13 13:40:58 1988
From: ihnp4!ihuxy!nowlin
Message-Version: 2
>To: /addr=ihlpe!orf, /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
Cc: ihlpe!orf
Subject: Re: complicated sorts
Ua-Message-Id: <post.nowlin.Tue 12 Jan 1988 07:04 CST>
End-Of-Protocol:
Content-Length: 4176
Errors-To: icon-group-request
Status: O

Group,

    I sent an example sorting procedure out a couple days ago in
response to a message about sorting routines.  I mentioned in the
accompanying note that the procedure could be extended to sort on multiple
keys with just a little modification.  I then decided to go ahead and make
it sort on multiple keys on my own.  The modified routine follows.  I also
commented the procedure this time so it would be easier to follow.

There is one final modification I'd like to see and I'd like some help from
you Icon gurus out there.  How could I pass a list of sorting keys that
consist of strings corresponding to the labels used to reference the fields
in a record instead of numeric indexes for the record that is being sorted
to the recsort() procedure?  If you didn't follow that question here is an
example of what I mean.  Given the program that follows, If I want to sort
the password file by the uid field I have to invoke the program with "3" as
the sorting key.  I'd like to be able to invoke it with "uid" as the
sorting key.

Any suggestions are welcome.  The real trick is to do this in a record
definition independent way.  This means that recsort() can't know ahead of
time about the definition of the record type it's sorting.  I don't think
it can be done given the current Icon.  Please prove me wrong.

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

# This example program is to illustrate the recsort() procedure.  It sorts
# a UNIX style password file.  The arguments to the program should be the
# fields in each password entry to sort on in order of precedence.  The
# program has a built-in limit of the first 20 entries in the password file
# but it can be removed to test the program on the whole password file.
# Notice that the UID and GID fields are now forced to be numeric.  Sorts
# on these fields will work accordingly.

record passwd(name,pass,uid,gid,info,logdir,shell)

procedure main(args)

    if *args = 0 then stop("I need a numeric record index to sort on")

    users := []

    in := open("/etc/passwd","r")

    every line := !in\20 do line ? {

        user := passwd()
        user.name := tab(upto(':')) & move(1)
        user.pass := tab(upto(':')) & move(1)
        user.uid := numeric(tab(upto(':'))) & move(1)
        user.gid := numeric(tab(upto(':'))) & move(1)
        user.info := tab(upto(':')) & move(1)
        user.logdir := tab(upto(':')) & move(1)
        user.shell := tab(0)
        put(users,user)

    }

    close(in)

    write("UNSORTED: ",image(users)," ",image(users[1]))
    every user := !users do write(    user.name,":",
                    user.pass,":",
                    user.uid,":",
                    user.gid,":",
                    user.info,":",
                    user.logdir,":",
                    user.shell)

    stuff := recsort(users,args)

    write("\nSORTED: ",image(stuff)," ",image(stuff[1]))
    every user := !stuff do write(    user.name,":",
                    user.pass,":",
                    user.uid,":",
                    user.gid,":",
                    user.info,":",
                    user.logdir,":",
                    user.shell)
end

# Sort a list of records by the fields given in keys.  These fields must
# be numeric indexes to one or more of the fields in the record type being
# sorted.  A sorted list of records is returned.

procedure recsort(recs,keys)

    # Initialize a temporary table.
    tempt := table()

    # Get a sorting key.
    key := get(keys)

    # Take every record in the recs list and add it to the table.
    every rec := !recs do

        # Each index to the table is a different sorting key.  To
        # avoid losing records which have identical sorting keys
        # each value in the table must be a list of the records
        # that are indexed by a given sorting key.
        (/tempt[rec[key]] := [ rec ]) | put(tempt[rec[key]],rec)

    # Sort the table by the indexes (sorting keys).
    templ := sort(tempt,1)

    # Initialize a new records list.
    newrecs := []

    # Take apart the pairs of lists generated by the sort.
    every pair := !templ do {

        # If there is more than one record in this value list and
        # there are additional keys to sort on recursively sort this
        # value list with the remaining keys.
        if *pair[2] > 1 & *keys > 0 then
            pair[2] := recsort(pair[2],copy(keys))

        # Add each record from the value list to the temporary list.
        every put(newrecs,!pair[2])
    }

    # Return the new sorted list of records.
    return newrecs
end

From icon-group-request  Wed Jan 13 17:05:34 1988
From: "David Gudeman" <gudeman>
To: ihnp4!ihuxy!nowlin, icon-group
In-Reply-To: <[e-mail]>
Subject: complicated sorts
Errors-To: icon-group-request
Status: O

   From: ihnp4!ihuxy!nowlin

   ...How could I pass a list of sorting keys that consist of strings
   corresponding to the labels used to reference the fields in a
   record instead of numeric indexes for the record that is being
   sorted to the recsort() procedure?  If you didn't follow that
   question here is an example of what I mean.  Given the program that
   follows, If I want to sort the password file by the uid field I
   have to invoke the program with "3" as the sorting key.  I'd like
   to be able to invoke it with "uid" as the sorting key.

You can't reference records by string name anyway, so getting a string
corresponding to a field name wouldn't do you any good.  You probably
should be using tables if you want to do this.  Table references are a
little uglier than record references, e.g.: foo["name"] vs. foo.name,
but tables are a lot more flexible.

From icon-group-request  Sun Jan 24 00:46:07 1988
From: [e-mail] (Richard Goerwitz)
To: [e-mail]
Subject: help
Errors-To: icon-group-request
Status: O


Since first coming to know about Icon last year, I've gone from a complete
programming neophyte to an intermediate user.  In fact, I cut my teeth on
Icon - the reverse of what most people do.  Only after getting to the last
chapters of Griswold & Griswold did I open up a book on C.  Imagine my horror
when I found out that all my variables would have to be declared, along with
their sizes and types.  No more garbage-collection and run-time typing!  No
more goal-oriented iterations!  No more coroutines, at least as I knew them
from Icon.

Things seemed quite a mess at first.  But after a while I discovered some im-
portant advantages to using C.  This brings me to my real purpose in writing.
As it turns out, nearly all of these advantages stem from features that would
be equally nice in Icon.  Although it's clearly not going to have any impact
on version 7, I'd still like to mention what some of these advantages are, and
see if anyone else agrees with me.

  1)  First and foremost is the ability to pass variables by reference rather
      than by value.  When I got to Pascal, this became even more natural than
      in C.  In Icon, it is impossible, unless one makes the variable in ques-
      tion global.  A typical situation in which this engenders problems is
      when a procedure gathers information that can be applied to more than
      one variable.  Often, for instance, I have to parse header lines in des-
      criptively marked-up text.  The information thus obtained is then used
      to set up several tables and lists.  Why should I have to do the proce-
      dure over again for each structure?  Why, on the other hand, should I
      have to introduce a superabundance of global variables?  It would be much
      faster and more elegant to allow passing of pointers in addition to val-
      ues.

  2)  Addendum to the previous:  If I can't have pointers, I'd like dynamic
      variables.  Ideally, I'd like to see them based on the current &level
      of the current activation branch (what would this do to coexpressions?).

  3)  Another nice point to C is the existence of standard pattern-matching
      routines.  Many compilers even provide regular expression pattern-
      matching routines.  It has been more than once that I have wanted to
      do

                   str ? egrep(s) #where egrep(str) works like find, except
                                  #that it accepts egrep-style regexp's

      in Icon.

  4)  Finally, it would be wonderful to have a compiler.  I keep wanting to
      send off Icon programs to friends who do not know the language, and who
      do not have the slightest interest in setting up an interpreter on their
      system (frequently they don't know ANY programming language, so this is
      no slight to Icon).  This seems a lot to ask, I know.  I'd just like to
      register my feelings.  Anyone else out there feel the need?  We would
      presumably get a little extra speed out of a compiler, too, so it could
      be useful in the later stages of preparing programs (after most of the
      bugs have been zapped).


     Anyone else out there have views pro/con?  I fully expect to get jumped on
by the more experienced programmers.  I probably deserve it.

                                                                   -Richard

From icon-group-request  Sun Jan 24 13:07:12 1988
From: [e-mail] (Richard Goerwitz)
To: [e-mail]
Subject: silly me
Errors-To: icon-group-request
Status: O


As usual, I end up looking silly in my last posting.  Yes, I do in fact know
that structures are passed by pointers, and are not de-referenced.  I still
have the problem of not being able to do this with other types of variables.
It would seem convenient to have the ability to pass pointers as a generally
available device in Icon.

Please don't hit me!

                                                                 -Richard

From icon-group-request  Sun Jan 24 13:48:29 1988
From: "Kenneth Walker" <kwalker>
In-Reply-To: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  help
Errors-To: icon-group-request
Status: O

This is a response to Richard Goerwitz's suggestions for new features
for Icon.

Usual preface:

There are several reasons for not including a new feature in Icon.
Implementing and maintaining new features place an additional burden
on limited resources. The language is already rather large - small
languages are easier to master. Some features may be very useful for
a few problems, but don't have wide spread applicability. Some features
don't fit into the philosophy of Icon.

    Date: Sun, 24 Jan 88 01:41:13 CST
    From: [e-mail] (Richard Goerwitz)

        ...

      1)  First and foremost is the ability to pass variables by reference
          rather than by value.  ...

This suggestion comes up occasionally. I think most people agree that it
would sometimes be nice to have. However, it doesn't look like it will
be added to the language.

      2)  Addendum to the previous:  If I can't have pointers, I'd like
          dynamic variables.  ...

There has been some discussion on dynamic variables. It has been motivated
in part by the fact that &subject and &pos act like dynamic variables
with respect to string scanning operations; one approach to language
design is to try to generalize existing features. There has been no
consensus on what such a feature should look like. Making all variables
dynamic is not a good idea (note that most Lisp implementations now
use static scope, atleast for the default scope).

      3)  Another nice point to C is the existence of standard
          pattern-matching routines.  Many compilers even provide
          regular expression pattern-matching routines.  It has been
          more than once that I have wanted to do

                str ? egrep(s) #where egrep(str) works like find, except
                               #that it accepts egrep-style regexp's

          in Icon.

Icon matching expressions are more powerful than regular expressions. If
s is a string constant, then you can easily do this with the current
facilities (though the code won't be as short). If you need to construct
the regular expression at run time or if it is supplied as a parameter
to the program, then it is not as easy to do it with the current facilities.

You get into philosophical questions here. If you want to be able to
construct regular expressions at run-time, wouldn't it be better to have
something along the lines of SNOBOL4's pattern data type?

In my own opinion, an egrep function (maybe with a different name) sounds
reasonable. However, I am not interested enough to implement it. We
do accept new built-in functions implemented by members of the user
community. There is no guarentee that such a function will get incorporated
in future releases, but having a working version increases the chances.

      4)  Finally, it would be wonderful to have a compiler. ...

Some interesting work has been done (by Janalee O'Bagy) on
optimizations which are possible in an Icon compiler. The work has
been done using prototype compilers written mostly in Icon (what else?).
However, converting from a prototype which is acceptable for research
to a production quality compiler is a significant undertaking.

From icon-group-request  Mon Jan 25 15:49:19 1988
From: naucse!sbw (Steve Wampler)
To: arizona!icon-group
Subject: IconTest Problem One Winner!
Errors-To: icon-group-request
Status: O


Paul Abrahams submitted the nicest entry (the problem was to
use Icon to compute A^B, for potentially large B - with specific
I/O restrictions.  His solution follows.

---cut here---

# Procedure to compute A^B
# Written by Paul Abrahams    November 10, 1987

procedure main()
    local a, b, bbits, prod
    every line := !&input do {
        (a := integer(line[1:6]), b:= integer(line[6:11]),
            a > 0, b > 0 ) |
            {write("Invalid input line ", image(line)); next}
        write("A = ", right(a, 5, "0"), "\nB = ", right(b, 5, "0"), "\n")
        bbits := binrep(b)
        if prod := power(a,bbits) then
            print_it(prod)
        else
            write("Too many digits in the result!\n\n")
        }
end

procedure binrep(n)
# Compute the binary representation of n (as a string)
    local retval
    retval := ""
    while n > 0 do {
        retval := n % 2 || retval
        n /:= 2
        }
    return retval
end

procedure power(a, bbits)
# Compute a to the power bbits, where bbits is a bit string.
# The result is a list of coefficients for the polynomial a(i)*k^i,
# least significant values first, with k=10000 and zero trailing coefficient
# deleted.
    local b, m1, retval
    m1 := (if a >= 10000 then [a % 10000, a / 10000] else [a])
    retval := [1]
    every b := !bbits do {
        (retval := product(retval, retval)) | fail
        if b == "1" then
            (retval := product(retval, m1)) | fail
        }
    return retval
end

procedure product(a,b)
# Compute a*b as a polynomial in the same form as for power.
# a and b are also polynomials in this form.
    local i, j, k, retval, x
    if *a + *b > 5001 then
        fail
    retval := list(*a + *hv)
    every i := 1 to *a do
        every j := 1 to *b do {
            k := i + j - 1
            retval[k] +:= a[i] * b[j]
            while (x := retval[k]) >= 10000 do {
                retval[k + 1] +:= x / 10000
                retval[k] %:= 10000
                k +:= 1
            }   }
    every i := *retval to 1 by -1 do
        if retval[i] > 0 then
            break
    return retval[1+:i]
end

procedure print_it(n)
    local ds, i, j, k
    ds := ""
    every k := *n to 1 by -1 do
        ds ||:= right(n[k], 4, "0")
    ds ?:= (tab(many("0")), tab(0))
    ds := repl("0", 4 - (*ds - 1) % 5) || ds

    every i := 1 to *ds by 50 do {
        k := *ds > i + 45 | *ds
        every j := i to k by 5 do
            writes(ds[j+:5], " ")
        write()
        }
    writes("\n\n")
end


From icon-group-request  Tue Jan 26 04:58:46 1988
From: [e-mail]
Subject: ATARI ICON.
To: [e-mail]
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Errors-To: icon-group-request
Status: O

I have a version of ICON 6.5 for Atari ST, with the following
change (from the previous version) :

. Co-expression are OK.
. Arithmetic overflow is handled.
. system() work. (depends on your shell....)
  (Most shell are not able to support system("ls")...try
  command.tos, it may work...)
  The shell is found by the SHELL environment variable.
. Faster. (Should be better than any PC or AT at that...)
. Usable from a shell or from the desktop.
  (An environment (ICON or PATH) variable can locate the ITRAN, ILINK &
  ICONX programs, or if not from a shell, a new switch in ICONT will
  tell where they are.)
. Handle environment variable for ICONX settings (Like the UNIX
   (version) (getenv() works.)
. Handle stderr redirection, just like the MSDOS version.

If you want to have it or test it, just drop me a mail.
(I will send it arc'ed and uue'coded, in several mail.)

regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
[e-mail] (arpanet)
[e-mail] (arpanet)

From icon-group-request  Tue Jan 26 13:33:32 1988
From: naucse!sbw (Steve Wampler)
To: arizona!icon-group
Subject: Solution to IconTest Problem One was corrupted...
Errors-To: icon-group-request
Status: O


The solution I posted to problem one of the IconTest was a
version that had been corrupted in transmission to me.  My
apologies, particularly to Paul, for sending that version out.
The uncorruption is:

    In the procedure product(a,b), change the line

       retval := list(*a + *hv)

    to

       retval := list(*a + *b, 0)

again, my apologies!

    -Steve Wampler

From icon-group-request  Wed Jan 27 15:51:46 1988
From: ihnp4!ihlpe!orf
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
End-Of-Header:
Email-Version: 2
X-Postmark: ihlpe!orf
To: arizona!icon-group
Subject: Re: ATARI ICON.
Ua-Message-Id: <post.orf.Tue 26 Jan 1988 14:12 CST>
End-Of-Protocol:
Content-Length: 834
Errors-To: icon-group-request
Status: O

 >
 > If you want to have it or test it, just drop me a mail.
 > (I will send it arc'ed and uue'coded, in several mail.)
 >
 > regards,
 >
 > Jean-Pierre H. Dumas
 >
 > network@frsac11 (bitnet)
 > [e-mail] (arpanet)
 > [e-mail] (arpanet)
 >

Sounds Great!!  I don't know how to reach you, so I had to send this via
the Icon group.  Jerry Nowlin just downloaded the version on the Arizona
Icon bulletin board -- and the documentation says 6.0.  We assume this is
not yours... (You may want to provide AZ the system, and then we can use the
bulletin board to download.)

Questions:

a) Will the source be sent to U. of A/Ralph?
b) if not, can we get it?
c) Does your 6.5 run on a 520?

We appreciate the work!!

Rick Fonorow
...ihlp4!ihlpe!orf
[phone]


From icon-group-request  Fri Jan 29 09:35:43 1988
From: naucse!sbw (Steve Wampler)
To: arizona!icon-group
Subject: IconTest Problem Two
Errors-To: icon-group-request
Status: O


Ok, I confess.  This isn't one of the problems from the
1987 ACM Mountain Regional Programming Contest, but a
student came to me with this yesterday and it has so
many nifty little solutions in Icon that I couldn't resist.

  The Tea-Time Tennis Troop enjoys meeting once a year for a tennis
  gala.  Since this is a social (as opposed to a sporting) event,
  they would like to schedule matches so that each player plays
  with as many other players as possible.  Consequently they have a
  hard and fast rule that no one is allowed to play more than a
  single match with anyone he has seen before.  (The TTTT always
  plays doubles - four players to a court.)

  Write a program that takes as arguments the number of available
  tennis courts and the number of players.  The output should be
  the players on each court in each round of tennis for as many
  rounds as possible until there is no way to avoid violating their
  rule on duplications.  All the courts are played on simultane-
  ously, so each player can play only one match per round.  You may
  assume that there are less than 1000 members in the TTTT, and
  that you are to keep all the courts filled each round.  For-
  tunately, all the players have names from 1 to the number of
  players.

From icon-group-request  Fri Jan 29 22:30:37 1988
From: ihnp4!ihlpf!nevin1
To: arizona!icon-group
Subject: Please add me to your email mailing list
Errors-To: icon-group-request
Status: O

Please add me to the icon-group email mailing list.  If you could, please
send confirmation that this has happened.

Thanks,
 _ __            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  Sun Jan 31 10:10:10 1988
From: [e-mail] (Richard Goerwitz)
To: [e-mail]
Subject: pointers, structures, confusion
Errors-To: icon-group-request
Status: O

Can someone out there explain to my why the following program outputs
Status: R

"hello"
"hello"
"hello"
"hello"
"hello"
"hello"

and not just "hello" plus a bunch of blank lines?


procedure main()

  List := list(4,[""])
  List[1] := AlterList(copy(List[1]))
  WriteList(List)

end


procedure AlterList(l)

  l[1] := "hello"
  return l

end


procedure WriteList(List)

  local i
  every i := 1 to *List
  do write(List[i][1])
  return 0

end




I realize that if I pass a copy of List[1] to AlterList, it will function as
expected.  But I'm not sure why.

                                                                   -Richard


From icon-group-request  Sun Jan 31 10:10:40 1988
From: [e-mail] (Richard Goerwitz)
To: [e-mail], [e-mail]
Subject: pointers, structures, confusion
Errors-To: icon-group-request
Status: O


Can someone out there explain to my why the following program outputs

"hello"
"hello"
"hello"
"hello"
"hello"
"hello"

and not just "hello" plus a bunch of blank lines?


procedure main()

  List := list(4,[""])
  List[1] := AlterList(copy(List[1]))
  WriteList(List)

end


procedure AlterList(l)

  l[1] := "hello"
  return l

end


procedure WriteList(List)

  local i
  every i := 1 to *List
  do write(List[i][1])
  return 0

end




I realize that if I pass a copy of List[1] to AlterList, it will function as
expected.  But I'm not sure why.

                                                                   -Richard

From icon-group-request  Sun Jan 31 10:38:33 1988
From: "Kenneth Walker" <kwalker>
In-Reply-To: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  pointers, structures, confusion
Errors-To: icon-group-request
Status: O

    Date: Sun, 31 Jan 88 10:29:35 CST
    From: [e-mail] (Richard Goerwitz)

    Can someone out there explain to my why ...

(I assume you ment to post the version of the program that did _not_ pass
a copy of List[1] to AlterList)

The effect that you are seeing is an interaction of 2 features of Icon:

   - the pointer semantics of lists
   - the fact that arguments are evaluated only once

The expression list(4,[""]) does _not_ create a list of 4 lists of
strings. It creates a list with 4 entries each of which references
the _same_ list contining the string "". To see why this happens,
consider the evaluation of the expression in detail:

   1) the constant 4 is evaluated
   2) "" is evaluated
   3) [] is excuted resulting in a new list containting one element, the
      string ""
   4) list() is called with 4 and a reference to the list created in the
      last step. It creates an new list with 4 elements each containing
      the reference.

If you change the contents of the list created in step 3, you will
see the change no matter which of the 4 references you use to access
the list.

From icon-group-request  Tue Feb  2 04:39:59 1988
Received: by bocklin.arizona.edu; Tue, 2 Feb 88 04:40:04 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 2 Feb 88 04:39:59 MST
Message-Id: <[e-mail]>
Received: from [128.228.1.2] by megaron.arizona.edu; Tue, 2 Feb 88 04:39:43 MST
Received: from FRSAC11.BITNET by CUNYVM.CUNY.EDU ; Tue, 02 Feb 88 06:38:45 EST
Date: Tue, 02 Feb 88 12:38:52 GMT
To: [e-mail]
From: [e-mail]
Comment: CROSSNET mail via SMTP@INTERBIT
Subject: Icon 6.5 for Atari ST
Errors-To: icon-group-request

If you are not into Atari ST, or the Icon programming language,
just go to the next message of your favorite mailer.

                     +++++++++++++++++++++++++++

ICON 6.5 (Implementation revision (e)) for the ATARI ST
has been sent to some people.

As the files are quite large, and I do not wish to abuse the local
mailer, I will ask any further request to be redirected to the nearest
person that already have it.

Here is the list where the binaries have been sent:

Vitas P.                rochester!ritcv!vxp6840 (uucp)
Denise ?                rochester!ritcv!dsh3059 (uucp)
Mark Storin             ihnp4!uwmcsd1!lakesys!mark (uucp)
Marty Wiedmeyer         ihnp4!uwmcsd1!lakesys!martin (uucp)
Rich ?                  ihnp4!uwmcsd1!lakesys!rich (uucp)
Plinio Barbeito         [e-mail] (edu)
Bertrand Decouty        decouty@frcicg71 (earn)
Klaus Hahn              hahn_k@dmrhrz11 (earn)
Greg Onufer             ucbvax!ucdavis!uop.edu!root (uucp)
Andres F. Moreno        [e-mail] (edu)
Bob Bright              bright@dalac (bitnet)
Matthias Moritz         u608017@hnykun11 (earn)
Ruud van der Plaats     vdplaats@hnykun53 (earn)
Gordon Joly             [e-mail] (uk)
Rick Fonorow            ihnp4!ihlpe!orf (uucp)
Wilfried Bloemberg      fonetiek@hnykun52 (earn)
Jerry Nowlin            ihnp4!ihuxy!nowlin (uucp)

The sources will not be distributed by me, They have been sent to
the Icon project at U. of Arizona, and to the 2 original implementors.

Some of you asked for some documentation on ICON or on this peculiar
version: I can send upon request the article on Icon version 6 from
U. of Arizona, and the various files that come with the former
implementation.

The reference book for the language beeing the book:
Griswold, Ralph E. and Madge T. Griswold. The Icon Programming
Language, Prentice-Hall, Inc., Englewood Cliffs, New Jersey.
1983.

Send all inquiries to [e-mail]

                    ++++++++++++++++++++++++

Notes on this (e) implementation:

-It is done using MCC Lattice 3.04 C compiler, with sources coming
from U. of Az (Rick Fonorow & Jerry Nowlin, made it for the 3.03 C).
I added the support for various missing stuff, the arithmetic overflow
and Co-expression assembly code was furnished to me by Ralph Griswold.
Ralph did answer to all questions that allowed me to bring this code up.

-All binaries are called .TTP in order to be called from the desktop,
without using a shell if you dont like it, or if you are short in memory.
I used/developped the thing on a 1040ST Monochrome, with a 400K
ram-disk. I think iconx.ttp will work on 520ST, with TOS in ROM.
Iconx.ttp takes 200K for the heap, and 10K for the stack, plus data
and text segment.

-If you want to use icont: it will attempt to find itran/ilink/iconx
by looking at the ICON environment variable, that should be set to
the disk/directory where these can be found, then it will try for the
PATH variable, then for the root directory of all currently mounted
disk drives, in alphabetical order.
If you are invoking icont.ttp from the desktop, you can tell where are
the other binaries by the "-p disk:\dir" option.
All options to icont can be in upper or lower case.

-If you want to use a very large Icon program, you may have to
increase some memory area, in this case, you will have to tell the
startup code of Iconx, with the % option, before all other arguments
on the command line. {iconx> is currently equivalent to <iconx %200000>,
you may have to try %300000 or more. The number after % is the total
heap size, in byte.)

-If you want to use the system() call, find a shell that can do what
you want... I have'nt yet...
Iconx will look into the SHELL environment variable, it should be set
to the complete filename of the shell you want to invoke.
I have tried PCOMMAND, ASH, MSH, COMMAND.TOS, and the lowly last one
gave me best results... (most shells are not able to understand
arguments passed to them, if this is an internal command, they
always try to "fork" it...)
(In fact it does not need to be a shell, just any program can be
"forked", args passed, and the exit code will be returned back.)
(I am still looking for the sources of a good shell that I can hack
and make useful on the ST, whatever be your keyboard religion.)

I would appreciate any hints of bugs, to be reported, altough
it may take time to fix... may be version 7...

Regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
[e-mail] (arpanet)
[e-mail] (arpanet)

From icon-group-request  Wed Feb 10 02:27:40 1988
Received: by bocklin.arizona.edu; Wed, 10 Feb 88 02:27:44 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Feb 88 02:27:40 MST
Received: from SUN.COM by megaron.arizona.edu; Wed, 10 Feb 88 02:27:31 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
    id AA09831; Wed, 10 Feb 88 01:26:41 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA01498; Wed, 10 Feb 88 01:26:50 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA23975; Wed, 10 Feb 88 01:19:03 PST
Received: from Nuksun.Europe.Sun.COM (inuksun) by UK.Sun.COM (3.2/SMI-3.2)
    id AA01478; Wed, 10 Feb 88 09:26:26 GMT
Received: from stevie.nuksun.uucp by Nuksun.Europe.Sun.COM (1.1/SMI-3.2)
    id AA02791; Wed, 10 Feb 88 09:25:55 GMT
Received: by stevie.nuksun.uucp (3.2/SMI-3.2)
    id AA18977; Wed, 10 Feb 88 09:25:49 GMT
Date: Wed, 10 Feb 88 09:25:49 GMT
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: E-mail handling software - testers wanted
Errors-To: icon-group-request

I have a number of programs to do various things with e-mail,
which I would like to put out in the field for testing.  Since
they are written in Icon, this is the logical group to approach.
The following programs are available:

classify:    reorganises mail folders and can produce tables
        of contents for them.

getmail:    retrieves selected (by number, so a table of contents
        is useful) mail items from a folder.

mailtrim:    tidies up a mail folder by throwing away redundant
        headers.

mp:        Has proved especially popular with Sun customers,
        prints e-mail messages and/or folders on a PostScript
        printer with relatively clean-looking headings.

These programs have seen quite a lot of use collectively.  They all
rely on a "mailio" library also in Icon, which could do with a tidier
rewrite.

If anyone is prepared to take these programs and feed back suggestions
for improvement could they please reply.  I will distribute the programs
to those interested in about a week.

Yours fraternally
Steve Holden

From icon-group-request  Wed Feb 10 08:36:28 1988
Received: by bocklin.arizona.edu; Wed, 10 Feb 88 08:36:31 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Feb 88 08:36:28 MST
Received: from SUN.COM by megaron.arizona.edu; Wed, 10 Feb 88 08:36:22 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
    id AA14325; Wed, 10 Feb 88 07:35:34 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA08779; Wed, 10 Feb 88 07:35:43 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA26719; Wed, 10 Feb 88 07:27:50 PST
Received: from snail.sun.com (snail-swanbb) by UK.Sun.COM (3.2/SMI-3.2)
    id AA04825; Wed, 10 Feb 88 15:34:52 GMT
Received: from Sun.COM (arpa-dev) by snail.sun.com (4.0/SMI-3.2)
    id AA26709; Wed, 10 Feb 88 07:27:12 PST
Received: from megaron.arizona.edu by Sun.COM (4.0/SMI-3.2)
    id AA14304; Wed, 10 Feb 88 07:34:27 PST
Received: by megaron.arizona.edu; Wed, 10 Feb 88 08:34:56 MST
Date: Wed, 10 Feb 88 06:01:27 mst
From: sunuk!sun!arizona.edu!naucse![e-mail] (Steve Wampler)
Message-Id: <8802101301.AA00900@naucse>
To: sunuk!nuksun!stevie![e-mail],
        sun!arizona.edu![e-mail]
Subject: Re:  E-mail handling software - testers wanted
Errors-To: icon-group-request

I would like to try out your Email processors.  May I?

Steve Wampler

From icon-group-request  Wed Feb 10 14:22:38 1988
Received: by bocklin.arizona.edu; Wed, 10 Feb 88 14:22:42 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Feb 88 14:22:38 MST
Received: from jvax.ccit.arizona.edu by megaron.arizona.edu; Wed, 10 Feb 88 14:22:36 MST
Received: from BITNET-GATEWAY by jvax.ccit.arizona.edu; Wed, 10 Feb 88 13:35 MST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 3332; Wed,
 10 Feb 88 19:22:18 GMT
Date: Wed, 10 Feb 88 18:52:07 GMT
From: Sebastian Rahtz <[e-mail]>
Subject: icon e-mail programs
To: icon-group <[e-mail]>
Via:        UK.AC.RL.EARN; Wed, 10 Feb 88 19:22:17 GMT
Via:        UK.AC.NCL; 10 FEB 88 19:22:13 GMT
Message-Id: <[e-mail]>
Errors-To: icon-group-request

i would love to acquire Steve Holden's programs, but the mail
route is unclear - can anyone send a clearer address for him?

sebastian rahtz, computer science, southampton, uk
[e-mail]

From icon-group-request  Wed Feb 10 18:59:46 1988
Received: by bocklin.arizona.edu; Wed, 10 Feb 88 18:59:49 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 10 Feb 88 18:59:46 MST
Received: from SUN.COM by megaron.arizona.edu; Wed, 10 Feb 88 18:59:39 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
    id AA26731; Wed, 10 Feb 88 17:58:52 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA22560; Wed, 10 Feb 88 17:59:01 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA13290; Wed, 10 Feb 88 17:50:25 PST
Received: from snail.sun.com (snail-swanbb) by UK.Sun.COM (3.2/SMI-3.2)
    id AA04436; Thu, 11 Feb 88 01:56:23 GMT
Received: from sun.Sun.COM (sun-bb) by snail.sun.com (4.0/SMI-3.2)
    id AA13255; Wed, 10 Feb 88 17:47:32 PST
Received: from cbosgd.UUCP by sun.Sun.COM (4.0/SMI-4.0)
    id AA22514; Wed, 10 Feb 88 17:55:15 PST
Received: by cbosgd.MIS.OH.ATT.COM (smail2.1)
    id AA16747; 10 Feb 88 18:34:00 EST (Wed)
Received: by n8emr.UUCP (smail2.5)
    id AA04604; 10 Feb 88 18:20:30 EST (Wed)
Received: by uncle.UUCP (smail3.0)
    id AA05629; 10 Feb 88 18:13:10 EST (Wed)
To: ihnp4!arizona!sunuk!nuksun!stevie![e-mail],
        sun!arizona.edu![e-mail]
Subject: Re:  E-mail handling software - testers wanted
Message-Id: <[e-mail]>
Date: 10 Feb 88 18:13:05 EST (Wed)
From: sunuk!sun!uncle![e-mail] (John B. Milton)
Errors-To: icon-group-request

I volunteer
--
John Bly Milton IV, [e-mail], {ihnp4|cbosgd}!n8emr!uncle!jbm
home: [phone], work: [phone], FLAME via email :)

From icon-group-request  Fri Feb 12 11:16:04 1988
Received: by bocklin.arizona.edu; Fri, 12 Feb 88 11:16:07 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 12 Feb 88 11:16:04 MST
Received: from SUN.COM by megaron.arizona.edu; Fri, 12 Feb 88 11:15:56 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
    id AA17076; Fri, 12 Feb 88 10:14:51 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA09395; Fri, 12 Feb 88 10:14:58 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA16524; Fri, 12 Feb 88 10:05:37 PST
Received: from Nuksun.Europe.Sun.COM (inuksun) by UK.Sun.COM (3.2/SMI-3.2)
    id AA24088; Fri, 12 Feb 88 18:12:57 GMT
Received: from stevie.nuksun.uucp by Nuksun.Europe.Sun.COM (1.1/SMI-3.2)
    id AA11741; Fri, 12 Feb 88 18:12:26 GMT
Received: by stevie.nuksun.uucp (3.2/SMI-3.2)
    id AA04997; Fri, 12 Feb 88 18:12:22 GMT
Date: Fri, 12 Feb 88 18:12:22 GMT
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re: Mail handling software
Errors-To: icon-group-request

Those who requested this package should have received it by now.
Iff you asked for it and never got a reply, (some of my replies
bounced) please contact me to try and work out a route or, worst
case, arrange for delivery on punched cards :-) or more suitable
media.

Regards
Steve Holden
Sun Microsystems UK Ltd.        [phone]
                    {many nodes}!sun!sholden
                    [e-mail]

From icon-group-request  Mon Feb 15 13:51:35 1988
Received: by bocklin.arizona.edu; Mon, 15 Feb 88 13:51:37 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 15 Feb 88 13:51:35 MST
Received: from SUN.COM by megaron.arizona.edu; Mon, 15 Feb 88 13:51:25 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-3.2)
    id AA08487; Mon, 15 Feb 88 12:50:32 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA15727; Mon, 15 Feb 88 12:50:53 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA20369; Mon, 15 Feb 88 12:42:43 PST
Received: from snail.sun.com (snail-swanbb) by UK.Sun.COM (3.2/SMI-3.2)
    id AA18477; Mon, 15 Feb 88 20:50:22 GMT
Received: from Sun.COM (arpa-dev) by snail.sun.com (4.0/SMI-3.2)
    id AA20361; Mon, 15 Feb 88 12:42:32 PST
Received: from askone.s1.gov by Sun.COM (4.0/SMI-3.2)
    id AA08484; Mon, 15 Feb 88 12:50:03 PST
Received: by askone.s1.gov id AA25051; Mon, 15 Feb 88 12:49:26 PST
    id AA25051; Mon, 15 Feb 88 12:49:26 PST
Date: Mon, 15 Feb 88 12:49:26 PST
From: sunuk!sun!mordor.s1.gov![e-mail]
Message-Id: <[e-mail]>
To: nuksun!stevie![e-mail]
Cc: sun!arizona.edu![e-mail]
In-Reply-To: Steve Holden - TSE's message of Wed, 10 Feb 88 09:25:49 GMT <[e-mail]>
Subject: E-mail handling software - testers wanted
Errors-To: icon-group-request

I'm interested....  sorry it's so late but I've been gone to Usenix.
  --berry

From icon-group-request  Tue Feb 16 17:20:44 1988
Received: by bocklin.arizona.edu; Tue, 16 Feb 88 17:20:47 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 16 Feb 88 17:20:44 MST
Received: from sphinx.uchicago.edu by megaron.arizona.edu; Tue, 16 Feb 88 17:19:35 MST
Received: from sophist.uchicago.edu by sphinx.uchicago.edu (5.52/2.0Sx)
    id AA17049; Tue, 16 Feb 88 18:19:15 CST
Return-Path: <[e-mail]>
Received:  by sophist.uchicago.edu (3.2/UofC3.0)
    id AA00347; Tue, 16 Feb 88 18:15:41 CST
Date: Tue, 16 Feb 88 18:15:41 CST
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Errors-To: icon-group-request

Subject: p(a,b,c[]) and &null

I was recently going over old icon-group mail, and noted the following:

     If we call a procedure defined as having arguments (a,b,c[]) with
     p(a), what will be passed to the procedure is (.a,&null,[]).

Why?  It would seem more natural to think that the same thing that happens to
b should happen to c, even though the notation there makes it clear that if
any values get passed, in addition to a and b, they are formed into a list.
To put it more lucidly:  I would expect that if we pass on a value for a only,
that b and c would turn up being null.  The notation p(a,b,c[]) simply means
to me that anything after b get put into a list (if there is in fact anything
to put there).  The fact that [] gets passed even in cases where nothing beyond
a and b is present seems strange to me.

Obviously I am missing something.

Could some kind soul(s) explain to me the motivation behind passing [] even
in cases where no value is present?

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-request  Tue Feb 16 22:13:17 1988
Received: by bocklin.arizona.edu; Tue, 16 Feb 88 22:13:20 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 16 Feb 88 22:13:17 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Tue, 16 Feb 88 22:13:08 MST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
    id AA10342; Tue, 16 Feb 88 20:45:19 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 17 Feb 88 03:08:12 GMT
From: marque![e-mail]  (Martin Wiedmeyer)
Organization: Marquette University, Milwaukee, WI
Subject: Re: Mail handling software
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request

I tried to send e-mail & my message got bounced back as 'host unknown'.
Please send me your Icon e-mail messaging files.

Thanks,

Marty

From icon-group-request  Wed Feb 17 10:57:42 1988
Received: by bocklin.arizona.edu; Wed, 17 Feb 88 10:57:45 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 17 Feb 88 10:57:42 MST
Date: Wed, 17 Feb 88 10:57:39 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Wed, 17 Feb 88 10:57:39 MST
To: icon-group
Subject: Version 7 of Icon for UNIX and VAX/VMS
Errors-To: icon-group-request

Version 7 of Icon is now available for UNIX and VAX/VMS systems.

Version 7 has a number of new features, including

    1. Functions for bit operations on integers, inserting and
       deleting tabs in text, accessing operating-system
       information, etc., etc.

    2. Error trace back, showing the sequence of procedure calls
       leading to the error, followed by an image of the offending
       expression.

    3. Procedures with a variable number of arguments.

    4. Corrected handling of co-expression activation, allowing use
       of co-expressions in a coroutine fashion, and also co-expression
       tracing.

    5. Corrected handling of string scanning so that the values of
       &subject and &pos are properly restored whenever scanning is
       exited (no matter how).

    6. And lots of other "goodies".

Version 7 is distributed on magnetic tape. It costs $25, which includes
documentation and shipping in the United States and Canada. There is a $10
additional charge for shipping to other countries.

The UNIX and VMS systems are independent; if you need Version 7 of Icon
for both systems, order both. For UNIX, specify tar or cpio format and 1600 or
6250 bpi. For VMS, specify 1600 or 6250 bpi.

Checks should accompany orders and be made payable to the University
of Arizona.  Checks must be written on a bank with a branch in the
United States.

Send orders to:

    Icon Project
    Department of Computer Science
    The University of Arizona
    Tucson, AZ   85721

Work is underway on Version 7 of Icon for other systems. These implementations
will be announced as they become available.

If you have questions, send electronic mail to icon-project@arizona
(*not* icon-group@arizona).

From icon-group-request  Wed Feb 17 11:04:21 1988
Received: by bocklin.arizona.edu; Wed, 17 Feb 88 11:04:24 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 17 Feb 88 11:04:21 MST
Date: Wed, 17 Feb 88 11:04:20 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Wed, 17 Feb 88 11:04:20 MST
To: icon-group
Subject: Version 7 Icon for VMS
Errors-To: icon-group-request

I forgot to mention Version 7 of Icon requires VMS 4.6 or higher.

From icon-group-request  Wed Feb 17 13:31:03 1988
Received: by bocklin.arizona.edu; Wed, 17 Feb 88 13:31:07 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 17 Feb 88 13:31:03 MST
Date: Wed, 17 Feb 88 13:31:01 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Wed, 17 Feb 88 13:31:01 MST
In-Reply-To: <[e-mail]>
To: icon-group
Subject: variable args
Errors-To: icon-group-request

    Date: Tue, 16 Feb 88 18:15:41 CST
    From: Richard Goerwitz <[e-mail]>

    I was recently going over old icon-group mail, and noted the following:

         If we call a procedure defined as having arguments (a,b,c[]) with
         p(a), what will be passed to the procedure is (.a,&null,[]).

    Why?   <text deleted>
    I would expect that if we pass on a value for a only,
    that b and c would turn up being null.   <text deleted>
    The fact that [] gets passed even in cases where nothing beyond
    a and b is present seems strange to me.

(NOTE, this feature is only available in Version 7 of Icon, which has not
yet been released for all systems)

It is indead possible either to argue that c should be null or to argue that
it should be the empty list. The philosophical argument for the empty list
is that c is defined to be a list and that the null value is not a list.
There is however a practical argument which deals with how c is likely to
be used. c contains the optional arguments to the procedure. If there are
no optional arguments in the call and c contains the empty list, then
code which tries to access the non-existant elements of c will simply
fail. In most situations the result is exactly what you want - the code
is simply not executed. If c were the null value, an attempt to do an
element access will result in a run-time error; thus you will need a
special test for null to handle this case.

From icon-group-request  Thu Feb 18 02:46:05 1988
Received: by bocklin.arizona.edu; Thu, 18 Feb 88 02:46:12 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 18 Feb 88 02:46:05 MST
Received: from SUN.COM by megaron.arizona.edu; Thu, 18 Feb 88 02:45:34 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-4.0)
    id AA19478; Thu, 18 Feb 88 01:44:41 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA27678; Thu, 18 Feb 88 01:44:49 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA21030; Thu, 18 Feb 88 01:35:32 PST
Received: from Nuksun.Europe.Sun.COM (inuksun) by UK.Sun.COM (3.2/SMI-3.2)
    id AA14507; Thu, 18 Feb 88 09:43:19 GMT
Received: from stevie.nuksun.uucp by Nuksun.Europe.Sun.COM (1.1/SMI-3.2)
    id AA08569; Thu, 18 Feb 88 09:42:41 GMT
Received: by stevie.nuksun.uucp (3.2/SMI-3.2)
    id AA06649; Thu, 18 Feb 88 09:42:35 GMT
Date: Thu, 18 Feb 88 09:42:35 GMT
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Mail handling software
Errors-To: icon-group-request

If you aren't interested in this stuff, please delete this mail and
accept my apologies for tying up bandwidth.  I've had a number of
requests for this software to which, due to mail addressing problems,
I have been unable to reply.

In general I am quite willing to try and communicate with people about
this stuff, but to make sure everyone gets it I am posting it to the
group.  What follows is a copy of the original mail which went out in
response to requests I got up to last Friday.  I have also done a couple
of individual mailing since.

Steve Holden
{many nodes}!sun!sunuk!nuksun!stevie!steveh
{many nodes}!sun!sholden
[e-mail]
---------------------------------------------------------------------------
Well, here they are: each program is preceded by a line containing its
name between asterisks.  Icon hackers should be able to sort that out,
but I'd appreciate it if someone would enlighten me as to a reliable
way to produce shell archives.

I was unable to reply to some of the people who mailed me - there are
best-guess addresses for them.  I'll post icon-group to let them know
it's gone out, and they can try to get it from the lucky people who
*do* receive it.

No makefile, no help, no README, just software.  I'd really like to
bundle this into a public domain package.  Any ideas for improvement,
please mail me.

Steve
********************* classify.1l *********************
.TH CLASSIFY 1 "19 Oct 1987" "Sun UK North"
.SH NAME
classify \- re-order or index a mail folder by subject alphabetically
.SH SYNOPSIS
.B classify
[
\fB\-i\fP
]
.SH DESCRIPTION
.I Classify
filters its input, which is assumed to be a mail folder,
and produces an output which consists of the same messages
sorted by subject.
.sp
The output resulting from re-ordering
can be processed as a folder
by the mail system in the usual ways.
.sp
An option is available to produce an index for the folder instead
of a new folder.  The index is always in alphabetical order.
If the file is re-organised first then the items in the index
should be in ascending number sequence.
.SH OPTIONS
The possible options are:
.TP
\fB\-i\fP
Instead of producing a mail folder as output, produce a
readable index.
Index lines look something like this:
.nf

\fBSubject-line  . . . . . . . . . . . . .  12; 13, 14, 15\fP

.fi
where the number(s) before the semi-colon represent messages with the
given subject line, and the number(s) after it represent messages which
refer to the given subject line.
.SH EXAMPLES
.LP
To organise a mail folder alphabetically by subject-line:
.nf

    \fBclassify < mailfile > /tmp/rhubarb
    mv /tmp/rhubarb mailfile\fP

.fi
.LP
To print a table of contents for a mail file two-up on a laserwriter:
.nf

    \fBclassify -i < mailfile | enscript -q -2r -f Courier7

.fi
.SH "SEE ALSO"
\fBgetmail(1), mailtrim(1), mp(1)\fP
.SH BUGS
Header lines which are repeated in a message (such as \fBReceived\fP)
will have all but the last occurrences silently removed.
Subjects which generate index lines too long for the output line will
produce erratic output.  There is no control over output line width.
********************* classify.icn *********************
#
#    classify.icn:    read a mail file and produce a subject-sorted
#            list of mail items and replies, or an index to
#            the mail file.
#
#    @(#)classify.icn    1.4    10/20/87
#
#    Bugs:        Sort is case-sensitive.
#            Craps out on overlength index lines.
#            (Possibly elsewhere) subjects are not always
#                well-trimmed.
#            Does not label untitled mail correctly :-(
#
link mailio        # mail i/o library

procedure main(arg)


while arg[1][1] == "-" do
    case (o :=pop(arg))[2] of {
    "i":    indexrun := ""
    default:stop("Unrecognised classify option: ",o)
    }

if *arg = 0 then arg := [ "-" ]
if *arg > 1 then stop("Bug: can only handle one file at a time. Sorry.")

ttls := table([])
refs := table([])

msg := []
while filename := pop(arg) do {
    if filename == "-"
    then ifn := &input
    else ifn := open(filename,"r") | stop("Cannot open file ",filename)
    while put(msg,readmail(ifn))
}
#DB7 write(*msg," items in mail file")

every m := 1 to *msg do {
    trim( \(msg[m].header["Subject"]) | "** Untitled Mail" ) ?
        if (="Re:" & tab(upto(~':\t ')))
        then refs[ms := tab(0)] |||:= [m]
        else ttls[ms := tab(0)] |||:= [m]
#DB7    write(ms,":: ",m)
}
#DB7 write("Ttls: ",*ttls,", Refs: ",*refs)

tlst := sort(ttls)
rlst := sort(refs)

#DB9 write("Tlist: ",*tlst,"  Rlist: ",*rlst)
#DB9 write("Title list")
#DB9 every x := !tlst do {
#DB9     writes(x[1],":")
#DB9     every(writes(!x[2],":"))
#DB9     write()
#DB9 }
#DB9 write("Reference list")
#DB9 every x := !rlst do {
#DB9     writes(x[1],":")
#DB9     every(writes(!x[2],":"))
#DB9     write()
#DB9 }
#DB9 write("\n")

while (*tlst > 0) | (*rlst > 0) do {        # for each subject...
#    write("## ",*tlst,"+",*rlst)
    if (rlst[1][1] << tlst[1][1]) | (*tlst = 0)
    then {                    # orphaned reference
        subject := rlst[1][1]
        refs := pop(rlst)[2]
        ttls := []
    } else {                # message
        subject := tlst[1][1]
        ttls := pop(tlst)[2]
        if subject == rlst[1][1]    # handle references, if any
        then refs := pop(rlst)[2]
        else refs := []
    }
    if \indexrun then {
#        write("Subject: ",subject, " -- ", *ttls,"+", *refs)
        present(subject,ttls,refs)
    } else
    every writemail(msg[!ttls | !refs])
}

end

procedure present(s, t, r, owid)

local    ts        # temp string for message numbers

/owid := 72
ts := ""
if *t > 0 then {
    every i := 1 to *t-1 do ts ||:= t[i] || ", "
    ts ||:= t[-1]
} else ts := "- "
if *r > 0 then {
    ts ||:= "; "
    every i := 1 to *r-1 do ts ||:= r[i] || ", "
    ts ||:= r[-1]
}
s ||:= repl(" ",3-(*s % 3))
write(s,": ",right(ts,owid-*s-2,".. "))
return
end
********************* getmail.1l *********************
.TH GETMAIL 1 "15 Oct 1987" "Sun UK North"
.SH NAME
getmail \- select messages from a mail folder by number
.SH SYNOPSIS
.B getmail
i[-j] ...
.SH DESCRIPTION
.I Getmail
filters its input, which is assumed to be a mail folder,
and produces an output which consists of those messages which
are selected by number from the command line.
.sp
The resulting output can be processed as a folder
by the mail system in the usual ways.
.sp
The arguments are of the form:
.TP
\fB\i\fP
Include the \fIi\fPth message.
.TP
\fB\i-j\fP
Include the \fIi\fPth message up to the \fIj\fPth one.
.\".TP
.\".B \-n
.\"No message bodies will be output, only the header lines.
.SH EXAMPLES
.LP
To store the first ten messages from a folder at the end of
another folder:
.nf

    \fBgetmail 1-10 < folder1 >> folder2\fP

.fi
.LP
To print messages 3,4,5,6 and 12 from a mail folder:
.nf

    \fBgetmail 3-6 12 < mailfile | mpt\fP

.fi

.SH "SEE ALSO"
\fBmailtrim(1), mp(1), classify(1)
.SH BUGS
Header lines which are repeated in a message (such as \fBReceived\fP)
will have all but the last occurrences silently removed.
********************* getmail.icn *********************
#
#    getmail.icn:    a program for handling mail
#            in the UNIX environment.
#
#    @(#)getmail.icn    1.4    10/9/87
#
#    Usage:        getmail n[-m] ... < mailfile
#
#    1.3 changes:
#
#    Accept arguments of the form n or n-m
#
#    1.4 changes:
#
#    Stop reading mail file when highest requested item has been
#    processed.  Comment if there are fewer messages than expected.
#
link mailio            # mail i/o package

record range(lower,upper)

procedure main(argv)

arglst := []
uplimit := 0
while (a:=pop(argv)) do
    a ? {
        put(arglst,r := range(
            l := tab(many('01234567789')),
            (pos(0) & l) |
                (="-" & tab(many('01234567789')))
        )) | Usage()
        uplimit <:= r.upper
    }

item_no := 0

#DB7    while r := pop(arglst) do write(r.lower,"-",r.upper)
#DB7    ("Debugged")

while (msg := readmail() & item_no < uplimit) do {

    item_no +:= 1
    every i := 1 to *arglst do {
        a := arglst[i]
        if a.lower <= item_no & a.upper >= item_no
        then {
            writemail(msg)
            break
        }
    }
}
if item_no < uplimit then stop("Only ",item_no," messages this file")
end

procedure Usage()

stop("Usage: getmail n[-m] ...")

end
********************* mailio.3l *********************
.TH MAILIO 3 "15 Oct 1987" "Sun UK North" "ICON LIBRARY FUNCTIONS"
.SH NAME
mailio \- handle mail folders in Icon programs
.SH SYNOPSIS
.nf
\fB
link mailio

record message(from,header,body)

procedure readmail(f)
procedure writemail(msg,f)
\fP
.fi
.SH DESCRIPTION
.I Readmail
reads the file given as an argument (or standard input by default)
and returns a
.B message
record.
.sp
The
.B from
field is the first line of the message.
The
.B header
field is a table where the entry values are the header keywords
(such as
.I Date
and
\fISubject\fP), and the assigned values are the
remainder of the header line with leading spaces trimmed.
The
.B body
field is a list of the lines of the message.
Note that readmail maintains an internal one-line buffer,
so you should not try and mix calls of readmail with other
input from the same file.
.sp
.I Writemail
takes a
.B message
record and writes it to the specified file (or standard output by
default).
.SH EXAMPLES
.LP
To copy every message from standard input to standard output:
.nf
\fB
    while writemail(readmail())
\fP
.fi
.LP
To write just the first lines and Subject headers (if present)
from a mail folder:
.nf
\fB
    while msg := readmail do {
        write(msg.from)
        write(\\msg.header["Subject"])
        write
    }
\fP
.fi

.SH "SEE ALSO"
\fBgetmail(1), mailtrim(1), mp(1), classify(1)\fP
.SH BUGS
Header lines which are repeated in a message (such as \fBReceived\fP)
will have all but the last occurrences silently removed.
It is hoped this restriction will be removed, at the expense of
a change in the format of the
.B message
record, at a later date.
********************* mailio.icn *********************
#
#    mailio.icn:    a skeletal package for reading and
#            writing mail in the UNIX environment.
#
#    @(#)mailio.icn    1.3    11/13/87    SMUKL
#
#    To test :    Using a main loop of while writemail(readmail())
#            should be the same as the input file.
#            (BUG: repeated header fields will be omitted
#            in the current version, and probably forever).
#
#    Note:        Name changed to mailio from mailskel at delta 1.5
#

record    message(from,header,body)

global    the_next_line


procedure writemail(msg,f)

local    t, t1, i

/f := &output
write(f,msg.from)
t := sort(msg.header)
i := 0
while (t1 := t[i +:= 1]) do
    write(f,t1[1],": ",t1[2])
every write(f,!msg.body)
return

end

procedure readmail(f)

local    line, fromline, headings, body
static    hch
initial    hch := &ucase ++ &lcase ++ '-'

/f := &input
headings := table()
if match("From ",fromline := read_header_line(f)) then {
    while line := read_header_line(f) do {
        line ?
        (headings[tab(many(hch))] := (tab(many(': \t')) & tab(0)))
    }

    body := []
    while (line := read_body_line(f)) do {
        put(body,line)
    }
    return message(fromline,headings,body)
}

end

#########################################################################
#                                    #
#    Private routines to this package.                #
#                                    #
#########################################################################

procedure read_header_line(f)

local the_line

initial the_next_line := read(f) | exit(0)

if (the_line := the_next_line) == "" then fail
else while (any(' \t',the_next_line := (read(f) | fail) \ 1 )) do {
    the_line ||:= "\n" || the_next_line
}
return the_line

end

procedure read_body_line(f)

local tmp

if match("From ",the_next_line) then fail
tmp := read(f) | "From "
tmp :=: the_next_line
return tmp

end
********************* mailtrim.1l *********************
.TH MAILTRIM 1 "15 Oct 1987" "Sun UK North"
.SH NAME
mailtrim \- remove unwanted headers from a mail folder
.SH SYNOPSIS
.B mailtrim
[
\fB\-n\fP
] [
\fB\-i\fP keyword ...
]
.SH DESCRIPTION
.I Mailtrim
filters its input, which is assumed to be a mail folder,
and produces an output which consists of the same messages with
only selected header fields from the input.
.sp
The first line of messages is never removed, as this is used by the
mail system to identify the start of a message.
Requested header lines which do not occur in a message being processed
will not appear in the output.
.sp
The resulting output can be processed as a folder
by the mail system in the usual ways.
.sp
The possible options are:
.TP
\fB\-i\fP keyword ...
Include only the message headers beginning with the given keywords.
If this option is omitted mailtrim will remove all but the \fBTo\fP, \fBFrom\fP,
\fBCc\fP, \fBDate\fP and \fBSubject\fP header lines, which will be
presented in that order.
.TP
.B \-n
No message bodies will be output, only the header lines.
.SH EXAMPLES
.LP
To get a listing of the subject lines of a mail folder:
.nf

    \fBmailtrim -n -i Subject < mailfile > subjects\fP

.fi
The output file will look something like this:
.nf
\fB
>From sunuk!sun!texsun!sun!rice.edu!Sun-Spots-Request Tue Sep 15 08:14:17 1987
Subject:  Sun-Spots Digest, v5n42

>From sunuk!sun!texsun!sun!rice.edu!Sun-Spots-Request Fri Sep 18 05:39:57 1987
Subject:  Sun-Spots Digest, v5n43

>From sunuk!sun!sunrise!sunnyc!exchange!mitch Fri Sep 18 05:23:20 1987

>From sunuk!sun!sunaus!yo Tue Sep 15 08:17:53 1987
Subject: 16 bit parallel interface card

>From sunuk!sun!sunuk!sungy!sunmuc!gaby Wed Sep 16 08:32:43 1987
Subject: 26 " monitor sought
\fP
.fi
.LP
To tidy up a mail folder:
.nf

    \fBmailtrim < mailfile > /tmp/rhubarb
    mv /tmp/rhubarb mailfile\fP

.fi
.SH "SEE ALSO"
\fBgetmail(1), mp(1), classify(1)
.SH BUGS
Header lines which are repeated in a message (such as \fBReceived\fP)
will have all but the last occurrences silently removed.
********************* mailtrim.icn *********************
#
#    mailtrim.icn:    a filter to trim mail files into smaller
#            ones by deleting non-required headers.
#
#    @(#)mailtrim.icn    1.5    10/20/87
#
#    Usage:        mailtrim  [-n] [-i keyword ...]
#
link mailio            # mail i/o library

procedure main(arg)

local    msg,            # store for mail message
    klist,            # list of keywords to print headers
    a            # argument being processed
#
#    Note: although not mentioned in documentation, the
#        order of output fields is their order in klist
#
klist := ["To","From","Cc","Date","Subject"]    # establish defaults
while arg[1][1] == "-" do {

    case (a := pop(arg)[2:0]) of {
    "i":    {
        klist := []            # clear defaults
        while (a:= pop(arg)) do        # build list
            klist |||:= [a]
        }
    "n":    nflag := ""
    default: stop("Unrecognised argument: -",a)
    }

}
while msg := readmail() do {        # for each message in the folder
write(msg.from)                # always include the first line
every hwrite(msg.header, !klist)    # include requested headers
if /nflag                # body required?
then every write(!msg.body)        # yes: write lines out    (body[1]
else write()                # no : terminate header    (always blank!
}

end

procedure hwrite(tbl,key)

write(key,": ",\tbl[key])

end

procedure Usage()
    stop("Usage: mailtrim [-n] [-i keyword ...]")
end
********************* mp.pro.ps *********************
%!PS-Adobe-1.0
%%Creator: steve holden
%%Title: @(#)mp.pro.ps    1.1    2/18/87
%%CreationDate: see above
%%DocumentFonts: Times-Bold Times-Roman Courier
%%Pages: (atend)
%%EndComments
%

save /nuksunmailsave exch def
/font1d /Times-Bold findfont 10 scalefont def

/font2d /Times-Roman findfont 10 scalefont def

/font3d /Courier findfont 9 scalefont def

/fontHd /Helvetica-BoldOblique findfont 15 scalefont def

/fontH2 /Helvetica-BoldOblique findfont 10 scalefont def

/fontNd /Times-Bold findfont 12 scalefont def

/Bold {font1d setfont} def
/Roman {font2d setfont} def
/Courier {font3d setfont} def
/fontH {fontHd setfont} def
/fontD {fontH2 setfont} def
/fontN {fontNd setfont} def

Courier

/endpage
{
    gsave
    fontH
    newpath
    90 756 moveto
    100 736 10 180 270 arc
    536 736 10 270 0 arc
    536 756 10 0 90 arc
    100 756 10 90 180 arc
    closepath 0.75 setgray fill
    newpath
    318 746 15 0 360 arc
    gsave 1 setgray fill grestore
    closepath
    0 setgray stroke
    100 740 moveto
    (Mail for ) show
    loginname (\(null\)) eq {(printing)} {loginname} ifelse show
    fontD
    timenow stringwidth pop neg 536 add 740 moveto timenow show
    fontN
    dup stringwidth pop 2 div neg 318 add 740 moveto show
    fontH
    newpath
    90 60 moveto
    100 40 10 180 270 arc
    536 40 10 270 0 arc
    536 60 10 0 90 arc
    100 60 10 90 180 arc
    closepath 0.75 setgray fill
    0 setgray
    100 44 moveto hostname show
    grestore
    showpage        % display it
    newpage        % reset parameters for next
} def

/newpage
{ /lct 0 def
  /ypos 700 def
  100 ypos moveto
} def

/showline { show /ypos ypos 10 sub def 100 ypos moveto } def

newpage            % establish first page parameters
********************* mpt.c *********************
/*
    mpt.c:    mail trigger program    @(#)mpt.c    1.1    2/18/87

        Add 'set EDITOR=/usr/local/bin/mpt' (or local
    equivalent: see Makefile) to .mailrc

        Use the command 'e 15' to print message 15.
    (Note: you can only 'e' one message at a time).

        This program is necessary because EDITOR cannot be
    a shellscript.  It receives a temporary filename as
    a single argument.  It gets the user's login name,
    abd then calls /usr/local/bin/mp which can be
    customised.
*/
#include <stdio.h>

extern int errno;

main(argc, argv)
 char *argv[];
 int argc;
{
    char *login, *getlogin();
        if(argc == 2) {
        login = getlogin();
                execlp("mp",
            "mp", "-s", "-u", login, argv[1], 0);
    } else {
        fprintf(stderr,"Usage: mpt filename (from mail)\n");
        exit(1);
    }
    fprintf(stderr,"mp not found\n");
        exit(1);        /* executed only if execlp fails */
}


From icon-group-request  Thu Feb 18 04:46:45 1988
Received: by bocklin.arizona.edu; Thu, 18 Feb 88 04:46:49 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 18 Feb 88 04:46:45 MST
Received: from SUN.COM by megaron.arizona.edu; Thu, 18 Feb 88 04:46:28 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-4.0)
    id AA20978; Thu, 18 Feb 88 03:45:28 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA29986; Thu, 18 Feb 88 03:45:41 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA21979; Thu, 18 Feb 88 03:36:17 PST
Received: from Nuksun.Europe.Sun.COM (inuksun) by UK.Sun.COM (3.2/SMI-3.2)
    id AA16131; Thu, 18 Feb 88 11:43:44 GMT
Received: from stevie.nuksun.uucp by Nuksun.Europe.Sun.COM (1.1/SMI-3.2)
    id AA09567; Thu, 18 Feb 88 11:43:11 GMT
Received: by stevie.nuksun.uucp (3.2/SMI-3.2)
    id AA07326; Thu, 18 Feb 88 11:43:05 GMT
Date: Thu, 18 Feb 88 11:43:05 GMT
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re:  Mail handling software
Errors-To: icon-group-request

Ahem.  Due to an oversight I omitted to include the program which
started all this off.  This is "mp", which formats mail for printing
on a PostScript printer.  The distributed program "mpt" exists to
set default values when mp is called from /usr/ucb/mail.

The program source and manual page follow.

Steve
********************* mp.icn *********************
#
#    mp.icn:    Take a mail file and format each item for laserwriter.
#
#    @(#)mp.icn    1.2    10/8/87    SMUKL
#
#    1.2 changes:
#
#    Give useline() an argument to make it easier to cope with
#    sections of text longer than one line.
#
#    Handle body lines of "form feed" correctly.
#
#    Ensure all local variables declared.
#
link mailio            # mail i/o library

global    pn,            # page number within message
    item,            # message number in mailstream
    linect,            # line count on current page
    op,            # output file
    sflag,            # non-null for single-item numbering
    nflag,            # non-null for output to stdout
    shno            # sheet number for PostScript page counts


procedure main(arg)

local    msg,            # stores mail item
    o,            # temporary fpr option strings
    hostname,        # string for bottom left corner
    username,        # string after "mail for" at top right
    infl,            # input file
    f,            # input file name
    pf            # prologue file


while arg[1][1] == "-" do            # handle each option
case (o := pop(arg))[2] of {
   "h"    : hostname := pop(arg) | stop("-h needs hostname as next argument")
   "u"    : username := pop(arg) | stop("-u needs username as next argument")
   "s"    : sflag := ""
   "n"    : nflag := ""
default    : stop("Unknown option ",o)
}

linect := shno := item := 0
/username := "printing"                # default value
/hostname := &host                # default value

if *arg > 0                    # input (use file if given)
then infl := open(f := pop(arg)) | stop("Cannot open file ",f)
else infl := &input

pf := open("/private/local/lib/mp.pro.ps") | stop("Prologue file not found")
if /nflag
then op := open("lpr","pw") | stop("Can't pipe output to lpr")
else op := &output

every write(op,!pf)
defwrite("hostname",hostname)
defwrite("loginname",username)
defwrite("timenow",&dateline)
write(op,"%%EndProlog")

while msg := readmail(infl) do {
    item +:= 1
    pn := 0
    startpage()
    Boldshow(msg.from)
    every Mixedshow(msg.header,
            !["From","To","Cc","Date","Subject"])
    write(op,"Courier")
    every Textshow(!msg.body)
    endpage()
}

write(op,"%%Trailer")
write(op,"%%Pages: ",shno)

end

procedure Boldshow(s)
useline(1)
write(op,"Bold (",expand(s),") showline")
end

procedure Mixedshow(t,k)
local    l    # bits of the line
if \t[k] then {
    write(op,"Bold (", k, ": ) show Roman")
    t[k] ? {
        while l := tab(many(~'\n')) do {
            useline(1)
            write(op,"(", expand(l), ") showline")
            move(1) | break
        }
    }
}
end

procedure Textshow(s)
if s == "\f" then
    useline(60)
else {
    useline(1)
    write(op,"(",expand(s),") showline")
}
end

procedure expand(s)
local    l            # bits between escapes
l := ""
s ? while l ||:= (tab(many(~'\\()\t')) | "") do {
    if pos(0) then break
    else case move(1) of {
        "\\":    l ||:= "\\\\"
        "(" :    l ||:= "\\("
        ")" :    l ||:= "\\)"
        "\t":    l ||:= repl(" ",8-(*l % 8))
    }
}
return l
end

procedure useline(n)
if (linect +:= n) > 60
then {
    endpage()
    startpage()
}
end


procedure startpage()
write(op,"%%Page: ? ",shno +:= 1)
end


procedure endpage(n)
local p
linect := 0
p := (/sflag & (item || "." || (pn +:= 1))) | shno
write(op,"(",p,") endpage")
end

procedure defwrite(name,def)
write(op,"/",name," (",def,") def")
end
********************* mp.1l *********************
.TH MP 1 "18 February 1987"
.\"@(#)mp.1    1.1    2/18/87
.SH NAME
mp \- mail printer
.SH SYNOPSIS
\fBmp\fP
[ \fB-u\fP \fIusername\fP ]
[ \fB-h\fP \fIhostname\fP ]
[ \fB-n\fP ]
[ \fB-s\fP ]
[ file ]
.SH DESCRIPTION
.IX  mp "" "\fLmp\fP \(em mail printing program"
.IX  mail "mp command" "" "\fLmp\fP \(em mail printing"
.IX "mail printing" "mp command" "" "\fLmp\fP \(em mail printing"
\fIMp\fP prints mail on a laserwriter.
The format adopted has shaded stripes containing banner information
at the top and bottom of every page.
It normally pipes its output straight into
\fIlpr\fP, causing direct printing of mail.
The output is page-reversed to leave the first sheet on the top
of the output stacker.
.SH OPTIONS
.TP
\fB-u\fP \fIusername\fP
The top left banner reads "Mail for \fIusername\fP", but the default
value of \fIusername\fP is "printing".
This option can be used to substitute, for example, your real name
for your username.
.TP
\fB-h\fP \fIhostname\fP
The hostname is printed left-justified in the bottom banner stripe.
You may customise it with this option.
.TP
\fB-n\fP
Do not pipe output to
\fIlpr\fP, but produce PostScript on standard output.
.TP
\fB-s\fP
Normally \fImp\fP assumes that its input contains a number of messages,
and numbers the output pages as \fIn.m\fP, where \fIn\fP is the message
number and \fIm\fP is the page number within the message.
This option is used when processing a single message, to cause simple
sequence-numbering of the output pages.
.SH FILES
.TP
/usr/local/mp.pro.ps
PostScript prologue to define required vocabulary for mail printing.
Editing this file will alow you to introduce some stylistic variation
in the printing of mail.
.TP
/usr/local/bin/iconx*
\fIMp\fP is written in Icon.  These files are the run-time package
for the Icon language.
Other mail-handling programs will also be written in Icon, so this
is an investment for the future.
.SH "SEE ALSO"
mail(1)
.SH BUGS
Needs to be installed at a fixed place in the filestore.
Does not process more than one file.
Does not handle overlength lines, truncating them silently.
Default username has an unhelpful value.


From icon-group-request  Thu Feb 18 12:15:48 1988
Received: by bocklin.arizona.edu; Thu, 18 Feb 88 12:15:53 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 18 Feb 88 12:15:48 MST
Received: from SUN.COM by megaron.arizona.edu; Thu, 18 Feb 88 12:15:36 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-4.0)
    id AA29053; Thu, 18 Feb 88 11:14:41 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA08074; Thu, 18 Feb 88 11:14:59 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA00832; Thu, 18 Feb 88 11:06:33 PST
Received: from snail.sun.com (snail-swanbb) by UK.Sun.COM (3.2/SMI-3.2)
    id AA21714; Thu, 18 Feb 88 19:14:24 GMT
Received: from Sun.COM (sun-arpa) by snail.sun.com (4.0/SMI-3.2)
    id AA00824; Thu, 18 Feb 88 11:06:23 PST
Received: from jhereg.s1.gov by Sun.COM (4.0/SMI-4.0)
    id AA29003; Thu, 18 Feb 88 11:13:49 PST
Received: by jhereg.s1.gov id AA05632; Thu, 18 Feb 88 10:30:37 PST
    id AA05632; Thu, 18 Feb 88 10:30:37 PST
Date: Thu, 18 Feb 88 10:30:37 PST
From: sunuk!sun!mordor.s1.gov![e-mail]
Message-Id: <[e-mail]>
To: nuksun!stevie![e-mail]
Cc: sun!arizona.edu![e-mail]
In-Reply-To: Steve Holden - TSE's message of Thu, 18 Feb 88 09:42:35 GMT <[e-mail]>
Subject: Mail handling software
Errors-To: icon-group-request

#! /bin/sh
# bundle:  group files into distribution package
# See Kernighan & Pike;  the Unix Programming Environment; pg 98
#
echo '# To unbundle, feed me to sh'
for i
do
    echo "echo $i 1>&2"
    echo "cat >$i <<'End of $1'"
    cat $i
    echo "End of $i"
done

From icon-group-request  Thu Feb 18 13:32:45 1988
Received: by bocklin.arizona.edu; Thu, 18 Feb 88 13:32:49 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 18 Feb 88 13:32:45 MST
Received: from XEROX.COM by megaron.arizona.edu; Thu, 18 Feb 88 13:32:37 MST
Received: from Semillon.ms by ArpaGateway.ms ; 18 FEB 88 11:45:19 PST
Date: Thu, 18 Feb 88 11:45:06 PST
From: [e-mail]
To: [e-mail]
Message-Id: <880218-112730-7432@Xerox>
Errors-To: icon-group-request

The little bundler just posted is not a good one: it will not survive many types
of mailers out there, which treat lines beginning with .'s as special.  There
are many version of the program 'makescript' floating around, which do a better
job, and also check that sizes are the same after unbundling, etc.  You can get
one by anonymous to parcvax.xerox.com, directory pub, file makescript.c.

-mark


From icon-group-request  Thu Feb 18 16:19:06 1988
Received: by bocklin.arizona.edu; Thu, 18 Feb 88 16:19:09 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 18 Feb 88 16:19:06 MST
Date: Thu, 18 Feb 88 16:19:04 MST
From: "Bill Mitchell" <whm>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Thu, 18 Feb 88 16:19:04 MST
To: icon-group
Subject: Re:  variable args
Errors-To: icon-group-request

As a similarity to the handling of x[] arguments, note that if a program is
invoked with no arguments, main is called with [] instead of &null.  As I
recall, this was changed to avoid having to special case the zero argument
situation.

From icon-group-request  Sat Feb 20 08:55:34 1988
Received: by bocklin.arizona.edu; Sat, 20 Feb 88 08:55:36 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Sat, 20 Feb 88 08:55:34 MST
Date: Sat, 20 Feb 88 08:55:32 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Sat, 20 Feb 88 08:55:32 MST
To: icon-group
Subject: Version 7 Icon available via FTP
Errors-To: icon-group-request


The UNIX and VMS Version 7 Icon systems are now available via anonymous
FTP from arizona.edu.  There also is a printable form of the report that
describes the features of Version 7 of Icon.

Do a cd to icon and get README, which is a summary of files available and
their sizes.  Note that the UNIX and VMS systems are *large*; you may or may
not find that FTP is practical.

From icon-group-request  Tue Feb 23 19:21:19 1988
Received: by bocklin.arizona.edu; Tue, 23 Feb 88 19:21:25 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 23 Feb 88 19:21:19 MST
Received: from [128.135.12.98] by megaron.arizona.edu; Tue, 23 Feb 88 19:18:16 MST
Received:  by sphinx.uchicago.edu (5.54/2.0Sx)
    id AA23234; Tue, 23 Feb 88 20:18:16 CST
Return-Path: <[e-mail]>
Received:  by sophist.uchicago.edu (3.2/UofC3.0)
    id AA14338; Tue, 23 Feb 88 20:13:09 CST
Date: Tue, 23 Feb 88 20:13:09 CST
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: cross posting
Errors-To: icon-group-request


A recent discussion of Icon on the HUMANIST - a network devoted to computing
in various aspects of the Humanities - has turned up some interesting comments,
both pro and con.  Most have been pro.  I thought it might be useful to cross
post to this group a representative letter:

Date:       23 February 1988, 19:06:00 EST
Sender:     HUMANIST Discussion <[e-mail]>
Subject:    ICON and commercial support (49 lines)

>From [e-mail] (Dominik Wujastyk)

I don't agree at all with Mark Olsen's claim that Icon is fettered by
its public domain status.  Of course it would be nice if a company took
it up and added goodies.  But I probably couldn't afford them anyway.

But look for a moment at TeX.  This is a public domain product that has
more support than any commerical product I can think of.  Have you ever
tried, for example, to get help from IBM?  Or Lotus?  Or Microsoft?
Sometimes one strikes lucky, and will get a helpful person.  But TeX
has a huge and thriving community of users, including many very talented
programmers, who provide a steady stream of excellent add-on programs and
macros.  In the first place there is TeXhax, which is a digest of
questions, answers and macros produced by Malcolm Brown, which appears
sometimes as often as thrice weekly!  Then there is TeXmag, another on line
magazine with news and more macros.  There is the USENET news area
comp.text which is full of TeXiana, and there is TUGboat, a tri-annual journal
of the highest quality, which is again full of help and interest.  The
staff of the TeX Users Group are also on hand with help and advice.  As I
say, I have not met support like this *anywhere* else, and the commercial
software I have used over the years, especially from the big companies, has
been abysmally supported.

It would be interesting to try and analyse just why it is that TeX has
attracted the support that it has.  In the first place it is a superb
program: so is Icon.  It is portable across systems and OSs: so is Icon.
It is supported by the User group, which in turn received a lot of support
from the American Mathematical Society, which uses TeX for most (perhaps
all by now) of its journals.  Ah! A difference. Icon does not lend itself
in any obvious way for large scale use in a semi commercial environment.
And I think the main reason is that it cannot produce compiled executables.
As someone else said recently here in Humanist, I think this is one of its
main drawbacks.

I make it my general policy to prefer the PD software to the commercial as
far as possible, and there are few areas where this has not led me to have
better programs and better support for them.

Dominik Wujastyk


Other comments on Icon centered on its power, ease of programming, availabil-
ity, and its modern, procedural orientation.  Cons included the apparent lack
of a facility for random disc access, and the absence of a good debugger.  In
response to this latter point, it was noted that version 7 has much improved
debugging facilities, and that Icon is so easy to program in (esp. with gar-
bage collection) that errors harder to make than with C, Pascal, etc.

People disagreed on whether Icon would make a good first programming language.
The initial poster argued "yes"; subsequent posters tended to disagree - all
except one, who was a SNO/SPITBOL programmer (does he really count).

Overall, the main concern was really the absence of the supposed advantages
of commercial support - things like a debugger and a built-in editor.  As the
letter quoted above indicates, not everyone saw these things as major concerns.
The only universal item on everyone's wish list was a compiler.

So much for what the Humanists are saying -

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer
Q.

From icon-group-request  Fri Feb 26 11:19:32 1988
Received: by bocklin.arizona.edu; Fri, 26 Feb 88 11:19:35 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 26 Feb 88 11:19:32 MST
Received: from SUN.COM by megaron.arizona.edu; Fri, 26 Feb 88 11:19:23 MST
Received: from sun.Sun.COM ([129.144.1.3]) by Sun.COM (4.0/SMI-4.0)
    id AA22565; Fri, 26 Feb 88 10:18:20 PST
Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0)
    id AA10167; Fri, 26 Feb 88 10:18:53 PST
Received: from UK.Sun.COM (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA01148; Fri, 26 Feb 88 10:19:32 PST
Received: from Nuksun.Europe.Sun.COM (inuksun) by UK.Sun.COM (3.2/SMI-3.2)
    id AA09733; Fri, 26 Feb 88 16:05:40 GMT
Received: from stevie.nuksun.uucp by Nuksun.Europe.Sun.COM (1.1/SMI-3.2)
    id AA20901; Fri, 26 Feb 88 16:05:07 GMT
Received: by stevie.nuksun.uucp (3.2/SMI-3.2)
    id AA24796; Fri, 26 Feb 88 16:05:03 GMT
Date: Fri, 26 Feb 88 16:05:03 GMT
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: SunSpots
Errors-To: icon-group-request

It has been suggested that the group might be interested in the
SunSpots mailings from Rice.  If people mail me to express their
interest I will contact the moderator to see if this would be
acceptable.  Or perhaps someone else would like to undertake
the task?

Steve

From icon-group-request  Fri Feb 26 20:34:04 1988
Received: by bocklin.arizona.edu; Fri, 26 Feb 88 20:34:08 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 26 Feb 88 20:34:04 MST
Date: Fri, 26 Feb 88 20:34:01 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Fri, 26 Feb 88 20:34:01 MST
To: icon-group
Subject: signatures
Errors-To: icon-group-request

I'd like to urge everyone to include a short signature when sending a message
to the icon-group mailing list.  It's hard in some systems to figure out who
sent a message when it's been passed through three (minimum) mailers.

Things are further complicated because we do some header rewriting before
forwarding messages to the list.  This is to spare the original sender all
the messages that bounce back due to unreachable list members.

     Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
     [phone]       [e-mail]      {allegra|noao|ihnp4}!arizona!gmt

From icon-group-request  Fri Feb 26 21:18:33 1988
Received: by bocklin.arizona.edu; Fri, 26 Feb 88 21:18:37 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 26 Feb 88 21:18:33 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Fri, 26 Feb 88 21:18:25 MST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
    id AA06565; Fri, 26 Feb 88 16:58:07 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 Feb 88 15:06:08 GMT
From: mcvax!ukc!stc!datlog!torch![e-mail]  (Paul Andrews)
Organization: TORCH Computers Ltd., Cambridge, United Kingdom
Subject: Map of Europe
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request


Looks to me like the map of Europe posted recently was automatically generated
(in 1986!) from a site list. Anybody know anything about that?

- Paul

From icon-group-request  Fri Feb 26 21:19:05 1988
Received: by bocklin.arizona.edu; Fri, 26 Feb 88 21:19:08 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Fri, 26 Feb 88 21:19:05 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Fri, 26 Feb 88 21:18:56 MST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
    id AA06587; Fri, 26 Feb 88 16:58:56 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 Feb 88 15:10:37 GMT
From: mcvax!ukc!stc!datlog!torch![e-mail]  (Paul Andrews)
Organization: TORCH Computers Ltd., Cambridge, United Kingdom
Subject: Icon?
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-request

Would someone like to give me some background on this language. I've never
heard of it before but it sounds interesting.

- Paul

From icon-group-request  Sun Feb 28 21:34:20 1988
Received: by bocklin.arizona.edu; Sun, 28 Feb 88 21:34:22 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Sun, 28 Feb 88 21:34:20 MST
Received: from [128.135.12.98] by megaron.arizona.edu; Sun, 28 Feb 88 21:33:02 MST
Received:  by sphinx.uchicago.edu (5.54/2.0Sx)
    id AA24237; Sun, 28 Feb 88 22:34:21 CST
Return-Path: <[e-mail]>
Received:  by sophist.uchicago.edu (3.2/UofC3.0)
    id AA07576; Sun, 28 Feb 88 22:28:58 CST
Date: Sun, 28 Feb 88 22:28:58 CST
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: A better way?
Errors-To: icon-group-request


I was looking at a sorry procedure in a much bigger program that I am writing.
I kept thinking, "There's gotta be a better way."  Trouble is that everything
else I tried was - if more elegant - less efficient.

Here it is.  Can anyone offhand offer me some ideas as to how I might clean
it up a bit?

procedure Bal(c1,c2,c3,s)

  # A bit like bal, but accounts for backslashed characters.
  local l1, l2
  l1 := []
  l2 := []
  s ? {
    repeat {
      &pos >= *s + 1 & fail
      if &subject[&pos] == "\\"
      then move(2) & next
      else {
        if push(l1,any(c2,move(1))) | push(l2,any(c3,move(1)))
        then next
        if (*l1 = *l2) & any(c1,move(1))
        then (suspend &pos - 1) & next
        move(1)
        }
      }
    }

end


                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-request  Mon Feb 29 11:23:34 1988
Received: by bocklin.arizona.edu; Mon, 29 Feb 88 11:23:38 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 29 Feb 88 11:23:34 MST
Date: Mon, 29 Feb 88 11:23:32 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Mon, 29 Feb 88 11:23:32 MST
To: icon-group
Subject: Re:  A better way?
Errors-To: icon-group-request

I have what I feel is a cleaner solution to Richard Goerwitz's problem.
I am not sure exactly what he wants to do with back slashes, but I believe
my version does what his does.


procedure Bal(c1,c2,c3,s)

  # A bit like bal, but accounts for backslashed characters.
  local cnt1, cnt2
  cnt1 := 0
  cnt2 := 0
  s ? {
    until pos(0) do {
      if not ="\\" then {
        if tab(any(c2)) then
           cnt1 +:= 1
        else if tab(any(c3)) then
           cnt2 +:= 1
        else  {
           if (cnt1 = cnt2) & any(c1) then
              suspend .&pos
           move(1)
           }
        }
      }
    }
  fail

end

Note that suspending from within string scanning is fine in Version 7
of Icon, but is not recomended in earlier versions. If Bal() is itself
called from within string scanning and an earlier version of Icon is
used, there will be problems with &subject and &pos. [this has been
an unpaid advertisement for V7 - keep posted for announcements of
release for your favorite system]

Does anyone else have a still better solution?

From icon-group-request  Mon Feb 29 18:25:39 1988
Received: by bocklin.arizona.edu; Mon, 29 Feb 88 18:25:42 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 29 Feb 88 18:25:39 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Mon, 29 Feb 88 18:25:37 MST
Received: by ihnp4.ATT.COM id AA15689; 29 Feb 88 08:05:46 CST (Mon)
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Mon 29 Feb 1988 08:05 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: A better way?
Ua-Message-Id: <post.nowlin.Mon 29 Feb 1988 08:01 CST>
End-Of-Protocol:
Content-Length: 209
Errors-To: icon-group-request

Whoops.  I forgot to add the backslashes to the upto cset.  Change the cset
definition line to this:

  cc := c2 ++ c3 ++ '\\'     # combine the brackets into one cset

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


From icon-group-request  Mon Feb 29 18:25:36 1988
Received: by bocklin.arizona.edu; Mon, 29 Feb 88 18:25:39 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 29 Feb 88 18:25:36 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Mon, 29 Feb 88 18:25:34 MST
Received: by ihnp4.ATT.COM id AA15360; 29 Feb 88 08:00:41 CST (Mon)
Message-Version: 2
>To: /addr=ihuxy!nowlin, /addr=ihnp4!arizona!icon-group
Date: Mon 29 Feb 1988 08:00 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Cc: ihuxy!nowlin
Subject: Re: A better way?
Ua-Message-Id: <post.nowlin.Mon 29 Feb 1988 07:14 CST>
End-Of-Protocol:
Content-Length: 2392
Errors-To: icon-group-request

> From: Richard Goerwitz <ihnp4!arizona![e-mail]>
> To: icon-group
> Subject: A better way?
>
> I was looking at a sorry procedure in a much bigger program that I am
> writing.  I kept thinking, "There's gotta be a better way."  Trouble is
> that everything else I tried was - if more elegant - less efficient.
>
> Here it is.  Can anyone offhand offer me some ideas as to how I might
> clean it up a bit?
>
> procedure Bal(c1,c2,c3,s)
>
>   # A bit like bal, but accounts for backslashed characters.
>   local l1, l2
>   l1 := []
>   l2 := []
>   s ? {
>     repeat {
>       &pos >= *s + 1 & fail
>       if &subject[&pos] == "\\"
>       then move(2) & next
>       else {
>         if push(l1,any(c2,move(1))) | push(l2,any(c3,move(1)))
>         then next
>         if (*l1 = *l2) & any(c1,move(1))
>         then (suspend &pos - 1) & next
>         move(1)
>         }
>       }
>     }
>
> end
>
> -Richard L. Goerwitz
> [e-mail]
> !ihnp4!gargoyle!sophist!goer

One suggestion.  It's a good idea to send procedures you have questions
about inside the context of a main procedure and some type of example
input and output.  That way people who don't have your mindset can try
things with the procedure and have more confidence they've figured out
what's expected.

I see a couple of obvious things that I modified.  I'm concerned that the
upto() I added doesn't distinguish characters in c1, but the move(1) it
replaced at the end of the else doesn't check for c1 either.  Is this a bug
in the existing procedure or did I fail to grasp the meaning of the whole
thing?  Here is a modified version.  Let me know how it works.

procedure Bal(c1,c2,c3,s)

  # A bit like bal, but accounts for backslashed characters.
  local l1, l2, cc
  l1 := []
  l2 := []
  cc := c2 ++ c3             # combine the brackets into one cset
  s ? {
    while not pos(0) do {    # use the pos() built-in function
      if ="\\" then          # use string scanning instead of subscripting
        move(1)              # you don't need a next with the else
      else {
        if push(l1,any(c2,move(1))) | push(l2,any(c3,move(1)))
        then next
        if (*l1 = *l2) & any(c1,move(1))
        then (suspend &pos - 1) & next
        tab(upto(cc)) | fail # avoid a bunch of moves with an upto
        }
      }
    }

end

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

From icon-group-request  Mon Feb 29 18:31:37 1988
Received: by bocklin.arizona.edu; Mon, 29 Feb 88 18:31:40 MST
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 29 Feb 88 18:31:37 MST
Date: Mon, 29 Feb 88 18:31:35 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Mon, 29 Feb 88 18:31:35 MST
To: icon-group
In-Reply-To: <[e-mail]>
Subject:  A better way?
Errors-To: icon-group-request

Ken's solution doesn't skip past the next character when it finds a
backslash, and I assume that Richard wants it to.  Here is a
stripped-down version of a solution I've used before.  Note that the
escape character '\\' should really be a parameter, rather than being
built in.  Also, the csets should all have reasonable defaults.
Adding these features back into the procedure is left as an excercise
for the reader...

# like bal, but uses \ as an escape character.
procedure Bal(c, l_brackets, r_brackets, s)
    local chars # cset of characters with special meaning
    local count    # incremented for each left-bracket and decremented for
        #   each right-bracket

    chars := c ++ l_brackets ++ r_brackets ++ '\\'
    count := 0

    s ? while tab(upto(chars)) do {
        if any(c) & count = 0 then suspend .&pos
        else if any(l_brackets) then count +:= 1
        else if any(r_brackets) then count -:= 1
        else if match("\\") then move(1)
        move(1)
        }
end

From icon-group-sender  Wed Mar  2 08:55:06 1988
Received: by bocklin.arizona.edu; Wed, 2 Mar 88 08:55:11 MST
Date: 25 Feb 88 13:31:57 GMT
From: mcvax!ukc!stc!datlog!torch![e-mail]  (Paul Andrews)
Organization: TORCH Computers Ltd., Cambridge, United Kingdom
Subject: Re: Map of Europe
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

In article <[e-mail]> [e-mail] (Paul Andrews) writes:
>
>Looks to me like the map of Europe posted recently was automatically generated


Looks to me like I posted this to the wrong place! Sorry.

- Paul

From icon-group-sender  Fri Mar  4 07:15:24 1988
Received: by bocklin.arizona.edu; Fri, 4 Mar 88 07:15:29 MST
Message-Id: <[e-mail]>
Date: Fri, 04 Mar 88 13:46:31 GMT
To: [e-mail]
From: [e-mail]
Comment: CROSSNET mail via SMTP@INTERBIT
Subject: Atari 6.5 memory problems.
Errors-To: icon-group-errors

About Icon 6.5 for the Atari ST:

The release (e) as distributed, was a little tight in heap memory
available, aborting for some programs with a message complaining
about not enough space. (e.g. #309 or #310)

The MCC library for the C compiler is weird about memory management.
To overcome this, at execution time, you can change the heap size by:
iconx %300000 program-name
Where %300000 is an example of the heap memory size you request.

By default this request is 200000, enough to run all the Icon test suite
programs, but not enough for some other.
On a 1040ST, without shell, you can try up to aroud %700000.
This MCC "feature" *cant* be used from Icont, with the -x option.
(The % arg is not passed to iconx, but used by icont, that does not
need it.)

A modified version (f) with a default of 260000 is released,
and sent to:

userczak@ualtamts (bitnet)
listserv@canada01 (the useful prog-a16 server, on bitnet)
hahn_k@dmrhrz11 (earn, europe)
ihnp4!uwmcsd1!lakesys6martin (uucp-us)
ihnp4!ihlpe!orf (uucp-us)
ukc!uk!ac!qmc!maths!gcj (uucp-europe)

Please do all request from your closest site.
(I am myself in France, and cant handle large amount of orders.)

Regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
[e-mail] (arpanet)
[e-mail] (arpanet)

From icon-group-sender  Fri Mar  4 07:15:44 1988
Received: by bocklin.arizona.edu; Fri, 4 Mar 88 07:15:48 MST
Message-Id: <[e-mail]>
Date: Fri, 04 Mar 88 13:59:38 GMT
To: [e-mail]
From: [e-mail]
Comment: CROSSNET mail via SMTP@INTERBIT
Subject: Atari Icon 6.5 Memory problems.
Errors-To: icon-group-errors

About Icon 6.5 for the Atari ST:

The release (e) as distributed, was a little tight in heap memory
available, aborting for some programs with a message complaining
about not enough space. (e.g. #309 or #310)

The MCC library for the C compiler is weird about memory management.
To overcome this, at execution time, you can change the heap size by:
iconx %300000 program-name
Where %300000 is an example of the heap memory size you request.

By default this request is 200000, enough to run all the Icon test suite
programs, but not enough for some other.
On a 1040ST, without shell, you can try up to aroud %700000.
This MCC "feature" *cant* be used from Icont, with the -x option.
(The % arg is not passed to iconx, but used by icont, that does not
need it.)

A modified version (f) with a default of 260000 is released,
and sent to:

userczak@ualtamts (bitnet)
listserv@canada01 (the useful prog-a16 server, on bitnet)
hahn_k@dmrhrz11 (earn, europe)
ihnp4!uwmcsd1!lakesys6martin (uucp-us)
ihnp4!ihlpe!orf (uucp-us)
ukc!uk!ac!qmc!maths!gcj (uucp-europe)

Please do all request from your closest site.
(I am myself in France, and cant handle large amount of orders.)

Regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
[e-mail] (arpanet)
[e-mail] (arpanet)

From icon-group-sender  Tue Mar  8 06:45:42 1988
Received: by bocklin.arizona.edu; Tue, 8 Mar 88 06:45:45 MST
Date: Tue, 8 Mar 88 13:43:41 GMT
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Matching a list of criteria
Errors-To: icon-group-errors

I'm probably not thinking straight, but I'd appreciate it if anyone
could help me.  I'm trying to write a program to scan mail and select
those message which match certain criteria.  For example, it should be
possible to issue the command

    mailget < mailfile From: ...sun!selling > /tmp/out

to extract into /tmp/out those messages which came from any UUCP address
which ends in "sun!selling".  However I now wish to extend the selection
features.

I started out just by allowing a single criterion (as in the example above).
The updated version builds a _list_ of criteria, and I want to modify the
selection routine [selected() in the listing below] so it only returns true
if all criteria match.

Anyone think of a smart way to do it?  Sorry about the length of the program
- I never did learn to stop writing comments like the "C" hackers :-)

Naturally, other suggestions for improvement will also be welcomed.

Thanks in advance

Steve Holden
[e-mail]
sholden@{sun,sunuk}.uucp
"On the whole, I'd rather be in Philadelphia"  --  W.C. Fields


#
#    mailget.icn:    Gets selected items of mail by header keyword.
#
#       %W%     %G%
#
link    mailio            # mail i/o package

record    criterion(key,condition)

procedure main(argv)

local    msg, c

c := []                # nullify criterion list
#
#    Scan argument list.  Expected arguments are in pairs:
#    the first specifies a header keyword such as "From:",
#    and should be terminated with a colon.  The second
#    specifies a matching criterion.  This is a literal
#    string which may be preceded or followed by "..." to
#    indicate that an arbitrary string may precede or follow
#    the specified literal.
#
while argv[1][-1] == ":" do {
    keyval := pop(argv)[1:-1]    # everything but the colon
    value := pop(argv) | stop(keyval,": no value argument")
    put(c,criterion(keyval,patternfor(keyval,value)))
}

while (msg := readmail()) do {
    if selected(msg,c)
    then writemail(msg)
}

end

procedure selected(m,c)
#
#    The message, m, is tested against the criteria, c,
#    which is a list of conditions which must all be
#    true for the mail to be written.  Each condition
#    is represented by a record.  The first field is the
#    entry value in the header table, the second field
#    is an expression which must match against the
#    corresponding header table assigned value.
#
#    Test version just tests the first criterion in the list
#
local pattern

pattern := ^c[1].condition
if \m.header[c[1].key] ? @pattern
then return
end

procedure patternfor(k,v)
#
#    Returns a value to be used in matching the given
#    header table entry against the value string v.
#
#    Test version just returns a co-expression with an
#    infinite sequence of "Match the string literally".
#
if v[1:4] == "..." then {        # if start can be anything
    v[1:4] := ""                # remove flag
    if v[-3:0] == "..." then {        # if end can be anything
        v[-3:0] := ""                # remove flag
        return create |(arbpat() || =v)        # and just match
    } else {                # if definite end required
        return create |(arbpat() || =v ||
                endpat())        # force end of word
    }
} else {                # if definite start required
    if v[-3:0] == "..." then {        # if end can be anything
        v[-3:0] := ""                # remove flag
        return create |=v            # and just match
    } else {
        return create |(=v || endpat())    # else match whole word
    }
}
end

procedure arbpat()
every suspend &subject[.&pos:&pos <- &pos to *&subject]
end

procedure endpat()
suspend (any(' \t\n') | pos(0))
end

From icon-group-sender  Tue Mar  8 12:39:41 1988
Received: by bocklin.arizona.edu; Tue, 8 Mar 88 12:39:44 MST
Date: Tue, 8 Mar 88 12:39:39 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
To: icon-group
Subject: Version 7 Icon for MS-DOS
Errors-To: icon-group-errors

Version 7 Icon for MS-DOS (large-memory model) is now available.
It should run on any computer with MS-DOS 2.0 or higher and 512KB
of RAM.

Executable binaries come on two 2S/DD 5.25" diskettes.  The price is
$20, including printed documentation and shipping.  Add $5 for overseas
airmail.

Source code comes on two 2S/DD 5.25" diskettes also.  The price is
$25, also including printed documentation and shipping.  Add $5 for
overseas airmail ($10 for both binaries and source code).

Make checks payable to The University of Arizona and address requests
to

    The Icon Project
    Department of Computer Science
    Gould-Simpson Building
    The University of Arizona
    Tucson, AZ   85721
    USA

Both source and binaries also are available via FTP and our BBS as
described earlier.

Please address any questions to me, not icon-group.


Ralph Griswold / Dept. of Computer Science / Univ of Arizona / Tucson, AZ 85721
  [phone]   [e-mail]     {allegra|noao|ihnp4}!arizona!ralph


From icon-group-sender  Tue Mar  8 17:24:39 1988
Received: by bocklin.arizona.edu; Tue, 8 Mar 88 17:24:42 MST
Date: Tue, 8 Mar 88 11:34:36 MST
From: "Kenneth Walker" <sunuk!sun!arizona.edu![e-mail]>
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
To: nuksun!stevie![e-mail],
        sun!arizona.edu![e-mail]
Subject: Re:  Matching a list of criteria
Errors-To: icon-group-errors

>Date: Tue, 8 Mar 88 13:43:41 GMT
>From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
>
>   [text deleted]
>I'm trying to write a program to scan mail and select
>those message which match certain criteria.
>   [example deleted]
>I started out just by allowing a single criterion (as in the example above).
>The updated version builds a _list_ of criteria, and I want to modify the
>selection routine [selected() in the listing below] so it only returns true
>if all criteria match.
>
>Anyone think of a smart way to do it?
>   [code for existing program deleted]

How about a recursive procedure to process the list:

procedure selected_by_all(str, lst)
   if *lst = 0 then
      return    # we got through all of the selection criteria
   else
      if selected(str, get(lst)) then
         return selected_by_all(str, lst)  # see if the rest succeed
      else
         fail
end

I just wrote this off the top of my head, so you should think through it
to see if it is the sort of thing you want to do (and you should check
my Icon). This type of list processing is quite common in Prolog and Lisp
(they may not be as nice as Icon, but they encourage you to think in
different ways, which is always good).

You could make selected() a polymorphic procedure, which incorporates
the code for both your selected and my selected_by_all(), basing the
choice of code on whether the second argument is a list or not. Keeping
them separate might be clearer, though.

Can someone come up with an iterative solution?

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

From icon-group-sender  Wed Mar  9 04:08:44 1988
Received: by bocklin.arizona.edu; Wed, 9 Mar 88 04:08:50 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Tue 08 Mar 1988 20:09 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: Matching a list of criteria
Ua-Message-Id: <post.nowlin.Tue 08 Mar 1988 20:09 CST>
End-Of-Protocol:
Content-Length: 1765
Errors-To: icon-group-errors

> From: "Kenneth Walker" <ihnp4!arizona!sunuk!sun!arizona.edu![e-mail]>
>
> >Date: Tue, 8 Mar 88 13:43:41 GMT
> >From: sunuk!nuksun!stevie![e-mail] (Steve Holden - TSE)
> >
> >   [text deleted]
> >I'm trying to write a program to scan mail and select
> >those message which match certain criteria.
> >   [example deleted]
> >I started out just by allowing a single criterion (as in the example above).
> >The updated version builds a _list_ of criteria, and I want to modify the
> >selection routine [selected() in the listing below] so it only returns true
> >if all criteria match.
> >
> >Anyone think of a smart way to do it?
> >   [code for existing program deleted]
>
> How about a recursive procedure to process the list:
>
> procedure selected_by_all(str, lst)
>    if *lst = 0 then
>       return    # we got through all of the selection criteria
>    else
>       if selected(str, get(lst)) then
>          return selected_by_all(str, lst)  # see if the rest succeed
>       else
>          fail
> end
>
> .
> .
> .
>
> Can someone come up with an iterative solution?
>
>  Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
>  [phone]  [e-mail]   {allegra|noao|ihnp4}!arizona!kwalker

If you go back to the original code that was posted, the iterative solution
is fairly straightforward:

    procedure selected(m,c)

        local pattern

        every l := !c do {
            pattern := ^l.condition
            if not (\m.header[l.key] ? @pattern)
            then fail
        }

        return
    end

This is probably faster and takes less resources than the recursive
solution.  Sorry, I know Icon programmers aren't supposed to worry about
things like that.  When you run it on a PC you soon learn though.

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

From icon-group-sender  Wed Mar  9 11:09:15 1988
Received: by bocklin.arizona.edu; Wed, 9 Mar 88 11:09:18 MST
Date: Tue, 8 Mar 88 18:01:37 pst
From: [e-mail] (Carole McNamee)
Message-Id: <8803090201.AA16699@iris>
To: [e-mail]
Subject: ICON library routines?
Errors-To: icon-group-errors


    I'm not sure if this is where this request should be directed.  If not
perhaps you could tell me where to direct it.
    I would like to know if there are any available icon library routines
which will do universal writes, copies and equals.  Thank you for looking
into this.

C. M. McNamee


From icon-group-sender  Thu Mar 10 11:06:18 1988
Received: by bocklin.arizona.edu; Thu, 10 Mar 88 11:06:21 MST
Date: Thu, 10 Mar 88 11:06:12 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
To: icon-group
Subject: tables, mappings, and unified field theory
Errors-To: icon-group-errors

I think we should consider a generalized many-to-many datatype.  For
discussion I'll call it a "map", ignoring collisions with current Icon
usage for the moment.

I like Kelvin's idea of making the lookup function be a generator.

A table would be a special case of a map with a one-to-one mapping.
A set would be a special case with a many-to-one mapping.

A map would have all the facilities that sets and tables now have,
and more.  Inversion of a map would be legal;  inversion of a table
would produce a map, possibly no longer in table (one-to-one) form.
Union of two tables would produce a map, again only possibly in table
form.

Obviously more work would be needed to hash out the details, and from
a practical matter the separate datatypes of sets and tables might need
to remain in Icon.

From icon-group-sender  Thu Mar 10 15:42:50 1988
Received: by bocklin.arizona.edu; Thu, 10 Mar 88 15:42:54 MST
Date: Thu, 10 Mar 88 14:05:19 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8803102105.AA01429@naucse>
To: arizona!icon-group
Subject: IconTest Problem Two Results
Errors-To: icon-group-errors


First, a couple of apologies, one for being so long in providing
results, and the other for the fact that the wording on the problem
did not include a key phrase that makes the problem much simpler.

(The problem was to write a scheduler for maximizing diversity among
partners in a doubles tennis tournament.)  The key phrase was that
the tennis group did not play unless *all* players get to play in
each round (i.e. number_of_players = 4*number_of_courts).  Omitting
this phrase means that any optimal solution must backtrack through
previously scheduled rounds.  My thanks to Gregg Townsend for pointing
this out.

The best non-Icon Project solution was by Paul Abrahams, and is reproduced
below.  It produces optimal scheduling for cases where the above
criteria is met, and does fairly well at the more general case.
It was also the fastest (in Icon there's a 'fastest'?) for small
numbers of players and courts.  Following Paul's solution is one
submitted anonymously from within Icon Project.  It is also optimal
for the simple case, and slightly better than Paul's at handling
the more general case, but still does not always find the optimal
solutions for the general case.  It is also slower for small input
values.

New users to Icon might look at the use of sets in both solutions
(which is why tennis was the chosen game).

----  Winning Solution by Paul Abrahams -----
----  (modified slightly to conform to pre-V7 versions of Icon) ----
# Program to assign players to tennis courts
# Written by Paul Abrahams     February 1988

# The assignment strategy backs up over courts and over players, but not over
# rounds of play.

global courts, players
global seen                         # list of sets, one per player
                    # seen[p] is players seen by p, including
                    # p himself

procedure main(args)
    local round                     # round of play
    local p

    courts := args[1]
    players := args[2]
    (integer(players) & 1 <= players < 1000 & integer(courts) &
    1 <= courts) | {write("Invalid input!"); stop()}
    if players < courts * 4 then
    {write("Not enough players to fill the courts!"); stop()}
    round := 0
    seen := list(players)
    every seen[p := 1 to players] := set([p])
    while print(assignment(), round +:= 1)
end

procedure assignment()
# "assignment" returns a list of foursomes for the courts.
# Each foursome is an ordered list of four players.
# Available players are kept in a list (not a set), so that after each
# round of play, the players who were in that round are considered after
# those who were not in that round.
    static avail                    # players available for assignment
    local assigns                   # list of court assignments
    local foursome                  # set of players on current court
    local assigned                  # set of players assigned in this round
    local a, p
    local list1                     # list of sets of four players
    initial {
    avail := []
    every put(avail, 1 to players)
    }

    assigns := []
    assigned := set([])
    (list1 := fill_courts(avail, courts)) | fail
    every a := !list1 do {
    put(assigns, sort(a))
    assigned ++:= a
    }
    avail := remset(avail, assigned) ||| sort(assigned)
    return assigns
end

procedure fill_courts(avail, n)
# Attempt to fill n courts with the players in the avail list.
# The returned value is a list of sets.  Each set consists of the four
# players on a court.
    local foursome, seen1, rest

    if n = 0 then
    return []
    seen1 := copy(seen)
    every foursome := get_players(avail, 4) do {
    every seen[!foursome] ++:= foursome
                    # p has seen all players in the foursome
    if rest := fill_courts(remset(avail, foursome), n - 1) then
        return push(rest, foursome)
    seen := seen1               # undo changes to "seen"
    }
    fail
end

procedure get_players(avail, n)
# Choose n players from the avail list who haven't previously seen each other
    local avail1                    # set of remaining available players
    local p
    if n = 0 then
    return set([])
    n -:= 1
    every p := !avail do {
    if *(avail1 := remset(avail, seen[p])) < n then
        next
    suspend get_players(avail1, n) ++ set([p])
    }
    fail
end

procedure remset(l, s)
# remset(l, s) removes the set s from the list l
    local e, retval
    retval := []
    every e := !l do
    if not member(s, e) then
        put(retval, e)
    return retval
end

procedure print(asst, r)
# Print the court assignments in up to three columns.
    local rows                      # number of rows in display
    local c, i, j
    rows := 3 >= courts | (5 >= courts, courts / 2) | (courts + 2) / 3
    write(center(" Round " || r || " ", 78, "-"))
    every i := 1 to rows do {
    every j := 0 to 2 do {
        c := i + j * rows
        if c > courts then
        break
        writes(left("Court " || c || ":", 9))
        every writes(right(!asst[c], 4))
        writes(j < 2 & "|")
        }
    write()
    }
    write()
    return
end

---- Alternate Solution (anonymous) -----

## Scheduling tennis players with no person re-encountering another
#
procedure main(args)
   local ncourts, nplayers
   local allplayers, previous, avail, partners
   local p1, p2, p3

   ncourts  := integer(args[1]) | 8
   nplayers := integer(args[2]) | 32

   every insert(allplayers:= set([]), 1 to nplayers)
   every put(previous := list(), set([1 to nplayers]))

   every write("\nRound ",seq(),":") do {

      avail := copy(allplayers)    # everyone's available at day start

      every writes("\tCourt ",1 to ncourts," has ") do {

         if partners := set([
              p1 := !avail,
              p2 := !(avail -- previous[p1]),
              p3 := !(avail -- (previous[p1]++previous[p2])),
              !(avail -- (previous[p1]++previous[p2]++previous[p3]))
              ])
           then {
              every writes(right(!partners,4))
              write()
              every previous[!partners] ++:= partners
              avail --:= partners
              }
           else
              stop(" no way to schedule!")

        }

      }

end

From icon-group-sender  Thu Mar 10 17:47:51 1988
Received: by bocklin.arizona.edu; Thu, 10 Mar 88 17:47:54 MST
Date: Thu, 10 Mar 88 17:47:47 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
To: icon-group
Subject: Tennis Scheduling Problem
Errors-To: icon-group-errors

The two contest solutions just posted do not produce optimal solutions.
For 20 players on five courts, each program quits after just one round.
Working by hand I can fill five full rounds (below), and almost a sixth
round.  (It's easily shown that six rounds is an upper bound, and I
conjecture that six full rounds are indeed possible.)

round 1:   1  2  3  4    5  6  7  8    9 10 11 12   13 14 15 16   17 18 19 20

round 2:   1  6 11 16    5 10 15 20    9 14 19  4   13 18  3  8   17  2  7 12

round 3:   4  7 10 13    8 11 14 17   12 15 18  1   16 19  2  5   20  3  6  9

round 4:   2  8  9 15    6 12 13 19   10 16  3 17   14 20  1  7   18  4  5 11

round 5:  13  2 11 20   17  6 15  4    1 10 19  8    5 14  3 12    9 18  7 16

round 6:   1  5  9 13    2  6 10 14    3  7 11 15    4  8 12 16

     Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
     [phone]       [e-mail]      {allegra|noao|ihnp4}!arizona!gmt

From icon-group-sender  Fri Mar 11 02:06:32 1988
Received: by bocklin.arizona.edu; Fri, 11 Mar 88 02:06:35 MST
Date: Thu, 10 Mar 88 23:10:04 EST
From: [e-mail]
To: [e-mail]
Message-Id: <38347@Wayne-MTS>
Subject: The Tennis Problem reconsidered
Errors-To: icon-group-errors

I'm not at all surprised that neither my solution nor the other (anonymous)
one to the tennis problem doesn't do well on certain particular cases.  An
exhaustive solution must back up not only within a round but also over the
rounds themselves (so that if it fails to produce an expected number of
rounds, it rearranges earlier rounds).  Clearly the search grows beyond any
reasonable bound, even for relatively small n.

The other method of solution that I played with (unsuccessfully) is to try to
find some pattern to the successful solutions and generate them explicitly.  I
never found a way to do that.  Nor, apparently, did anyone else (though it
might be a little easier given the constraint that was missing).  In fact,
with that constraint there is no reason to give the number of players in the
input, since it is implied by the number of courts.

Paul Abrahams

From icon-group-sender  Fri Mar 11 06:33:51 1988
Received: by bocklin.arizona.edu; Fri, 11 Mar 88 06:33:53 MST
Date: Fri, 11 Mar 88 05:54:04 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8803111254.AA03751@naucse>
To: arizona!gmt, arizona!icon-group
Subject: Re:  Tennis Scheduling Problem
Errors-To: icon-group-errors

sigh.  i should have had you check them out.  i'll post a correction.

thanks.

From icon-group-sender  Fri Mar 11 12:12:42 1988
Received: by bocklin.arizona.edu; Fri, 11 Mar 88 12:12:45 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Fri 11 Mar 1988 07:05 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: unified field theory
Ua-Message-Id: <post.nowlin.Fri 11 Mar 1988 06:45 CST>
End-Of-Protocol:
Content-Length: 1482
Errors-To: icon-group-errors

> From: "Gregg Townsend" <ihnp4!arizona!gmt>
>
> I think we should consider a generalized many-to-many datatype.  For
> discussion I'll call it a "map", ignoring collisions with current Icon
> usage for the moment.
>
> I like Kelvin's idea of making the lookup function be a generator.
>
> A table would be a special case of a map with a one-to-one mapping.
> A set would be a special case with a many-to-one mapping.
>
> A map would have all the facilities that sets and tables now have,
> and more.  Inversion of a map would be legal;  inversion of a table
> would produce a map, possibly no longer in table (one-to-one) form.
> Union of two tables would produce a map, again only possibly in table
> form.
>
> Obviously more work would be needed to hash out the details, and from
> a practical matter the separate datatypes of sets and tables might need
> to remain in Icon.

First of all, the explanation above wasn't clear enough for me to figure
out what you really mean by "many-to-many datatype."  I hate to sound
ignorant but what would you use something like this for?  Maybe some
examples of algorithms that this new type would make easier to implement
would help to explain it.  I can't think of any functionality this type
would give me (remember I don't quite grasp what you were talking about)
that I don't already have with the data types and the incredible amount of
flexibility that already exists in Icon?  Elucidate.

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

From icon-group-sender  Sun Mar 13 23:45:40 1988
Received: by bocklin.arizona.edu; Sun, 13 Mar 88 23:45:43 MST
Date: 5 Mar 88 16:22:17 GMT
From: lakesys![e-mail]  (Martin Wiedmeyer)
Organization: Lake Systems - Milwaukee, WI
Subject: Re: Atari 6.5 memory problems.
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

In article <[e-mail]> [e-mail] writes:
>About Icon 6.5 for the Atari ST:
>
[info deleted]
>A modified version (f) with a default of 260000 is released,
>and sent to:
>
[addresses deleted]
>ihnp4!uwmcsd1!lakesys6martin (uucp-us)
There is a typo in my path, it is

ihnp4!uwmcsd1!lakesys!martin (uucp-us)

>Please do all request from your closest site.
>(I am myself in France, and cant handle large amount of orders.)

Thank you Jean-Pierre, for the ST implementation of Icon!

Marty Wiedmeyer
--
|    Marty Wiedmeyer                                           |
|       Lake Systems, Milwaukee, WI                                        |
|       UUCP: {ihnp4,uwvax}!uwmcsd1!lakesys!martin                         |
|    Disclaimer: I take the heat for my own (mis)statements.....        |

From icon-group-sender  Wed Mar 16 22:14:06 1988
Received: by bocklin.arizona.edu; Wed, 16 Mar 88 22:14:09 MST
Date: 15 Mar 88 23:10:43 GMT
From: amsterdam![e-mail]  (Alexander Dupuy)
Organization: Columbia University Computer Science Dept.
Subject: Re: tables, mappings, and unified field theory
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

For an idea of how another language used mappings, you might want to look at
SETL, a language used extensively within Courant (NYU), although it was not
widely used elsewhere.

In SETL, mappings were sets of two element tuples, and the lookup function
would return the set of matching second elements.  Given a mapping such as

    map := { [ 1, 2 ], [ 1, 3 ], [ 2, 3 ] };

( '{}' are set braces, '[]' are tuple (vector) braces)

the expression "map[1]" would return "{ 2, 3 }" and map[2] would return "{ 3 }"
(or perhaps "3"? - SETL was a fairly typeless language, and the distinction was
minor).

SETL also had generators (of a different sort than Icon) which could be used to
generate sets or tuples.  For example, "x := { d | 3 .elt map[d] }" (read as
"x gets set of d such that 3 is an element of map[d]") would return all the
domain elements which mapped to 3.  It was even possible to write a one-line
bubblesort expression which would return a sorted tuple (I can't remember it
offhand; it was 7 years ago that I used SETL).

Mappings were used extensively in SETL - it didn't have any pointer type, so
most complex data structures ended up as mappings of one sort or another.

@alex

inet: [e-mail]
uucp: ...!rutgers!columbia!dupuy

From icon-group-sender  Sun Mar 20 13:11:35 1988
Received: by bocklin.arizona.edu; Sun, 20 Mar 88 13:11:38 MST
Date: Sun, 20 Mar 88 13:11:33 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
To: icon-group
Subject: Re: unified field theory
Errors-To: icon-group-errors

    From Jerry Nowlin (ihnp4!ihuxy!nowlin Fri Mar 11 12:12:58 1988)

    [re my comments about a "many-to-many" datatype]

    First of all, the explanation above wasn't clear enough for me to figure
    out what you really mean by "many-to-many datatype."  I hate to sound
    ignorant but what would you use something like this for?  Maybe some
    examples of algorithms that this new type would make easier to implement
    would help to explain it.  I can't think of any functionality this type
    would give me (remember I don't quite grasp what you were talking about)
    that I don't already have with the data types and the incredible amount of
    flexibility that already exists in Icon?  Elucidate.

I'll be the first to admit that I don't have a precise idea of what this
would be or exactly how it would be used;  it's a research idea (and not
original with me).  I'm envisioning a general datatype that would encompass
tables, sets, and more.  From the brief description posted by dupuy@columbia,
it does sound a lot like SETL mappings.

Let me try to construct an example.  Suppose you need a database of names
and phone numbers.  The obvious thing in Icon is a table;  index it by
name and you get back a telephone number.

What if somebody has two telephones?  Well, you could make every table
entry a list to handle cases like this, but my idea is that an Icon
mapping would provide this automatically, and if you said
    every write (phones["Fred"])
you'd get both of them.

Another thing you can't do with tables is invert them;  that is, create
a table of names indexed by phone numbers.  Mappings would be invertible.

Inversions would be useful anyway, but shouldn't be needed to look
something up.  Given the mapping above it should be easy to generate
the people who share a given phone number, though an obvious notation
doesn't come readily to my mind.

Perhaps this helps explain what I had in mind.  Let's hear some other ideas!

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

From icon-group-sender  Thu Mar 24 01:49:21 1988
Received: by bocklin.arizona.edu; Thu, 24 Mar 88 01:49:25 MST
To: [e-mail]
Subject: string scanning
Reply-To: [e-mail]
Message-Id: <[e-mail]>
Date: 23 Mar 88 22:24:07 EST (Wed)
From: [e-mail] (K. Richard Magill)
Errors-To: icon-group-errors

Can someone send me a four line?  I want to read four (well, N) fields
from a line separated by spaces into variables a, b, c, d.

Actually, I think I understand how to do it but suspect a bug in the
3b1 implementation.  If your working four line doesn't work here I
know to go chasing source.

From icon-group-sender  Thu Mar 24 07:51:55 1988
Received: by bocklin.arizona.edu; Thu, 24 Mar 88 07:51:57 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Thu 24 Mar 1988 05:34 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: string scanning
Ua-Message-Id: <post.nowlin.Thu 24 Mar 1988 05:25 CST>
End-Of-Protocol:
Content-Length: 1119
Errors-To: icon-group-errors

> From: ihnp4!arizona![e-mail] (K. Richard Magill)
>
> Can someone send me a four line?  I want to read four (well, N) fields
> from a line separated by spaces into variables a, b, c, d.
>
> Actually, I think I understand how to do it but suspect a bug in the
> 3b1 implementation.  If your working four line doesn't work here I
> know to go chasing source.

Try this program.  It reads from standard in and parses each line of input
into a list of words.  For the sake of illustration you can run it with
trace turned on.  This program works fine on the machines I have access to
and should work on your 3B1.

procedure main()

    while line := read() do {
        words := parse(line)
        every writes(!words," ")
        write()
    }

end

procedure parse(t)

    static    WS
    initial    WS := ' \t'

    w := []

    trim(t,WS) ? until pos(0) do {
        tab(many(WS))
        put(w,tab(upto(WS) | 0))
    }

    return w

end

If you'd used some kind of return address I could decipher I'd have replied
to you directly.  I only have access to usenet.  Sorry for having to use
the group address.

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

From icon-group-sender  Thu Mar 24 07:51:59 1988
Received: by bocklin.arizona.edu; Thu, 24 Mar 88 07:52:02 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Thu 24 Mar 1988 05:34 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: string scanning
Ua-Message-Id: <post.nowlin.Thu 24 Mar 1988 05:25 CST>
End-Of-Protocol:
Content-Length: 1119
Errors-To: icon-group-errors

> From: ihnp4!arizona![e-mail] (K. Richard Magill)
>
> Can someone send me a four line?  I want to read four (well, N) fields
> from a line separated by spaces into variables a, b, c, d.
>
> Actually, I think I understand how to do it but suspect a bug in the
> 3b1 implementation.  If your working four line doesn't work here I
> know to go chasing source.

Try this program.  It reads from standard in and parses each line of input
into a list of words.  For the sake of illustration you can run it with
trace turned on.  This program works fine on the machines I have access to
and should work on your 3B1.

procedure main()

    while line := read() do {
        words := parse(line)
        every writes(!words," ")
        write()
    }

end

procedure parse(t)

    static    WS
    initial    WS := ' \t'

    w := []

    trim(t,WS) ? until pos(0) do {
        tab(many(WS))
        put(w,tab(upto(WS) | 0))
    }

    return w

end

If you'd used some kind of return address I could decipher I'd have replied
to you directly.  I only have access to usenet.  Sorry for having to use
the group address.

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

From icon-group-sender  Thu Mar 24 09:33:59 1988
Received: by bocklin.arizona.edu; Thu, 24 Mar 88 09:34:03 MST
Date: Thu, 24 Mar 88 09:28:17 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8803241628.AA28100@naucse>
To: arizona!icon-group
Subject: Re: string scanning
Errors-To: icon-group-errors


>From: arizona!ihnp4!ihuxy!nowlin
>> From: ihnp4!arizona![e-mail] (K. Richard Magill)
>>
>> Can someone send me a four line?  I want to read four (well, N) fields
>> from a line separated by spaces into variables a, b, c, d.
>>
>> Actually, I think I understand how to do it but suspect a bug in the
>> 3b1 implementation.  If your working four line doesn't work here I
>> know to go chasing source.

>Try this program.  It reads from standard in and parses each line of input
>
>procedure main()
>
>    while line := read() do {
>        words := parse(line)
>        every writes(!words," ")
>        write()
>    }
>
>end
>
>procedure parse(t)
>
>    static    WS
>    initial    WS := ' \t'
>
>    w := []
>
>    trim(t,WS) ? until pos(0) do {
>        tab(many(WS))
>        put(w,tab(upto(WS) | 0))
>    }
>
>    return w
>
>end

Here's another approach, though it may not work under all versions
of Icon.  I suspect that it does, though (the 'dangerous' part is
the suspend/fail out a a string scanning).  I think v7 handles this
properly.

    .
    .
    nextfld := create genflds(line,separators)
    every a|b|c|d := @nextfld
    .
    .
    procedure genflds(s,sep)
       s ? repeat {
                  suspend tab(upto(sep)|0)\1
              move(1) | fail
                  }
        end

I also think the code in genflds() can be cleaned up, I did this in
a hurry.

From icon-group-sender  Thu Mar 24 09:55:46 1988
Received: by bocklin.arizona.edu; Thu, 24 Mar 88 09:55:49 MST
Date: Thu, 24 Mar 88 09:55:44 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
In-Reply-To: <8803241628.AA28100@naucse>
To: icon-group
Subject: Re: string scanning
Errors-To: icon-group-errors

> Date: Thu, 24 Mar 88 09:28:17 mst
> From: naucse!sbw (Steve Wampler)
>
> Here's another approach, though it may not work under all versions
> of Icon.  I suspect that it does, though (the 'dangerous' part is
> the suspend/fail out a a string scanning).  I think v7 handles this
> properly.

Yes, v7 does indeed "correctly" handle suspend/fail (and return, break, and
next) out of string scanning. You can "get away with it" in earlier versions
if you don't used nested scanning, but it is considered a 'dangerous'
practice.

From icon-group-sender  Thu Mar 24 11:35:29 1988
Received: by bocklin.arizona.edu; Thu, 24 Mar 88 11:35:32 MST
Date: Thu, 24 Mar 88 10:48:52 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8803241748.AA28592@naucse>
To: arizona!icon-group
Subject: Re: string scanning
Errors-To: icon-group-errors


oops, on returning from class, I see that the problem assumed fields
separated by 1 or more spaces (separators).  The version of genflds()
I mailed out assumes two adjacent separators separate an empty field.

Change the line:

        move(1) | fail

into

        tab(many(sep)) | fail

From icon-group-sender  Thu Mar 24 13:47:01 1988
Received: by bocklin.arizona.edu; Thu, 24 Mar 88 13:47:05 MST
Date: Wed, 23 Mar 88 20:30:14 EST
From: [e-mail] (Leonard H. Tower Jr.)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail],
        mailrus!umix!oxtrap!sendai![e-mail]
Subject: [[e-mail]: icon mode]
Reply-To: mailrus!umix!oxtrap!sendai![e-mail]
Errors-To: icon-group-errors

Path: mit-eddie!bloom-beacon!tut.cis.ohio-state.edu!mailrus!umix!oxtrap!sendai!rich
From: [e-mail] (K. Richard Magill)
Newsgroups: comp.emacs
Subject: icon mode
Date: 22 Mar 88 11:42:59 GMT
Reply-To: [e-mail]
Organization: Digital Works Ltd, Ann Arbor
Apparently-To: [e-mail]

Anyone have an icon mode like for griswold's icon? (the programming
language)?


From icon-group-sender  Thu Mar 24 20:30:06 1988
Received: by bocklin.arizona.edu; Thu, 24 Mar 88 20:30:13 MST
Return-Path: <[e-mail]>
Date: Thu, 24 Mar 88 20:51:47 CST
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: coexpressions - help!
Errors-To: icon-group-errors


I can't tell why the following program works (i.e. outputs "678"):

procedure main()
  C := create GetVal()
  every a|b|c := @C
  write(a,b,c)
end

procedure GetVal()
  every suspend "6"|"7"|"8"
end

Why doesn't this work like:

procedure main()
  every a|b|c := "6"|"7"|"8"
  write(a,b,c)
end

I.e. why doesn't it output "888" (seeing as each variable eventually gets
assigned the value "8")?  In the second program, it seems clear that each
resumption merely assigns successive strings to the same variable.  In
the first, resumption of @C apparently fails to produce another result.  I
would have thought that this would have reactiveated C.  Apparently, though,
the result sequence of @C has a length of one.  Correct?  How come?

It seems that I am missing something very important about coexpressions and
coexpression activations, and how they are treated when resumed.  If some kind
soul could straighten me out, I would be most grateful.

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Fri Mar 25 02:15:16 1988
Received: by bocklin.arizona.edu; Fri, 25 Mar 88 02:15:19 MST
Date: Thu, 24 Mar 88 23:35:42 EST
From: [e-mail]
To: [e-mail]
Message-Id: <42248@Wayne-MTS>
Subject: Splitting a line into tokens
Errors-To: icon-group-errors

Here's another version of the line splitter. - Paul Abrahams

********************************

procedure main()
     while line := read() do {
             every writes((trim(line) ? parse()), " | ")
             write()
     }
end

procedure parse()
    suspend tab(upto(' ')|0) \ 1 | (tab(many(' ')), parse())
end

From icon-group-sender  Fri Mar 25 03:21:55 1988
Received: by bocklin.arizona.edu; Fri, 25 Mar 88 03:21:58 MST
Date: Fri, 25 Mar 88 10:19:31 GMT
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - Sun UK TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!sophist.uchicago.edu![e-mail]
Subject: Re:  coexpressions - help!
Cc: sunuk!sun!arizona.edu![e-mail]
Errors-To: icon-group-errors

*)I can't tell why the following program works (i.e. outputs "678"):
*)
*)procedure main()
*)  C := create GetVal()
*)  every a|b|c := @C
*)  write(a,b,c)
*)end

The "every" above has only three alternates: choose a, b or c to assign to.
The co-expression generates on of its three alternates each time it is
activated.  Put more variables and you'd only get assignments to three of
them (ie "every a|b|c|d := @C" would not assign to d as the coexpression
would run out of results at that stage).

*)Why doesn't this work like:
*)
*)procedure main()
*)  every a|b|c := "6"|"7"|"8"
*)  write(a,b,c)
*)end

This "every" has nine alternations (perm every one of {a,b,c} with every
one of {"6","7","8"}).  Since the expression backtracking activated by the
every varies the last alternation most rapidly, the last assignment to
each variable is of the value "8".

Interesting question.

Steve

From icon-group-sender  Fri Mar 25 11:41:31 1988
Received: by bocklin.arizona.edu; Fri, 25 Mar 88 11:41:34 MST
Date: 25 Mar 88  14:09:46 gmt
From: [e-mail]
To: [e-mail]
Via:        UK.AC.RL.EARN; Fri, 25 Mar 88 14:09:15 GMT
Via:        UK.AC.ED.EMAS-C; 25 MAR 88 14:09:07 GMT
Message-Id: <25 Mar 88  14:09:46 gmt  340174@EMAS-C>
Errors-To: icon-group-errors

This is my first query to this board - I hope it's the right forum for this
sort of question.

Consider the code fragment:

d:=read(file)
case d of E-1 : ...
            0 : ...L

fairly non-controversial I think, but it doesn't work on my VAX because (as I
found out after battering my way through the Icon book) the implicit type
conversion called for here (d(string) -> d(integer)) fails unpredictably. The
solution is obvious:

d:=integer(read(file))
case d of E-1 : ...
            0 : ...L

which works fine.

What I want to know is *why* the implicit type conversion fails in this
instance.

Any suggestions gratefully received.

Roger Hare
([e-mail])

From icon-group-sender  Fri Mar 25 12:08:58 1988
Received: by bocklin.arizona.edu; Fri, 25 Mar 88 12:09:02 MST
Return-Path: <[e-mail]>
Date: Fri, 25 Mar 88 13:04:04 CST
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: two types of comparisons
Cc: [e-mail]
Errors-To: icon-group-errors


In response to the type conversion query, please note that there are
two types of comparison operations in Icon:  Ones which compare values,
and ones which don't.  The ones that don't will convert their arguments
to the appropriate type before comparing.  So "10" == 10 will succeed.
So will "10" = 10, I believe.  "10" === 10 won't, however, seeing as the
operation === compares values, and does not convert its arguments to the
appropriate type.  Case expressions work like ===.  I don't know why,
myself, since I rarely have to test variables to see what type they
are.  I rarely use ===.  Although Icon does a lot of implicit type con-
versions, it's often good to use explicit type-conversion functions like
integer() and string() so that your understanding of what is going on is
obvious.

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

P.S. Nice to see a Humanist here.

From icon-group-sender  Fri Mar 25 13:15:10 1988
Received: by bocklin.arizona.edu; Fri, 25 Mar 88 13:15:15 MST
Date: Fri, 25 Mar 88 13:13:10 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: type conversion
Cc: icon-group
In-Reply-To: <25 Mar 88  14:09:46 gmt  340174@EMAS-C>
Errors-To: icon-group-errors

Icon only does type conversion when the operation calls for it.  There
is nothing about a case expression that says the selection should be
on any particular type, so there isn't.  Subscripting tables is
similar.

While you may not have gotten what you expected in your example,
the lack of type conversion actually provides more generality --
e.g. you can select on *any* type (even a list, e.g.).  Since
implicit type conversion that fails is an error, any ad hoc
decision to convert to a particular type would be restrictive.

Icon tries to give you the maximum amount of flexibility in
such situations.

From icon-group-sender  Fri Mar 25 14:18:07 1988
Received: by bocklin.arizona.edu; Fri, 25 Mar 88 14:18:10 MST
Date: Fri, 25 Mar 88 15:05:58 EST
From: [e-mail]
To: [e-mail]
Message-Id: <42455@Wayne-MTS>
Subject: Sorting in Icon, again
Errors-To: icon-group-errors

A while ago there was a flurry of messages about sorting in Icon.  The gist of
them was that it would be nice if the "<" relation could be specified by the
user, thus making more general sorts possible.  The people who would have to
do the work reacted, quite understandably, with less than unbridled
enthusiasm.

I have a more modest proposal.

Currently, according to Scripture, p. 67, all records are treated as one type
during sorting, and the "<" relation for two records is left unspecified.
By defining the "<" relation on records, I think we could achieve most of what
the sorters would like, while at the same time adding no new syntax to Icon.
The effect of making such a definition would simply be to specify what is now
left unspecified.

Three definitions of "<" seem reasonable:

(1) Major sort on record type, minor sort on fields in the order in which they
appear in the record definition.

(2) Major sort on fields in order of appearance, minor sort on record type.

(3) Sort on fields (lexicographic), record types not considered.

For (1) and (2), there are two further possibilities: arbitrary sort on
record type, or sort by name of record type.

Of these possibilities the weakest (and probably easiest to implement) is
(3).  Even this definition would solve a lot of the problems that people have
had with more general sorting.  The most desirable probably would be (1),
with records sorted by record type.  I consider the sort order of record types
less important than providing lexicographic sorting on fields.

Would this be hard to implement?

Paul Abrahams

From icon-group-sender  Fri Mar 25 22:42:24 1988
Received: by bocklin.arizona.edu; Fri, 25 Mar 88 22:42:29 MST
Return-Path: <[e-mail]>
Date: Fri, 25 Mar 88 23:37:30 CST
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: better way?
Errors-To: icon-group-errors


Here's a program that I wrote to convert every sequence of "35," "75," or
"95" to a lowercase "m" (yes, this actually was a real-world problem).  It
seemed a bit clunky to me.  If someone out there is so inclined, would he
or she please offer me some ideas as to how this might better be done:

procedure main()
  s2 := ""
  every s := !&input do {
    s ? {
      while s2 ||:= tab(WhichFirst(["35","75","95"]))
      do s2 ||:= "m" & move(2)
      s2 ||:= tab(0)
      }
    write(s2)
    }
end

procedure WhichFirst(l)
  t := (u := *&subject + 1)
  every t := t > upto(!l)
  return (u ~= t) | fail
end

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Sat Mar 26 07:09:59 1988
Received: by bocklin.arizona.edu; Sat, 26 Mar 88 07:10:03 MST
Date: 25 Mar 88 08:52:50 GMT
From: rochester![e-mail]  (Ken Yap)
Organization: U of Rochester, CS Dept, Rochester, NY
Subject: sets from ranges
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

Pardon a novice question. A colleague of mine posed a problem.  Given
the syntax x{aa-zz}, generate the sequence xaa, xab, ..., xba, ...
xzz.

I can handle the multiple counters by invoking a generator for each
level. But when I came to generating the sequence a, b, ..., z, I
couldn't think of anything better than this.  (This is just a test
program to try the idea.)

procedure main()
    st := "a"
    en := "z"
    al := &ascii
    ran := al[upto(st,al):upto(en,al)]
    every write(!ran)
end

This looks inelegant.

It would have been nice if i to j by k took non-integers. Am I missing
a really simple and obvious way?

    Ken

From icon-group-sender  Sat Mar 26 07:25:36 1988
Received: by bocklin.arizona.edu; Sat, 26 Mar 88 07:25:40 MST
Date: Sat, 26 Mar 88 07:25:34 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
To: rochester![e-mail]
Subject: Re:  sets from ranges
Cc: icon-group
Errors-To: icon-group-errors

-----------------------------------------
   Pardon a novice question. A colleague of mine posed a problem.  Given
   the syntax x{aa-zz}, generate the sequence xaa, xab, ..., xba, ...
   xzz.

   I can handle the multiple counters by invoking a generator for each
   level. But when I came to generating the sequence a, b, ..., z, I
   couldn't think of anything better than this.  (This is just a test
   program to try the idea.)

   procedure main()
       st := "a"
       en := "z"
       al := &ascii
       ran := al[upto(st,al):upto(en,al)]
       every write(!ran)
   end

   This looks inelegant.

   It would have been nice if i to j by k took non-integers. Am I missing
   a really simple and obvious way?
-------------------------------------------------

Version 7 of Icon has a function ord(s) that produces the integer
corresponding to the representation of the one-character string s.

So you can say

    every write(&ascii[ord(st) + 1 to ord(en) + 1])

You might want to use &cset instead of &ascii for generality.

     Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
     [phone]   [e-mail]     {allegra|noao|ihnp4}!arizona!ralph


From icon-group-sender  Sat Mar 26 13:32:08 1988
Received: by bocklin.arizona.edu; Sat, 26 Mar 88 13:32:11 MST
Date: Sat, 26 Mar 88 13:32:06 MST
From: "Janalee O'Bagy" <janalee>
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
To: [e-mail], rochester![e-mail]
Subject: Re:  sets from ranges
Errors-To: icon-group-errors

    From icon-group-sender Sat Mar 26 07:10:30 1988
    From: rochester![e-mail]  (Ken Yap)

    procedure main()
        st := "a"
        en := "z"
        al := &ascii
        ran := al[upto(st,al):upto(en,al)]
        every write(!ran)
    end



I would also use the element generation operator '!' to
generate the strings from a to z, but this is a case where
it is easier to specify the alphabet string with a constant,
rather than to construct it, like this:

        ran := "abcdefghijklmnopqrstuvwxyz"
        every write(!ran)

From icon-group-sender  Sat Mar 26 16:28:46 1988
Received: by bocklin.arizona.edu; Sat, 26 Mar 88 16:28:52 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Sat 26 Mar 1988 17:11 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: better way
Ua-Message-Id: <post.nowlin.Sat 26 Mar 1988 17:01 CST>
End-Of-Protocol:
Content-Length: 1040
Errors-To: icon-group-errors

> Here's a program that I wrote to convert every sequence of "35," "75," or
> "95" to a lowercase "m" (yes, this actually was a real-world problem).  It
> seemed a bit clunky to me.  If someone out there is so inclined, would he
> or she please offer me some ideas as to how this might better be done:

I think your line to initialize s2 was in the wrong place.  I moved it
inside the input loop.  The easiest way to improve this program was to use
alternation to take advantage of goal directed evaluation in the while
loop.  Then you can use a plain old find() function to find your sequences
instead of having to write your own procedure.  Try this version.  I left
your while line in as a comment but left out your WhichFirst() procedure.

procedure main()
  every s := !&input do {
    s2 := ""
    s ? {
      # while s2 ||:= tab(WhichFirst(["35","75","95"]))
      while s2 ||:= tab(find("35" | "75" | "95"))
      do s2 ||:= "m" & move(2)
      s2 ||:= tab(0)
      }
    write(s2)
    }
end

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

From icon-group-sender  Sat Mar 26 20:16:41 1988
Received: by bocklin.arizona.edu; Sat, 26 Mar 88 20:16:46 MST
Date: Sat, 26 Mar 88 20:16:39 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
To: icon-group
Subject: Re:  better way
Errors-To: icon-group-errors

Jerry,

I'm afraid your solution doesn't always find the first of the
numbers in the string. Try: 7535

How is this for a solution

procedure main()
  every s := !&input do {
    s2 := ""
    s ? {
      while s2 ||:= tab(upto('379')) do
        if =("35" | "75" | "95") then
           s2 ||:= "m"
        else
           s2 ||:= move(1)
      s2 ||:= tab(0)
      }
    write(s2)
    }
end

From icon-group-sender  Sat Mar 26 20:21:49 1988
Received: by bocklin.arizona.edu; Sat, 26 Mar 88 20:21:52 MST
From: ihnp4!ihlpe!orf
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Sat 26 Mar 1988 20:37 CST
End-Of-Header:
Email-Version: 2
X-Postmark: ihlpe!orf
To: arizona!icon-group
Subject: Re: Better Way?
Ua-Message-Id: <post.orf.Sat 26 Mar 1988 20:36 CST>
End-Of-Protocol:
Content-Length: 1087
Errors-To: icon-group-errors

 >Here's a program that I wrote to convert every sequence of "35," "75," or
 >"95" to a lowercase "m" (yes, this actually was a real-world problem).  It
 >seemed a bit clunky to me.  If someone out there is so inclined, would he
 >or she please offer me some ideas as to how this might better be done:
 >
Richard,

Here is one way.  It is a "SNOBOL-like" solution in that it simply changes
the line over and over until there are no more changes to make.  If nothing
else, it is simple..


procedure main()
    every s := !&input do
    {
     while  s ?:= 1(tab(find("35"|"75"|"95",s)) , move(2)) || "m" || tab(0)
     write(s)
     }
end

As an aside, here is another version with the strings you are looking for
in a list called pat -- if there are no command line arguments it uses
your default strings. If there are, it will use the argv list instead:

procedure main(argv)
    pat := if *argv = 0 then ["35",75","95"] else argv
    every s := !&input do
    {
     while  s ?:= 1(tab(find(!pat,s)) , move(2)) || "m" || tab(0)
     write(s)
     }
end



Rick Fonorow
ihnp4!ihlpe!orf

From icon-group-sender  Sat Mar 26 21:34:55 1988
Received: by bocklin.arizona.edu; Sat, 26 Mar 88 21:34:58 MST
Date: Sat, 26 Mar 88 21:34:51 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
To: "Re: -s from icon-group ranges", sets
Errors-To: icon-group-errors

Instead of computing the string for the subrange by

     al := &ascii
     ran := al[upto(st,al):upto(en,al)]

You can use string scanning

    &ascii ? {
       tab(find(st))
       ran := tab(find(en) + 1)
       }

I am not sure if it is more elegant, but it is probably a little easier
to read. If you are interested in efficiency, you will note that your
solution converts al from a cset to a string in three places. It also
converts st and en from strings to csets. Actually the most efficient
solution is probably a modification of Ralph's V7 solution (I haven't
run timing tests, so I won't vouch for the relative speeds - it is
easy to guess wrong when trying to decide the fastest way to do something
in Icon). It uses ord's dual function, char.

    every write(char(ord(st) to ord(en)))

Of course, for many Icon programs minor differences in efficiency
are not important.

From icon-group-sender  Sun Mar 27 10:11:28 1988
Received: by bocklin.arizona.edu; Sun, 27 Mar 88 10:11:31 MST
Date: Sun, 27 Mar 88 10:11:26 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
In-Reply-To: <42455@Wayne-MTS>
To: icon-group
Subject: Re:  Sorting in Icon, again
Errors-To: icon-group-errors

> Date: Fri, 25 Mar 88 15:05:58 EST
> From: [e-mail]

...

> Three definitions of "<" seem reasonable:
>
> (1) Major sort on record type, minor sort on fields in the order in which they
> appear in the record definition.
>
> (2) Major sort on fields in order of appearance, minor sort on record type.
>
> (3) Sort on fields (lexicographic), record types not considered.
>
> For (1) and (2), there are two further possibilities: arbitrary sort on
> record type, or sort by name of record type.

...

> Would this be hard to implement?

It does not look hard to do with a recursive comparison routine.
However, some questions arise. Suppose, for simplicity, that we
have only integers and records with 1 field. The following routine
will compare these values (using (3)).

procedure compare(x, y)
   if integer(x) then
      if integer(y) then {
         if      x < y then return "less"
         else if x = y then return  "equal"
                       else return  "greater"
         }
      else
         return "less"       # integers are less than records
   else   # x is a record
      if integer(y) then
         return "greater"    # records are greater than integers
      else
    return compare(x[1], y[1])
end

Now try running the program:

record r(a)

procedure main()
   local x, y

   x := r()
   x.a := x
   y := r()
   y.a := y
   write(compare(x, y))
end

Is this reasonable behavior?

From icon-group-sender  Mon Mar 28 12:13:08 1988
Received: by bocklin.arizona.edu; Mon, 28 Mar 88 12:13:12 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Mon 28 Mar 1988 09:28 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: better way (again)
Ua-Message-Id: <post.nowlin.Mon 28 Mar 1988 09:13 CST>
End-Of-Protocol:
Content-Length: 1054
Errors-To: icon-group-errors

It's so hard to leave this alone.  I screwed up with my first attempt by
not testing thoroughly.  Rick's solution comes closest to being general but
it still assumes that the list of patterns is always two characters long.
Here's a solution that works for arbitrary length patterns (that can be
listed in a different order than they appear in the text...argh!).

procedure main(args)
  if *args = 0 then args := ["35","75","95"]
  every s := !&input do {
    while s ?:= 1(tab(find(p := !args)) , =p) || "m" || tab(0)
    write(s)
  }
end

The originator of this problem also asked for a solution that would only
get the first occurrence of any of the patterns on a given line.  This will
do it.

procedure main(args)
  if *args = 0 then args := ["35","75","95"]
  every s := !&input do {
    s1 := s
    c1 := *s
    p1 := &null
    while s ?:= 1(tab(c := find(p := !args)) , =p) || "m" || tab(0) do
      if c < c1 then c1 := c & p1 := p
    s1 ?:= 1(tab(find(\p1)) , =p1) || "m" || tab(0)
    write(s1)
  }
end

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

From icon-group-sender  Mon Mar 28 13:42:46 1988
Received: by bocklin.arizona.edu; Mon, 28 Mar 88 13:42:50 MST
Date: Mon, 28 Mar 88 12:15:02 EST
From: [e-mail]
To: [e-mail]
Message-Id: <42915@Wayne-MTS>
Subject: Sorting records in Icon
Errors-To: icon-group-errors

Apparently there was some misunderstanding of my comment about sorting, based
on the (unsigned) reply that I received.  The problem I was addressing was not
how to do record sorting in Icon as it stands, but how to change Icon itself
(by defining a case that is presently undefined) in order to make record
sorting useful.

Paul Abrahams

From icon-group-sender  Mon Mar 28 14:35:45 1988
Received: by bocklin.arizona.edu; Mon, 28 Mar 88 14:35:49 MST
Date: Mon, 28 Mar 88 14:35:42 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
In-Reply-To: <42915@Wayne-MTS>
To: icon-group
Subject: Re:  Sorting records in Icon
Errors-To: icon-group-errors

> Date: Mon, 28 Mar 88 12:15:02 EST
> From: [e-mail]
>
> Apparently there was some misunderstanding of my comment about sorting, based
> on the (unsigned) reply that I received.  The problem I was addressing was not
> how to do record sorting in Icon as it stands, but how to change Icon itself
> (by defining a case that is presently undefined) in order to make record
> sorting useful.

I was addressing the question of how to define such a sort and was using
Icon as a convenient language in which to express the comparison algorithm.
I'm sorry I didn't make that clear - I just automatically prototype
in Icon. The actual implementation would be done in C as part of the
Icon run-time system and needs to be more general then the prototype
I presented. In either Icon or C the question still remains of how much
work is needed in dealing with the possiblitly of loops created using
record references.

By the way, in Version 7 record sorting has been defined to be
chronological. That is they are sorted into the order in which they
were created. However, I don't see that has much effect on the
discussion.

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

(I remembered to include a signaure this time :-)


From icon-group-sender  Tue Mar 29 12:04:16 1988
Received: by bocklin.arizona.edu; Tue, 29 Mar 88 12:04:19 MST
Return-Path: <[e-mail]>
Date: Tue, 29 Mar 88 12:55:41 CST
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Which is first?
Errors-To: icon-group-errors

>procedure main()
>  s2 := ""
>  every s := !&input do {
>    s ? {
>      while s2 ||:= tab(WhichFirst(["35","75","95"]))
>      do s2 ||:= "m" & move(2)
>      s2 ||:= tab(0)
>      }
>    write(s2)
>    }
>end
>
>procedure WhichFirst(l)
>  t := (u := *&subject + 1)
>  every t := t > upto(!l)
>  return (u ~= t) | fail
>end

With all due respect, I think I like WhichFirst(l) best so far, since it
could be used to find "35" or "75" or "95," whichever comes first, as well
as find every one on the line (hence its name).

Expression of joy:  Isn't it great how Icon lets one say "every t := t >
upto(!l)"?!  The elegance of this language is amazing except in how it
shows my inelegance as a programmer....

                                                           Richard Goerwitz
                                                  [e-mail]
                                            ...!ihnp4!gargoyle!sophist!goer

From icon-group-sender  Tue Mar 29 21:41:01 1988
Received: by bocklin.arizona.edu; Tue, 29 Mar 88 21:41:07 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Tue 29 Mar 1988 14:40 CST
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Why Co-expressions?
Ua-Message-Id: <post.nowlin.Tue 29 Mar 1988 14:38 CST>
End-Of-Protocol:
Content-Length: 959
Errors-To: icon-group-errors

I've noticed there are two major classes of solutions to the problems
posted here; those that use co-expressions and those that don't.  I favor
solutions that avoid co-expressions and some others seem to favor solutions
that make use of them.  I guess I've led a relatively sheltered Icon life.
Until I recently got V7 on my MS-DOS machine, I haven't had ready access to
co-expressions. I've learned to get by without them in the past so I don't
automatically think of them when programming in Icon.

Some examples that have gone by in this group appear to use co-expressions
to simply generate the results of an already generative procedure.  I can
understand the use of co-expressions for parallel and "floating"
generation.  Other than that I wonder why you would use them?  This is a
legitimate question.  I want to understand how co-expression will make my
programming easier now that I have more access to them.

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

From icon-group-sender  Wed Mar 30 02:55:10 1988
Received: by bocklin.arizona.edu; Wed, 30 Mar 88 02:55:18 MST
Date: 28 Mar 88 22:55:58 GMT
From: ihnp4!ihlpf![e-mail]  (00704a-Liber)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: Re: sets from ranges
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

In article <[e-mail]> [e-mail] (Ken Yap) writes:
.Pardon a novice question. A colleague of mine posed a problem.  Given
.the syntax x{aa-zz}, generate the sequence xaa, xab, ..., xba, ...
.xzz.

From icon-group-sender  Wed Mar 30 04:53:03 1988
Received: by bocklin.arizona.edu; Wed, 30 Mar 88 04:53:07 MST
Return-Path: <[e-mail]>
Date: Wed, 30 Mar 88 05:19:29 CST
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Why coexpressions?
Errors-To: icon-group-errors

Jerry Nowlin, in a recent posting, stated that he wanted to understand coex-
pressions better.  Me, too.

I've used them to pop off results from a sequence one at a time in various
places.  However, because v6 didn't let me do coroutine programming, I have
never really become accustomed to using coexpressions this way.  I don't
have a feel for it.

Could someone maybe offer some short, practical examples?

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Thu Mar 31 06:48:37 1988
Received: by bocklin.arizona.edu; Thu, 31 Mar 88 06:48:40 MST
Date: Thu, 31 Mar 88 06:48:35 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
To: icon-group
Subject: co-expressions
Errors-To: icon-group-errors

The following mail is from Steve Wampler a NAU. It was intended for
icon-group, but wound up elsewhere by accident.  I am just sending it
along.
===================================================================
Jerry Nowlin recently asked about the uses of co-expressions.  I
thought I might throw my $0.02 in on this.

   Goal-directed evaluation is a very generalized, very powerful
   control regime.  However, as with most such beasts, sometimes
   it needs 'taming' (you can see why I didn't contribute to
   recent discussions in the Icon newsletter on terminology!) -
   that is, often the effects of GDE are not quite what is needed.

   Several examples:

    (1) The natural LIFO order to resuming generators isn't
        at all natural for all problems.  The question on
        assigning successive results from a result sequence
        to separate scalar variables that was recently posed
        to this group is such a case.  Even though there
        are clear and succinct expressions for generating both
        the variables:
                 (a | b | c | d)
            and the values (say the following, for discussion):
                 (1 to 4)
            The normal operation of GDE prevents their combination
            in the 'natural':
                 every (a|b|c|d) := (1 to 4)

        (2) The coupling of a generator (which produces results)
        to its lexical point of invocation similarly
            restricts the effective use of generators.  A (very)
            rough analogy can be made with the concept of an Algol
        (or C) block - it can be conceptualized as a procedure
        whose invocation is fixed to the point of definition -
            a useful tool, but severely restricted in its generality.
        Generators provide a extremely nice way to describe a
        result sequence.  Fixing access to the results in that
        sequence to a single lexical sight forces some
            uses of generators to be obscured.  For example, one
            often sees results from a generator being placed into
            a list - just so the results can be accessed at other
            places in the program.

   Co-expressions solve both these problems (and others) by allowing
   programmers to manage result sequences as data objects in the
   language - the generator becomes (as it really is) simply a
   representation of the result sequence.  The co-expression activation
   allows the programmer control over the production of the results
   in that sequence.

   By controling the generator (1 to 4) in the first
   example, one can use the 'natural' generators above to perform the
   task:

    next_result := create (1 to 4)
        every (a|b|c|d) := @next_result

   (for the symmetry fanatics, does the following work?

    next_variable := create (a|b|c|d)
        next_result   := create (1 to 4)
        while @next_variable := @next_result

    Why not?)

   In general, anytime you find yourself either unable to use a generative
   expression when a natural one exists, or saving the results from a
   generative expression into a list - you probably should think
   'co-expression'.

   I could go on here, and talk about designing your own control regimes
   by using co-expressions, but this is way too long already.

Richard Goerwitz asked for 'short, practical' examples of co-expressions
used as coroutines.  I wish I could help - but I think 'short, practical
coroutines' just might be an oxymoron.  Most small examples of coroutines
are contrived examples that usually can be just as clearly coded in
some other fashion - this is similar to using factorial to illustrate
recursive code.  I have a simple prime number seive that uses coroutines.
I think it appeared in an early newsletter.  You might compare that to
the considerably more efficient seive that uses Icon sets which appeared
in a later newsletter.  If you want to see it, I'll be happy to mail it
to you (the coroutine version, alas) - if I can find it again.  I also
had (note the past tense) a partial solution to my second Icon programming
contest problem that used co-expressions as coroutines for managing
the rounds - but the complexity of the parallelism involved exceeded the
complexity of my brain paths.

From icon-group-sender  Thu Mar 31 12:27:00 1988
Received: by bocklin.arizona.edu; Thu, 31 Mar 88 12:27:07 MST
Date: Thu, 31 Mar 88 12:54:38 EST
From: [e-mail]
To: [e-mail]
Message-Id: <44149@Wayne-MTS>
Subject: Co-expressions: their uses and non-uses
Errors-To: icon-group-errors

I have found co-expressions used in one direction, not as coroutines, to be
extraordinarily useful -- indeed essential -- in a lot of the work I've been
doing in Icon.  A typical pattern is:

gen := create "generator"
while (v := @gen) { "do something complicated with v" }

If the code that works on v isn't compact enough to fit into an expression,
ordinary goal-directed evaluation does not suffice.

However, I have yet to find any uses for the more general form of
co-expressions, in which values are passed in both directions.  In fact, most
of the classic applications of coroutines really use them as generalized
pipes.  Steve (Wampler), have you ever encountered any situations, even in
complicated programs, where co-expressions that receive values as well as
transmit them are useful in the sense of significantly simplifying the
program?  From your description of the prime sieve with coroutines, I gather
that coroutines don't produce a more satisfying program.

Paul Abrahams

From icon-group-sender  Thu Mar 31 14:16:49 1988
Received: by bocklin.arizona.edu; Thu, 31 Mar 88 14:16:52 MST
Date: Thu, 31 Mar 88 14:16:47 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
In-Reply-To: <44149@Wayne-MTS>
To: icon-group
Subject: Re:  Co-expressions: their uses and non-uses
Errors-To: icon-group-errors

> From: [e-mail]
> To: [e-mail]
>
> I have found co-expressions used in one direction, not as coroutines, to be
> extraordinarily useful -- indeed essential -- in a lot of the work I've been
> doing in Icon.  A typical pattern is:
>
> gen := create "generator"
> while (v := @gen) { "do something complicated with v" }
>
> If the code that works on v isn't compact enough to fit into an expression,
> ordinary goal-directed evaluation does not suffice.

It is not clear from this why you cannot do something like

  every v := ``generator'' do {
     ``something complicated with v''
     }

could you elaborate?

From icon-group-sender  Thu Mar 31 15:35:15 1988
Received: by bocklin.arizona.edu; Thu, 31 Mar 88 15:35:24 MST
Date: Thu, 31 Mar 88 14:41:48 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8803312141.AA03146@naucse>
To: arizona!icon-group
Subject: Re:  Co-expressions: their uses and non-uses
Errors-To: icon-group-errors

> From: arizona![e-mail]
>
> However, I have yet to find any uses for the more general form of
> co-expressions, in which values are passed in both directions.  In fact, most
> of the classic applications of coroutines really use them as generalized
> pipes.  Steve (Wampler), have you ever encountered any situations, even in
> complicated programs, where co-expressions that receive values as well as
> transmit them are useful in the sense of significantly simplifying the
> program?  From your description of the prime sieve with coroutines, I gather
> that coroutines don't produce a more satisfying program.

My own (very naive) opinion is that coroutines are to recursion as
recursion is to interation.  At the 'simple' end of recursion, you
are no clearer than iteration, at the 'simple' end of coroutining[sic],
you are no clearer than recursion.  However, at the complex end of
recursion, you are a lot clearer than iteration.  I suspect that
at the complex end of coroutines, you are a lot clearer than recursion.
However, my own work (undergraduate teaching) doesn't get into that realm.

As to the prime sieve, I personally think the coroutine version is very
clear, but so is a similar recursive version.  The set version (which
I'm recalling from memory) takes some getting used to, but distills the
problem down to pretty basic components.

One problem in using past versions of co-expressions as pipes is
the fact that the initial call ignores the value in the 'pipe'.
I don't know if v7 Icon handles that differently.  Thus the seive
program passes values down the pipe via global variable.

Before we get too far off, let me state that the more 'conventional'
uses of co-expressions are very nice - they work simply and can
often produce much clearer code.

For the record, here is my co-expression version of the prime-number
seive (posted semi-reluctantly - people should really look at the
set version).

----
## prime number sieve (using co-expressions)
#    builds an increasingly long 'cascade' of coroutines acting
#    as filters between the source of numbers and the sink for primes.

global num, cascade, source, nextfilter

procedure main()

   source := create {                   # start the cascade on possible primes
                every num := seq(2) do
                   @@(nextfilter := create !cascade)
                }
   cascade := []
   put(cascade, create sink())         # the first number (2) is assumed to
                                        #   be a prime.
   @source

end

procedure sink()                        # have a prime, display it and
local prime                             #   add a new filter to the cascade

   repeat {
      write(prime := num)
      put(cascade, create filter(prime))    # this keeps us looking at
      cascade[-2] :=: cascade[-1]        #   small divisors first.
      @source
      }

end

procedure filter(prime)                 # test to see if num is a multiple
                                        #   of prime
   repeat {
     if num % prime = 0 then @source
     else @@nextfilter
     }

end

From icon-group-sender  Mon Apr  4 17:24:43 1988
Received: by bocklin.arizona.edu; Mon, 4 Apr 88 17:24:45 MST
Return-Path: <[e-mail]>
Date: Mon, 4 Apr 88 19:19:36 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Icon prgms. in other languages
Errors-To: icon-group-errors


Occasionally I'm faced, for one reason or another, with the task of re-coding
Icon programs in another language.  Usually I try to use C, but it's often
very time-consuming and messy compared to the original Icon.  Perhaps this is
due in part because I don't feel really comfortable programming in C.  More
than this, though, it seems to be due to the drastically different geniuses
of the languages.  I wonder:  Would there be a better choice of languages to
use when faced with the need for re-coding?  Prolog?  Lisp?  Others?  Of
course, my first choice for what I am doing (natural language processing of
various sorts) is Icon, and I like to use it if at all possible.  Sometimes,
however, the people I'm working with don't know it, or don't have it instal-
led, or for some other reason can't work with Icon.  It's cases like this
I'm concerned about.  Does anyone have any ideas as to what might serve as
a good middle-ground?

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Tue Apr  5 12:21:04 1988
Received: by bocklin.arizona.edu; Tue, 5 Apr 88 12:21:07 MST
Date: Tue,  5 Apr 88 14:19:33 CDT
From: D.S.Cargo MN67-2D13 593-2822 <[e-mail]>
Subject: Possible bug in getch() in MS-DOS version 7
To: [e-mail]
X-Vms-Mail-To: EXOS%"[e-mail]"
Message-Id: <[e-mail]>
Errors-To: icon-group-errors

## yesno -- a program to allow manual filtering of lines through a pipe
# Try testing with "iconx yesno <yesno.icn >junk" to observe behavior.
# Use a ^C when it finally gets around to getting terminal input.
# I sure hope somebody can tell me whats going on here.
# It looks like a bug to me.  If it isn't, then the applicable documents
# need to be updated.  Code that has been commented out are fossils of
# attempts to find alternate implementations that would work as intended.
# David S. Cargo -- [e-mail]

procedure main (a)
  local answer, conin, conout, line
# conin := open ("CON", "r")
  conout := open ("CON","w")
  filein := &input
# filein := open (a[1], "r") | stop ("Couldn't open input file.")

  write (conout, "In response to the query, y or Y will cause the line to")
  write (conout, "be copied to standard output, n or N will cause the line")
  write (conout, "not to be copied, and q will cause the no more lines to")
  write (conout, "be copied.")

  while line := read (filein) do
    {
    write (conout, line)
    write (conout, "copy?")
#   while answer := read (conin) do
#   while answer := getche () do
    while answer := getch () do
      {
      if answer == "" then answer := " "
      case answer of
        {
        "y" | "Y" | "c" | "C" :
          {
          write (line)
          break
          }

        "n" | "N" : break

        "q" | "Q" : break break

        " " | char (10) | char (13) : next

        default :
          {
          writes (conout, answer, " (char code ", ord (answer))
          write (conout, ") is not understood.  Use Y, y, N, or n.")
          write (conout, line)
          write (conout, "copy?")
          }
        }
      }
    }
  return
end

From icon-group-sender  Tue Apr  5 15:26:08 1988
Received: by bocklin.arizona.edu; Tue, 5 Apr 88 15:26:11 MST
Return-Path: <[e-mail]>
Date: Tue, 5 Apr 88 17:20:59 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Bad idea?  Good idea?
Errors-To: icon-group-errors


When doing text and language processing of various sorts, especially when
doing parsing based on pattern-matching procedures, I run into a situation
where I want to have disjoint if-then constructions.

An example:  Suppose I want to find the sequences (each beginning a word) -

            LIK:T.OB
            B.IK:TOB
            K.IK:TOB
            W:BIK:TOB
            W:KIK:TOB
            etc.

(the main consideration here is that if W: starts the word, then "." may not
follow B and K and L), I would create a procedure that said something like:

            while arb() & tab(many(' ')) &
                  hit := (="W:" | "") || tab(any('LKB')) ||
                         ="K:T" || .....
            do suspend hit

The trouble here is that what I really want to do is tie the occurrence of
W: at the beginning of the word into the presence of "."

Right now, I am generally stuck admitting strings I don't want, or else
writing out many, many pattern-matchers that cover much of the same
ground.  This example is only a small one.  If I could just be granted
a shorthand notation for tying what one expression produces to the suc-
cess or failure of another one, much of my language processing could
be simplified.  Such devices are used quite often by linguists, especially
when talking about phonological rules.  It's part of the power of formal
grammar and its appropriate notation.  It allows much to be stated in a
very small space.  Elegance.

Right now we have / and \ in Icon.  These check for the value &null, and
either suceed or fail, depending on which one is used, and whether &null
is found.  What I would want is something like this, but yet which checked
for any result I specified.  Unlike / and \, however, it would set a marker
to the value "succeed" or "fail."  This marker could then be tied to
any other expression at that &level, and it would be evaluated only if the
marker had the value "succeed."  Otherwise, it would simply be ignored.
To do all this, we can use, say // or \\.  On the left is the desired
result, on the left is the expression proper:

      while arb() & tab(many(' ')) &
            hit := "W."\\(="W:"|"") || tab(any('LKB')) ||
                   \\(="." ||) etc.

"W:"//(="W:"|"") means that if (="W:"|"") produces "W:", then some
invisible marker gets set to "succeed".  The next expression preceded
by // then is evaluated.  If (="W."|"") does not produce "W:", then
the next expression preceded by // would be ignored.  \\ would work the
opposite way (if "W:" was produced, then the next expression preceded
by \\ would not be evaluated).

Is this totally absurd?  Is this a bad idea?  Should I go home and stuff
my head under my pillow for sticking my neck out and embarrassing myself?

Uncertain of myself....

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Wed Apr  6 12:01:38 1988
Received: by bocklin.arizona.edu; Wed, 6 Apr 88 12:01:41 MST
Date: Wed,  6 Apr 88 14:00:08 CDT
From: D.S.Cargo MN67-2D13 593-2822 <[e-mail]>
Subject: Particulars on Icon 7 for MS-DOS where bug believed found
To: [e-mail]
X-Vms-Mail-To: EXOS%"[e-mail]"
Message-Id: <[e-mail]>
Errors-To: icon-group-errors

Running the following program produced the output included below it.
I trust this is sufficient to identify the Icon version used with my
yesno.icn program sent earlier.

procedure main()
  write (&version)
  write (&host)
  every write (&features)
end

Icon Version 7.0.  January 16, 1988.
MS-DOS (FR + MS-DOS functions) ex Microsoft C Version 4.0
MS-DOS
MS-DOS extensions
co-expressions
overflow checking
environment variables
error traceback
string invocation
fixed regions

From icon-group-sender  Wed Apr  6 18:33:26 1988
Received: by bocklin.arizona.edu; Wed, 6 Apr 88 18:33:30 MST
Date: Wed, 6 Apr 88 16:59:28 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8804062359.AA07625@naucse>
To: arizona!icon-group
Subject: another example of co-expressions
Errors-To: icon-group-errors


Recent postings prompt me to provide the following illustration of
a simple use of co-expressions to "capture" a result-sequence.

I regularly want to scan the command line arguments looking for
various options.  Often some options flag the next argument has
providing some specific value.  The '!' operator is a very
elegant means of generating the command line arguments, but
isn't directly applicable to this problem (because of the feature
in the second sentence of this paragraph).  An example of the
co-expression use in this problem follows:

    procedure main(args)
            ...
        nextarg := create !args
            while arg := @nextarg do
               case arg of {
                  "-r" : &random := integer(@nextarg)
                  "-n" : {
                         name := @nextarg
                         new_grade := @nextarg
                          }
                  default: put(flist,arg)
                   }
        ...

Note that

    every arg := !args do ...

will not work in this situation.  The other alternatives of
(i) subscripting through the list ala 'C', 'Pascal', etc.
and (ii) using pop(args) to pull items out of the list are
(i) ugly, requiring an extra variable, extra work, etc. and
(ii) destructive to the argument list, rendering it useless
for later access.

From icon-group-sender  Thu Apr  7 08:44:01 1988
Received: by bocklin.arizona.edu; Thu, 7 Apr 88 08:44:04 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Thu 07 Apr 1988 08:25 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: another example of co-expressions
Ua-Message-Id: <post.nowlin.Thu 07 Apr 1988 08:18 CDT>
End-Of-Protocol:
Content-Length: 1420
Errors-To: icon-group-errors

This is the best example of using co-expressions to a allow a generator to
be invoked from different expressions that I've seen.  Very illustrative.

> Recent postings prompt me to provide the following illustration of
> a simple use of co-expressions to "capture" a result-sequence.
>
>     procedure main(args)
>             ...
>         nextarg := create !args
>             while arg := @nextarg do
>                case arg of {
>                   "-r" : &random := integer(@nextarg)
>                   "-n" : {
>                          name := @nextarg
>                          new_grade := @nextarg
>                           }
>                   default: put(flist,arg)
>                    }
>         ...
>
> Note that
>
>     every arg := !args do ...
>
> will not work in this situation.

Joe Hall had an application that's a good example of parallel generation
using co-expressions.  He wanted to print the values in the new generator
keyword &collections (V7) with labels in front.  This example program
contains a procedure to do that using co-expressions.

procedure main()
    write(gc_cnt())
    collect()
    write(gc_cnt())
end

procedure gc_cnt()
    static    gc_text
    initial    gc_text := [ "total ", "static", "string", "block " ]

    label := create !gc_text
    value := create &collections

    write("\nGarbage Collections:")
    while write(@label,right(integer(@value),8))
end

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

From icon-group-sender  Thu Apr  7 09:40:38 1988
Received: by bocklin.arizona.edu; Thu, 7 Apr 88 09:40:41 MST
Date: Thu, 7 Apr 88 09:40:36 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
To: icon-group
Subject: Re:  Bad idea?  Good idea?
Errors-To: icon-group-errors

> Date: Tue, 5 Apr 88 17:20:59 CDT
> From: Richard Goerwitz <[e-mail]>
>
> [justification for proposal deleted]
> Right now we have / and \ in Icon.  These check for the value &null, and
> either suceed or fail, depending on which one is used, and whether &null
> is found.  What I would want is something like this, but yet which checked
> for any result I specified.  Unlike / and \, however, it would set a marker
> to the value "succeed" or "fail."  This marker could then be tied to
> any other expression at that &level, and it would be evaluated only if the
> marker had the value "succeed."  Otherwise, it would simply be ignored.
> To do all this, we can use, say // or \\.  On the left is the desired
> result, on the left is the expression proper:
>
>       while arb() & tab(many(' ')) &
>             hit := "W."\\(="W:"|"") || tab(any('LKB')) ||
>                    \\(="." ||) etc.
>
> "W:"//(="W:"|"") means that if (="W:"|"") produces "W:", then some
> invisible marker gets set to "succeed".  The next expression preceded
> by // then is evaluated.  If (="W."|"") does not produce "W:", then
> the next expression preceded by // would be ignored.  \\ would work the
> opposite way (if "W:" was produced, then the next expression preceded
> by \\ would not be evaluated).

Is the following a reasonable characterization of the proposal?

   expr1 // expr2

is equivalent to

   {
   invisable_marker := &null
   2(t1 := expr1,
     t2 := expr1,
     if t1 === t2 then
        invisable_marker := 0  # an arbitrary non-null value
     else
        0                      # something other than failure
    )
   }

and

   //expr

is equivalent to

   if \invisable_marker then expr

I have two reactions to this proposal. One is that it is somewhat
specialized: you are setting a flag (marker) based on an implicit
comparison. It seems to me that it would be more general to simply
set it based on the success or failure of an explicit expression.
Judging from your example, you want to produce the value of the
expression even when the comparison fails, but I think your needs
are rather specialized in this respect.

My second reaction is that it is somewhat limited in that you can
only have one flag active per procedure call. I occasionally want
several "boolean" flags at one time.

At present the best way to handle flags seems to be to have variables
with null/non-null values an to use the unary operators / and \ to
test them. It would be more elagant to have real true/false values
with some operator which would succeed/fail based on those values.
Perhaps some control structure like the following would be useful

   variable <some-operator> expr

which has the following effect

  if temp := expr then {
      variable := &true
      temp
      }
   else
      variable := &false
      &fail
       }

except that the expression for variable would be evaluated before
expr.

Such a feature is probably not quite useful enough to justify the
additonal burden on the language.

From icon-group-sender  Fri Apr  8 09:30:52 1988
Received: by bocklin.arizona.edu; Fri, 8 Apr 88 09:30:55 MST
Date: Fri, 8 Apr 88 09:30:49 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
In-Reply-To: <46251@Wayne-MTS>
To: icon-group
Subject: Re: another example of co-expressions
Errors-To: icon-group-errors

[Really From: [e-mail]]

So far I've seen three examples of why coexpressions are useful (including
my own).  But all three of them use one-way transmission only.  Does anyone
have an example of two-way transmission being used in as natural a way?

Paul Abrahams

From icon-group-sender  Mon Apr 11 18:16:56 1988
Received: by bocklin.arizona.edu; Mon, 11 Apr 88 18:17:00 MST
Date: Thu, 7 Apr 88 09:40:36 MST
From: "Kenneth Walker" <arizona.edu![e-mail]>
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
To: [e-mail]
Subject: Re:  Bad idea?  Good idea?
Errors-To: arizona.edu![e-mail]
Errors-To: icon-group-errors

> Date: Tue, 5 Apr 88 17:20:59 CDT
> From: Richard Goerwitz <[e-mail]>
>
> [justification for proposal deleted]
> Right now we have / and \ in Icon.  These check for the value &null, and
> either suceed or fail, depending on which one is used, and whether &null
> is found.  What I would want is something like this, but yet which checked
> for any result I specified.  Unlike / and \, however, it would set a marker
> to the value "succeed" or "fail."  This marker could then be tied to
> any other expression at that &level, and it would be evaluated only if the
> marker had the value "succeed."  Otherwise, it would simply be ignored.
> To do all this, we can use, say // or \\.  On the left is the desired
> result, on the left is the expression proper:
>
>       while arb() & tab(many(' ')) &
>             hit := "W."\\(="W:"|"") || tab(any('LKB')) ||
>                    \\(="." ||) etc.
>
> "W:"//(="W:"|"") means that if (="W:"|"") produces "W:", then some
> invisible marker gets set to "succeed".  The next expression preceded
> by // then is evaluated.  If (="W."|"") does not produce "W:", then
> the next expression preceded by // would be ignored.  \\ would work the
> opposite way (if "W:" was produced, then the next expression preceded
> by \\ would not be evaluated).

Is the following a reasonable characterization of the proposal?

   expr1 // expr2

is equivalent to

   {
   invisable_marker := &null
   2(t1 := expr1,
     t2 := expr1,
     if t1 === t2 then
        invisable_marker := 0  # an arbitrary non-null value
     else
        0                      # something other than failure
    )
   }

and

   //expr

is equivalent to

   if \invisable_marker then expr

I have two reactions to this proposal. One is that it is somewhat
specialized: you are setting a flag (marker) based on an implicit
comparison. It seems to me that it would be more general to simply
set it based on the success or failure of an explicit expression.
Judging from your example, you want to produce the value of the
expression even when the comparison fails, but I think your needs
are rather specialized in this respect.

My second reaction is that it is somewhat limited in that you can
only have one flag active per procedure call. I occasionally want
several "boolean" flags at one time.

At present the best way to handle flags seems to be to have variables
with null/non-null values an to use the unary operators / and \ to
test them. It would be more elagant to have real true/false values
with some operator which would succeed/fail based on those values.
Perhaps some control structure like the following would be useful

   variable <some-operator> expr

which has the following effect

  if temp := expr then {
      variable := &true
      temp
      }
   else
      variable := &false
      &fail
       }

except that the expression for variable would be evaluated before
expr.

Such a feature is probably not quite useful enough to justify the
additonal burden on the language.

From icon-group-sender  Mon Apr 11 20:10:49 1988
Received: by bocklin.arizona.edu; Mon, 11 Apr 88 20:10:52 MST
Date: Fri, 8 Apr 88 09:30:49 MST
From: "Gregg Townsend" <arizona.edu![e-mail]>
Message-Id: <[e-mail]>
In-Reply-To: <46251@Wayne-MTS>
To: [e-mail]
Subject: Re: another example of co-expressions
Errors-To: arizona.edu![e-mail]
Errors-To: icon-group-errors

[Really From: [e-mail]]

So far I've seen three examples of why coexpressions are useful (including
my own).  But all three of them use one-way transmission only.  Does anyone
have an example of two-way transmission being used in as natural a way?

Paul Abrahams

From icon-group-sender  Mon Apr 11 21:58:07 1988
Received: by bocklin.arizona.edu; Mon, 11 Apr 88 21:58:11 MST
Date: Mon, 11 Apr 88 21:58:05 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: icon-group
In-Reply-To: <[e-mail]>
Subject:  Bad idea?  Good idea?
Errors-To: icon-group-errors

   Date: Thu, 7 Apr 88 09:40:36 MST
   From: "Kenneth Walker" <[e-mail]>
   ...
   At present the best way to handle flags seems to be to have variables
   with null/non-null values an to use the unary operators / and \ to
   test them. It would be more elagant to have real true/false values
   with some operator which would succeed/fail based on those values.
   ...

I don't agree that true/false values are in any way elegant.  In fact
I've always thought they were awkward and artificial, and one of my
favorite things about Icon is the way it gets rid of booleans.  In
languages with boolean values the expression part of the language is
functional (meaning that everything returns a value).  Relations are
not functional, so when relations are needed, they are crammed into
functions that return booleans.  Ick.

Take Pascal as an example.  There are two different kinds of contexts
in Pascal (ignoring declarations).  One is the context in which
statements may appear such as after a "begin" or a "then".  The other
context is for expressions, such as after a ":=" or inside another
expression.  Look at a Pascal syntax to see what I mean.  Now a
statement is something that has an affect on the state of the
computer, such as changing a variable, or changing the flow of
control.  An expression is something that produces a value, and
generally has no other affect (that is, expressions are not supposed
to change variables or the flow of control).  Relations such as
"equals" and "parent of" don't really fit either category.  They
aren't supposed to affect the state of the computer, and they aren't
supposed to return a value, they are supposed to be true or false (not
_return_ true or false).

Wirth chose to force relations into expressions rather than creating a
new sort of context.  Well, if two contexts are good, why aren't three
better?  Or if it is good to combine contexts, then why not combine
statements and expressions as Icon does?  By the way, this should not
be taken of a criticism of Pascal only, _most_ procedural languages do
this, including Algol and C.

Sorry if I ran on, this is one of my favorite nits to pick on.

                    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-sender  Thu Apr 14 11:48:51 1988
Received: by bocklin.arizona.edu; Thu, 14 Apr 88 11:48:54 MST
Date: Thu, 14 Apr 88 13:43:11 CDT
From: David S. Cargo MN67-2F08 593-2822 <[e-mail]>
Subject: environment variables
To: [e-mail]
X-Vms-Mail-To: EXOS%"[e-mail]"
Message-Id: <[e-mail]>
Errors-To: icon-group-errors

The new version of MS-DOS Icon can examine individual environment variables.
Is it reasonable to add the capability to see ALL the environment variables
(probably as a list of list, or perhaps as a table)?  The C runtimes for
MS-DOS also allow a peek at the command line (typically as argument 0).
I could see some utility with that too.

Anybody else have an opinion?

David S. Cargo ([e-mail])

From icon-group-sender  Sun Apr 17 12:44:24 1988
Received: by bocklin.arizona.edu; Sun, 17 Apr 88 12:44:26 MST
Return-Path: <[e-mail]>
Date: Sun, 17 Apr 88 14:12:57 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: suspending
Errors-To: icon-group-errors

Can someone with more experience than I explain why these two are not equival-
ent:

            while suspend str || @E

            while str2 := @E
            do suspend str1 || str2

where E is a coexpression that returns a string.  What I'm finding is that
@E gets successfully produces two results in the second case (in my program,
it's supposed to produce two results), while the first fails when resumed for
the second time.

If you want, I can give more context; I think, though, that I must be over-
looking something fairly simple.

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Sun Apr 17 16:52:26 1988
Received: by bocklin.arizona.edu; Sun, 17 Apr 88 16:52:29 MST
Date: 17 Apr 88 03:43:25 GMT
From: [e-mail]  (Alan D Corre)
Organization: University of Wisconsin-Milwaukee
Subject: Re: Bad idea?  Good idea?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors


It seems to me that the main problem with booleans in Icon is that
there isn't a neat way to flip them. If ZAZO is a boolean, then in Pascal
               ZAZO := NOT ZAZO
makes ZAZO true if it is false and vice versa. In Icon I would write
          /ZAZO := 1 | ZAZO := &null
which seems to me much harder to read. Is there a better way to do it?

From icon-group-sender  Sun Apr 17 17:36:14 1988
Received: by bocklin.arizona.edu; Sun, 17 Apr 88 17:36:18 MST
Date: Sun, 17 Apr 88 15:38:36 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8804172238.AA21859@naucse>
To: arizona!icon-group
Subject: Explanation of prime seive
Errors-To: icon-group-errors


I was asked by a couple of people about two weeks ago to provide an
explanation of the prime number seive I posted to this group.  I'm
sorry this took so long, but things have been busy (so what else is
new?).

Before I launch into this, I want to point out that this type of
use of co-expressions is NOT typical - it is much more common to
use co-expressions as means of controlling access to result sequences.

The basic idea of the program is to construct a 'cascade' of independent
routines.  Except for the first and the last routine, each is a 'filter'
that checks to see if a potential prime is divisible by a known prime.
Since a potential prime that passes completely through the filters becomes
a known prime, the last routine in the cascade has to add a 'filter'
to the cascade to test subsequent potential primes against this new
known prime (this last routine, dubbed the 'sink' also prints the
value of the newly discovered prime).  The first routine in the cascade
is responsible for producing potential primes (and is hence the 'source'
of all numbers fed through the cascade).  For each potential prime, the
source also establishes the sequence of filters the number is to passed
through.

If a filter discovers that the current potential prime is divisible by
its known prime, then it simply restarts the source, which produces the
next prime, and so on.  If a filter discovers that the current potential
prime is not divisible by its known prime (and hence, still a potential
prime), it simply starts up the next filter to continue the potential
prime's journey down the cascade.

The important parts of the actual code are reproduced below, annotated
to reflect the role each has in the above description:

(1)
  global num,    # It turns out to be easiest in Icon to pass the
        #   potential prime via a global, so this is it.
     cascade,    # the cascade of filters, global so that
            #   both the source and the sink can manipulate it
     nextfilter,    # the sequence of filters in the cascade
     source    # see comments above

(2)
   source := create {                   # start the cascade on possible primes
                every num := seq(2) do
                   @@(nextfilter := create !cascade)
                }

    This is the source mentioned above.  It's perhaps clearer if
    the code is 'spread out' some:

   source := create {
            every num := seq(2) do {    # generate the potential primes
           nextfilter := create !cascade    # sequence of filters
           first_filter := @nextfilter
                   @first_filter    # pass the potential prime to the
                    #   first filter in the cascade
                   }
                }

(3)    # at this point, the source hasn't been executed, just constructed
(4)    #  so construct an initial cascade, with just the sink in it.
    #  this means that the first potential prime produced by the source
    #  will reach the sink and become the first known prime (which
    #  is why 'seq(2)' was used above).
   cascade := list()
   put(cascade, create sink())         # the first number (2) is assumed to
                                        #   be a prime.
    # in retrospect, this is cleaner as:
   cascade := [create sink()]

    # start up the source, to get everything rolling
   @source

(5)    # the sink is only reached when 'num' is known to be prime...

   procedure sink()                # have a prime, display it and
   local prime                     #   add a new filter to the cascade

   repeat {
    # num must be a 'known' prime...
      write(prime := num)
    # for performance reasons, it is better to test against small primes
        # early in the cascade.  since the primes are found in increasing
    # order, this next line puts the new filter for the newly discovered
    # prime at the end of the cascade.
      put(cascade, create filter(prime))
    # however, the end of the cascade HAS to remain the sink, so
    # new filter should have gone in just before the sink.  this
    # next line fixes that by moving the sink after the new filter.
      cascade[-2] :=: cascade[-1]
    # restart the source to get the next potential prime started down
    # this new cascade.
      @source
      }

   end

(5) # Each filter does a simple test for relative primeness, then uses the
    #   outcome to either continue the potential prime down the cascade or
    #   to start a new potential prime down the cascade
   procedure filter(prime)              # test to see if num is a multiple
                                        #   of prime
   repeat {
     if num % prime = 0 then @source    # num wasn't prime, get next number.
     else @@nextfilter            # num is still a potential prime.
                    # @nextfilter supplies the next
                    # filter, which is then activated
                    # to test 'num' against its known
                    # prime or, if it's the sink, to
                    # display 'num' and add a new filter.
     }

   end

I hope this helps explain the operation.  Please don't think that this
is an efficient operation - it was written (originally) to show that
some of the behaviour of coroutines could be mimiked using co-expressions.
(If one had a bank of cpus and some syncronizing mechanism, then all the
co-expressions (with minor modifications) could be running in parallel,
with different potential primes being processed by different filters
in the cascade.  The 'sink' would then be adding cpu's into the process.)

It also shows that the call-graph for a program need not be a tree, as
is the case in many languages - the co-expression mechanism allows the
transfer of control among procedures in non-hierarchical form.  (Hmm,
I suppose this could be used to produce one of the world's slowest
finite state machine simulations!)

Again, let me finish by repeating that this is NOT the usual use of
co-expressions, which are remarkably simple devices in themselves.
I think the fact that transfer of control is not hierarchical is what
is causing people the most trouble in understanding how this operates.

Sorry this is so long.

From icon-group-sender  Sun Apr 17 23:49:41 1988
Received: by bocklin.arizona.edu; Sun, 17 Apr 88 23:49:44 MST
Date: 18 Apr 88 02:59:40 GMT
From: [e-mail]  (Mike O'Dell)
Organization: UUNET Communications Services, Arlington, VA
Subject: icon implementation for SUNs
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

Can someone give me a pointer to an implementation
of Icon for SUN workstations (SUN-3/68020 critters)?
We need to do some serious data hacking,
and icon seems to be the best choice.
Is the distribution online somewhere, or is
it voluminous enough that tape is the best way?

    -Mike O'Dell

From icon-group-sender  Mon Apr 18 05:37:45 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 05:37:48 MST
Date: Mon, 18 Apr 88 13:35:52 BST
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - Sun UK TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re: icon implementation for SUNs
Errors-To: icon-group-errors

>From: sunuk!sun!uunet.uu.net!mo  (Mike O'Dell)
>Can someone give me a pointer to an implementation
>of Icon for SUN workstations (SUN-3/68020 critters)?
>We need to do some serious data hacking,
>and icon seems to be the best choice.
>Is the distribution online somewhere, or is
>it voluminous enough that tape is the best way?

v7 appears to work fine on both Sun-3 and Sun-2 hardware.  I have not
yet had time to attempt an implementation for Sun-4, a situation which
is likely to continue indefinitely.

Note that there are implementations named "sun2" and "sun3".  In the
past these referred to operating system version.  However, compiling
the "sun2" version gives you a translation system suitable for both
types of machine - here we run Sun-2 under SunOS 3.0, and Sun-3 under
3.0 and 3.5.  Everything seems to run fine.  Compile "sun2" on a Sun-2
unless you want to fiddle with the CFLAGS to set the machine type.

The "sun3" system won't build on a Sun-2 due to 68020 assembly code
being generated from "rover.c" during the iconx build.

The Icon v7 distribution weighed in at 2519040 bytes - make your own
mind up about a network transfer - that's how it was obtained for me.

Steve Holden                    [e-mail]
Necessity is a mother.            sholden@{sun,sunuk}.uucp

From icon-group-sender  Mon Apr 18 12:09:35 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 12:09:38 MST
Return-Path: <[e-mail]>
Date: Mon, 18 Apr 88 14:03:27 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Still don't understand (thick head?)
Errors-To: icon-group-errors


I still don't quite understand why the following cut-down (hence inane) program
only outputs "A":

procedure main()
  S := create WriteString()
  while write(@S)
end

procedure WriteString()
  SS := create WriteString2()
  while suspend @SS
end

procedure WriteString2()
  every suspend !"AbCdEfGh"
end

I would expect this to do the same thing as:

procedure main()
  S := create WriteString()
  while write(@S)
end

procedure WriteString()
  SS := create WriteString2()
  while s := @SS
  do suspend s
end

procedure WriteString2()
  every suspend !"AbCdEfGh"
end

The only difference here is in the middle procedure, where we have either
while s := @SS do suspend s; or while suspend @SS.  I guess I thought that
they would do the same thing, namely reactivate SS over and over again, until
it fails.  In the first case, the result produced gets assigned to a variable
(s), then the material in the do-clause is evaluated, resulting in the sus-
pension of what SS has just produced.  In the second, case, I would have
thought that the same thing should happen, only in more truncated form, namely
that the expression "suspend @SS" would be repeatedly evaluated, each time
popping another result off of SS, then suspending it - until @SS fails.

This is an extremely silly mistake, I know, but could someone take another
crack at explaining it all to me?  (P.S.  I do know the difference between
every, while, and that coexpressions are not generators [i.e. every @e will
produce one result].  I'm just hitting a blind spot here.)

From icon-group-sender  Mon Apr 18 12:15:57 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 12:16:00 MST
Date: Mon, 18 Apr 88 12:15:35 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  Still don't understand (thick head?)
Cc: icon-group
In-Reply-To: <[e-mail]>
Errors-To: icon-group-errors

The argument of suspend is repeatedly *resumed*, not repeatedly
evaluated.  For an analogy, try

    suspend read()

and see what you get (at most one read).

     Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
     [phone]   [e-mail]     {allegra|noao|ihnp4}!arizona!ralph


From icon-group-sender  Mon Apr 18 12:55:01 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 12:55:07 MST
Date: Mon, 18 Apr 88 12:54:58 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
To: icon-group
Subject: Re:  Still don't understand (thick head?)
Errors-To: icon-group-errors

> Date: Mon, 18 Apr 88 14:03:27 CDT
> From: Richard Goerwitz <[e-mail]>
  ...
> The only difference here is in the middle procedure, where we have either
> while s := @SS do suspend s; or while suspend @SS.
  ...
> In the second, case, I would have
> thought that the same thing should happen, only in more truncated form, namely
> that the expression "suspend @SS" would be repeatedly evaluated, each time
> popping another result off of SS, then suspending it - until @SS fails.

A critical point to notice is that suspend itself always fails after it
has exhasted the generators in its argument. This means that the while
will terminate after the first evaluation of the suspend expression.

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

From icon-group-sender  Mon Apr 18 18:00:55 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 18:00:58 MST
Return-Path: <[e-mail]>
Date: Mon, 18 Apr 88 19:54:55 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  Still don't understand (thick head?)
Cc: [e-mail]
Errors-To: icon-group-errors

So suspend is just like "every" and "while."  For some reason, I had it in
my head that "suspend" just saved all local variables, and returned, then passed
control on to what follows when resumed.

In order to cause resumption of suspend's argument,  I was writing things like

     every suspend

and to bring about repeated evaluation of its argument, I was writing

    every suspend,

and the like.  The fact is that when I wrote "while suspend" I was really get-
ting back what I thought I was getting when I wrote "every suspend"!  In fact,
I needn't have written anything but "suspend."  Writing "every suspend" is as
silly as writing "every every"!

Many thanks to those who helped me hammer this seemingly basic fact out.  I
send this to the icon-group not out of any masochistic desire to embarrass
myself, but because I know not everyone who reads this is an advanced Icon pro-
grammer.  Maybe I'll be able to stop someone else from making a similar mis-
take.

One further question, by the way:  Why is it that the version 7 executables,
though large, do not show much (any?) decrease in performance over their
version 6 counterparts?  In many cases, I could swear that there is even a
speedup.  Although I do not have any old executables arount, it also seems
to me that the .icx files under version 7 are smaller than their version 6
counterparts.  Obviously the move from 6 to 7 involved some major implemen-
tation change:  Could someone clue me in to what is going on here?  Are we
moving closer to compiled code (drool, pant, pant)?

Again, many thanks for the patience....

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Mon Apr 18 18:09:54 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 18:09:56 MST
From: ihnp4!ihcup!pax
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihlpe!orf, /addr=ihnp4!arizona!icon-group
Date: Mon 18 Apr 1988 15:38 cst
End-Of-Header:
Email-Version: 2
X-Postmark: joe.t.hall attrd ihp2b524 55513 3124167285 ihcup!pax
To: arizona!icon-group
Cc: ihlpe!orf
Subject: V7 for SUN3
Ua-Message-Id: <post.pax.Mon 18 Apr 1988 13:21 cst>
End-Of-Protocol:
Content-Length: 378
Errors-To: icon-group-errors

Mike,

It looks like we'll do a SUN3 implementation sometime in the near future
and you could get from that the binary files for the language.  Otherwise,
you'll need the full tape from Arizona.

Joe T. Hall
AT&T Bell Laboratories
200 Park Plaza, Room IHP 2B-524
Naperville, Illinois 60566-7050
USA
ihnp4!ihcup!pax
tel:[phone]
fax: [phone]
tlx:157294384(JTHALL)

From icon-group-sender  Mon Apr 18 18:10:01 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 18:10:06 MST
Date: Mon, 18 Apr 88 18:09:58 MST
From: ihnp4!ihlpf!nevin1
Message-Id: <[e-mail]>
To: arizona!icon-group
Subject: Re: environment variables
Errors-To: icon-group-errors

>The new version of MS-DOS Icon can examine individual environment variables.
>Is it reasonable to add the capability to see ALL the environment variables
>(probably as a list of list, or perhaps as a table)?

If this capability were added to the language (the ability to get all the
environment variables), I would like to see it implemented as a generator.
This built-in generator should return the names of all the environment
variables, since in conjunction with getenv() all the information about the
environment variables can be deduced.

 _ __            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-sender  Mon Apr 18 18:09:57 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 18:10:01 MST
Date: Mon, 18 Apr 88 18:09:55 MST
From: ihnp4!ihlpf!nevin1
Message-Id: <[e-mail]>
To: arizona!icon-group
Subject: Re: Still don't understand (thich head?)
Errors-To: icon-group-errors

>The only difference here is in the middle procedure, where we have either
>while s := @SS do suspend s; or while suspend @SS.  I guess I thought that
>they would do the same thing, namely reactivate SS over and over again, until
>it fails.  In the first case, the result produced gets assigned to a variable
>(s), then the material in the do-clause is evaluated, resulting in the sus-
>pension of what SS has just produced.  In the second, case, I would have
>thought that the same thing should happen, only in more truncated form, namely
>that the expression "suspend @SS" would be repeatedly evaluated, each time
>popping another result off of SS, then suspending it - until @SS fails.

In Icon, the value of 'suspend' is fail.  If you try the following program:

    procedure main()

    nevin := create liber()
    write(@nevin)
    write(@nevin)

    end


    procedure liber()

    x := 1
    x := suspend 3
    return x

    end

you get:

    3
    1

which means that the assignment 'x := suspend 3' failed, which can only
happen if the value of 'suspend' is fail.  This is why
'while suspend @s' and 'while ss := @s do suspend ss' are not equivalent;
the former goes until 'suspend' fails (which is just as the procedure is
resumed @s) but the latter goes until 'ss := @s' fails.

If you look at a TRACE of your first program, you will see that
WriteString() fails just after it is reactivated; it does not call
WriteString2() a second time.

Hope this helps,

 _ __            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-sender  Mon Apr 18 18:20:17 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 18:20:22 MST
Date: Mon, 18 Apr 88 18:20:14 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
To: icon-group
Subject: getting all environment variables
Errors-To: icon-group-errors

As noted, a generator is the natural mechanism for
generating a sequence of values.  It could take the
form of a keyword:  &environment (or some other suitable
name).

     Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
     [phone]   [e-mail]     {allegra|noao|ihnp4}!arizona!ralph


From icon-group-sender  Mon Apr 18 21:40:31 1988
Received: by bocklin.arizona.edu; Mon, 18 Apr 88 21:40:34 MST
Date: Mon, 18 Apr 88 21:40:29 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
To: icon-group
Subject: v7 performance
Errors-To: icon-group-errors


> Date: Mon, 18 Apr 88 19:54:55 CDT
> From: Richard Goerwitz <[e-mail]>
>
> One further question, by the way:  Why is it that the version 7 executables,
> though large, do not show much (any?) decrease in performance over their
> version 6 counterparts?  In many cases, I could swear that there is even a
> speedup.  Although I do not have any old executables arount, it also seems
> to me that the .icx files under version 7 are smaller than their version 6
> counterparts.  Obviously the move from 6 to 7 involved some major implemen-
> tation change:  Could someone clue me in to what is going on here?  Are we
> moving closer to compiled code (drool, pant, pant)?

Most of the increase in the size of iconx in version 7 is due to additional
features. If these features are not being used they do not affect
performance. There have been a number of changes which can affect
performance. Some probably slow things down while others may speed things
up a little. I wouldn't expect much change in performance for most programs.
I just compared the sizes of a couple i-code files produced by Version
6 and Version 7 under Unix on a Vax. I came up with larger files
under Version 7. The changes to the implementation in Version 7 are
to implement the new features, fix some bugs, and make it a little
easier to port. It does not represent movement toward a compiler.

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

From icon-group-sender  Sun Apr 24 16:29:49 1988
Received: by bocklin.arizona.edu; Sun, 24 Apr 88 16:29:51 MST
Date: Sun, 24 Apr 88 16:27:57 PDT
From: [e-mail] (William Griswold)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: object oriented Icon
Errors-To: icon-group-errors


I've been thinking about building an object-oriented version of Icon using
variant translators (and maybe some minor mods to icont/iconx).  Does anybody
know of anyone who has tried to do this?  Any opinions on such an attempt?

                           Bill Griswold
                        [e-mail]


From icon-group-sender  Mon Apr 25 02:31:45 1988
Received: by bocklin.arizona.edu; Mon, 25 Apr 88 02:31:48 MST
Date: Mon, 25 Apr 88 02:31:31 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Subject: object oriented Icon
Errors-To: icon-group-errors

What do you mean by "object-oriented"?  I can think of at least two
different definitions that might apply here...

From icon-group-sender  Mon Apr 25 02:47:23 1988
Received: by bocklin.arizona.edu; Mon, 25 Apr 88 02:47:26 MST
Date: Mon, 25 Apr 88 02:45:21 PDT
From: [e-mail] (William Griswold)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  object oriented Icon
Cc: [e-mail]
Errors-To: icon-group-errors

    From: "David Gudeman" <[e-mail]>
    To: [e-mail]
    Cc: [e-mail]
    Subject: object oriented Icon
    Status: R

    What do you mean by "object-oriented"?  I can think of at least two
    different definitions that might apply here...

I'll tell you what I think if you'll tell me what you want or what you'd
expect.

Basically, I'm talking about a language that supports:

    1) Inheritance
       The language should have a powerful way to relate the datatypes
       used in a program, both in type definition and during execution.

    2) Encapsulation
       It should be possible to describe a type in terms of the "behavior"
       of a set of operations, hiding the representation of the type.

    3) Objects as first-class citizens
       Instances of a type should be dynamically instantiable with
       independent state, valid as arguments to procedures, and
       returnable from procedures as values.

These ideas are demonstrated in languages such as Smalltalk, C++, and DEC's
Trellis/Owl, with minor variations and additions.

Icon currently does not support the first two design goals.  Languages such
as Ada and Modula do not meet the third design goal.

An object-oriented language could certainly support more or less than these
features.  Many of the design decisions would be influenced by Icon.  For
example, I would not suggest supporting static (sub)typing, which many modern
OO languages support.  But I am considering allowing user-definition of Icon
operators.

                        Bill Griswold


From icon-group-sender  Mon Apr 25 22:33:55 1988
Received: by bocklin.arizona.edu; Mon, 25 Apr 88 22:33:58 MST
Date: Mon, 25 Apr 88 22:31:39 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: icon-group
In-Reply-To: <[e-mail]>
Subject:  object oriented Icon
Errors-To: icon-group-errors

I think inheritance and encapsulation are good ideas, but I don't like
it when they dominate the language.  In SmallTalk you sometimes have
to do strange things like create imaginary types just to write a
procedure.  SmallTalk-with-generators wouldn't appeal to me very much,
but if you're just talking about adding a type structure to Icon and
implementing modules of some sort, I'd really like see it.

From icon-group-sender  Tue Apr 26 08:58:40 1988
Received: by bocklin.arizona.edu; Tue, 26 Apr 88 08:58:44 MST
Date: Tue, 26 Apr 88 08:55:34 PDT
From: Michael Shafto <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  object oriented Icon
Cc: [e-mail], [e-mail]
Errors-To: icon-group-errors

I would like to second Dave's comments and add one:  I had some
experience with LOOPS on early D-Machines; it was "built on top of"
Interlisp-D, an ugly and ineffective amalgam, to say the least.

I would actually like to see (easy for me to say, since no way
I'm going to be involved in implementing it!) an Icon-like language
(Icob?) which is built from the ground up to be an object-oriented
language, leaving out features of Icon that don't strongly support
or easily fit in with object-oriented programming.

No use creating the PL/1 of symbolic computing.  Better to create an
option which can be chosen for tasks that fit the object-oriented
paradigm.  I agree with Dave that object-oriented programming
(like logic programming) is good for what it's good for, but not
as an all-purpose framework.

Mike Shafto

From icon-group-sender  Tue Apr 26 12:56:18 1988
Received: by bocklin.arizona.edu; Tue, 26 Apr 88 12:56:21 MST
Date: Tue, 26 Apr 88 12:56:17 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: icon-group
In-Reply-To: <[e-mail]>
Subject:  object oriented Icon
Errors-To: icon-group-errors

Gee, I hate to do this when Mike was nice enough to agree with me, but
I'm afraid he missed my point and actually wants the opposite of what
I would like to see.  It was probably my own fault for being terse.
What I meant to say was that I don't like the idea of making Icon into
an OBJECT ORIENTED LANGUAGE or designing a new object oriented
language that is similar to Icon.  The problem with this approach is
exactly what Mike Shafto pointed out: "... object-oriented programming
(like logic programming) is good for what it's good for, but not as an
all-purpose framework".

Logic languages, object-oriented languages, pure functional languages,
constraint languages, etc., all suffer from this problem of being
really good for some things and really poor for other things.  I still
have faith that it is possible to design a language that is really
good for everything.  Icon is closer to that goal than most other
languages, and I think inheritance and better modularity would move it
closer to the goal.  But don't take out other important features while
you are doing it.

On the other hand, I don't like the idea of huge languages, I think
the perfect programming language will be quite simple and elegant when
we find it (maybe next year), but for now, it looks like adding
features and not removing any is the best way to go.  Of course I am
speaking as a person who doen't mind learning new software.  For that
large percentage of the population who don't like to learn new
software, adding features probably isn't as acceptable.

From icon-group-sender  Wed Apr 27 06:27:53 1988
Received: by bocklin.arizona.edu; Wed, 27 Apr 88 06:27:56 MST
Date: 27 Apr 88 07:27:39 GMT
From: [e-mail]  (Clinton Jeffery)
Organization: U of Arizona CS Dept, Tucson
Subject: Re: object oriented Icon
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

From article <[e-mail]>, by [e-mail]:
> "... object-oriented programming (like logic programming) is good
> for what it's good for, but not as an all-purpose framework".

In my ignorance, this is not at all clear to me.  In fact, I would state
the opposite--object oriented programming is a wonderful all-purpose
framework.  Smalltalk may be a specialized world unto itself, and it may
run dog-slow, but it is the FORTRAN of object-oriented languages...
At any rate, Dave, I would appreciate it if you or the original writer
would provide some support for this assertion.
--
| Clint Jeffery, University of Arizona Department of Computer Science
| [e-mail] -or- {ihnp4 noao}!arizona!cjeffery
--

From icon-group-sender  Wed Apr 27 08:39:19 1988
Received: by bocklin.arizona.edu; Wed, 27 Apr 88 08:39:22 MST
Date: Wed, 27 Apr 88 08:36:18 PDT
From: Michael Shafto <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: object oriented Icon
Cc: [e-mail]
Errors-To: icon-group-errors


>>From article <[e-mail]>, by [e-mail]:
>> "... object-oriented programming (like logic programming) is good
>> for what it's good for, but not as an all-purpose framework".

>In my ignorance, this is not at all clear to me.  In fact, I would state
>the opposite--object oriented programming is a wonderful all-purpose
>framework.  Smalltalk may be a specialized world unto itself, and it may
>run dog-slow, but it is the FORTRAN of object-oriented languages...
>At any rate, Dave, I would appreciate it if you or the original writer
>would provide some support for this assertion.

As the original writer, I feel I should respond, however briefly:
I don't think personal opinions about programming languages should
extend to proselytizing (for or against).  To anyone who loves
Prolog, APL, Smalltalk, SNOBOL4, or (even) Lisp, I say:  "Right
on."  For the kinds of problems I have to deal with, which are
pretty mundane, and given my own background, which is pretty
mundane, I find the frameworks of both Smalltalk and Prolog
unnatural and awkward.  For certain kinds of database stuff,
Prolog is just the ticket.  I know people who have found Smalltalk
ideal for modeling physical systems made up of components which
communicate by sending and receiving messages.  But evaluating
3+5 by sending the message "add 5" to the object 3?  I repeat, it's
not my goal to start a debate on the merits of Smalltalk, but
personally I don't consider it a general-purpose programming
language.

Mike Shafto


From icon-group-sender  Wed Apr 27 12:26:25 1988
Received: by bocklin.arizona.edu; Wed, 27 Apr 88 12:26:28 MST
Date: Wed, 27 Apr 88 12:23:59 PDT
From: [e-mail] (William Griswold)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: object oriented Icon
Errors-To: icon-group-errors

This message is in response to the many messages I have received
concerning the design of an ``object-oriented'' Icon.

The type of object-orientation I'm talking about wouldn't incorporate
the quirks of Smalltalk:  no message passing or anything like that.  In
fact it would have the quirks of Icon.  Expression evaluation and all
that would stay the same.

The type of object-oriention I intend for Icon would support
ADT-oriented (i.e., typed) modules, with the added kick of procedure
fields in values in order to keep track of the operations that can
manipulate the value.  But of course there is the type structure
among the modules that allows sharing of operations in implementation
and execution....

I don't intend to remove any features of Icon, nor make old programs
incompatible.  If you have a ten line program to write there will be
no need or requirement to use the object-oriented features.

Thanks for all your feedback!

                    Bill Griswold

From icon-group-sender  Wed Apr 27 18:21:54 1988
Received: by bocklin.arizona.edu; Wed, 27 Apr 88 18:21:57 MST
Date: Wed, 27 Apr 88 18:21:52 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: icon-group
In-Reply-To: <[e-mail]>
Subject: object oriented languages
Errors-To: icon-group-errors

Clinton asked for some support for my assertion that object oriented
languages are not a good all-purpose framework.  First, I would like
to say what I think a strict object oriented language is: it is a
language where the single model of computation is that of objects and
message passing.  That _isn't_ what Bill Griswold meant by "object
oriented Icon", as he made clear in his reply to my reply to his
original message.

I believe that the term "object oriented" has aquired another meaning,
Bill's meaning, originally as a misunderstanding.  In fact, the
hierarchical representation of data is seperable from the object
oriented paradigm, and what Bill wants to do is include this seperable
part of object oriented languages into Icon.  A pure object oriented
language wouldn't even have to have to have this hierarchical
organization.  I never meant to say that hierarchical organization is
not a good general purpose framework, but it is not a paradigm of
computation in and of itself.  It is only a way to structure data and
programs.

A paradigm of computation is a model of what we mean by "program".  An
assembly language program consists of a set of instructions put
together into a proceedure for getting the answer.  I call this the
proceedural paradigm.  An FP program consists of an expression that
represents the answer.  I call this the functional paradigm.  A
Smalltalk program consists an expression that represents messages
being passed to objects, where one of the objects sends the answer
back to the user.  I call this the object oriented paradigm.

I maintain that no single one of these paradigms is good for all types
of problems.  Any general-purpose language should support several
paradigms so that the programmer can write in whatever paradigm the
problem calls for, and doesn't have to force the problem into a
paradigm that is not natural for it.  Note that Icon contains all of
these paradigms: an assignment is an instruction, a monogenic
operation (like a + b) is an expression, and transmission to a
co-expression is message passing.

From icon-group-sender  Thu Apr 28 00:40:40 1988
Received: by bocklin.arizona.edu; Thu, 28 Apr 88 00:40:43 MST
Date: Thu, 28 Apr 88 00:38:40 PDT
From: [e-mail] (Manu Dibango)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  object oriented languages
Errors-To: icon-group-errors

This is in response to David Gudeman's message concerning what he
considered to be the core of object-orientation:

Historically, you will find that a large number of those languages that
are considered object-oriented are not message-passing languages.  Some
that I know of are Simula, C++, and Trellis/Owl.  I contend that this
is more than an accident.

I think it is better to think of an OO language as supplying a set of certain
capabilities rather than a particular design supporting those capabilities, or
even a way of thinking about them.  For example:

(You could quibble with me here about the following definitions.  They aren't
intended to be fully accurate.)

"x + y" can mean "send the message `+ y' to `x'"    (Smalltalk)
         "apply `x''s `+' operator `x' and `y'"    (Owl)

These ways of describing "x + y" are equally valid as ways of thinking
about the computation, and they are equally valid ways of implementing the
computation.  There needn't be any relationship between the thought model and
the implementation (as long as you don't run into inconsistencies).

Object orientation means to me that a value knows what can be done to it, and
will do it when asked to.  It implies a close binding of state and the
operations that can manipulate that state.  This close binding also permits
an operation to directly manipulate the state of the object from which it
was selected.  For example "matrix1.transpose()" might change the value of
matrix1 so that it is the transpose of its previous value.

Note that this particular syntax suggests the operation is being selected
from matrix1 as a field in a record.  It corresponds to the second example
above.  In some systems it is actually implemented this way.  Theoreticians
think about it this way, too.

I agree that object orientation is not a full programming paradigm.  In the
literature I have seen the model consistently used in a message-passing
framework, a procedural framework, and in a functional framework as well.
The last prohibits an operation from *changing* a value, but not creating a
new one.  Thus object orientation has something to offer every model.

OO starts to involve structuring of the name space, since different types can
have like-named operations.  You soon discover that like-named operations
often have similar semantics, and even implementations, so you'd like to
share them.  Once you admit to some sort of structuring and sharing, you
might as well go the whole way to hierarchical structuring, in my opinion,
though there are certainly systems which do not.  Object orientation easily
admits such a scheme because each value knows what a particular operation
name means to it.  So although OO does not imply such a type structure, it
yields it effortlessly.

There are many details that I have omitted, but I hope you get the central
idea that I am driving at:  I don't mean to suggest that anybody's model
of OO is wrong, just that very likely it is compatible with mine.


                    Bill Griswold

From icon-group-sender  Thu Apr 28 05:02:00 1988
Received: by bocklin.arizona.edu; Thu, 28 Apr 88 05:02:05 MST
Date: Thu, 28 Apr 88 05:01:58 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
To: icon-group
Subject: Forwarded Mail
Errors-To: icon-group-errors


I am sending along the following mail, which is self-explanatory.
====================================================================

   Re: Icon user-community and Icon-project resources.

   Yes, indeed I do realize that you have limited resources.  In fact, I am
   amazed at how much you can get done, given your circumstances.  The help
   you offer your user community, and the quality of your implementations
   (few bugs) leads many, I would think, to treat Icon like a commercially-
   supported product.  The few bug-reports we see are often worded like com-
   plaints to a major software house about one of their top products!

   This is not to belittle Icon itself, mind you.  I suspect that, even if
   you people were less professional, Icon would still be useful to a lot
   of individuals.  Frankly, I have little knowledge of the theoretical is-
   sues that motivated Icon's development.  I use it because it is simple
   and powerful, and well-suited to text-manipulation.  Occasionally, I hear
   people complain that no decent debugger is available for it.  This gives
   me a chuckle, because I make such few errors when programming in Icon.
   Big programs I write often compile and run without serious error.  In C,
   on the other hand, I usually walk away from first-time tries at compiling
   programs, so that I don't have to watch the error messages that inevitably
   appear.

   One matter that came up in the context of this discussion, by the way, was
   the question of maintaining upward-compatibility.  I know that I, as many
   others, have some very large directories full of Icon programs that would
   be a pain to alter.  However, I would rather give you folks a free hand in
   developing the language in as elegant and consistent fashion as seems use-
   ful.  If you want to add a feature - say the limited application of dynamic
   variables, or something else that might present compatibility problems - I
   would rather that you did it than worry about miffing users.  After all, one
   of the joys of Icon right now is that it is not a commercial product.  It is,
   in a sense, still in development.  I feel very strongly that you people
   should be free to refine the language while its definition remains in your
   hands.

   If you think it appropriate (this I leave in your hands), please send a copy
   of this over to the Icon-group to be distributed.  I would be very interested
   in knowing whether others feel as I do.

                                                 -Richard L. Goerwitz
                                                 [e-mail]
                                                 !ihnp4!gargoyle!sophist!goer


================================================================================
     Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
     [phone]   [e-mail]     {allegra|noao|ihnp4}!arizona!ralph


From icon-group-sender  Thu Apr 28 11:26:31 1988
Received: by bocklin.arizona.edu; Thu, 28 Apr 88 11:26:34 MST
Date: Thu, 28 Apr 88 11:25:29 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: icon-group
In-Reply-To: <[e-mail]>
Subject:  object oriented languages
Errors-To: icon-group-errors

This seems like a good time to admit that I'm really not that familiar
with the history of OO programming, so my belief that the term has
changed meaning is not that well-founded.  I'll accept your definition
with the proviso that my previous remarks about OO programming applied
to _my_ definition of the term.

One question though, your last message implied that "object oriented"
just means that the language has operator overloading, and the
hierarchical organization is not necessary.  This means that Algol68
is object oriented.  Is that right?

From icon-group-sender  Thu Apr 28 15:18:08 1988
Received: by bocklin.arizona.edu; Thu, 28 Apr 88 15:18:11 MST
From: Jeff Dalton <[e-mail]>
Date: Thu, 28 Apr 88 22:59:18 bst
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  object oriented languages
Cc: [e-mail]
Errors-To: icon-group-errors

> Date: Thu, 28 Apr 88 11:25:29 MST
> From: David Gudeman <[e-mail]>
> Subject: object oriented languages
>
> One question though, your last message implied that "object oriented"
> just means that the language has operator overloading, and the
> hierarchical organization is not necessary.  This means that Algol68
> is object oriented.  Is that right?

Some (e.g., Peter Wegner in his OOPSLA '87 paper) say

     object-oriented = objects + classes + inheritance

I would say this is too restrictive.  Anyway, Algol 68 doesn't really
have objects, although heap allocated structures might do.

From icon-group-sender  Thu Apr 28 15:20:58 1988
Received: by bocklin.arizona.edu; Thu, 28 Apr 88 15:21:02 MST
Date: Thu, 28 Apr 88 15:19:13 PDT
From: [e-mail] (William Griswold)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: object-oriented Icon
Errors-To: icon-group-errors


A lot of the recent messages directed at me have concerned the nature
of object orientation, rather than of (object oriented) Icon.  In order
to avoid flooding the network (and my mailbox!), there is a paper I can
recommend:

L. Cardelli, P. Wegner, "On Understanding Types, Data Abstraction, and
Polymorphism", ACM Computing Surveys, Vol. 17, No. 4, Dec.  1985.

In my opinion, it is an excellent survey of the work in the areas of
polymorphism and object orientation.  It is very readable, unlike some
stuff in this area.  They say it much better than I could, if less
succinctly.

                        Bill Griswold

From icon-group-sender  Thu Apr 28 15:30:24 1988
Received: by bocklin.arizona.edu; Thu, 28 Apr 88 15:30:28 MST
From: ihnp4!ihuxy!nowlin
Message-Id: <[e-mail]>
Message-Version: 2
>To: /addr=ihnp4!arizona!icon-group
Date: Thu 28 Apr 1988 17:05 CDT
End-Of-Header:
Email-Version: 2
X-Postmark: jerry.d.nowlin attrd ix1c461 55621 3129790441 ihuxy!nowlin
To: arizona!icon-group
Subject: Re: object oriented Icon
Ua-Message-Id: <post.nowlin.Thu 28 Apr 1988 16:41 CDT>
End-Of-Protocol:
Content-Length: 1497
Errors-To: icon-group-errors

I know less about OOP then I care to let on...but.  It would seem to me
that Icon already lends itself to this kind of programming without even
adding anything to the language.

I've written programs that manipulate lists of records that contains fields
that are additional lists or procedures to operate on other fields in the
records.  By careful programming you can have values in a list take
advantage of other values in the same list or of values in the list that
contains the list their in.  This same scheme can be carried on as many
levels deep as you want to go.

The difficulty is in knowing about the list you're a member of.  It is not
by any means automatic.  This makes schemes like inheritance difficult to
implement but not impossible and certainly much easier than with languages
like ordinary C.

I have a feeling from my C++ experience (minimal) that there aren't may
things I would want to do in C++ instead of Icon either.  Even if the tasks
really fit the C++ model well.  Icon is just much more intuitive to
formulate solutions with and certainly easier to program in.

If you concentrate on the "object" in OOP, Icon has all the data types you
need to get started.  Adding built-ins to make inheritance more intuitive
(like C++) would be nice but I get by.  Some of the other things about C++
are more like bells&whistles then real necessities of OOP.  For example,
constructors and destructors are nice but are they needed for OOP?

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

From icon-group-sender  Fri Apr 29 03:19:02 1988
Received: by bocklin.arizona.edu; Fri, 29 Apr 88 03:19:06 MST
Date: Fri, 29 Apr 88 11:15:48 BST
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - Sun UK TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re: object oriented Icon
Errors-To: icon-group-errors

"David Gudeman" <sunuk!sun!arizona.edu!gudeman> wrote:

> I still have faith that it is possible to design a language that is
> really good for everything

Well, how about English?  If we can't achieve a satisfactory universal
for direct person-person communications do we stand any chance in the
world of programming languages?  Then there are the questions of taste
in  progr am m ing style, etc.

[Sorry, my spacekey                                 just         started
to jam,i"ll      g et    back tothis    later!!!!!]

Steve

From icon-group-sender  Fri Apr 29 11:26:55 1988
Received: by bocklin.arizona.edu; Fri, 29 Apr 88 11:26:57 MST
Date: Fri, 29 Apr 88 11:26:51 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: icon-group
In-Reply-To: <[e-mail]>
Subject: object oriented Icon
Errors-To: icon-group-errors

The analogy with English is not good for three reasons.  First English
was not designed, it evolved.  Second, English is not a formal system
with fixed rules for using it (yes, they be rules, but them rules if
freely violated, they do prevent not the understanding). Third,
English is used for more complex purposes than programming.

The last point prompts me to make the following restriction to my
earlier claim that

    > I still have faith that it is possible to design a language that
    > is really good for everything

"Everything" here means everything that universal programming
languages are typicaly used for.  It is not practical to ask a single
programming language to do everything that computers can do.

From icon-group-sender  Fri Apr 29 16:59:42 1988
Received: by bocklin.arizona.edu; Fri, 29 Apr 88 16:59:46 MST
Date: 29 Apr 88 03:17:25 GMT
From: [e-mail]  (Clinton Jeffery)
Organization: U of Arizona CS Dept, Tucson
Subject: Re:  object oriented languages
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

From article <[e-mail]>, by [e-mail] (Manu Dibango):
> There needn't be any relationship between the thought model and
> the implementation (as long as you don't run into inconsistencies).

I just want to repeat one beautiful sentence from an excellent article.
As long as I can write "x+3", and get an ADD.L instruction, I want as
much support for abstractions as I can get!  Now, what I really want to
know, Bill, is: WHO IS MANU DIBANGO?!

Clint Jeffery
--
| Clint Jeffery, University of Arizona Department of Computer Science
| [e-mail] -or- {ihnp4 noao}!arizona!cjeffery
--

From icon-group-sender  Sun May  1 14:51:49 1988
Received: by bocklin.arizona.edu; Sun, 1 May 88 14:51:52 MST
Date: 1 May 88 00:24:09 GMT
From: [e-mail]  (Mark C. Carroll <[e-mail]>)
Organization: Rutgers Univ., New Brunswick, N.J.
Subject: Re: object oriented Icon
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

This is in response to someone basically stating that they don't like
object oriented programming as a general purpose framework. I just
want to preface this with the fact that I have NEVER used an OOL. I've
read quite a lot about them, and consider them a wonderful idea, but I
may have severe misconceptions. Please correct me if I foul up. On
to my comments:

]             I know people who have found Smalltalk
]]ideal for modeling physical systems made up of components which
]communicate by sending and receiving messages.  But evaluating
]3+5 by sending the message "add 5" to the object 3?

    I think you've missed to whole idea of object oriented
programming. The real idea isn't that you evaluate 3+5 by sending
the message "add 5" to 3. It's that no matter WHAT type 3 and 5 are,
you can ALWAYS use +. The beauty of OOLs is the fact that types are
not quite as "significant" ( Wrong word I know, but it gets my general
idea across). As an example, look at sorting. We'll use the < operator
rather than +. I can write a simple sort procedure in an OOL, and the
SAME code will work for integers, strings, cardinals, floats, and just
about anything else where I define the < comparison. The advantage
isn't because it's sending a comparison message, it's because the
comparison function to the data type, so I can use it on ANY data type
with the comparison function bound to it.

] I repeat, it's
]not my goal to start a debate on the merits of Smalltalk, but
]personally I don't consider it a general-purpose programming
]language.
]
    I don't know if smalltalk is a good GP language. I expect it
is NOT. But some aspects of it's philosophy are certainly useful for
nearly any application. I honestly can't think of any situation where
it would become a disadvantage to have the ability to bind function
calls to data types, which is what I see as the primary advantage of
OOLs.


]Mike Shafto

        <MC>

    by the way, how do I send followups to comp.lang.misc? That's
where they belong, but I honestly don't know how. Sorry!
--
<MC>=Mark C. Carroll,Rutgers CS Student| I won't wear your white feather
mail to: ARPA: [e-mail] | I won't carry your white flag
   UUCP: [e-mail]    | I will swear to have no nation
   (backbone)!rutgers!topaz!mccarrol   | But I'm PROUD to hold MY heart

From icon-group-sender  Sun May  1 23:11:33 1988
Received: by bocklin.arizona.edu; Sun, 1 May 88 23:11:38 MST
Date: Sun, 1 May 88 23:10:55 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: [e-mail]  (Mark C. Carroll's message of 1 May 88 00:24:09 GMT <[e-mail]>
Subject: object oriented Icon
Errors-To: icon-group-errors

   From: Mark C. Carroll

   This is in response to someone basically stating that they don't like
   object oriented programming as a general purpose framework...

       I think you've missed to whole idea of object oriented
   programming. The real idea isn't that you evaluate 3+5 by sending
   the message "add 5" to 3. It's that no matter WHAT type 3 and 5 are,
   you can ALWAYS use +.

I think this is exactly the problem.  The term "object oriented" seems
to imply more than just a hierarchy of types and operator overloading,
so a lot of people (including myself) assume that it refers to the
message-passing paradigm.  Obviously most people _are_ only refering
to the type organization and operator overloading, so those of us who
take things too literally will just have to adjust.  I have always
prefered operator overloading to Icon's multiple operators, but Ralph
Griswold feels otherwise (or did when Icon was designed).

   ... I honestly can't think of any situation where it would become a
   disadvantage to have the ability to bind function calls to data
   types...

This would be a disadvantage is if the _only_ way to create a function
is to make it part of a data type, but Bill said he doesn't intend to
do this.

   ... by the way, how do I send followups to comp.lang.misc? That's
   where they belong, but I honestly don't know how. Sorry!

Normally I would agree, but there is so little traffic on this group
that I really don't think anyone will complain if the discussion goes
a little far afield.

From icon-group-sender  Sun May  1 23:26:19 1988
Received: by bocklin.arizona.edu; Sun, 1 May 88 23:26:22 MST
Date: Sun, 1 May 88 23:26:17 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
To: icon-group
In-Reply-To: <[e-mail]>
Subject: Icon group
Errors-To: icon-group-errors

   Date: Sun, 1 May 88 23:10:55 MST
   From: "David Gudeman" <gudeman>

(Yes, I'm replying to my own message.  Something I said struck a
chord, probably because I think a lot like myself.  Also, I talk too
much.)

>  ... there is so little traffic on this group that I really don't
>  think anyone will complain if the discussion goes a little far
>  afield.

Which brings up an interesting point.  Why is there so little traffic
on this group?  Surely it's not because there isn't much to say about
Icon.  The Icon-project gets a lot of mail that would be interesting
to Icon group, why isn't it sent there?  A lot of people are doing
interesting work in Icon that I would like to hear about, and a lot of
people are doing research on Icon that I would like to hear about.  So
far Bill Griswold is the only one who has really talked about research
in this forum.

I thought it showed a lot of guts, leaving himself wide open for a
thousand suggestions about how to do Object Oriented Icon.  He got a
few, but I would have liked to see more (whether Bill wanted to see
more is an open question).

From icon-group-sender  Wed May  4 04:08:35 1988
Received: by bocklin.arizona.edu; Wed, 4 May 88 04:08:41 MST
From: Gordon Joly <[e-mail]>
Date: Wed, 4 May 88 09:35:28 BST
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  object oriented languages
Errors-To: icon-group-errors

>
>                                             Now, what I really want to
>know, Bill, is: WHO IS MANU DIBANGO?!
>
>Clint Jeffery
>--
>| Clint Jeffery, University of Arizona Department of Computer Science
>| [e-mail] -or- {ihnp4 noao}!arizona!cjeffery
>--
>
To the list and Clint,
A musician of note, of course.
Gordon Joly.

From icon-group-sender  Fri May  6 04:43:22 1988
Received: by bocklin.arizona.edu; Fri, 6 May 88 04:43:25 MST
Return-Path: <[e-mail]>
Date: Fri, 6 May 88 05:25:34 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: user-defined control-structures
Errors-To: icon-group-errors

Thanks to everyone who posted on coroutines.  The prime number sieve was the
most useful.  After reading it, and then the explanation that came a week or
so later, I went out and started using coroutines as if I had been using them
from the very beginning.  I can't see how I lived without them!

Now I have another query:  How is it exactly that one defines ones own control
structures?  There is a technical report out on this, I know.  Does someone
have some simple examples of how these can be of use in everyday programming?

Last query:  Has anyone ever toyed with the idea of having entire loop-struc-
tures return values (the last value produced before termination either by
failure of the expression or by a break or return expression)?

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Fri May  6 13:20:15 1988
Received: by bocklin.arizona.edu; Fri, 6 May 88 13:20:18 MST
Date: Fri, 6 May 88 13:20:13 MST
From: ihnp4!ihlpf!nevin1
Message-Id: <[e-mail]>
To: arizona!icon-group
Subject: C++ and Icon (was: object oriented Icon)
Errors-To: icon-group-errors

With all this talk of adding object-oriented extensions to Icon, let me
propose a different approach.

Since C++ is already an object-oriented language (I really don't want
to get into the debate on whether this is true or not; for this
discusssion, please assume that it is), why not start out by adding
Icon extensions to C++ (starting with the Icon types and defining the
operators so that they act as close to Icon as possible).  We would
then have a language which is like Icon and also allows object-oriented
features such as data abstraction and encapsulation.

I do realize that all of the Icon features cannot easily be
incorporated into C++ (generators, for example, would probably be very
tough to implement, although I know that Tim Budd did a little research
into adding them to C.  Personally, I would hate to give up this
feature), but this would allow us a rather straight forward way of
seeing whether or not the object-oriented programming paradigm would be
a useful extension to Icon.  If it is, we can then propose a useful
syntax for adding it to Icon.  If not, maybe all those people who
really want Icon compilers would be able to use the Icon extensions in
C++ as a substitute.

--
 _ __            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-sender  Fri May  6 14:09:49 1988
Received: by bocklin.arizona.edu; Fri, 6 May 88 14:09:52 MST
Date: Fri, 6 May 88 14:04:53 PDT
From: [e-mail] (William Griswold)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  C++ and Icon (was: object oriented Icon)
Errors-To: icon-group-errors


This message is in response to:
    From: ihnp4!ihlpf![e-mail]
    Date: Fri, 6 May 88 13:20:13 MST

    Since C++ is already an object-oriented language (...), why not start
    out by adding Icon extensions to C++ (starting with the Icon types
    and defining the operators so that they act as close to Icon as
    possible).  We would then have a language which is like Icon and also
    allows object-oriented features such as data abstraction and
    encapsulation.

    I do realize that all of the Icon features cannot easily be
    incorporated into C++ (generators, for example, would probably be
    very tough to implement, although I know that Tim Budd did a little
    research into adding them to C.  Personally, I would hate to give up
    this feature), but this would allow us a rather straight forward way
    of seeing whether or not the object-oriented programming paradigm
    would be a useful extension to Icon.  If it is, we can then propose a
    useful syntax for adding it to Icon.  If not, maybe all those people
    who really want Icon compilers would be able to use the Icon
    extensions in C++ as a substitute.

I'm afraid that Icon is sufficiently different from C++ that you
would not find it worthwhile to get C++ to do things the Icon way.
It's not just generators, but the entire expression evaluation
mechanism of Icon that would need to be implemented.  Before
considering doing this, consider implementing PROLOG expression
evaluation in C++, or LISP's LAMBDA expressions.

There are many avenues for trying OO in Icon.  I have a number of
techniques that would take a day or so, one or two that would take a
week, and a complete implementation that would take longer.  I feel
no need to prototype in C++, when I can prototype in Icon so easily
(having garbage collection, dynamic typing, fast compilation,
tracing, expression stack dumps, etc.).  The presence of the variant
translator facility distributed with Icon also makes Icon an attractive
place to prototype.

I'll stick my neck out and say some enhancement of the encapsulation
and abstraction mechanisms in Icon *must* be a useful addition.
These are intellectual mechanisms that are thousands of years old and
used in numerous disciplines.  OO is one manifestation (and one of
the most general) of such mechanisms in programming languages.

For these reasons I see no reason to not work directly with Icon.  I
should mention that the techniques used in the implementation of C++
are familier to me, and would be used in part in any design and
implementation of an OO Icon that I would undertake.

Thanks again for all your input!

                    Bill Griswold


From icon-group-sender  Fri May  6 14:10:44 1988
Received: by bocklin.arizona.edu; Fri, 6 May 88 14:10:47 MST
Date: Fri, 6 May 88 14:10:36 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
To: icon-group
Subject: Re:  C++ and Icon (was: object oriented Icon)
Errors-To: icon-group-errors

    Date: Fri, 6 May 88 13:20:13 MST
    From: ihnp4!ihlpf!nevin1

        ...

    why not start out by adding
    Icon extensions to C++ (starting with the Icon types and defining the
    operators so that they act as close to Icon as possible).  We would
    then have a language which is like Icon and also allows object-oriented
    features such as data abstraction and encapsulation.

    I do realize that all of the Icon features cannot easily be
    incorporated into C++ (generators, for example, would probably be very
    tough to implement, although I know that Tim Budd did a little research
    into adding them to C.

Without generators (or something similar to produce alternates) goal directed
evaluation makes no sense. To my mind, goal directed evaluation, generators,
and the accompanying control structures are the heart of Icon. It is true
that many peaple use Icon because of its high level data structures
and automatic memory management, but these are not the features which
realy distinguish Icon from other languages.

I don't know much about C++; I suspect it would be useful to add
high level data structures to it. However, I am more excited in
seeing what happens when data abstraction and encapsulation are added
to Icon with it generators and control stratagies.

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

From icon-group-sender  Fri May  6 19:34:30 1988
Received: by bocklin.arizona.edu; Fri, 6 May 88 19:34:33 MST
Date: Fri, 6 May 88 19:22:34 mst
From: naucse!sbw (Steve Wampler)
Message-Id: <8805070222.AA25364@naucse>
To: arizona!icon-group
Errors-To: icon-group-errors

Subject: Re:  C++ and Icon (was: object oriented Icon)

Just to muddy the waters...

A long time ago I looked at, and a friend of mine briefly implemented
a facility called 'procs' - a procedure that shared the environment
of the defining procedure (i.e. procs were constructed inside of
procedures).  They had some utility (not much, however) - for one thing,
they could be treated as an abstraction of a thunk and used to implement
pass-by-name parameter passing techniques (much as the &x operator
in C can be treated as an abstraction of pass-by-reference).

However, the implementation was never developed to the point it could
have been.

Now, suppose one extended the idea so that the environment of the
defining procedure existed as long as the procs it defined did.
Presto, encapsulation, internal abstract data types, etc.  For example,
here's a (loosely implemented) stack:

    procedure new_stack()
           local stack_store, push_proc, pop_proc

           stack_store := []    # implement internally as a list

           push_proc := proc(value) {    # pardon the syntax
                           push(stack_store,value)
                           }
           pop_proc  := proc() {
                           return pop(stack_store)
                           }
           return [push_proc,pop_proc]
    end

One could create stacks then with:  (sorry about the names)

    next_stack := new_stack()
    stack_1_push := next_stack[1]
    stack_1_pop  := next_stack[2]

    next_stack := new_stack()
    stack_2_push := next_stack[1]
    stack_2_pop  := next_stack[2]

Or some such nonsense.  I suspect that reimplementing procs (aside
from syntactic arguments) is really just a matter of diddling a bit
with the code for implementing co-expressions, but then again everything
seems easy Friday evening.

From icon-group-sender  Sat May  7 07:41:47 1988
Received: by bocklin.arizona.edu; Sat, 7 May 88 07:41:50 MST
Date: 6 May 88 17:58:53 GMT
From: ihnp4!ihlpf![e-mail]  (00704a-Liber)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Subject: C++ and Icon (was: object oriented Icon)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Errors-To: icon-group-errors

With all this talk of adding object-oriented extensions to Icon, let me
propose a different approach.

Since C++ is already an object-oriented language (I really don't want
to get into the debate on whether this is true or not; for this
discusssion, please assume that it is), why not start out by adding
Icon extensions to C++ (starting with the Icon types and defining the
operators so that they act as close to Icon as possible).  We would
then have a language which is like Icon and also allows object-oriented
features such as data abstraction and encapsulation.

I do realize that all of the Icon features cannot easily be
incorporated into C++ (generators, for example, would probably be very
tough to implement, although I know that Tim Budd did a little research
into adding them to C.  Personally, I would hate to give up this
feature), but this would allow us a rather straight forward way of
seeing whether or not the object-oriented programming paradigm would be
a useful extension to Icon.  If it is, we can then propose a useful
syntax for adding it to Icon.  If not, maybe all those people who
really want Icon compilers would be able to use the Icon extensions in
C++ as a substitute.

--
 _ __            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-sender  Sat May  7 16:10:05 1988
Received: by bocklin.arizona.edu; Sat, 7 May 88 16:10:10 MST
Date: Sat, 7 May 88 16:04:25 PDT
From: [e-mail] (William Griswold)
Return-Path: <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  encapsulation with "procs"
Errors-To: icon-group-errors


Sbw's use of procs to implement encapsulation is very similar to the way
modern lisps such as T implement their version of object orientation.
This is enhanced by the availability of lambda expressions, suggesting
that the "unevaluated expression" facility in Ken Walker's Icon variant
could be useful in this regard (as a generalization of procs).
There are more angles to this OO thing than I had anticipated!

                    Bill Griswold

From icon-group-sender  Mon May  9 11:33:53 1988
Received: by bocklin.arizona.edu; Mon, 9 May 88 11:33:59 MST
Date: Mon, 9 May 88 10:52:00 BST
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - Sun UK TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Object Orientation
Errors-To: icon-group-errors

There are object-oriented _languages_, and object-oriented _systems_.
I would put Simula in the former category (a fixed set of classes
can be used in a program in which they are defined), and Smalltalk-80
in the latter (it has not only encapsulation of procedures within
"packages" and property inheritance to offer subclassing, as does
Simula, it also contains the ability for run-time refinement of the
class hierarchy and is therefore capable of compiling programs).

Surely a weakness of Icon is its inability to create expressions
dynamically, unless anyone has got up to devious tricks I know nothing
of.

An object-oriented system needs to be able to create dynamic procedure
bindings, and to create data objects with procedural values which can
then be executed at a later date [or perhaps millisecond].  Given an
execution abstraction based on a stack, however, it would be possible
to create a minimal set if co-expressions to perform each Icon
operation on a global stack.  It would then be possible to "compile" an
expression into a list of co-expressions which operated sequentially on
the stack.

Object-orientation should, in my opinion, be addable to any language
with "extensible" data structures [Icon tables, PostScript dictionaries]
and the ability to store "expression values" [Icon co-expressions,
PostScript procs].  However, the syntax would not necessarily most
effectively be that of the underlying implementation language.  In an
environment with dynamic procedure binding message-passing somehow seems
the natural way to establish communications between objects, but I can't
see how message sending would fit into the current syntax.

I quote the PostScript parallels because of the (so-called) object-
oriented extensions Sun have provided, implemented in PostScript, as a
part of the NeWS system.  Postscript's being an interpreted language
makes it much easier to add the required abstractions to implement an
object-oriented system rather than simply a language.  This overcomes the
restrictions on richness imposed by the static nature of the class
hierarchy in compiled langauges such as Simula or C++.

To be fair I should point out that not everybody accepts these
extensions as a "good thing", and there seems to be some feeling that
production  graphics languages should leave "fancy tricks" to hard-core
experimental languages [such as Icon?].  Personally I do not regard this
as a religious discussion.


Steve Holden                    [e-mail]
                        sholden@{sun,sunuk}.uucp
"everything seems easy Friday evening."    [Steve Wampler]


From icon-group-sender  Mon May  9 17:32:41 1988
Received: by bocklin.arizona.edu; Mon, 9 May 88 17:32:44 MST
Return-Path: <[e-mail]>
Date: Mon, 9 May 88 18:42:34 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: user-defined control structures
Errors-To: icon-group-errors

I don't remember if I posted on this or not.  If I did, then many apologies.
I owe many thanks to the folks who offered examples of using coexpressions to
do coroutines.  After reading a few letters, I now feel quite comfortable with
them, and in fact can't see how I lived without them.

Has anyone made any use of the capability Icon offers for user-defined control
structures, using the alternate call syntax p{} ?  If so, maybe a word or tow
could be offered to the group on this subject.

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Mon May  9 17:32:44 1988
Received: by bocklin.arizona.edu; Mon, 9 May 88 17:32:48 MST
Return-Path: <[e-mail]>
Date: Mon, 9 May 88 18:34:39 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: creating expressions & procedures on the fly
Errors-To: icon-group-errors

Just a few loose bits of information that might be relevant:

We have seen a few hints about an experimental feature whereby one could
create procedures more elegantly at run-time ("expression data-type" or some-
thing).  I don't recall exactly, and if I say more than this, I'll end up dis-
playing my ignorance for everyone in the group.  Besides, as I understand the
situation, there are no plans to implement it.  Maybe Ken Walker would be kind
enough to explain the issues involved here (he once wrote to me about it, but
I can't find the letter just now).

You know, I was hoping to use the new call-by-string facility to have Icon
programs that essentially extend themselves.  However, the feature seems to
have been written more to facilitate writing other languages in Icon than
to allow for Lisp-like self-extension.  I wonder how difficult it would be
to generalize the call-by-string function to help interconnect programs and
data.  Or would this end up being a useless kludge?

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Tue May 10 15:01:33 1988
Received: by bocklin.arizona.edu; Tue, 10 May 88 15:01:37 MST
Date: Tue, 10 May 88 14:40:34 MST
From: "Kenneth Walker" <kwalker>
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
To: icon-group
Subject: Re:  creating expressions & procedures on the fly
Errors-To: icon-group-errors

> Date: Mon, 9 May 88 18:34:39 CDT
> From: Richard Goerwitz <[e-mail]>
>
> We have seen a few hints about an experimental feature whereby one could
> create procedures more elegantly at run-time ("expression data-type" or some-
> thing).  I don't recall exactly, and if I say more than this, I'll end up dis-
> playing my ignorance for everyone in the group.  Besides, as I understand the
> situation, there are no plans to implement it.  Maybe Ken Walker would be kind
> enough to explain the issues involved here (he once wrote to me about it, but
> I can't find the letter just now).

Actually 2 versions of this feature have been implemented in an experimental
version of Icon (there is presently no plan to put it in a released
version of Icon, though). The first version is described in the U of A
Technical Report TR 86-20 "An Expression Data Type for Icon". The 2nd
version is a merger with co-expressions, called c-expressions.

A c-expression is very much like a co-expression, except that instead of
making private copies of local variables, it actually share these
variables with the procedure creating it. For those of you familiar
with language implementation techniques, this means that procedure frames
mush be heap allocated instead of stack allocated, so that local variables
can outlive the procedure invocation (the c-expression can be put in a
global variable or returned from the procedure). For programs doing a lot
of procedure calls this can increase the amount of garbage collection.
This problem is familiar to Lisp implementors (because of closures) and
there are techniques for determining when a procedure frame can safely
be stack allocated in a language containing this type of feature.
However, I never got around to using such a technique with c-expressions.

Another differnece is that c-expressions do not support value transmition,
they only support the unary form of @. I don't think this is an
inherent restriction, but it didn't seem worth the bother to implement
in an experimental version. The one thing that makes c-expressions truly
different, is the fact that they can be invoked with the ! operator. This
causes the c-expression to generate all of its results starting from the
beginning, instead of just producing the next one as when activated by @.
In this context you can think of a c-expression as a (possibly) generative
procedure which takes no arguments, with ! corresponding to procedure
invocation.

The motivation for c-expressions was simulating SNOBOL4 patterns by
"capturing" Icon matching expressions. For this purpose, they need
a very compact syntax to be convenient, even so corresponding SNOBOL4
patterns are smaller. My original idea was to use a full scale
dyanmic procedure facility, but I was dissuaded. Such a facility
requires synatax for declaring parameters and local variables (and
requires extending Icon scoping rules to handle such nested contexts);
this syntax would be bulky. Of course there could be a separate compact
notation for dynamically creating parameterless procedures and ! could
still be used for invocation with no arguments (in this case procedure
rather the c-expression invocation).

In an Icon with dynamic procedure creation, should "c-expressions" be
moved from co-expressions to procedures, or it there some elegant way to
merge co-expressions and these dynamically created procedures?

I did experiment a little with dynamically created procedures. They
are fun to play with. The implementation used a variant translator
and a personalized interpreter, but I don't think I will admit to
the techniques used; they were rather gross and the implementation
was not quite right.

(I guess I have rambled on enough for now.)

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

From icon-group-sender  Tue May 10 15:02:03 1988
Received: by bocklin.arizona.edu; Tue, 10 May 88 15:02:07 MST
Message-Id: <[e-mail]>
Date: Tue, 10 May 88 09:07 CST
From: "Many people would rather die than think; in fact, most do."
 <[e-mail]>
Subject: call-by-string procedures?
To: [e-mail]
X-Vms-To: CRCVMS::IN%"[e-mail]"
Errors-To: icon-group-errors

While working on my project for our school's Icon class, I came across something
that I realy would love to see in future versions of Icon, and the last message
I just got from Richard G. via the Icon-Group reminded me of it...

I have several (very small) routines that print VT220 escape codes to turn on
various text attributes, like inverse, underscore, etc, and I came across the
problem of passing the routine name {set_inverse(), in this case} to a "print"
procedure.  Then, I wanted to call the routine just by the string that had
"set_inverse" in it like such: s()  (where s was the string).  No such luck.

As it turned out, the program was rather large, so I just put in a case
statement to handle the seperate types, and went out to fiddle around with the
example of call-by-string in the version7.docs file, but I couldn't get it to
work satisfactoraly (sp?!).

Am I doing something wrong?  Any help on this would be greatly apprecciated!

-/ Dave Capligner /---------------+--------------------------------------------
  Microcomputer Specialist        | Internet: [e-mail]
  Campus Computing                | UUCP:     ihnp4!unocss!dent
  University of Nebraska at Omaha | ARPAnet:  [e-mail]
  Omaha, NE 68182                 | Bitnet:   [e-mail]


From icon-group-sender  Tue May 10 21:43:30 1988
Received: by bocklin.arizona.edu; Tue, 10 May 88 21:43:35 MST
Date: Tue, 10 May 88 21:43:28 MST
From: "Tom Hicks" <trh>
Message-Id: <[e-mail]>
To: icon-group
Subject: precedence chart
Errors-To: icon-group-errors

Has anyone ever sat down and created a precedence chart (like the one
in the SNOBOL4 (green) reference book) which shows the precedence
hierarchy and associativity of all the operators for Icon? I am
aware that this information is available within the Icon grammar
(Icon book appendix A?) but was wondering if anyone had taken the
trouble to dig it out and summarize it. Such a document would be
immensely handy.

From icon-group-sender  Tue May 17 06:31:25 1988
Received: by bocklin.arizona.edu; Tue, 17 May 88 06:31:28 MST
Message-Id: <[e-mail]>
Date: Mon, 16 May 88 22:00 CST
From: "Many people would rather die than think; in fact, most do."
 <[e-mail]>
Subject: string invocation followup
To: [e-mail]
X-Vms-To: CRCVMS::IN%"[e-mail]"
Errors-To: icon-group-errors

My sincerest appologies for not seeing something obvious in my methods of
string invocation...  I realize now how to do it.  Apparently, one can
simply say    dosomething := "set_inverse"    if "set_inverse" is a procedure
name, and then just    dosomething   by itself will work.  I think I was
making it too difficult.  It turns out to be quite simple.

Thanks, however, to those of you that sent me mail about it!

-/ Dave Capligner /---------------+--------------------------------------------
  Microcomputer Specialist        | Internet: [e-mail]
  Campus Computing                | UUCP:     ihnp4!unocss!dent
  University of Nebraska at Omaha | ARPAnet:  [e-mail]
  Omaha, NE 68182                 | Bitnet:   [e-mail]

From icon-group-sender  Tue May 17 06:31:23 1988
Received: by bocklin.arizona.edu; Tue, 17 May 88 06:31:27 MST
Message-Id: <[e-mail]>
Date: Mon, 16 May 88 22:13 CST
From: "Many people would rather die than think; in fact, most do."
 <[e-mail]>
Subject: Custom iconx: fxsys.c ?
To: [e-mail]
X-Vms-To: CRCVMS::IN%"[e-mail]"
Errors-To: icon-group-errors

I recently discovered a desperate need for single-key input from our VMS-based
ICON (v7), but reads(file,1) doesn't quite do it... I need unbuffered input,
without moving the whole project into MS-DOS. :-)  So, while looking around
in the v7/src/iconx directory, I noticed "fxtras.c", and more relevantly,
"fxsys.c", which contains the (prototype?) function "readc()"

Two questons:  is readc() what I want? (I'm not sure from the code; I'm not
an extremely proficient C programmer), and if it is...

How do I install it?  I tried the obvious method of defining "SysFcns" (i think
that was the appropriate name) in the config.h file, and when that didn't work,
I even added a statement "DefFcn(readc)" in "fdefs.h", right after a similar
one for the fsize() function, which is also in fxsys.c (so I figured that it
was a good guess).  That won't seem to do it either.  Do I have to recompile
icont, itran, and ilink as well?  It didn't appear that they would be directly
affected by including fxsys in the iconx make, but... ?

Thanks in advance for any help anyone may be able to offer!

-/ Dave Capligner /---------------+--------------------------------------------
  Microcomputer Specialist        | Internet: [e-mail]
  Campus Computing                | UUCP:     ihnp4!unocss!dent
  University of Nebraska at Omaha | ARPAnet:  [e-mail]
  Omaha, NE 68182                 | Bitnet:   [e-mail]


From icon-group-sender  Tue May 17 18:57:30 1988
Received: by bocklin.arizona.edu; Tue, 17 May 88 18:57:33 MST
Return-Path: <[e-mail]>
Date: Tue, 17 May 88 16:06:20 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: "call-by-string"
Errors-To: icon-group-errors

Just a followup to Dave Capligner's bit on string invocation....

The thing I like about string invocation is that I can use it instead of
setting a flag.  It can make things much more clear.  Say I use one of
two output routines, depending on the value of the first argument:

  procedure main(a)
    Output := ( if a[1] == "a" then "FullOutput" else "PartialOutput" )
    etc....

  end

  procedure FullOutput(args)
    # Gives fully tabulated output
    etc...
  end

  procedure PartialOutput(args)
    # Gives a brief, one-line output
    etc...
  end

This way, I can call Output() in the main procedure, and not worry about
checking for some flag.  Not only this, but the variable name "Output"
is transparent.


                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

P.S.  I know I keep harping on this, but has anyone fooled with defining
      their own control structures (using p{})?  I'd really like to hear
      if someone knows what they are doing in this area....

From icon-group-sender  Tue May 17 19:13:15 1988
Received: by bocklin.arizona.edu; Tue, 17 May 88 19:13:19 MST
Date: Tue, 17 May 88 19:10:33 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Programmer-Defined Control Structures
In-Reply-To: <[e-mail]>
Errors-To: icon-group-errors

Since no one else has commented on this repeated request, I'll
make a comment or two.

The p{...} syntax was introduced into Icon as a method of experimenting
with the control of expression evaluation in Icon and in particular to
make it possible to define control structures (albiet somewhat awkwardly)
in the same sense procedures are commonly defined to augment the
built-in function repertoire.

Some time ago when extensible programming languages were the rage,
there were several proposals for programmer-defined control structures.
These proposals mostly came to nothing.  There are probably several
reasons for this, but it seems to me the main one is that the built-in
control structures provide the facilities that are needed in most
programming languages and there was little real motivation for defining
more.

I originally thought that the richness of expression evaluation in Icon
(compared to "flat" languages in which all expressions produce exactly
one result) provided more need for programmer-defined control structures.

There are papers with examples of programmer-defined control structures
and the Icon program library has collections and examples.

It seems, however, that programmer-defined control structures are rarely
used.  Perhaps there really is not the need.  Perhaps the mechanism is
awkward.  Perhaps it takes too much work.  Or perhaps this is fertile,
unexplored territory.

From a personal viewpoint, I used programmer-defined control structures
rarely -- and then only for "parallel" evaluation.

From icon-group-sender  Wed May 18 00:59:10 1988
Received: by bocklin.arizona.edu; Wed, 18 May 88 00:59:13 MST
Date: Wed, 18 May 88 08:57:16 BST
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - Sun UK TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re: "call-by-string"
Errors-To: icon-group-errors

Richard Goerwitz writes:

    The thing I like about string invocation is that I can use it
    instead of setting a flag.  It can make things much more
    clear.  Say I use one of two output routines, depending on the
    value of the first argument:

      procedure main(a)
        Output := ( if a[1] == "a" then "FullOutput" else "PartialOutput" )
        etc....

      end

    [ rest of program omitted]

If you substitute "prcedure-valued variables" for "string invocation"
above the same holds true.  Since I'm not a source freak (I _use_ Icon
rather than poke about with its insides to further research interests)
I don't know whether it is any more efficient, but it seems to me much
more obvious and elegant to write:

procedure  main(a)
        Output := ( if a[1] == "a" then Fullout else Partialout )
        Output(a)
end

procedure Fullout(x)
        every write(!x)
end

procedure Partialout(x)
        write(*x," arguments")
end

When you run this program you get the following results:

stevie% t a b c
a
b
c
stevie% t b c a
3 arguments

So why use a string when the natural data type is a procedure --
or is there some subtle point I'm missing?


Steve Holden                    [e-mail]
                        sholden@{sun,sunuk}.uucp
"No FM in the field from where I write...."    [Marty Reynolds]

From icon-group-sender  Wed May 18 21:00:21 1988
Received: by bocklin.arizona.edu; Wed, 18 May 88 21:00:25 MST
Return-Path: <[e-mail]>
Date: Wed, 18 May 88 22:03:49 CDT
From: Richard Goerwitz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: not missing anything
Errors-To: icon-group-errors

I don't think you are missing anything, Marty (may I presume?).  I was the
one who was missing something.  It never occurred to me to use procedure
valued variables, rather than string-valued ones.  Now that I've had the
chance to try out your examples, I like your way better....

                                                  -Richard L. Goerwitz
                                                  [e-mail]
                                                  !ihnp4!gargoyle!sophist!goer

From icon-group-sender  Thu May 19 01:48:11 1988
Received: by bocklin.arizona.edu; Thu, 19 May 88 01:48:13 MST
Date: Thu, 19 May 88 09:45:56 BST
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - Sun UK TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!sophist.uchicago.edu![e-mail]
Subject: Re:  not missing anything
Cc: sunuk!sun!arizona.edu![e-mail]
Errors-To: icon-group-errors

Marty was responsible for the quote, which came from the well-worn
phrase RTFM much used by tech. support in Sun (Read the F*******
Manual) - not to customers, I would add.  I really am Steve Holden,
and yes, you may presume.  If I don't get called Steve I tend to
assume I'm in trouble!

I'm glad you prefer the procedure valued variables.

 Steve

From icon-group-request  Tue May 24 23:36:54 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Tue, 24 May 88 23:36:54 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Tue, 24 May 88 23:36:24 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
    id AA19466; Tue, 24 May 88 16:19:23 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 24 May 88 00:08:07 GMT
From: portal!cup.portal.com![e-mail]
Organization: The Portal System (TM)
Subject: HELP ME!!!
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

Poor College Student needs Your Help!!   :-(

Hi.  I just finished my junior year in college, and now I'm
faced with a major problem.  I can't afford to pay for my senior
year.  I've tried everything.  I can't get any more student loans,
I don't qualify for any more scholarships, and my parents are as
broke as am I.  So as you can see, I've got a major problem.  But
as far as I can see, there is only one solution, to go forward.
I've come along way, and there is no chance in hell that I'm going
to drop out now!  I'm not a quiter, and I'm not going to give up.

But here is why I'm telling you all this.  I want to ask a favor of every
one out here on the net.  If each of you would just send me a one
dollar bill, I will be able to finish college and go on with my life.
I'm sure a dollar is not much to any of you, but just think how it
could change a person's life.  I'd really like to encourage all of you
to help me out, I've no other place to go, no other doors to knock
on.  I'm counting on all of you to help me! (PLEASE!)
If you would like to help a poor boy out, please send $1 (you can
of course send more if you want!!  :-)

Jay-Jay's College Fund
PO BOX 5631
Lincoln, NE  68505

PS.  Please don't flame me for posting this to so many newsgroups,
I really am in dire need of help, and if any of you were as desparate
as I am, you just might resort to the same thing I am.  Also, please
don't tell me to get a job!  I already have one and work over 25 hrs
a week, plus get in all my classes, plus find time to study!  So hey,
please consider it!  It would really mean a lot to me.  Thank you!

NOTE: Any extra money I receive will go to a scholarship fund to help
others in the same situation.  :-)

From icon-group-request  Wed May 25 14:32:36 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 25 May 88 14:32:36 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Wed, 25 May 88 14:32:17 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
    id AA26089; Tue, 24 May 88 23:34:03 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 25 May 88 05:52:05 GMT
From: kaon!gide.uchicago.edu![e-mail]  (Max Ziff)
Organization: University of Chicago
Subject: modeling mutual evaluation
Message-Id: <[e-mail]>
Sender: [e-mail]
To: [e-mail]


How can mutual evaluation be modeled?

I recently needed to implement an algorithm for finding a perfect hash function
for a fixed set of keys.  I read Richard Cichelli's "Minimal Perfect Hash
Functions Made Simple" (in Comm ACM, 1983, 1) where he suggests a simple
heuristic and backtracking, and I immediately thought of the eight queens
problem, and modeled my program after the one in the book:

global hashcodes,mapvals,maxval

procedure main()
    hashcodes := table(-1)
    mapvals := table(-1)
    maxval := 6
    (h("jun"), h("sep"), h("dec"), h("aug"), h("jan"), h("feb"),
    h("jul"), h("apr"), h("oct"), h("may"), h("mar"), h("nov"))
    hlist := sort(mapvals)
    i := 0
    while pair := hlist[i +:= 1] do
    write (pair[1],pair[2])
end

procedure h(s)
    if hashcodes[(hashval := (hashchar(s[2]) + hashchar(s[3])))] = -1
    then suspend hashcodes[hashval] <- hashval
end

procedure hashchar(s)
    if (mapvals[s] ~= -1) then return mapvals[s]
    suspend mapvals[s] <- 0 to maxval
end

The program works fine, and I was pleased by how easy it was to throw
together.  But I'd like not to have to "hardwire" the keys in the code.
Suppose the keys are in a list:

    keys := ["jun", "sep", "dec", "aug", "jan", "feb",
    "jul", "apr", "oct", "may", "mar", "nov"]

With what can I replace the mutual evaluation expression to get the same
backtracking effect?  To be more specific, suppose I want a function, call it
"mutual-map-proc" of two arguments: a procedure and a co-expression, such that
the function models the mutual evaluation of the procedure on each value
returned by the co-expression.  Thus I could replace the mutual evaluation
in my program with:

    mutual-map-proc(h, create !keys)

and the function call in the eight queens program on page 153 of the icon book
could be replaced by

    mutual-map-proc(q, create 1 to 8)

(except, of course, that this would not have the side effect of printing out
the solution).

Am I off-course?  Any ideas?

Donald Ziff               ARTFL Project, University of Chicago
                          1050 E. 59th Street, Chicago, Illinois   60637

                          ...ihnp4!gargoyle!sphinx!maxz
                          [e-mail].{EDU,BITNET,MAILNET,CSNET}

From icon-group-request  Wed May 25 16:01:03 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 25 May 88 16:01:03 MST
Received: from UCBVAX.Berkeley.EDU by megaron.arizona.edu; Wed, 25 May 88 16:00:32 MST
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
    id AA03697; Wed, 25 May 88 09:16:22 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 25 May 88 15:10:19 GMT
From: [e-mail]  (Clarence K. Din)
Organization: Boston Univ.
Subject: Re: HELP ME!!!
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>Poor College Student needs Your Help!!   :-(
>
>Hi.  I just finished my junior year in college, and now I'm
>faced with a major problem.  I can't afford to pay for my senior
>year.  I've tried everything.  I can't get any more student loans,
>I don't qualify for any more scholarships, and my parents are as
>broke as am I.  So as you can see, I've got a major problem.

Hey, we all have problems, buddy.

>But as far as I can see, there is only one solution, to go forward.
>I've come along way, and there is no chance in hell that I'm going
>to drop out now!  I'm not a quiter, and I'm not going to give up.

That's a lot of hoopla.  If you had the motivation, determination,
and intelligence, you'd find yourself a decent part-time job.

>But here is why I'm telling you all this.  I want to ask a favor of every
>one out here on the net.  If each of you would just send me a one
>dollar bill, I will be able to finish college and go on with my life.
>I'm sure a dollar is not much to any of you, but just think how it
>could change a person's life.  I'd really like to encourage all of you
>to help me out, I've no other place to go, no other doors to knock
>on.  I'm counting on all of you to help me! (PLEASE!)

Remember the ol' exec in the airport terminal routine (y'know, where
some bum dresses up like some well-to-do feeb and asks people for
money because "he missed his flight and has to call his wife, but has
no pocket change or transportation fare"?).

>Jay-Jay's College Fund
>PO BOX 5631           <<--- hmmm... a box number...
>Lincoln, NE  68505
> Also, please
>don't tell me to get a job!  I already have one and work over 25 hrs
>a week, plus get in all my classes, plus find time to study!  So hey,
>please consider it!  It would really mean a lot to me.  Thank you!

Big deal.  I work more than 25 hours a week; I get no money and
tuition here at BU, including everything, is $18000.  Hey, people,
if you have any of that money, send it to me!

>NOTE: Any extra money I receive will go to a scholarship fund to help
>others in the same situation.  :-)

Sure.  Sure.  It'll all go in your back pocket.


Sincerely,

Clarence K. Din
[e-mail]
.

From gudeman  Wed May 25 16:15:42 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Wed, 25 May 88 16:15:42 MST
Date: Wed, 25 May 88 16:15:41 MST
From: "David Gudeman" <gudeman>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Wed, 25 May 88 16:15:41 MST
To: icon-group
In-Reply-To: <[e-mail]>
Subject: modeling mutual evaluation

>From: kaon!gide.uchicago.edu![e-mail]  (Max Ziff)
>
>How can mutual evaluation be modeled?
>...
>    keys := ["jun", "sep", "dec", "aug", "jan", "feb",
>       "jul", "apr", "oct", "may", "mar", "nov"]
>
>With what can I replace the mutual evaluation expression to get the same
>backtracking effect?  To be more specific, suppose I want a function, call it
>"mutual-map-proc" of two arguments: a procedure and a co-expression, such that
>the function models the mutual evaluation of the procedure on each value
>returned by the co-expression.  Thus I could replace the mutual evaluation
>in my program with:
>
>    mutual-map-proc(h, create !keys)

As long as you already have a list, why turn it into a co-expression?
Here is a function that maps a procedure over a list using mutual
evaluation of each call.  Your program would use the expression

    mutual-eval-map(h, keys)
----------------------------------------------------------------------
# call p(x) for each x in ls with backtracking into previous calls.
#        mutual_eval_map(p,ls)
# is equivalent to
#        (p(ls[1]), p(ls[2]),..., p(ls[*ls]))
# An optional third argument i means to start at ls[i] instead of
# ls[1].  Notice that i is needed for recursive calls.
procedure mutual_eval_map(p,ls,i)
    /i := 1
    if i = *ls then suspend p(ls[i])
    else suspend p(ls[i]) & mutual_eval_map(p,ls,i+1)
end

From [e-mail]  Thu May 26 07:26:19 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 26 May 88 07:26:19 MST
Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu; Thu, 26 May 88 07:26:12 MST
Received: by CIM-VAX id <[e-mail]> ;
       Thu, 26 May 88 09:24:29 CDT
Date: Thu, 26 May 88 09:20:42 CDT
From: David S. Cargo MN67-2F08 593-2822 <[e-mail]>
Subject: Decompiling
To: [e-mail]
X-Vms-Mail-To: EXOS%"[e-mail]"
Message-Id: <[e-mail]>

Sorry if this message seems like a repeat.  I never got a network echo from
the first one, so I don't know if it got through originally.

I accidently deleted a .icn file on my MS-DOS system.  Is there any way to
turn a version 7 .icx file back into Icon source?  Even approximately?
The structure of some of the algorithms I sometimes use are hard to recreate.
I figure I'm not the only person who has had this problem, so I thought it
was worth bringing up to the whole group.

David S. Cargo ([e-mail])

From ralph  Thu May 26 07:47:51 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 26 May 88 07:47:51 MST
Date: Thu, 26 May 88 07:43:15 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Thu, 26 May 88 07:43:15 MST
To: [e-mail], [e-mail]
Subject: Re:  Decompiling
In-Reply-To: <[e-mail]>

As far as I know, there is no program around to decompile an an Icon
icode file back into a source file.  If I'm mistaken, and some one
has done this, we'd like to have a copy.

Note that the structure of an icode file varies with the Icon version
and with the architecture on which it was created.  Also, some information
is lost (like the names of record fields) in per-Version 7 icode files.
I'm not sure, off hand, if other information is lost.

From sunuk!nuksun!stevie![e-mail]  Thu May 26 15:26:31 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 26 May 88 15:26:31 MST
Received: from SUN.COM by megaron.arizona.edu; Thu, 26 May 88 15:26:21 MST
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
    id AA04552; Thu, 26 May 88 00:50:30 PDT
Received: from uk.sun.com (sunuk) by snail.sun.com (4.0/SMI-3.2)
    id AA06630; Thu, 26 May 88 00:47:50 PDT
Received: from Nuksun.Europe.Sun.COM (inuksun) by uk.sun.com (3.2/SMI-3.2)
    id AA17232; Thu, 26 May 88 08:51:39 BST
Received: from stevie.nuksun.uucp by Nuksun.Europe.Sun.COM (1.1/SMI-3.2)
    id AA02425; Thu, 26 May 88 09:51:52 -0100
Received: by stevie.nuksun.uucp (3.2/SMI-3.2)
    id AA17361; Thu, 26 May 88 08:51:38 BST
Date: Thu, 26 May 88 08:51:38 BST
From: sunuk!nuksun!stevie![e-mail] (Steve Holden - Sun UK TSE)
Message-Id: <[e-mail]>
To: sunuk!sun!arizona.edu![e-mail]
Subject: Re: HELP ME!!!

I trust the origin of this mail will be traced - my copy only comes
in with headers from Arizona - and the appropriate wires cut.  A
case begins to emerge for sender authorisation.

Steve

From gmt  Thu May 26 16:45:01 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 26 May 88 16:45:01 MST
Date: Thu, 26 May 88 16:44:58 MST
From: "Gregg Townsend" <gmt>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Thu, 26 May 88 16:44:58 MST
In-Reply-To: <[e-mail]>
To: icon-group
Subject: Re: HELP ME!!!

JJ's plea for money was sent to nearly every usenet newsgroup and mailing list,
so we weren't singled out.  Of course, there is a huge uproar; it's reported
that JJ's account has been cancelled, and other actions are also being proposed.
Further discussions should probably be directed to the "news.misc" newsgroup;
let's get back to Icon here.

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

From [e-mail]  Thu May 26 17:36:13 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 26 May 88 17:36:13 MST
Received: from UXC.CSO.UIUC.EDU by megaron.arizona.edu; Thu, 26 May 88 17:36:05 MST
Received: by uxc.cso.uiuc.edu (5.51/9.7)
    id AA08062; Thu, 26 May 88 19:33:58 CDT
Received: by stride.Stride.COM (5.51/UUCP-Project/rel-1.0/11-05-86)
    id AA23865; Thu, 26 May 88 09:04:27 PDT
Date: Thu, 26 May 88 09:04:27 PDT
From: [e-mail] (Bruce Robertson)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: [e-mail]'s message of 24 May 88 00:08:07 GMT <[e-mail]>
Subject: HELP ME!!!

If your current job isn't enough to pay your tuition, then try taking
fewer classes.  Why do you have to get through college in four years?

You obviously haven't learned anything in your first three years of
college, as the errors in spelling and grammar indicate.

From mcvax!cerisi.cerisi.Fr![e-mail]  Thu May 26 21:37:42 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 26 May 88 21:37:42 MST
Received: from uunet.UU.NET by megaron.arizona.edu; Thu, 26 May 88 21:37:33 MST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
    id AA23347; Fri, 27 May 88 00:35:28 EDT
Received: by mcvax.cwi.nl; Fri, 27 May 88 06:25:16 +0200 (MET)
Received: from mirsa.inria.Fr by inria.inria.fr; Thu, 26 May 88 21:46:13 +0200 (MET)
Message-Id: <[e-mail]>
Posted: Thu, 26 May 88 21:44:48 -0100
Date: Thu, 26 May 88 21:44:48 -0100
Posted-Date: Thu, 26 May 88 21:44:48 -0100
From: olivier lecarme <mcvax!cerisi.cerisi.Fr![e-mail]>
To: [e-mail]
In-Reply-To: "Ralph Griswold"'s message of Thu, 26 May 88 07:43:15 MST <[e-mail]>
Subject:  Decompiling

Decompiling in itself is a difficult and fascinating subject, but I
think that in the case of Icon there is much less information lost than
for any other language implementation I know of. I evaluate the work to
be feasible as a final project for a team of three or four undergraduate
students. Is Ralph of the same opinion?

By the way, I have another student team working on an Icon indenting
prettyprinter, written in Icon of course. Are any people interested?

Olivier Lecarme, University of Nice, France

From ralph  Thu May 26 22:03:57 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Thu, 26 May 88 22:03:57 MST
Date: Thu, 26 May 88 22:03:55 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Thu, 26 May 88 22:03:55 MST
To: [e-mail], mcvax!cerisi.cerisi.Fr![e-mail]
Subject: Re:  Decompiling
In-Reply-To: <[e-mail]>

I'm really not sure how hard it is to decompile an Icon icode file.
I once tried to write a decompiler for Icon ucode files (closer to
the source than icode files) and found it unexpectedly difficult.  I
did not pursue the matter, so I really cannot make a definitive
comment.

It certainly is an interesting project.

     Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
     [phone]   [e-mail]     {allegra|noao|ihnp4}!arizona!ralph


From [e-mail]  Mon May 30 17:36:11 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 30 May 88 17:36:11 MST
Message-Id: <[e-mail]>
Received: from rvax.ccit.arizona.edu by megaron.arizona.edu; Mon, 30 May 88 17:36:10 MST
Received: from BITNET-GATEWAY by rvax.ccit.arizona.edu; Mon, 30 May 88 17:32 MST
Date: Sun, 29 May 88 13:55 CST
From: "Many people would rather die than think; in fact, most do."
 <[e-mail]>
Subject: The future implementations of Icon
To: [e-mail]
X-Vms-To: CRCVMS::IN%"[e-mail]"

In my recent attempts to implement single-key input (non-buffered) for
Icon version 7 under VAX/VMS 4.7, I picked up the book "The Implementation
of the Icon Programming Language," and boy did that help!  I've now got
a synchronous readc() function that pauses until a key is pressed, and returns
that key.  I'll probably expand this to an asynchronous version that returns
&null if there aren't any characters in the buffer or something.. I haven't
really thought to much about that one.

But on to the point of this post.  In the back of the book, included in
the "projects" section (Appendix E), I noticed a few things that seem to be
near completion for newer versions of Icon.. (The book refers to version 6
something, I think)  Most notably "operators", which I've been wondering
about.  The "call-by-string" feature in Icon version 7 looks like a precursor
to user-defined operators.  But, what /are/ user-defined operators, and how
might they be implemented (as well as what use will they find)?  When I first
glanced over the projects, I had an idea of something like this:

operator "#"(a,b)
  if (MIN < a < b < MAX) then return b
end        # (failure implied)

which would define the "#" character to do something trivial (I couldn't
think of a usefull example off the top of my head), and could then be called
like:

  x := a # b

(for a trivial example :-)

Am I close?  Does anyone have any thoughts on this?

Something else I saw was "Design and implement a terminal-independant
windowing package for Icon."  Wouldn't it just be simpler to implement Icon
commands to perform Curses functions?  (as an example)  I'm not sure of the
complexity of that one..  (Incidentally, I have a "windowing package" for
Icon, but it's not terminal-independant.  I did restrict it to VT-100 codes
though, and VT-100's are pretty common so...)

-/ Dave Caplinger /---------------+--------------------------------------------
  Microcomputer Specialist        | Internet: [e-mail]
  Campus Computing                | UUCP:     ihnp4!unocss!dent
  University of Nebraska at Omaha | ARPAnet:  [e-mail]
  Omaha, NE 68182                 | Bitnet:   [e-mail]


From ralph  Mon May 30 17:46:00 1988
Received: from megaron.arizona.edu by bocklin.arizona.edu; Mon, 30 May 88 17:46:00 MST
Date: Mon, 30 May 88 17:45:57 MST
From: "Ralph Griswold" <ralph>
Message-Id: <[e-mail]>
Received: by megaron.arizona.edu; Mon, 30 May 88 17:45:57 MST
To: [e-mail], [e-mail]
Subject: Re:  The future implementations of Icon
In-Reply-To: <[e-mail]>

To the best of my knowledge, nothing has been done with programmer-defined
operators.  There are lots of approaches, both in terms of language design
and in terms of implementation.  The real problem is that they would
have a potentially serious impact on efficiency. Right now, the meanings
of operator symbols are known to the translator and the source-language
is connected firmly to the code to be executed. If operators could be
redefined, a level of indirectness would be needed.

Not that efficiency is everything -- witness many features in Icon where
user flexibility takes precedence over efficiency.  The question is --
is there enough need for programmer-defined operators to justify the
costs.

Incidentally, you shouldn't take the projects in the Icon implementation
book to be a blueprint for future developments in the Icon language.  Granted,
some of the projects fall into this category.  Others are things that might
be useful in a "private" version of Icon.  Some are wishful thinking.
Some are designed to the useful exercises for person who want to work
on the implementation of Icon.


   Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
   [phone]   [e-mail]     {allegra|noao|ihnp4}!arizona!ralph