From icon-group-request Fri Jan 1 02:17:02 1988 From: grand!day@uunet.uu.net (Dave Yost) Organization: Grand Software, Inc., 213-650-1089, Los Angeles, CA Subject: complicated sorting Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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" In-Reply-To: <397@grand.UUCP> To: grand!day@uunet.uu.net, icon-group@arizona.edu Subject: Re: complicated sorting Errors-To: icon-group-request Status: O Date: 1 Jan 88 05:33:51 GMT From: grand!day@uunet.uu.net (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: 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: goer%sophist@gargoyle.uchicago.edu (Richard Goerwitz) To: icon-group@arizona.edu 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 To: icon-group@arizona.edu 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 (608) 263-3509 Thank you, Paul DuBois dubois@rhesus.primate.wisc.edu rhesus!dubois bin@rhesus.primate.wisc.edu rhesus!bin From icon-group-request Tue Jan 5 17:25:09 1988 From: "Kenneth Walker" In-Reply-To: <8801050803.AA14397@sophist.uchicago.edu> To: goer%sophist@gargoyle.uchicago.edu, icon-group@arizona.edu Subject: Re: find/upto Errors-To: icon-group-request Status: O > Date: Tue, 5 Jan 88 02:03:48 CST > From: goer%sophist@gargoyle.uchicago.edu (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!day@uunet.UU.NET Posted-Date: Tue, 05 Jan 88 23:38:53 PST To: icon-group@arizona.edu Cc: day@uunet.UU.NET Subject: open ("command", "wp) Organization: Grand Software, Inc., makers of "The Grand Editor" Domain-From: day@grand.COM Phone: 213-650-1089 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" In-Reply-To: <8801060738.AA13176@grand.COM> To: grand!day@uunet.UU.NET, icon-group@arizona.edu Subject: Re: open ("command", "wp) Cc: day@uunet.UU.NET 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: goer%sophist@gargoyle.uchicago.edu (Richard Goerwitz) To: icon-group@arizona.edu 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: 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!day@uunet.UU.NET Posted-Date: Fri, 08 Jan 88 17:33:06 PST To: "Kenneth Walker" Cc: icon-group@arizona.edu, day@uunet.UU.NET Subject: Re: complicated sorting In-Reply-To: Your message of Sun, 03 Jan 88 13:38:47 MST. <8801032038.AA13538@megaron.arizona.edu> Organization: Grand Software, Inc., makers of "The Grand Editor" Domain-From: day@grand.COM Phone: 213-650-1089 Errors-To: icon-group-request Status: O Date: Sun, 3 Jan 88 13:38:47 MST From: "Kenneth Walker" In-Reply-To: <397@grand.UUCP> To: day@grand.UUCP, icon-group@arizona.edu 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!day@uunet.uu.net (Dave Yost) Organization: Grand Software, Inc., Los Angels, CA 213-650-1089 Subject: Re: open ("command", "wp) References: <8801091948.AA28813@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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" To: icon-group Subject: Re: complicated sorting Errors-To: icon-group-request Status: O From: grand!day@uunet.UU.NET 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: 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" To: ihnp4!ihuxy!nowlin, icon-group In-Reply-To: <8801132040.AA07880@megaron.arizona.edu> 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: goer%sophist@gargoyle.uchicago.edu (Richard Goerwitz) To: icon-group@arizona.edu 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: goer%sophist@gargoyle.uchicago.edu (Richard Goerwitz) To: icon-group@arizona.edu 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" In-Reply-To: <8801240741.AA05380@sophist.uchicago.edu> To: goer%sophist@gargoyle.uchicago.edu, icon-group@arizona.edu 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: goer%sophist@gargoyle.uchicago.edu (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: NETWORK@FRSAC11.BITNET Subject: ATARI ICON. To: icon-group@arizona.edu 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) network%frsac11.bitnet@mitvma.mit.edu (arpanet) dumas@sumex-aim.stanford.edu (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: 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) > network%frsac11.bitnet@mitvma.mit.edu (arpanet) > dumas@sumex-aim.stanford.edu (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 (312) 979-7173 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 (312) 510-6194 ' ) ) The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill. / (_ In-Reply-To: <8801311629.AA18373@sophist.uchicago.edu> To: goer%sophist@gargoyle.uchicago.edu, icon-group@arizona.edu Subject: Re: pointers, structures, confusion Errors-To: icon-group-request Status: O Date: Sun, 31 Jan 88 10:29:35 CST From: goer%sophist@gargoyle.uchicago.edu (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: <8802021139.AA02428@megaron.arizona.edu> 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: icon-group@arizona.edu From: NETWORK%FRSAC11.BITNET@CUNYVM.CUNY.EDU 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 acm@valhalla.cs.ucla.edu (edu) Bertrand Decouty decouty@frcicg71 (earn) Klaus Hahn hahn_k@dmrhrz11 (earn) Greg Onufer ucbvax!ucdavis!uop.edu!root (uucp) Andres F. Moreno moreno@umn-cs.cs.umn.edu (edu) Bob Bright bright@dalac (bitnet) Matthias Moritz u608017@hnykun11 (earn) Ruud van der Plaats vdplaats@hnykun53 (earn) Gordon Joly gcj%@uk.ac.qmc.maths (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 icon-project@arizona.edu ++++++++++++++++++++++++ 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 , 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) network%frsac11.bitnet@mitvma.mit.edu (arpanet) dumas@sumex-aim.stanford.edu (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!steveh@Sun.COM (Steve Holden - TSE) Message-Id: <8802100925.AA18977@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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!sbw@Sun.COM (Steve Wampler) Message-Id: <8802101301.AA00900@naucse> To: sunuk!nuksun!stevie!steveh%arizona@Sun.COM, sun!arizona.edu!icon-group%sunuk@Sun.COM 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 Subject: icon e-mail programs To: icon-group 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: <6842.8802101922.cheviot@uk.ac.newcastle> 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 spqr@uk.ac.soton.cm 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!steveh@Sun.COM, sun!arizona.edu!icon-group%sunuk@Sun.COM Subject: Re: E-mail handling software - testers wanted Message-Id: <8802101813.AA05625@uncle.UUCP> Date: 10 Feb 88 18:13:05 EST (Wed) From: sunuk!sun!uncle!jbm@Sun.COM (John B. Milton) Errors-To: icon-group-request I volunteer -- John Bly Milton IV, jbm@uncle.UUCP, {ihnp4|cbosgd}!n8emr!uncle!jbm home: (614) 294-4823, work: (614) 459-7641, 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!steveh@Sun.COM (Steve Holden - TSE) Message-Id: <8802121812.AA04997@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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. +44 61 477 3100 {many nodes}!sun!sholden sholden@sun.com 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!berry%askone.s1.gov@Sun.COM Message-Id: <8802152049.AA25051@askone.s1.gov> To: nuksun!stevie!steveh%sunuk@Sun.COM Cc: sun!arizona.edu!icon-group%sunuk@Sun.COM In-Reply-To: Steve Holden - TSE's message of Wed, 10 Feb 88 09:25:49 GMT <8802100925.AA18977@stevie.nuksun.uucp> 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: 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 Message-Id: <8802170015.AA00347@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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 icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Feb 88 03:08:12 GMT From: marque!martin@csd1.milw.wisc.edu (Martin Wiedmeyer) Organization: Marquette University, Milwaukee, WI Subject: Re: Mail handling software Message-Id: <39@marque.mu.edu> References: <8802121812.AA04997@stevie.nuksun.uucp> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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" Message-Id: <8802171757.AA02952@megaron.arizona.edu> 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" Message-Id: <8802171804.AA03682@megaron.arizona.edu> 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" Message-Id: <8802172031.AA11080@megaron.arizona.edu> Received: by megaron.arizona.edu; Wed, 17 Feb 88 13:31:01 MST In-Reply-To: <8802170015.AA00347@sophist.uchicago.edu> To: icon-group Subject: variable args Errors-To: icon-group-request Date: Tue, 16 Feb 88 18:15:41 CST From: Richard Goerwitz 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? I would expect that if we pass on a value for a only, that b and c would turn up being null. 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!steveh@Sun.COM (Steve Holden - TSE) Message-Id: <8802180942.AA06649@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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 sholden@sun.com --------------------------------------------------------------------------- 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 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!steveh@Sun.COM (Steve Holden - TSE) Message-Id: <8802181143.AA07326@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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!berry%jhereg.s1.gov@Sun.COM Message-Id: <8802181830.AA05632@jhereg.s1.gov> To: nuksun!stevie!steveh%sunuk@Sun.COM Cc: sun!arizona.edu!icon-group%sunuk@Sun.COM In-Reply-To: Steve Holden - TSE's message of Thu, 18 Feb 88 09:42:35 GMT <8802180942.AA06649@stevie.nuksun.uucp> 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: weiser.pa@Xerox.COM To: icon-group@arizona.edu 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" Message-Id: <8802182319.AA22670@megaron.arizona.edu> 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" Message-Id: <8802201555.AA19898@megaron.arizona.edu> 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: 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 Message-Id: <8802240213.AA14338@sophist.uchicago.edu> To: icon-group@arizona.edu 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 Subject: ICON and commercial support (49 lines) >From dow@husc6.BITNET (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 goer@sophist.uchicago.edu !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!steveh@Sun.COM (Steve Holden - TSE) Message-Id: <8802261605.AA24796@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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" Message-Id: <8802270334.AA01812@megaron.arizona.edu> 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 +1 602 621 4325 gmt@Arizona.EDU {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 icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 88 15:06:08 GMT From: mcvax!ukc!stc!datlog!torch!paul@uunet.uu.net (Paul Andrews) Organization: TORCH Computers Ltd., Cambridge, United Kingdom Subject: Map of Europe Message-Id: <60@torch.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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 icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Feb 88 15:10:37 GMT From: mcvax!ukc!stc!datlog!torch!paul@uunet.uu.net (Paul Andrews) Organization: TORCH Computers Ltd., Cambridge, United Kingdom Subject: Icon? Message-Id: <61@torch.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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: 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 Message-Id: <8802290428.AA07576@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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" Message-Id: <8802291823.AA17235@megaron.arizona.edu> 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: <8803010125.AA14607@megaron.arizona.edu> 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: 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: <8803010125.AA14602@megaron.arizona.edu> 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: End-Of-Protocol: Content-Length: 2392 Errors-To: icon-group-request > From: Richard Goerwitz > 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 > goer@sophist.uchicago.edu > !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" Message-Id: <8803010131.AA15206@megaron.arizona.edu> Received: by megaron.arizona.edu; Mon, 29 Feb 88 18:31:35 MST To: icon-group In-Reply-To: <8802291823.AA17235@megaron.arizona.edu> 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!paul@uunet.uu.net (Paul Andrews) Organization: TORCH Computers Ltd., Cambridge, United Kingdom Subject: Re: Map of Europe Message-Id: <62@torch.UUCP> References: <60@torch.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-errors In article <60@torch.UUCP> paul@torch.UUCP (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: <8803041415.AA06825@megaron.arizona.edu> Date: Fri, 04 Mar 88 13:46:31 GMT To: icon-group@arizona.edu From: NETWORK%FRSAC11.BITNET@CUNYVM.CUNY.EDU 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) network%frsac11.bitnet@mitvma.mit.edu (arpanet) dumas@sumex-aim.stanford.edu (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: <8803041415.AA06888@megaron.arizona.edu> Date: Fri, 04 Mar 88 13:59:38 GMT To: icon-group@arizona.edu From: NETWORK%FRSAC11.BITNET@CUNYVM.CUNY.EDU 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) network%frsac11.bitnet@mitvma.mit.edu (arpanet) dumas@sumex-aim.stanford.edu (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!steveh@Sun.COM (Steve Holden - TSE) Message-Id: <8803081343.AA12237@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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 sholden@sun.com 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" Message-Id: <8803081939.AA15583@megaron.arizona.edu> 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 +1 602 621 6609 ralph@Arizona.EDU {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" Message-Id: <8803081834.AA12810@megaron.arizona.edu> In-Reply-To: <8803081343.AA12237@stevie.nuksun.uucp> To: nuksun!stevie!steveh%sunuk@Sun.COM, sun!arizona.edu!icon-group%sunuk@Sun.COM 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!steveh@Sun.COM (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 +1 602 621 2858 kwalker@Arizona.EDU {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: <8803091108.AA26850@megaron.arizona.edu> 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: End-Of-Protocol: Content-Length: 1765 Errors-To: icon-group-errors > From: "Kenneth Walker" > > >Date: Tue, 8 Mar 88 13:43:41 GMT > >From: sunuk!nuksun!stevie!steveh@Sun.COM (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 > +1 602 621 2858 kwalker@Arizona.EDU {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: mcnamee@iris.ucdavis.edu (Carole McNamee) Message-Id: <8803090201.AA16699@iris> To: icon-group@arizona.edu 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" Message-Id: <8803101806.AA17771@megaron.arizona.edu> 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" Message-Id: <8803110047.AA17998@megaron.arizona.edu> 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 +1 602 621 4325 gmt@Arizona.EDU {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: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu To: icon-group@arizona.edu 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: <8803111912.AA03606@megaron.arizona.edu> 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: End-Of-Protocol: Content-Length: 1482 Errors-To: icon-group-errors > From: "Gregg Townsend" > > 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!martin@csd1.milw.wisc.edu (Martin Wiedmeyer) Organization: Lake Systems - Milwaukee, WI Subject: Re: Atari 6.5 memory problems. Message-Id: <487@lakesys.UUCP> References: <8803041415.AA06825@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-errors In article <8803041415.AA06825@megaron.arizona.edu> NETWORK@FRSAC11.BITNET 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!dupuy@columbia.edu (Alexander Dupuy) Organization: Columbia University Computer Science Dept. Subject: Re: tables, mappings, and unified field theory Message-Id: <5417@columbia.edu> References: <8803101806.AA17771@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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: dupuy@columbia.edu 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" Message-Id: <8803202011.AA14369@megaron.arizona.edu> In-Reply-To: <8803111912.AA03606@megaron.arizona.edu> 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 +1 602 621 4325 gmt@Arizona.EDU 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: icon-group@arizona.edu Subject: string scanning Reply-To: rich%sendai.UUCP@umix.cc.umich.edu Message-Id: <8803232224.AA02958@sendai.UUCP> Date: 23 Mar 88 22:24:07 EST (Wed) From: rich%sendai.UUCP@umix.cc.umich.edu (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: <8803241451.AA06102@megaron.arizona.edu> 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: End-Of-Protocol: Content-Length: 1119 Errors-To: icon-group-errors > From: ihnp4!arizona!rich%sendai.UUCP@umix.cc.umich.edu (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: <8803241451.AA06113@megaron.arizona.edu> 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: End-Of-Protocol: Content-Length: 1119 Errors-To: icon-group-errors > From: ihnp4!arizona!rich%sendai.UUCP@umix.cc.umich.edu (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!rich%sendai.UUCP@umix.cc.umich.edu (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" Message-Id: <8803241655.AA12476@megaron.arizona.edu> 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: tower@wheaties.ai.mit.edu (Leonard H. Tower Jr.) Message-Id: <8803240130.AA01161@soleus.ai.mit.edu> To: info-gnu-emacs-non-usenet@prep.ai.mit.edu Cc: Icon-Group@arizona.edu, mailrus!umix!oxtrap!sendai!rich@tut.cis.ohio-state.edu Subject: [rich@sendai.uucp: icon mode] Reply-To: mailrus!umix!oxtrap!sendai!rich@tut.cis.ohio-state.edu Errors-To: icon-group-errors Path: mit-eddie!bloom-beacon!tut.cis.ohio-state.edu!mailrus!umix!oxtrap!sendai!rich From: rich@sendai.uucp (K. Richard Magill) Newsgroups: comp.emacs Subject: icon mode Date: 22 Mar 88 11:42:59 GMT Reply-To: rich@sendai.uucp Organization: Digital Works Ltd, Ann Arbor Apparently-To: emacs-netnews-distribution@prep.ai.mit.edu 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: Date: Thu, 24 Mar 88 20:51:47 CST From: Richard Goerwitz Message-Id: <8803250251.AA00828@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu To: icon-group@arizona.edu 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!steveh@Sun.COM (Steve Holden - Sun UK TSE) Message-Id: <8803251019.AA23622@stevie.nuksun.uucp> To: sunuk!sun!sophist.uchicago.edu!goer@Sun.COM Subject: Re: coexpressions - help! Cc: sunuk!sun!arizona.edu!icon-group@Sun.COM 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: R.J.Hare@EDINBURGH.AC.UK To: icon-group@arizona.edu 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 (R.J.HARE@UK.AC.EDINBURGH) 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: Date: Fri, 25 Mar 88 13:04:04 CST From: Richard Goerwitz Message-Id: <8803251904.AA00543@sophist.uchicago.edu> To: R.J.Hare@EDINBURGH.AC.UK Subject: two types of comparisons Cc: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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" Message-Id: <8803252013.AA17684@megaron.arizona.edu> To: R.J.Hare@EDINBURGH.AC.UK 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: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu To: icon-group@arizona.edu 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: Date: Fri, 25 Mar 88 23:37:30 CST From: Richard Goerwitz Message-Id: <8803260537.AA01330@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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!ken@bbn.com (Ken Yap) Organization: U of Rochester, CS Dept, Rochester, NY Subject: sets from ranges Message-Id: <8041@sol.ARPA> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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" Message-Id: <8803261425.AA23978@megaron.arizona.edu> To: rochester!ken@bbn.com 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 +1 602 621 6609 ralph@Arizona.EDU {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" Message-Id: <8803262032.AA04273@megaron.arizona.edu> In-Reply-To: <8041@sol.ARPA> To: icon-group@arizona.edu, rochester!ken@bbn.com Subject: Re: sets from ranges Errors-To: icon-group-errors From icon-group-sender Sat Mar 26 07:10:30 1988 From: rochester!ken@bbn.com (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: <8803262328.AA09626@megaron.arizona.edu> 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: 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" Message-Id: <8803270316.AA18338@megaron.arizona.edu> 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: <8803270321.AA18718@megaron.arizona.edu> 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: 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" Message-Id: <8803270434.AA20893@megaron.arizona.edu> 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" Message-Id: <8803271711.AA15329@megaron.arizona.edu> 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: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu ... > 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: <8803281913.AA14043@megaron.arizona.edu> 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: 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: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu To: icon-group@arizona.edu 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" Message-Id: <8803282135.AA22435@megaron.arizona.edu> 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: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu > > 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 +1 602 621 2858 kwalker@Arizona.EDU {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: Date: Tue, 29 Mar 88 12:55:41 CST From: Richard Goerwitz Message-Id: <8803291855.AA03851@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu ...!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: <8803300440.AA17071@megaron.arizona.edu> 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: 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!nevin1@ucbvax.Berkeley.EDU (00704a-Liber) Organization: AT&T Bell Laboratories - Naperville, Illinois Subject: Re: sets from ranges Message-Id: <4171@ihlpf.ATT.COM> References: <8041@sol.ARPA> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-errors In article <8041@sol.ARPA> ken@cs.rochester.edu (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: Date: Wed, 30 Mar 88 05:19:29 CST From: Richard Goerwitz Message-Id: <8803301119.AA04972@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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" Message-Id: <8803311348.AA10888@megaron.arizona.edu> 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: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu To: icon-group@arizona.edu 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" Message-Id: <8803312116.AA06405@megaron.arizona.edu> In-Reply-To: <44149@Wayne-MTS> To: icon-group Subject: Re: Co-expressions: their uses and non-uses Errors-To: icon-group-errors > From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu > To: icon-group@arizona.edu > > 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!Paul_Abrahams%Wayne-MTS@um.cc.umich.edu > > 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: Date: Mon, 4 Apr 88 19:19:36 CDT From: Richard Goerwitz Message-Id: <8804050019.AA03836@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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 Subject: Possible bug in getch() in MS-DOS version 7 To: icon-group@arizona.edu X-Vms-Mail-To: EXOS%"icon-group@megaron.arizona.edu" Message-Id: <880405141933.0000052A081@CIM-VAX.HONEYWELL.COM> Errors-To: icon-group-errors ## yesno -- a program to allow manual filtering of lines through a pipe # Try testing with "iconx yesno 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 -- DSCARGO@CIM-VAX.HONEYWELL.COM 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: Date: Tue, 5 Apr 88 17:20:59 CDT From: Richard Goerwitz Message-Id: <8804052220.AA05921@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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 Subject: Particulars on Icon 7 for MS-DOS where bug believed found To: icon-group@arizona.edu X-Vms-Mail-To: EXOS%"icon-group@megaron.arizona.edu" Message-Id: <880406140008.00000367081@CIM-VAX.HONEYWELL.COM> 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: <8804071543.AA01091@megaron.arizona.edu> 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: 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" Message-Id: <8804071640.AA04410@megaron.arizona.edu> In-Reply-To: <8804052220.AA05921@sophist.uchicago.edu> 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 > > [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 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" Message-Id: <8804081630.AA04527@megaron.arizona.edu> In-Reply-To: <46251@Wayne-MTS> To: icon-group Subject: Re: another example of co-expressions Errors-To: icon-group-errors [Really From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu] 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" Message-Id: <8804071640.AA04410@megaron.arizona.edu> In-Reply-To: <8804052220.AA05921@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: Re: Bad idea? Good idea? Errors-To: arizona.edu!icon-group-errors%cogsci.Berkeley.EDU@ucbvax.Berkeley.EDU Errors-To: icon-group-errors > Date: Tue, 5 Apr 88 17:20:59 CDT > From: Richard Goerwitz > > [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 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" Message-Id: <8804081630.AA04527@megaron.arizona.edu> In-Reply-To: <46251@Wayne-MTS> To: icon-group@arizona.edu Subject: Re: another example of co-expressions Errors-To: arizona.edu!icon-group-errors%cogsci.Berkeley.EDU@ucbvax.Berkeley.EDU Errors-To: icon-group-errors [Really From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu] 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" Message-Id: <8804120458.AA13859@megaron.arizona.edu> To: icon-group In-Reply-To: <8804071640.AA04410@megaron.arizona.edu> Subject: Bad idea? Good idea? Errors-To: icon-group-errors Date: Thu, 7 Apr 88 09:40:36 MST From: "Kenneth Walker" ... 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 gudeman@arizona.edu 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 Subject: environment variables To: icon-group@arizona.edu X-Vms-Mail-To: EXOS%"icon-group@megaron.arizona.edu" Message-Id: <880414134311.00000330071@CIM-VAX.HONEYWELL.COM> 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 (DSCARGO@CIM-VAX.HONEYWELL.COM) 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: Date: Sun, 17 Apr 88 14:12:57 CDT From: Richard Goerwitz Message-Id: <8804171912.AA05765@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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: corre@csd4.milw.wisc.edu (Alan D Corre) Organization: University of Wisconsin-Milwaukee Subject: Re: Bad idea? Good idea? Message-Id: <5574@uwmcsd1.UUCP> References: <8804071640.AA04410@megaron.arizona.edu>, <8804120458.AA13859@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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: mo@uunet.uu.net (Mike O'Dell) Organization: UUNET Communications Services, Arlington, VA Subject: icon implementation for SUNs Message-Id: <11640@uunet.UU.NET> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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!steveh@Sun.COM (Steve Holden - Sun UK TSE) Message-Id: <8804181235.AA08725@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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 sholden@sun.com 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: Date: Mon, 18 Apr 88 14:03:27 CDT From: Richard Goerwitz Message-Id: <8804181903.AA08436@sophist.uchicago.edu> To: icon-group@arizona.edu 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" Message-Id: <8804181915.AA07427@megaron.arizona.edu> To: goer@sophist.uchicago.edu Subject: Re: Still don't understand (thick head?) Cc: icon-group In-Reply-To: <8804181903.AA08436@sophist.uchicago.edu> 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 +1 602 621 6609 ralph@Arizona.EDU {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" Message-Id: <8804181954.AA09155@megaron.arizona.edu> In-Reply-To: <8804181903.AA08436@sophist.uchicago.edu> 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 ... > 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 +1 602 621 2858 kwalker@Arizona.EDU {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: Date: Mon, 18 Apr 88 19:54:55 CDT From: Richard Goerwitz Message-Id: <8804190054.AA09145@sophist.uchicago.edu> To: kwalker@arizona.edu Subject: Re: Still don't understand (thick head?) Cc: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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: <8804190109.AA01683@megaron.arizona.edu> 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: 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:+1 312 416-7285 fax: +1 312 416-7480 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: <8804190109.AA01695@megaron.arizona.edu> 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 (312) 510-6194 ' ) ) The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill. / (_ 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 (312) 510-6194 ' ) ) The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill. / (_ Message-Id: <8804190120.AA03857@megaron.arizona.edu> 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 +1 602 621 6609 ralph@Arizona.EDU {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" Message-Id: <8804190440.AA09819@megaron.arizona.edu> To: icon-group Subject: v7 performance Errors-To: icon-group-errors > Date: Mon, 18 Apr 88 19:54:55 CDT > From: Richard Goerwitz > > 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 +1 602 621 2858 kwalker@Arizona.EDU {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: wgg@june.cs.washington.edu (William Griswold) Return-Path: Message-Id: <8804242327.AA08935@june.cs.washington.edu> To: icon-group@arizona.edu 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 wgg@june.cs.washington.edu 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" Message-Id: <8804250931.AA25208@megaron.arizona.edu> To: wgg@june.cs.washington.edu Cc: icon-group@arizona.edu In-Reply-To: <8804242327.AA08935@june.cs.washington.edu> 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: wgg@june.cs.washington.edu (William Griswold) Return-Path: Message-Id: <8804250945.AA19922@june.cs.washington.edu> To: gudeman@arizona.edu, wgg@june.cs.washington.edu Subject: Re: object oriented Icon Cc: icon-group@arizona.edu Errors-To: icon-group-errors From: "David Gudeman" To: wgg@june.cs.washington.edu Cc: icon-group@arizona.edu 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" Message-Id: <8804260531.AA13965@megaron.arizona.edu> To: wgg@june.cs.washington.edu Cc: icon-group In-Reply-To: <8804250945.AA19922@june.cs.washington.edu> 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 Message-Id: <8804261555.AA05301@eos.arc.nasa.gov> To: gudeman@arizona.edu, wgg@june.cs.washington.edu Subject: Re: object oriented Icon Cc: icon-group@arizona.edu, shafto@EOS.ARC.NASA.GOV 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" Message-Id: <8804261956.AA13125@megaron.arizona.edu> To: icon-group In-Reply-To: <8804261555.AA05301@eos.arc.nasa.gov> 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: cjeffery@arizona.edu (Clinton Jeffery) Organization: U of Arizona CS Dept, Tucson Subject: Re: object oriented Icon Message-Id: <5185@megaron.arizona.edu> References: <8804261956.AA13125@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-errors From article <8804261956.AA13125@megaron.arizona.edu>, by gudeman@ARIZONA.EDU: > "... 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 | cjeffery@arizona.edu -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 Message-Id: <8804271536.AA04688@eos.arc.nasa.gov> To: cjeffery@arizona.edu, icon-group@arizona.edu Subject: Re: object oriented Icon Cc: shafto@AMES-AURORA.ARPA Errors-To: icon-group-errors >>From article <8804261956.AA13125@megaron.arizona.edu>, by gudeman@ARIZONA.EDU: >> "... 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: wgg@june.cs.washington.edu (William Griswold) Return-Path: Message-Id: <8804271923.AA16088@june.cs.washington.edu> To: icon-group@arizona.edu 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" Message-Id: <8804280121.AA28479@megaron.arizona.edu> To: icon-group In-Reply-To: <5185@megaron.arizona.edu> 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: wgg@june.cs.washington.edu (Manu Dibango) Return-Path: Message-Id: <8804280738.AA17065@june.cs.washington.edu> To: icon-group@arizona.edu 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" Message-Id: <8804281201.AA21253@megaron.arizona.edu> 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 goer@sophist.uchicago.edu !ihnp4!gargoyle!sophist!goer ================================================================================ Ralph Griswold / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU {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" Message-Id: <8804281825.AA10836@megaron.arizona.edu> To: wgg@june.cs.washington.edu Cc: icon-group In-Reply-To: <8804280738.AA17065@june.cs.washington.edu> 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 Date: Thu, 28 Apr 88 22:59:18 bst Message-Id: <18285.8804282159@aiva.ed.ac.uk> To: gudeman@arizona.edu Subject: Re: object oriented languages Cc: icon-group@arizona.edu Errors-To: icon-group-errors > Date: Thu, 28 Apr 88 11:25:29 MST > From: David Gudeman > 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: wgg@june.cs.washington.edu (William Griswold) Return-Path: Message-Id: <8804282219.AA04623@june.cs.washington.edu> To: icon-group@arizona.edu 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: <8804282230.AA28219@megaron.arizona.edu> 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: 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!steveh@Sun.COM (Steve Holden - Sun UK TSE) Message-Id: <8804291015.AA00553@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM Subject: Re: object oriented Icon Errors-To: icon-group-errors "David 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" Message-Id: <8804291826.AA19979@megaron.arizona.edu> To: icon-group In-Reply-To: <8804291015.AA00553@stevie.nuksun.uucp> 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: cjeffery@arizona.edu (Clinton Jeffery) Organization: U of Arizona CS Dept, Tucson Subject: Re: object oriented languages Message-Id: <5243@megaron.arizona.edu> References: <8804280738.AA17065@june.cs.washington.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-errors From article <8804280738.AA17065@june.cs.washington.edu>, by wgg@june.cs.washington.EDU (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 | cjeffery@arizona.edu -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: mccarrol@topaz.rutgers.edu (Mark C. Carroll ) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: object oriented Icon Message-Id: References: <8804271536.AA04688@eos.arc.nasa.gov> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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 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! -- =Mark C. Carroll,Rutgers CS Student| I won't wear your white feather mail to: ARPA: CARROLL@AIM.RUTGERS.EDU | I won't carry your white flag UUCP: mccarrol@topaz.rutgers.edu | 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" Message-Id: <8805020610.AA27944@megaron.arizona.edu> To: mccarrol@topaz.rutgers.edu Cc: icon-group@arizona.edu In-Reply-To: mccarrol@topaz.rutgers.edu (Mark C. Carroll's message of 1 May 88 00:24:09 GMT 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" Message-Id: <8805020626.AA28525@megaron.arizona.edu> To: icon-group In-Reply-To: <8805020610.AA27944@megaron.arizona.edu> Subject: Icon group Errors-To: icon-group-errors Date: Sun, 1 May 88 23:10:55 MST From: "David 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 Date: Wed, 4 May 88 09:35:28 BST Message-Id: <6888.8805040835@qmcms.maths.qmc.ac.uk> To: cjeffery@arizona.edu, icon-group@arizona.edu 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 >| cjeffery@arizona.edu -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: Date: Fri, 6 May 88 05:25:34 CDT From: Richard Goerwitz Message-Id: <8805061025.AA03273@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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: <8805062020.AA20810@megaron.arizona.edu> 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 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_ Message-Id: <8805062104.AA27041@june.cs.washington.edu> To: icon-group@arizona.edu Subject: Re: C++ and Icon (was: object oriented Icon) Errors-To: icon-group-errors This message is in response to: From: ihnp4!ihlpf!nevin1@arizona.edu 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" Message-Id: <8805062110.AA24615@megaron.arizona.edu> In-Reply-To: <8805062020.AA20810@megaron.arizona.edu> 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 +1 602 621 2858 kwalker@Arizona.EDU {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!nevin1@ucbvax.Berkeley.EDU (00704a-Liber) Organization: AT&T Bell Laboratories - Naperville, Illinois Subject: C++ and Icon (was: object oriented Icon) Message-Id: <4672@ihlpf.ATT.COM> References: <8804282230.AA28219@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_ Message-Id: <8805072304.AA09918@june.cs.washington.edu> To: icon-group@arizona.edu 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!steveh@Sun.COM (Steve Holden - Sun UK TSE) Message-Id: <8805090952.AA09263@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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 sholden@sun.com 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: Date: Mon, 9 May 88 18:42:34 CDT From: Richard Goerwitz Message-Id: <8805092342.AA07866@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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: Date: Mon, 9 May 88 18:34:39 CDT From: Richard Goerwitz Message-Id: <8805092334.AA07855@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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" Message-Id: <8805102140.AA08117@megaron.arizona.edu> In-Reply-To: <8805092334.AA07855@sophist.uchicago.edu> 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 > > 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 +1 602 621 2858 kwalker@Arizona.EDU {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: <8805101429.AA17587@megaron.arizona.edu> Date: Tue, 10 May 88 09:07 CST From: "Many people would rather die than think; in fact, most do." Subject: call-by-string procedures? To: icon-group@arizona.edu X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu" 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: UNOCC07%ZEUS.DNET@FERGVAX.UNL.EDU Campus Computing | UUCP: ihnp4!unocss!dent University of Nebraska at Omaha | ARPAnet: dent@fergvax.unl.edu Omaha, NE 68182 | Bitnet: dc3a+@andrew.cmu.edu 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" Message-Id: <8805110443.AA26874@megaron.arizona.edu> 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: <8805171331.AA01547@megaron.arizona.edu> Date: Mon, 16 May 88 22:00 CST From: "Many people would rather die than think; in fact, most do." Subject: string invocation followup To: icon-group@arizona.edu X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu" 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: UNOCC07%ZEUS.DNET@FERGVAX.UNL.EDU Campus Computing | UUCP: ihnp4!unocss!dent University of Nebraska at Omaha | ARPAnet: dent@fergvax.unl.edu Omaha, NE 68182 | Bitnet: dc3a+@andrew.cmu.edu 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: <8805171331.AA01543@megaron.arizona.edu> Date: Mon, 16 May 88 22:13 CST From: "Many people would rather die than think; in fact, most do." Subject: Custom iconx: fxsys.c ? To: icon-group@arizona.edu X-Vms-To: CRCVMS::IN%"icon-group@arizona.edu" 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: UNOCC07%ZEUS.DNET@FERGVAX.UNL.EDU Campus Computing | UUCP: ihnp4!unocss!dent University of Nebraska at Omaha | ARPAnet: dent@fergvax.unl.edu Omaha, NE 68182 | Bitnet: dc3a+@andrew.cmu.edu 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: Date: Tue, 17 May 88 16:06:20 CDT From: Richard Goerwitz Message-Id: <8805172106.AA20179@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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" Message-Id: <8805180210.AA24973@megaron.arizona.edu> To: goer@sophist.uchicago.edu, icon-group@arizona.edu Subject: Programmer-Defined Control Structures In-Reply-To: <8805172106.AA20179@sophist.uchicago.edu> 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!steveh@Sun.COM (Steve Holden - Sun UK TSE) Message-Id: <8805180757.AA18714@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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 sholden@sun.com 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: Date: Wed, 18 May 88 22:03:49 CDT From: Richard Goerwitz Message-Id: <8805190303.AA21819@sophist.uchicago.edu> To: icon-group@arizona.edu 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 goer@sophist.uchicago.edu !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!steveh@Sun.COM (Steve Holden - Sun UK TSE) Message-Id: <8805190845.AA23503@stevie.nuksun.uucp> To: sunuk!sun!sophist.uchicago.edu!goer@Sun.COM Subject: Re: not missing anything Cc: sunuk!sun!arizona.edu!icon-group@Sun.COM 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 icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 May 88 00:08:07 GMT From: portal!cup.portal.com!JJ@uunet.uu.net Organization: The Portal System (TM) Subject: HELP ME!!! Message-Id: <5811@cup.portal.com> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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 icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 88 05:52:05 GMT From: kaon!gide.uchicago.edu!max@oddjob.uchicago.edu (Max Ziff) Organization: University of Chicago Subject: modeling mutual evaluation Message-Id: <305@kaon.uchicago.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu 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 max@gide.UChicago.{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 icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 May 88 15:10:19 GMT From: cd@bu-cs.bu.edu (Clarence K. Din) Organization: Boston Univ. Subject: Re: HELP ME!!! Message-Id: <22861@bu-cs.BU.EDU> References: <5811@cup.portal.com> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <5811@cup.portal.com> JJ@cup.portal.com 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 cd@bu-cs.bu.edu . 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" Message-Id: <8805252315.AA13334@megaron.arizona.edu> Received: by megaron.arizona.edu; Wed, 25 May 88 16:15:41 MST To: icon-group In-Reply-To: <305@kaon.uchicago.edu> Subject: modeling mutual evaluation >From: kaon!gide.uchicago.edu!max@oddjob.uchicago.edu (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 DSCARGO@CIM-VAX.HONEYWELL.COM 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 <0000126E0B1@CIM-VAX.HONEYWELL.COM> ; 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 Subject: Decompiling To: icon-group@arizona.edu X-Vms-Mail-To: EXOS%"icon-group@arizona.edu" Message-Id: <880526092042.0000126E0B1@CIM-VAX.HONEYWELL.COM> 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 (DSCARGO@CIM-VAX.HONEYWELL.COM) 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" Message-Id: <8805261443.AA12612@megaron.arizona.edu> Received: by megaron.arizona.edu; Thu, 26 May 88 07:43:15 MST To: DSCARGO@CIM-VAX.HONEYWELL.COM, icon-group@arizona.edu Subject: Re: Decompiling In-Reply-To: <880526092042.0000126E0B1@CIM-VAX.HONEYWELL.COM> 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!steveh@Sun.COM 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!steveh@Sun.COM (Steve Holden - Sun UK TSE) Message-Id: <8805260751.AA17361@stevie.nuksun.uucp> To: sunuk!sun!arizona.edu!icon-group@Sun.COM 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" Message-Id: <8805262344.AA23839@megaron.arizona.edu> Received: by megaron.arizona.edu; Thu, 26 May 88 16:44:58 MST In-Reply-To: <8805260751.AA17361@stevie.nuksun.uucp> 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 +1 602 621 4325 gmt@Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From bruce@stride.stride.com 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: bruce@stride.Stride.COM (Bruce Robertson) Message-Id: <8805261604.AA23865@stride.Stride.COM> To: JJ@cup.portal.com Cc: icon-group@arizona.edu In-Reply-To: JJ@cup.portal.com's message of 24 May 88 00:08:07 GMT <5811@cup.portal.com> 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!ol@uunet.UU.NET 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: <8805261946.AA13697@inria.inria.fr> 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 To: icon-group@arizona.edu In-Reply-To: "Ralph Griswold"'s message of Thu, 26 May 88 07:43:15 MST <8805261443.AA12612@megaron.arizona.edu> 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" Message-Id: <8805270503.AA05447@megaron.arizona.edu> Received: by megaron.arizona.edu; Thu, 26 May 88 22:03:55 MST To: icon-group@arizona.edu, mcvax!cerisi.cerisi.Fr!ol@uunet.UU.NET Subject: Re: Decompiling In-Reply-To: <8805261946.AA13697@inria.inria.fr> 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 +1 602 621 6609 ralph@Arizona.EDU {allegra|noao|ihnp4}!arizona!ralph From UNOCC07%zeus@crcvms.unl.edu 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: <8805310036.AA13635@megaron.arizona.edu> 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." Subject: The future implementations of Icon To: ICON-GROUP@arizona.edu X-Vms-To: CRCVMS::IN%"ICON-GROUP@ARIZONA.EDU" 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: UNOCC07%ZEUS.DNET@FERGVAX.UNL.EDU Campus Computing | UUCP: ihnp4!unocss!dent University of Nebraska at Omaha | ARPAnet: dent@fergvax.unl.edu Omaha, NE 68182 | Bitnet: dc3a+@andrew.cmu.edu 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" Message-Id: <8805310045.AA14047@megaron.arizona.edu> Received: by megaron.arizona.edu; Mon, 30 May 88 17:45:57 MST To: ICON-GROUP@arizona.edu, UNOCC07%zeus@crcvms.unl.edu Subject: Re: The future implementations of Icon In-Reply-To: <8805310036.AA13635@megaron.arizona.edu> 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 +1 602 621 6609 ralph@Arizona.EDU {allegra|noao|ihnp4}!arizona!ralph