From ralph Sat Jan 24 16:52:26 1987 From: "Ralph Griswold" To: icon-group Subject: Book on the implementation of Icon Status: RO The book on the implementation of the Icon programming language been published. It corresponds to Version 6 of Icon, which is currently running on UNIX, VMS, and MS-DOS computers. The book concentrates on the run-time system and describes data structures, the Icon virtual machine, the interpreter, how generators work, and the techniques for storage allocation and garbage collection. Its appendices include information on modifying and extending the implementation. The publication information is: title: The Implementation of the Icon Programming Language authors: Ralph E. Griswold and Madge T. Griswold publisher: Princeton University Press ISBN 0-691-08431-9 Hardbound, 336 pages, $39.50. The book may be ordered from local bookstores or directly from the publisher: Princeton University Press 3175 Princeton Pike Lawrenceville, NJ 08648 (609) 896-1344 There is no shipping charge for orders sent fourth class. UPS delivery is available for a small additional charge that depends on the destination. There is sales tax of 6.5% in California and 6% in New Jersey. Note: This book is not available from the Icon Project. From wyle%ifi.ethz.chunet@RELAY.CS.NET Fri Jan 30 08:52:35 1987 From: Wyle To: Icon-Group%Arizona.csnet%ifi.ethz.chunet@RELAY.CS.NET Mmdf-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET Cc: Icon-Project%Arizona.csnet%ifi.ethz.chunet@RELAY.CS.NET Subject: icon programming Status: RO I have a student project under design here in which a palatte of icons will be developed for higher level modules in a visual information retrieval system. I am interested in your mailing list. Can you send more information? -- M i t c h e l l F W y l e EEEEE TTTTTT H H Eidgenoessische | wyle%ifi.ethz.chunet@csnet-relay E T H H Technische Hochschule | wyle@ethz.uucp EEEE T HHHHH Zuerich | ...!cernvax!ethz!wyle E T H H Institut fuer Informatik| Telephone: 011 41 1 256 5235 EEEEE T H H 8092 Zuerich, Switzerland| "Ignore alien orders" From ralph Mon Feb 9 14:26:13 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: Status of icon-group Status: RO Several years ago we set up icon-group as a mail-redistribution system whereby addressees on a list kept at the University of Arizona could recieve electronic mail about the Icon programming language and in turn have their mail to icon-group redistributed to others on the list. The idea was to encourage the exchange of information. Historically, most of the mail has originated at the University of Arizona and has consisted mostly of announcements. Relatively few messages have come in from outside the University of Arizona for redistribution. Last July a mail-server bug caused some addressees to receive multiple copies of the same message. Since this was a comparatively serious problem, we disconnected icon-group service. We now have a a way around for the problem. However, the usefulness of icon-group depends on the active participation of its members. Let us hear from you. If you have questions, ask. If you have problems with programming in Icon, try icon-group; perhaps someone can help. For reference, here are the relevant addresses: icon-project@arizona.edu mail just to the Icon Project icon-group@arizona.edu mail for redistribution icon-group list icon-group-request@ariona.edu requests to be added to icon-group From naucse!sbw Mon Feb 9 16:29:03 1987 From: naucse!sbw (Steve Wampler) To: arizona!icon-group Subject: formatting (shudder) in Icon Status: RO I'm looking for nice ways to format floating point numbers in Icon. Something along the lines of: write(format(x,"5.2")) or Write("f5.2 f5.2",x,y) say. Any ideas are welcome, as are other approaches. However, I am not particularly interested in FORTRAN- (or C-)style solutions. -Steve Wampler From amdcad!bandy@decwrl.DEC.COM Tue Feb 10 00:23:43 1987 From: amdcad!bandy@decwrl.DEC.COM (Andy Beals) To: icon-group@arizona.edu Subject: status of icon group Status: RO >From amdcad!bandy@decwrl.DEC.COM Mon Feb 9 16:48:20 1987 To: ralph@arizona.edu Subject: Re: Status of icon-group I admit it! I haven't been using icon at all - I haven't written a single line of code - I'm wasting my time working on a portable c-based snobol4 interpreter. Ouch! Hit me hit me! Seriously though, I think that one of the reasons that the icon-group hasn't gotten much traffic is because there are very few people using it -- imagine how it would be if Icon got the publicity and coverage (in cs courses (they're still teaching snobol in every computing languages survey course I've seen!) as well as useful / fun programs posted to the net) that say (ugh) Modula2 has. How does the current vax (or sun) implementation of icon compare to awk in terms of speed when you use it for reading and decoding uucp LOGFILES or netnews' log file? I think that if you could take Erik Fair's popular scripts that do just these things and convert them to Icon and show that they're faster than the scripts in awk, I'm sure that you could get a lot of system-hacker types interested -- I still manage to write a coupld little awk programs a month, again mostly state-machine file summarizers. ramble ramble ramble andy From ralph Tue Feb 10 04:31:57 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: Icon for the Atari ST Status: RO O. Rick Fonorow and Jerry D. Nowlin report that they have completed an implementation of Version 6.3 of Icon for the Atari ST computer family. The Lattice C compiler was used for the port (giving 32-bit ints). This version takes all available memory, but uses fixed-sized regions for Icon's data. It will run on the 520ST with no other programs (i.e. desk accessories) resident. This implementation is available on the Atari Base BBS: (408) 745-4758. From @po3.andrew.cmu.edu:mss#@andrew.cmu.edu Tue Feb 10 06:56:17 1987 X-Trace: MS Version 3.21 on ibm032 host westchester, by mss (1342). From: mss#@andrew.cmu.edu (Mark Steven Sherman) To: icon-group@arizona.edu Subject: Use in CS classes Cc: amdcad!bandy@decwrl.DEC.COM Status: RO It may have been a while since you were in a comparative languages course. I taught it several times at Dartmouth and we used Icon, not Snobol, and one of the three sections of it here at CMU is also using Icon (the other two are using neither Icon nor Snobol). I think you overestimate the fall-out of usage from these classes of any language. A language gets used by undergrads when their part-time workstudy employer tells them to use it. -Mark From shafto@nprdc.arpa Tue Feb 10 10:12:06 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group@arizona.edu Subject: reads(&input,1) under MSDOS Icon Status: RO Using SNOBOL4+ under MSDOS, I can define keyboard input to be "R,B,Q,1" = Read, Binary, Quiet, 1-character, and I have 1-character input from the keyboard, without echo, which is useful for control characters, function keys, etc., in interactive programs. In Icon under MSDOS, I try to get the same effect by asking for the result of reads(&input,1), but I do NOT get the same effect. reads() waits for a CR. Is anyone else bothered by this problem, and better yet, has anyone fixed it? (You can use the ANSI.SYS-dependent key-redefinition to make control- and function-keys generate a code followed by a CR, but this is inelegant.) Mike Shafto shafto@nprdc Office of Naval Research, Code 1142CS 800 N. Quincy St. Arlington, VA 22217-5000 202/696-4596 From ralph Tue Feb 10 10:20:48 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: reading single characters in MS-DOS Icon Status: RO In response to Mike Shafto's query, there are a number of extensions to MS-DOS Icon that are in the works to solve this problem and in general give the MS-DOS programmer access to almost anything from the Icon source level. I'm not sure how long it will take to get these completed, tested, documented, and packaged for distribution. Perhaps a month. I'll try to get a preliminary description of what's in the works out to icon-group within a week. Ralph Griswold From naucse!sbw Tue Feb 10 10:47:24 1987 From: naucse!sbw (Steve Wampler) To: arizona!mss#@andrew.cmu.edu Subject: Re: Use in CS classes Cc: arizona!icon-group Status: RO I agree. My feeling is that the way to increase the popularity of Icon is by distributing some really useful programs that also show off the power of the language. Icon-group could help do this. From SARASWAT@C.CS.CMU.EDU Tue Feb 10 14:25:54 1987 From: vijay Subject: Increasing the popularity of ICON To: icon-group@arizona.edu Cc: Vijay.Saraswat@C.CS.CMU.EDU Status: RO Or have some country like S.Korea pick it up as the basis for their Next Generation Software Miracle! :-) ------- From notkin@timor.cs.washington.edu Tue Feb 10 16:29:01 1987 To: icon-group@arizona.edu Cc: amdcad!bandy@DECWRL.dec.com, wgg@timor.cs.washington.edu Subject: icon in courses From: David Notkin Status: RO Here at the University of Washington we also teach Icon as part of a junior-level comparative languages class (this year, the other languages we are teaching are Lisp, Prolog, and Smalltalk). It's at least the fourth quarter we are using Icon in this course. David From whm Thu Feb 12 13:45:56 1987 From: "Bill Mitchell" To: icon-group Subject: Re: formatting (shudder) in Icon In-Reply-To: <8702092256.AA17254@naucse> Status: RO I think that Icon's output facilities are really weak with respect to the rest of the language -- all there is a function that concatenates a bunch of strings and prints the result. Purists will no doubt cringe, but I think that C's printf is vastly more usable. For a couple of large projects in Icon I added a C function called format that was really just a front-end to printf's internal routine doprnt, which really does the work. To wit: format(s, x1, ... xn) Returns a string produced by formatting the values x1-xn according the printf-style specification s. For example, write(format("i = %d, hex: %x, octal: %o", i, i, i)) From ralph Thu Feb 12 15:30:30 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: Formatting (shudder) Status: RO I wouldn't argue that a printf-like facility in Icon would not be useful. However, from a language-design viewpoint, I'd rather see something at a higher level. In fact, the real problem is not just output formatting, but the synthesis of strings (witness the usefulness of sprintf in C). I've thought about abstractions for synthesis comparable to the pattern abstractions for analysis. It's possible to formulate some of these in Icon itself, much in the fashion that string scanning and pattern matching can be formulated in Icon to model the built-in facilities. However, while you can argue that analysis and synthesis should be treated symmetrically, it seems there are many more problems that require string analysis than there are that require string synthesis. Hence, it is hard to justify such an elaborate mechanism for synthesis. Of course, if high-level analysis and synthesis could be unified ... From @po3.andrew.cmu.edu:mss#@andrew.cmu.edu Thu Feb 12 17:47:41 1987 X-Trace: MS Version 3.21 on ibm032 host cmu-ws-ardara, by mss (1342). From: mss#@andrew.cmu.edu (Mark Steven Sherman) To: icon-group@arizona.edu Subject: MacIcon Status: RO I think purely by coincidence, the Usenet Macintosh newsgroup started discussing Icon on the Mac. Last I heard, someone was working on it, but I never heard of a release being available from Arizona or anywhere else (there was a suggestion to check on Sumex, which I will do). What is the current status of Icon on the Macintosh? From ralph Thu Feb 12 18:02:36 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: Icon for the Macintosh Status: RO In response to Mark Steven Sherman's query about Icon for the Macintosh: Funny you should ask, as they say; I was preparing an announcement. Here it is: Bob Alexander has completed an implementation of Version 6 of Icon that runs under MPW. It is not a stand-alone application; MPW is required. It is a large-memory model implementation that requires at least a 512K Mac. This implementation is in the public domain and eventually will be available from a variety of sources. We will provide a copy along with printed documentation for $15, payable to the University of Arizona. Add $5 for air mail delivery outside the United States and Canada. Source code and the Icon program library will be available at a later date. Please note: MPW is *required* to run this application. MPW is a window-oriented development system available exclusively through Apple Developer's and Programmer's Association 290 SW 43rd Street Renton, WA 98055 (206) 251-6548 The fee to join APDA is $20 and MPW costs $150. There also is a C compiler, but it is not needed to run Icon. From ralph Thu Feb 12 18:44:13 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: Our Postal Mailing Address Status: RO It only occurred to me after sending information on getting Icon for the Macintosh from us that some of you may not know our postal address. In fact, it recently has acquired an adornment, courtesy of the relocation of our department to a newly constructed building. Here's the best address: Icon Project Department of Computer Science Gould-Simpson Science Building The University of Arizona Tuscon, AZ 87521 Our telephone number remains the same: (602) 621-6613 From gus@shasta.stanford.edu Thu Feb 12 22:11:44 1987 From: Gus Fernandez Subject: Re: Icon for the Macintosh To: icon-group@arizona.edu, ralph@arizona.edu Status: RO From gus@shasta.stanford.edu Thu Feb 12 22:12:05 1987 From: Gus Fernandez Subject: Re: Icon for the Macintosh To: icon-group@arizona.edu, ralph@arizona.edu Status: RO From gus@shasta.stanford.edu Thu Feb 12 22:29:08 1987 From: Gus Fernandez Subject: 8 queens revisited. To: icon-group@arizona.edu Status: RO Hello, I am new to this group, and to ICON, but I would like to discuss two objecttions which I have to the "8 queeens" problem implementation which appears on page 153 of Griswold's book. As a refresher, here it is... procedure main() every write(q(1),q(2),q(3),q(4),q(5),q(6),q(7),q(8)) end procedure q(c) suspend place(1 to 8,c) # Look for a row end procedure place(r,c) static up,down,row initial { up:= list(15,0) down := list(15,0) row := list(8,0) } if row[r] = down[r+c-1] = up[8+r-c] = 0 then suspend row[r] <- down[r+c-1] <- up[8+r-c] <- r # Place if free end My first objection seems to be the necessity of having to explicitly invoke q() 8 times in the main() procedure. Just typing every q(1 to 8) does not work since q(1) immediately succeeds after placing the first queen. Perhaps what I want is a more general itterator which applies the output of a generator to a co-expression and backtracks when necessary. How would one write something like that in ICON? My second objection is to the use of static variables in the place routine. I may have just answered my own question. Make an instance of place into a co- expression, and use it instead of the static variables, but I will have to try it out to see if it works. Does anyone have an elegant way of having two or more queens sequences active, and being able to call on either one to get the next valid queen configuration for that list? This seems easy in a language like smalltalk, but I am convinced that with little work, it should be possible in ICON as well Gus Fernandez From icon-group-request Fri Feb 13 17:41:49 1987 From: "Bill Mitchell" To: icon-group Subject: Testing Icon-Group Errors-To: icon-group-request Status: RO This test should be local only -- my apologies if it goes further. From icon-group-request Fri Feb 13 18:04:23 1987 From: "Bill Mitchell" To: icon-group Subject: mailer improvements Errors-To: icon-group-request Status: RO We've made some changes in the local processing of the list that will hopefully cause failed mail to be redirected back to the icon-group-request address rather than going to the sender of the particular message. If you send a message after today (2/13) and get back failed mail from it, we'd appreciate it if you'd forward the failed messages to icon-group-request. From ralph Sat Feb 14 15:38:01 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: N Queens Errors-To: icon-group-request Status: RO As a partial response to Gus Fernandez' query about the n-queens problem, here is a version from the Icon program library that approaches the situation a little differently from the approach in the Icon book (which is designed to illustrate goal-directed evaluation and data backtracking, rather than the issues Gus Fernandez raised): ========================================================================= # QUEENS # # Solutions to n nonattacking queens # # Stephen B. Wampler # # Last modified 8/14/84 # global n, solution procedure main(args) local i n := args[1] | 6 # 6 queens by default if not(0 < integer(n)) then stop("usage [ n ]") solution := list(n) # ... and a list of column solutions write(n,"-Queens:") every q(1) # start by placing queen in first col. end # q(c) - place a queen in column c. # procedure q(c) local r static up, down, rows initial { up := list(2*n-1,0) down := list(2*n-1,0) rows := list(n,0) } every 0 = rows[r := 1 to n] = up[n+r-c] = down[r+c-1] & rows[r] <- up[n+r-c] <- down[r+c-1] <- 1 do { solution[c] := r # record placement. if c = n then show() else q(c + 1) # try to place next queen. } end # show the solution on a chess board. # procedure show() static count, line, border initial { count := 0 line := repl("| ",n) || "|" border := repl("----",n) || "-" } write("solution: ", count+:=1) write(" ", border) every line[4*(!solution - 1) + 3] <- "Q" do { write(" ", line) write(" ", border) } write() end From icon-group-request Sun Feb 15 00:27:18 1987 Return-Path: From: Bill Kinnersley To: icon-group@arizona.edu Errors-To: icon-group-request Status: RO Well OK, Ralph. I too would like to see more active discussion of Icon in this group. Let me help to start the ball rolling. I am certainly not an Icon expert. I have been fascinated with the language for the past two years, and I taught it to my class in Programming Language Design. What puzzles me is how little I use it. Our conclusion in class was that Icon was much more in the experimental stage than Smalltalk, Prolog, etc. According to the book, Icon is good for string processing, quick one-shot programs, and heuristic solutions to complex problems. In other words, AI. From an internal point of view, surely the central feature of the language is generators. Most of the cost of Icon implementation must be allowing each and every expression to be a generator. One needs to ask, therefore, whether that feature is worth the cost. From my own ignorant and biased perspective, let's list some good points and some bad... Syntax - I find the syntax natural, and the innovations particularly appealing. :=: and "break break" should be in every language. Csets - No use for this, myself. Lists - One of Icon's best aspects. Much easier to use than Lisp. I do get confused between get(), put(), push(), and pop(). My impression is that many of the things that used to be done using string manipulation are better done with lists anyway. Implicit type conversion - not such a great idea. Mainly it's the conversion to and from strings that's unusual, and I'd rather do it explicitly when I really need to. Typelessness of variables has an unpleasant side effect-- It puts the burden on the operators to decide the type of an outcome, and as a result there are FAR TOO MANY operators. Mentioning ~===:= to the class is always good for a giggle. Procedure invocation - again very nicely done. Generators - outside the string-search context, I find it a little hard to explain what these are, and what they're good for. Me: "Well, they're like a generalized for loop. Suppose you didn't want to just go 1, 2, 3, ... say, but for every number obeying some complicated condition..." Student: "Well then, I'd use a while loop, and write a subroutine with some static variables, and I'd just keep calling that to get the next number." Me: "Yes, but this is cleaner conceptually. And more general. And you can write your own generators...and, uh, in fact they look just like subroutines, only they suspend." (Student stares at me, and whispers something to his neighbor. Other student smiles and nods his head.) Seriously, as the heart and soul of Icon, generators need a strong sales push. Do they really open up new worlds, or are they rarely used and easy to simulate? Go through a book on algorithms and count how many times a generator would come in handy. Backtracking - this is great! One of the real reasons for choosing Icon to program in. The Eight Queens problem deserves its place on the cover, and it's not too hard to produce other examples which are equally impressive. Suggestion: Here's a common situation that needs to be handled better. Where it says write (q(1), q(2), q(3), q(4), q(5), q(6), q(7), q(8)) Remember that? This is a trick we use to get the q's to mutually succeed. Or, we could have used q(1) & q(2) & ... This does come up a lot, and it can get out of hand pretty quickly if there are more than 8 items. Maybe what we need is a new construct: all q(1 to 8) Summary - We teach that a well designed programming language is more than a collection of useful features. It must have a uniform syntax, an easily-expressed purpose and philosophy, and a set of features which are consistent, powerful, and thrifty. Often as not, a language can be improved by removing features, not just adding. Object-oriented languages are all the rage these days. People are diligently putting objects into Pascal, C, Lisp, etc. For heavens sakes, don't anyone try to do that to Icon! From mark Sun Feb 15 09:41:19 1987 From: "Mark L. Langley" To: icon-group@arizona.edu, kinner%wsu.csnet@RELAY.CS.NET Subject: Kinnersley Comments In-Reply-To: <8702150726.AA24707@arizona.arizona.edu> Errors-To: icon-group-request Status: RO I enjoyed the comments of Bill Kinnersley. I would like to add to them with my own perspective remarks... According to the book, Icon is good for string processing, quick one-shot programs, and heuristic solutions to complex problems. In other words, AI. >From an internal point of view, surely the central feature of the language is generators. Most of the cost of Icon implementation must be allowing each and every expression to be a generator. One needs to ask, therefore, whether that feature is worth the cost. My experience is that the central feature or the language is data structures and the unique control mechanisms exist to manipulate them with idiomatic operations! I acknowledge that generators-in-a-vacuum seem kind of odd. But the key is that I always use generators with something particular in mind. For example emumerating the elements of a list or string with '!'. The non-icon way of enumerating the elements of some data structure is by producing successive subscripts or dereferencing consecutive pointers. In Icon, you just say every i := !Thing do do_something(i) Thus one can eliminate the subscript-scaffolding present in other flavors of solutions. The word-parsing programs in the book are another good example. You just want to say -- "Yea, I figured out how to get the first one, you go get the next one..." Csets - No use for this, myself. The key to Csets is that most string-functions take a cset as an argument. They simply represent a character class in pattern matching, I've found. Implicit type conversion - not such a great idea. Mainly it's the conversion to and from strings that's unusual, and I'd rather do it explicitly when I really need to. Typelessness of variables has an unpleasant side effect-- It puts the burden on the operators to decide the type of an outcome, and as a result there are FAR TOO MANY operators. Mentioning ~===:= to the class is always good for a giggle. Interesting point. As for the string-to-number property, It is nice to be able to read something in and have it be added to at the same time. It would be nice if you could trap errors though, rather than have to check explicitly in advance... ie t := 0 while (t +:= read()) write (t) and t := 0 while (t +:= number(read()) | tilt()) write (t) My own personal objections are that functions can be overwritten but not defined on the fly. And there are severe performance penalties for having to check the type of an object (which is syntacticaly a function) before calling it. (ie someone may overwrite "write"...) I particularly don't like the global side effect of overwriting "write". ie if I say write := foonley Then it tries to call foonley the next time I call write, since functions are first class objects with global scope. From gudeman Sun Feb 15 14:19:52 1987 From: "David Gudeman" To: icon-group@arizona.edu In-Reply-To: Bill Kinnersley's message of Sat, 14 Feb 87 10:36:44 PST Subject: generators and backtracking Errors-To: icon-group-request Status: RO Date: Sat, 14 Feb 87 10:36:44 PST From: Bill Kinnersley ... Seriously, as the heart and soul of Icon, generators need a strong sales push. Do they really open up new worlds, or are they rarely used and easy to simulate? Go through a book on algorithms and count how many times a generator would come in handy. Backtracking - this is great! One of the real reasons for choosing Icon to program in. The Eight Queens problem deserves its place on the cover, and it's not too hard to produce other examples which are equally impressive. It seems that a lot of people think of generators as "just a sort of implicit loop". They are actually much more than that, specifically, they are the mechanism on which backtracking is based. It is hard to imagine how there could be backtracking without generators. So if you think backtracking is great, you should like generators. From icon-group-request Sun Feb 15 14:58:51 1987 From: nessus@EDDIE.MIT.EDU (Doug Alan) To: icon-group@arizona.edu Subject: Re: generators and backtracking Errors-To: icon-group-request Status: RO Personally, I think that generators are much more important than backtracking. Generators are a good form "control abstraction", which is just as essential, but much more often neglected than, procedural abstraction and data abstraction. Saying "I don't need generators -- I could do that in a for loop," is like saying "I don't need procedures -- I can just stick the code for that right in here." Control abstraction allows you to provide, for example, a way of iterating through all the components of an abstract data type in a way that may not be possible otherwise without violating the interface of the abstract data type. It provides a clean and simple mechanism for doing co-routining. Generators are a clean generalization of data streams. Instead they are computation streams. |>oug /\lan -- Nessus@Eddie.MIT.EDU {allegra,seismo,decvax!genrad}!mit-eddie!nessus MIT, E40-358a, Cambridge, MA 02139 (617) 253-0147 From icon-group-request Sun Feb 15 16:21:01 1987 From: wgg@june.cs.washington.edu (William Griswold) Return-Path: To: icon-group@arizona.edu, nessus@EDDIE.MIT.edu Subject: Re: generators and backtracking Errors-To: icon-group-request Status: RO I like Doug Alan's comments on generators supporting computation streams. One thing I would like to point out is that computation streams, unlike data streams, experience false dead-ends. To generate all possible results in a computation stream it is absolutely necessary to backtrack from a given result and find another one. Even the simplist case of generating all the elements in a list requires this. The concept of a generator is a control structure for implementing backtracking. The two are in fact the same thing. The Icon book describes Icon's evaluation method as ``goal directed''. When thought of this way, the duality of generators versus backtracking should vanish. Bill Griswold From ralph Mon Feb 16 10:54:26 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: Enhancements to Version 6 of Icon for MS-DOS Errors-To: icon-group-request Status: RO What follows is a condensed version of working notes from Cheyenne Wills for the enchancements he has implemented for MS-DOS Icon. I've left out details of error and failure conditions, examples, and so forth, in the interests of brevity. I'll be happy to mail a copy of the complete notes to ineterested persons. Comments are welcome and will be passed on to Cheyenne. - Ralph Griswold ralph@arizona.edu ========================================================================= Console input routines: getch() Wait until a keyboard character is available. Then return a one-character string containing it. The character is not displayed on the screen. getch() returns a "\0" value for a character that doesn't have a ASCII equivalent. The next call to getch returns the keyboard scan code. getche() Same as getch() except that characters are echoed as they are typed. kbhit() Succeeds if there is a character available for getch or getche. Otherwise it fails. ========================================================================= Miscelaneous functions: getenv(s) Return contents of environment variable s. It fails if s is not in environment. seek(f,i1,i2) Seek to offset byte from start in file. Returns byte offset within file. fails if an error occurs. ========================================================================= MS-DOS interface routines: Disclaimer: The following routines are included as a "gateway" to functions provided by MS-DOS and ROM BIOS. They should be used with care, as Icon maintains a strict control on its environment (although it uses standard MS-DOS interfaces and doesn't bypass MS-DOS or ROM BIOS in any way). The descriptions that follow are low-level descriptions. They assume knowlege of the Intel 8086 (8088, 80x86 etc.) architecture. Int86(l) Generate a hardware interrupt. The input (l) is a list of integer values [interrupt #, ax, bx, cx, dx, si, di, es, ds] It returns a list: [flags, ax, bx, cx, dx, si, di, es, ds]. GetSpace(i) Allocate a static block of storage outside of Icon's direct control (i.e., it will not be affected by garbage collection). FreeSpace(A) Free a static block of storage. A is the value returned by GetSpace. Peek(A,i) Build a string pointing to the address specified by A with a length of i. Poke(A,s) Copy a string s to location A From icon-group-request Mon Feb 16 16:08:51 1987 From: "Bill Mitchell" To: ralph Subject: Re: Enhancements to Version 6 of Icon for MS-DOS Cc: icon-group@arizona.edu In-Reply-To: <8702161754.AA10393@megaron.arizona.edu> Errors-To: icon-group-request Status: RO Gosh, those MS-DOS guys have it made. I've been wanting a getenv in UNIX Icon for years and still no luck. From icon-group-request Mon Feb 16 18:15:11 1987 From: "Bill Mitchell" To: icon-group Subject: Re: Formatting (shudder) In-Reply-To: <8702122230.AA03382@megaron.arizona.edu> Errors-To: icon-group-request Status: RO From ralph Thu Feb 12 15:30:48 1987 To: icon-group@arizona.edu Subject: Formatting (shudder) I wouldn't argue that a printf-like facility in Icon would not be useful. However, from a language-design viewpoint, I'd rather see something at a higher level. In fact, the real problem is not just output formatting, but the synthesis of strings (witness the usefulness of sprintf in C). String synthesis is an interesting problem, but I don't often find myself wanting more string synthesis facilities, but the lack of formatting capabilities darkens my Icon programs on very regular basis. It seems that the printf syntax is really fairly good -- it's concise, it doesn't try to do everything, and it usually covers all the bases. I don't recall anything that I like better than printf; are there simple formatting methods that are preferred by others? I'd imagine that the printf syntax was inspired by FORTRAN's FORMAT. Was FORMAT in the very first FORTRAN? If so, is that to say that we really haven't had any advances in this area? From icon-group-request Tue Feb 17 07:55:27 1987 From: Guy Lapalme To: icon-group@arizona.edu Subject: string formatting Errors-To: icon-group-request Status: RO I think that people that are only considering C and Fortran like formatting facilities should look at what is done in COBOL using the "PICTURE" specifications. Given that icon is not in the same class as COBOL, but the formatting specifications are very well done. Should somebody really want high level formatting specifications, go and see what was done in Algol-68, you'll see a quite simple and efficient way (and very systematic too) approach to formatting. It would surely be interesting to write and Icon procedure that implements Algol68 IO. As Algol68 was meant to be compiled, it does not need to be all interpreted at run-time. I also want to point out that Common Lisp has a very extensive (if not too much) set of formatting commands in which you can even write number in roman or in letters, you can right justify paragraphs etc... Guy Lapalme Universite de Montreal From icon-group-request Tue Feb 17 14:03:33 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group-request@arizona.edu Subject: Rolling the ball Cc: icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO Original message From: Bill Kinnersley To: icon-group@arizona.edu Errors-To: icon-group-request@arizona.edu I am certainly not an Icon expert. I have been fascinated with the language for the past two years, and I taught it to my class in Programming Language Design. What puzzles me is how little I use it. Our conclusion in class was that Icon was much more in the experimental stage than Smalltalk, Prolog, etc. ----- I'm not sure what "experimental" means. All I know is that I have some very practical programs which I use every day for budget-management and for managing a volatile set of distribution lists. I maintain these programs myself, even though I'm far from being a professional programmer, and I really have zero time to devote to software development/maintenance. The exact same programs run on a Zenith 120 (not IBM compatible), IBM-XT, Leading Edge, KayPro, Vax 11/780 running Unix, Vax 11/750 running VMS, and an Apollo. For general usability and portability, what language compares with Icon? Smalltalk? Prolog?? Lisp??? Get serious. ----- According to the book, Icon is good for string processing, quick one-shot programs, and heuristic solutions to complex problems. In other words, AI. ----- I think Icon falls a little short as an "AI language," due to the fact that -- for example -- there aren't full-fledged analogues to SNOBOL4's EXPRESSION, PATTERN, and CODE datatypes. I believe SNOBOL4 and LISP are the only generally available languages which support the full range of atrocities needed for he-man AI. ----- >From an internal point of view, surely the central feature of the language is generators. Most of the cost of Icon implementation must be allowing each and every expression to be a generator. One needs to ask, therefore, whether that feature is worth the cost. >From my own ignorant and biased perspective, let's list some good points and some bad... Syntax - I find the syntax natural, and the innovations particularly appealing. :=: and "break break" should be in every language. ----- I did an experiment recently in which I sent a 25-line Icon program to a friend who was familiar with Pascal but not Icon. My program was uncommented & I challenged him to figure out what it did & insert comments. He wass able to do this perfectly (Except: he enclosed the comments in /* */) and even to provide one slight re-write. Since I did this as an afterthought, having written the program for a typically Icon-ish ad hoc purpose, I think it provides a fair demonstration of what one might mean by "natural syntax." ----- Csets - No use for this, myself. Lists - One of Icon's best aspects. Much easier to use than Lisp. I do get confused between get(), put(), push(), and pop(). My impression is that many of the things that used to be done using string manipulation are better done with lists anyway. Implicit type conversion - not such a great idea. Mainly it's the conversion to and from strings that's unusual, and I'd rather do it explicitly when I really need to. Typelessness of variables has an unpleasant side effect-- It puts the burden on the operators to decide the type of an outcome, and as a result there are FAR TOO MANY operators. Mentioning ~===:= to the class is always good for a giggle. ----- Agree re: lists. Disagree re: implicit type conversion. In my opinion, you leave the realm of byte-pushing and enter the realm of high-level programming languages when memory management and typing are handled as transparently as possible. ----- Procedure invocation - again very nicely done. Generators - outside the string-search context, I find it a little hard to explain what these are, and what they're good for. Me: "Well, they're like a generalized for loop. Suppose you didn't want to just go 1, 2, 3, ... say, but for every number obeying some complicated condition..." Student: "Well then, I'd use a while loop, and write a subroutine with some static variables, and I'd just keep calling that to get the next number." Me: "Yes, but this is cleaner conceptually. And more general. And you can write your own generators...and, uh, in fact they look just like subroutines, only they suspend." (Student stares at me, and whispers something to his neighbor. Other student smiles and nods his head.) Seriously, as the heart and soul of Icon, generators need a strong sales push. Do they really open up new worlds, or are they rarely used and easy to simulate? Go through a book on algorithms and count how many times a generator would come in handy. ----- I generally disagree with the above, but it raises an interesting issue in conjunction with the earlier "multiplicity of operators" observations: Why are there so many different operators in a language in which you get so much mileage out of the humble "!" operator? Or, why isn't == as generic as !? ----- Backtracking - this is great! One of the real reasons for choosing Icon to program in. The Eight Queens problem deserves its place on the cover, and it's not too hard to produce other examples which are equally impressive. Suggestion: Here's a common situation that needs to be handled better. Where it says write (q(1), q(2), q(3), q(4), q(5), q(6), q(7), q(8)) Remember that? This is a trick we use to get the q's to mutually succeed. Or, we could have used q(1) & q(2) & ... This does come up a lot, and it can get out of hand pretty quickly if there are more than 8 items. Maybe what we need is a new construct: all q(1 to 8) Summary - We teach that a well designed programming language is more than a collection of useful features. It must have a uniform syntax, an easily-expressed purpose and philosophy, and a set of features which are consistent, powerful, and thrifty. Often as not, a language can be improved by removing features, not just adding. Object-oriented languages are all the rage these days. People are diligently putting objects into Pascal, C, Lisp, etc. For heavens sakes, don't anyone try to do that to Icon! ----- That's a big 10-4! Although I've found the added feature of true sets to be enormously useful. Oddly, tables and lists can be quite awkward (at least conceptually) when what you want is sets. ----- ----- From icon-group-request Tue Feb 17 14:04:12 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: ralph@arizona.edu Subject: Re: Enhancements to Version 6 of Icon for MS-DOS Cc: icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO I'm an interested person. You can mail me a copy of Wills's complete notes at the following address: Dr. Michael G. Shafto Office of Naval Research, Code 1142CS 800 N. Quincy Street Arlington, VA 22217-5000 Also, I'm ready to mail in my 25 bucks or whatever when these enhancements are released. Mike From icon-group-request Fri Feb 20 19:10:34 1987 From: "Bill Mitchell" To: icon-group Subject: .2 + .2 = 4 Errors-To: icon-group-request Status: RO It's true that in the Icon book a decimal literal, a type of real constant, is defined as: digit+ . digits* but it seems to me that it's not hard to imagine someone writing something like x := y * .9 and then being surprised that x = y * 9 . I just did this and must admit that I was mystified for an embarrassing length of time. A quick look at tran/lex.c seems to indicate that this wouldn't be hard to arrange -- if the current character is '.', peek at the next character and if it's a digit, call getnum instead of gathering an operator. getnum would also need a little work, but considering the likelihood of others falling over this (any victims out there?), it seems like a reasonable thing to do. From icon-group-request Fri Feb 20 19:14:51 1987 From: "Ralph Griswold" To: icon-group, whm Subject: Re: .2 + .2 = 4 In-Reply-To: <8702210210.AA25290@megaron.arizona.edu> Errors-To: icon-group-request Status: RO Since the unary prefix operator does dereferencing, there is a fundamental ambiguity. SNOBOL4 has it too. I, for one, while I realize the pitfall, would have trouble with .2 and .x (not to mention ."2") being treated in fundamentally different ways. cheer up ... .2 + .2 = .4 From icon-group-request Sat Feb 21 01:45:38 1987 To: icon-group%arizona.edu@relay.cs.csnet From: U249101%HNYKUN11.BITNET@WISCVM.WISC.EDU Subject: Icon in Holland Errors-To: icon-group-request Status: RO Date: 19 February 1987, 13:33:41 MET From: Jan Blom U249101 at HNYKUN11 To: ICON-GROUP at ARIZONA.EDU I'm glad to see that the Icon-group functions after all! We use Icon here on a VAX/750 (VMS), and it also appears to run on a Microvax II under MicroVMS. I would like to know what implementations are available for Atari/ST and MS/DOS machines, and how I can obtain them here in Europe (Holland). Jan Blom From icon-group-request Sat Feb 21 06:13:19 1987 From: "Ralph Griswold" To: U249101%HNYKUN11.BITNET@WISCVM.WISC.EDU, icon-group Subject: Re: Icon in Holland In-Reply-To: <8702210845.AA02934@arizona.arizona.edu> Errors-To: icon-group-request Status: RO Thanks for letting us know about your use of Icon. Icon is available both for the Atari ST and for MS-DOS. The Atari implementation is available for downloading frm the Atari Base BBS in this country. I don't know if there is a corresponding service in Europe. We do not have an Atari ST locally and did not do the implementation of Icon for it, so our ability to help you is limited. I will, however, forward your request to the person who did the implementation. We distribute the MS-DOS implementation and I'll send you a recent Icon Newletter describing how you can get this implementation from us. We have no "distributors" in Europe, although there are many persons there who have Icon, including a good number in your country. You raise a question that has come up several times -- how persons in countries that are inconveniently distant from ours can get Icon locally. We encourage persons to install Icon on electronic bulletin boards and since the implement- ations are in the public domain, anyone can serve as a distributor. We would welcome volunteers and will pass along information that we get about such services. From icon-group-request Sat Feb 21 12:23:05 1987 From: "Gregg Townsend" To: icon-group Subject: Re: .2 + .2 = 4 Errors-To: icon-group-request Status: RO I've also been bitten by the problem of trying to write a real as .nnn and instead finding that I was really dereferencing an integer. I had a little one-shot program which went every r := 0 to 7 do every g := 0 to 7 do every b := 0 to 7 do write ((.30 * r + .59 * g + .11 * b) / 7.0) and when the output began coming out 0.0 1.5714286 3.1428571 4.7142857 6.2857143 ... I began wondering why I was getting multiples of pi/2. Had I somehow connected with some trigonometric functions? After quite a bit of head-scratching I figured out the real problem and realized that the red herring came from inadvertent calculation of the common approximation of pi as a fraction, namely 22/7. I'd favor a change if it could be done cleanly. I doubt that any existing programs would be invalidated. As for ambiguity, it's already there in people's minds, and is resolved the wrong way. In the statement off := .47 most people wouldn't notice "." as an operator any more than they'd notice that the variable name begins with a reserved word. People look at things in context. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@Arizona.EDU 110 57 17 W / 32 13 47 N / +758m From icon-group-request Sat Feb 21 13:03:29 1987 From: "Ralph Griswold" To: gmt, icon-group Subject: Re: .2 + .2 = 4 In-Reply-To: <8702211923.AA01862@megaron.arizona.edu> Errors-To: icon-group-request Status: RO Gregg has a good point about the more important ambiguity. I'd be willing to make the change if it is strictly limited to a period followed by a digit meaning a real literal. (Documenting the syntax will be unpleasant, however.) Or, to be more accurate, I'll add it to the huge pile of things that ought to be done to Icon. I have a program that this change will affect. Not that it's an important program. Can anyone guess what it might be? As another exercise, would anyone care to catalog all the changes that need to be made to distributed Icon material when/if this change is made? From icon-group-request Sat Feb 21 14:54:25 1987 From: "Bill Mitchell" To: icon-group Subject: Re: .2 + .2 = 4 In-Reply-To: <8702211923.AA01862@megaron.arizona.edu> Errors-To: icon-group-request Status: RO I thought about this some more and making .digits into a decimal literal could be a bad idea since programs developed under the new version that have constants of this type would then mysteriously malfunction when run on earlier versions. How about just arranging for .digits to produce a warning message? This would serve to alert the programmer to the problem, but wouldn't produce any inter-version incompatibilities. This could be done in either the lexical analyzer or during the code generation tree walk. The former would allow `. n' to be used for `.n' and not draw a warning, but it might be hard to localize the overhead for that check. Checking during the tree walk would probably be a little cleaner, but the `. n' ruse wouldn't work. This approach would seem to require a minimum of changes outside the code -- just a note in the Version N document saying that .digits now produces a warning. Thus, in the worst case you have a program that generates warning messages and in the best case, a programmer's sanity is saved. From icon-group-request Sun Feb 22 08:05:39 1987 From: "Mark L. Langley" To: icon-group, whm Subject: Re: .2 + .2 = 4 In-Reply-To: <8702212154.AA12199@megaron.arizona.edu> Errors-To: icon-group-request Status: RO From icon-group-request Sat Feb 21 14:54:39 1987 Received: by megaron.arizona.edu; Sat, 21 Feb 87 14:54:27 MST Date: Sat, 21 Feb 87 14:54:25 MST From: "Bill Mitchell" I thought about this some more and making .digits into a decimal literal could be a bad idea since programs developed under the new version that have constants of this type would then mysteriously malfunction when run on earlier versions. I think I disagree. First of all, when was the last time you dereferenced a constant? Second when was the last time you dereferenced a constant that began with a digit? (Obviously you can't dereference a variable that begins with a digit...) I think one usually dereferences variables unless the object of the program is to find bugs in the compiler. Other languages enforce the "Floats must begin with a digit" rule, (ie Pascal) but I always thought Icon was supposed to suggest improvements. Furthermore the incompatible version argument has been violated before, for example when versions of Icon were distributed without co-expressions. And I don't think Icon is ready to have an ANSI standard... From icon-group-request Thu Feb 26 16:52:44 1987 From: "Bill Mitchell" To: icon-group Subject: % operator Errors-To: icon-group-request Status: RO I was just noticing that in the Icon book on page 20, n % m is defined as being the remainder of n divided by m with the sign of m, but the code that implements % just uses the C % operator and when a negative operand is involved, different implementations of C do different things when remaindering. From icon-group-request Wed Mar 4 10:40:17 1987 From: "Ralph Griswold" To: icon-group Subject: fyi In-Reply-To: From shafto@nprdc.arpa Wed Mar 4 10:35:45 1987 Received: by megaron.arizona.edu; Wed, 4 Mar 87 10:35:43 MST Received: by arizona.arizona.edu; Wed, 4 Mar 87 10:34:46 MST Received: by nprdc.arpa (5.51/ 1.1) id AA13801; Wed, 4 Mar 87 09:35:17 PST Message-Id: <8703041735.AA13801@nprdc.arpa> Date: 4 March 1987 0935-PST (Wednesday) From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: ralph@arizona.edu Subject: MS-DOS Icon goodies I received the hard-copy of Cheyenne Wills's notes. Thanks. (You have my correct net address -- I guess something somewhere was just down.) One thing that us psychologists like to use microcomputers for is running experiments. Reaction time is one of our favorite dependent variables. Software evaluation is another area where people like to get fine-grained timing information in the microsecond to millisecond range. Three recent articles have pointed out that it is possible to use the IBM-PC and similar machines to get accurate microsecond-level times without any special hardware or software. The three articles are the following: Smith, B., & Puckett, T. (April, 1984). Life in the fast lane. PC Tech Journal, 63-74. Sheppard, B. (January, 1987). Programming insight: High- performance software analysis on the IBM PC. Byte, 12(1), 157-168. Graves, R., & Bradley, R. (Fedruary, 1987). Millisecond interval timer and auditory reaction time programs for the IBM PC. Behavior Research Methods, Instruments, and Computers, 19(1), 30-35. All these articles use the same method: The system timing chip is re-programmed (software programmable) to "Mode 2" rather than the BIOS setting of "Mode 3." Without getting into the mysteries of the timing chip and its associated ports and counters, suffice it to say that I've experimented extensively with this gimmick. It does not require any assembly-level programming (contrary to what the articles above would suggest). You can do it all with Turbo Pascal. Which brings me to my point: Turbo Pascal has two capabilities which are not represented in Cheyenne's notes and which are necessary to get this no-fuss microsecond hardware timer: 1) The ability to read and write ports. This is represented in Turbo Pascal as the pseudo-arrays Port and PortW. You read a port by reading Port[i] & write a port by assigning a value to Port[i] (or PortW for 2-byte reads and writes). 2) A limited capability to exec Status: RO Errors-To: icon-group-request ute in-line machine code. Specifically, CLI and STI instructions must be placed around the code that reads the memory locations which maintain the timer interrupt count. In addition, the Peek() function would be used. I realize that both of these "features" -- especially #2 -- might be hard to justify as additions to MS-DOS Icon. An alternative would be to implement three functions, say, time_start, time_stop, and delay. time_start would start a 1.19 Mh stopwatch, and subsequent references to &time would return the elapsed time in (floating-point) milliseconds since the call to time_start. The system clock would be operating in Mode 2 (fast, nonstandard). time_stop would stop the fast clock and re-set the system clock to Mode 3 (slow, 55-msec interrupts; BIOS standard setting); delay(n) would delay for n milliseconds. Potential problems: I've found that it's important to run the clock in Mode 2 only when really necessary. For some reason, the system tends to hang occasionally and' unpredictably when the clock is in Mode 2 (and i/o is performed? -- I still don't know the cause, but I do know that the problem can be managed for practical purposes and programs that use this feature can be highly reliable). Another problem -- having delay(n) call time_init and then monitor &time until it goes above n is not as good an idea as it might seem. If this approach is used and there are a lot of "long" 1-2 sec delays in a run (as there would be in the typical psychological experiment) the hang-up problem emerges. Thus, the practical approach is to calibrate a loop (figure out how many iterations are required to produce the desired delay -- using the fast clock for the calibration only), then use the calibrated loop to produce the actual delays during long runs. I know this is special pleading for psychologists -- but maybe there is enough interest among software people to justify some kind of fast-clock feature in MS-DOS Icon. Mike Shafto PS: I fogot another problem I've found: KayPro PC's and perhaps some others have a 4.77Mh/8 Mh dual clock-speed option controlled by a toggle switch. If the 8 Mh, nonstandard clock option is in effect, the timer routines cited above go to hell. mgs From icon-group-request Wed Mar 4 11:24:11 1987 From: "Ralph Griswold" To: icon-group Subject: bogus mail Errors-To: icon-group-request Status: RO For some as yet unknown reason, a portion of a message that I was remailing to persons here on the Icon Project wound up in the outgoing icon-group mail. It's subject is "fyi" and its contents will no doubt appear mysterious. Ignore it. My apologies for the bother. From icon-group-request Wed Mar 4 12:56:04 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group@arizona.edu Subject: micro- to millisecond timing in MS-DOS Icon? Cc: cdavis@a.isi.edu Errors-To: icon-group-request Status: RO NOTE: THIS IS A REBROADCAST OF A NOTE THAT I SENT TO RALPH GRISWOLD. PART OF THAT PREVIOUS MESSAGE WAS ACCIDENTALLY DISTRIBUTED TO ICON-GROUP. MGS One thing that us psychologists like to use microcomputers for is running experiments. Reaction time is one of our favorite dependent variables. Software evaluation is another area where people like to get fine-grained timing information in the microsecond to millisecond range. Three recent articles have pointed out that it is possible to use the IBM-PC and similar machines to get accurate microsecond-level times without any special hardware or software. The three articles are the following: Smith, B., & Puckett, T. (April, 1984). Life in the fast lane. PC Tech Journal, 63-74. Sheppard, B. (January, 1987). Programming insight: High- performance software analysis on the IBM PC. Byte, 12(1), 157-168. Graves, R., & Bradley, R. (Fedruary, 1987). Millisecond interval timer and auditory reaction time programs for the IBM PC. Behavior Research Methods, Instruments, and Computers, 19(1), 30-35. All these articles use the same method: The system timing chip is re-programmed (via software) to "Mode 2" rather than the BIOS setting of "Mode 3." Without getting into the mysteries of the timing chip and its associated ports and counters, suffice it to say that I've experimented extensively with this gimmick. It does not require any assembly-level programming (contrary to what the articles above would suggest). You can do it all with Turbo Pascal. (You have to cheat and use the Turbo inline() function in order to disable and enable interrupts -- see below). Which brings me to my point: Turbo Pascal has two capabilities which are not represented in the working notes for additions to MS-DOS Icon (Cheyenne Wills) and which are necessary to get this no-fuss microsecond hardware timer: 1) The ability to read and write ports. This is represented in Turbo Pascal as the pseudo-arrays Port and PortW. You read a port by referencing Port[i] & write a port by assigning a value to Port[i] (or PortW[i] for 2-byte reads and writes). 2) A limited capability to execute in-line machine code. Specifically, CLI and STI instructions must be placed around the code that reads the memory locations which maintain the timer interrupt count. In addition, the Peek() function would be used. I realize that both of these "features" -- especially #2 -- might be hard to justify as additions to MS-DOS Icon. An alternative would be to implement three functions, say, time_start, time_stop, and delay. time_start would start a 1.19 Mh stopwatch, and subsequent references to &time would return the elapsed time in (floating-point) milliseconds since the call to time_start. The system clock would be operating in Mode 2 (fast, nonstandard). time_stop would stop the fast clock and re-set the system clock to Mode 3 (slow, 55-msec interrupts; BIOS standard setting); delay(n) would delay for n milliseconds. Potential problems: I've found that it's important to run the clock in Mode 2 only when really necessary. For some reason, the system tends to hang occasionally and' unpredictably when the clock is in Mode 2 (and i/o is performed? -- I still don't know the cause, but I do know that the problem can be managed for practical purposes and programs that use this feature can be highly reliable). Another problem -- having delay(n) call time_init and then monitor &time until it goes above n is not as good an idea as it might seem. If this approach is used and there are a lot of "long" 1-2 sec delays in a run (as there would be in the typical psychological experiment) the hang-up problem emerges. Thus, the practical approach is to calibrate a loop (figure out how many iterations are required to produce the desired delay -- using the fast clock for the calibration only), then use the calibrated loop to produce the actual delays during long runs. This might mean that the delay() function is not a good candidate for a built-in function & should be implemented and calibrated as a user-defined function. I've been using the hardware clock on my PC to calibrate the built-in delay procedure in Turbo. I know this is special pleading for psychologists -- but maybe there is enough interest among software people to justify some kind of fast-clock feature in MS-DOS Icon. Mike Shafto PS: I forgot another problem I've found: KayPro PC's and perhaps some others have a 4.77Mh/8 Mh dual clock-speed option controlled by a toggle switch. If the 8 Mh, nonstandard clock option is in effect, the timer routines cited above go to hell. mgs From icon-group-request Wed Mar 4 16:18:27 1987 From: "David Gudeman" To: icon-group Subject: proof-reader Errors-To: icon-group-request Status: RO I've been thinking about writing a proof-reading program in Icon. The program would check spelling, punctuation, word choice, phrase choice, sentence structure, and paragraph structure. It would need to store an entire English dictionary in a table cross-referenced with various information such as synonyms, syntactic category, aesthetic quality, etc. I think that such a program would be very useful for us careless writers. This is a fairly major project, and I am hoping for some opinion on the feasibility and best procedure. Also, does anyone know of other programs that do this? (I am aware of the Unix utilities.) I would also like to find a dictionary that is already on a computer. I know about word-lists, I need a dictionary with syntactic category and synonym information. Here is my general idea. I guess (without much evidence) that there are less than 256 legal syllables in English words. If this is the case, then it is possible to represent words as strings where each character represents a whole syllable. Otherwise (if there are too many syllables for this), words could be represented as lists of strings where each string is a syllable. The reason I want to represent words as strings of syllables is to help in identifying misspelled words. When a word is not recognized, the program will try replacing syllables with other syllables that might represent the same sound, then check if that is a real word. If syllables can be represented as characters, then I could use csets to represent equivalence classes of syllables. English sentences could be parsed as a context-sensitive grammar, incomplete of course, but I think I could get one complete enough for most sentences that are written in semi-formal style. To detect errors in sentence structure and punctuation, I need information on what kinds of errors are most often made. Then I can include these errors in the grammar as a kind of error production. The program will have to read words, selecting one syntactic category for those words that have multiple categories. If the sentence cannot be parsed, the program must backtrack to the selection point and chose a different syntactic category for the word. In other words, the program must be able force backtracking of lexical analysis by failure in syntactic analysis. Even more difficult than this, I have to specify some sort of grammar to describe paragraphs. It is not enough to say that a paragraph is a sequence of sentences. There must be some sort of context similarity in the sentences of a paragraph. I don't know whether this is formally specifiable, but I would like to try. More questions: Is Icon going to be able to handle all of this without spending ten minutes on each paragraph? Do I need to change Icon's internal table functions to make this sort of program efficient? Has anyone done something similar in Icon? From icon-group-request Wed Mar 4 18:25:40 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: bogus mail Errors-To: icon-group-request@arizona.edu Errors-To: icon-group-request Status: RO For some as yet unknown reason, a portion of a message that I was remailing to persons here on the Icon Project wound up in the outgoing icon-group mail. It's subject is "fyi" and its contents will no doubt appear mysterious. Ignore it. My apologies for the bother. From icon-group-request Wed Mar 4 18:39:17 1987 From: "David Gudeman" To: icon-group@arizona.edu Subject: proof-reader Errors-To: icon-group-request@arizona.edu Errors-To: icon-group-request Status: RO I've been thinking about writing a proof-reading program in Icon. The program would check spelling, punctuation, word choice, phrase choice, sentence structure, and paragraph structure. It would need to store an entire English dictionary in a table cross-referenced with various information such as synonyms, syntactic category, aesthetic quality, etc. I think that such a program would be very useful for us careless writers. This is a fairly major project, and I am hoping for some opinion on the feasibility and best procedure. Also, does anyone know of other programs that do this? (I am aware of the Unix utilities.) I would also like to find a dictionary that is already on a computer. I know about word-lists, I need a dictionary with syntactic category and synonym information. Here is my general idea. I guess (without much evidence) that there are less than 256 legal syllables in English words. If this is the case, then it is possible to represent words as strings where each character represents a whole syllable. Otherwise (if there are too many syllables for this), words could be represented as lists of strings where each string is a syllable. The reason I want to represent words as strings of syllables is to help in identifying misspelled words. When a word is not recognized, the program will try replacing syllables with other syllables that might represent the same sound, then check if that is a real word. If syllables can be represented as characters, then I could use csets to represent equivalence classes of syllables. English sentences could be parsed as a context-sensitive grammar, incomplete of course, but I think I could get one complete enough for most sentences that are written in semi-formal style. To detect errors in sentence structure and punctuation, I need information on what kinds of errors are most often made. Then I can include these errors in the grammar as a kind of error production. The program will have to read words, selecting one syntactic category for those words that have multiple categories. If the sentence cannot be parsed, the program must backtrack to the selection point and chose a different syntactic category for the word. In other words, the program must be able force backtracking of lexical analysis by failure in syntactic analysis. Even more difficult than this, I have to specify some sort of grammar to describe paragraphs. It is not enough to say that a paragraph is a sequence of sentences. There must be some sort of context similarity in the sentences of a paragraph. I don't know whether this is formally specifiable, but I would like to try. More questions: Is Icon going to be able to handle all of this without spending ten minutes on each paragraph? Do I need to change Icon's internal table functions to make this sort of program efficient? Has anyone done something similar in Icon? From icon-group-request Wed Mar 4 18:54:14 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: fyi In-Reply-To: From shafto@nprdc.arpa Wed Mar 4 10:35:45 1987 Received: by megaron.arizona.edu; Wed, 4 Mar 87 10:35:43 MST Received: by arizona.arizona.edu; Wed, 4 Mar 87 10:34:46 MST Received: by nprdc.arpa (5.51/ 1.1) id AA13801; Wed, 4 Mar 87 09:35:17 PST Message-Id: <8703041735.AA13801@nprdc.arpa> Date: 4 March 1987 0935-PST (Wednesday) From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: ralph@arizona.edu Subject: MS-DOS Icon goodies Errors-To: icon-group-request Status: RO I received the hard-copy of Cheyenne Wills's notes. Thanks. (You have my correct net address -- I guess something somewhere was just down.) One thing that us psychologists like to use microcomputers for is running experiments. Reaction time is one of our favorite dependent variables. Software evaluation is another area where people like to get fine-grained timing information in the microsecond to millisecond range. Three recent articles have pointed out that it is possible to use the IBM-PC and similar machines to get accurate microsecond-level times without any special hardware or software. The three articles are the following: Smith, B., & Puckett, T. (April, 1984). Life in the fast lane. PC Tech Journal, 63-74. Sheppard, B. (January, 1987). Programming insight: High- performance software analysis on the IBM PC. Byte, 12(1), 157-168. Graves, R., & Bradley, R. (Fedruary, 1987). Millisecond interval timer and auditory reaction time programs for the IBM PC. Behavior Research Methods, Instruments, and Computers, 19(1), 30-35. All these articles use the same method: The system timing chip is re-programmed (software programmable) to "Mode 2" rather than the BIOS setting of "Mode 3." Without getting into the mysteries of the timing chip and its associated ports and counters, suffice it to say that I've experimented extensively with this gimmick. It does not require any assembly-level programming (contrary to what the articles above would suggest). You can do it all with Turbo Pascal. Which brings me to my point: Turbo Pascal has two capabilities which are not represented in Cheyenne's notes and which are necessary to get this no-fuss microsecond hardware timer: 1) The ability to read and write ports. This is represented in Turbo Pascal as the pseudo-arrays Port and PortW. You read a port by reading Port[i] & write a port by assigning a value to Port[i] (or PortW for 2-byte reads and writes). 2) A limited capability to e Errors-To: icon-group-request ute in-line machine code. Specifically, CLI and STI instructions must be placed around the code that reads the memory locations which maintain the timer interrupt count. In addition, the Peek() function would be used. I realize that both of these "features" -- especially #2 -- might be hard to justify as additions to MS-DOS Icon. An alternative would be to implement three functions, say, time_start, time_stop, and delay. time_start would start a 1.19 Mh stopwatch, and subsequent references to &time would return the elapsed time in (floating-point) milliseconds since the call to time_start. The system clock would be operating in Mode 2 (fast, nonstandard). time_stop would stop the fast clock and re-set the system clock to Mode 3 (slow, 55-msec interrupts; BIOS standard setting); delay(n) would delay for n milliseconds. Potential problems: I've found that it's important to run the clock in Mode 2 only when really necessary. For some reason, the system tends to hang occasionally and' unpredictably when the clock is in Mode 2 (and i/o is performed? -- I still don't know the cause, but I do know that the problem can be managed for practical purposes and programs that use this feature can be highly reliable). Another problem -- having delay(n) call time_init and then monitor &time until it goes above n is not as good an idea as it might seem. If this approach is used and there are a lot of "long" 1-2 sec delays in a run (as there would be in the typical psychological experiment) the hang-up problem emerges. Thus, the practical approach is to calibrate a loop (figure out how many iterations are required to produce the desired delay -- using the fast clock for the calibration only), then use the calibrated loop to produce the actual delays during long runs. I know this is special pleading for psychologists -- but maybe there is enough interest among software people to justify some kind of fast-clock feature in MS-DOS Icon. Mike Shafto PS: I fogot another problem I've found: KayPro PC's and perhaps some others have a 4.77Mh/8 Mh dual clock-speed option controlled by a toggle switch. If the 8 Mh, nonstandard clock option is in effect, the timer routines cited above go to hell. mgs From icon-group-request Wed Mar 4 18:55:46 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group@arizona.edu Subject: micro- to millisecond timing in MS-DOS Icon? Cc: cdavis@a.isi.edu Errors-To: icon-group-request@arizona.edu Errors-To: icon-group-request Status: RO NOTE: THIS IS A REBROADCAST OF A NOTE THAT I SENT TO RALPH GRISWOLD. PART OF THAT PREVIOUS MESSAGE WAS ACCIDENTALLY DISTRIBUTED TO ICON-GROUP. MGS One thing that us psychologists like to use microcomputers for is running experiments. Reaction time is one of our favorite dependent variables. Software evaluation is another area where people like to get fine-grained timing information in the microsecond to millisecond range. Three recent articles have pointed out that it is possible to use the IBM-PC and similar machines to get accurate microsecond-level times without any special hardware or software. The three articles are the following: Smith, B., & Puckett, T. (April, 1984). Life in the fast lane. PC Tech Journal, 63-74. Sheppard, B. (January, 1987). Programming insight: High- performance software analysis on the IBM PC. Byte, 12(1), 157-168. Graves, R., & Bradley, R. (Fedruary, 1987). Millisecond interval timer and auditory reaction time programs for the IBM PC. Behavior Research Methods, Instruments, and Computers, 19(1), 30-35. All these articles use the same method: The system timing chip is re-programmed (via software) to "Mode 2" rather than the BIOS setting of "Mode 3." Without getting into the mysteries of the timing chip and its associated ports and counters, suffice it to say that I've experimented extensively with this gimmick. It does not require any assembly-level programming (contrary to what the articles above would suggest). You can do it all with Turbo Pascal. (You have to cheat and use the Turbo inline() function in order to disable and enable interrupts -- see below). Which brings me to my point: Turbo Pascal has two capabilities which are not represented in the working notes for additions to MS-DOS Icon (Cheyenne Wills) and which are necessary to get this no-fuss microsecond hardware timer: 1) The ability to read and write ports. This is represented in Turbo Pascal as the pseudo-arrays Port and PortW. You read a port by referencing Port[i] & write a port by assigning a value to Port[i] (or PortW[i] for 2-byte reads and writes). 2) A limited capability to execute in-line machine code. Specifically, CLI and STI instructions must be placed around the code that reads the memory locations which maintain the timer interrupt count. In addition, the Peek() function would be used. I realize that both of these "features" -- especially #2 -- might be hard to justify as additions to MS-DOS Icon. An alternative would be to implement three functions, say, time_start, time_stop, and delay. time_start would start a 1.19 Mh stopwatch, and subsequent references to &time would return the elapsed time in (floating-point) milliseconds since the call to time_start. The system clock would be operating in Mode 2 (fast, nonstandard). time_stop would stop the fast clock and re-set the system clock to Mode 3 (slow, 55-msec interrupts; BIOS standard setting); delay(n) would delay for n milliseconds. Potential problems: I've found that it's important to run the clock in Mode 2 only when really necessary. For some reason, the system tends to hang occasionally and' unpredictably when the clock is in Mode 2 (and i/o is performed? -- I still don't know the cause, but I do know that the problem can be managed for practical purposes and programs that use this feature can be highly reliable). Another problem -- having delay(n) call time_init and then monitor &time until it goes above n is not as good an idea as it might seem. If this approach is used and there are a lot of "long" 1-2 sec delays in a run (as there would be in the typical psychological experiment) the hang-up problem emerges. Thus, the practical approach is to calibrate a loop (figure out how many iterations are required to produce the desired delay -- using the fast clock for the calibration only), then use the calibrated loop to produce the actual delays during long runs. This might mean that the delay() function is not a good candidate for a built-in function & should be implemented and calibrated as a user-defined function. I've been using the hardware clock on my PC to calibrate the built-in delay procedure in Turbo. I know this is special pleading for psychologists -- but maybe there is enough interest among software people to justify some kind of fast-clock feature in MS-DOS Icon. Mike Shafto PS: I forgot another problem I've found: KayPro PC's and perhaps some others have a 4.77Mh/8 Mh dual clock-speed option controlled by a toggle switch. If the 8 Mh, nonstandard clock option is in effect, the timer routines cited above go to hell. mgs From icon-group-request Wed Mar 4 23:47:34 1987 From: "Bill Mitchell" To: icon-group Subject: duplicates Errors-To: icon-group-request Status: RO We had a problem earlier today with several messages appearing twice, but it has been corrected. Sorry about that. From icon Wed Dec 31 11:37:36 1986 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group@arizona.edu Subject: mathematics vs. computer science Errors-To: icon-group-request Status: RO The Icon Newsletter (Number 23 -- February 3, 1987) contains a puzzling statement on page 5 regarding the "Knuth method" for shuffling a deck of cards: "Whether or not this produces a 'good' shuffle is somewhat of an open question, but it seems to work well in practice." Perhaps this was intended as a subtle joke; if so, my apologies. In any case, it's easy to prove that the method produces a truly random shuffle (if the Icon random number generator is truly random). A truly random shuffle is one in which any arbitrarily chosen card (c) has a probability of 1/N of appearing in the k-th position in the shuffled deck (N = number of cards in deck; k in [1..N]). Let c be any card in the original deck. The first time through the loop, c is moved to position N with probability 1/N; this takes into account the possibility that c is already in position N and is left there. The probability that c is moved to position N-1 on the second iteration is the product of two probabilities: the probability that c was NOT moved to position N on the first pass; the probability that it IS moved to position N-1 on the second pass, i.e., ((N-1)/N) * (1/(N-1)) = 1/N The argument continues, leading to the conclusion that the probability c ends up in the k-th position in the shuffled deck is ((N-1)/N) * ((N-2)/(N-1)) * ... * ((N-k)/(N-k+1)) * (1/(N-k)) = 1/N So if the random number generator is nice and uniform, the shuffle is completely fair (completely random), and every possible permutation of the cards is equally likely. Mike Shafto From icon Tue Mar 10 13:13:13 1987 From: "David Gudeman" To: icon-group Subject: opendir for Icon Errors-To: icon-group-request Status: RO Here are some useful procedures for Unix programming in Icon. It would be nice if there were also a procedure that runs "ls -dgl" on a file and parses the output to create a record of file attributes. I'll probably do that sometime, unless someone else does it first and posts it to icon-group. Procedures readfile() and tempfile() will probably work on non-Unix machines. # Return a set of all the file names in dir (except . and ..). If # dir is not the name of a directory, fail. If dir is not a string # or is "", then an error occurs. # procedure opendir(dir) local pipe, file_names, name_set, s (dir := string(dir), dir ~== "") | stop("opendir: ", image(dir), " is not a name") if dir[-1] ~== "/" then dir ||:= "/" pipe := open("echo " || dir || ".* " || dir || "*", "pr") file_names := readfile(pipe) close(pipe) if file_names[*dir+:3] == "/.*" then fail # not a directory name_set := set([]) file_names ? while s := tab(find(" ")) do { move(1) if s[-2:0] == "/." | s[-3:0] == "/.." then next insert(name_set, s) } return name_set end #Read the entire file, f, into a single string, and return the string. # (the constant 1000000 may have to be reduced on machines with small # word sizes) procedure readfile(f) local s s := "" while s ||:= reads(f,1000000) return s end # Find an unused file name beginning with prefix, open it for # writing, and return the file. The name of the file can be found # with image(file)[6:-1]. If a temporary file cannot be found, # then an error occurs. # procedure tempfile(prefix) local name prefix ||:= map(&clock[4:0],":",".") (every name := prefix || (1 to 20) do close(open(name, "r")) | break) | stop("can't open a temporary file") return open(name, "c") end From icon Tue Mar 10 14:44:19 1987 From: "Bill Mitchell" To: gudeman Subject: Re: proof-reader Cc: icon-group In-Reply-To: <8703042318.AA01701@megaron.arizona.edu> Errors-To: icon-group-request Status: RO AT&T's "Writer's Workbench" has some programs that supposedly do some non-trivial sentence analysis, but I don't really have any more details at my fingertips. Is anyone on the list familar with the WWB programs? Personally speaking, a tool that could just find omitted words would be wonderful. From icon Tue Mar 10 14:49:57 1987 From: "Ralph Griswold" To: gudeman, whm Subject: Re: proof-reader Cc: icon-group In-Reply-To: <8703102144.AA22427@megaron.arizona.edu> Errors-To: icon-group-request Status: RO From icon Tue Mar 10 14:44:31 1987 Received: by megaron.arizona.edu; Tue, 10 Mar 87 14:44:22 MST Date: Tue, 10 Mar 87 14:44:19 MST From: "Bill Mitchell" Message-Id: <8703102144.AA22427@megaron.arizona.edu> Received: by megaron.arizona.edu; Tue, 10 Mar 87 14:44:19 MST To: gudeman Subject: Re: proof-reader Cc: icon-group In-Reply-To: <8703042318.AA01701@megaron.arizona.edu> Errors-To: icon-group-request AT&T's "Writer's Workbench" has some programs that supposedly do some non-trivial sentence analysis, but I don't really have any more details at my fingertips. Is anyone on the list familar with the WWB programs? Personally speaking, a tool that could just find omitted words would be wonderful. No doubt you'd like to start with an empty file and have it fill in the document for you ... From icon Tue Mar 10 14:51:45 1987 From: "Ralph Griswold" To: whm Subject: Re: proof-reader Cc: icon-group In-Reply-To: <8703102144.AA22427@megaron.arizona.edu> Errors-To: icon-group-request Status: RO IBM Research at Yorktown Heights has done a lot of work in this area. Their system parses input text, does spelling and other checks, and suggests corrections. I don't know how much about their work is in the public literature -- perhaps someone in icon-group knows and will respond. From icon-group-request Tue Mar 10 15:20:05 1987 From: "Bill Mitchell" To: ralph Subject: Re: proof-reader Cc: icon-group In-Reply-To: <8703102149.AA22781@megaron.arizona.edu> Errors-To: icon-group-request Status: RO From: "Ralph Griswold" To: gudeman, whm Subject: Re: proof-reader Cc: icon-group No doubt you'd like to start with an empty file and have it fill in the document for you ... I'd be willing to supply the title of the document as the command line argument, naturally. The program would also need to be able to produce at least 100 words a day. Otherwise, would be faster for me to do it myself. From icon-group-request Tue Mar 10 16:31:50 1987 From: naucse!sbw (Steve Wampler) To: arizona!shafto@nprdc.arpa Subject: Re: mathematics vs. computer science Cc: arizona!icon-group Errors-To: icon-group-request Status: RO I'm not sure that the statement is one of whether the shuffle produces a mathematically 'good' shuffle, but whether a mathematically 'good' shuffle is a 'good' shuffle when simulating shuffling a deck of playing cards. That is, normal human shuffling techniques do not typically produce truly random shuffles. From icon-group-request Tue Mar 10 23:21:38 1987 From: amdcad!bandy@decwrl.DEC.COM (Andy Beals) To: icon-group@arizona.edu Subject: article generator (whm) Errors-To: icon-group-request Status: RO Have you looked at "markov3" by jbuck@epicen? Perhaps someone could re-implement it (or do better!) in icon? andy From icon-group-request Wed Mar 11 11:24:44 1987 From: ihnp4!iwsam!orf Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf To: arizona!icon-group Subject: Re: proof-reader Errors-To: icon-group-request Status: RO > >IBM Research at Yorktown Heights has done a lot of work in this area. >Their system parses input text, does spelling and other checks, and >suggests corrections. I don't know how much about their work is >in the public literature -- perhaps someone in icon-group knows and >will respond. > I have used both the IBM "Proof" system (described above) and the AT&T WWB programs. I don`t really know how much of the AT&T stuff is in the "public domain" so I will confine my comments to the I.B.M. system - which I thought was terrific! The system I used was running on a mainframe and was a tool for their technical writing department. The user interface was marvelous. It would high-lite misspelled words (and words that were too "complicated" for the education level of the expected audience of the document.) A page at a time is displayed, and the user hits an arrow key to move the cursor to the next hi-lited word. A function key is then depressed and a box (window) is displayed showing suggested spellings or authorized replacements (synonyms). I was amazed because of all my misspellings, the correct spelling was *always* one of the alternatives in the box. To replace a word, a single key was hit corresponding to the number of the alternative in the box. It was very very good. A large document can be "proofed" in a matter of minutes.. I was amazed to read a couple of years ago that IBM started marketing this system on their PC's -- for $30 BUCKS!!! I don't have an IBM PC, but if it is 1/2 as good as the mainframe system, it is worth a lot more than $30 bucks.. They call it "proof". O. R. Fonorow IW 1Z-261 x7173 iwsam!orf From icon-group-request Wed Mar 11 13:45:23 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group-request@arizona.edu Subject: Re: article generator (whm) Cc: icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO Check out RPOEM in Jim Gimpel's book Algorithms in SNOBOL4 (Wiley, 1976?) From icon-group-request Wed Mar 11 13:48:17 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon@arizona.edu Subject: Re: Re: proof-reader Cc: whm@arizona.edu, icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO Someone who has done serious work on more semantically based text parsing, especially technical material, is Dr. David Kieras David_Kieras@um.cc.umich.edu From icon-group-request Wed Mar 11 13:51:19 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group-request@arizona.edu Subject: Re: Re: proof-reader Cc: ralph@arizona.edu, icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO There's a lot of interest in applied text-processing research at the Navy Personnel R&D Center, San Diego. A good contact person, and old-time SNOBOLler, is Dr. Wallace Wulfeck wulfeck@NPRDC.ARPA From icon-group-request Wed Mar 11 13:54:54 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon@arizona.edu Subject: Re: Re: proof-reader Cc: gudeman@arizona.edu, icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO Here are two people with relevant knowledge: Dr. Fred Chang Pacific Bell pdsfac!ptsfa!tricep!ptsrat!frc@sdcsvax Dr. George Miller Princeton University princeton!mind!geo@seismo.CSS.GOV From icon-group-request Wed Mar 11 15:44:25 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon@arizona.edu Subject: Re: Re: proof-reader Cc: whm@arizona.edu, icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO Someone who has done serious work on more semantically based text parsing, especially technical material, is Dr. David Kieras David_Kieras@um.cc.umich.edu From icon-group-request Wed Mar 11 15:55:10 1987 From: "Ralph Griswold" To: icon-group Subject: proof-readers and such Errors-To: icon-group-request Status: RO A friend at IBM Reseach sent me the following information from their brochure "Computer Science at the Thomas J. Watson Research Center": The CRITIQUE Advanced Text Critiquing System CRITIQUE is an experimental system that aids in the preparation of written text. It is based on state-of-the-art natural language processing techniques and combines theoretical work in computational linguistics with practical work in systems design. It currently diagnoses about 25 grammar errors, such as subject-verb number disagreement and wrong case of pronouns, and diagnoses about 50 style errors, such as split infinitives and too many premodifiers in a noun phrase. The system also can provide about 40 word and phrase critiques, such as misspelled words, and it produces about 50 summary analysis critiques, including the Flesch/Kincaid readability score. The central component of CRITIQUE is a natural language parser and its associated English grammar, both of which are written in PLNLP (Programming Language for Natural Language Processing), developed at IBM Research. PLNLP is a procedural programming language, with LISP-style semantics, and a rule language for writing grammars. The PLNLP English Grammar (PEG) is a broad-coverage, computational grammar of ordinary English, with special features for detecting common grammatical errors. It consists of about 250 rules, which comprise about 7,000 lines of PLNLP code. An on-line dictionary of over 100,000 entries gives it an essentially unlimited vocabulary. From icon-group-request Wed Mar 11 16:14:20 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group-request@arizona.edu Subject: Re: Re: proof-reader Cc: ralph@arizona.edu, icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO There's a lot of interest in applied text-processing research at the Navy Personnel R&D Center, San Diego. A good contact person, and old-time SNOBOLler, is Dr. Wallace Wulfeck wulfeck@NPRDC.ARPA From icon-group-request Wed Mar 11 16:44:22 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon@arizona.edu Subject: Re: Re: proof-reader Cc: gudeman@arizona.edu, icon-group@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO Here are two people with relevant knowledge: Dr. Fred Chang Pacific Bell pdsfac!ptsfa!tricep!ptsrat!frc@sdcsvax Dr. George Miller Princeton University princeton!mind!geo@seismo.CSS.GOV From icon-group-request Sat Mar 21 08:50:34 1987 From: "Ralph Griswold" To: icon-group Subject: pattern words Errors-To: icon-group-request Status: RO Here is a simple problem in string manipulation that you might try to program in Icon. The "pattern" for a word (take a word to be a string of letters for simplicity) displays its structure by representing all occurrences of the first letter of the word by "a", all the occurrences of the second letter of the word by "b", and so on. Thus, the pattern of "proposals" is "abcacdefd". The problem is to write a procedure whose argument is a word and whose value is the corresponding pattern. Assume the argument consists of letters if you wish, although the problem clearly generalizes to any string of characters. For simplicity, assume that upper- and lowercase letters are distinct. You can assume that no more that 26 distinct characters occur in the word, corresponding to the pattern characters "a", "b", ..., "z", although there again are obvious generalizations. Aim for clarity and the best use of the features of Icon, but don't ignore efficiency (imagine your procedure is going to be used on a large word list). Lest you think this problem is totally frivilous, two books of pattern words are currently being offered by the Aegean Park Press, a company that sells a large selection of works on cryptography. From icon-group-request Tue Mar 24 12:27:28 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group@arizona.edu Subject: an object of ridicule for group amusement Errors-To: icon-group-request Status: RO I'll bite. Here's my response to Ralph Griswold's problem of 21 March: procedure pattern(x) static letters,cletters,rep,corep initial { letters := &lcase || &ucase cletters := cset(letters) rep := &cset[0-:*letters] corep := create !rep } corep := ^corep while x := map(x, x[upto(cletters,x)], @corep) return map(x, rep, letters) end From icon-group-request Tue Mar 24 12:28:08 1987 From: vijay Subject: Re: pattern words To: ralph@arizona.edu Cc: icon-group@arizona.edu, Vijay.Saraswat@C.CS.CMU.EDU In-Reply-To: <8703211550.AA00459@megaron.arizona.edu> Errors-To: icon-group-request Status: RO There is considerable similarity in the elegance, economy of concepts, the use of generators, pattern matching driven control structures etc in ICON and in logic programming languages. Perhaps some of you may be interested in a simple solution to Prof. Griswold's little programming exercise in Prolog --- no specific features of Prolog are used, and with very minor modifications the program is a valid CP(!,|) (which is a concurrent logic programming language) program in which considerable use of pipelining is made. The basic idea is to use a symbol table to identify repetitions of chars in the input word. In detail, with every character C[i] (say, 1 =< i =< n) in the input word, we associate a distinct variable V[i], which is initially unbound, but will ultimately be bound to the translation of C[i], i.e. the pattern of the input word will be V[i] (1 =< i =< n). Having initially created a list V of n unbound variables, we need to do two things: first we need to unify two variables V[i] and V[j] iff C[i] and C[j] are the same character; and then we need to pair off the variables V[i] with the list of the alphabet letters, unifying V[i] with the next available alphabet if V[i] is not already bound, and doing nothing if V[i] is already bound. For example, consider the word C='proposals'. We create V as the list [V1, V2, V3, V4, V5, V6, V7, V8, V9] (9 distinct variables). Now, because C[1]=C4], we unify V1 with V4. Similarly we unify V3 with V5 and V6 with V9. This causes the list V to become [V1, V2, V3, V1, V3, V6, V7, V8, V6]. Now we pair up the elements in V1 with the list [a, b, c, ... z]. V1 pairs up with a, V2 with b, V3 with c. V4 is already unified with V1, which is already unified with a. Hence we skip it and look at V5, which is bound to V3, which is bound to c, and is also skipped. V6 next becomes bound to d, and so on, causing V to become 'abcacdefd'. There remains the question of figuring out the values of i and j such that C[i]=C[j]. For this we use a symbol table. For every character C[i], we insert the pair alpha(C[i], V[i]) in the symbol table. If subsequently, the pair alpha(C[j], V[j]) is inserted such that C[i]=C[j], V[i] and V[j] will be automatically unified. Here is the program: we iterate down the characters in Word, pairing each with a fresh variable (the list of fresh variables is Pattern), inserting the pair alpha(Char, Out_Char) in Sym_Table producing New_Sym_Table, and having done this for all the characters in the input word, alphabetizing the list Pattern. pattern(Word, Pattern):- pattern(Word, Null_Sym_Table, Pattern), alphabetize(Pattern). pattern([Char | Word], Sym_Table, [Out_char | Pattern]):- insert(alpha(Char, Out_char), Sym_Table, New_Sym_Table), pattern(Word, New_Sym_Table, Pattern). pattern([], Sym_Table, []). To alphabetize List, we pick up A (the list of alphabets), and pair List with A. The pairing operation consists of taking the next 'variable' in List and unifying it with the next letter in A. If this succeeds then continue with the tail of the two lists. Else, skip the variable in List becuase it already has a value. Continue until there are no more 'variables' left in List. alphabetize(List):- alphabet(A), pair(List, A). pair([],A). pair([Char | List], [Letter | Alphabets]):- pair(List, Alphabets). pair([Char | List], [Letter | Alphabets]):- Char \== Letter, pair(List, [Letter | Alphabets]). alphabet([a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z]). It remains to define the insert operation on the symbol-table. The best way to implement a symbol table in Prolog (that I know of) is to use the Sleator and Tarjan splay trees. For those of you interested in details, I am posting the (simple!) program on the Prolog Digest. For this example it will suffice to use a simple list as a symbol table: insert(alpha(Char, OutChar), Table, Table):- Table = [alpha(Char, OutChar) | Rest]. insert(alpha(Char, OutChar), Table, Table):- Table = [alpha(Char_1, Out1) | Rest] Char \== Char_1, insert(alpha(Char, OutChar), Rest,). This is the entire program: it will run on any Dec-10/20 Prolog system. Vijay Saraswat. ------- From icon-group-request Tue Mar 24 14:18:54 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group@arizona.edu Subject: somewhat faster pattern procedure Errors-To: icon-group-request Status: RO I believe this is 25-30% faster than my earlier effort. procedure pattern(x) local rep static letters initial letters := &lcase || &ucase if *x = 0 then return "" rep := "" while rep ||:= x[upto(~rep,x)] return map(x, rep, letters[1+:*rep]) end From icon-group-request Tue Mar 24 14:44:36 1987 From: "Ralph Griswold" To: icon-group Subject: pattern words Errors-To: icon-group-request Status: RO Here is a solution that came to me personally from a member of icon-group who prefers to be anonymous: To: ralph@arizona.edu Subject: word patterns Status: R How about: ? procedure pat(x) z:=reverse(x) z:=map(z,z,reverse(&ascii)[1:*z + 1]) cz:=cset(z) return reverse(map(z,cz,map(cz,cz,&lcase[1:*cz + 1]))) end From icon-group-request Wed Mar 25 07:39:31 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group-request@arizona.edu Subject: Re: Re: pattern words Cc: ralph@arizona.edu, icon-group@arizona.edu, Vijay.Saraswat@C.CS.CMU.EDU, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO Does it run or walk? From icon-group-request Wed Apr 1 03:20:34 1987 Return-Path: From: Bill Kinnersley To: icon-group@arizona.edu Errors-To: icon-group-request Status: RO Here are some more observations and opinions about Icon. I have no qualifications except a) an intense interest in the language and b) being a newcomer. A newcomer may sometimes focus on inconsistencies that an expert has already come to accept. (And a cat may look at a king.) Also, expressing controversial opinions is a good way to encourage others to straighten you out! It seems to me that much of the Icon philosophy is a duality: two levels of flow control. In addition to the conventional explicit flow: if-then-else, while-do and call- return, Icon has added an implicit flow control: suspend, resume, iterate and backtrack. They parallel one another, and to some extent they're interchangeable. For example (A & B) | C may be used (with qualifications) instead of if A then B else C The parallelism is what makes the scheme logical and consistent, while the qualifications are what make it worth having both. But there's something missing from the language that I'd like to put back in. Real, honest-to-gosh Booleans. (No, seriously.) This is the one place where the two parallel tracks have been allowed to intersect. I think the important concept of success-failure needs to be kept distinct from the even more fundamental idea of true and false. It's neat that they can be treated as one, but we really need both. Booleans are everywhere in Computer Science. There are Boolean flags, Boolean arrays, Boolean matrices, and don't forget some people use bit fields. Hey, I might even want to generate a result sequence of Booleans. Should a modern language like Icon really force us to simulate Booleans with integer 0's and 1's? Or strings "0" and "1"? Or "true" and "false"? Did you ever try to XOR "01001" with "11100"? Implicit flow control is useful in a restricted class of programming problems, but where it does apply, it is very useful. On the other hand it can be tricky to get right, and this is where being a novice comes in. A problem I repeatedly run up against is the rule delimiting resumption. In Icon, backtracking is limited to an expression. The result is that expressions are sometimes forced to become overly complex. This distorts the appearance of our programs and makes their intended action quite subtle. We may need to cram as much as possible into one poor expression. (And it can't even be compound.) Exhibit A: "If a procedure fails, its arguments are resumed", so we write C(B(A())) and claim it's because we *like* to be concise! Exhibit B: Instead of {A(); B(); C()} we may need to write A() & B() & C(). I guess this is not too bad if you think of the & as a sort of "reversible semicolon". Exhibit C: When a procedure is resumed, the resumption starts with the expression following the suspend. In order to make use of data backtracking therefore, much of your procedure may have to be written in that single expression: suspend(A <- B & C <- D & E <- F & G <- H) The issue here is not one of style. Not even clarity. The issue is designing the language to let the power come through without forcing your program to stand on its head. The cleaner it looks, the more people will use it. Any suggestions? Here are some minor wishes: 1) Empty if-then-else clauses. We can say break ; # empty, producing &null and return ; # empty, producing &null We should be able (currently illegal) to say if A then B else ; # if A fails, produces &null if A then ; else B # similarly 2) Tables. !t generates the entries of a table. There needs to be a way of generating the *keys*. As it is, I use sort() to produce a list of pairs, then pick the keys out of that by hand. (Since tables are in principle unordered, perhaps the keys in a table should be made available as a set.) 3) Built-in functions I still say we need: a) all P(1 to n) # P(1) & P(2) & ... & P(n) and b) any P(1 to n) # P(1) | P(2) | ... | P(n) I've tried simulating them with procedures, and come close, but only close. From icon-group-request Wed Apr 1 15:53:55 1987 From: "David Gudeman" To: icon-group@arizona.edu In-Reply-To: Bill Kinnersley's message of Tue, 31 Mar 87 11:39:55 PST Subject: Suggestions for Icon Errors-To: icon-group-request Status: RO Date: Tue, 31 Mar 87 11:39:55 PST From: Bill Kinnersley Errors-To: icon-group-request It seems to me that much of the Icon philosophy is a duality: two levels of flow control. In addition to the conventional explicit flow: if-then-else, while-do and call- return, Icon has added an implicit flow control: suspend, resume, iterate and backtrack. That's an interesting point, it corresonds to my idea that Icon contains two different "paradigms": the procedural paradigm and the goal-directed paradigm. Icon also incorporates the functional paradigm, in the sense that expressions return values. (This may seem like a peculiar way to define the functional paradigm, but notice that pure procedural languages, pure goal-directed languages, pure logic languages, etc. _don't_ have expressions that return values.) But there's something missing from the language that I'd like to put back in. Real, honest-to-gosh Booleans. (No, seriously.) This is the one place where the two parallel tracks have been allowed to intersect. I think the important concept of success-failure needs to be kept distinct from the even more fundamental idea of true and false. It's neat that they can be treated as one, but we really need both. Actually, success/failure is not meant to take the place of the boolean data type. It's just that it's not obvious that control structures should be driven by booleans rather than something else. Lisp uses null/`any other value', C uses 0/`any other value', Pascal uses True/False. The Pascal solution is actually the _least_ useful, and was chosen more for security than for expressiveness. The Icon solution has its disadvantages, but it seems to fit the language very well. If I need a boolean that will be used to drive control structures, I usually use &null for false and "" for true. Then if x is the variable containing one of these two values, I can write if \x then ... When I do this a lot, I even get to the point where I can remember which of the unary \ and / operators does what. Here is how I would add booleans to Icon: add the keyword &true, which returns a unique object like &null. Add the keyword &false which is identical to &null. Add the function boolean(x) which returns x if it is &null or &true, and fails otherwise. Would that be sufficient? A problem I repeatedly run up against is the rule delimiting resumption. In Icon, backtracking is limited to an expression. The result is that expressions are sometimes forced to become overly complex. This distorts the appearance of our programs and makes their intended action quite subtle. We may need to cram as much as possible into one poor expression. (And it can't even be compound.) Try using the mutual-evaluation operator ",". It has to occur inside parentheses, but otherwise it does pretty much what you seem to want. It would be possible to take make _all_ Icon expressions backtrack into previous expressions, but this would make programs much more interconected and much harder to understand. Here are some minor wishes: 1) Empty if-then-else clauses. We can say We should be able (currently illegal) to say if A then B else ; # if A fails, produces &null if A then ; else B # similarly 2) Tables. !t generates the entries of a table. There needs to be a way of generating the *keys*. Ditto for me, I think we need both of these. 3) Built-in functions b) any P(1 to n) # P(1) | P(2) | ... | P(n) Will (i := 1 to n, P(i)) work? We also need a control structure: E1 reduce E2 where E1 returns a binary function, and the results of E2 are combined pairwise with the function. For example "+" reduce !"123" ==> "+"("+"("1","2"),"3") ==> 1+2+3 ==> 6 "||" reduce 1 to 3 ==> "||"("||"(1,2),3) ==> 1 || 2 || 3 ==> "123" From icon-group-request Wed Apr 1 16:00:24 1987 From: "Ralph Griswold" To: icon-group Subject: control structures Errors-To: icon-group-request Status: RO A small comment: the result sequence for P(1 to n) is the same as the result sequence for P(1) | P(2) | ... | P(n) (assuming no bizzare side effects). Result sequences, which represent the *capability* of expressions to produce results, are very useful in understanding generative control structures and how to formulate programs using generators. We have a technical report that discusses them (TR 85-25, Programming with Generators). We'll be happy to send a copy to anyone who does not already have it -- just mail your *postal* address to me. ralph@arizona.edu Ralph Griswold From icon-group-request Thu Apr 2 11:39:33 1987 From: "Kenneth Walker" To: icon-group Subject: Suggestions for Icon Errors-To: icon-group-request Status: RO Date: Tue, 31 Mar 87 11:39:55 PST From: Bill Kinnersley It seems to me that much of the Icon philosophy is a duality: two levels of flow control. In addition to the conventional explicit flow: if-then-else, while-do and call- return, Icon has added an implicit flow control: suspend, resume, iterate and backtrack. I tend to view sequential execution with backtracking as the underlying control mechanism of Icon. The various control structures: ";", if-then-else, while-do, etc. are added on top of this underlying mechanism to give added control over it and to add to the expressive power of the language. Most of these control structures were inspired by counter parts in traditional languages, but if you look closely at what there are doing, they are different - indeed, in the presence of backtracking they must be. But there's something missing from the language that I'd like to put back in. Real, honest-to-gosh Booleans. (No, seriously.) This is the one place where the two parallel tracks have been allowed to intersect. I think the important concept of success-failure needs to be kept distinct from the even more fundamental idea of true and false. It's neat that they can be treated as one, but we really need both. I have used Dave Gudeman's solution to the lack of Booleans by using &null, with the operators / and \, but I find it inelegant. A nicer, though less efficeint solution would be to capture success and failure in a procedure or co-expression and use these to represent true and false: procedure true() return end procedure false() fail end procedure main() local x, y x := true y := false if x() then write("true") else write("false") if y() then write("true") else write("false") end or global true, false procedure main() local x, y true := create |&null false := create &fail x := true y := false if @x then write("true") else write("false") if @y then write("true") else write("false") end prehaps there should be keywords &true and &false which use one of these two schemes. 1) Empty if-then-else clauses. if A then B else ; # if A fails, produces &null if A then ; else B # similarly You can say if A then {} else B you should be able to say if A then B else {} but there seems to be a bug in the compiler so that it gets translated into if A then B Note that {} can also be used in a case expression: case A of { B: C D: {} default: E } also (rambling on) another useful programming technique with the case expression is to use | to create the effect of multiple ``case labels'' on one expression: case A of { B | C | D: E F: G } 2) Tables. !t generates the entries of a table. There needs to be a way of generating the *keys*. As it is, I use sort() to produce a list of pairs, then pick the keys out of that by hand. (Since tables are in principle unordered, perhaps the keys in a table should be made available as a set.) I agree that there is a deficiency here. 3) Built-in functions I still say we need: a) all P(1 to n) # P(1) & P(2) & ... & P(n) Problems arise with the interpretation of all when an expression contains more than one generator. Suppose we have two procedures, p and q, where q(1) generates i1, i2, ..., im. Does all p(q(1 to n)) mean p(q(1)) & p(q(2)) & ... & p(q(n)) or p(i1) & p(i2) & ... & p(im) or something else and why? What happens if p is also a generator? From icon-group-request Thu Apr 2 13:32:36 1987 From: naucse!sbw (Steve Wampler) To: arizona!gudeman Subject: Re: Suggestions for Icon Cc: icon-group@arizona.edu Errors-To: icon-group-request Status: RO But there's something missing from the language that I'd like to put back in. Real, honest-to-gosh Booleans. (No,... If I need a boolean that will be used to drive control structures, I ... add booleans to Icon: add the keyword &true, which returns a unique object like &null. Add the keyword &false which is identical to &null. Add the function boolean(x) which returns x if it is &null or &true, and fails otherwise. Would that be sufficient? I suspect Bill is not interested in booleans so much for control flow, as as data objects (bitmaps, etc.). Csets give a limited form of bitmap, but is limited by the size of &cset. For example, I would love to run (personally) some graphics simulations in Icon, and being able to twiddle bits would be nice. However, I'm also not sure if that should be considered within the domain of Icon. 1) Empty if-then-else clauses. We can say We should be able (currently illegal) to say if A then B else ; # if A fails, produces &null if A then ; else B # similarly Why doesn't this work? Aren't null statements legal in such places? Sigh. Bill is correct, though one could argue that is it 'clearer' to write: if A then B else &null if A then &null else B (see, Icon really *is* police state programming!) 2) Tables. !t generates the entries of a table. There needs to be a way of generating the *keys*. Ditto for me, I think we need both of these. I'd really like a way to generate the table elements, and then pull either(both) the key and entry values from each element. 3) Built-in functions b) any P(1 to n) # P(1) | P(2) | ... | P(n) Will (i := 1 to n, P(i)) work? This *is* just P(1 to n), and 'all P(1 to n)' is almost 'every P(1 to n)'. I suspect what Bill means by 'all P(1 to n)' is the ability to spread results of an expression out (into a list?). We also need a control structure: E1 reduce E2 where E1 returns a binary function, and the results of E2 are combined pairwise with the function. For example "+" reduce !"123" ==> "+"("+"("1","2"),"3") ==> 1+2+3 ==> 6 "||" reduce 1 to 3 ==> "||"("||"(1,2),3) ==> 1 || 2 || 3 ==> "123" This is fairly simple to model with PDCO (programmer-defined control operations), and in fact, makes a good homework exercise on the subject. Of course, using a PDCO has its drawbacks. By the way, assignment is a binary operator, could one ":=" reduce (x|y|z)? (Why not? - maybe there should be a 'reduceleft' and a 'reduceright'.) From icon-group-request Sat Apr 4 12:16:11 1987 From: boba@iscuva.ISCS.COM (Bob Alexander) To: cheyenne@arizona.edu Subject: Re: MS-DOS Icon suggestion Cc: icon-group@arizona.edu Errors-To: icon-group-request Status: RO Cheyenne -- I'm going to copy this message to icon-group, since the ideas presented might be of general interest. Icon-groupies -- for background: this is a discussion of a technique for making icode files executable as commands on non-UNIX machines. The method is to place shell commands into the header portion of the icode file that invoke iconx with the icode file as parameter. This technique is currently used in the Macintosh MPW version, and is being suggested for the MS-DOS version. ---------------------------------- Speaking of the perils of possibly rewriting edited icode files ... let me mention an idea I had but never did anything with. Since my MPW icode headers are text commands, maybe they could actually be user-modifiable. Additional stuff could be put in there (occasionally); in particular manipulation of environment variables. Wouldn't it be nice it the memory region sizes could be properties of the programs themselves, rather than part of a global environment. Of course, there are other ways to do this, but I can't think of any where the parameters would be integral to the program file. Users couldn't be allowed to just edit the icode files though, because the size of the header would have to be prevented from changing. A utility would have to be provided to help them out. Since the environment changes would occur in a sub-shell, the global environment would not be affected. I went as far as leaving extra space in the header for MPW, but never provided the utility. On a different subject, but still related to executable icode files, the MPW version of Icon gets its iconx path info from an environment variable instead of having it "hard-coded" into the header. I think that feature would be useful in all versions of Icon. It makes it much easier for someone to copy a personal copy of Icon to his machine (which doesn't already have Icon installed globally) , into his own area of the file system. As it is, he would usually have to either talk to a system administrator to put it into /usr, or build his own Icon (difficult for many users who aren't allowed to consume the amount of file space required to build Icon). And it just seems like a good idea that makes life easier all around. It could default to a hard-coded path if the environment variable is missing. In the case of MPW, where the ability to build Icon is currently not provided, specification of the iconx path by environment variable is the only way to allow users to choose where they want to locate Icon. From icon-group-request Mon Apr 6 12:14:40 1987 From: "Ralph Griswold" To: icon-group Errors-To: icon-group-request Status: RO A couple of weeks ago I posed the following Icon programming problem: The "pattern" for a word ... displays its structure by representing all occurrences of the first letter of the word by "a", all the occurrences of the second letter of the word by "b", and so on. Thus, the pattern of "proposals" is "abcacdefd". The problem is to write a procedure whose argument is a word and whose value is the corresponding pattern ... . Aim for clarity and the best use of the features of Icon, but don't ignore efficiency ... . Experienced Icon programmers naturally turn to map(s1,s2,s3) when there is a hint of character substitution or rearrangement in the air. The problem above is a natural for map -- the difficulty is finding the unique characters on which to base a substitution. Most solutions we received (not all of which were posted to icon-group) were based on removing duplicate characters in the word by "conventional" string processing, followed by a straightforward use of map. These solutions had the following form: procedure patternword(s) # Solution 1 static letters # based on program by Gregg Townsend initial letters := string(&lcase) out := "" every c := !s do if not find(c,out) then out ||:= c return map (s, out, letters[1+:*out])) end The static identifier is used to avoid cset-to-string conversion every time the function is called. This makes a noticeable difference, as does the use of find() instead of upto() -- the latter requires a string-to-cset conversion in the loop. Ardent Icon programmers try to find a way to do it entirely with map -- both because of the challenge and because of the knowledge that map operates on all characters of its arguments in each call, avoiding loops over the characters at the source level. Here is such a solution: procedure patternword(s) # Solution 2 # based on program by Ken Walker local numbering, orderS, orderset, patlbls static labels, revnum initial { labels := &lcase || &lcase revnum := reverse(&cset) } # 1: Map each character of s into another character, such that the # the new characters are in increasing order left to right (note # that the map function chooses the rightmost character of its second # argument so things must be reversed). # 2: Map each of these new characters into contiguous letters. (numbering := revnum[1 : *s + 1]) | stop("word too long") orderS := map(s, reverse(s), numbering) orderset := string(cset(orderS)) (patlbls := labels[1 : *orderset + 1]) | stop("too many characters") return map(orderS, orderset, patlbls) end Yet another all-map solution is: procedure patternword(s) # Solution 3 static backwards, letters initial { backwards := reverse(&ascii) letters := string(&lcase) } z := reverse(s) z := map(z,z,backwards[1:*z + 1]) cz := cset(z) return reverse(map(z,cz,map(cz,cz,letters[1:*cz + 1]))) end I'll leave you to figure it out. The concept of "good style" is more controversial in Icon than in many other programming languages. I personally prefer the first solution for clarity and the second for cleverness. Timing is more objective. Solution 2 is fastest. Here are comparative timings from processing 10,000 words from the word list from Webster's 2nd. The results are normalized to Solution 2: Solution 1 1.15 Solution 2 1.00 Solution 3 1.51 It's worth noting that the timing is very sensitive to the method used. Solutions that use table-lookup instead of mapping typically are in the 3 - 5 times range compared to Solution 1. Even putting the cset-to-string conversion in the body of the procedure in Solution 1 adds about 20% to its running time. From icon-group-request Tue Apr 7 17:40:23 1987 From: Gus Fernandez Subject: comments from a skeptic To: icon-group@arizona.edu, ralph@arizona.edu Errors-To: icon-group-request Status: RO Having seen the responses over the past few weeks regarding the string mapping problem, I begin to question the true power of the language Given that a problem is needed to be solved, one must set forth certain measures regarding the effectiveness of the solution. The best measure I know of is some linear combination of the speed of the resulting code and the speed with which the programmer implemented the solution. (code readability, and monetary cost may be other factors but I won't go into those here.) One must also note how these factors change as the complexity of the problem increases. Icon is generally considered a slow language, certainly slower than equivalent code written in C. Icon thus loses on this ground. Speed of implementation is my main bone of contention. The fact that a "simple" problem was stated and it raised the curiosity of several to implement either "standard" or "clever" solutions leads me to believe that too much effort is required to come up with such "simple" solutions over and above that which is needed to implement them in a conventional language. Moreover, the resulting code would probably be faster. Problems such as these are reminiscent of the same sorts of things I saw being done years ago with APL. We have a programming model quite different from that with which we are used to and are challenged to see how we can apply it in clever ways to problems which we used to solve with conventional languages. To a certain extent, this is good, especially when first learning how to program, and discovering the similarities and differences in syntax and semantics between different languages. If this sort of thing goes on for too long, however, we must question whether any language is an effective tool for the job. I consider a language to be "useful" only when I can sit down at a keyboard and hammer out a working algorithm to a simple problem without much forethought and have it work more or less the first time without any glaring logical errors. Certainly, one is not "proud" of this sort of code. It is something you needed to do to get the job done. If one thinks for a minute that this is any sort of accomplishment, then I would like to see this person tackle a much more complex job. So far, I have only seen fairly trivial examples of ICON code. Certainly they do well to illustrate some of the interesting features of the language, but if I cannot rely on it to help me substantially when writing larger systems, I see little reason to invest the time and effort required to master a complex language such as ICON. Perhaps, I am too used to the Von Neuman model to see the "obvious" advantage of using alternative models. I can certainly see where certain "kernels" of programs could be implemented quite effectively in languages such as ICON, SNOBOL4, APL, or PROLOG, but when 99% of the rest of the problem requires little more than what we already have in C, Pascal, or LISP, we are tempted to move toward homogeneity. Perhaps certain languages are best suited to proving that certain key algorithms work, which are required in a larger system. This is a legitimate use for specialized languages, as long as the programmer is prepared to either re-write his code in a conventional language for speed or compatibility, or suffer the consequences of slow code or clumsy and error prone interfaces. I believe that this is the main reason that I read about so many people "interested in learning" about ICON, but fewer actually making effective use of it. I would like to hear from anyone who thinks otherwise. Gustavo A. Fernandez From icon-group-request Tue Apr 7 18:45:49 1987 From: "Ralph Griswold" To: icon-group@arizona.edu Subject: in reponse to "comments from a skeptic" Errors-To: icon-group-request Status: RO The problem posed was designed to encourage persons interested in Icon to think about some of its features as they apply to certain kinds of programming problems. I tried it out on local folks first to see what kind of reactions I'd get. Most produced something corresponding to "Solution #1" from my recent mail without any noticeable difficulty; in fact, I got back one solution almost instantly. So I do not think there is anything particularly difficult or arcane about the problem to programmers who are reasonably familiar with Icon. I don't see any connection between this kind of exercise, which admittedly is of interest mostly as a puzzler, and the use of Icon for "real" programming problems. There certainly are plenty of the latter, although as for any programming language, persons usually don't publish their programs. We know of very successful production uses of Icon for rapid prototyping in industry, and the regular use of Icon at many sites for all kinds of utilities, including things like one-of-a-kind data transformations and text generation. In fact, I've been surprised to learn in recent months that some Icon sites we didn't even know about are using the language regularly for certain kinds of tasks. In many cases these are commercial organizations that use languages like C also, so I presume they feel that Icon offers economy in the balance between program development time and programmer costs versus execution efficiency. Results from a reader survey taken last fall show all kinds of applications. We haven't tabulated them yet, but my impression is that the bulk are in natural language applications and prototyping. When these are tabulated, we'll post the results. From icon-group-request Tue Apr 7 23:09:09 1987 From: "David Gudeman" To: icon-group In-Reply-To: Gus Fernandez's message of Tue, 7 Apr 87 17:13:36 PST Subject: Re: comments from a skeptic Errors-To: icon-group-request Status: RO The statement that Icon is too slow is not a valid critism of Icon, it is a critism of a particular implementation. A lot of people once criticized Lisp on the same grounds (some uninformed people still do) but today there are Lisp compilers comparable to C compilers in efficiency. It took me less than 10 minutes to code the solution to the puzzle (with complete error checking), and I am a fairly slow programmer. If the puzzle were supposed to be solved in C I would not have even tried it, it would not have been worth the time and effort. By this measurement, Icon is superior to C. Of course, if you are considering which language to use for a particular project, you have to take into acount the implemenations available. But in this case, you are not judging a "language", you are judging a program (the translator). There are still a lot of C programmers writing Fortran code because Fortran has better optimizing compilers on certain machines. From icon-group-request Wed Apr 8 14:18:26 1987 From: ks26#@andrew.cmu.edu (Kenneth Sykes) To: icon-group@arizona.edu Subject: Re: comments from a skeptic Errors-To: icon-group-request Status: RO Like many other people said, the program was a puzzle, the type of thing a group of people come up with during coffee break. So the time needed to write the most efficient version is irrelevant. As to real applications in ICON, I am writing a Pascal to C translator in ICON as a semester project. I would consider this a "real" application. I have written a simplified YACC compiler, and am currently working on a LEX compiler. Both programs are small, compact and easy to read. Development time was considerably less than a C version, despite the fact that I am proficient in C. This leads me to a question: I would like to simulate regular expressions in ICON, and would be glad to hear suggestions anyone has. I have a copy of Mr. Griswold's book, which gave me a starting point. The problem is I would *ideally* like to pass either a matching expression or a matching procedure to a function, say arbno, to simulate regular expression operators. I have not figured out a way to invoke a code fragment in a string, although I do know how to invoke a procedure stored in a string (i.e. "write"("hello")). An Eval() primitive would be ideal for this... Any help would be appreciated. ICON is a slick language (esp. on a VAX!); keep up the good work! Sincerely, Ken Sykes From icon-group-request Wed Apr 8 15:43:39 1987 From: ihnp4!iwsam!orf Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf To: arizona!icon-group Cc: arizona!ralph Subject: Re: comments from a skeptic Errors-To: icon-group-request Status: RO My "on-the-fly" response.. >Given that a problem is needed to be solved, one must set forth certain >measures regarding the effectiveness of the solution. The best measure >I know of is some linear combination of the speed of the resulting code >and the speed with which the programmer implemented the solution. Yes, empirical evidence would be nice. My intuition, having used Icon for about 1 1/2 years in my "real" work here at AT&T, is that it is easy for experienced programmers to learn, and few languages would be able to better it -- using your limited criteria. > >Icon is generally considered a slow language, certainly slower than >equivalent code written in C. Icon thus loses on this ground. Slower than what??? Slower than UNIX shell? Slower than Lisp? Slower than prolog?? I don't consider it a "slow" language (although it is true that its speed is sensitive to the experience and ability of the programmer). We used it to prototype a complex system. We gave the prototype to our customers less than 2 months after we started programming. We iterated through 5 prototype releases trying to "please" our customers. There were remarkably few (if any) concerns or issues raised about system performance. Our departments UNIX shell based tools (scripts), of which there are many "because they were easier to implement than C" are a constant source of customer complaints about performance. I don't see any difference, on our UNIX systems, between Icon and C in user interfaces. I also recommend you try Icon on an Amdahl 580 (3081 equivalent) running pure System V - You will never think speed is an issue or important in regard to Icon again. The hardware technology today is lightyears past the software technology. > >Speed of implementation is my main bone of contention. I think the main "niche" Icon will find is providing quick "models" of proposed software. Icon's speed is not an important factor as far as I am concerned in my work. What kind of system are you using it on? A PC??? >The fact that a "simple" problem was stated and it raised the curiosity >of several to implement either "standard" or "clever" solutions leads me >to believe that too much effort is required to come up with such "simple" >solutions over and above that which is needed to implement them in a >conventional language. Moreover, the resulting code would probably be faster. Icon, in general, is the easiest language I've ever used. It is the only language I have used that over %50 of my programs run the first time - and I no longer even consider that surprising. I (we) have experience with large "real" programs. The most interesting aspect is that by following a "mild" discipline (trying to make the code look like psuedo code, declaring all variables, etc.) people who came on board in the middle of the project had no problem understanding and adapting the Icon programs. No such thing can be said about the C programs after the conversions. Our management is convinced that Icon is easier to maintain, and depending on the application, not a performance dog (much better than shell). Their primary concern now is support for the language. > >Problems such as these are reminiscent of the same sorts of things I saw >being done years ago with APL. We have a programming model quite different >from that with which we are used to and are challenged to see how we can >apply it in clever ways to problems which we used to solve with conventional >languages. I will steal this line from Joe Hall (AT&T Bell Labs): "The difference between a language like APL and a language like Icon is that nothing you can do can make an APL program readable." In my opinion, Icon is the most readable language (potentially) available. > >To a certain extent, this is good, especially when first learning how to >program, and discovering the similarities and differences in syntax and >semantics between different languages. If this sort of thing goes on for >too long, however, we must question whether any language is an effective >tool for the job. I can understand your "concern" if the only experience you have with the language are these esoteric solutions that came across the net. Again, there is a certain intellectual pleasure in "breaking new ground" and thinking in new ways, but that doesn't diminish the general usefulness of the language. > >I consider a language to be "useful" only when I can sit down at a keyboard >and hammer out a working algorithm to a simple problem without much >forethought and have it work more or less the first time without any glaring >logical errors. Bingo! I'll match Icon against any language you care to name in this regard. SNOBOL4 was close - in my estimation... > >Certainly, one is not "proud" of this sort of code. It is something you >needed to do to get the job done. If one thinks for a minute that this is >any sort of accomplishment, then I would like to see this person tackle >a much more complex job. The reason Icon can succeed here is that it is capable of giving a "high level" - yet efficient - representation of the solution to a given problem. In any case, these "one-shot" programs can be extremely valuable. > >So far, I have only seen fairly trivial examples of ICON code. Certainly >they do well to illustrate some of the interesting features of the language, >but if I cannot rely on it to help me substantially when writing larger >systems, I see little reason to invest the time and effort required to >master a complex language such as ICON. Suit yourself. This is a "technology transfer" problem. You are not much different that a lot of people who generally feel "overloaded" with too many languages and tools... In my case, not having Icon (when I first got here) was like having to go back to "ed" after learning "vi", or going back to "sh" after using "ksh", etc... Any environment without it seems primitive to me.. > >Perhaps, I am too used to the Von Neuman model to see the "obvious" advantage >of using alternative models. I can certainly see where certain "kernels" of >programs could be implemented quite effectively in languages such as ICON, >SNOBOL4, APL, or PROLOG, but when 99% of the rest of the problem requires >little more than what we already have in C, Pascal, or LISP, we are tempted >to move toward homogeneity. Not to "nit-pick" but we have "everything we need in assembly language"... > >Perhaps certain languages are best suited to proving that certain key >algorithms work, which are required in a larger system. This is a legitimate >use for specialized languages, as long as the programmer is prepared to >either re-write his code in a conventional language for speed or >compatibility, or suffer the consequences of slow code or clumsy and error >prone interfaces. I suppose. But prototyping is a very valuable tool in the area of software development. Don't slight it. > >I believe that this is the main reason that I read about so many people >"interested in learning" about ICON, but fewer actually making effective >use of it. I would like to hear from anyone who thinks otherwise. > > Gustavo A. Fernandez > I can't give any more specifics other than we spent 9 months and iterated through 5 Icon releases of a prototype automated testing system. The system is quite large now, probably because it seemed so "easy" that we were willing to tackle more. It definitely was easier to maintain in Icon - and I was the only person originally who knew the language. Now my entire group knows it. When we turned (most) of it into "C", that effort alone spanned 6 months. We are not nearly so "happy" now, and looking for something else to prototype.. O. R. Fonorow AT&T Informat Systems Software Technology Department IW 1Z-261 ihnp4!iwsam!orf From icon-group-request Wed Apr 8 15:52:11 1987 From: "David Gudeman" To: icon-group In-Reply-To: ks26#@andrew.cmu.edu's message of Wed, 8 Apr 87 16:12:05 est Subject: comments from a skeptic Errors-To: icon-group-request Status: RO Date: Wed, 8 Apr 87 16:12:05 est From: ks26#@andrew.cmu.edu (Kenneth Sykes) ... I have written a simplified YACC compiler, and am currently working on a LEX compiler... Well don't keep us in suspense. Do they compile to Icon or C? Are you willing to post them? If they compile to Icon, they would be great to include in the Icon program library. From icon-group-request Wed Apr 8 21:20:06 1987 From: "Kenneth Walker" To: icon-group Subject: regular expressions Errors-To: icon-group-request Status: RO Date: Wed, 8 Apr 87 16:12:05 est From: ks26#@andrew.cmu.edu (Kenneth Sykes) Subject: Re: comments from a skeptic ... This leads me to a question: I would like to simulate regular expressions in ICON, and would be glad to hear suggestions anyone has. I have a copy of Mr. Griswold's book, which gave me a starting point. The problem is I would *ideally* like to pass either a matching expression or a matching procedure to a function, say arbno, to simulate regular expression operators. I have simulated regular expressions, but I used an experimental feature of Icon (described in "TR86-20 An Expression Data Type for Icon") and the feature probably will not be incorporated in a release of Icon in the immediate future. It is possible to simulate most aspects of the feature with co-expressions, but it is not elegant. Recursive "patterns" like those created by an arbno procedure are particularly ugly to implement. The simulation with co-expressions is not particularly difficult, but it is **not** pretty. If you really think you want to see it, I can give you details. The only other approach that comes to mind is the standard set of transformations: regular expression --> non-deterministic finite state autamata (NFA) with epsilon moves --> NFA without epsilon moves --> deterministic finite state autamata (DFA) --> minimal DFA then interpret the DFA. Of course, you can stop with the NFA and interpret it. I haven't thought much about it, but interpreting an NFA in Icon is probably easy because of goal directed evaluation. The question is do you want a simple construction routine or a fast regular expression. By the way, the co-expression approach is non-deterministic , i.e. it uses backtracking, and is probably significantly slower, in general, than interpreting a minimal DFA. The performance of a DFA or NFA interpreter will of course depend on your representation of the the autamata. You will probably want to use strings rather than individual characters as symbols. From icon-group-request Thu Apr 9 09:10:24 1987 From: ks26#@andrew.cmu.edu (Kenneth Sykes) To: icon-group@arizona.edu Subject: YACC/LEX in ICON Errors-To: icon-group-request Status: RO The YACC compiler I mentioned in my previous post generates ICON code. I would be more than happy to submit it to your program library - all I need is instructions on how to do it. I would rather wait a couple weeks until I finish my project before I submit it, however. By then I will have finished the LEX compiler (which will also generate ICON code), grammars for a Pascal to C translator, and documentation. -- Ken P.S. Thanks for the reply regarding regular expressions. I have considered converting the RE to a FSM, but I was hoping to exploit ICONs string features if at all possible. If it's not too much trouble, I would like to see how you would use co-expressions to simulate REs. From icon-group-request Thu Apr 9 11:16:09 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group-request@arizona.edu Subject: Re: comments from a skeptic Cc: icon-group@arizona.edu, ralph@arizona.edu, shafto@nprdc.arpa Errors-To: icon-group-request Status: RO ----- Without rebroadcasting Gustavo's courageous -- foolhardy?? -- message yet again, I do want to respond to a few snippets. The reason I think my two cents' worth might be worth two cents is that I represent a certain class of computer user: I have been programming since 1968, starting with Fortran II on an IBM 1620 BCD machine. I've used mainframes, minis, & micros; languages ranging from assembler to C & Pascal, SNOBOL4, PL/1, and a whole bouquet of LISP dialects -- including Interlisp on a Xerox 1109, in case anyone thinks I can't stand up to serious self-flagellation. But I'm NOT a professional programmer, much less a computer scientist. I started programming because it was fun & continued because programming became an indispensible day-to-day tool. I must admit that I got a bit hostile when I saw the all-map solution. map was the first thing I thought of, and I even got some fragments of the all-map solution, e.g., I realized that reverse would have to in there somewhere; but I couldn't see how to put it all together. Given that I did see the "standard" solution pretty fast, I guess I wouldn't leap to the conclusion that Icon is slow and/or obscure. It's a bit like faulting Fortran because it isn't immediately obvious how to write Quickersort. ----- ... some linear combination of the speed of the resulting code and the speed with which the programmer implemented the solution ... ... readability & monetary cost ... ... complexity of the problem ... ... speed of execution ... Speed of implementation is my main bone of contention. ... comparison with APL ... ----- Icon is a winner according to any of the above criteria except perhaps sheer execution speed. Conclusion: Don't use Icon if sheer execution speed is your sole performance criterion. But how many of us fit that description? The comparison with APL is a complete bum rap; Icon code is so clear that people can read and understand Icon code even when they don't know Icon at all. ----- I consider a language to be "useful" only when I can sit down at a keyboard and hammer out a working algorithm to a simple problem without much forethought and have it work more or less the first time without any glaring logical errors. ----- The above is exactly my criterion. That's why I now program exclusively in Icon unless (a) I need very precise timing [use Turbo Pascal] or (b) I need to enter SNOBOL4 patterns as parts of commands at run-time [use SNOBOL4]. For fast working code that you can go back to six months later and still comprehend, Icon wins over any other language. For my money (i.e., $15), it beats C, Pascal, LISP, and everything else for a combination of reasons, but NOT primarily because of its unique, nonstandard features. The particular things I like for sheer usability are: standardization -- unsurpassed; link directive -- write it and forget it libraries; telescoping code -- algebraic, C-looking stuff can be telescoped down to Lisp-looking stuff, sometimes actually improving clarity (and the reverse can be done if THAT improves clarity); I find it a much more "write as you think" language than any other; finally, most importantly, it supports the datatypes and data structures I find most useful, especially list/arrays, tables, and true sets (and of course strings). To me, this is what a high-level programming language should be: C and Pascal do not qualify as high-level languages because they don't support a useful range of high-level data structures. My criteria relate mainly to this central theme: I want a language that DOES work, not one that MAKES work. ----- little more than what we already have in C, Pascal, or LISP, we are tempted to move toward homogeneity. ----- Yes, I am awe-struck at the homogeneity of LISP. ----- From: "Ralph Griswold" In fact, I've been surprised to learn in recent months that some Icon sites we didn't even know about are using the language regularly for certain kinds of tasks. In many cases these are commercial organizations that use languages like C also, so I presume they feel that Icon offers economy in the balance between program development time and programmer costs versus execution efficiency. ----- This has been my experience. I've used Icon for a range of tasks from experiments with text analysis to maintaining mailing lists and budgetary databases. Not only does Icon have a very favorable programming+execution time (winning on very short programming-debugging time), but I think it is very easy to learn, given its usefulness. Of course, I already knew a lot of languages, but could Icon be much harder to learn as a first language than, say, Pascal? ----- From: "David Gudeman" Of course, if you are considering which language to use for a particular project, you have to take into acount the implemenations available. But in this case, you are not judging a "language", you are judging a program (the translator). There are still a lot of C programmers writing Fortran code because Fortran has better optimizing compilers on certain machines. ----- Carefully choosing a language for an application is only a concern for certain kinds of applications. For do-it-yourselfers like me, it is very useful to have one language that "satisfices," using Herb Simon's term, for almost all applications. That's where Icon is a winner: it's acceptably good for a wide range of tasks, even though some other language might be better on a given task, especially if execution speed is extremely important and development and maintenance time aren't. ----- From: ihnp4!iwsam!orf@arizona.edu Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf >I consider a language to be "useful" only when I can sit down at a keyboard >and hammer out a working algorithm to a simple problem without much >forethought and have it work more or less the first time without any glaring >logical errors. Bingo! I'll match Icon against any language you care to name in this regard. SNOBOL4 was close - in my estimation... ----- I completely agree with all of orf's comments down to this point, which is why I deleted them. But I must inject a word of disagreement here: I am certainly a SNOBOL4 fan; in fact, I think the continued survival of LISP disproves the principle of natural selection. BUT -- let's be honest. There are trade-offs; you can simply DO things in SNOBOL4 that you can't do in Icon. That is granted. But SNOBOL4 is highly idiosyncratic and opaque compared with Icon. I don't think this is debatable, since two of SNOBOL4's best advocates, Griswold and Gimpel, are on record also as its ablest critics. SNOBOL4, like PROLOG and LISP, are high-level languages, but for practical purposes I refuse to consider them general-purpose programming languages, nor is APL. Icon rules as the highest-level, generalest-purpose language available. PL/1 is disqualified on grounds of ugliness. ----- From icon-group-request Thu Apr 9 12:01:07 1987 From: "Kenneth Walker" To: icon-group Subject: co-expressions & REs Errors-To: icon-group-request Status: RO The basic idea for simulating regular expressions is capture matching expressions in co-expressions. For example p := create ="hi" "high" ? write(@p) There are two problems. One is that the co-expression must be refreshed between uses and the other is that it must be forced to produce all alternatives during backtracking. This can be acomplished by invoking it with the following procedure. procedure eval(e) e := ^e suspend |@e end for example p := create =("hi" | "low") "low" ? every write(eval(p)) "hi" ? every write(eval(p)) The procedure eval is circumventing most of what makes a co-expression a co-expression. If you look at what is going on in the run-time system, stacks are being allocated and execution is switching back and forth between stacks. None of this is needed for this problem; the stack of the caller would could be used for all evaluation (see TR86-20). To see how to create more complex matching co-expressions from simpler ones, recall that a co-expression gets a copy of all local variables, including parameters. The following procedure constructs the alternation of two co-expressions. procedure alt(e1, e2) return create eval(e1) | eval(e2) end The following co-expression is functionally equivalent to the one given above. p := alt(create ="hi", create ="low") In order to take a Kleene closure you needed to be able to do something like p := arbno(create ="hi") This can be done by creating a recursive co-expression, but the following will not work arbe := create "" | (eval(e) || eval(arbe)) # WRONG The idea is basically right: an arbitrary number of applications of e is either no application (the null string) or one application followed by and arbitrary number of applications. The problem is that the co-expression gets a **copy** of arbe before the assignment and thus it contains the null value not the co-expression. The following solution is better than the one I had come up with before - it is not quite as ugly. The idea here is to make use of the pointer semantics of Icon records. arbe is assigned a record. The co-expression gets a copy of arbe and thus a reference to the record. The co-expression is then assigned to the field of the record. record r(a) procedure arbno(e) local arbe arbe := r() arbe.a := create "" | (eval(e) || eval(arbe.a)) return arbe.a end You also need a procedure to implement concatination and prabably one to convert a string to the corrosponding matching co-expression. They are easy once you see what is going on. I will leave them as an exercise. From icon-group-request Thu Apr 9 12:41:48 1987 From: "David Gudeman" To: icon-group In-Reply-To: "Kenneth Walker"'s message of Thu, 9 Apr 87 12:01:07 MST Subject: co-expressions & REs Errors-To: icon-group-request Status: RO Ken's solution to regular expressions in Icon (using co-expressions) is rather elegant, but it really eats up memory. You might be able to reduce this problem considerably by careful choice of co-expression stack size since presumably the stacks needed for these co-expression will be quite small. The size of co-expression stacks can be set by the environment variable COEXPSIZE. Be careful that the stack is large enough for any possible execution of the program, because stack overflow checking is not perfect in Icon. Also, you will want to avoid any recursive co-expressions or any co-expressions that can make recursive function calls. For arbno try: procedure arbno(e) return create |eval(e) end (no guarantees on this, I havn't tried it.) From icon-group-request Thu Apr 9 13:17:43 1987 From: "Kenneth Walker" To: icon-group Subject: Re: co-expressions & REs Errors-To: icon-group-request Status: RO Date: Thu, 9 Apr 87 12:41:48 MST From: "David Gudeman" Ken's solution to regular expressions in Icon (using co-expressions) is rather elegant, but it really eats up memory. You might be able to reduce this problem considerably by careful choice of co-expression stack size since presumably the stacks needed for these co-expression will be quite small. The size of co-expression stacks can be set by the environment variable COEXPSIZE. Be careful that the stack is large enough for any possible execution of the program, because stack overflow checking is not perfect in Icon. Note that COEXPSIZE does not affect the main stack. Also, you will want to avoid any recursive co-expressions or any co-expressions that can make recursive function calls. Calling recursive functions from co-expressions could certainly cause problems, but recursive co-expressions should be ok. Each recursion gets its own stack, so lots of small stacks are needed. For arbno try: procedure arbno(e) return create |eval(e) end (no guarantees on this, I havn't tried it.) I don't think this will work for "matching co-expressions" because &pos will be reset during the backtracking that occurs between repetitions. From icon-group-request Fri Apr 10 13:19:51 1987 From: ks26#@andrew.cmu.edu (Kenneth Sykes) To: icon-group@arizona.edu Subject: Re: co-expressions & REs Errors-To: icon-group-request Status: RO I have a couple of questions concerning Ken's post on REs: 1) Is the use of every in the main code (i.e. "low" ? every write(eval(p))) used to get at the alternatives of p (i.e. "hi", "low") or is it used for some reason relating to the co-expressions? 2) Is the correct way to use arbno p := arbno(create ="hi") "hihihi there!" ? every write(eval(p)) or "hihihi there!" ? write(eval(p)) or something completely different? None of the above ways works - one gives me the null string and the other runs out of memory. I'm really not sure how the arbno() code could work: record r(a) procedure arbno(e) local arbe arbe := r() arbe.a := create "" | (eval(e) || eval(arbe.a)) return arbe.a end how can you run eval(arbe.a) when arbe.a is not defined on entry? Does it make use of &null somehow? 3) I tried to write a concat() procedure, to simulate an RE of the form A B: procedure concat(e1, e2) return create eval(e1) || eval(e2) end this seems like a logical way to me, but it does not work (another out of memory error). I have not tried the COEXPSIZE variable yet, which may help here. I am running the Large model version of ICON on a PC with 448k of memory. Again, any help would be appreciated. -- Ken P.S. More explanation of co-expressions in the ICON book would be nice (hint) From icon-group-request Fri Apr 10 14:46:04 1987 From: "Ralph Griswold" To: icon-group Subject: re: co-expressions & REs Errors-To: icon-group-request Status: RO Co-expressions were added to Icon rather late in its initial design. In fact, theey almost were left out of the Icon book and the chapter on them was put in near the end of all the writing. Since that time, we've developed a better understanding of how co-expressions can be used in the context of Icon's kind of expression evaluation, and co-expression features have been added (programmer-defined control operation syntax). I'm presently writing (slowly) a technical report on co-expressions to fill in what's lacking in the present literature. In the process, I've added co-expression tracing and the keyword ¤t, whose value is the current co-expression (so you can tell who you are, as it were). Bill Mitchell is fixing a "hole" in the implementation with respect to return points. Out of all of this, we hope to have a more robust, better documented, and easier to use facility. Unfortunately, it's going to take another release of the implementation to bring things into sync. From icon-group-request Sat Apr 11 08:44:22 1987 From: "Kenneth Walker" To: icon-group Subject: Re: co-expressions & REs Errors-To: icon-group-request Status: RO Date: Fri, 10 Apr 87 15:19:40 est From: ks26#@andrew.cmu.edu (Kenneth Sykes) Subject: Re: co-expressions & REs I have a couple of questions concerning Ken's post on REs: 1) Is the use of every in the main code (i.e. "low" ? every write(eval(p))) used to get at the alternatives of p (i.e. "hi", "low") or is it used for some reason relating to the co-expressions? oops, I borrowed the code from another test. The every interates over all matches, but in this case there is only one match. 2) Is the correct way to use arbno p := arbno(create ="hi") "hihihi there!" ? every write(eval(p)) or "hihihi there!" ? write(eval(p)) or something completely different? None of the above ways works - one gives me the null string and the other runs out of memory. The first result should be the null string - it is the result of zero matches. every should iterate over all the solutions: "" "hi" "hihi" "hihihi" I have no problems running these examples here on a VAX. Here are some suggestions for environment variables which should help your out of memory problems: COEXPRSIZE 1000 STRSIZE 5000 HEAPSIZE 5000 MSTKSIZE 3000 If they don't help let us know. I'm really not sure how the arbno() code could work: record r(a) procedure arbno(e) local arbe arbe := r() arbe.a := create "" | (eval(e) || eval(arbe.a)) return arbe.a end how can you run eval(arbe.a) when arbe.a is not defined on entry? Does it make use of &null somehow? The create is just capturing the code, eval(arge.a) is not executed until the result returned by arbno is evaluated by eval. By that time arbe.a has been assigned the co-expression. 3) I tried to write a concat() procedure, to simulate an RE of the form A B: procedure concat(e1, e2) return create eval(e1) || eval(e2) end this seems like a logical way to me, but it does not work (another out of memory error). That is the correct. I ran it here without any problems. From icon-group-request Sat Apr 11 10:36:29 1987 From: "Ralph Griswold" To: icon-group Subject: solitaire program Errors-To: icon-group-request Status: RO An Icon program for playing solitaire (s.icn) showed up in our uucp area a few days ago -- but with no origin or indication of authorship. Will anyone acknowledge it? From icon-group-request Mon Apr 13 23:12:51 1987 From: ihnp4!ihuxy!nowlin Message-Version: 2 >To: /addr=iwsam!orf, /addr=ihnp4!arizona!icon-group Message-Service: Mail Message-Protocol: EMail End-Of-Header: Email-Version: 2 X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin To: arizona!icon-group Subject: Re: pattern words Ua-Message-Id: End-Of-Protocol: Errors-To: icon-group-request Status: RO > Here is a simple problem in string manipulation that you might try > to program in Icon. > The "pattern" for a word (take a word to be a string of letters > for simplicity) displays its structure by representing all > occurrences of the first letter of the word by "a", all the > occurrences of the second letter of the word by "b", and so on. > Thus, the pattern of "proposals" is "abcacdefd". . . . > Aim for clarity and the best use of the features of Icon, but don't > ignore efficiency (imagine your procedure is going to be used on a > large word list). I had to try this. Especially after seeing some solutions fly by with co-expressions in them. One of the criteria was supposed to be "clarity" and another "efficiency". This is about as straight forward as you can get. It just assumes a knowledge of the test for null (/). After trying this and the other solutions I received with a list of 23739 words it seems to be about as fast as the others. procedure change(word) ctab := table() pattern := "" every c := !word do { /ctab[c] := &lcase[*ctab+1] pattern ||:= ctab[c] } return pattern end It could be made more efficient by putting a dummy value in the ctab table before generating characters. That way the addition in the calculation of an index into &lcase could be avoided. For long lists of long words it would be worth doing. Jerry Nowlin (...!ihnp4!ihuxy!nowlin) From icon-group-request Tue Apr 14 13:41:37 1987 From: "Bill Mitchell" To: icon-group Subject: Re: comments from a skeptic Errors-To: icon-group-request Status: RO Forwarded message follows... From ihnp4!ihuxy!nowlin Thu Apr 9 14:52:19 1987 >To: /addr=ihnp4!arizona!icon-group-request X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin To: arizona!icon-group-request Subject: Re: comments from a skeptic I just had to respond to this message. It was too much for me to take. > Having seen the responses over the past few weeks regarding the string > mapping problem, I begin to question the true power of the language. > ... > Icon is generally considered a slow language, certainly slower than > equivalent code written in C. Icon thus loses on this ground. Nobody I know will argue the point that Icon is slower than good C but I wouldn't generalize and call Icon a slow language. It can't compare with C and assembler but it flys by any shell scripts I've ever seen and passes BASIC on the PC like it was standing still. > Speed of implementation is my main bone of contention. > The fact that a "simple" problem was stated and it raised the curiosity > of several to implement either "standard" or "clever" solutions leads me > to believe that too much effort is required to come up with such "simple" > solutions over and above that which is needed to implement them in a > conventional language. Moreover, the resulting code would probably be > faster. Your previous comments lead me to believe you've never bothered to learn Icon at even a rudimentary level. Don't argue religion if you can't read the bible. Most of the time shell won't do what I want I resort to Icon. It's much faster to solve little problems in it than in C. For example, I wanted to add carriage returns to the end of each line in ascii files so I could transfer some files to an MS-DOS machine and be able to use them. A three line Icon program that took about 30 seconds to type in and translate did the trick. procedure main() while write(read(),"\r") end I then invoked the program from a shell script that looped and fixed a whole batch of files. To do the same program in shell would be cumbersome to say the least. It's also incredibly slow! To do the same in C would take more time and be more prone to error. Icon is the best solution for these kinds of problems. It's exactly the speed of implementation that makes Icon so useful for small problems like this. > Problems such as these are reminiscent of the same sorts of things I saw > being done years ago with APL. We have a programming model quite different > from that with which we are used to and are challenged to see how we can > apply it in clever ways to problems which we used to solve with conventional > languages. > > To a certain extent, this is good, especially when first learning how to > program, and discovering the similarities and differences in syntax and > semantics between different languages. If this sort of thing goes on for > too long, however, we must question whether any language is an effective > tool for the job. Once again your naivete is showing. I've been using C for a long time and I still enjoy trying to do "clever" thing with it from time to time. Don't hold a language responsible if novice programmers (or even experienced ones) want to experiment from time to time. Would you consider C an ineffective tool just because some people try to push it to the limits? One of the nice things about Icon is that it can be used in a purely conventional style if that's what you want. If you want to take the time to learn some of the more advanced features of the language you can program circles, in terms of implementation speed, around C for lots of applications. > I consider a language to be "useful" only when I can sit down at a keyboard > and hammer out a working algorithm to a simple problem without much > forethought and have it work more or less the first time without any glaring > logical errors. > > Certainly, one is not "proud" of this sort of code. It is something you > needed to do to get the job done. If one thinks for a minute that this is > any sort of accomplishment, then I would like to see this person tackle > a much more complex job. > > So far, I have only seen fairly trivial examples of ICON code. Certainly > they do well to illustrate some of the interesting features of the language, > but if I cannot rely on it to help me substantially when writing larger > systems, I see little reason to invest the time and effort required to > master a complex language such as ICON. I work at AT&T Bell Labs and there are lots of trivial program that you can quickly become dependent on in this and many other programming environments. I wouldn't discard a programming language out of hand just because it does a whiz bang job on trivial programs. Icon also does very well at large programs. I'll give you an example. The area I work in develops very large databases that change on a regular basis. There's a system of C programs that check the integrity of the database after changes are made. The process of running this system on a medium sized database took almost half a day and generated a error report that only identified tuples that were bad. One of the engineers working on the database tools wrote an Icon program to do the same task. His main goal was to generate a more detailed error report so that the database could be fixed. His program prints the bad records in each bad tupple and exactly what's wrong with them. This Icon program took several hours to do the same task that took the C programs six to eight hours. He programmed his tool using standard procedural programming techniques so when it was slower than he liked came to me to see if I could speed up his code a little. When we were done his tool could check the same database in about 15 minutes. He not only improved the reports generated, he speeded up the process by more than a factor of 20. Icon is NOT a trivial language. > Perhaps, I am too used to the Von Neuman model to see the "obvious" advantage > of using alternative models. Perhaps you're too comfortable with what you already know and it's easier to argue against new languages and programming techniques than it is to learn them. > Gustavo A. Fernandez Jerry Nowlin (...!ihnp4!ihuxy!nowlin) From icon-group-request Thu Apr 16 13:33:14 1987 From: boba@iscuva.ISCS.COM (Bob Alexander) To: icon-group@arizona.edu Subject: Icon close() function Errors-To: icon-group-request Status: RO I've been doing a fair amount of shell script type stuff in Icon recently (under UNIX), and there is a "shortcoming" that is rather bothersome sometimes. Background ---------- In UNIX versions of Icon, using open() with the "p" option invokes the C function popen(). Popen(command,) allows execution of any UNIX command, with the popen caller either providing "standard input" to the command, or receiving its "standard output", depending on whether the "command" wass opened for write or read. (Bear with me if you're a UNIX/Icon whiz and already know this stuff. I thought I was, and I only recently discovered this powerful capability!) The Icon system() function invokes a UNIX command, and returns the command's exit status value to the system() function's caller. That's nice, because it is sometimes necessary to check that value. However, when using open() with the "p" option (invoking popen()), there is no way to check the command's exit status. In C, the status is returned by the corresponding pclose(). In Icon, close() always returns the "file" that was closed. Open(...,"p") is an extremely useful facility with a nasty limitation that it can't be used if one needs to know the exit status of the command. Proposal -------- It would be more useful if a close() corresponding to an open(...,"p") would return the command's exit value as an integer, (similar to system()), rather than the file. Of course, that would create an inconsistency (sort of) in the close() function (unless all Icon closes returned integers, but that wouldn't make much sense for files). But I contend that open(...,"p")/close() is really more parallel to system() than it is to open()/close(). (And I've never found much useful to do with the file returned by close() anyway). I'd be interested in hearing comments or debate on this matter. From icon-group-request Thu Apr 16 14:00:11 1987 From: boba@iscuva.ISCS.COM (Bob Alexander) To: icon-group@arizona.edu Subject: More on Icon for shell script applications Errors-To: icon-group-request Status: RO Oh yeah, I just remembered another limitation I bumped up against while using Icon for shell script type applications. The string length limit of 256 (MacCvtLen) for the system() function is too short for some uses. In particular, there are times when it is desirable to build long parameter lists consisting of many file names. In such cases I was able to work around the limitation by repetitive calls to the command, a much less efficient alternative. There are other cases where it could prevent a desired operation from being performed at all. UNIX generally allows command strings to be much longer than 256 characters; into the tens of thousands, I think. Icon's philosophy is to be free of any size limits that one would really ever run up against. It seems contrary to the spirit of Icon to have such a limit on the lengths of commands passed to the operating system. I propose that the string length limit be removed for system() and open() calls (open(...,"p") in particular). From icon-group-request Thu Apr 16 14:37:26 1987 From: "David Gudeman" To: icon-group In-Reply-To: boba@iscuva.ISCS.COM's message of Thu, 16 Apr 87 13:29:37 pst Subject: Icon close() function Errors-To: icon-group-request Status: RO Another thing that would be nice for the system() and open(...,"p") functions is a way to specify a direct execution instead of execution through the shell. That is, system(s) starts a shell process and passes s to it as input. I would like to write system(s,s1,...,sn) where s is the name of a program that is executed, and s1 to sn are arguments passed to the program. This would in general be much faster than starting a shell. From icon-group-request Fri Apr 17 11:54:36 1987 From: ihnp4!iwsam!orf Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf To: arizona!icon-group Subject: Implementation Errors-To: icon-group-request Status: RO One thing I forget to add to my preview message. I am now reading Griswolds' Implementation book -- and enjoying it thoroughly! I highly recommend it to anyone considering changes to the present implementation, or wondering about various idiosyncracies.. orf From icon-group-request Fri Apr 17 11:54:32 1987 From: ihnp4!iwsam!orf Postmark: fonorow,owen r 60045184-5 iw1z261 3129797173 iwsam!orf To: arizona!icon-group Cc: ihcup!pax, ihuxy!nowlin Subject: Internal Limits Errors-To: icon-group-request Status: RO And the litany goes on... Another "limitation" many of you may not be aware of is that there is an internal limit on the read() function. We "discovered" the read() limit while using Icon programs as "front-ends" to a DBMS. The database may contain records of 4096 chars. I don't remember exactly, but the "delivered" Icon internal buffer limit for the read function is about 2200 chars. Because of this limit, the aforementioned system() limit and a few limitations I will mention in a moment, we simply wound up using a personal Icon interpreter and increased the limits as necessary. Remember, you have the source and can control these limits at your site - with or without resorting to a PI. By the way, as an aside, our first attempt was simply to increase MaxCvtLen to 512. I don't remember exactly what happened, but we started hitting the process ulimit on a 3B2, i.e. MaxCvtLen is used in a *lot* of places. So we finally just hard-coded 512 into the buffer declaration for the system() function. Also, I don't know what internal UNIX limits there are - but command lines are not (at least under System 5) allowed to be "10s of thousands of chars..." I think the limit is probably 1024 (see xargs(1)). As far as returning "useable" values with the close() function, I don't see a problem (other than existing documentation) with that idea. We also ran into problems in that the UNIX write/close/flush would fail - and there is currently no way to detect this in Icon. (Under certain circumstances when there is no more space on a device, (under system V) the only way to detect whether or not the write failed is if the C close() library routine returns an error value.) I guess my "requirement" is that if a write() or close() fails - that a run-time error be issued. (So we don't have to always check for failure in our programs). I'd also like to see a run-time error if the internal read() buffer (or any for that matter) over-flows. As far as returning the return code from open(..,"p") through close() .. sounds reasonable. Keep in mind that with popen() or system() something like: open("sort From: Bill Kinnersley To: icon-group@arizona.edu Errors-To: icon-group-request Status: RO Regarding the question of whether Icon is easy or hard to learn, I would say easy to learn, hard to master. In my Programming Languages course, I teach Icon as the first "new" language, right after surveys of Fortran and Pascal. It is presented at first as a dialect of Pascal with high-level data types: lists, strings, etc. (Records aren't mentioned--these Pascalers would use them and nothing else.) The students write their first programs, and build up confidence. THEN we kick the props out! *-) Someone mentioned confusion between the two null-testing operators / and \. Here's a way to remember which is which. Associate them with the crossbar appearing in their names. \ stands for Notnull and / stands for iZnull. Has anyone noticed the striking similarity between Icon and this other language called Lucid? Lucid has a totally different ancestry, but it wound up with many of the same features. In Lucid, the idea of a result sequence is even more pervasive than in Icon. Every variable has a "history" of values. In Icon, an ordinary variable produces one result, say 2. In Lucid, it would produce <2, 2, 2...> Every expression automatically resumes the variables appearing in it. Histories may be terminated with the symbol eod ("end-of-deck"), which corresponds to our failure. Other special symbols found in Lucid are true, false, nil, and error. An inappropriate calculation results in the error object. Thus, the Icon concept of failure has been split into three: false, eod, and error. Once result sequences like are available, it is possible to have one sequence control another. Operators asa ("as-soon-as") and wvr ("whenever") let you select values from result sequence A depending on the Boolean values in sequence B. Wouldn't something like this be useful in Icon? ---- "If at first you do not fail, try try again." --Bill Kinnersley USENET: ...!ucbvax!ucdavis!egg-id!ui3!wsucshp!kinner INTERNET: kinner%wsu.csnet@RELAY.CS.NET CSNET: kinner@wsu MAIL: CS Dept, Washington State Univ, Pullman WA 99164-1210 PHONE: (509)332-3340 From icon-group-request Mon Apr 20 18:32:45 1987 From: boba@iscuva.ISCS.COM (Bob Alexander) To: icon-group@arizona.edu Subject: Re: Internal Limits Errors-To: icon-group-request Status: RO Oops, I guess I did exaggerate a bit when I said the shell could handle command lines in the tens of thousands of characters. I did some experimentation, though, and found that our Ultrix (DEC Berkeley UNIX) maxes out at just under 10,000 characters, considerably more than the System V limit (according to orf) of 1024. It wouldn't surprise me if that's a "sysgenable" parameter that varies from installation to installation. In any case, 256 is a rather uncomfortable limit that apparently a few of you have run up against. I didn't know about the read() limit. Again, some experimentation showed this to be 2049 -- and a look at the code confirmed it (MaxReadStr). I've mounted an attack on some of these limits, and my version of Icon currently supports: Infinitely long strings for: open() first argument (mainly for open(...,"p") system() argument result of read() Close of a file opened by open(...,"p") returns the integer status of the command, just like system() does. Close of a regular file still returns the file. The long string changes were done not by increasing any internal buffer sizes, but by modifying the algorithms to build their strings in dynamic string space if necessary. I've mailed my code changes to R.G., so maybe we'll see these limits lifted in standard Icon in the near future. I agree with the suggestions that run-time errors for write() and close() would be desirable. Currently there doesn't appear to be any error detection at all for write errors. I also support the statement that a way to invoke processes without going through a shell is a nice idea, but is a little too UNIXy to be a standard Icon function. A good candidate for the Icon Program Library for PIs, or for the "fxtra.c" collection. Then the next thing we'll want is a popen() equivalent that calls processes directly, etc., etc. ... From icon-group-request Wed May 13 12:03:11 1987 From: naucse!sbw (Steve Wampler) To: arizona!whm Subject: Re: more co-expression questions... Cc: arizona!icon-group Errors-To: icon-group-request Status: RO From arizona!whm Wed May 13 07:06:42 1987 Received: by arizona.arizona.edu; Tue, 12 May 87 17:13:59 MST Date: Tue, 12 May 87 17:13:50 MST From: "Bill Mitchell" Message-Id: <8705130013.AA12659@megaron.arizona.edu> Received: by megaron.arizona.edu; Tue, 12 May 87 17:13:50 MST To: naucse!sbw Subject: Re: more co-expression questions... Cc: icon-project Assuming that you're talking about co-expressions... This program: global A,B,C procedure main() A := create write(@B) B := create @C C := create "foo"@A @A end prints "foo" when run under the development version of Version 6. good, that makes sense... Ditto for: global A,B,C procedure main() A := create @C & @B & @B & write(@B) B := create @A & @C & @C & @B & @C C := create @C & @A & @B & @A & "foo"@A @A end wow! what a great exam question. note that both these still work under the lrao model.... an internal ADT is one where the user of the ADT sees only the operations on the ADT (in an external ADT, the operations and the data structure are visible.) if there is an expression data type that executes in the environment of definition, and if such expressions can share the same environment (hence the restriction that they not be co-expressions, then the following is a sketch of a internal ADT 'stack': procedure makestack() local stkstore stkstore := [] suspend {expression for push on stkstore} suspend {expression for pop on stkstore} # sorry, i don't know the syntax for the above end . . . getstack := create |makestack() every (spush1|spop1) := @getstack every (spush2|spop2) := @getstack . . . 5 @ spush1 write( @spop1) it occurs to me that, since i haven't kept up on your organization of all this, that my view is probably a bit off. my view of the world (feel free to trash): @ --> activates either an expression data type or a co-expression, either as unary or binary x := coexpression(e) converts an expression data type into a co-expression (i'm not comfortable with the automatic conversion of an expression into a co-expression on activation - just doesn't seem orthogonal.) i do not know very much about c-expressions. perhaps they permit this. From icon-group-request Thu May 21 16:17:53 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group@arizona.edu Errors-To: icon-group-request Status: RO From MAILER-DAEMON@arizona.edu Thu May 21 14:28:03 1987 From: "Mail Delivery Subsystem" Subject: Returned mail: Service unavailable To: Status: RO ----- Transcript of session follows ----- >>> HELO arizona.arizona.edu <<< 553 arizona.arizona.edu I refuse to talk to myself 554 ... Service unavailable: Bad file number ----- Unsent message follows ----- Received: by arizona.arizona.edu; Thu, 21 May 87 14:23:25 MST Received: by nprdc.arpa (5.54/ 1.1) id AA25008; Thu, 21 May 87 14:23:32 PDT Message-Id: <8705212123.AA25008@nprdc.arpa> Date: 21 May 1987 1423-PDT (Thursday) From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: arizona!icon-group@arizona.edu Subject: net address change I'm not sure whether I'm sending this request to the right address but ... Please change my net address to shafto@AMES-AURORA.ARPA my phone number to 415/694-6170 and my snail-mail address to Dr. Michael G. Shafto NASA-Ames Research Center Aerospace Human Factors Lab Mail Stop 239-1 Moffett Field, CA 94035 Thanks. From icon-group-request Tue Jun 23 09:29:18 1987 From: jl42+@andrew.cmu.edu (Jay Mathew Libove) To: icon-group@arizona.edu Subject: Icon source for Xenix Cc: Errors-To: icon-group-request Status: RO Hi - I have an IBM PC/AT running Santa Cruz Operation (SCO) Xenix System V release 2 kernel 2.1.3 on which I would like to run Icon. Is there an ARPAnet / Internet FTPable site from which I can get the sources to Icon? Is there a version specific to Xenix that will be pretty much guaranteed to compile? Thanks for any and all help! Jay Libove Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42 UUCP: ...!{pitt | bellcore} !darth!libove!libove Disclaimer: My employers really don't care what I say... From icon-group-request Tue Jun 23 09:33:41 1987 From: "Ralph Griswold" To: icon-group@arizona.edu, jl42+@andrew.cmu.edu Subject: Re: Icon source for Xenix In-Reply-To: Errors-To: icon-group-request Status: RO Our FTPable UNIX distribution contains configuration information for SCO XENIX. It runs here, both SMM and LMM. Do an anonymous FTP from arizona.edu. cd to icon and get README -- it tells what is available. You want one of UNIX distribution files (it comes in several forms). Documentation is included. Check out v6/setup/pc_xenix_smm and v6/setup/pc_xenix_lmm, which contains the configuration. From icon-group-request Tue Jun 23 10:55:20 1987 From: jl42+@andrew.cmu.edu (Jay Mathew Libove) To: icon-group@arizona.edu Subject: Message of 23-Jun-87 09:59:07 Errors-To: icon-group-request Status: RO Someone has a mail forwarding address that isn't working. Here's the returned stuff. -Jay Forwarded message follows: Return-path: X-Andrew-Authenticated-as: UID422 Received: FROM andrew.cmu.edu VIA trymail ID ; Tue, 23 Jun 87 13:05:10 edt Received: by andrew.cmu.edu (5.54/3.15) id for jl42+; Tue, 23 Jun 87 13:04:33 EDT Date: Tue 23 Jun 87 10:01:55-PDT From: The Mailer Daemon To: jl42+@ANDREW.CMU.EDU Subject: Message of 23-Jun-87 09:59:07 Message failed for the following: jbrookshire@ECLA.USC.EDU.#Internet: No such mailbox ------------ Received: from ARIZONA.EDU (for arizona.arizona.edu) by ECLA.USC.EDU; Tue 23 Jun 87 09:59:17-PDT Received: by arizona.arizona.edu; Tue, 23 Jun 87 09:31:47 MST Received: by megaron.arizona.edu; Tue, 23 Jun 87 09:29:20 MST Received: by megaron.arizona.edu; Tue, 23 Jun 87 09:29:18 MST Received: by arizona.arizona.edu; Tue, 23 Jun 87 09:25:07 MST Received: by po5.andrew.cmu.edu (5.54/3.15) id for icon-group@arizona.edu; Tue, 23 Jun 87 12:21:50 EDT Received: via switchmail; Tue, 23 Jun 87 12:21:47 edt Received: FROM stewartstown VIA queuemail ID ; Tue, 23 Jun 87 12:19:49 edt Received: FROM stewartstown VIA qmail ID ; Tue, 23 Jun 87 12:19:44 edt Received: from stewartstown by MS.3.32 via sun3; Tue, 23 Jun 87 12:19:42 edt Message-Id: Date: Tue, 23 Jun 87 12:19:42 edt From: jl42+@andrew.cmu.edu (Jay Mathew Libove) To: icon-group@arizona.edu Subject: Icon source for Xenix Cc: Errors-To: icon-group-request@arizona.edu Hi - I have an IBM PC/AT running Santa Cruz Operation (SCO) Xenix System V release 2 kernel 2.1.3 on which I would like to run Icon. Is there an ARPAnet / Internet FTPable site from which I can get the sources to Icon? Is there a version specific to Xenix that will be pretty much guaranteed to compile? Thanks for any and all help! Jay Libove Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42 UUCP: ...!{pitt | bellcore} !darth!libove!libove Disclaimer: My employers really don't care what I say... ------- From icon-group-request Tue Jun 23 12:53:57 1987 To: Jay Mathew Libove Cc: icon-group@arizona.edu Subject: Re: Message of 23-Jun-87 09:59:07 In-Reply-To: Your message of Tue, 23 Jun 87 13:18:26 -0400. <4UrfVWy00WARJ3s0D9@andrew.cmu.edu> From: Dave Farber Errors-To: icon-group-request Status: RO I am slowly VERY slowly ftping the SCO Xenix version of icon. I suggest that you all wait till I get it and I will then announce From icon-group-request Tue Jun 23 15:56:50 1987 From: wbm%mdc14.uucp@RELAY.CS.NET To: icon-group@arizona.edu Errors-To: icon-group-request Status: RO Icon mailing list Dear icon-group: Please add me to your mailing list. Thank you, -------- William B. McCormick uucp: !{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!mdc14!wbm From icon-group-request Wed Jun 24 01:27:41 1987 From: jl42+@andrew.cmu.edu (Jay Mathew Libove) To: icon-group@arizona.edu Subject: Icon source for Xenix Errors-To: icon-group-request Status: RO Hi - I have an IBM PC/AT running Santa Cruz Operation (SCO) Xenix System V release 2 kernel 2.1.3 on which I would like to run Icon. Is there an ARPAnet / Internet FTPable site from which I can get the sources to Icon? Is there a version specific to Xenix that will be pretty much guaranteed to compile? Thanks for any and all help! Jay Libove Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42 UUCP: ...!{pitt | bellcore} !darth!libove!libove Disclaimer: My employers really don't care what I say... From icon-group-request Thu Jun 25 13:24:05 1987 From: R301JL42%CMCCVB.BITNET@wiscvm.wisc.edu Subject: FTPing Xenix sources to Icon To: icon-group@arizona.edu X-Vms-To: IN%"icon-group@arizona.edu" Errors-To: icon-group-request Status: RO [ This may be a repost, if so, please forgive- our mailers (whole network) had a serious problem yesterday...] I FTP'd to arizona.edu and went looking for the v6/ directory and the xenix sources to icon, but the directory wasn't there, and the sources for xenix (in fact sources at all) didn't seem to exist. Could someone please mail me back and tell me where they are? Mail addresses to use: R301JL42@CMCCVB.bitnet JL42@ANDREW.CMU.EDU arpanet. Thanks very much -Jay Libove From icon-group-request Thu Jun 25 14:42:59 1987 From: "Kelvin Nilsen" In-Reply-To: To: icon-group@arizona.edu, jl42+@andrew.cmu.edu Subject: Re: Icon source for Xenix Errors-To: icon-group-request Status: RO you can ftp icon materials from arizona.edu using anonymous login. cd to icon, and get README before proceeding. source code configurable for SCO Xenix is available in v6.cpio (or the tar and compressed versions of the same). we haven't emphasized the availability of Xenix source because we had to work around some compiler bugs to make it work, and weren't sure we wanted to even distribute the code as it currently stands. Xenix has compiled for release 2.1.3 of the kernel. i believe we are currently using release G of the development system. let me know if you have any problems with this. From icon-group-request Thu Jun 25 14:45:43 1987 From: "Kelvin Nilsen" In-Reply-To: <8706252022.AA14741@arizona.arizona.edu> To: R301JL42%CMCCVB.BITNET@wiscvm.wisc.edu, icon-group@arizona.edu Subject: Re: FTPing Xenix sources to Icon Errors-To: icon-group-request Status: RO try cd icon, get README. source code configurable for xenix is found in v6.cpio|tar[.Z] From icon-group-request Thu Jun 25 18:18:24 1987 From: jl42+@andrew.cmu.edu (Jay Mathew Libove) To: icon-group@arizona.edu Subject: apologies Errors-To: icon-group-request Status: RO My apologies for sending too many posts to too many places of late in reference to getting icon sources. I didn't realize that the v6/ directory was actually just the v6.* files - and we had some trouble with the systems on campus here so I wasn't sure what was getting where when etc..... Anyway, I am currently FTPing... slowly... and I hope I will be able to post a message soon saying "I got it, it works!" Thanks for all the support I have received! Jay Libove Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42 UUCP: ...!{pitt | bellcore} !darth!libove!libove Disclaimer: My employers really don't care what I say... From icon-group-request Thu Jun 25 18:42:44 1987 From: jl42+@andrew.cmu.edu (Jay Mathew Libove) To: icon-group@arizona.edu Subject: No such luck Cc: Errors-To: icon-group-request Status: RO Well, I said in my last post that I hoped I could soon send a post saying "I got it and it works!" but I can not. I have tried and failed three FTP attempts so far. It would be extremely helpful if the files in question here (specifically the rather large tar and cpio files) were broken down in to smaller pieces, of say 50 to 100K each. FTPing a 900K files (or a 2meg file!) over a connection like arizona.edu's is an almost hopeless adventure... Jay Libove Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42 UUCP: ...!{pitt | bellcore} !darth!libove!libove Disclaimer: My employers really don't care what I say... From icon-group-request Fri Jun 26 08:24:11 1987 From: David Farber Subject: Re: Icon source for Xenix To: kelvin%arizona.edu@UDEL.EDU Cc: icon-group%arizona.edu@UDEL.EDU In-Reply-To: Your message of Thu, 25 Jun 87 14:42:59 MST Errors-To: icon-group-request Status: RO I would recommend you ftp from Udel. The effective rate via the arizona link is about 1 bit per year. Ask Cranor@udel.edu where the stuff is. We brought it over to help. From icon-group-request Fri Jun 26 09:05:31 1987 From: shafto@nprdc.arpa Reply-To: shafto@nprdc.arpa To: icon-group@arizona.edu Subject: distribution list revision request Errors-To: icon-group-request Status: RO It occurred to me after I sent my previous net-note that I'm probably getting Icon e-mail at NPRDC because I'm on a local redistribution list. If so, I'll handle that at NPRDC. Mike S From icon-group-request Fri Jun 26 12:25:14 1987 From: "Bill Mitchell" To: icon-group Subject: Re: Icon source for Xenix Errors-To: icon-group-request Status: RO I hesitate to contribute to this overblown discussion of FTPing Icon, but if you have trouble with 192.12.69.1, try 128.196.6.1. From icon-group-request Tue Jun 30 21:23:51 1987 From: Michael Shafto Organization: NASA Ames Research Center, Mt. View, Ca. Subject: Help requested re GC strategy Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: RO I'm forwarding this from the lisp bb. I know Icon incorporates some careful thinking about garbage collection. From seismo.css.gov!reed.UUCP!keith Mon Jun 29 00:34:42 1987 Path: aurora!ames!ll-xn!husc6!mit-eddie!uw-beaver!tektronix!reed!keith From: keith@reed.UUCP (Keith Packard) Newsgroups: comp.lang.lisp Subject: when to garbage collect Keywords: mark-sweep, non-incremental Organization: Reed College, Portland OR Lines: 17 Status: RO I am looking for references on algorithms for deciding when to garbage collect a non-incremental mark/sweep lisp interpreter. I expect this sort of thing has been well hashed out by many designers of memory management software, but I've been unable to locate any reasonable discussion of the basics. I don't know how important the architecture of the system is, but it's designed for a VM system but doesn't pack memory upon completion so this question is rather important. If memory isn't swept often enough, large gaps will in general exist with the resultant loss of locality-of-reference. But, because the system is not incremental, the cost of calling the garbage-collector is rather substantial. So the obvious solution is a clever algorithm to decide when to GC. keith packard tektronix!reed!keith From icon-group-request Sat Jul 4 17:57:59 1987 From: naucse!sbw (Steve Wampler) To: arizona!icon-group Subject: failing memory... Cc: arizona!icon-project, arizona!ralph Errors-To: icon-group-request Status: RO I was wondering what people thought the best way was to handle the following problem: I have a a series of book title,author,publisher, etc... sequences that I'd like to sort by title, or author, or publisher. What is the best way to handle this multi-keyed sort. One solution, to put records of the information into a table keyed by the sort field, fails pretty miserably. I suppose that one could build a list of lists (ideally a list of book records), but I've forgotten if any of the new options to sort() allow one to sort a list of lists (or records) by any field. Any suggestions on how to proceed? Of course, it would also be nice to be able to do a multikeyed sort (all books, sorted by title within author within publisher [say]), but as it stands now, sort() is not guaranteed to be stable. I'd rather not do my own sort procedure... -Thanks, responses to Icon-group, please From icon-group-request Sun Jul 26 13:42:22 1987 From: olson Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Icon on Sun3 Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: RO (Sorry to bother you, but my addresses seem to be out of date.) Is there a version of Icon that runs on Sun3 workstations? Who do I contact? Thanks, Todd Olson ARPA: olson@lasspvax.tn.cornell.edu UUCP: {ihnp4,allegra,...}!cornell!lasspvax!olson US Mail: Dept Physics, Clark Hall, Cornell University, Ithaca, New York 14853-2501 From icon-group-request Fri Oct 2 16:38:55 1987 From: Ken Yap Organization: U of Rochester, CS Dept, Rochester, NY Subject: Re: Seeking Humanities Programming Texts (Pascal Preferred) References: <21261XBQ@PSUVM> Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: O This appeared in comp.lang.pascal so you Iconers should have a go at disabusing this person's misconceptions. In article <21261XBQ@PSUVM> XBQ@PSUVM.BITNET (Ed Winograd) writes: |I'm looking for a good beginning programming text for my students |in Liberal Arts 482 at Penn State. The course focuses on TEXT PROCESSING |rather than on number crunching and is designed for humanities majors |who have no previous programming experience. | |I'm currently teaching my class PL/C, a somewhat stripped-down version |of PL/1. However, since this language is generally available only on |IBM mainframe systems, it's not the optimal language to use. Although |I know that Digital Research puts out a PL/1 for IBM PC's, it's very |expensive, and I have never seen ANY references to it (if anyone has |used it, what's it like? Is it compatible with mainframe PL/1?). | |I realize that SNOBOL and ICON are widely used for text processing, |but SNOBOL is so radically different from any other language that |I hesitate to use it (but am willing to be convinced otherwise, if |there's a good TEXT to go with it -- the Green Book is MUCH too |hard for beginners). And I'm a little hesitant to use ICON, since |so many of the implementations seem to be public domain ones of |unknown quality and robustness. | |The best language to teach seems to be Pascal, since it's a structured |language which is widely available, and not as dangerous as C for |beginning programmers. But the lack of string primitives in ISO |Standard Pascal is a major problem. | |So, my main question is if anyone knows of a Pascal text for |humanities programming that uses a version such as UCSD Pascal or Turbo |Pascal. If so, I'd very much like to hear from you. Otherwise, |I'm open to considering other languages if there's a GOOD text for them |that my beginners/humanities students could use. The machines available |to me are an IBM mainframe using VM/CMS, IBM PC's, and Macintoshes. | Icon of dubious quality and not robust? Nonsense. Most of the implementations are of U of Arizona descent, and are written in C. Works real well. There are IBM PC and Mac versions. I don't know about those implementations but I'm very happy with the Unix implementation. I can prototype an application faster than in Pascal or C. And I don't mean text processing only, I test out search algorithms with Icon. Ken From icon-group-request Fri Oct 2 19:55:09 1987 From: Adam Beguelin Organization: University of Colorado, Boulder Subject: What is Icon Anyway? Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: O So what is Icon anyway? Is it a graphical programming language? I just subscribed to this group but from the one article I read there are public domain versions out for unix, ibm-pcs and macs. Could someone fill me in on what icon is and maybe even point me to a public domain unix or mac version? Thanks in advance for the education. Adam Beguelin adamb@boulder.colorado.edu University of Colorado Boulder, CO From icon-group-request Fri Oct 2 23:02:08 1987 From: "Richard L. Goerwitz III" Organization: U Chicago Computation Center Subject: Speeding up Icon prgms. Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: O I always hate to post my code, since it's usually not very good (I strive for readability more than anything else). What I'd like to know is whether there is somewhere in this program that I might have written things in such a way as to get increased speed. I'm not an experienced Icon programmer, so any ideas would be welcome. What this procedure does is split up texts formatted according to the standards followed in the Thesaurus Linguae Graecae. Works are marked by ~a"title", books by ~c"bookname", chapters by ~x and verses by ~y. A typical header looks like this: ~a"Bible"b"Hebrew"c"genesis". Subsequent chapters and verses are marked with ~x and ~y, respectively (on a line of its own). A typical text has: ~a"Bible"b"Hebrew"c"Genesis" GENESIS M7493K987XCKN2892(093K2309832K 09KSKLJXC98U4KLS 9832KKXZCKJS ~x PQOIWEUR 039854 V0-9834()LKWLJ23J $OKSLKXCPKL etc. The next book will begin: ~c"Exodus" EXODUS etc. What I am trying to do is splitup the chapters into individual files, naming each file after the title contained in the expression c"chapter". procedure main() y := 0 if not (outtext2 := open("junkfile","w")) then stop("cannot open chapter output file") write("input filename\:") if not (intext2 := open(read())) then stop("cannot open input file") write("finding first chapter") while line2 := reads(intext2,80) do {if find("\~",line2) then {if find("c\"",line2) then {close(outtext2) chapter := (line2[find("c\"",line2) + 2:0] ? move(upto("\"") - 1)) outtext2 := open(chapter,"w") write(y +:= 1," chapters") } } line2 := line2[1+:find(" ",line)] write(outtext2,line2) } end NB: Usually I get these things off tape, so that I need to strip trailing blanks off of the 80 character records the files are usually arranges in. That explains the need for "reads(intext2,80)" and at the end "line2[1+:find ..." As I said above, my concern is for speed. I want to write some programs to do more complex things to these texts, among them go to specific points in given files, and then reverse the string, so as to present natural Hebrew left-to-right order (I use special escape sequences to signal font changes to my terminal - a PC with a Hercules Plus card). But anyway, I'm concerned with questions like, "Which is faster, find or match, or upto?" How does one get to a specific point in a file in the least amount of time? Thanks to whoever might answer. !ihnp4!gargoyle!sphinx!goer goer@sphinx.uchicago.edu -Richard Goerwitz From icon-group-request Mon Oct 5 13:13:12 1987 From: sunuk!nuksun!stevie!steveh@Sun.COM (Steve Holden - TSE) To: sunuk!sun!arizona.edu!icon-group@Sun.COM Subject: Re: Speeding up Icon prgms. Errors-To: icon-group-request Status: O [ Caveat: I am new to this mailgroup, and so my Icon has been self-taught. I'll be asking my own, similar, questions about my programs soon! ] "Richard L. Goerwitz III" wrote in <2348@sphinx.uchicago.edu>: > What I'd like to know is whether there is somewhere in this program > that I might have written things in such a way as to get increased > speed. I'm not an experienced Icon programmer, so any ideas would be > welcome. First of all, have I understood the text format correctly? I presume what you want is to find a line beginning with a tilde "~" and a chapter name, extract the chapter name from it, then to copy that header line and all remaining lines up to but not including the next such line. One problem with the existing program is it might fail on a line such as ~a"Book"b"Generic" ^^ because the "c\"" will be thought to refer to a chapter, so we'll try and fix that as a by-product. Trimming spaces is most easily done on input, using the trim() function. I presume your junkfile only exists to throw away stuff before the first chapter heading; you could do this either by writing to /dev/null (on a U**X system) , or by re-structuring the program to simply not copy that first section. Let's suppose we have a procedure which will identify one of the "magic lines" and return the chapter name. The guts of the program could then be: procedure main() line := trim(read()) | stop("Empty input") until chapter := magicline(line) do line := trim(read()) | stop("No chapters") # # chapter now has chapter name in it # repeat { outtext2 := open(chapter,"w") write(outtext2,line) while line := (trim(read()) | break break) do if chapter := magicline(line) then break else write(outtext2,line) close(outtext2) } close(outtext2) # end The loop structure seems horrible, but I haven't written any Icon in a while. That takes care of the main problem. Now what about the magic lines? Remembering that every line is checked for magicness this test needs to be reasonably quick, but I see no way around some fairly complex checks on the syntax to avoid the problem I outlined above: procedure magicline(l) static namechars initial namechars := &ucase ++ &lcase # assumes letters only l ? { if ="~" then { # can't be magic without "~" while move(1) ~== "c" do # other bits ignored ( move(1) & tab(many(namechars)) & move(1) ) | fail ( c := (="c\"" & write("++",tab(many(namechars))))) | fail return c } } end I tried this on some simple test data: ~a"Bible"b"Hebrew"c"Genesis" GENESIS M7493K987XCKN2892(093K2309832K 09KSKLJXC98U4KLS 9832KKXZCKJS ~x PQOIWEUR 039854 V0-9834()LKWLJ23J $OKSLKXCPKL ~c"Exodus" EXODUS and got the following files: Genesis: ~a"Bible"b"Hebrew"c"Genesis" GENESIS M7493K987XCKN2892(093K2309832K 09KSKLJXC98U4KLS 9832KKXZCKJS ~x PQOIWEUR 039854 V0-9834()LKWLJ23J $OKSLKXCPKL Exodus: ~c"Exodus" EXODUS which seems to be what you wanted. As to whether it's any quicker or better-structured, I leave that to you to decide. These are the sorts of things I'm hoping the group will help me with! Steve From icon-group-request Mon Oct 5 15:14:41 1987 From: Michael Shafto To: icon-group%arizona.CSNET@RELAY.CS.NET, sunybcs!boulder!adamb@RUTGERS.EDU Subject: Re: What is Icon Anyway? Cc: shafto@AMES-AURORA.ARPA Errors-To: icon-group-request Status: O Let me know if the experts at Arizona don't reply. Mike Shafto From icon-group-request Mon Oct 5 15:20:59 1987 From: Michael Shafto To: goer@SPHINX.UCHICAGO.EDU, icon-group%arizona.CSNET@RELAY.CS.NET Subject: Re: Speeding up Icon prgms. Cc: shafto@AMES-AURORA.ARPA Errors-To: icon-group-request Status: O Richard -- For a kindred text-processing spirit, call Jim Nye at the Regenstein Library, 312/962-8430 Mike Shafto From icon-group-request Tue Oct 6 15:09:17 1987 From: ihnp4!ihlpe!orf Message-Version: 2 >To: /addr=ihnp4!gargoyle!sphinx!goer, /addr=ihnp4!arizona!icon-group End-Of-Header: Email-Version: 2 X-Postmark: owen.r.fonorow attis iw1z261 xmpi4000 3129797173 ihlpe!orf To: arizona!icon-group, gargoyle!sphinx!goer Subject: Re: Speeding Up Icon Programs Ua-Message-Id: End-Of-Protocol: Content-Length: 2003 Errors-To: icon-group-request Status: O Richard, You asked for some guidelines about improving the performance of Icon programs. The following rules of thumb seem to apply to the small program you sent: -------------------------------------------------------------------------- o match() is in a sense an "anchored" find() - so if you don't need to look through the entire string (i.e. you know the sequence will be the first two characters) then use match(). If your data is representative then: {if find("\~",line2) then {if find("c\"",line2) then can be replaced by: {if match("~c",line2) then This should avoid *many* unnecssary string comparisons. o Use correct "types" in built-in functions. Since upto() expects a cset, then upto("\"") is better replaced by upto('"') o Subscripting is expensive. Avoid it. This implies that the following lines need to be changed: chapter := (line2[find("c\"",line2) + 2:0] ? move(upto("\"") - 1)) line2 := line2[1+:find(" ",line)] One way is to set up a string scanning expression with line2 like this: while line2 := reads(intext2,80) do line2 ? { if match("~c") then {close(outtext2) move(3) & # Assumes ~c" sequence.... chapter := move(upto('\"') outtext2 := open(chapter,"w") write(y +:= 1," chapters") } } write(outtext2,trim(line2)) } end -------------------------------------------------------------------------- Again, This may not work with your data. My intent was to answer your question. There may be issue of getting information after the chapter name on a ~c" line. To summarize: o Use match() if appropriate to limit string comparisons o Use correctly typed arguments to built-in functions o Avoid subscripting. How this helps... O. Rick Fonorow ihnp4!ihlpe!orf (312) 979-7173 From icon-group-request Wed Oct 7 06:17:37 1987 From: sunuk!nuksun!stevie!steveh@Sun.COM (Steve Holden - TSE) To: sunuk!sun!arizona.edu!icon-group@Sun.COM Subject: Re: Speeding up Icon prgms. Errors-To: icon-group-request Status: O Ahem. I suppose we all have our off-days. I looked at the code I produced and decided it just wouldn't do (my hacking days came back to haunt me). Here is a re-write, more in keeping with the spirit of the Icon language. Thanks to the group for not taking me to task (or is no-one listening?) The output is tha same as for the previous one. procedure main() outtext2 := open("/dev/null","w") | stop("Cannot open /dev/null!!") while line := read() do line ? { if ="~" then # it's text if no "~" while c := move(1) & # parse a heading bit ="\"" & (chap := tab(many(~'"'))) & ="\"" do if c == "c" then { # new chapter found close(outtext2) # so open new file outtext2 := newchapter(chap) break # stop parsing } write(outtext2,line) # write to chapter file } close(outtext2) end procedure newchapter(chapname) return open(chapname,"w") | stop("Cannot create chapter ",chapname) end regards Steve From icon-group-request Wed Oct 7 15:21:22 1987 From: "Mr. nEtural" Organization: Up against the wall of SCIENCE Subject: Re: Speeding up Icon prgms. References: <8710052136.AA02391@ames-aurora.arpa> Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: O ) Richard -- ) For a kindred text-processing spirit, call Jim Nye at the Regenstein ) Library, 312/962-8430 ) Mike Shafto Note: The prefix here has changed from 962 to 702. James Nye's number is now 312-702-8430. From icon-group-request Wed Oct 7 17:47:20 1987 From: Ralph Griswold Organization: U of Arizona CS Dept, Tucson Subject: What is Icon? Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: O For persons who may not be familiar with the Icon programming language, here's a brief description and a pointer to more information. Icon is a high-level, general-purpose programming language that is well-suited for nonnumerical applications. Icon supports several data types, including variable-length strings, sets, lists with flexible access methods, and tables with associative lookup. Storage management is automatic. Icon has a goal-directed evaluation mechanism that allows concise solutions of many programming tasks to be formulated easily. Its string scanning facility is comparable to pattern matching in SNOBOL4, but Icon allows all language operations to be used in the analysis and synthesis of strings. Icon is available for a wide range of computers, including most UNIX systems, MS-DOS, VAX/VMS, the Atari ST, the Amiga, and the Macintosh (under MPW). These implementations are in the public domain and are available at a nominal cost from the Icon Project at the University of Arizona. For more information, contact: Icon Project Department of Computer Science Gould-Simpson Building The University of Arizona Tucson, AZ 85721 (602) 621-2018 icon-project@arizona.edu ... {ihnp4, allegra, noao}!arizona!icon-project Incidentally, the the name "Icon" has nothing to do with graphic images used to identify files on computer screens. The name was chosen before the latter use of the word came into vogue. The confusion is unfortunately, but it's too late to do anything about it. From icon-group-request Sun Oct 11 06:46:02 1987 From: Abrahams@MIT-Multics.ARPA Subject: New language features for Icon 7? To: icon-group@arizona.edu Errors-To: icon-group-request Status: O I have a couple of suggestions for additions to Icon. Perhaps it's not too late to get them into Version 7, if you like them. (1) There ought to be a notation for procedures with a variable number of arguments, such as "write". I propose that the argument list be put in square brackets, just like any other list (with the restriction that there be only one argument). Here's how to do "write" very elegantly in this notation: procedure write[args] local a, f f := &output every a := !args do if type(a) == "file" then f := a else write1(f, a) # write1(f, v) writes the value v to the file f write1(f, "\n") end (2) The Icon scoping mechanism is very weak, and is also almost independent of the other aspects of the language. As my programs get large, I need some way of restricting the scope of global variables without eliminating them altogether. I would like to see a "package" mechanism, where a package simply groups a set of global declarations (including procedures) and specifies which ones are exported to the surrounding environment. For simplicity, a package inherits anything known in the environment that surrounds it. For example: package P1 exports write_line, write_page, page_number global current_line, page_number record page_image(...) procedure write_page(...); ... ; end procedure insert_header(...); ... ; end procedure write_line(...); ... ; end procedure justify_line(...); ... ; end end P1 # or perhaps "end package" or even just "end" Although a multi-level package mechanism would be best, even a one-level version of it would be very useful. Paul Abrahams From icon-group-request Mon Oct 12 02:50:27 1987 From: sunuk!nuksun!stevie!steveh@Sun.COM (Steve Holden - TSE) To: sunuk!sun!arizona.edu!icon-group@Sun.COM Subject: Re: New language features for Icon 7? Errors-To: icon-group-request Status: O 1. Variable # of arguments: Seems reasonable if it's not too hard to incorporate. 2. The Icon scoping mechanism. I agree. The worst feature of things as presently set up is that on those odd occasions when you *have* to use a global variable in a package there is no protection against some other (possibly imported in ucode) package declaring the same global and using it. I would suggest a simpler syntax: private var1, var2, var2 should make the named variables globally available *only* within the scope of the current source file. Steve From icon-group-request Mon Oct 12 08:25:36 1987 From: Abrahams@MIT-Multics.ARPA Subject: Packages for Icon? To: icon-group@arizona.edu Errors-To: icon-group-request Status: O I hope that any package mechanism for Icon won't adopt what I consider to be the insane C rule that associates scopes with file structure. Steve Holden also raises an interesting question with his proposal for "private": should the default be public or private. I think it should be private; things should only be public if so declared. It would also be useful to have an outermost global level, both to provide compatibility with Icon as it is and to avoid any requirement that packages be used. I believe that all this is a translation-time and link-time issue, with little or no impact on the Icon compiler, which is the most difficult part of the Icon implementation. Am I right? Paul Abrahams From icon-group-request Mon Oct 12 12:22:18 1987 From: Mr Binary Organization: UW-Madison Primate Center Subject: Re: What is Icon? References: <2341@megaron.arizona.edu> Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: O Ralph Griswold gave the mail and e-mail addresses for more info on Icon. If you want, you can just ftp anonymously from arizona.edu. That's how I got mine. It took a while, though, if I remember correctly. --- Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!rhesus!dubois | ARPA: dubois@rhesus.primate.wisc.edu --+-- | "Suffering is the finger exercising of the spirit." - Mr. Theo | From icon-group-request Mon Oct 12 18:41:31 1987 From: Abrahams@MIT-Multics.ARPA Subject: Generating a list To: icon-group@arizona.edu Errors-To: icon-group-request Status: O Is there an elegant way to generate a list containing the result sequence of a given expression? I can write the following procedure that does it (I think), but perhaps there's a way to do it better: # listgen(a,n) returns a list whose elements are the result sequence of a. # If n is specified, then the length of the list is limited to n. procedure listgen{a} local e, retval retval := [] if integer(n) then every |(e := @a) \ n do put(retval, e) else while e := @a put(retval, e) return retval end Paul Abrahams From icon-group-request Thu Dec 31 11:48:51 1987 From: "David Gudeman" To: icon-group In-Reply-To: <871013012245.836237@MIT-Multics.ARPA> Subject: Generating a list Errors-To: icon-group-request Status: O Date: Mon, 12 Oct 87 21:22 EDT From: Abrahams@MIT-Multics.ARPA Is there an elegant way to generate a list containing the result sequence of a given expression? ... I usually use the following idiom, where expr is the expression for which you want the result sequence. ls := [] every put(ls, !expr) From icon-group-request Tue Oct 13 18:43:42 1987 From: "Kenneth Walker" To: icon-group Subject: variable args and packages Errors-To: icon-group-request Status: O Date: Sun, 11 Oct 87 09:42 EDT From: Abrahams@MIT-Multics.ARPA (1) There ought to be a notation for procedures with a variable number of arguments, such as "write". Version 7 of Icon (which we expect to release in a few months) will have a mechanism for handling a variable number of arguments. It will allow you to indicate that the last parameter should be list of the remaining arguments. The procedure declaration will look like: procedure p(a, b, c[]) If this is called with p(1, 2, 3, 4, 5) you will have a === 1 b === 2 c === [3, 4, 5] If this is called with p(1) you will have a === 1 b === &null c === [] (2) The Icon scoping mechanism is very weak ... I would like to see a "package" mechanism, where a package simply groups a set of global declarations (including procedures) and specifies which ones are exported to the surrounding environment. Some of the current research here at the U of A is aimed at developing an optimizing compiler (if this progresses to distribution, it certainly won't be with version 7). In order to do a reasonable job of optimization the compiler will have to know which variables are local to the compilation unit (that is, the file), which are exported and which are imported; so we will at least need to develop a simple "package" mechanism at the file level. This is what C does and seems to provide adaquate modularization for many programs. Does a more complex mechanism give enough benifit to justify the complexity? From icon-group-request Fri Oct 16 02:07:52 1987 From: "J. A. \"Biep\" Durieux" Organization: VU Informatica, Amsterdam Subject: Re: What is Icon? References: <2341@megaron.arizona.edu> Sender: icon-group-request%arizona.CSNET@RELAY.CS.NET To: icon-group%arizona.CSNET@RELAY.CS.NET Errors-To: icon-group-request Status: O If I read&remember well, the name Icon was chosen because the group considered itself rather iconoclastic. Somewhat of an amazing behaviour, for an icono*clastic* group to call a thing they love and care *Icon*. The world is full of wonders. -- Biep. (biep@cs.vu.nl via mcvax) Warning: this life is only an alpha test release, and will probably not be bug-free. No responsibility is taken for any damage that may result from the use of this life. Send any bug reports or enhance- From icon-group-request Fri Oct 16 10:34:03 1987 From: Abrahams@MIT-Multics.ARPA Subject: Arglists and packages To: icon-group@arizona.edu Errors-To: icon-group-request Status: O This is a reply to Ken Walker's comments on my proposals. (1) The notation procedure p(a,b,c[]) is quite elegant, and more general that what I had proposed. But why not allow the form procedure[a] as a synonym for procedure(a[]) (2) I'd be quite happy with a package mechanism that would provide only for exporting procedures and not variables. That would avoid the need to deal with any difficulties in optimization, because the whole problem would become very static. That is, packages would have variables declared internal to them, and would inherit all variables in their enclosing packages. The optimization problems are then no different than those we now have with global versus local. With this kind of packaging mechanism, the translator and compiler would not have much more work to do; the linker would bear the brunt of the task. The only tricky run-time issue is what the "proc" function does. But this could be solved by conceptually associating a run-time symbol table with every procedure; the name in the "proc" call would be looked up in that table. In practice, the symbol tables could be combined. I dislike the C approach to scoping because it forces every package to reside in a separate file and thus leads to the proliferation of files. It also leads to additional complications in resolving the different sets of externs, a problem that has led to incompatibilities among C compilers. Finally, it excludes the possibility of nested packages, which in fact are not at all hard to do. (Nested procedures are a different story, and I'm not advocating them.) Please don't do it that way. Paul Abrahams From icon-group-request Fri Oct 16 13:15:35 1987 From: "David Gudeman" To: icon-group In-Reply-To: <871016172837.628350@MIT-Multics.ARPA> Subject: Arglists and packages Errors-To: icon-group-request Status: O I rather like the package idea, but any new scoping mechanism should be a superset of the existing mechanism. This is necessary to insure backward (forward, upward, downward) compatibility with previous versions of Icon. It may come as a surprise to those who think of Icon as a teaching language, or a language for small one-shot programs, but there are actually large Icon programs out there in regular use. It would be unkind to obsolete all of these programs by not supporting their scoping mechanism in v7 of Icon. As a reminder, Paul Abrahams suggested a scheme where packages are defined by declarations of the form: package exports , , ... ... end where the s are local to the package unless they appear in the export part of the declaration. This can easily be made a superset of the current scheme by defining all declarations that don't occur in a package as members of package global, which exports everything. (Maybe Paul Abrahams had this in mind, I couldn't tell.) Another suggestion is to make "export" a separate declaration from package. This allows an orthogonal "import" declaration, for packages that want to restrict the visible name space. For backward compatibility, all modules would automatically import everything from the global package. From icon-group-request Sat Oct 17 15:30:12 1987 From: ihnp4!ihuxy!nowlin Message-Version: 2 >To: /addr=ihnp4!arizona!icon-group End-Of-Header: Email-Version: 2 X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin To: arizona!icon-group Subject: Re: variable args and packages Ua-Message-Id: End-Of-Protocol: Content-Length: 3872 Errors-To: icon-group-request Status: O > Version 7 of Icon (which we expect to release in a few months) will have > a mechanism for handling a variable number of arguments. It will allow you > to indicate that the last parameter should be list of the remaining > arguments. The procedure declaration will look like: > > procedure p(a, b, c[]) > > If this is called with > > p(1, 2, 3, 4, 5) > > you will have > > a === 1 > b === 2 > c === [3, 4, 5] > > If this is called with > > p(1) > > you will have > > a === 1 > b === &null > c === [] Why not pass all the arguments as a list (like the command line arguments in the main procedure) instead of having any formally declared arguments? This isn't a purely rhetorical question. It only seems natural to pass a list to a procedure if you want a variable number of arguments. The Icon printf() procedure I've seen worked this way. If the expression with which a procedure is called is forced to use a notation indicating a variable number of arguments it will make for more readable code. One of the trickier things to explain to novice C users is the concept of a variable number of arguments to the family of printf() system calls. The biggest reason is that the syntax of a calling expression does nothing to indicate that there's a variable number of arguments. On the other hand take the exec() family of system calls. The syntax of these functions makes it clear that there is a variable number of arguments. (Never mind that novice C programmers never figure out how to set them up.) Icon already has a simple mechanism for passing a list to a procedure and it seems like a waste of resources to make it more formal. If you want to call p(), from the above example, with a variable number of arguments and there are only three formal arguments in the declaration call it like this: p(1, 2, [ 3, 4, 5 ]) You end up with the same kind of parsing work in the procedure itself that exists with the proposed formal mechanism, but with this syntax what's happening is clear from the calling expression. It also has the advantage that the missing third argument is &null instead of an empty list, if only one argument is used. That follows the current Icon missing argument convention. What you currently have is the need for some documentation explaining how to use Icon in this way. Not the need for a more formal mechanism to provide a variable number of arguments. > (2) The Icon scoping mechanism is very weak ... > I would like to see a "package" mechanism, where a package simply > groups a set of global declarations (including procedures) and specifies > which ones are exported to the surrounding environment. > > Some of the current research here at the U of A is aimed at developing > an optimizing compiler (if this progresses to distribution, it certainly > won't be with version 7). In order to do a reasonable job of optimization > the compiler will have to know which variables are local to the > compilation unit (that is, the file), which are exported and which are > imported; so we will at least need to develop a simple "package" mechanism > at the file level. This is what C does and seems to provide adaquate > modularization for many programs. Does a more complex mechanism give enough > benifit to justify the complexity? The C mechanism of scoping "static global" variables to the source file in which they're declared is a handy thing to have. If Icon were to provide this type of scoping it would be useful. A more complex scoping scheme would be overkill. PLEASE, don't use "static global" like C. The difference between "static global" and "static local" variables is another one of those things that you're never really sure you've gotten across to new C programmers. Use any keyword but "static"! Jerry Nowlin (...!ihnp4!ihuxy!nowlin) From icon-group-request Sat Oct 17 15:31:57 1987 From: ihnp4!ihlpe!orf Message-Version: 2 >To: /addr=ihnp4!arizona!icon-group End-Of-Header: Email-Version: 2 X-Postmark: owen.r.fonorow attis iw1z261 xmpi4000 3129797173 ihlpe!orf To: arizona!icon-group Subject: Variable Scoping Ua-Message-Id: End-Of-Protocol: Content-Length: 1184 Errors-To: icon-group-request Status: O To: ihnp4!arizona!icon-group Subject: Re: variable args and packages > (2) The Icon scoping mechanism is very weak ... > I would like to see a "package" mechanism, where a package simply > groups a set of global declarations (including procedures) and specifies > which ones are exported to the surrounding environment. > > >This is what C does and seems to provide adaquate > >modularization for many programs. Does a more complex mechanism give enough > >benifit to justify the complexity? I'd just like to point out that in the case here where Icon was used to implement a large applications program, we had from 3 to 5 developers working on a system that ended up being about 20,000 NCLC before being translated to C. We didn't realize there was a problem with weak scoping. That is there were few - if any - software bugs that resulted from incorrect scoping (i.e. using an unintended variable with the same name). We did have to be careful about undeclared local identifiers in shared ucode libraries, but we made it a practice to always translate with -u flag to icont. Rick Fonorow p.s. Icon group: my new address is ihnp4!ihlpe!orf (not iwsam!orf) From icon-group-request Sun Oct 18 14:22:35 1987 From: "Kenneth Walker" To: icon-group Subject: variable args Errors-To: icon-group-request Status: O > Date: Fri, 16 Oct 87 13:28 EDT > From: Abrahams@MIT-Multics.ARPA > > (1) The notation > procedure p(a,b,c[]) > is quite elegant, and more general that what I had proposed. But why > not allow the form > procedure[a] > as a synonym for > procedure(a[]) I agree that your form for the case of one argument looks nicer than that of the general form, but I don't feel that the additional syntax is justified when you only save 2 key strokes and the feature is not likely to be used much. > From: ihnp4!ihuxy!nowlin > Date: Fri 16 Oct 1987 07:11 CDT > > Why not pass all the arguments as a list (like the command line > arguments in the main procedure) instead of having any formally > declared arguments? The motivation for adding variable argument lists to Icon is that any language which has built-in functions which take a variable number of arguments (write, writes, and stop) but does not allow user defined procedures to take a variable number of arguments is incomplete. This argument has been around for a long time, but it is only recently that someone (Bill Mitchell and Dave Gudeman) has actually implemented a variable argument feature in Icon. From icon-group-request Sun Oct 18 15:14:06 1987 From: "Kenneth Walker" To: icon-group Subject: packages Errors-To: icon-group-request Status: O > Date: Fri, 16 Oct 87 13:28 EDT > From: Abrahams@MIT-Multics.ARPA > > (2) I'd be quite happy with a package mechanism that would provide only for > exporting procedures and not variables. That would avoid the need to deal > with any difficulties in optimization, because the whole problem would become > very static. That is, packages would have variables declared internal to > them, and would inherit all variables in their enclosing packages. The > optimization problems are then no different than those we now have with > global versus local. The optimizations that I am interested in are based on type inference and I want to be able to do them without looking outside the compilation unit. I can accept the "outside world" sharing variables with the compilation unit, but I want to know which ones are actually shared. I have no way of knowing what affect an outside procedure will have on shared variables and must assume the worst. If I can limit the affect to a few variables I can do a better job of type inference. > From: ihnp4!ihlpe!orf > Date: Fri 16 Oct 1987 15:50 CDT > > I'd just like to point out that in the case here where Icon was used to > implement a large applications program, we had from 3 to 5 developers working > on a system that ended up being about 20,000 NCLC before being translated to > C. We didn't realize there was a problem with weak scoping. That is there > were few - if any - software bugs that resulted from incorrect scoping > (i.e. using an unintended variable with the same name). It seems to me that a big advantage of some kind of packaging mechanism would be in program maintenance. It is often a good idea to look to see how a variable or procedure is used before changing code that will affect it (just in case you are making some false assumptions). If you cannot limit the scope of the name, you have to look in all program files. Even with reasonable tools, this search is a pain when more than one file is involved. From icon-group-request Sun Oct 18 15:27:04 1987 From: "David Gudeman" To: icon-group In-Reply-To: <8710172230.AA27538@megaron.arizona.edu> Subject: variable args and packages Errors-To: icon-group-request Status: O From: ihnp4!ihuxy!nowlin Date: Fri 16 Oct 1987 07:11 CDT Why not pass all the arguments as a list (like the command line arguments in the main procedure) instead of having any formally declared arguments? .... The Icon printf() procedure I've seen worked this way. The Icon printf() procedure had to work that way because there was no more elegant way to do it. There is a conceptual difference between printf([...]) and printf(...). In the first, a single parameter is being passed to printf() as a list, in the second an arbitrary number of parameters is being passed. The printf() procedure may have to treat the cases the same, but to the caller they are different cases. If the expression with which a procedure is called is forced to use a notation indicating a variable number of arguments it will make for more readable code. I would say just the opposite. One of the trickier things to explain to novice C users is the concept of a variable number of arguments to the family of printf() system calls. The biggest reason is that the syntax of a calling expression does nothing to indicate that there's a variable number of arguments. I suspect that the hard thing to explain is that arguments following the format depend on the format. I never had any trouble explaining to complete novices how Pascal i/o procedures work. These procedures take a variable number of arguments also. .... If you want to call p(), from the above example, with a variable number of arguments and there are only three formal arguments in the declaration call it like this: p(1, 2, [ 3, 4, 5 ]) ... with this syntax what's happening is clear from the calling expression. But we don't want what's happening to be clear from the calling expression. The whole point of procedure abstraction is to make it so the calling procedure doesn't know what goes on in the called procedure, only what the affect is. The fact that the called procedure has to make a list of its arguments (to handle a variable number) should be opaque to the calling procedure. It also has the advantage that the missing third argument is &null instead of an empty list, if only one argument is used. This ``advantage'' was decided to be a peculiar and surprising affect, so we took deliberate steps to make a missing list argument be an empty list instead of &null. This lets the programmer loop directly on the list without first checking whether it is &null or not. Presumably, if the list is empty, then the loop will never be executed. .... PLEASE, don't use "static global" like C. Little chance of that. Actually, there is little chance of any change in Icon's scoping mechanism because the change would be both non-trivial and uninteresting (from the point of view of language research). Of course, if someone else wanted to implement a better scoping mechanism for Icon, I'm sure Ralph Griswold would be glad to consider putting it in the distributed version of Icon... From icon-group-request Sun Oct 18 17:56:59 1987 From: Abrahams@MIT-Multics.ARPA Subject: Variable number of args (again) To: icon-group@arizona.edu Errors-To: icon-group-request Status: O In response to Ken Walker's remark on my p[a] notation: I realized afterwards that p[a,b,c] is a nicer way to write what would be p(a,b,c[]) in the other notation. Another advantage is that it doesn't have similar forms that are illegal, such as p(a,b[],c) or p(a[],b,c[]) (or do those indeed have a meaning)? I agree that whatever the notation, it should be used in the procedure definition rather than at the point of call. Paul Abrahams From icon-group-request Mon Oct 19 11:37:55 1987 From: "Kenneth Walker" In-Reply-To: <871019005326.141703@MIT-Multics.ARPA> To: Abrahams@MIT-Multics.ARPA, icon-group@arizona.edu Subject: Re: Variable number of args (again) Errors-To: icon-group-request Status: O > Date: Sun, 18 Oct 87 20:53 EDT > From: Abrahams@MIT-Multics.ARPA > > In response to Ken Walker's remark on my p[a] notation: I realized > afterwards that p[a,b,c] is a nicer way to write what would be > p(a,b,c[]) in the other notation. Another advantage is that it doesn't > have similar forms that are illegal, such as p(a,b[],c) or p(a[],b,c[]) > (or do those indeed have a meaning)? Your notation is more compact, but I like the fact that p(a,b,c[]) emphasizes the asymmetry of argument handling. As for p(a,b[],c), I suggested at one point that we allow the list to go anywhere among the paramters with the interpretation that if there were enough arguments, it would take up the slack in the middle so the last parameter would get the last argument. The suggestion got shot down however. As I recall, the reasoning was that the parameters could always be rearranged to put the list at the end. It seems to me that p(a[],b,c[]) is inherently ambiguous. I suppose we could **generate** a sequence of calls, one for each valid arrangement of arguments into the lists (however, its not clear to me that this would be useful). From icon-group-request Mon Oct 19 15:42:32 1987 From: "Bill Mitchell" To: icon-group Subject: Re: Variable number of args (again) Errors-To: icon-group-request Status: O Having thought about this for some time, I think that what I like the best is procedure p[x] to indicate that x is a list of all the arguments. Although I was involved with the hacks for p(a,b,c[]), the ability to type stuff like p(a[],b,c) seems like an indication that a better idea is required. The above notation seems fairly clean in contrast, but there is the possibility of typing p[x,y,z]. From icon-group-request Tue Oct 20 04:01:24 1987 From: rosevax!ems!dayton!umn-cs!amit@uunet.uu.net (Neta Amit) Organization: University of Minnesota Subject: Re: Arglists and packages References: <871016172837.628350@MIT-Multics.ARPA> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-request Status: O In article <871016172837.628350@MIT-Multics.ARPA> Abrahams@MIT-MULTICS.ARPA writes: >This is a reply to Ken Walker's comments on my proposals. > >(1) The notation > procedure p(a,b,c[]) >is quite elegant, and more general than what I had proposed. For elegance and generality, consider the solution that has been available in many Lisp/Scheme dialects for many years: (define foo (a b c &optional d e &rest f) ...) At least three args must be provided and are bound to a, b and c. The next two args, if any, are bound to d and e. Any additional args form a list which is bound to f. If d, e or f args are not provided, those vars are assigned (). -- Neta Amit U of Minnesota CSci Arpanet: amit@umn-cs.cs.umn.edu From icon-group-request Tue Oct 20 05:20:22 1987 From: "David Gudeman" To: icon-group In-Reply-To: <2393@umn-cs.UUCP> Subject: Arglists and packages Errors-To: icon-group-request Status: O Date: 17 Oct 87 21:33:40 GMT From: rosevax!ems!dayton!umn-cs!amit@uunet.uu.net (Neta Amit) ... For elegance and generality, consider the solution that has been available in many Lisp/Scheme dialects for many years: (define foo (a b c &optional d e &rest f) ...) This essentially what the notation procedure foo(a, b, c, d, e, f[]) gives you. The only differences being that (1) _all_ the arguments are optional (the &optional keyword would be spurious in Icon), and (2) Only the list argument f is replaced with an empty list if it is missing, other missing arguments are replaced with the special value &null. From icon-group-request Wed Oct 21 22:13:50 1987 From: stuart@gargoyle.uchicago.edu (Stuart A. Kurtz) Organization: Dept. of Comp. Sci., The University of Chicago Subject: Re: The future of icon. Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-request Status: O A few random thoughts. 1) Re: scoping. Most of the suggestions about controlling the scope of variables has been to use C style scoping. I.e., scope at the file level only, and "protect" names by explicit static declarations. I would prefer (although it may be too late ...) to require explicit export statements, i.e., the default is not to export. Pro: This is better software engineering. Define an interface, and then stick with it. I envision a style with all of the export's at the top of the program, documented to describe the interface. Static variables (i.e., variables declared as "global") would then not contribute by default (and silently) to the interface. Con: Existing icon programs would be invalidated. At the very least, implementation of this suggestion would require adding another flag to icont "make all declarations external". 2) Re: varargs. I suspect that the syntax "procedure p[a]" is most reasonable. There is comparatively little reason to have "procedure p(a,b,[c])" or whatever, as icon permits fewer actual parameters than formal ones. Thus, "p(a,b,[c])", or its ilk, in no way "enforces" at least two parameters, which was the point behind the C varargs structure. Stu Stuart A. Kurtz Dept Computer Science The University of Chicago From icon-group-request Thu Oct 29 01:17:55 1987 From: clyde!burl!codas!mtune!lzaz!bds@rutgers.edu (BRUCE SZABLAK) Organization: AT&T ISL Middletown NJ USA Subject: Re: The future of icon. References: <779@gargoyle.UChicago.EDU> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-request Status: O Is there a symbolic debugger available for Icon? If not, there should be (or at least a true interpreter). From icon-group-request Mon Nov 9 11:36:32 1987 From: naucse!sbw (Steve Wampler) To: arizona!icon-group Subject: Not A Contest, but IconTest! Errors-To: icon-group-request Status: O While proctoring part of the ACM Mountain Regional Programming Contest, it struck me how well suited Icon was for the majority of the contest problems. "Hmmm," I say to myself... Announcing: The First Annual Great Icon Programming Test (IconTest for short) Problems will be chosen from the 1987 ACM Mountain Regional Programming Contest, and will be presented one at a time to the Icon programming community. Rules: Solve the problems using Icon, and mail the source to: Email: Steve Wampler {....!arizona!naucse!sbw} USmail: Steve Wampler College of Engineering and Technology Box 15600 Northern Arizona University Flagstaff, AZ 86011 Solutions must show the version of Icon used and any special options. (Don't just have the source print &version and &option - that isn't going to do much when I try it out on my end.) Judging will be entirely subjective, and based upon such abstract criteria as: (1) Correctness (2) Suitability of solution to Icon (3) Appropriate use of Icon language features. (4) Readability (note: Pascal-style Icon is not a priori more readable than other styles!) The decision of the judge(s) is final, though icon-project may be consulted during the judging to resolve sticky points. Duration: Each problem will remain open until a "winning" entry is found. Since mail times differ around the icon-group, there is a built-in hysteresis. All programs collected in a two week period will be judged as simultaneous arrivals. The "winning" programs will be posted back to icon-group. Eligibility: The contest is restricted to Icon programmers. Members of icon-project are encouraged to compete, but cannot win except by default (sorry, folks, life is tough). Prizes: Absolutely none, unless someone *else* wants to foot the bill. Now, a few comments. Some of the problems are particularly easy in Icon, occasionally requiring little more than consultation of the "Icon Programming Language" by Griswold and Griswold. Others might take a bit more design to find an appropriate solution approach for Icon. None are identified as being easy or hard. At least one of the problems is not necessarily well-formed in the problem statement. Sorry, I didn't write them. Make sure any assumptions you make are clearly specified - if they're incorrect assumptions, too bad. Where I've made typographical changes, the change is enclosed in square brackets ('[' and ']'). By the way, at the ACM contests, the programs must behave exactly to specs - no deviation from the specified output format is allowed. Just for grins, let's do that here as well. [ A^B for you Icon] Okay, let the games begin! From icon-group-request Mon Nov 9 11:39:44 1987 From: naucse!sbw (Steve Wampler) To: arizona!icon-group Subject: IconTest Problem #1 Statement Cc: cjh@mv2.arizona.edu, cst@mv2.arizona.edu, ewh@mv2.arizona.edu, gce@mv1.arizona.edu, igc@mv2.arizona.edu, jap@mv2.arizona.edu, jjt@mv1.arizona.edu, jmm@mv2.arizona.edu, jwse@mv2.arizona.edu, kds@mv2.arizona.edu, mer@mv2.arizona.edu, mjm@mv2.arizona.edu, pab@mv1.arizona.edu, pfr@mv2.arizona.edu, ptj@mv2.arizona.edu, rjb@mv1.arizona.edu, scc@mv2.arizona.edu, scs@mv1.arizona.edu, tgj@mv1.arizona.edu, wen@mv2.arizona.edu Errors-To: icon-group-request Status: O ----------------------------------------------------------------------------- IconTest Problem #1: The Big Powers: Your task is to read in pairs of positive numbers, A and B. They will be contained in two right justified fields of length and type integer. You are to then calculate the value of A raised to the power B, [ A^B ] for you [Icon] types. The output should be of the format: A = ddddd B = ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd . . . ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ddddd ..... The number should be padded on the left with leading zeros to ensure that the number of digits printed is divisible by 5. Digits are printed in groups of five, with an intervening blank between groups, and ten groups per line with the exception of the last line which may have between one and ten groups. The output will be 5,000 digits or less in length. ----------------------------------------------------------------------------- Mail source code for solution to: -Steve Wampler College of Engineering and Technology Box 15600 NAU, Flagstaff, AZ 86011 -{....!arizona!naucse!sbw} From icon-group-request Thu Nov 12 21:59:32 1987 Return-Path: From: Richard L. Goerwitz III To: icon-group@arizona.edu Subject: stripping Errors-To: icon-group-request Status: O I know it's a bit late now. But I've been wanting for some time now to see a strip command. Whether it be incorporated into map, or set up as a separate command, I don't really care. I assume that such a command has not been included in releases to date for some logical reason. I wonder what that reason is. And if it still holds (i.e. a primitive strip command will not be implemented), I wonder whether anyone could advise me as to what the best way of accomplishing a quick strip is. So far, I've been using: map(string,repl((char := !string),*string)) while i := upto(char,string) do string[i:many(char,string,i)] := "" Yuck! What a time-waster. A major slowup in my programs. Any better ideas? -Richard Goerwitz goer@sphinx.uchicago.edu From icon-group-request Fri Nov 13 23:59:06 1987 Return-Path: From: Richard L. Goerwitz III To: icon-group@arizona.edu Subject: stripping Errors-To: icon-group-request Status: O Okay, okay. I'm thoroughly chastened. In the letter I wrote about strippint, I asked a question: Why no primitive strip function? I also asked, how can I do a strip as quickly as possible, given the present tools? Unfortunately, I posted some code. That was silly. I used a reserved word where I shouldn't have, and then forgot to assign any variable to what was produced by map(str,...). Silly, silly, silly. And confusing. All I really wanted to know was what the fastest way to accomplish in icon what I accomplish in UNIX with "tr -d." This is a blanket response to all the justifiably confused people who wrote to me either telling me I was nuts, or thinking they were! The questions still, stand, though. Any thoughts? -Richard From icon-group-request Sat Nov 14 06:23:18 1987 From: "Ralph Griswold" To: goer@sphinx.uchicago.edu, icon-group@arizona.edu Subject: Re: stripping In-Reply-To: <8711140039.AA09415@sphinx.uchicago.edu> Errors-To: icon-group-request Status: O From icon-group-request Fri Nov 13 23:59:19 1987 Return-Path: From: Richard L. Goerwitz III To: icon-group@arizona.edu Subject: stripping Errors-To: icon-group-request Status: R Okay, okay. I'm thoroughly chastened. In the letter I wrote about strippint, I asked a question: Why no primitive strip function? I also asked, how can I do a strip as quickly as possible, given the present tools? Unfortunately, I posted some code. That was silly. I used a reserved word where I shouldn't have, and then forgot to assign any variable to what was produced by map(str,...). Silly, silly, silly. And confusing. All I really wanted to know was what the fastest way to accomplish in icon what I accomplish in UNIX with "tr -d." This is a blanket response to all the justifiably confused people who wrote to me either telling me I was nuts, or thinking they were! The questions still, stand, though. Any thoughts? -Richard The answer to your question as to why a "stripping" function is not included in the built-in repertoire of Icon is simply that there is not enough need for such a function to justify it. Every function that is added to the repertoire of a programming language increases the size of the language. If a function is widely useful or cannot be written as a procedure in the language, then having it built-in is important. But if it is relatively special-purpose and can be written as a procedure, then having it built-in can be a disadvantage -- it inceases the size of the implementation, the vocabulary programmers need to learn, the size of the documentation, and the maintenance load. Obviously, decisions like these are not clear cut. They depend on the philisophy of the design of the language, the opinions, style, and taste of the authors, and so on. Some folks think Icon should have a lot more built-in functions than it does. Others think it has many too many. The "stripping" operation is easy to write as a procedure in Icon. See the solution to Exercise 4.7 in the Icon Programming Language book. Of course, it's not as efficient as a built-in function; that's part of the trade-off. Icon also makes it fairly easy to add to its built-in repertoire by adding functions written in C. Source code for Icon is in the public domain and documentation on modifying it is extensive. So, if you want to, you can make a personalized version of Icon that has the built-in repertoire you want. From icon-group-request Wed Nov 18 08:06:24 1987 From: J65%TAUNIVM.BITNET@wiscvm.wisc.edu To: icon-group@arizona.edu Errors-To: icon-group-request Status: O sorry for bothering you all. pl. remove me from the mailing list. thanx. From icon-group-request Mon Dec 14 14:12:05 1987 To: From: Subject: no mail? Errors-To: icon-group-request Status: O I did not receive any mail from the Icon group since November 19. Have all members of the group become dumb, or is there any problem in email communications ? From icon-group-request Mon Dec 14 17:01:28 1987 From: Kee Hinckley Subject: Re: no mail? To: lecarme%frcicg71.bitnet@rutgers.EDU Cc: icon-group@arizona.edu, icon-group@arizona.edu In-Reply-To: lecarme%FRCICG71.BITNET@WISCVM.WISC.EDU, mon, 14 dec 87 17:10:20 Errors-To: icon-group-request Status: O I did not receive any mail from the Icon group since November 19. Have all members of the group become dumb, or is there any problem in email communications ? Well, I tried just recently but I can't seem to get through via 'icon-group@arizona.edu' anymore. -kee ### {mit-erl,yale,uw-beaver}!apollo!nazgul ### (Apple ][e ProLine BBS) ### ### apollo!nazgul@eddie.mit.edu ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. ------- From icon-group-request Tue Dec 15 01:12:28 1987 From: goer%sophist@gargoyle.uchicago.edu (Richard Goerwitz) To: icon-group@arizona.edu Subject: superficial equivalencies Errors-To: icon-group-request Status: O In a letter sent out several months ago, I noticed someone remarking on how the expression "if expr then expr else expr" is equivalent to (expr & expr) | expr. Perhaps the writer knew that this was not correct, strictly speaking. However, since it has proven a source of problems for me, and for other no- vices I have rubbed shoulders with, the exact facts of the matter are worth relating. Alternation does not imply any mutual exclusivity. The result sequence gen- erated by expr1 | expr2 is the sequence of results for expr1 followed by those for expr2. So if one executes every write(("a" & "b") | "c") one gets "b\nc" (b newline c). However, if one executes every write(if "a" then "b" else "c") one simply gets "b." The confusion here is caused by the fact that the two following lines are equivalent: write(("a" & "b") | "c") write(if "a" then "b" else "c") Both will simply write the first result produced by the expression or con- trol structure contained in parentheses. In both cases, this is simply "b." Likewise, in both cases, if "a" were to fail (impossible here), then we'd get "c." At first glance, therefore, the two seem to be equivalent. As I mentioned above, the difference only appears when write is preceded by every, since then we see that the result sequence produced by the top example has two members. The if...then...else structure produces only one result, "b" and "c" being mutually exclusive. Note that the if..then...else structure in fact produces a result. In contrast, write(every ...) writes nothing to the terminal. This is because while...do and every...do loops always continue until failing, at which point they terminate. So, in effect, they never produce a result. I realize that many of the more experienced ICON programmers will see this as rather basic. My aim here, however, is to help anyone who is still plodding through Griswold's ICON PROGRAMMING LANGUAGE to avoid some pitfalls that inexperienced programmers like me can easily fall into.... -Richard Goerwitz From icon-group-request Tue Dec 15 13:02:56 1987 From: "David Gudeman" To: icon-group In-Reply-To: Richard Goerwitz's message of Tue, 15 Dec 87 02:07:57 CST <8712150807.AA01759@sophist.uchicago.edu> Subject: superficial equivalencies Errors-To: icon-group-request Status: O I thought I would add something to the note about the similarity of (expr1 & expr2) | expr3 and if expr1 then expr2 else expr3 Another difference not mentioned in the note is that in the first expression, expr3 is evaluated if either expr1 or expr2 fails. In the second expresion, expr3 is only evaluated if expr1 fails. So the expression write(("a" & &fail) | "c") writes out a "c", while the expression write(if "a" then &fail else "c") doesn't write anything, it fails. From icon-group-request Wed Dec 16 20:36:40 1987 From: goer%sophist@gargoyle.uchicago.edu (Richard Goerwitz) To: icon-group@arizona.edu Subject: regular expressions Errors-To: icon-group-request Status: O Just wondered if anyone has attempted to write any ICON procedures that implement regular expression-ish pattern-matching, or if anyone has extended the interpreter to handle this sort of thing. -Richard Goerwitz !ihnp4!gargoyle!sophist!goer goer@sophist.uchicago.edu From icon-group-request Mon Dec 21 09:38:18 1987 From: NETWORK@FRSAC11.BITNET Subject: Benchmark needed. To: icon-group@arizona.edu Errors-To: icon-group-request Status: O Date: 21 December 1987, 16:44:54 GMT From: NETWORK at FRSAC11 To: ICON-GROUP at ARIZONA Who can send me some Icon sources to be used as benchmark ? I mean a/several pieces of software that exercise widely the language, to check the implementation speed on a particular hardware. The dhrystone of Icon ... With strings, generator, numbers, etc... I would prefer a single file, but a serie would be OK. (The time lo load, etc is more of a problem on several than on a single file.) I want to check the speed, not the implementation. I can measure wall clock time, not CPU. I do not have the complete port set for the current Icon (6.5), but I may have the one in BSD 4.3 sources (A 5.x Icon if I remember well) I have the greatest difficulty with the FTP access to megaron.arizona, very slow, response time in the minute range, etc. I call around 1 am PST, until 6 am PST, it should be easy then. I have tried twice today to retreive a file, and quit after 5 hours, for a 200K file. The FTP is issued from sumex-aim.stanford.edu. Can you check with your local network guru why am I having so much troubles ? Regards, Jean-Pierre H. Dumas network@frsac11 (bitnet) network%frsac11.bitnet@mitvma.mit.edu (arpanet) dumas@sumex-aim.stanford.edu (arpanet) From icon-group-request Mon Dec 21 15:32:24 1987 From: goer%sophist@gargoyle.uchicago.edu (Richard Goerwitz) To: icon-group@arizona.edu Subject: variables Errors-To: icon-group-request Status: O Re: Sets of ICON variables Seeing as variables are passed by value and not reference, it is difficult to perform the same operation on a series of variables with any degree of elegance or economy. I often end up doing things like a := doito(a) b := doito(b) c := doito(c) etc... I wonder if it would eventually be possible to include some mechanism in ICON for manipulating variables themselves (and not just their values). Or is there some basic problem with doing things this way...? -Richard Goerwitz From icon-group-request Mon Dec 21 15:49:51 1987 From: "Ralph Griswold" To: icon-group Subject: Suggestions for new language features for Icon Errors-To: icon-group-request Status: O There have been a number of suggestions for new Icon language features in recent mail. The lack of response from us doesn't mean we didn't get the mail or are insensitive to the ideas. It's more a matter of being backlogged and short-handed -- not to mention the holiday season. It's virtually impossible for us to respond intelligently to every suggestion that is made in a prompt manner (there are a lot more of you than there are of us, for one thing). At the moment, we're working hard to get Version 7 of Icon completed. While it won't answer all the questions and suggestions, it's the place to start. If you have questions about Icon and don't get the Icon Newsletter, send us a *postal* mailing address; we'll put you on our (free) subscription list and send you the last issue. You'll find a lot of your questions answered in the Newsletter and you'll also see what our resources are and why we can't do everything everyone wants us to do. From icon-group-request Mon Dec 21 16:00:29 1987 From: berry%jhereg.s1.gov@mordor.s1.gov To: ralph@arizona.edu Cc: icon-group@arizona.edu In-Reply-To: "Ralph Griswold"'s message of Mon, 21 Dec 87 15:49:49 MST <8712212249.AA08653@megaron.arizona.edu> Subject: Suggestions for new language features for Icon Errors-To: icon-group-request Status: O My subscription to the Icon newsletter seems not to have followed me to the Lab. here is my address now: Berry Kercheval Lawrence Livermore National Laboratory P.O. Box 808, L-270 Livermore, CA 94550 (415) 422-7387 Thanks! --berry From icon-group-request Mon Dec 21 17:14:04 1987 From: "Ralph Griswold" To: icon-group Subject: e-mail about Icon Errors-To: icon-group-request Status: O I should have mentioned that mail to icon-group@arizona.edu is redistributed automatically to a fairly large group of persons interested in Icon. That mail address is appropriate for matters of general interest about Icon. If you have a request about icon-group (such as to be added, your address changed, or to be deleted), mail to icon-group-request@arizona.edu. Such mail is not redistributed. For other specific matters (such as being added to the Newsletter mailing list), send mail to icon-project@arizona.edu. That will assure it gets handled here but will not result in redistribution to other sites. If you want to restrict your message to an individual here, send to that person, not icon-project, which goes to several persons. E.g., if you want to give me a piece of your mind, deliver it to ralph@arizona.edu. From icon-group-request Tue Dec 22 02:04:48 1987 From: "David Gudeman" To: goer%sophist@gargoyle.uchicago.edu Cc: icon-group@arizona.edu In-Reply-To: Richard Goerwitz's message of Mon, 21 Dec 87 16:29:03 CST <8712212229.AA08679@sophist.uchicago.edu> Subject: variables Errors-To: icon-group-request Status: O Date: Mon, 21 Dec 87 16:29:03 CST From: goer%sophist@gargoyle.uchicago.edu (Richard Goerwitz) ... I wonder if it would eventually be possible to include some mechanism in ICON for manipulating variables themselves (and not just their values). Or is there some basic problem with doing things this way...? -Richard Goerwitz Offhand I would say that this is not a problem in concept or in implementation, but it might cause problems with efficiency. We get a _lot_ of suggestions for additions to Icon, and many of them are interesting and/or useful. I would classify your suggestion as both. Obviously we cannot implement every useful suggestion, (or even most), since Icon is already a large language (maybe too large), and because it has a large user community that expects continuity between versions. However Icon is also a vehicle for research into programming languages, and we are always interested in how users feel about Icon and where they feel it needs improvement. For a more direct answer to your question: I doubt very much that such a feature will appear in the near future, as current research is moving in other directions. I like to think of our research as a traversal through a hugely branching tree of possible programming languages, searching for the Perfect Programming Language. It's not at all clear that the tree is finite. David Gudeman Department of Computer Science 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-request Tue Dec 22 06:29:13 1987 From: "Ralph Griswold" To: gudeman Subject: Re: variables Cc: icon-group In-Reply-To: <8712220904.AA27710@megaron.arizona.edu> Errors-To: icon-group-request Status: O Very nicely put. My only disagreement with you is that language research is a search through some existing structure. I see is as an endless architectural endeavor, deciding what to build next and what it should look like. From icon-group-request Tue Dec 22 12:33:59 1987 From: ihnp4!ihuxy!nowlin Message-Version: 2 >To: /addr=ihnp4!arizona!icon-group End-Of-Header: Email-Version: 2 X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin To: arizona!icon-group Subject: Re: variables Ua-Message-Id: End-Of-Protocol: Content-Length: 2005 Errors-To: icon-group-request Status: O > Seeing as variables are passed by value and not reference, it is difficult > to perform the same operation on a series of variables with any degree of > elegance or economy. I often end up doing things like > > a := doito(a) > b := doito(b) > c := doito(c) > etc... > > I wonder if it would eventually be possible to include some mechanism in > ICON for manipulating variables themselves (and not just their values). > > Or is there some basic problem with doing things this way...? > > -Richard Goerwitz It's easy to have doito() perform it's operation on a list of variables and return a new list with modified variables. I'd call that fairly elegant. You could call doito() with an already defined list: l1 := [a,b,c] l2 := doito(l1) or just pass the list of variables as a constant: l2 := doito([a,b,c]) or go even further and make doito() a generator: every i := doito([a,b,c]) do ... It sounds like what you want is procedures with side effects instead of procedures that act like functions, kind of like subroutines in FORTRAN. This is possible but the way that data structures like lists are normally operated on in Icon creates new copies of the list. The following procedure modifies the contents of a list and the modifications stay in effect in the main procedure. In order to avoid making a copy of the list during the processing you have to use subscripts. YECH! procedure main (args) dub(args) every write(!args) end procedure dub(lst) every i := 1 to *lst do lst[i] *:= 2 end The normal way I'd do this in Icon would be: procedure main (args) every write(dub(args)) end procedure dub(lst) every suspend !lst *:= 2 end This is elegant to me. Jerry Nowlin (...!ihnp4!ihuxy!nowlin) P.S. I tried to reply to the message about regular expressions last week but it didn't get out correctly. I have a grep written in Icon if anyone is interested. From icon-group-request Tue Dec 22 12:37:57 1987 From: "Janalee O'Bagy" In-Reply-To: <8712211638.AA18226@megaron.arizona.edu> To: NETWORK@FRSAC11.BITNET Subject: Re: Benchmark needed. Cc: icon-group Errors-To: icon-group-request Status: O We don't have what you need here at the Icon Project. The test suite that we use and distribute with source code is designed to verify proper functioning of all the language features--this suite would be inadequate for testing execution time. Maybe someone in the user community (i.e., icon-group) has developed such a collection of programs. I'll bring your troubles with FTP to the attention of our local expert. Janalee O'Bagy From icon-group-request Tue Dec 22 14:41:13 1987 From: ihnp4!ihuxy!nowlin Message-Version: 2 >To: /addr=ihnp4!arizona!icon-group End-Of-Header: Email-Version: 2 X-Postmark: jerry.d.nowlin attbl ix1c461 55621 3129790441 ihuxy!nowlin To: arizona!icon-group Subject: Re: variables Ua-Message-Id: End-Of-Protocol: Content-Length: 2006 Errors-To: icon-group-request Status: O > Seeing as variables are passed by value and not reference, it is difficult > to perform the same operation on a series of variables with any degree of > elegance or economy. I often end up doing things like > > a := doito(a) > b := doito(b) > c := doito(c) > etc... > > I wonder if it would eventually be possible to include some mechanism in > ICON for manipulating variables themselves (and not just their values). > > Or is there some basic problem with doing things this way...? > > -Richard Goerwitz It's easy to have doito() perform it's operation on a list of variables and return a new list with modified variables. I'd call that fairly elegant. You could call doito() with an already defined list: l1 := [a,b,c] l2 := doito(l1) or just pass the list of variables as a constant: l2 := doito([a,b,c]) or go even further and make doito() a generator: every i := doito([a,b,c]) do ... It sounds like what you want is procedures with side effects instead of procedures that act like functions, kind of like subroutines in FORTRAN. This is possible but the way that data structures like lists are normally operated on in Icon creates new copies of the list. The following procedure modifies the contents of a list and the modifications stay in effect in the main procedure. In order to avoid making a copy of the list during the processing you have to use subscripts. YECH! procedure main (args) dub(args) every write(!args) end procedure dub(lst) every i := 1 to *lst do lst[i] *:= 2 end The normal way I'd do this in Icon would be: procedure main (args) every write(dub(args)) end procedure dub(lst) every suspend !lst *:= 2 end This is elegant to me. Jerry Nowlin (...!ihnp4!ihuxy!nowlin) P.S. I tried to reply to the message about regular expressions last week but it didn't get out correctly. I have a grep written in Icon if anyone is interested. From icon-group-request Wed Dec 23 06:53:02 1987 From: "Ralph Griswold" To: icon-group Subject: This is a test. Errors-To: icon-group-request Status: O From icon-group-request Thu Dec 24 19:46:44 1987 From: steinmetz!ge-dab!codas!killer!nansonp@itsgw.rpi.edu (Paul Nanson) Organization: The Unix(R) Connection, Dallas, Texas Subject: dial-up Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-request Status: O I heard there is a dial system associated with the ICON project. The number given was (602) 621-2883. The settings were 300/1200/2400-E71, and login was guest. Is such a system in existence, and if so, are these the correct settings, etc? Paul Nanson From icon-group-request Thu Dec 24 20:44:57 1987 From: ihnp4!ihuxy!lied@ucbvax.Berkeley.EDU (Bob Lied) Organization: AT&T Bell Laboratories - Naperville, Illinois Subject: Substring positions Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-request Status: O I've finally gotten enough spare time to take a look at ICON, and I have a novice question (please don't hit me). In an example and a solution in chapter 5 of the book (I assume you know the book I refer to), the size of a substring is calculated with *line[i:j] where I would intuitively expect to use i-j I am inferring from this that string positions are like other languages' pointers in that their numerical values are not to be trusted, and I should limit their use to assignments, comparisons, and defined operations like subscripting. Am I right? Bob Lied ihnp4!ihuxy!lied AT&T Bell Laboratories From icon-group-request Tue Dec 29 20:49:57 1987 From: ihnp4!ihlpf!nevin1@ucbvax.Berkeley.EDU (00704A-Liber) Organization: AT&T Bell Laboratories - Naperville, Illinois Subject: Transmission of results to Co-expressions (need help) Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Errors-To: icon-group-request Status: O HELP!! How does one transmit results of expressions to co-expressions? I know that the example in the Icon book section 13.4.2 no longer works (I think I read about that in the Version 6 docs) and I tried the example given in technical report TR 87-6 (Programming in Icon; Part II -- Programming with Co-Expressions), but when I try to execute it I get run-time error 214 -- recursive co-expression activation. I could probably use a global variable but somehow that doesn't seem elegant. Please e-mail me any sample programs or explanations and I will summarize and post to the net. I am using Version 6.3 under MS-DOS with the LMM/FR executable; I have also tried it under Unix (Icon version 6.0) with the same error message. BTW, does anyone know what's coming up in Version 7?? :-) Here is a copy of the program found in TR 87-6 pp 10-11: global words, lines, writer procedure main() words := create word() lines := create reader() writer := create output() @writer end procedure word() static letters initial letters := &lcase || &ucase while line := @lines do line ? while tab(upto(letters)) do tab(many(&lcase)) @ writer end procedure reader() while read() @ words end procedure output() while write(@words) @&main end Thanks (in advance)!! -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_ To: icon-group Subject: Co-Expression Transmission and Version 7 Errors-To: icon-group-request Status: O Co-expression transmission cannot be made to work in a useful way in the distributed Version 6 of Icon. We have the problem corrected, and the results will be available in Version 7. We presently expect Version 7 to be available for UNIX systems late in January and for MS-DOS systems a couple of weeks later. The release of Version 7 will be annnounced via icon-group. From icon-group-request Wed Dec 30 16:19:19 1987 From: "David Gudeman" To: ihnp4!ihuxy!lied@ucbvax.Berkeley.EDU, icon-group In-Reply-To: (Bob Lied's message of 25 Dec 87 00:31:22 GMT <2321@ihuxy.ATT.COM> Subject: Substring positions Errors-To: icon-group-request Status: O From: ihnp4!ihuxy!lied@ucbvax.Berkeley.EDU (Bob Lied) .... In an example and a solution in chapter 5 of the book (I assume you know the book I refer to), the size of a substring is calculated with *line[i:j] where I would intuitively expect to use i-j I am inferring from this that string positions are like other languages' pointers in that their numerical values are not to be trusted, and I should limit their use to assignments, comparisons, and defined operations like subscripting. Am I right? Well, not really. String positions are integer positions _between_ the characters of the string, where 1 is the position at the beginning of the string. However, non-positive integers are also valid string positions (with 0 at the end of the string). So if i or j is non-positive, it is not true that "*line[i:j] = j-i" (I assume you meant "j-i" rather than "i-j"). In the example in the book, both i and j are guaranteed to be positive, so "j-i" works. Notice though, that in most languages the positive integers refer to character positions, so the correct formula for the length of a substring from i to j is "j-i+1". Perhaps the authors wanted to avoid confusing readers with this subtlety. From icon-group-request Thu Dec 31 09:06:28 1987 To: arizona!icon-group-request, arizona!icon-group, arizona!icon-project Subject: Sample programs and subscription From: noao!rutgers!gatech!rebel!dkstar!n8emr!uncle!jbm@hao.UCAR.EDU (John B. Milton) Errors-To: icon-group-request Status: O Please add my name to the newsletter distribution and the discussion group. Also: I am trying to get a grip on this language and what I need next is some sample programs that are of decent size, that are not in the book. Thank you very much John -- John Bly Milton IV, jbm@uncle.UUCP, {ihnp4|cbosgd}!n8emr!uncle!jbm home: (614) 294-4823, work: (614) 459-7644, FLAME via email :) From icon-group-request Thu Dec 31 11:53:09 1987 From: Michael Shafto To: gudeman@arizona.edu, icon-group@arizona.edu, ihnp4!ihuxy!lied@ucbvax.Berkeley.EDU Subject: Re: Substring positions Cc: shafto@AMES-AURORA.ARPA Errors-To: icon-group-request Status: RO For what it's worth: When I first started using Icon, I thought the string/list subscripting conventions were extremely counter-intuitive and confusing; and, in fact, they caused me to make a number of annoying errors. E.g., even if you know better, a := el[1:3] looks like a good way to pick off the first three elements of a list. Now it seems to me that these conventions are unusual, but worth getting used to. Once you get the hang of them, they seem pretty neat. Mike