From icon-group-request Wed Jan 1 09:42:23 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 1 Jan 92 09:42:23 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA06371; Wed, 1 Jan 92 09:42:21 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA27710; Wed, 1 Jan 92 08:35:03 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Dec 91 22:51:53 GMT From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!convex!russur@ames.arc.nasa.gov (Russ Urquhart) Organization: CONVEX Computer Corporation, Richardson, Tx., USA Subject: Snobol4 to Icon: A converter? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I'm kind of new to this group, so if this question has already been asked/answered, please bear with me. I an looking for a snobol4 to icon conversion. I have some snobol4 programs that I would like to convert and use under icon. Any help would be appreciated! Thanks Russ Urquhart Convex Computer Corporation From icon-group-request Wed Jan 1 23:18:45 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 1 Jan 92 23:18:45 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA25319; Wed, 1 Jan 92 23:18:43 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA05563; Wed, 1 Jan 92 17:05:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Dec 91 17:56:39 GMT From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!wupost!dsuvax.dsu.edu!ghelmer@ames.arc.nasa.gov (Guy Helmer) Organization: Dakota State University Subject: CFP: SIXTH INTERNATIONAL CONFERENCE on SYMBOLIC and LOGICAL COMPUTING Message-Id: <1991Dec13.175639.23063@dsuvax.dsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu SIXTH INTERNATIONAL CONFERENCE on SYMBOLIC and LOGICAL COMPUTING DAKOTA STATE UNIVERSITY MADISON, SOUTH DAKOTA OCTOBER 15 - 16, 1992 ICEBOL6, the Sixth International Conference on Symbolic and Logical Computing, is designed for teachers, scholars, and programmers who want to meet to exchange ideas about computer programming for non-numeric applications -- especially those in the humanities. In addition to a focus on SNOBOL4, SPITBOL, and Icon, ICEBOL6 invites presentations on textual and logical processing in a variety of programming languages such as Prolog and C. Topics of discussion will include artificial intelligence and expert systems, and a wide range of analyses of texts in English and other natural languages. Parallel tracks of concurrent sessions are planned. ICEBOL's coffee breaks, social hours, lunches, and banquet will provide a series of opportunities for participants to meet and informally exchange information. CALL FOR PAPERS Abstracts (250-750 words) of proposed papers to be read at ICEBOL6 are invited in any area of non-numeric programming. Planned sessions include the following: analysis of texts (including bibliography, concordance, and index generation) artificial intelligence and expert systems computational linguistics computer languages and compilers designed for non-numeric processing electronic texts and encoding grammar and style checkers linguistic and lexical analysis (including parsing and machine translation) music analysis preparation of texts for publishing Papers must be in English and may not exceed twenty minutes reading time. Abstracts should be received by March 1, 1992. Notification of acceptance (based on recommendations of readers) will follow promptly. Papers will be published in ICEBOL6 Proceedings. Presentations at previous ICEBOL conferences were made by Paul Abrahams (ACM President), Gene Amdahl (Andor Systems), Robert Dewar (New York University), Mark Emmer (Catspaw, Inc.), James Gimpel (Lehigh), Ralph Griswold (Arizona), Susan Hockey (Oxford), Nancy Ide (Vassar) and many others. Copies of the ICEBOL5 Proceedings are available. FOR FURTHER INFORMATION All correspondence including abstracts of proposed papers as well as requests for registration materials may be sent to: Eric Johnson ICEBOL Director 114 Beadle Hall Dakota State University Madison, SD 57042 U.S.A. Inquiries, abstracts, and correspondence are encouraged via electronic mail, and they may be sent to Eric Johnson at: ERIC@SDNET.BITNET or johnsone@dsuvax.dsu.edu -- Guy Helmer, Dakota State University Computing Services ghelmer@dsuvax.dsu.edu, helmer@sdnet.bitnet, dsuvax!ghelmer@wunoc.wustl.edu Whip me, beat me, but don't make me maintain BASIC code! From icon-group-request Thu Jan 2 14:18:45 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Jan 92 14:18:45 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA00596; Thu, 2 Jan 92 14:18:42 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA22969; Thu, 2 Jan 92 08:07:02 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Jan 92 19:22:27 GMT From: att!cbnewsj!dsk@ucbvax.berkeley.edu (donald.s.klett) Organization: AT&T Bell Laboratories Subject: Icon Version 8 System for Mac Message-Id: <1992Jan2.192227.3854@cbnewsj.cb.att.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I have ported the Icon translator and interpreter to the Macintosh using THINK C 5.0.1 under System 7. This is not the MPW version. I used the "console" feature in THINK C. Since I am not sure how much interest there is in the Mac community, I will initially offer to e-mail the binaries to anyone interested. Just send e-mail making the request. Source code is not available from me, but may be available from the Icon project. I submitted the ported code to the project. At this stage, coexpressions are not activated, and calling C routines is not supported. Don Klett dsk@arch3.att.com (908)949-2283 From icon-group-request Fri Jan 3 21:10:07 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 3 Jan 92 21:10:07 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA06817; Fri, 3 Jan 92 21:10:01 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA08162; Fri, 3 Jan 92 20:05:15 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Jan 92 07:12:19 GMT From: csus.edu!wupost!spool.mu.edu!munnari.oz.au!uniwa!gudjm@ucdavis.ucdavis.edu (D John McKenna) Organization: University of Western Australia Subject: Re: tic-tac-toe Message-Id: <1992Jan3.071219.3395@uniwa.uwa.oz.au> References: <9112241206.AA05909@relay2.UU.NET> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu nowlin@isidev.UUCP writes: >The reason I brought this up was the tic-tac-toe game that's popped up here >a couple of times lately. The nim program has a learning mode (which is >what made it applicable to the AI seminar) that applies real well to >tic-tac-toe since tic-tac-toe has a finite range of possible "states" that >can be recorded in game memory. The nim game remembers the success or >failure of a given choice for a given "state" of the game and eventually >only makes choices for a given "state" that result in success. It learns >by playing so it tends to make stupid moves for the first five or ten >games. Then if it was playing someone smart it gets just as good. The >same learning mode could be easily applied to tic-tac-toe. >I would tackle it but thought I'd give the original poster a shot at this >technique first. Tic-tac-toe has a more difficult algorithm than nim >(although not that hard) so the learning version may be easier to program >than the algorithmic version. A neat trick would be to have the game >record it's game memory in a file so it doesn't have to learn all over >again every time the game is started. The nim game doesn't (yet). Your mention of a learning tic-tac-toe reminds me of something I saw in some book produced by Reader's Digest many years ago. This was circa 1980, maybe earlier. There was a method of creating a learning tic-tac-toe system, where every possible situation (except reflections, of course) were drawn on a macthbox - that is, one matchbox per situation. Each possible next move by the opponent was drawn in a different colour - ie green if the opponent moves into the top left corner, red if the opponent moves into the centre, etc. Each move is represented by a coloured bead in the matchbox. Once this is all set up, you begin playing. So you do your move - maybe in the centre of the grid. Then, taking the matchbox that represents this situation, you take a bead out of it at random, to determine the system's move. You then do your move, and get the matchbox representing that situation, etc. This continues till the game is over. If the system loses, you destroy the last bead you drew - ie leave it out of the matchbox in future. Now I think about it, the game wasn't tic-tac-toe - it was played on a 3 by 3 grid with chess pawns - the top row had 3 pawns belonging to the human, and the bottom row had 3 pawns belonging to the system. But the same principles applied. It was interesting to me - I was probably younger than ten when I did this - my first contact with AI I suppose, although I didn't know it at the time. Oh well, that was much harder to explain than it should be. Steven McLeod (posing as John Mckenna) - the man without a signature From icon-group-request Sat Jan 4 03:52:32 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 4 Jan 92 03:52:32 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA24629; Sat, 4 Jan 92 03:52:29 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA00564; Sat, 4 Jan 92 02:40:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Dec 91 18:53:06 GMT From: arizona.edu!arizona.edu!news@arizona.edu (Kurt Parten) Organization: Dept of Electrical and Computer Engineering, University of Arizona, Tucson, Arizona Subject: read() problems Message-Id: <1991Dec12.115308.2254@arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Is there a way for read to be OS independent, so that DOS text files look like UNIX text files. I'm running icon under UNIX, but the data files are in DOS format. I would like to get rid of the ^M character that shows up in every line. I tried trim(read(dosfile), "\r"), but that transformed h e l l o \r \n to: h e l l o \r \r \n instead of h e l l o \n -- Kurt Parten parten@helios.ece.arizona.edu From icon-group-request Sat Jan 4 14:28:57 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 4 Jan 92 14:28:57 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA07848; Sat, 4 Jan 92 14:28:55 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA06274; Sat, 4 Jan 92 13:17:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Dec 91 01:44:22 GMT From: mips.mitek.com!utacfd.uta.edu!utagraph.uta.edu!utarlg.uta.edu!b912dieg@apple.com (DOUG WITMER) Organization: The University of Texas at Arlington Subject: Memory Mangement Message-Id: <1991Dec19.015629.3966@utagraph.uta.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu This question is directed at those having an in depth knowledge of ICON internals and in particular ICON memory management. I know from my readings that the ICON system finds it necessary to perform frequent garbage collections to maintain an adequate supply of unfragmented memory. I also know that ICON is implemented in the C language. My question stems from a claim which I read today concerning the Mathematica language which is also implemented in C. Here is what they say about garbage collection: Mathematica does memory management with reference counts, so that pieces of memory are freed as soon as they stop being used. This means that Mathematica can make use of essentially all the memory that is available on a particular computer, without the need for operations such as garbage collection. (Mathematica by Wolfram 1988:xvi) Does anyone have an explanation of reference counts? Can the use of reference counts really eliminate garbage collection? Thanks for helping satisfy my curiosity. Doug Witmer b912dieg@utarlg.uta.edu From icon-group-request Mon Jan 6 16:06:26 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 6 Jan 92 16:06:26 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA19180; Mon, 6 Jan 92 16:06:21 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA18045; Mon, 6 Jan 92 14:50:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Dec 91 03:22:27 GMT From: ksr!tim@uunet.uu.net (Tim Peters) Organization: Kendall Square Research Corp. Subject: Re: Memory Mangement Message-Id: <8080@ksr.com> References: <1991Dec19.015629.3966@utagraph.uta.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1991Dec19.015629.3966@utagraph.uta.edu> b912dieg@utarlg.uta.edu writes: >... >I know from my readings that the ICON system finds it necessary to >perform frequent garbage collections to maintain an adequate supply of >unfragmented memory. Guess I'll have to do until a real expert comes along . The frequency of Icon garbage collection depends on an awful lot of things. In general, I'd say that if Icon *is* doing collections frequently, there's an easily-changed (if not easily-found ...) way to stop that by rewriting a bit of the Icon application. For most Icon programs most times, garbage collection should not be a problem; indeed, for many real Icon programs garbage collection is never needed at all. > ... > Mathematica does memory management with reference counts, > so that pieces of memory are freed as soon as they stop > being used. This means that Mathematica can make use of > essentially all the memory that is available on a > particular computer, without the need for operations such > as garbage collection. (Mathematica by Wolfram 1988:xvi) > >Does anyone have an explanation of reference counts? >Can the use of reference counts really eliminate garbage collection? Dynamic memory management has become a rather large field by now, but the intro in Knuth's "Art of Computer Programming" (Volume 1) remains helpful. Assuming you can read Icon, here's a fragement to help explain the differences: B := [2] A := [1, b, 3] # === [1, B === pointer to [2], 3] B := &null A := &null I'll call those lines #1, #2, #3 and #4. Icon-style garbage collection works by (in effect) putting a mark on all the memory you can possibly reference, then reusing all the memory that is *not* marked (it's trickier than that, of course, but I think that's a fair summary of the basic idea). So if garbage collection (GC) occurs right after line #2, the memory earlier allocated for the lists A and B will get marked, because you could still reference that memory in the future just by mentioning A or B. If GC occurs after #3, we must still keep all the memory around, but for a subtler reason: even though you can't reference the [2] list directly via B any more, the garbage collector knows you might still reference A, and the value of A still contains a pointer to the list that used to be named by B. So all the allocated memory is still potentially reachable, so the garbage collector can't reuse it. GC must in general not only mark all the memory reachable in "one step", but all the memory reachable from that in turn, and so on & so on. If GC occurs after #4, of course neither of the earlier-allocated lists are reachable, so the memory they occupy won't get "marked", so that memory will get reused. The general behavior is that "the system" doesn't worry about memory until it runs out of it, at which point it stops everything else to find & recycle the old memory that's no longer being used. This can take an appreciable amount of time when it happens, and of course the collector is itself a program that needs memory for its own use. That's the likely source of the (misleading; see below) claim that Mathematica can use "essentially all" the memory for real stuff. Reference counting (RC) is a different technique. Under RC, each piece of allocated memory keeps track of how many times it's pointed *at* by other pieces of memory; when this count drops to 0, the memory can be reused (that the count is 0 *means* that it's not being pointed at). So in executing line #1, a piece of data is attached to the [2] list that records that the [2] list is pointed at once (by the program variable A). In executing line #2, the "reference count" for the [2] list must be bumped up by 1 because the [2] list is again referenced by a pointer embedded in the A list. In addition, a RC of 1 must be attached to the list assigned to A. In line #3, the system sees that B is being changed to point at a different chunk of memory, so the RC of what it used to point at (the [2] list) must be decreased by 1. This will decrease it from 2 to 1. Since it's 1, it's still being pointed at by something, so the system can't reuse it. Similarly, in line #4 the reference count of the A list is decreased from 1 to 0. Aha! Since it's 0, nobody else is referencing it, so the system can reuse it. Since it will be reused, the reference counts of everything *it* points at must also be decreased by 1, so the system has to examine the A list carefully to find all the things it points at. It will find that it's pointing to the [2] list, so will decrease the [2] list's RC by 1. That in turn decrease's the [2] list's RC to 0, so that's no longer used either. The system then searches thru the [2] list in order to find anything *it* may be referencing, but doesn't find another pointer so the process stops there. There are several things to note about this: (1) It takes memory to store the reference counts. So a claim that an RC approach lets you use "almost all" the available memory for "real stuff" is misleading. (2) Like Icon-flavor GC, RC also needs to recursively traverse your data structures looking for contained pointers. (3) It takes time to increase and decrease the counts. (4) While Icon-flavor GC lumps all the work together at one time, RC-based systems tend to spread the work out over time so that memory-management "hiccups" (pauses) aren't noticeable. (5) An RC-based system does all the work of maintaining the counts whether or not you eventually run out of memory; so an Icon- flavor GC gets off cheaper in the common case where the initial memory region suffices. Dynamic memory management is a very involved topic, and the stuff above conveniently ignored almost all the interesting problems & possible workarounds in both systems. They both face real problems in practice! As another complication, almost all large programs (like Icon, and probably Mathematica too) use several different strategies (e.g., Icon uses a different scheme for strings than it uses for co-expressions, and so on). I just hoped to convey enough of the essentials to make you skeptical of marketing hype . from-what-i-know-of-them-icon's-strategies-are-very-intelligent-choices- for-icon's-needs-and-i'd-be-real-surprised-if-mathematica's-choices- weren't-intelligent-for-its-needs-ly y'rs - tim Tim Peters Kendall Square Research Corp tim@ksr.com, ksr!tim@uunet.uu.net From icon-group-request Mon Jan 6 16:34:14 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 6 Jan 92 16:34:14 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA20619; Mon, 6 Jan 92 16:34:11 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA19778; Mon, 6 Jan 92 15:22:35 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Dec 91 04:52:15 GMT From: news@psuvax1.cs.psu.edu (Felix Lee) Organization: Penn State Computer Science Subject: Re: Memory Mangement Message-Id: References: <1991Dec19.015629.3966@utagraph.uta.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu > Mathematica does memory management with reference counts, > so that pieces of memory are freed as soon as they stop > being used. This means that Mathematica can make use of > essentially all the memory that is available on a > particular computer, without the need for operations such > as garbage collection. (Mathematica by Wolfram 1988:xvi) This is called "propaganda": condensing many subtle issues into a sweeping, positive-image statement. The memory management problem is this: if X used to refer to A but now refers to B, you can reuse the memory occupied by A, but only if noone else is using A. Reference counting (RC) is giving each object a count of how many things are using it. When you assign X = A, you increase A's count by one. When you later assign X = B, you decrease A's count, and increase B's count. When the count for something reaches zero, you know that noone is using it, so you can reclaim it. The main flaw is this does not handle circular references. Say that A refers to B and B refers to A, but neither A nor B is being used any more. In principle you can reclaim both A and B, but RC cannot discover this fact easily. This isn't a problem if you can't create recursive structures. Perhaps Mathematica forbids them. But these types of structures are quite natural and common in languages like Icon and Lisp. Garbage collection (GC) strategies are more general than RC. Rather than continually doing RC bookkeeping, you periodically discover which objects are in use and reclaim everything else. There are several different strategies for this, with different contraints and characteristics. I'm not going to describe them here. The main flaw with GC is it has a bad image. At apparently random times, the system may pause for several seconds to do GC. But modern GC systems tend to behave well, and there's still plenty of active research into improving GC in different ways. There is good evidence that, overall, GC is more efficient than RC. All the bookkeeping involved in RC doesn't come free. However, the costs get amortized over all operations, giving you a more predictable response time. This is attractive for interactive and real-time use, as long as you can ignore the circular-reference problem. Incremental and concurrent GC strategies may be viable alternatives. Memory fragmentation is a related issue. If you allocate variably sized pieces of memory, then the available memory in the system tends to become scattered into many small pieces over the course of many allocations and deallocations. Now say you need to allocate 16 bytes. There may be more than 1600 bytes of memory available, but you won't be able to use any of it if all the pieces are smaller than 16 bytes. RC is not enough to ensure you can actually use "all the memory that is available on a particular computer". Pathological fragmentation is unavoidable in general unless you do garbage compaction. This involves moving all the objects in memory to collect the available memory into a single area. This suffers from all the performance objections that apply to GC. Note, however, that with some types of GC you get compaction for free. Now, try to condense all this into a simple blurb. "Mathematica uses reference counting instead of garbage collection because it seemed like a good idea at the time." Not very marketroidish... -- Felix Lee flee@cs.psu.edu From icon-group-request Tue Jan 7 17:37:14 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 7 Jan 92 17:37:14 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA21434; Tue, 7 Jan 92 17:37:11 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA17595; Tue, 7 Jan 92 16:20:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Jan 92 22:50:53 GMT From: autodesk!drake@apple.com (Dan Drake) Organization: Autodesk Inc., Sausalito CA, USA Subject: Re: tic-tac-toe Message-Id: <9512@autodesk.COM> References: <1992Jan3.071219.3395@uniwa.uwa.oz.au+ Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu gudjm@uniwa.uwa.oz.au (D John McKenna) writes: + Your mention of a learning tic-tac-toe reminds me of something I saw in + some book produced by Reader's Digest many years ago. This was circa + 1980, maybe earlier. + + There was a method of creating a learning tic-tac-toe system, where + every possible situation (except reflections, of course) were drawn on a + macthbox - that is, one matchbox per situation. Each possible next move + by the opponent was drawn in a different colour - ie green if the + opponent moves into the top left corner, red if the opponent moves into + the centre, etc. Each move is represented by a coloured bead in the + matchbox. Once this is all set up, you begin playing. Reader's Digest? Interesting. It was first written up in the early 60's in the Amateur Scientist department (I think) of Scientific American. It was called Matchbox Educable Naughts And Crosses Engine, or Menace. No worse than Oak Ridge Automatic Computing and Logical Engine, which was an ORACLE long before Larry whatsisname got into business. + ... + Now I think about it, the game wasn't tic-tac-toe - it was played on a 3 + by 3 grid with chess pawns - the top row had 3 pawns belonging to the + human, and the bottom row had 3 pawns belonging to the system. But the + same principles applied. It was interesting to me - I was probably + younger than ten when I did this - my first contact with AI I suppose, + although I didn't know it at the time. The Hexpawn game was described in the same SciAm article, as another candidate for this treatment. I implemented it as my first non-trivial assembler program, on an IBM 1620 in 1965. Decimal assembly language. NO arithmetic capability in the hardware; just table lookup. 160 microseconds for a NO-OP. Those were the days. -- Dan Drake "When you're as good as I am, it's hard to be humble" drake@Autodesk.com "It wasn't hard for Einstein; so what's _your_ problem?" From icon-group-request Tue Jan 7 19:22:40 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 7 Jan 92 19:22:40 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA24614; Tue, 7 Jan 92 19:22:38 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA23397; Tue, 7 Jan 92 18:16:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Jan 92 16:58:51 GMT From: walter!MERLIN.ims.bellcore.com!attila@uunet.uu.net (Leslie A. Walko) Organization: Bellcore - IMS, Morristown, NJ Subject: windows interface ? Message-Id: <1992Jan7.165851.20951@walter.bellcore.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Hello, Is there an operating system independent graphic system for Icon? What I have in mind is a UIMS such as CLIM (Common Lisp Interface Management System) that can provide high level graphics and presentation services. Thank you, Leslie A. Walko attila@bellcore.com From cfcl!rdm@apple.com Wed Jan 8 00:51:23 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 8 Jan 92 00:51:23 MST Received: from apple.com by optima.cs.arizona.edu (4.1/15) id AA04369; Wed, 8 Jan 92 00:51:18 MST Received: by apple.com (5.61/10-Dec-1991-eef) id AA04511; Tue, 7 Jan 92 23:38:53 -0800 for Received: by cfcl.uucp (4.1/SMI-4.1) id AA17517; Tue, 7 Jan 92 22:38:00 PST Date: Tue, 7 Jan 92 22:38:00 PST From: cfcl!rdm@apple.com (Rich Morin) Message-Id: <9201080638.AA17517@cfcl.uucp> To: icon-group@cs.arizona.edu Subject: Re: windows interface ? (Or: Icon do Windows?) I tried hacking Icon together with NeWS a few years back. It wasn't too hard to do; I just allowed Icon to open I/O channels with the NeWS server. The programs then emitted commands as text PostScript strings. I never pursued it, however, so I can't say whether it would have worked out well. If I were to try it today, I think I would tie in with a high-level X11 toolkit. Tk (ftp: sprite.berkeley.edu) might be an interesting choice. It is written in C, making it easy to hack onto Icon. The relevant paper is: An X11 Toolkit based on the Tcl Language John K. Ousterhout USENIX Conference Proceedings, Winter, 1991 Here's the Abstract: This paper describes a new toolkit for X11 called Tk. The overall functions provided by Tk are similar to those of the standard toolkit Xt. However, Tk is implemented using Tcl, a lightweight interpretive command language. This means that Tk's functions are available not just from C code compiled into the application but also via Tcl commands issued dynamically while the application runs. Tcl commands are used for binding keystrokes and other events to application-specified actions, for creating and configuring widgets, and for dealing with geometry managers and the selection. The use of an interpretive language means that any aspect of the user interface may be changed dynamically while an application executes. It also means that many interesting applications can be created without writing any new C code, simply by writing Tcl scripts for existing applications. Furthermore, Tk provides a special "send" command that allows any Tk-based application to invoke Tcl commands in any other Tk-based application. Send allows applications to communicate in more powerful ways than a selection mechanism and makes it possible to replace monolithic applications with collections of reusable tools. From icon-group-request Sun Jan 12 07:27:21 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 12 Jan 92 07:27:21 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA05986; Sun, 12 Jan 92 07:27:19 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA16412; Sun, 12 Jan 92 06:12:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Dec 91 22:03:32 GMT From: uchinews!ellis!goer@speedy.wisc.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: bibleref-2.2 Message-Id: <1991Dec30.220332.4899@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu For anyone who wants it, a maintenance update of bibleref has been placed in ~ftp/icon/contrib/bibleref-2.2.tar.Z on cs.arizona.edu. Bibleref is a King James Bible text retrieval program geared for UNIX systems. It comes with a pre-indexed, compressed King James text, but other texts can be indexed as well (e.g. the CCAT RSV text with the Catholic Apocrypha, the Princeton Qur'an, and the Book of Mormon). I've not tried running the program under anything but UNIX. It can't run under DOS because of the 64k executable size-limit, but maybe it would run under VMS - ? Dunno. Anyone wanting additional information, please drop me a line. -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From LARSSON@sj03.ts.tele.nokia.fi Mon Jan 13 08:18:53 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 08:18:53 MST Received: from SJ03.TS.TELE.NOKIA.FI by optima.cs.arizona.edu (4.1/15) id AA07720; Mon, 13 Jan 92 08:18:43 MST Date: Mon, 13 Jan 1992 17:18:45 GMT+0300 From: LARSSON@sj03.ts.tele.nokia.fi (Arne Larsson tel 358-0-5117476 fax 358-0-51044287) Message-Id: <920113171845.23a0849b@sjclus.tele.nokia.fi> Subject: Icon on HP Apollo under Domain/OS? To: icon-group@cs.arizona.edu X-Vmsmail-To: INET::"icon-group@cs.arizona.edu" Have the Icon programming language been ported to the HP Apollo hardware running under Domain/OS SR 10.2 and/or higher. If so, would there be a binary downloadable using FTP from cs.arizona.edu? Best regards, Arne Larsson From isidev!nowlin@uunet.uu.net Mon Jan 13 15:57:27 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 15:57:27 MST Received: from relay1.UU.NET by optima.cs.arizona.edu (4.1/15) id AA29311; Mon, 13 Jan 92 15:57:24 MST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05558; Mon, 13 Jan 92 17:57:20 -0500 Date: Mon, 13 Jan 92 17:57:20 -0500 From: isidev!nowlin@uunet.uu.net Message-Id: <9201132257.AA05558@relay1.UU.NET> Received: from isidev.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 175706.8102; Mon, 13 Jan 1992 17:57:06 EST To: uunet!cs.arizona.edu!icon-group@uunet.uu.net Subject: large integer bug? This may be related to an earlier problem with large integers that was posted a while back but I just recently noticed a problem with large integers that work just fine for other operations but bomb with run-time error 101 when used with "to". This program illustrates: procedure main(args) local i while i := integer(get(args)) do { write(i) every write("\t",(i-4) to i) } end If this program is invoked with 1234567890 and 999999999999999: $ testint 1234567890 999999999999999 1234567890 1234567886 1234567887 1234567888 1234567889 1234567890 999999999999999 Run-time error 101 File testint.icn; Line 5 integer expected offending value: 999999999999995 Trace back: main(list_1 = []) {999999999999995 to 999999999999999 by 1} from line 5 in testint.icn it can convert both strings to integers and can subtract 4 from each but it croaks when it tries to use 999999999999995 in the every loop. Any thoughts? --- --- | S | Iconic Software, Inc. - Jerry Nowlin - uunet!isidev!nowlin --- --- From ralph Mon Jan 13 16:22:06 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 16:22:06 MST Received: from relay1.UU.NET by optima.cs.arizona.edu (4.1/15) id AA01345; Mon, 13 Jan 92 16:22:04 MST Received: from optima.cs.arizona.edu by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA13471; Mon, 13 Jan 92 18:21:49 -0500 Received: from cheltenham.cs.arizona.edu by optima.cs.arizona.edu (4.1/15) id AA01308; Mon, 13 Jan 92 16:21:48 MST Date: Mon, 13 Jan 92 16:21:46 MST From: "Ralph Griswold" Message-Id: <9201132321.AA13804@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 16:21:46 MST To: isidev!nowlin@uunet.uu.net, cs.arizona.edu!icon-group@uunet.uu.net Subject: Re: large integer bug? Large integers are not supported in i to j and seq() This is documented, although it might be easy to overlook. The reason is that supporting large integers in these situations would have a significant performance impact on the customary use. Ralph Griswold / Department of Computer Science The University of Arizona / Tucson, AZ 85721 ralph@cs.arizona.edu / uunet!arizona!ralph voice: 602-621-6609 / fax: 602-621-9618 From kwalker Mon Jan 13 16:56:54 1992 Received: from ocotillo.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Jan 92 16:56:54 MST Date: Mon, 13 Jan 92 16:56:53 MST From: "Kenneth Walker" Message-Id: <9201132356.AA01101@ocotillo.cs.arizona.edu> Received: by ocotillo.cs.arizona.edu; Mon, 13 Jan 92 16:56:53 MST To: icon-group Subject: Re: large integer bug? Part of the confusion in trying to use large integers in "to" is that in V8.0 the error message is integer expected that is fixed in future releases by changing it to integer expected or out of range Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621-4252 kwalker@cs.arizona.edu {uunet|allegra|noao}!arizona!kwalker From icon-group-request Tue Jan 14 15:36:29 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 14 Jan 92 15:36:29 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA26091; Tue, 14 Jan 92 15:36:22 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA10408; Tue, 14 Jan 92 14:32:00 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Jan 92 19:22:27 GMT From: att!cbnewsj!dsk@ucbvax.berkeley.edu (donald.s.klett) Organization: AT&T Bell Laboratories Subject: Icon Version 8 System for Mac Message-Id: <1992Jan2.192227.3854@cbnewsj.cb.att.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I have ported the Icon translator and interpreter to the Macintosh using THINK C 5.0.1 under System 7. This is not the MPW version. I used the "console" feature in THINK C. Since I am not sure how much interest there is in the Mac community, I will initially offer to e-mail the binaries to anyone interested. Just send e-mail making the request. Source code is not available from me, but may be available from the Icon project. I submitted the ported code to the project. At this stage, coexpressions are not activated, and calling C routines is not supported. Don Klett dsk@arch3.att.com (908)949-2283 From icon-group-request Tue Jan 14 17:51:39 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 14 Jan 92 17:51:39 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA01375; Tue, 14 Jan 92 17:51:33 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA17429; Tue, 14 Jan 92 16:41:19 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Jan 92 19:47:27 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!yale.edu!jvnc.net!netnews.upenn.edu!msuinfo!uchinews!ellis!goer@ucbvax.berkeley.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: bibleref, more info Message-Id: <1992Jan2.194727.10677@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I have been asked to offer more information about Bibleref. It's not a very complicated program, but I've certainly found it useful. A tri- lingual version (English-Hebrew-Aramaic) is actually the driving data collection tool for my dissertation. (Don't ask me for the trilingual version, though; I can't possible maintain it at other sites.) I've appended part of the README file for Bibleref below. I hope this satis- fies the requests for additional information I've received. If not, please drop me a line. -------- Program: Bibleref (version 2.2) Language: Icon Purpose: Perform word and passage-based retrievals on the King James or CCAT Revised Standard versions of the Bible (check with me if you have a Greek New Testament online) Files: bibleref.src convertb.icn convertr.icn listutil.icn name2num.icn passutil.icn readfile.icn ref2bmap.icn srchutil.icn Requires: Icon version 8, a working, up-to-date Icon Program Library (see below on IPATH), and a King James or RSV Bible text (the latest from helens.stanford.edu; write me if yours is different) -------- Overview: This package, Bibleref, offers simple tools for word and passage-based access to the King James or Revised Standard Version of the Bible on UNIX platforms. Bibleref is quick, and fairly easy to install (assuming you possess a suitable King James Bible text, a sufficiently powerful machine, and know a little about Icon). It will also run with stock terminals - even nasty old ones that leave magic cookies on your screen. Bibleref will, however, put a significant dent in your mass storage resources. Your 4-5 megabyte King James or RSV text will get block Huffman encoded, which will bring it down to about three. The freed space, however, will be gobbled up immediately by some 2 megabytes of auxiliary files, and by the 150k executable (more if you compile, rather than interpret). In-core requirements for the executable start at about 300k, and go up from there (if your searches are complex enough, you could easily eat up two or three megabytes). In brief: Bibleref has a large appetite for memory. Once set up, though, it can operate with fairly minimal impact on the CPU. With Bibleref, you can perform most of the more basic, low-level functions commercial Bible browsing packages offer (and perhaps a few not found in some of the commercial packages). You can, for example, - retrieve any passage in the Bible instantaneously - move forward or backward relative to the retrieved passage - search the entire Bible for words and/or word-patterns - search for word co-occurrences (or the absence thereof) - save passages and/or passage-lists for use with an editor Although this program is hardly the product of any major research effort :-), it should prove sophisticated enough for quick lookup of passages whose precise location you have forgotten, for research on sermons and Bible study classes, and for general topical perusal of the biblical text. -------- Installation: The following set-up and installation instructions generally assume that you received Bibleref as a shell archive, with no prebuilt data files. If you snarfed it from an ftp site, with the data files already built, you can skip all the instructions about obtaining and indexing a King James Bible text. If there's any doubt over whether your data files are prebuilt, check to see if the file "index.done" exists in your Bibleref source directory. If it does, then your data files have already been built. Otherwise, you'll need to do a "from scratch" installation. In brief, the setup process consists of the following steps (those with prebuilt data files only need to do the starred ones): * make sure Icon is installed & your IPATH variable is set - get a hold of a KJV or RSV text - unpack the text & link the files to the current directory * modify the makefile to suit your machine * make Although I will discuss it below briefly, installation of the Icon programming language falls outside the scope of this manual. I will therefore begin setup instructions with directions on how to get a biblical text, and how to set it up for indexing. And so on... (blah, blah, blah) -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From icon-group-request Wed Jan 15 08:34:28 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 15 Jan 92 08:34:28 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA08139; Tue, 14 Jan 92 22:20:36 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA02147; Tue, 14 Jan 92 21:07:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Jan 92 22:40:15 GMT From: mcsun!sun4nl!wn1.sci.kun.nl!news@uunet.uu.net (NUnet News Owner) Organization: University of Nijmegen Subject: test Message-Id: <1992Jan2.224015.13121@sci.kun.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu this is the first line. This is he second line. This is the third line. Sorry folks, this test is very important for me. From cliff Fri Jan 17 11:32:46 1992 Received: from javelina.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Jan 92 11:32:46 MST Date: Fri, 17 Jan 92 11:32:42 MST From: "Cliff Hathaway" Message-Id: <9201171832.AA03711@javelina.cs.arizona.edu> Received: by javelina.cs.arizona.edu; Fri, 17 Jan 92 11:32:42 MST To: icon-group Subject: resending message The disk that the icon-group mailinglist address file resides on went down yesterday - here's a message that apparently didn't make it out. Cliff Hathaway Dept. of Computer Science (602)621-4291 University of Arizona cliff@cs.arizona.edu (internet) Tucson, Ariz. 85721 {cmcl2,noao,uunet}!arizona!cliff (uucp) ============= forwarded message starts here ================================ Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA01541; Thu, 16 Jan 92 19:59:08 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA28720; Thu, 16 Jan 92 18:56:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Jan 92 23:58:06 GMT From: pa.dec.com!nntpd.lkg.dec.com!tle.enet.dec.com!ellenberger@decwrl.dec.com (John Ellenberger) Organization: Digital Equipment Corporation Subject: New Version of Catspaw Snobol Available Message-Id: <32582@nntpd.lkg.dec.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu This month's BYTE article on Snobol mentions a free implmentation of the language available on the network. Unfortunately the version available in most archives (uu, wuarchive, simtel) is out of date and will not work on some PCs (486s in particular). Catspaw Inc. has provided an up to date version and I have downloaded it to GATEKEEPER for general use. Fell free to propigate it to the other archives if you wish. It can be ftp'd from: gatekeeper:/pub/micro/msdos/Snobol/vanilla.zip Any questions/concerns/orders should be directed to: Catspaw, Inc. P.O. Box 1123 Salida, Colorado 81201 719-539-3884 FAX 539-4830 AppleLink D6941 CompuServe 76176,1304 Internet emmer@cs.arizona.edu From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk Fri Jan 17 12:41:31 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Jan 92 12:41:31 MST Received: from sun2.nsfnet-relay.ac.uk by optima.cs.arizona.edu (4.1/15) id AA26478; Fri, 17 Jan 92 12:41:07 MST Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <14322-5@sun2.nsfnet-relay.ac.uk>; Fri, 17 Jan 1992 13:24:47 +0000 Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa21167; 17 Jan 92 12:15 WET Date: 17 Jan 92 12:16:32 gmt From: R.J.Hare@edinburgh.ac.uk Subject: Test To: icon-group@cs.arizona.edu Message-Id: <17 Jan 92 12:16:32 gmt 320862@EMAS-A> Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk> This also is a test - problems with mail at this end - please ignore. RH From icon-group-request Fri Jan 17 21:48:19 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Jan 92 21:48:19 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA19476; Fri, 17 Jan 92 21:48:11 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA18359; Fri, 17 Jan 92 20:45:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Jan 92 11:56:39 GMT From: csus.edu!wupost!zaphod.mps.ohio-state.edu!caen!garbo.ucc.umass.edu!risky.ecs.umass.edu!umaecs!amh!kehandley@ucdavis.ucdavis.edu Organization: Amherst College, Amherst, MA. Subject: MS-DOS Icon limitations? Message-Id: <17517.29699577@amherst.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Hello all. Richard Goerwitz recently posted the following to HUMANIST: >[MS-DOS's] memory limitations and inability to multitask make it a >bit difficult for many of us to stomach (although its small size and >relative simplicity make it fine for applications). Icon is a very >high level, OS-independent language, and its implementation was geared >for machines with medium or large address spaces and high-level memory >management facilities (i.e. UNIX, VMS, etc.). There is a DOS version >available from cs.arizona.edu (which you can obtain via anonymous ftp), >and it's very popular. I found it klunky, though, and the inherent >limitations of DOS memory management facilities forced me quickly to >move "up." My Icon programs aren't nearly as long as Goerwitz's programs that I've seen, so I was curious about just what kind of limitation DOS might really have for me. I do my Icon work in VMS. I decided to see whether the program I am currently writing would work on MS-DOS. Here are the VMS and MS-DOS compiles, respectively: $ icont create C:\> icont create Translating: Translating: create.icn: create.icn: main (99/15000) main (3037/15000) pow (5/15000) pow (179/15000) get1or2 (8/15000) get1or2 (286/15000) makeprintout (11/15000) makeprintout (388/15000) printit (111/15000) printit (3565/15000) randomseed (8/15000) randomseed (267/15000) No errors No errors Linking: Linking: $ C:\> I remember (perhaps incorrectly) that the (99/15000), etc. has to do with memory, but I don't remember where I read it. Anyway, I wonder if anyone out there can tell me where to find out. It appears as though some of my procedures are making a dent in MS-DOS Icon, whereas to VMS Icon, they are pretty dinky. So what's the point of my post? First, the question above, and second, some folks may not know the difference between the compiles across platforms, so maybe it is a little interesting. I am not trying to knock MS-DOS. Keith Handley kehandley@amherst From icon-group-request Sat Jan 18 12:05:29 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 18 Jan 92 12:05:29 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA11462; Sat, 18 Jan 92 12:05:25 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA17097; Sat, 18 Jan 92 11:00:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Jan 92 03:42:29 GMT From: dorm.rutgers.edu!pilot.njin.net!hedges@princeton.edu (Douglas Hedges) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: New Version of Catspaw Snobol Available Message-Id: References: <32582@nntpd.lkg.dec.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu ellenberger@tle.enet.dec.com (John Ellenberger) writes: >This month's BYTE article on Snobol mentions a free implmentation >of the language available on the network. Unfortunately the version >available in most archives (uu, wuarchive, simtel) is out of date >and will not work on some PCs (486s in particular). >Catspaw Inc. has provided an up to date version and I have downloaded >it to GATEKEEPER for general use. Fell free to propigate it to the >other archives if you wish. It can be ftp'd from: > gatekeeper:/pub/micro/msdos/Snobol/vanilla.zip >Any questions/concerns/orders should be directed to: > Catspaw, Inc. > P.O. Box 1123 > Salida, Colorado 81201 > 719-539-3884 > FAX 539-4830 > AppleLink D6941 > CompuServe 76176,1304 > Internet emmer@cs.arizona.edu Let me add that Catspaw also has an excellent version of Spitbol available for the Mac, MaxSPITBOL. Mark Emmer has continued to refine it and has been generous in his update policy. Note that MaxSPITBOL is, unlike the 'vanilla' version of Snobol he makes available for DOS machines, a commercial product and well worth the money at that. NOTE: I've no connection with Catspaw other than as a satisfied customer. It's nice to be able to call and speak with Mark himself in re questions or problems. From icon-group-request Sun Jan 19 10:52:06 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Jan 92 10:52:06 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA13840; Sun, 19 Jan 92 10:52:04 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA26974; Sun, 19 Jan 92 09:45:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Jan 92 11:21:41 GMT From: dog.ee.lbl.gov!network.ucsd.edu!swrinde!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!gmdzi!icking@ucbvax.berkeley.edu (Werner Icking) Organization: GMD, St. Augustin, F.R. Germany Subject: Re: New Version of Catspaw Snobol Available Message-Id: <6744@gmdzi.gmd.de> References: <32582@nntpd.lkg.dec.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu ellenberger@tle.enet.dec.com (John Ellenberger) writes: >[...] >Catspaw Inc. has provided an up to date version and I have downloaded >it to GATEKEEPER for general use. [...] You mean: gatekeeper.dec.com? I could ftp it from there :-) Thanks > gatekeeper:/pub/micro/msdos/Snobol/vanilla.zip -- Werner Icking icking@gmdzi.gmd.de (+49 2241) 14-2443 GMD - Gesellschaft fuer Mathematik und Datenverarbeitung mbH Schloss Birlinghoven, P.O.Box 1316, D-5205 Sankt Augustin 1, Germany "Der Dativ ist dem Genitiv sein Tod." From KKTK_KK@cc.helsinki.fi Mon Jan 20 11:58:19 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 20 Jan 92 11:58:19 MST Received: from cc.Helsinki.FI (hylka.Helsinki.FI) by optima.cs.arizona.edu (4.1/15) id AA25506; Mon, 20 Jan 92 11:58:15 MST Date: Mon, 20 Jan 1992 20:58 EET From: "Kimmo Kettunen; HYLK" Subject: Subscription To: icon-group@cs.arizona.edu Message-Id: Hi, could you put me on the subscription list of Icon newsgroup. My e-mail address is KKTK_KK@CC.HELSINKI.FI. Yours, Kimmo Kettunen Helsinki From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk Mon Jan 20 22:48:15 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 20 Jan 92 22:48:15 MST Received: from by optima.cs.arizona.edu (4.1/15) id AB17386; Mon, 20 Jan 92 22:48:08 MST Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <8208-4@sun2.nsfnet-relay.ac.uk>; Mon, 20 Jan 1992 12:18:49 +0000 Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa22781; 20 Jan 92 12:02 WET Date: 20 Jan 92 12:03:54 gmt From: R.J.Hare@edinburgh.ac.uk Subject: Mac Icon To: icon-group@cs.arizona.edu Message-Id: <20 Jan 92 12:03:54 gmt 320141@EMAS-A> Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk> I am having great trouble contacting Donald Klett (poster of the THINK C Mac Icon) by email - could he please post his email address somwhere in clear please (I can't see what is going wrong - I mail to the States every day and don't normally have problems). Thanks. Roger Hare. From kwalker Tue Jan 21 08:51:22 1992 Received: from ocotillo.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 21 Jan 92 08:51:22 MST Date: Tue, 21 Jan 92 08:51:20 MST From: "Kenneth Walker" Message-Id: <9201211551.AA04139@ocotillo.cs.arizona.edu> Received: by ocotillo.cs.arizona.edu; Tue, 21 Jan 92 08:51:20 MST To: icon-group Subject: Re: MS-DOS Icon limitations? > Keith Handley (kehandley@amherst) writes: > ... > Here are the VMS and MS-DOS compiles, respectively: > > $ icont create C:\> icont create > Translating: Translating: > create.icn: create.icn: > main (99/15000) main (3037/15000) > ... > I remember (perhaps incorrectly) that the (99/15000), etc. has to do with > memory, but I don't remember where I read it. The first number indicates the amount of memory used during translation to represent the procedure. The second number is the amount of memory reserved for this; it can be changed with the -St option of icont. icont is implemented in C and the first number may vary somewhat between systems depending how the C compiler represents structures. However, I would say that, in your case, at least one set of numbers is bogus. The code to print the numbers in our working version of Icon looks okay to me, but I haven't checked it out on different platforms to see if it really is. I vaguely recall that a problem in that code was fixed a while ago. In any event, these numbers don't tell you anything about the run-time memory usage of your program. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621-4252 kwalker@cs.arizona.edu {uunet|allegra|noao}!arizona!kwalker From @um.cc.umich.edu:Paul_Abrahams@MTS.cc.Wayne.edu Thu Jan 23 19:01:44 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Jan 92 19:01:44 MST Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15) id AA15122; Thu, 23 Jan 92 19:01:37 MST Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA08470; Thu, 23 Jan 92 20:57:24 -0500 Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Thu, 23 Jan 92 19:12:54 EST Date: Thu, 23 Jan 92 19:12:38 EST From: Paul_Abrahams@mts.cc.wayne.edu To: icon-group@cs.arizona.edu Message-Id: <407392@MTS.cc.Wayne.edu> Subject: Pipes in MS-DOS Icon The latest issue of the Icon Analyst discusses several handy uses of pipes. It also points out that pipes are not available under the MS-DOS version of Icon and states: "Note that the MS-DOS idea of pipes---writing the output of a program to a temporary file and then reading that file in another program---is bogus." In fact, the MS-DOS idea of pipes is only slightly less powerful than the Unix version, and including pipes in MS-DOS Icon poses no problem in principle. (Not knowing the code, I can't speak to the problems that it might pose in practice.) Nearly all useful cases would be covered by a straightforward implementation of pipes in MS-DOS; in particular, such an implementation would easily handle all the examples in the Analyst article. The straightforward and obvious implementation goes like this: (1) When opening a pipe for input, execute the command in a subshell, save the output in a temporary file, and read that temporary file as though you were reading the pipe. (2) When opening a pipe for output, save all data written to the pipe in a temporary file; when the pipe is closed either explicitly or implicitly (at program termination), execute the piped command with that file as its standard input. To understand why the DOS use of temporary files isn't really so far from the Unix treatment of pipes, it helps to look at what the Unix treatment of pipes really is. Unix treats pipes at two levels: shell commands and system functions. The shell commands, which are what most users see, behave very much like the DOS ones; typing prog1 | prog2 produces the same effect in either system. The underlying mechanism is that the shell sets up a pipe between prog1 and prog2 by calling the "pipe" function to obtain a pair of file descriptors, one for output and one for input. The shell associates the output descriptor with the output of prog1 and the input descriptor with the input of prog2. The shell then calls the system function "fork" twice to establish prog1 and prog2 as its child processes. The pipe itself uses an internal 4096-byte memory buffer (in classic Unix, at least); if no context switching takes place and the output of prog1 is less than 4096 bytes long, the sequence of events is: (1) prog1 writes its output to the memory buffer. (If prog2 tries to start before prog1, it is suspended on its first read from standard input.) (2) prog1 fills the memory buffer and terminates. (3) prog2 executes, reading the memory buffer, and terminates. In fact, the sequence is almost exactly equivalent to what happens under DOS using a RAM disk to hold the temporary file. Although other variations are possible under Unix in principle, they don't matter much in practice. For instance, context switching might take place so that execution of prog1 and prog2 is interleaved. However, if the result depends on the presence of such interleaving, prog1 and prog2 are probably not very robust. If the size of the output exceeds the capacity of the memory buffer associated with the pipe, interleaving will be unavoidable, but still should not affect the result. Unix does, of course, also offer the opportunity for a C programmer to construct pipes within a program (as the various shells do). Such programmed pipes offer possibilities not available at the command-line level or through MS-DOS (although some of them can be achieved in MS-DOS through explicit subshelling). For instance, you can connect two processes through two independent pipes. (I don't know how often people really do this.) However, if the pipes don't all flow in the same direction, then the possibility of deadlock is immediately introduced. And if they do flow in the same direction, the straightforward MS-DOS implementation described above still works; it is only necessary to execute the upstream program before the downstream program. I don't believe the rare case that is expressible in Unix but not in MS-DOS (processes that share pairs of pipes pointing in opposite directions) arises very often. Virtually all of the examples I have seen of pipes used for program input and output involve system programs such as "ls" (for Unix) or "dir" (for MS-DOS). And even if this case is excluded, the functionality of piped commands would be very useful for MS-DOS Icon. Another way of looking at it is that Unix provides more possible orders of computation than MS-DOS; the temporary file model greatly constrains the order of computation. However, programs that are sensitive to the order of computation are unlikely to be well-behaved or useful. Therefore the MS-DOS order must be semantically equivalent to any of the Unix orders. Any counterexamples? Paul Abrahams Abrahams@mts.cc.wayne.edu From ralph Thu Jan 23 19:20:31 1992 Date: Thu, 23 Jan 92 19:20:31 MST From: "Ralph Griswold" Message-Id: <9201240220.AA00618@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Thu, 23 Jan 92 19:20:31 MST To: Paul_Abrahams@mts.cc.wayne.edu, icon-group@cs.arizona.edu Subject: Re: Pipes in MS-DOS Icon I stand by my statement. If the output of one process is very large (or not bounded), the use of a temporary file as in MS-DOS ranges from downright painful to unworkable. I'll let my side of the conversation drop there -- this is the kind of thing that results in endless "flames" that do little to illuminate and only clutter the network. Ralph Griswold / Department of Computer Science The University of Arizona / Tucson, AZ 85721 ralph@cs.arizona.edu / uunet!arizona!ralph voice: 602-621-6609 / fax: 602-621-9618 From nevin@apple.com Fri Jan 24 02:05:11 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Jan 92 02:05:11 MST Received: from apple.com by optima.cs.arizona.edu (4.1/15) id AA08658; Fri, 24 Jan 92 02:05:08 MST Received: from [90.134.16.31] by apple.com with SMTP (5.61/10-Dec-1991-eef) id AA25306; Fri, 24 Jan 92 01:04:57 -0800 for icon-group@cs.arizona.edu Message-Id: <9201240904.AA25306@apple.com> Date: Fri, 24 Jan 1992 01:06:13 -0800 To: icon-group@cs.arizona.edu From: nevin@apple.com (Nevin :-] Liber) Subject: Re: Pipes in MS-DOS Icon Cc: Paul_Abrahams@mts.cc.wayne.edu [This is pretty much off the subject of Icon. Followup by mail and/or to another newsgroup if you feel that you must.] Ralph Griswold (ralph@cs.arizona.edu) writes: >... If the output of one process is very large (or >not bounded), the use of a temporary file as in MS-DOS ranges from >downright painful to unworkable. Let me second this sentiment. As someone who once had to make the transition from Unix to MS-DOS, I was made painfully aware of how limiting MS-DOS pseudo-pipes (or MPW pipes on the Macintosh, for that matter) really are. One of the most common idioms I use under Unix is something like: command1 | command2 | ... | commandN | more where the output of each of the commands is typically much larger than 4K (a typical size for a Unix pipe), and I using "more" to do some interactive filtering of the data. If I had to wait until command1 finished running, then command2 starting, then command2 ending, then command3 starting, etc. (MS-DOS pipes are equivalent to sequential execution of the commands) before I could even begin to look at my output, it would at a minimum slow me down and take a lot of temporary space. As a human, I tend to implicitly exploit the property that I am pushing through much more data than the size of the pipe, and I suspect that most other Unix users do too. Many uses of pipes involve looking for a specific piece of information and ignoring the rest of the input. Even if you have a lot of temp space (and believe me; it is very frustrating when you run out), this is vastly inefficient on an MS-DOS machine. And if one of the processes happens to produce an unbounded amount of output (such as a random sentence generator or getting live data from a port and then piping the output to some kind of a filter), all bets are off. Back when I was using MS-DOS (it should be obvious from my .signature why I don't anymore :-)), I was running most of my stuff using the MKS Toolkit (an excellent commercial port of most of the Unix utilities). Even with this environment, the scripts I used under Unix were much different than the ones I used under MS-DOS, precisely because of the way pipes didn't work on my MS-DOS machine. The sequential execution/temporary file model of pipes, although still quite useful, does not even come close to the power of a Unix pipe. From @um.cc.umich.edu:Paul_Abrahams@MTS.cc.Wayne.edu Fri Jan 24 20:08:41 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Jan 92 20:08:41 MST Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15) id AA19622; Fri, 24 Jan 92 20:08:34 MST Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA17741; Fri, 24 Jan 92 22:04:37 -0500 Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Fri, 24 Jan 92 21:17:59 EST Date: Fri, 24 Jan 92 21:18:04 EST From: Paul_Abrahams@mts.cc.wayne.edu To: icon-group@cs.arizona.edu Message-Id: <407920@MTS.cc.Wayne.edu> Subject: Pipes in MS-DOS Icon (continued) I readily concede the point that when intermediate results are very large and the ultimate output is being processed interactively, the MS-DOS imitation of pipes doesn't work very well (or not at all, if the output is unbounded). Nonetheless I still argue that there are many useful applications of the MS-DOS model, including practically all of the published examples of Icon pipes. The disk usage implied under MS-DOS is not much of a penalty if the disk is a RAM disk---which is easily provided for on machines having the hardware capability of typical Unix machines. Moreover, if the temporary files fit on the RAM disk and the final output is not being processed interactively, the MS-DOS timings (for comparable hardware) should be similar to the Unix ones. In fact, some MS-DOS programs run faster than their Unix equivalents on the same hardware; for example, Eberhard Mattes's version of TeX, EmTeX, runs about 40% faster than Unix TeX on my computer. I also point out that "sort" is one of the most commonly used filters in a Unix pipeline, and if the amount of data being passed through "sort" exceeds the memory capacity, even Unix needs to use an intermediate file implicitly. The same holds for any other filter that cannot operate in a single pass. Paul Abrahams Abrahams@mts.cc.wayne.edu From icon-group-request Fri Jan 24 20:27:34 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Jan 92 20:27:34 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA20187; Fri, 24 Jan 92 20:27:32 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA17612; Fri, 24 Jan 92 19:12:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Jan 92 21:19:06 GMT From: uchinews!ellis!goer@handies.ucar.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: icon & parsing Message-Id: <1992Jan18.211906.23703@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu If one were outputting a LALR(k) parser of some sort in Icon, I wonder how states might best be represented. Normally, one can created labeled nodes in the source code to which one sim- ply jumps via a goto. In Icon this isn't possible. What would be better? To create a coexpression that reads a state table, outputting states as needed, and then check these states against a (possibly huge) case statement? Sorry if these questions sound naive. I'd appreciate any ad- vice I can get. -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From wgg@cs.ucsd.edu Fri Jan 24 23:14:45 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Jan 92 23:14:45 MST Received: from ucsd.edu by optima.cs.arizona.edu (4.1/15) id AA25014; Fri, 24 Jan 92 23:14:41 MST Received: from odin.ucsd.edu by ucsd.edu; id AA00993 sendmail 5.64/UCSD-2.2-sun via SMTP Fri, 24 Jan 92 22:14:33 -0800 for icon-group@cs.arizona.edu Received: by odin.ucsd.edu (4.1/UCSDPSEUDO.4) id AA10946 for uchinews!ellis!goer@handies.ucar.edu; Fri, 24 Jan 92 22:14:32 PST Date: Fri, 24 Jan 92 22:14:32 PST From: wgg@cs.ucsd.edu (William Griswold) Message-Id: <9201250614.AA10946@odin.ucsd.edu> To: icon-group@cs.arizona.edu, uchinews!ellis!goer@handies.ucar.edu Subject: Re: icon & parsing Yes, simulating gotos with a case statement is quite reasonable. I don't know that a coexpression would be necessary to generate the states. You can think of the state transitions as instructions to be executed by an interpreter. Then you can think of case statement as the basic interpreter-loop for the instructions. But I'll bet someone out there can out-do this solution. bill From icon-group-request Sat Jan 25 00:58:33 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Jan 92 00:58:33 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA27646; Sat, 25 Jan 92 00:58:30 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA29028; Fri, 24 Jan 92 23:54:47 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Jan 92 12:51:41 GMT From: mcsun!uknet!bcc.ac.uk!ucgadkw@uunet.uu.net (Dominik Wujastyk) Organization: Bloomsbury Computing Consortium, London Subject: Re: New Version of Catspaw Snobol Available Message-Id: <1992Jan17.125141.93070@link-1.ts.bcc.ac.uk> References: <32582@nntpd.lkg.dec.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu What is the ftp address of "Gatekeeper"? Thanks, Dominik From @um.cc.umich.edu:Paul_Abrahams@MTS.cc.Wayne.edu Sat Jan 25 10:16:24 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Jan 92 10:16:24 MST Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15) id AA13933; Sat, 25 Jan 92 10:16:21 MST Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA21466; Sat, 25 Jan 92 12:12:26 -0500 Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Sat, 25 Jan 92 12:13:20 EST Date: Sat, 25 Jan 92 12:13:24 EST From: Paul_Abrahams@mts.cc.wayne.edu To: icon-group@cs.arizona.edu Message-Id: <408009@MTS.cc.Wayne.edu> Subject: Pipes for MS-DOS Icon revisited The question of whether or not MD-DOS pipes are bogus has, I think, obscured my main point relative to Icon: that providing pipes in MS-DOS Icon would be a very useful enhancement. Even if the MS-DOS version lacks the full power of the Unix version, the power it provides would be very convenient. Moreover, the visible semantics under the two systems are the same (modulo the fact that the DOS utilities have different names from their Unix counterparts). The weaknesses of the DOS version show up not in different results but in programs that run more slowly (including the extreme point of nontermination). Paul Abrahams Abrahams@mts.cc.wayne.edu From nevin@apple.com Sun Jan 26 01:37:21 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 26 Jan 92 01:37:21 MST Received: from apple.com by optima.cs.arizona.edu (4.1/15) id AA26138; Sun, 26 Jan 92 01:37:16 MST Received: from [90.134.16.31] by apple.com with SMTP (5.61/10-Dec-1991-eef) id AA12732; Sun, 26 Jan 92 00:37:01 -0800 for icon-group@cs.arizona.edu Message-Id: <9201260837.AA12732@apple.com> Date: Sun, 26 Jan 1992 00:38:22 -0800 To: icon-group@cs.arizona.edu From: nevin@apple.com (Nevin :-] Liber) Subject: Re: Pipes for MS-DOS Icon revisited Cc: Paul_Abrahams@mts.cc.wayne.edu >The question of whether or not MD-DOS pipes are bogus has, I think, >obscured my main point relative to Icon: that providing pipes in MS-DOS >Icon would be a very useful enhancement. The interface between Icon and the underlying operating system a given implementation is run on is minimal (and should be, IMHO. This is one of the reasons why the Icon implementation itself is highly portable). It does, however, provide extra support for OS features (system(), pipes in Unix, etc.) when the cost for the service is negligible. To provide pipes under Unix, all that has to happen on the C implementation side is to call popen() instead of fopen() to open the file. No other bookkeeping is required. [As a side note: when I write Unix utilities with multiple input and/or output streams, I tend to add options to allow users to pipe to and from the utility via the command line precisely because it is so easy to implement.] Now, should features be added to Icon to make up for operating system deficiencies? IMHO, this is not something that Icon is well-suited for. This problem falls outside of what a programming language for processing symbolic data should be fixing; it goes against the "spirit" of Icon (again, IMHO). >Moreover, the visible semantics under the two >systems are the same (modulo the fact that the DOS utilities have >different names from their Unix counterparts). Not true. Adding the ability to save the output of a command into a temporary file and then reading that file back in (equivalent to reading from MS-DOS pipes) or the ability to write to a temporary file and then execute a command using that file as input (writing to MS-DOS pipes) does not provide any new functionality to Icon, while true Unix-type pipes do. Now, if you still really think that this enhancement justifies the cost, then why don't you implement it yourself? And you can do it all without writing a single line of C code! And it would be almost transparent (all you really need are five Icon procedures and a global variable) to the rest of your program, too (ie, you can make it so the code takes advantage of real pipes when it is running under Unix)! How to go about implementing MS-DOS pipes for Icon in Icon: Under Icon, you can replace any of the built-in function calls with your own procedures. All you would need to replace are open, close, exit, and stop (exit and stop are replaced because they may need to close and remove the temporary files if there are still open pipes). You would need an initialization routine to do this; let's call it PIPEInitialize(). The code for PIPEInitialize() would go something like this (note: this code is 100% untested): global PIPETGlobals procedure main(LArguments) initial { #in case main() is called recursively PIPEInitialize() ... #your code } ... end procedure PIPEInitialize() initial { #put it in the initial clause in case someone tries to call #it a second time if ("pipes" ~== &features) then { #only bother if real pipes #are not available PIPETGlobals := table() #need to still call PIPETGlobals["open"] := open # the built-ins PIPETGlobals["close"] := close PIPETGlobals["exit"] := exit PIPETGlobals["stop"] := stop open := PIPEOpen close := PIPEClose exit := PIPEExit stop := PIPEStop } } end Since the semantics of reading from/writing to a sequentially executed pipe are very well defined, it should be fairly straightforward to write the procedures PIPEOpen(sFilename, sOptions), PIPEClose(fFile), PIPEExit(iExitStatus), and PIPEStop(xStrings[]). For instance: the code for PIPEOpen should go something like this: 1. Trap run-time errors 2. Call "open" (fFile := PIPETGlobals["open"](sFilename, sOptions)) 3. If no errors occurred, restore &error and return \fFile 4. If the error was not invalid option or "p" is not in sOptions, then restore &error, do runerr() and fail 5. Make up a unique file name. 6. Call system(sFilename || " > " || sTemporaryFilename) 7. Open the temp file fFile := PIPETGlobals["open"](sTemporaryFilename) 8. Keep track of the file so PIPEClose can remove it when done PIPETGlobals[fFile] := sTemporaryFilename 9. restore &error and return fFile And PIPEClose() (again, ignoring the case of writing to a pipe) would do something like this: procedure PIPEClose(fFile) PIPETGlobals["close"](fFile) remove(\PIPETGlobals[fFile]) delete(PIPETGlobals, fFile) return fFile end Anyway, you get the idea. Starting with this model and a few hours work, you can have your sequentially executed pipes without having to bog down the implementation with yet another "creeping featurism". Plus, it can be 100% portable, too! ___ NEVIN ":-)" LIBER, Speech Recognition Guy email: nevin@apple.com paper: Apple Computer, Inc. voice: (408) 974-MIX1 20525 Mariani Avenue, MS: 76-7E AppleLink: NEVIN.LIBER Cupertino, California 95014 From @um.cc.umich.edu:Paul_Abrahams@MTS.cc.Wayne.edu Sun Jan 26 13:00:20 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 26 Jan 92 13:00:20 MST Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15) id AA15095; Sun, 26 Jan 92 13:00:14 MST Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA27886; Sun, 26 Jan 92 14:56:15 -0500 Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Sun, 26 Jan 92 14:54:51 EST Date: Sun, 26 Jan 92 13:33:04 EST From: Paul_Abrahams@mts.cc.wayne.edu To: icon-group@cs.arizona.edu Message-Id: <408264@MTS.cc.Wayne.edu> Subject: Pipes in MS-DOS Icon (ctd.) What strikes me about the debate over pipes in MS-DOS Icon is that just about all of the objections to my suggestion have come from Unix users who, judging from their comments, consider MS-DOS to be beneath contempt and never use MS-DOS Icon. (As for me, I use Icon under both MS-DOS and Unix.) It would be interesting to get some comments from whoever is responsible for the current MS-DOS implementation as well as from people who are using MS-DOS Icon. My impression is that there are many of them out there (any data, Ralph?) I just don't see why enhancements to MS-DOS Icon should be so irksome to the Unix folk. After all, what difference does it make to you? It's a big world, guys and gals! However, I can't resist one dig: anybody out there who has paid for Unix software or hardware with an unreimbursed personal check (OK, Visa and Mastercard count too)? Paul Abrahams Abrahams@mts.cc.wayne.edu From cfcl!rdm@apple.com Sun Jan 26 15:28:01 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 26 Jan 92 15:28:01 MST Received: from apple.com by optima.cs.arizona.edu (4.1/15) id AA18810; Sun, 26 Jan 92 15:27:57 MST Received: by apple.com (5.61/10-Dec-1991-eef) id AA18262; Sun, 26 Jan 92 14:12:26 -0800 for Received: by cfcl.uucp (4.1/SMI-4.1) id AA05456; Sun, 26 Jan 92 13:55:18 PST Date: Sun, 26 Jan 92 13:55:18 PST From: cfcl!rdm@apple.com (Rich Morin) Message-Id: <9201262155.AA05456@cfcl.uucp> To: icon-group@cs.arizona.edu, rdm@apple.com Subject: UNIX software prices > However, I can't resist one dig: anybody out there who has paid > for Unix software or hardware with an unreimbursed personal check > (OK, Visa and Mastercard count too)? I have bought in excess of $50K worth of "UNIX Hardware" (primarily Sun-related equipment) over the years. By and large, I consider it to be money well-spent. I spend vanishingly small amounts of money on software, however. Reasons: 1) As a trade writer, I tend to get free copies of almost any software I want. This isn't much, however, as I really don't use much commercial software. Instead, I use: 2) Bundled UNIX tools. The UNIX system comes with zillions of useful tools. I can usually make some combination of them do the trick. Interesting combinations get saved as shell scripts, and may be distributed as: 3) Freeware. I am a very minimal producer of freeware, but I use a number of freeware packages on a regular basis. The fact that source code distribution is the norm for UNIX freeware allows me to build upon others' work, fix bugs, etc. Aside from the usual ftp and UUCP techniques, I can acquire this code in the form of inxpensive CDROM collections. Which gives me an entree into a commercial pitch (tune out if desired, flames to /dev/null): Prime Time Freeware, Volume 1, Number 1 (January, 1992) The first issue of Prime Time Freeware (PTF) is now available. It contains over 1500 MB of UNIX-related source code, stored as compressed tar(1) files on an ISO-9660 CDROM. A 50+ page booklet introduces and explains the disc. The issue contains recent versions of over 100 packages, including: Andrew (windowing code) Athena (except Kerberos) CLU comp.sources.{amiga,3b1,games,x,sun,unix} Epoch GNU (current and vintage versions) Icon InterViews ISODE Kermit (tapes A-E) Mach NCSA Data Analysis Code Scheme Serpent T Utah Rendering Toolkit X11R5 The disc and booklet are available from: Prime Time Freeware 415-112 N. Mary Ave., Suite 50 Sunnyvale, CA 94086 USA (408) 738-4832 cfcl!ptf@apple.com The list price is $60 US, payable by check or money order. A 30% discount applies to orders of 10-100 units. Include $5 per order for shipping and handling. Add %7 to help with sales tax, if ordering within California. From ercn72@festival.ed.ac.uk Mon Jan 27 05:14:17 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Jan 92 05:14:17 MST Received: from Arizona.edu (Osprey.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15) id AA15072; Mon, 27 Jan 92 05:14:06 MST Received: from UKACRL.BITNET (MAILER@UKACRL) by Arizona.edu with PMDF#10282; Mon, 27 Jan 1992 05:13 MST Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 0390; Mon, 27 Jan 92 10:18:33 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 1263; Mon, 27 Jan 92 10:18:04 GMT Date: Mon, 27 Jan 92 10:04:33 GMT From: "R.J.Hare" Subject: Compiler on Sun To: icon-group Message-Id: <9201271004.aa28931@uk.ac.ed.festival> X-Envelope-To: icon-group@cs.arizona.edu Via: UK.AC.ED.FESTIVAL; 27 JAN 92 10:04:24 GMT I am getting: write failed, file system full messages when I try and compile large(ish) Icon programs on a Sun. Our system staff tell me that this is probably because Icon is grabbing all the available space on the /tmp directory. Is there any switch or environment variable I ould use or set to force Icon to use a different area for its temporary files (for local reasons, they are unwilling to increase the size of the /tmp disrectory). Thanks. Roger Hare. From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk Mon Jan 27 09:14:09 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Jan 92 09:14:09 MST Received: from by optima.cs.arizona.edu (4.1/15) id AB22341; Mon, 27 Jan 92 09:14:02 MST Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <15975-0@sun2.nsfnet-relay.ac.uk>; Mon, 27 Jan 1992 15:32:05 +0000 Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa18388; 27 Jan 92 15:36 WET Date: 27 Jan 92 15:37:40 gmt From: R.J.Hare@edinburgh.ac.uk Subject: Compiler on Sun. To: icon-group@cs.arizona.edu Message-Id: <27 Jan 92 15:37:40 gmt 320193@EMAS-A> Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk> Please ignore my last message - problem fixed, and in any case the message should have gone to the Icon team. Soirry... Roger Hare. From @um.cc.umich.edu:Paul_Abrahams@MTS.cc.Wayne.edu Mon Jan 27 11:43:37 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Jan 92 11:43:37 MST Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15) id AA02700; Mon, 27 Jan 92 11:43:33 MST Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA01345; Mon, 27 Jan 92 13:39:39 -0500 Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Mon, 27 Jan 92 12:39:17 EST Date: Mon, 27 Jan 92 12:39:04 EST From: Paul_Abrahams@mts.cc.wayne.edu To: icon-group@cs.arizona.edu Message-Id: <408605@MTS.cc.Wayne.edu> Subject: Pipes for MS-DOS clarified Some of the heat generated by my comments about pipes in MS-DOS may come from a confusion between two different ways of using pipes. The case that most people have cited to show the inadequacies of MSDOS piping is a command line of the form prog1 | prog2 | ... | more where at least one of the progs is an Icon program. The enhancements I was discussing were not directed at all towards this case; I don't see anything that MS-DOS Icon can reasonably do to improve DOS's behavior here. The other case, the one that concerned me, was the use, internal to a program, of an Icon expression such as infile := open("dir", "rp") (or its Unix equivalent using "ls"). I still see no difficulties in principle with enhancing MS-DOS Icon to cover this case, although I want to make very clear that I'm not expecting the Icon project to take on the burden of providing this enhancement. If they want to do it, I'd be delighted; if they don't, I'll remain grateful for all the other fine things they have done. My postings have been directed only at the question of whether the enhancement poses difficulties in principle. Although generalizations are risky, my impression, not contradicted by the posted examples, is that most uses of pipes that depend on process interleaving are at the command level rather than at the internal level. Indeed, the internal level is much more useful for extracting the output of a fixed command, while the external level is more useful for combining programs in a flexible way. Paul Abrahams Abrahams@mts.cc.wayne.edu From reid@vtopus.cs.vt.edu Mon Jan 27 12:29:41 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Jan 92 12:29:41 MST Received: from vtopus.cs.vt.edu by optima.cs.arizona.edu (4.1/15) id AA05171; Mon, 27 Jan 92 12:29:35 MST Received: by vtopus.cs.vt.edu (5.57/Ultrix3.0-C) id AA14401; Mon, 27 Jan 92 14:29:20 -0500 Message-Id: <9201271929.AA14401@vtopus.cs.vt.edu> Subject: Programming Problem To: icon-group@cs.arizona.edu Date: Mon, 27 Jan 92 14:29:20 EST From: Thomas F. Reid Cc: reid@vtopus.cs.vt.edu (Thomas F. Reid) X-Mailer: ELM [version 2.3 PL11] I am going to spend a day (2 1/2 hours) of my graduate level programming languages class on Icon and would like the students to do a small programming problem in Icon as homework. What I would like about a 100 line program that I can leave out about 10 lines that they have to figure out and enter. Any suggestions for a meaty little program that will help the students get the gist of Icon without having to do a tremendous amount of programming? Thanks in advance, Tom Reid, Virginia Tech No VA Graduate Center, Falls Church VA, (703)698-4713 reid@vtopus.cs.vt.edu From icon-group-request Wed Jan 29 18:05:49 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 29 Jan 92 18:05:49 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA12117; Wed, 29 Jan 92 18:05:46 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA01057; Wed, 29 Jan 92 16:52:19 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Jan 92 12:34:43 GMT From: hsi!mlfarm!rosie!ron@uunet.uu.net (Ronald Florence) Organization: Maple Lawn Farm, Stonington, CT Subject: Re: Pipes in MS-DOS Icon Message-Id: <1992Jan24.123443.17900@mlfarm.com> References: <407392@MTS.cc.Wayne.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Paul_Abrahams@MTS.CC.WAYNE.EDU writes: In fact, the MS-DOS idea of pipes is only slightly less powerful than the Unix version, and including pipes in MS-DOS Icon poses no problem in principle. Since I don't use MS-DOS I cannot comment on the efficiency of temporary files as pseudo-pipes, and in any case I don't want to join a flame war. I wrote the following code to imitate pipes for MS-DOS and other Icon implementations which cannot write-to or read-from pipes. It works, but as the comment in the header notes, I'm not sure how to determine when a pseudo-pipe fails in MS-DOS. Any suggestions? -----------------------------pipes.icn-------------------------- # pipes.icn # imitates pipes # ron@mlfarm.com, 24 Jan 92 # # This is a modest effort at portability. Unix implementations of # Icon have the ability to read from and write to pipes. Pipeout() # and pipein() are an effort to duplicate this functionality for # systems without pipes, like ms-dos. Both functions could do with # some error-trapping, especially in the ms-dos versions. My # experience with the system function is that it returns 0 (success) # on ms-dos machines even when command.com cannot find the command, so # I'm at a loss how to trap errors. # write "what" (a list) to command "cmd" procedure pipeout(what, cmd) static real_pipes initial real_pipes := find("pipes", &features) p := (\real_pipes & open(cmd, "wp")) | open(tfn := tempname(), "w") every write(p, !what) if \real_pipes then return close(p) else { cmd ||:= " < " || tfn status := system(cmd) remove(tfn) return status } end # read from command "cmd" procedure pipein(cmd) static real_pipes initial real_pipes := find("pipes", &features) if \real_pipes then p := open(cmd || " 2> /dev/null", "rp") else { tfn := tempname() system(cmd || " > " || tfn) p := open(tfn) } suspend !p /real_pipes & remove(tfn) end # Richard Goerwitz's ever-useful generator. procedure tempname() dir := "" every temp_name := dir || "pipe." || right(1 to 999,3,"0") do { close(open(temp_name)) & next suspend \temp_name } end --------------------------------eof----------------------------- -- Ronald Florence ron@mlfarm.com From icon-group-request Thu Jan 30 06:10:49 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 30 Jan 92 06:10:49 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA07373; Thu, 30 Jan 92 06:10:45 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA02380; Thu, 30 Jan 92 05:03:05 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Jan 92 15:39:34 GMT From: hsi!mlfarm!rosie!ron@uunet.uu.net (Ronald Florence) Organization: Maple Lawn Farm, Stonington, CT Subject: Re: Pipes for MS-DOS Icon revisited Message-Id: <1992Jan26.153934.7567@mlfarm.com> References: <408009@MTS.cc.Wayne.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Paul_Abrahams@MTS.CC.WAYNE.EDU writes: The question of whether or not MD-DOS pipes are bogus has, I think, obscured my main point relative to Icon: that providing pipes in MS-DOS Icon would be a very useful enhancement. Even if the MS-DOS version lacks the full power of the Unix version, the power it provides would be very convenient. Agreed. The code below is intuitive, if not efficient. The `pipe' has to be closed with pclose under ms-dos. # # popen.icn # ron@mlfarm.com, 26 Jan 1992 # # popen(cmd, mode) # mode == "w" writes to a pipe, mode == "r" reads from a pipe # pclose(pipe) # # On systems without real pipes (ms-dos), popen and pclose imitate # pipes; pclose must be called after popen. The code should run # faster on ms-dos if dir in tempname() points to a directory on a # virtual disk. # # On systems with real pipes, popen & pclose open and close a pipe. # global real_pipes, pipe_cmd, pipe_fname procedure popen(cmd, mode) initial { real_pipes := find("pipes", &features) pipe_cmd := table() pipe_fname := table() } \real_pipes & return open(cmd, mode || "p") tfn := tempname() upto('r', mode) & system(cmd || " > " || tfn) p := open(tfn, mode) pipe_fname[p] := tfn upto('w', mode) & pipe_cmd[p] := cmd return p end procedure pclose(pipe) \real_pipes & return close(pipe) if \pipe_cmd[pipe] then { pipe_cmd[pipe] ||:= " < " || pipe_fname[pipe] status := system(pipe_cmd[pipe]) } else status := close(pipe) remove(pipe_fname[pipe]) pipe_cmd[pipe] := pipe_fname[pipe] := &null return status end # Richard Goerwitz's ever-useful generator. procedure tempname() dir := "" every temp_name := dir || "pipe." || right(1 to 999,3,"0") do { close(open(temp_name)) & next suspend \temp_name } end -- Ronald Florence ron@mlfarm.com From icon-group-request Mon Feb 3 16:55:51 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 3 Feb 92 16:55:51 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA23123; Mon, 3 Feb 92 16:55:45 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA14662; Mon, 3 Feb 92 15:51:00 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Feb 92 05:54:47 GMT From: wupost!uwm.edu!csd4.csd.uwm.edu!corre@decwrl.dec.com (Alan D Corre) Organization: Computing Services Division, University of Wisconsin - Milwaukee Subject: Icon and MSDOS Message-Id: <1992Feb2.055447.8433@uwm.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu "Nobody appreciates what I do until I don't do it." -- notice above the service desk at our gym. I should like to offer some reflections on using Icon under MSDOS. It seems to me that MSDOS is like a Chevy with automatic shift. It is meant for use by ordinary people who have no interest in looking under the hood. (The last time I did that a hole in a pipe was spurting gasoline and I ran for my life.) MSDOS is rock solid. In the years I have been writing Icon programs and doing much else, my Zenith has never once stopped working. Error messages aplenty, always justified, but never, never a need to reboot. Its commands are named with humans, not machines, in mind. Compare dir, erase, rename with ls, rm and mv. MSDOS made it possible for the ordinary, non-professional programmer to do a lot of useful, if simple-minded, work. So it doesn't have pipes. I was never a smoker anyway. I only realised this when I shifted to using ProIcon on the Mac. For years I had wanted to confront some problems in the teaching of Hebrew in a particular way. I had tried programmed learning, but it was clumsy and cumbersome. The Mac's visual capabilities seemed to make it possible. The result was really excellent. The student sees one window in which he types an English transcription, and another window offers the unvocalized Hebrew equivalent, which he is able to enunciate because he used a modified phonemic transcription. She can switch off the transcription at will. A cumulative log is kept, and is instantly available with dates, lessons studied, and scores. A vocabulary can be viewed at any time. The student can print documents in mixed Hebrew and English. But how difficult it was for me as developer to achieve! The machine was forever blowing up for no apparent reason, and demanding to be restarted from scratch. Some of this was due to bugs in the Icon program, which were promptly attended to by the author, but most were simply that Mac operating system. Peter Robinson of Oxford, author of a Mac program called "Collate" puts it well in the documentation (p.69): I have taken every care I could to make Collate as stable as possible. However, C programming is notoriously tricky, and nowhere more so than on the Mac. Essentially, C lets you manipulate any bit of memory you like anyway you like. But if you do this to this bit, or that to that bit, the machine will crash. Most difficult of all: a program will include a memory error which every Mac you run it on tolerates. But the next Mac won't! This applies particularly to locking and unlocking handles to memory. Lock or unlock the wrong handle, at the wrong time, and most of the time all is well. But sometimes... Sometimes, says he. Maybe in Oxford it's sometimes, but in Milwaukee it's like frequently. At the hundredth appearance of that cute little bomb, I started remarking with Queen Victoria: We are not amused. For a period of more than a month I was unable to get my SE to run Icon altogether. I had two people who know much more about the Mac than I do working on it for days. We took all the files off the hard disk and reinitialized it. We removed the inits. Nothing seemed to work. Then I tried booting up the Mac from a floppy, and Icon worked again. The next time I tried from the hard disk, and we were back in business. Last week I needed to make a small change to the program. Since the program was written under system six, and I am now using system seven on the SE, I decided to take Icon off the SE and use the chief Mac in the lab the students use to recompile under the old system six Icon. The lab folks dont want to switch to seven, because they can't spare the memory. Anyway, I made the change, and told the Mac to recompile. It did so. Then characters started appearing on the screen that looked like a cross between Chinese and Mongolian. Then a window appeared that looked like a standard Mac message window, but it was completely empty. And the machine was frozen. I said to the lab monitor glumly: It's stuck. Her hand flew to the reset button at the bottom of the machine. I said: Stop! Tom told me never to do that. She said: Why not? This happens all the time, and I'm always hitting that button. I pleaded: Call Tom, and ask him if it's ok. (I'm too old to adopt the morals of the new generation.) She called and announced: He's with the director of Computer services. He can't come to the phone. She added archly: Can I hit the button now? Go ahead, I said in resignation. The machine made that silly noise and came to life. There was the newly compiled program, and it worked just fine. What had I done wrong? I asked. After compiling the program properly, why should it go beserk? MSDOS I love you. -- Alan D. Corre Department of Hebrew Studies University of Wisconsin-Milwaukee (414) 229-4245 PO Box 413, Milwaukee, WI 53201 corre@csd4.csd.uwm.edu From icon-group-request Tue Feb 4 01:27:27 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 4 Feb 92 01:27:27 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA11856; Tue, 4 Feb 92 01:27:25 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA04266; Tue, 4 Feb 92 00:19:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Jan 92 02:01:18 GMT From: hsi!mlfarm!rosie!ron@uunet.uu.net (Ronald Florence) Organization: Maple Lawn Farm, Stonington, CT Subject: Re: Pipes in MS-DOS Icon (ctd.) Message-Id: <1992Jan29.020118.16915@mlfarm.com> References: <408264@MTS.cc.Wayne.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Paul_Abrahams@MTS.CC.WAYNE.EDU writes: What strikes me about the debate over pipes in MS-DOS Icon is that just about all of the objections to my suggestion have come from Unix users who, judging from their comments, consider MS-DOS to be beneath contempt and never use MS-DOS Icon. Someone once gave me the good advice to never criticize the spouse or children of a friend. Given the sensitivity that the issue provokes, I'd add `operating system' to the do-not-criticize list. That said, I think there is little to be gained by pretending that differences of operating systems do not exist. Unix has pipes on the kernel level; ms-dos does not. We can produce Icon code that will imitate the _function_ of pipes in ms-dos, and doing so makes it possible to write portable Icon code. But there is a difference between reading from and writing to a temporary file, and a true pipe; code which depends heavily on pipes will run better on an operating system with real pipes. Recognizing those differences is not judging ms-dos "beneath contempt." However, I can't resist one dig: anybody out there who has paid for Unix software or hardware with an unreimbursed personal check (OK, Visa and Mastercard count too)? For what it is worth, we bought our Sun workstations and SunOS (the only software we had to buy) with an unreimbursed personal check. Now, let's please let this newsgroup return to talk about Icon, a language that does many things, on many operating systems, very well. -- Ronald Florence ron@mlfarm.com From nevin@apple.com Wed Feb 5 02:08:11 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 5 Feb 92 02:08:11 MST Received: from colossus.apple.com by optima.cs.arizona.edu (4.1/15) id AA19032; Wed, 5 Feb 92 02:08:03 MST Received: from [90.1.0.10] by colossus.apple.com with SMTP (5.65/11-Dec-1991-eef) id AA01496; Tue, 4 Feb 92 23:43:35 -0800 for Received: from [90.134.16.31] (peachfuzz.apple.com) by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef) id AA16328; Tue, 4 Feb 92 23:43:27 -0800 for corre@csd4.csd.uwm.edu Message-Id: <9202050743.AA16328@internal.apple.com> Date: Tue, 4 Feb 1992 23:45:13 -0800 To: icon-group@cs.arizona.edu From: nevin@apple.com (Nevin ":-]" Liber) Subject: Re: Icon and MSDOS Cc: corre@csd4.csd.uwm.edu Alan Corre (corre@csd4.csd.uwm.edu) writes: >It [MS-DOS] is >meant for use by ordinary people who have no interest in looking under >the hood. But as you point out later, you DO want to look under the hood! >Its commands are named with humans, >not machines, in mind. Compare dir, erase, rename with ls, rm and mv. Actually, the only reason that dir, erase, and rename are used is because they have been used on computer systems for years before the PC (my TRS-80 is one example, I believe CP/M is another). Ask any non-computer person what "dir" means, and they'll look at you kind of funny. From the name "erase", can you tell if it actually erases the file, or does it just mark the directory entry as unavailable? Also, "rename" was fine in the old days where there weren't hierarchial file systems, but it is not intuitive that you can "rename" something to put it somewhere else in the directory tree (after all, there is a big distinction made between a directory and a file, and all of a sudden that distinction no longer applies), but you aren't allowed to "rename" it to a different file system. ls, rm, and mv were named with humans in mind; the attempt was to reduce the number of keystrokes to perform a common command (I know that this causes other problems for humans, but the original idea was to help humans). It is utterly obsurd to think that the two letter commands were designed for the machine's sake. > I only realised this when I shifted to using ProIcon on the Mac. >... >But how difficult it was for me as developer to >achieve! But now you are tinkering UNDER THE HOOD; that's what developers DO! It isn't fair to compare USING system A with PROGRAMMING system B! I could claim that using a Mac is much easier than programming a PC, and I don't think I'll get much argument from the PC community. In general, using an arbituary computer system X is always easier than programming arbituary computer system Y. Now, I also believe that we have a long way to go on our development environments (or, to fit it into the analogy: it should be easy for those home mechanics to do the very common stuff like oil changes), but that is a very different topic, and as inappropriate for this newsgroup/mailing list as this one is (sorry folks). ___ NEVIN ":-)" LIBER, Speech Recognition Guy email: nevin@apple.com paper: Apple Computer, Inc. voice: (408) 974-MIX1 20525 Mariani Avenue, MS: 76-7E AppleLink: NEVIN.LIBER Cupertino, California 95014 From corre@convex.csd.uwm.edu Wed Feb 5 08:08:06 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 5 Feb 92 08:08:06 MST Received: from convex.csd.uwm.edu by optima.cs.arizona.edu (4.1/15) id AA12168; Wed, 5 Feb 92 08:08:02 MST Received: by convex.csd.uwm.edu; id AA02512; Wed, 5 Feb 92 09:07:59 -0600 Date: Wed, 5 Feb 92 09:07:59 -0600 From: Alan D Corre Message-Id: <9202051507.AA02512@convex.csd.uwm.edu> To: icon-group@cs.arizona.edu, nevin@apple.com Subject: Re: Icon and MSDOS My comparison was writing Icon programs on the Zenith and Icon programs on the Mac. I'm sorry if I didn't make this clear, but I was not comparing apples and oranges. From TELLEFSENGW@HIRAMB.BITNET Thu Feb 6 12:22:17 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 6 Feb 92 12:22:17 MST Received: from Arizona.edu (Hopey.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15) id AA29878; Thu, 6 Feb 92 12:22:14 MST Received: from HIRAMB (TELLEFSE@HIRAMB) by Arizona.edu (PMDF #12663) id <01GG74IH91YO9D5A62@Arizona.edu>; Thu, 6 Feb 1992 11:45 MST Date: Thu, 6 Feb 1992 13:41 EST From: TELLEFSENGW@HIRAMB.BITNET Subject: Question on generators To: icon-group@cs.arizona.edu Message-Id: <12444929E060142A@HIRAMB> X-Envelope-To: icon-group@cs.arizona.edu X-Vms-To: IN%"icon-group@cs.arizona.edu" I was reading through the Icon Programming Language book last night and I came across a line something like this: if (&features = = "co-expressions") then.... Is there a space between the equals signs, or is it a "==" string comparison? And if it is, why isn't there an "every" before the expression in parentheses (to continue generating values from &features until it fails or matches "co-expressions")? And if it isn't, what do the two equals signs do? I'm sure I'm missing something very basic here, but I still don't know what it is... any help would be appreciated! Thanks, Guy Tellefsen From isidev!nowlin@uunet.uu.net Thu Feb 6 13:27:27 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 6 Feb 92 13:27:27 MST Received: from relay2.UU.NET by optima.cs.arizona.edu (4.1/15) id AA03838; Thu, 6 Feb 92 13:27:23 MST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18697; Thu, 6 Feb 92 15:27:25 -0500 Date: Thu, 6 Feb 92 15:27:25 -0500 From: isidev!nowlin@uunet.uu.net Message-Id: <9202062027.AA18697@relay2.UU.NET> Received: from isidev.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 152632.3443; Thu, 6 Feb 1992 15:26:32 EST To: uunet!cs.arizona.edu!icon-group@uunet.uu.net Subject: Re: ? on generators > I was reading through the Icon Programming Language book last night > and I came across a line something like this: > > if (&features = = "co-expressions") then.... > > Is there a space between the equals signs, or is it a "==" string > comparison? And if it is, why isn't there an "every" before the expression > in parentheses (to continue generating values from &features until it fails > or matches "co-expressions")? And if it isn't, what do the two equals > signs do? > > I'm sure I'm missing something very basic here, but I still don't > know what it is... any help would be appreciated! > > Thanks, > Guy Tellefsen I'm sure given the context, the operator is supposed to be a string comparison, the ==. This illustrates one of the real snazzy features of Icon, goal directed evaluation. I'd suggest reading up on it in the book now that your curiosity is aroused. Goal directed evaluation is very handy for expressions like this where the goal is to determine if co-expressions are one of the features in the version of Icon being executed. Since &features is a generator, all of its results are generated until the comparison succeeds or the generator is exhausted and the comparison expression fails. You have to be cautions with goal directed evaluation since it can sneak up on you when you don't expect it. The first example that comes to mind is when you only want the first element in a list and you use !list as a quick way to get it. If you inadvertently include this expression in a larger comparison expression you will end up generating all the elements in the list until the expression is satisfied or the list is exhausted. I learned this the hard way. I'm sure there are other examples of goal directed evaluation gotchas. The more powerful the tool the more dangerous. Any horror stories out there (not related to pipes in MS-DOS)? --- --- | S | Iconic Software, Inc. - Jerry Nowlin - uunet!isidev!nowlin --- --- From ercn72@festival.edinburgh.ac.uk Mon Feb 10 10:47:29 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 10:47:29 MST Received: from sun2.nsfnet-relay.ac.uk by optima.cs.arizona.edu (4.1/15) id AA24310; Mon, 10 Feb 92 10:47:19 MST Received: from festival.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <19325-0@sun2.nsfnet-relay.ac.uk>; Mon, 10 Feb 1992 15:49:58 +0000 From: "R.J.Hare" Subject: Various To: icon-group@cs.arizona.edu Date: Mon, 10 Feb 92 15:56:24 GMT Message-Id: <9202101556.aa02286@uk.ac.ed.festival> 1) Is there a charge currently for Icon reports? 2) I read the stuff about pipes in the last Analyst with some interest as I have a need for a 'one line calculator' at the moment. Accordingly, I modified the simple code example in the Analyst (last example,in col2 of p2) to accept an Icon expression rather than just the 'write("Hello World")' text. I then read in an expression (say, 3+4) at run time and got the answer I expected. I then modified the program to accept a command line argument - no problems until I entered something like sin(1) when I got a syntax error message. If I entered sin(1) as the input to the read statement (ie: not on the command line) it works fine. However, if I enter "sin(1)" as a command line argument, it works - am I missing something about the differnce between 'simple' things like '3+4' and 'difficult' things like 'sin(1)'? 3) Apart from the advantages outlined in the Newsletter of November 1991, is there any advantage in using the 386 version of Icon? Is it 'faster' or more 'efficient' for instance? Thanks. Roger Hare. From pbewig@netcom.netcom.com Mon Feb 10 11:21:47 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 11:21:47 MST Received: from netcomsv.netcom.com by optima.cs.arizona.edu (4.1/15) id AA27340; Mon, 10 Feb 92 11:21:34 MST Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1) id AA01946; Mon, 10 Feb 92 10:22:00 PST Received: by netcom.netcom.com (4.1/SMI-4.1) id AA24509; Mon, 10 Feb 92 10:22:00 PST From: pbewig@netcom.netcom.com (Phil Bewig) Message-Id: <9202101822.AA24509@netcom.netcom.com> To: icon-group@cs.arizona.edu Subject: Permuted Index for Icon Program Library Date: Mon, 10 Feb 1992 10:20:02 -0800 The following simple pipeline, run from the /usr/icon/v8/ipl directory, will produce a permuted index of all procs and progs in the library: grep "Title:" */*.icn | sed 's/.icn.*:[ \t]*/ /' | ptx -frt | troff -mptx | ... The pipeline works as follows: First, extract the title line from the header in each ipl file; grep prepends the filename to each line. Then, replace everything from the ".icn" filename suffix to the white space after the word "Title:" with a single space. The options to ptx fold upper and lower case together and ignore non-letters (-f), take the first word on each line to be an index entry (-r), and produce output suitable for troff (-t); some of these options may vary on some systems. Finally, the index is printed by troff through whatever post-processors your system requires. You can vary the pipeline to do such things as specify an ignore file for the ptx command or specify additional text or formatting details to troff. I hope you find this useful. Phil pbewig@netcom.com From nevin@apple.com Mon Feb 10 12:48:06 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 12:48:06 MST Received: from colossus.apple.com by optima.cs.arizona.edu (4.1/15) id AA02532; Mon, 10 Feb 92 12:48:03 MST Received: from [90.1.0.10] by colossus.apple.com with SMTP (5.65/11-Dec-1991-eef) id AA01902; Mon, 10 Feb 92 11:44:44 -0800 for Received: from [90.134.16.31] (peachfuzz.apple.com) by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef) id AA00449; Mon, 10 Feb 92 11:44:38 -0800 for ercn72@festival.edinburgh.ac.uk Message-Id: <9202101944.AA00449@internal.apple.com> Date: Mon, 10 Feb 1992 11:46:38 -0800 To: icon-group@cs.arizona.edu From: nevin@apple.com (Nevin ":-]" Liber) Subject: Re: Various Cc: "R.J.Hare" Roger Hare writes: > no problems until I entered something like sin(1) when I got a syntax error > message. If I entered sin(1) as the input to the read statement (ie: not on > the command line) it works fine. However, if I enter "sin(1)" as a command > line argument, it works - am I missing something about the differnce > between 'simple' things like '3+4' and 'difficult' things like 'sin(1)'? (I assume you meant didn't work from the command line). Many shell languages use parentheses as special characters, and may need to be quoted to remove their special meaning so they can be passed directly from the shell to your Icon program. Try something like sin\(1\) or 'sin(1)' (backslashes and single quotes included) and see if that works. ___ NEVIN ":-)" LIBER, Speech Recognition Guy email: nevin@apple.com paper: Apple Computer, Inc. voice: (408) 974-MIX1 20525 Mariani Avenue, MS: 76-7E AppleLink: NEVIN.LIBER Cupertino, California 95014 From pbewig@netcom.netcom.com Mon Feb 10 16:05:44 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 16:05:44 MST Received: from netcomsv.netcom.com by optima.cs.arizona.edu (4.1/15) id AA18593; Mon, 10 Feb 92 16:05:32 MST Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1) id AA02403; Mon, 10 Feb 92 15:05:55 PST Received: by netcom.netcom.com (4.1/SMI-4.1) id AA22714; Mon, 10 Feb 92 15:03:53 PST Date: Mon, 10 Feb 92 15:03:53 PST From: pbewig@netcom.netcom.com (Phil Bewig) Message-Id: <9202102303.AA22714@netcom.netcom.com> Subject: Untranslated Mode in &input Apparently-To: icon-group@cs.arizona.edu In the MS-DOS/386 version of icon from Catspaw, it appears that the file &input is opened in translated mode. I would like to access the bytes of &input one at a time in untranslated mode using reads(). Is there any way to close &input and re-open it in untranslated mode? Thanks, Phil Bewig pbewig@netcom.com From ralph Mon Feb 10 16:36:51 1992 Date: Mon, 10 Feb 92 16:36:51 MST From: "Ralph Griswold" Message-Id: <9202102336.AA15909@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Mon, 10 Feb 92 16:36:51 MST To: pbewig@netcom.netcom.com Subject: Re: Untranslated Mode in &input Cc: icon-group Standard input (&input) is always opened in the translated mode. You can't do anything about it -- it's a property of the C I/O library. The same is true of the standard MS-DOS Icon. To the best of my knowledge, this "feature" is true of all MS-DOS C libraries. The thing I usually do to work around this is to pass a file name as a command-line argument and open the file in untranslated mode inside the program. Incidentally, there probably is a good reason for always opening standard input in the translated mode. Perhaps someone more knowledgeable than I am can illuminate this. Ralph Griswold / Department of Computer Science The University of Arizona / Tucson, AZ 85721 ralph@cs.arizona.edu / uunet!arizona!ralph voice: 602-621-6609 / fax: 602-621-9618 From pbewig@netcom.netcom.com Fri Feb 14 13:05:56 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 14 Feb 92 13:05:56 MST Received: from netcomsv.netcom.com by optima.cs.arizona.edu (4.1/15) id AA03220; Fri, 14 Feb 92 13:05:31 MST Received: from netcom.netcom.com by netcomsv.netcom.com (4.1/SMI-4.1) id AA24327; Fri, 14 Feb 92 12:05:58 PST Received: by netcom.netcom.com (4.1/SMI-4.1) id AA27907; Fri, 14 Feb 92 12:05:56 PST Date: Fri, 14 Feb 92 12:05:56 PST From: pbewig@netcom.netcom.com (Phil Bewig) Message-Id: <9202142005.AA27907@netcom.netcom.com> X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: icon-group@cs.arizona.edu Subject: Lists, Timing, and Memory Consumption Hello, I've been studying the chapter on lists in the icon implementation book. An interesting conclusion of that study is that the manner in which a list is created can have a drastic effect on the memory consumed by the list and the time taken to access the elements of the list. The following program shows the difference between pre-initializing a list by using a L := list(n, 0) statement, to allocate space for the list, or using stack- and-queue statements to build from an initially empty list: procedure main(args) # write headings, initialize variables write(" Pre-initialize List Successive Insertions") write(" ") write(" Block Set-Up Search Block Set-Up Search") write(" Items Memory Time Time Memory Time Time ") write("------ ------ ------ ------ ------ ------ ------") trials := [25, 100, 500, 1000, 2000, 5000, 10000, 25000, 50000] memory := [] # performs tests every n := !trials do { writes(right(n, 6)) # pre-initialize list every put(memory, -&storage) timer := -&time L := list(n, 0) every L[1 to n] := 1992 # a very good year timer +:= &time i := 0 every s := &storage do memory[i +:= 1] +:= s writes(right(memory[3], 10), right(timer, 8)) timer := -&time every k := L[1 to n] timer +:= &time writes(right(timer, 8)) L := [] collect() # successive insertions every put(memory, -&storage) timer := -&time M := [] every 1 to n do put(M, 1992) timer +:= &time i := 0 every s := &storage do memory[i +:= 1] +:= s writes(right(memory[3], 12), right(timer, 8)) timer := -&time every k := M[1 to n] timer +:= &time writes(right(timer, 8)) M := [] collect() write() } end Here is the output from one run of the program: Pre-initialize List Successive Insertions Block Set-Up Search Block Set-Up Search Items Memory Time Time Memory Time Time ------ ------ ------ ------ ------ ------ ------ 25 248 0 0 1124 0 0 100 2632 50 0 4476 60 0 500 9184 110 280 15136 110 110 1000 23936 380 220 36024 390 220 2000 52948 600 610 70660 600 660 5000 111584 1370 1370 168372 1320 1540 10000 249468 2360 2800 334160 2690 3680 25000 535256 7090 6980 817432 6920 9120 50000 1218528 14060 14280 1640988 13510 18780 I am running on a Compaq 386 at 16mhz using the MS-DOS/386 version of Icon from Catspaw. I have several questions: 1) Is there a better way to extract the amount of block memory used from the &storage keyword? What I did is just too ugly. 2) When pre-initializing, why does the memory consumed per item vary? It is 10 bytes per item for 25 items, 26 bytes per item for 100, 24 bytes at 1000, 22 bytes at 5000, 25 bytes at 10000, 21 bytes at 25000, and 24 bytes at 50000. 3) Memory consumed per item for successive insertions also varies, from 45 bytes per item at 25 and 100 items, to 30 bytes per item at 500, back up to 36 bytes at 1000, decreasing at each step to 32 bytes per item at 25000, and then increasing to 33 bytes at 50000. Why? The moral of the story is to pre-initialize lists whenever possible so that space is allocated more efficiently, especially when making a large number of searches in a static array. Phil Bewig pbewig@netcom.com From icon-group-request Sat Feb 15 16:04:22 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 15 Feb 92 16:04:22 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA07253; Sat, 15 Feb 92 16:04:16 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA15789; Sat, 15 Feb 92 14:53:38 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Feb 92 22:46:33 GMT From: csus.edu!wupost!zaphod.mps.ohio-state.edu!uwm.edu!convex.csd.uwm.edu!corre@ucdavis.ucdavis.edu (Alan D Corre) Organization: University of Wisconsin - Milwaukee Subject: ProIcon Program Message-Id: <1992Feb10.224633.15785@uwm.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Since I have not seen much here on ProIcon I offer a program which is a small part of the package to which I referred in a previous posting. This is the one that prints mixed Hebrew and English text. It is not a word processor, although it has some of the characteristics of one. Since in this system students are encouraged to regard as Hebrew words what goes into their heads and not what goes on paper, this program is psychologically important, since it enables the student to produce nicely printed "real" Hebrew. Part of the point is to avoid the archaic, difficult, addictive massoretic vowel point system. I realise that it could be greatly improved, but it works well enough, and sufficient unto the day is the evil thereof. ---------------------------------------------------------------------------- #This program is written in ProIcon for the Macintosh computer. Alan D. Corre #August 1991. It takes input in a transcription of Hebrew which represents #current pronunciation adequately but mimics the peculiarities of Hebrew #spelling. Here are some sentences from the beginning of Agnon's story #"Friendship": marat qliyngel 'i$ah mefursemet haytah umenahelet beyt sefer #haytah qowdem liymowt hamilHamah. mi$eni$tanu sidrey ha`owlam,neHtexah #migdulatah..wexol miy $eyac'u low mowniyTiyn ba`owlam haytah mitqarevet #'eclow weyowce't wenixneset leveytow" The letter sin is represented by the #German ess-zed which is alt-s on the Mac and cannot be represented here. #The tilde (~)toggles between English and Hebrew, so the word "bar" will be #the English word "bar" or the Hebrew beyt-rey$ according to the current #mode of the program. Finals are inserted automatically. Justification #both ways occurs unless the program detects a blank or empty line, in #which case the previous line is not justified. #Since I took out non-ASCII chars, and have not rechecked that this #works with the corresponding octal chars, there could be some slips in #this text. global outfilename, outvar, outwin,hebrew_string_flag, hebrew_text_flag, screenwidth,screenheight,markers procedure main() #message() creates a standard Mac message box if message("Do you wish to create a new text or print an old one?","New", "Old") then newtext() else oldtext() #Empty and hide the interactive window wset(0,5) wset(0,0) end procedure newtext() set_markers() get_info() get_screensize() create_file() go() end procedure oldtext() #getfile() allows selection of a file already available outfilename := getfile("Please select file.",,) #attempt to open a window with the name of the file if not (outwin := wopen(outfilename,"f")) then stop() #put a font in this window which has Hebrew letters in high ASCII numbers wfont(outwin,"Ivrit") #use 12-point wfontsize(outwin,12) #show the window. The user wishing to edit must make the window active #and use the appropriate alt keys to edit the Hebrew text. This is not #necessary when using the transcription initially wset(outwin,1) if message("Do you wish to edit? (Press return when through editing.)","Yes","No") then read() if message("Do you wish to print?","Yes","No") then #send the window to the printer if the user desires wprint(outwin,1,1) end procedure set_markers() #five letters preceding these characters take a special final shape markers := ' ,.;:-\324\"?)]}' end procedure get_info() local dimlist outfilename := gettext("What is the name of your output file?",,"Cancel") if /outfilename then stop() #the program has to know what is the principal language in order to leave #blanks at paragraph endings properly. When the text flag is set, then the #program overall is operating in Hebrew mode. When the string flag is set #the current string is Hebrew if message("What is the principal language of the text?","Hebrew","English") then hebrew_string_flag := hebrew_text_flag := 1 if \hebrew_text_flag then { if not message("The principal language used is Hebrew.","Okay","Cancel") then stop()} else if not message("The principal language used is English.","Okay","Cancel") then stop() end procedure get_screensize() local dimlist #&screen is a list. Work with the old standard mac screen dimlist := &screen screenheight := dimlist[3] screenwidth := dimlist[4] if screenwidth > 470 then screenwidth := 470 end procedure create_file() #arrange the various fonts and sizes outwin := wopen(outfilename,"n") outvar := open(outfilename,"w") wsize(0,screenwidth,(screenheight / 2 - 40)) wsize(outwin,screenwidth,(screenheight / 2 - 40)) wfont(outwin,"Ivrit") wfontsize(outwin,12) wfont(0,"Geneva") wfontsize(0,12) #position windows wmove(0,0,40) wmove(outwin,0,screenheight / 2 + 20) wset(outwin,1) #show the output window end procedure process(l) local cursor,substring,newline if *l = 0 then return " " cursor := 1 newline := "" #look for a tilde, and piece together a new line accordingly l ? while substring := tab(upto('~')) do { move(1) if \hebrew_string_flag then substring := hebraize(substring) if /hebrew_text_flag then newline ||:= substring else newline := (substring || newline) #string flag toggle (/hebrew_string_flag := 1) | (hebrew_string_flag := &null) cursor := &pos} substring := l[cursor:0] if \hebrew_string_flag then substring := hebraize(substring) if /hebrew_text_flag then newline ||:= substring else newline := (substring || newline) return newline end procedure justify(l) #doesnt give perfect right justification, but its good enough local stringlength,counter,n,increment,newline stringlength := wtextwidth(outwin,l) newline := l increment := 1 while stringlength < screenwidth do { counter := 0 l ? every n := upto(' ') do { newline[n + (counter * increment)] := " " counter +:= 1 stringlength +:= 4 if stringlength >= screenwidth then break} increment +:= 1} return newline end procedure go() #the appearence of the Hebrew/English window lags one line behind the #input window local line,line2,counter,mess counter := 0 line := read() #octal 263 is option-period. if line == "\263" then stop() while (line2 := read()) ~== "\263" do { counter +:= 1 if ((not match(" ",line2)) & (*line2 ~= 0)) then line := justify(process(line)) else if /hebrew_text_flag then line := process(line) else line := rt(process(line)) if (wtextwidth(outwin,line) - screenwidth) > 10 then { mess := "Warning. Line " || counter || " is " || (wtextwidth(outwin,line) - screenwidth) || " pixels too long." message(mess,"Okay","")} write(outvar,line) line := line2} if /hebrew_text_flag then line := process(line) else line := rt(process(line)) if (wtextwidth(outwin,line) - screenwidth) > 10 then { mess := "Warning. Last Line is " || (wtextwidth(outwin,line) - screenwidth) || " pixels too long." message(mess,"Okay","")} write(outvar,line) if message("Do you wish to print?","Yes","No") then wprint(outwin,1,1) close(outvar) wclose(outwin,"") end procedure hebraize(l) static s2,s3 #' is used for aleph. For the abreviation sign use either alt-] which gives #an appropriate sign, or alt-' which is easier to remember but gives a funny #looking digraph on the screen initial{ s2 := "u\'\276\324bvgdhwzHTykKlmMnNs`pfFcCqr$\247tx\261\335(){}[]X" s3 := "\267\324\'\'\272\272\355\266\372\267\275\305\303\264\373\373\302\265_ \265\176\176\247\322\304\304\304\215\215\317\250\246\244\240_ \373+$)(}{][\373"} #the following (1) inserts initial aleph in case the student has forgotten it #(2) takes care of final x with vowel (all other finals are vowelless in #modern Hebrew (3) takes out vowels except u which is usually represented in #modern Hebrew (4) takes care of other finals (5) converts to Hebrew letters #(6) reverses to Hebrew direction l := reverse(map(finals(devowel(xa(aleph(l)))),s2,s3)) return l end procedure aleph(l) #inserts an aleph in words beginning with vowels only #this alters the duplicate line; compare procedure devowel which rebuilds #the line from scratch local newl,offset newl := l offset := 0 if upto('aeiou',l[1]) then { offset +:= 1 newl[1] := ("\'" || l[1])} l ? while tab(upto(' ')) do { tab(many(' ')) if upto('aeiou',l[&pos]) then { newl[&pos + offset] := ("\'" || l[&pos]) offset +:= 1}} return newl end procedure xa(s) #takes care of the special case of final xa local substr,newstr newstr := "" s ||:= " " s ? {while substr := tab(find("xa")) || move(2) || tab(any(markers)) do { substr[-3] := char(170) newstr ||:= substr} newstr ||:= s[&pos:-1]} return newstr end procedure finals(l) #arranges the final letters static finals,corresp local newline initial {finals := 'xmncf' corresp := table("") corresp["x"] := "\301" corresp["m"] := "\243" corresp["n"] := "\242" corresp["f"] := "\354" corresp["c"] := "\260"} newline := l l ? while tab(upto(finals)) do { move(1) if (any(markers)) | (&pos = *l + 1) then newline[&pos - 1] := corresp[l[&pos - 1]] } return newline end procedure rt(l) #for right justification; chars are of different size local stringlength,newline stringlength := wtextwidth(outwin,l) newline := l if (screenwidth-stringlength) > 0 then newline := (repl(" ",(screenwidth-stringlength +2) / 4) || l) return newline end procedure devowel(l) local newline,substring newline := "" l ? {while substring := tab(upto('aeio')) do { newline ||:= substring move(1)} newline ||:= l[&pos:0]} return newline end From icon-group-request Mon Feb 17 00:08:37 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 17 Feb 92 00:08:37 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA01005; Mon, 17 Feb 92 00:08:34 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA29116; Sun, 16 Feb 92 23:04:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Feb 92 19:45:07 GMT From: world!ksr!tim@uunet.uu.net (Tim Peters) Organization: Kendall Square Research Corp. Subject: Re: Lists, Timing, and Memory Consumption Message-Id: <9855@ksr.com> References: <9202142005.AA27907@netcom.netcom.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <9202142005.AA27907@netcom.netcom.com> pbewig@NETCOM.NETCOM.COM (Phil Bewig) writes: >I've been studying the chapter on lists in the icon implementation book. ... > ...[stuff deleted]... >... >1) Is there a better way to extract the amount of block memory used >from the &storage keyword? What I did is just too ugly. Suggest hiding the trickery in a procedure. E.g., procedure block_memory() local temp every temp := &storage # block memory is the last one return temp end Co-expressions are another way, but (I believe) less portable. >2) When pre-initializing, why does the memory consumed per item vary? >... >3) Memory consumed per item for successive insertions also varies, ... >... Why? Suspect you'll be surprised if you put the line every write(!memory) at the end of your program; don't think you quite managed to measure what you intended to measure. Here are all the lines that affect the `memory' vrbl: >procedure main(args) > ... > memory := [] > ... > every n := !trials do { > ... > every put(memory, -&storage) > ... > i := 0 > every s := &storage do memory[i +:= 1] +:= s > writes(right(memory[3], 10), right(timer, 8)) > ... > every put(memory, -&storage) > ... > i := 0 > every s := &storage do memory[i +:= 1] +:= s > writes(right(memory[3], 12), right(timer, 8)) > ... The scoop is that `memory' keeps growing in length (6 additional elements are appended on each loop iteration), but the elements after memory[3] are never referenced. Expect that what you really want is to delete the memory := [] line before the loop and insert it before each of the two `put' lines. When I did that, the bytes/element reported for the preinitialized case settled down to a very steady 8; in the successive-insertion case, I believe Icon needs additional memory to chain in overflow blocks as needed. >The moral of the story is to pre-initialize lists whenever possible so >that space is allocated more efficiently, especially when making a >large number of searches in a static array. I don't know much about Icon's implementation, but believe your conclusion holds (albeit with somewhat less force) anyway; on the other hand, there's almost no measurable difference until the number of elements in the list is on the order of a thousand, so for "almost all" lists I wouldn't worry about it. was-actually-quite-surprised-at-how-efficiently-icon-managed-to-implement- dynamic-length-list-indexing!-ly y'rs - tim Tim Peters Kendall Square Research Corp tim@ksr.com, ksr!tim@uunet.uu.net ps: for comparison, here's the output of the program after making the changes described above; this is on a Solbourne (souped-up SPARC): Pre-initialize List Successive Insertions Block Set-Up Search Block Set-Up Search Items Memory Time Time Memory Time Time ------ ------ ------ ------ ------ ------ ------ 25 248 0 0 420 16 0 100 848 0 0 1184 0 0 500 4048 0 17 5200 16 0 1000 8048 34 33 11336 33 17 2000 16048 50 67 16836 66 67 5000 40048 133 117 55912 150 167 10000 79936 266 250 83644 300 317 25000 199936 650 600 281128 766 800 50000 399936 1334 1250 421412 1566 1650 >>> END OF MSG From pbewig@netcom.com Tue Feb 18 13:35:46 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 18 Feb 92 13:35:46 MST Received: from netcom.netcom.com by optima.cs.arizona.edu (4.1/15) id AA09531; Tue, 18 Feb 92 13:35:44 MST Received: by netcom.netcom.com (4.1/SMI-4.1) id AA15491; Tue, 18 Feb 92 12:36:10 PST Date: Tue, 18 Feb 92 12:36:10 PST From: pbewig@netcom.com (Phil Bewig) Message-Id: <9202182036.AA15491@netcom.netcom.com> Apparently-To: icon-group@cs.arizona.edu Tim Peters, responding to my earlier post, writes: The scoop is that 'memory' keeps growing in length but the elements after memory[3] are never referenced. Oops! Kernighan and Plauger's book The Elements of Programming Style taught me that ugly code is quite frequently wrong, too. I think I'll have to re-read that classic book. Tim Peters also writes: was-actually-quite-surprised-at-how-efficiently-icon- managed-to-implement-dynamic-length-list-indexing! So was I. In fact, the first chapter I read from the implementation book was the chapter on lists, to see how they did it. From icon-group-request Tue Feb 18 20:36:36 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 18 Feb 92 20:36:36 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA00482; Tue, 18 Feb 92 20:36:32 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA03670; Tue, 18 Feb 92 19:26:54 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Feb 92 22:10:31 GMT From: van-bc!rsoft!agate!spool.mu.edu!sdd.hp.com!think.com!rpi!sarah!eve.albany.edu!lg4248@ucbvax.berkeley.edu (The Sea Nymph) Organization: State University of New York at Albany Subject: implementation book[s]? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I have only seen one book on implementing Icon (in C). Unfortunately I can't remember the specific title or author.. but in general, does anyone know if there is more than one book, and can you tell me what book[s] there is/are? many thanks, lg ****************IAMNOTASIGNATUREIAMAFREETHINKINGINDIVIDUAL****************** From dorsaidm!idealord@uu.psi.com Wed Feb 19 14:44:00 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 19 Feb 92 14:44:00 MST Received: from uu.psi.com by optima.cs.arizona.edu (4.1/15) id AA26562; Wed, 19 Feb 92 14:42:25 MST Received: from dorsaidm.UUCP by uu.psi.com (5.65b/4.1.011392-PSI/PSINet) id AA18826; Wed, 19 Feb 92 16:06:41 -0500 Received: by dorsai.com (1.64/waf) via UUCP; Wed, 19 Feb 92 15:39:26 EST for cs.arizona.edu!icon-group To: icon-group@cs.arizona.edu Subject: ICON Procedures for Reading and Writing Standard MIDI Files From: idealord@dorsai.com (Jeff Harrington) Message-Id: Date: Wed, 19 Feb 92 15:39:26 EST Organization: The Dorsai Diplomatic Mission, New York's Computer Consulate I am interested in archive sites or individuals who have ICON code for this purpose. I am currently developing such a set of procedures and was wondering if others had done work in this area yet. I am developing the capability for algorithmic composition and decomposition ;) of MIDI files and MIDI files containing "gestural" MIDI streams. I would like to be able to convert such files to human readable text and back. Thanks for your consideration of this project. Jeff Harrington idealord@dorsai.com From senac@laas.laas.fr Thu Feb 20 02:16:17 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 20 Feb 92 02:16:17 MST Received: from chenas.inria.fr by optima.cs.arizona.edu (4.1/15) id AA06911; Thu, 20 Feb 92 02:16:10 MST Received: from laas.laas.fr by chenas.inria.fr (5.65c8d/91.12.15) via Fnet-EUnet id AA04012; Thu, 20 Feb 1992 10:15:59 +0100 (MET) Received: by laas.laas.fr, Thu, 20 Feb 92 10:11:40 +0100,Sendmail 5.61+ Date: Thu, 20 Feb 92 10:11:40 +0100 From: Patrick Senac Message-Id: <9202200911.AA15654@laas.laas.fr> Return-Receipt-To: senac@laas.laas.fr To: icon-group@cs.arizona.edu Subject: How to get Icon ? Could you tell me please how to get a free software version of an Icon compiler ( for MS-DOS )from an ftp with your university. I am researcher in CS at LAAS in Toulouse, France, and I am interested by the Icon's string handling capabilities. Thank You very much. From ralph Fri Feb 21 10:28:44 1992 Date: Fri, 21 Feb 92 10:28:44 MST From: "Ralph Griswold" Message-Id: <9202211728.AA00530@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Fri, 21 Feb 92 10:28:44 MST To: icon-group Subject: Version 8.5 of Icon Executables and source code for Version 8.5 of Icon for MS-DOS are now available by anonymous FTP from cs.arizona.edu. cd /icon/interpr/packages/msdos and look around. Stand-alone Macintosh executables are in the parallel macintosh subdirectory. These files will show up on our RBBS in a couple of days. Ralph Griswold / Department of Computer Science The University of Arizona / Tucson, AZ 85721 ralph@cs.arizona.edu / uunet!arizona!ralph voice: 602-621-6609 / fax: 602-621-9618 From TENAGLIA@mis.mcw.edu Sat Feb 22 07:45:36 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 22 Feb 92 07:45:36 MST Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15) id AA02828; Sat, 22 Feb 92 07:45:32 MST Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12252) id <01GGTAWRVDF4AFTRXL@mis.mcw.edu>; Sat, 22 Feb 1992 08:46 CST Date: Sat, 22 Feb 1992 08:46 CST From: Chris Tenaglia - 257-8765 Subject: Word Finder Puzzle To: icon-group@cs.arizona.edu Message-Id: <01GGTAWRVDF4AFTRXL@mis.mcw.edu> X-Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" I noticed a word finder puzzle in comp.lang.icon this past week from Richard Goerwitz. Working from a VMS platform, and lacking some of the links he had, it took me a little while to get it working. But it was intriguing, and I recalled I forgot to post a holiday code for the Valentines/Presidents day. So I'm including my hack of a word finder puzzle generator. I think mine uses more 'brute force' than Richards' and I've only tested it with 8 to 12 words. It should work as well in DOS or Unix. It seems to take too long (probably has too much table copying). Oh well. Enjoy! Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu, mcwmis!tenaglia ############################################################ # # # puzz.icn 2/21/92 by tenaglia # # # # this program generates a word search puzzle # # usage : puzz puzz_out_file x y # # # ############################################################ global matrix, # the actual puzzle board width, # width of the puzzle height, # height of the puzzle completed # number of completed word placements procedure main(param) # # initial set up : x=20, y=20 by default # width := param[1] | 20 height := param[2] | 20 words := [] # # load words to place in a space delimited # file. more than one word per line is ok. # while line := map(read()) do { tokens := parse(line,' \t') while put(words,pop(tokens)) } # # get ready for main processing # matrix := table(" ") pass := 0 completed := 0 &random:= map(&clock,":","0") # # here's the actual word placement rouinte # every word := !words do place(word) # # fill in the unchosen areas with random alphas # every i := 1 to height do every j := 1 to width do if matrix[i||","||j] == " " then matrix[i||","||j] := ?(&ucase) # # output results (for the test giver, words are lcase, noise is ucase) # write(completed," words inserted out of ",*words," words.\n") write("\nNow for the puzzle you've been waiting for! (ANSWER)\n") every i := 1 to height do { every j := 1 to width do writes(matrix[i||","||j]," ") write() } # # output results (for the test taker, everything is upper case # write("\fNow for the puzzle you've been waiting for! (PUZZLE)\n") every i := 1 to height do { every j := 1 to width do writes(map(matrix[i||","||j],&lcase,&ucase)," ") write() } end # # this procedure tries to place the word in a copy of the matrix # if successful the updated copy is moved into the original # if not, the problem word is skipped after 20 tries # procedure place(str) static xstep,ystep initial { xstep := [0,1,1,1,0,-1,-1,-1] ystep := [-1,-1,0,1,1,1,0,-1] } pass := 0 repeat { if (pass +:= 1) > 20 then { write("skipping ",str) fail } direction := ?8 xinc := integer(xstep[direction]) yinc := integer(ystep[direction]) if xinc < 0 then x := *str + ?(width - *str) if xinc = 0 then x := ?height if xinc > 0 then x := ?(width - *str) if yinc < 0 then y := *str + ?(height - *str) if yinc = 0 then y := ?width if yinc > 0 then y := ?(height - *str) if (x < 1) | (y < 1) then stop(str," too long.") construct := copy(matrix) item := str write("placing ",item) every byte := !item do { if (construct[x||","||y] ~== " ") & (construct[x||","||y] ~== byte) then break next construct[x||","||y] := byte x +:= xinc y +:= yinc } matrix := copy(construct) completed +:= 1 return "ok" } # end repeat return "ok" end # # parse a string into a list with respect to a delimiter (cset) # procedure parse(line,delims) static chars chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end From icon-group-request Sat Feb 22 13:12:40 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 22 Feb 92 13:12:40 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA11503; Sat, 22 Feb 92 13:12:34 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA05518; Sat, 22 Feb 92 11:54:54 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Feb 92 15:41:29 GMT From: hsi!mlfarm!rosie!ron@uunet.uu.net (Ronald Florence) Organization: Maple Lawn Farm, Stonington, CT Subject: mr.icn - a mail (and news) reader Message-Id: <1992Feb6.154129.26508@mlfarm.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Mr is a simple reader for mail. It won't replace elm, mush, mailtool, or the emacs mail readers, but it is small, quick, easy-to-use, and robust. Mr has commands to page, reply-to, save, append, print, forward, pipe, conceal and reveal headers, originate, delete, and undelete mail. An alternate mailspool, or a newspool created by bsnews, a news system for leaf nodes, can be specified on the command line. Mr is written entirely in Icon. To build mr, you need iolib.icn, available from the IPL. Rename Makefile.unix or Makefile.dos to Makefile, configure mr.icn (instructions are in the header comments), and do `make'. The Unix Makefile includes an install option. On a non-Unix system, make sure the TERM and TERMCAP environmental variables are set correctly; see the comments in iolib.icn if you are not familiar with termcap. Mr has not been tested on ms-dos: it might run up against memory limits on large mail spools, and while the ms-dos pseudo-pipes in popen.icn should work to send a mail message thru a simple pipe command like `uudecode' or `unshar', they probably will not work on a pipeline like `pretty-formatter | print-spooler'. A list of the commands is available by entering `h' or `?' in mr. The shar file also included a man page, and for those without troff, a formatted version of the man page using backspaces for bolds and underlines. In the interest of portability and simplicity, mr does not use getch() command input. Nor does it include a lot of other bells and whistles that are pretty standard in sophisticated mail readers. Mr might be useful to someone with simpler mail needs. Ronald Florence #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # mr.icn # popen.icn # mr.man # Makefile.unix # Makefile.dos # manpage.mr # This archive created: Thu Feb 6 10:24:02 1992 # By: Ronald Florence (Maple Lawn Farm, Stonington, CT ) export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'mr.icn'" '(11250 characters)' if test -f 'mr.icn' then echo shar: "will not over-write existing file 'mr.icn'" else sed 's/^X//' << \SHAR_EOF > 'mr.icn' X############################################################################ X# X# Name: mr.icn X# X# Title: Mail (and News) Reader X# X# Author: Ronald Florence (ron@mlfarm.com) X# X# Date: 7 February 1992 X# X# Version: 1.0 X# X############################################################################ X# X# This simple mail reader will also work with bsnews news spools (see X# comp.sources.misc). X# X# Configuration: X# Editor for replies or new mail. X# Host optional upstream routing address for outgoing mail; X# a domained Host is appended to the address, a uucp X# Host prefixes the address. X# Print_cmd command to format and/or spool material for the printer. X# Mail_cmd the system mailer (usually sendmail, smail, or mail). X# Ignore a list of headers to ignore when paging messages. X# X# On non-Unix systems, change DUNNO in the Mailspool assignment to X# the full path of the default mailspool. Ms-dos users could set X# dir in popen.icn to a directory on a virtual (RAM) disk. Make X# sure the TERMCAP and TERM environment variables are set correctly X# for displays other than ms-dos mono. If you are not familiar with X# termcap, see the header section of iolib.icn. X# X############################################################################ X Xlink popen, iolib Xglobal Host, Editor, Spool, Status, Ignore, X Print_cmd, Mail_cmd, Mailspool, Md, Me, Ce X Xprocedure main(arg) X local i, cmd, art X # configuration X Editor := "vi" X Host := &null X Print_cmd := "mp -F | lpr" X Mail_cmd := "/usr/lib/sendmail -t" X Ignore := ["From ", "Message-Id", "Received", "Return-path", "\tid", X "Path", "Xref", "References", "X-mailer", "Errors-to", X "Resent-Message-Id", "Status", "X-lines"] X if "UNIX" == &features then X Mailspool := "/usr/spool/mail/" || getenv("LOGNAME"|"USER") X else Mailspool := getenv("MAILSPOOL") | "DUNNO" X X # end of configuration X X Md := ckval("md" | "so") | "\e[1m" X Me := ckval("me" | "se") | "\e[m" X Ce := (ckval("up") || ckval("ce")) | "\e[A\e[K" X (*arg > 0) & Mailspool := arg[1] X i := readin(Mailspool) X headers(i) X repeat { X cmd := query("\n[" || i || "/" || *Status || "]: ", " ") X if integer(cmd) & (cmd > 0) & (cmd <= *Status) then headers(i := cmd) X else case map(!cmd) of { X "a": save(query("Append to: "), i, "append") X "x": upto('yY', query("Are you sure? ")) & exit(1) X "l": headers(i) X "r": reply(i) X "d": { (Status[i] ++:= 'D'); writes(Ce); i := inc(i) } X "f": forward(query("Forward to: "), i) X "g": readin(Mailspool, "update") & headers(i) X "s": save(query("Filename: "), i) X "q": quit() X "|": pipeto(query("Command: "), i) X " ": { showart(i); i := inc(i) } X "-": { if (i -:= 1) = 0 then i := *Status; showart(i) } X "n"|"+": showart(i := inc(i)) X "u": { (Status[i] --:= 'D'); writes(Ce); i := inc(i) } X "m": newmail(query("Address: ")) X "p": { pipeto(Print_cmd, i) & Status[i] ++:= 'P'; writes(Ce) } X "v": showart(i, "all") X "!": { system(query("Command: ")) X write() & query("Press to continue") } X "?"|"h": help() X default: { writes(Ce); writes("\^g") } X } X } Xend X X # Read the mail spool into a list of X # lists and set up a status list. Xprocedure readin(spoolname, update) X local sf, i, article X X Spool := [] X \update | Status := [] X sf := open(spoolname) | stop("Can't read " || spoolname) X i := 0 X every !sf ? { X ="From " & { X ((i +:= 1) > 1) & put(Spool, article) X article := [] X /update | /Status[i] & put(Status, 'N') X } X (i > 0) & put(article, &subject) X } X (i > 0) & { X put(Spool, article) X i := 1 X } X close(sf) X return i Xend X X # Parse messages for author & subject, X # highlight the current message. Xprocedure headers(art) X local hlist, i, entry, author, subj X X hlist := [] X every i := 1 to *Status do { X entry := if i = art then Md else "" X entry ||:= left(i, 3, " ") || left(Status[i], 4, " ") X author := "" X subj := "" X while (*author = 0) | (*subj = 0) do !Spool[i] ? { X ="From: " & author := tab(0) X ="Subject: " & subj := tab(0) X (*&subject = 0) & break X } X entry ||:= " [" || right(*Spool[i], 3, " ") || ":" X entry ||:= left(author, 17, " ") || "] " || left(subj, 45, " ") X (i = art) & entry ||:= Me X put(hlist, entry) X } X put(hlist, "") X more(Mailspool, hlist) Xend X X # Check if any messages are deleted; X # if the spool cannot be written, X # write a temporary spool. Rename X # would be convenient, but won't work X # across file systems. Xprocedure quit() X local msave, f, tfn, i X X every !Status ? { find("D") & break msave := 1 } X \msave & { X (f := open(Mailspool, "w")) | { X f := open(tfn := tempfile("spool."), "w") X write("Cannot write " || Mailspool || ". Saving changes to " || tfn) X } X every i := 1 to *Status do { X find("D", Status[i]) | every write(f, !Spool[i]) X } X } X exit(0) Xend X X Xprocedure save(where, art, append) X local mode, outf X X mode := if \append then "a" else "w" X outf := open(where, mode) | { write("Can't write ", where) & fail } X every write(outf, !Spool[art]) X Status[art] ++:= 'S' X return close(outf) Xend X X X # A pipe for Unix; pseudo-pipe for ms-dos. Xprocedure pipeto(cmd, art) X local p X X p := popen(cmd, "w") X every write(p, !Spool[art]) X return pclose(p) Xend X X X # Lots of case-insensitive parsing. Xprocedure reply(art) X local tfn, fullname, address, quoter, date, id, subject, newsgroup, refs, r X X r := open(tfn := tempfile("reply."), "w") X every !Spool[art] ? { X tab(match("from: " | "reply-to: ", map(&subject))) & { X if find("<") then { X fullname := tab(upto('<')) X address := (move(1), tab(find(">"))) X } X else { X address := trim(tab(upto('(') | 0)) X fullname := (move(1), tab(find(")"))) X } X while match(" ", \fullname, *fullname) do fullname ?:= tab(-1) X quoter := if *\fullname > 0 then fullname else address X } X tab(match("date: ", map(&subject))) & date := tab(0) X tab(match("message-id: ", map(&subject))) & id := tab(0) X match("subject: ", map(&subject)) & subject := tab(0) X match("newsgroups: ", map(&subject)) & newsgroup := tab(upto(',') | 0) X match("references: ", map(&subject)) & refs := tab(0) X (\address & *&subject = 0) & { X writes(r, "To: " || address) X write(r, if *\fullname > 0 then " (" || fullname || ")" else "") X \subject & write(r, subject) X \newsgroup & write(r, newsgroup) X \refs & write(r, refs, " ", id) X write(r, "In-reply-to: ", quoter, "'s message of ", date); X write(r, "\nIn ", id, ", ", quoter, " writes:\n") X break X } X } X every write(r, " > ", !Spool[art]) X send(tfn, address) & { X Status[art] ++:= 'RO' X Status[art] --:= 'N' X } Xend X X # Put user in an editor with a temp X # file, query for confirmation, if X # necessary rewrite address, and send. Xprocedure send(what, where) X local edstr, mailstr, done X static console X X initial { X if "UNIX" == &features then console := "/dev/tty" X else if "MS-DOS" == &features then console := "CON" X else write("Need to configure `console' in mr.icn.") & fail X } X edstr := getenv("EDITOR") | Editor || " " || what || " < " || console X system(edstr) X upto('nN', query( "Send to " || where || " y/n? ")) & { X if upto('yY', query("Save your draft y/n? ")) then X writes(Ce) & write("Your draft is saved in " || what || "\n") X else writes(Ce) & remove(what) X fail X } X writes(Ce) X \Host & not find(map(Host), map(where)) & upto('!@', where) & { X find("@", where) & where ? { X name := tab(upto('@')) X where := (move(1), tab(upto(' ') | 0)) || "!" || name X } X if find(".", Host) then where ||:= "@" || Host X else where := Host || "!" || where X } X mailstr := Mail_cmd || " " || where || " < " || what X done := system(mailstr) X remove(what) X return done Xend X X Xprocedure forward(who, art) X local out, tfn X X out := open(tfn := tempfile("forward."), "w") X write(out, "To: " || who) X write(out, "Subject: FYI (forwarded mail)\n") X write(out, "-----[begin forwarded message]-----") X every write(out, !Spool[art]) X write(out, "------[end forwarded message]------") X send(tfn, who) & Status[art] ++:= 'F' Xend X X Xprocedure newmail(address) X local out, tfn X X out := open(tfn := tempfile("mail."), "w") X write(out, "To: " || address) X write(out, "Subject:\n") X return send(tfn, address) Xend X X Xprocedure showart(art, eoh) X local out X X out := [] X every !Spool[art] ? { X /eoh := *&subject = 0 X if \eoh | not match(map(!Ignore), map(&subject)) then put(out, tab(0)) X } X more("Message " || art, out, "End of Message " || art) X Status[art] ++:= 'O' X Status[art] --:= 'N' Xend X X Xprocedure help() X local hlist X static pr, sts X X initial { X pr := ["Append message to a file", X "Delete message", X "eXit, without saving changes", X "Forward message", X "Get new mail", X "Help", X "List headers", X "Mail to a new recipient", X "Next message", X "Print message", X "Quit, saving changes", X "Reply to message", X "Save message", X "Undelete message", X "View all headers", X "| pipe message to a command", X "+ next message", X "- previous message", X "! execute command", X "# make # current message"] X sts := ["New", "Old", "Replied-to", "Saved", X "Deleted", "Forwarded", "Printed"] X } X hlist := [] X every !pr ? put(hlist, " " || tab(upto(&ucase++'!|+-#') \1) || X Md || move(1) || Me || tab(0)) X put(hlist, "") X every !sts ? put(hlist, " " || tab(upto(&ucase)) || X Md || move(1) || Me || tab(0)) X put(hlist, "") X more("Commands & Status Symbols", hlist) Xend X X # The second parameter specifies a X # default response if the user presses X # . Xprocedure query(prompt, def) X local ans X X writes(Ce) X writes(prompt) X ans := read() X return (*ans = 0 & \def) | ans Xend X X # Increment the count, then cycle X # through again when user reaches the X # end of the list. Xprocedure inc(art) X X if (art +:= 1) > *Status then art := 1 X return art Xend X X Xprocedure more(header, what, footer) X local ans, lines X static li, so, se, co, cl, us, ue X X initial { X li := ckval("li") | 25 X co := ckval("co") | 80 X so := ckval("so") | "\e[7m" X se := ckval("se") | "\e[m" X cl := ckval("cl") | "\e[H\e[2J" X us := ckval("us"|"so") | "\e[4m" X ue := ckval("ue"|"se") | "\e[m" X } X writes(cl) X if \header then { X write(us || header || ue) X lines := 1 X } X else lines := 0 X every !what ? { X write(tab(0)) X ((lines +:= 1 + *&subject/co) % (li - 1) = 0) & { X writes(so || "-MORE-(", (100 > (lines - 2)*100/*what) | 100, "%)" || se) X ans := read() & writes(Ce) X upto('nNqQ', ans) & fail X } X } X \footer & { X writes(so || footer || se) X read() & writes(Ce) X } Xend X X Xprocedure ckval(titem) X static termcap X X initial { X if \getenv("TERMCAP") | close(open("/etc/termcap")) then termcap := 1 X else if "MS-DOS" == &features then termcap := &null X else stop("Need TERMCAP & TERM environment variables") X } X \termcap & return getval(titem) X fail Xend X SHAR_EOF if test 11250 -ne "`wc -c < 'mr.icn'`" then echo shar: "error transmitting 'mr.icn'" '(should have been 11250 characters)' fi fi echo shar: "extracting 'popen.icn'" '(1855 characters)' if test -f 'popen.icn' then echo shar: "will not over-write existing file 'popen.icn'" else sed 's/^X//' << \SHAR_EOF > 'popen.icn' X######################################################################## X# X# Name: popen.icn X# X# Title: Pipes for Unix and non-Unix systems X# X# Author: Ronald Florence (ron@mlfarm.com) X# X# Version: 1.0 X# X######################################################################### X# X# Contents: X# X# popen(command, mode) X# mode == "w" writes to a pipe X# mode == "r" reads from a pipe X# X# pclose(pipe) X# X# On systems without real pipes (ms-dos), popen and pclose imitate X# pipes; pclose must be called after popen. The code should run X# faster on ms-dos if dir in tempfile() points to a directory on a X# virtual disk. X# X# On systems with real pipes, popen & pclose open and close a pipe. X# X########################################################################## X Xglobal PIPE_cmd, PIPE_fname X Xprocedure popen(cmd, mode) X local tfn, p X X initial ("pipes" == &features) | { X PIPE_cmd := table() X PIPE_fname := table() X } X (type(PIPE_fname) ~== "table") & return open(cmd, mode || "p") X tfn := tempfile("pipe.") X upto('r', mode) & system(cmd || " > " || tfn) X p := open(tfn, mode) X PIPE_fname[p] := tfn X upto('w', mode) & PIPE_cmd[p] := cmd X return p Xend X X Xprocedure pclose(pipe) X local status X X (type(PIPE_fname) ~== "table") & return close(pipe) X if \PIPE_cmd[pipe] then { X close(pipe) X PIPE_cmd[pipe] ||:= " < " || PIPE_fname[pipe] X status := system(PIPE_cmd[pipe]) X } X else status := close(pipe) X remove(PIPE_fname[pipe]) X PIPE_cmd[pipe] := PIPE_fname[pipe] := &null X return status Xend X X # Richard Goerwitz's ever-useful generator. X Xprocedure tempfile(template) X local temp_name X static dir X X initial { X if "UNIX" == &features then dir := "/tmp/" X else dir := "" X } X every temp_name := dir || template || right(1 to 999,3,"0") do { X close(open(temp_name)) & next X suspend \temp_name X } Xend SHAR_EOF if test 1855 -ne "`wc -c < 'popen.icn'`" then echo shar: "error transmitting 'popen.icn'" '(should have been 1855 characters)' fi fi echo shar: "extracting 'mr.man'" '(2580 characters)' if test -f 'mr.man' then echo shar: "will not over-write existing file 'mr.man'" else sed 's/^X//' << \SHAR_EOF > 'mr.man' X.\" mr.man version 1.0 X.\" copyright 1991 Ronald Florence X.TH MR LOCAL "7 Feb 1992" X.SH NAME Xmr \- mail (or news) reader X.SH SYNOPSIS X.B mr X[ X.I spool X] X.SH DESCRIPTION XMr is a simple reader for mail and/or news spools. It won't obsolete Xelm, mailtool, emacs, mush, or even /usr/ucb/Mail, but it allows a Xreader to page, reply-to, save, append, print, forward, pipe, Xoriginate, conceal or reveal headers, and delete or undelete mail. Mr Xcan also be used to read the news spools produced by the bsnews news Xsystem for leaf nodes. X.SH COMMANDS XAn alternate mail or news spool can be named on the command line. The Xinitial display lists waiting messages: X.ta .5i 1i 3.5i X.sp X.nf X.if t .ft CR X1 FOP [ 22:ron@mlfarm.com (R] How to use mr X.ie t .ft CB X.el .ft B X2 DOR [985:goer@sophist.uchi] Improving MR (part I) X.ie t .ft CR X.el .ft R X3 N [ 61:ralph@cs.arizona.] MS-Dos Pipes X.ft R X.fi X.P XThe letters after the message number indicate the status of the Xmessage; New, Old, Replied-to, Printed, Deleted, Saved, Forwarded. XThe number inside the square brackets is the number of lines in the Xmessage, followed by the author's name and/or email address, and the Xsubject. The current message is highlighted in bold or reverse video, Xdepending on the capabilities of the display. The prompt shows the Xcurrent message number and the total number of messages. The Xfollowing commands can be given: X.sp X.nf X.RS XA Append current message to a file XD Delete current message XF Forward current message XG Get new mail XH Help XL List headers XM Mail to a new recipient XN Next message XP Print current message XQ Quit, saving changes XR Reply-to current message XS Save current message to a file XU Undelete current message XV View all headers XX eXit without saving changes X| pipe current message to a command X! execute command X# make # current message X+ next message X- previous message X? help X.RE X.fi X.P XPressing X.RI < return > Xwill page thru the current message, then advance the current message Xnumber. Press X.I Q Xor X.I N Xat a X.SM MORE Xprompt to return to the command prompt. X.SH ENVIRONMENT XThe X.SM EDITOR Xand X.SM MAILSPOOL Xenvironmental variables can be used to override default settings. Mr Xuses the X.SM TERM Xand X.SM TERMCAP Xvariables to lookup screen parameters and control strings. X.SH SEE ALSO Xmail(1), sendmail(1), bsnews(\s-1LOCAL\s0) X.SH BUGS XThe pseudo-pipes used for ms-dos cannot handle a complex command. XSome users would undoubtedly prefer getch() style command parsing. XThe pager used to display messages does not back-up. X.SH AUTHOR XRonald Florence (ron\s-2@\s0mlfarm.com). SHAR_EOF if test 2580 -ne "`wc -c < 'mr.man'`" then echo shar: "error transmitting 'mr.man'" '(should have been 2580 characters)' fi fi echo shar: "extracting 'Makefile.unix'" '(276 characters)' if test -f 'Makefile.unix' then echo shar: "will not over-write existing file 'Makefile.unix'" else sed 's/^X//' << \SHAR_EOF > 'Makefile.unix' X# Makefile for mr X X.SUFFIXES: .icn .u1 X X.icn.u1: X icont -c $< X X.icn: X icont $@ X XBINDIR = /usr/local/bin XMANDIR = /usr/man/mann XMANEXT = n X Xmr: popen.u1 iolib.u1 mr.icn X icont -u $@ X Xinstall: mr mr.man X cp mr $(BINDIR) X cp mr.man $(MANDIR)/mr.$(MANEXT) X Xclean: X rm -f *.u[12] SHAR_EOF if test 276 -ne "`wc -c < 'Makefile.unix'`" then echo shar: "error transmitting 'Makefile.unix'" '(should have been 276 characters)' fi fi echo shar: "extracting 'Makefile.dos'" '(129 characters)' if test -f 'Makefile.dos' then echo shar: "will not over-write existing file 'Makefile.dos'" else sed 's/^X//' << \SHAR_EOF > 'Makefile.dos' X# ms-dos makefile for mr X X.SUFFIXES: .icn .u1 .icx X X.icn.u1: X icont -c $< X X.icn.icx: X icont $* X Xmr.icx: popen.u1 iolib.u1 mr.icn SHAR_EOF if test 129 -ne "`wc -c < 'Makefile.dos'`" then echo shar: "error transmitting 'Makefile.dos'" '(should have been 129 characters)' fi fi echo shar: "extracting 'manpage.mr'" '(3534 characters)' if test -f 'manpage.mr' then echo shar: "will not over-write existing file 'manpage.mr'" else sed 's/^X//' << \SHAR_EOF > 'manpage.mr' X X X XMR(LOCAL) MR(LOCAL) X X XNNAAMMEE X mr - mail (or news) reader X XSSYYNNOOPPSSIISS X mmrr [ _s_p_o_o_l ] X XDDEESSCCRRIIPPTTIIOONN X Mr is a simple reader for mail and/or news spools. It X won't obsolete elm, mailtool, emacs, mush, or even X /usr/ucb/Mail, but it allows a reader to page, reply-to, X save, append, print, forward, pipe, originate, conceal or X reveal headers, and delete or undelete mail. Mr can also X be used to read the news spools produced by the bsnews X news system for leaf nodes. X XCCOOMMMMAANNDDSS X An alternate mail or news spool can be named on the com- X mand line. The initial display lists waiting messages: X X 1 FOP [ 22:ron@mlfarm.com (R] How to use mr X 22 DDOORR [[998855::ggooeerr@@ssoopphhiisstt..uucchhii]] IImmpprroovviinngg MMRR ((ppaarrtt II)) X 3 N [ 61:ralph@cs.arizona.] MS-Dos Pipes X X The letters after the message number indicate the status X of the message; New, Old, Replied-to, Printed, Deleted, X Saved, Forwarded. The number inside the square brackets X is the number of lines in the message, followed by the X author's name and/or email address, and the subject. The X current message is highlighted in bold or reverse video, X depending on the capabilities of the display. The prompt X shows the current message number and the total number of X messages. The following commands can be given: X X A Append current message to a file X D Delete current message X F Forward current message X G Get new mail X H Help X L List headers X M Mail to a new recipient X N Next message X P Print current message X Q Quit, saving changes X R Reply-to current message X S Save current message to a file X U Undelete current message X V View all headers X X eXit without saving changes X | pipe current message to a command X ! execute command X # make # current message X + next message X - previous message X ? help X X X X 7 Feb 1992 1 X X X X X XMR(LOCAL) MR(LOCAL) X X X Pressing <_r_e_t_u_r_n> will page thru the current message, then X advance the current message number. Press _Q or _N at a X MORE prompt to return to the command prompt. X XEENNVVIIRROONNMMEENNTT X The EDITOR and MAILSPOOL environmental variables can be X used to override default settings. Mr uses the TERM and X TERMCAP variables to lookup screen parameters and control X strings. X XSSEEEE AALLSSOO X mail(1), sendmail(1), bsnews(LOCAL) X XBBUUGGSS X The pseudo-pipes used for ms-dos cannot handle a complex X command. Some users would undoubtedly prefer getch() X style command parsing. The pager used to display messages X does not back-up. X XAAUUTTHHOORR X Ronald Florence (ron@mlfarm.com). X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 7 Feb 1992 2 X X echo shar: "119 control characters may be missing from 'manpage.mr'" SHAR_EOF if test 3534 -ne "`wc -c < 'manpage.mr'`" then echo shar: "error transmitting 'manpage.mr'" '(should have been 3534 characters)' fi fi exit 0 # End of shell archive -- Ronald Florence ron@mlfarm.com From TENAGLIA@mis.mcw.edu Sun Feb 23 07:51:22 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 23 Feb 92 07:51:22 MST Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15) id AA12627; Sun, 23 Feb 92 07:51:19 MST Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12252) id <01GGUPEH8A34AFTSC7@mis.mcw.edu>; Sun, 23 Feb 1992 08:52 CST Date: Sun, 23 Feb 1992 08:52 CST From: Chris Tenaglia - 257-8765 Subject: Word Puzzle Times To: icon-group@cs.arizona.edu Message-Id: <01GGUPEH8A34AFTSC7@mis.mcw.edu> X-Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" I had a chance to try out the word puzzle I posted earlier on a number of different platforms and noticed something totally unexpected. VAX 780 1MIP 36 sec VAX4500 25MIP 28 sec VAX6620 70MIP 33 sec MSDOS-286 ?MIP 11 sec DEC-Risc 20MIP 1 sec This was on the same piece of code during off hours, so there were no other competing loads. VMS icon usually doesn't make such a bad showing but I wonder if this might be something worth looking into. Perhaps there is some aspect of Icon and VMS where certain coding pratices should be watched out for. Chris Tenaglia (System Manager) | Medical College of Wisconsin 8701 W. Watertown Plank Rd. | Milwaukee, WI 53226 (414)257-8765 | tenaglia@mis.mcw.edu, mcwmis!tenaglia From icon-group-request Tue Feb 25 07:40:17 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 25 Feb 92 07:40:17 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA21544; Tue, 25 Feb 92 07:40:14 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA15085; Tue, 25 Feb 92 06:32:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Feb 92 09:58:23 GMT From: optima.UUCP@arizona.edu (Clinton Jeffery) Subject: Re: Beginner questions Message-Id: <13140@optima.cs.arizona.edu> References: <1992Feb21.042030.4668@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu From article <1992Feb21.042030.4668@midway.uchicago.edu>, by goer@ellis.uchicago.edu (Richard L. Goerwitz): > rahard@ee.umanitoba.ca (Budi Rahardjo) writes: > >>- I'd like to add my own function (written in C). How would >> I call/link that function with my icon program ? > > You would need to recompile the Icon run-time system with your function Richard is right. There is a C-callout mechanism, or you can always write your own Icon "builtin function" that calls your C function. The details are not too hard once you are familiar with Icon's C-based implementation. Lastly, note that Version 8.5 has different details than Version 8.0. >>- Is there an ICON compiler for the MS-DOS (ie. produce .exe file) ? >> (I don't want to run the program with 'iconx' :-) Well, many Icon systems feature executable headers that call iconx when they are run, so you don't have to type it. Under this approach, icont would put out a .COM file or .EXE file, but MS-DOS Icon doesn't have this feature. We'd love it if someone would get it working, bearing in mind that memory is so precious under MS-DOS that only a few kilobytes could be spared for it at runtime. Richard's comments about a REAL Icon compiler under MS-DOS are right on target. Not likely to fit on less than a 386; I don't know of anyone doing one. Does anyone else? >>Sorry if those questions are in the FAQ. > There *is* no FAQ; we answer as we go. Please don't feel you need to > apologize. Would anyone like to start and maintain an icon-group/comp.lang.icon FAQ? > I'd kinda like for one of the more technically inclined readers of this > group to post a followup to this reply. I'm not really qualified to give > definitive answers to your queries (although I hope I've helped sketch > things out). Your answers are generally very high quality, Richard. Please don't feel you need to apologize for them! :-) -- Clint Jeffery, U. of Arizona Dept. of Computer Science cjeffery@cs.arizona.edu -or- {noao allegra}!arizona!cjeffery -- From @um.cc.umich.edu:Paul_Abrahams@MTS.cc.Wayne.edu Tue Feb 25 10:52:38 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 25 Feb 92 10:52:38 MST Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15) id AA29961; Tue, 25 Feb 92 10:52:35 MST Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA13119; Tue, 25 Feb 92 12:48:33 -0500 Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Tue, 25 Feb 92 12:47:51 EST Date: Tue, 25 Feb 92 12:47:56 EST From: Paul_Abrahams@mts.cc.wayne.edu To: icon-group@cs.arizona.edu Message-Id: <422067@MTS.cc.Wayne.edu> Subject: Element generation On page 12 of the October 1991 issue of the Icon Analyst, a technique is suggested for providing a multi-line macro definition facility for input streams. The essence of the method is that you have a loop of the form: every s := !input do { ... } When you encounter a macro definition, you place its lines into a list; when you encounter a use of a macro, you "change" the value of `input' to the list associated with the macro. The trouble with this suggestion is that you can't make the change to `input' in the obvious way, by executing an assignment to `input' from within the loop. The value (and result sequence) of `input' is determined when you enter the loop, and subsequent assignments to `input' are ineffective. It's possible to get the desired effect by breaking out of the loop and restarting it when a macro is encountered, but the necessity of restarting the loop is not obvious from the article. Nevertheless, it's a useful technique to know about. Paul Abrahams From icon-group-request Sat Feb 29 19:30:48 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 29 Feb 92 19:30:48 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA24504; Sat, 29 Feb 92 19:30:44 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA19317; Sat, 29 Feb 92 18:17:11 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Feb 92 16:30:34 GMT From: bonnie.concordia.ca!ccu.umanitoba.ca!news@uunet.uu.net (Budi Rahardjo) Organization: University of Manitoba Subject: Beginner questions Message-Id: <1992Feb20.163034.253@ccu.umanitoba.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I've just got the Icon book and installed icont and iconx on my PC. Some questions: - I'd like to add my own function (written in C). How would I call/link that function with my icon program ? (The book mentioned something about 'reference 8', is this another document ? ftp-able ?) - In MS-DOS how can I get a list of files in certain directory ? Is there an 'opendir()' function ? (Would be nice if I can pipe a 'dir' or 'ls' command in MS-DOS) - Is there an ICON compiler for the MS-DOS (ie. produce .exe file) ? (I don't want to run the program with 'iconx' :-) Sorry if those questions are in the FAQ. -- budi -- Budi Rahardjo Electrical Engineering - University of Manitoba - Canada From icon-group-request Sat Feb 29 20:46:05 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 29 Feb 92 20:46:05 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA26299; Sat, 29 Feb 92 20:46:02 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA22981; Sat, 29 Feb 92 19:37:21 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Feb 92 07:08:19 GMT From: uchinews!ellis!goer@uunet.uu.net (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: sample BNFs Message-Id: <1992Feb28.070819.8756@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu # # Here, by the way, is the sample grammar offered in the magazine # article that got me wondering about Icon-based chart parsers: # ::= | ::= | ( () | ) | \ ( | | | ) ::= ( | | | ) | \ | | | \ ::=

( | ) | ::= ::= and ::= the | a | his | her ::= her | he | they ::= nurse | nurses | book | books | travel | arrow | arrows | \ fortune | fortunes | report ::= outrageous | silly | blue | green | heavy | white | red | \ black | yellow ::= travel | travels | report | see | suffer ::= hear | see | suffer

::= on | of ::= that -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From icon-group-request Sun Mar 1 17:35:55 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 1 Mar 92 17:35:55 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA07815; Sun, 1 Mar 92 17:35:54 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA10682; Sun, 1 Mar 92 16:20:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Feb 92 19:45:07 GMT From: world!ksr!tim@uunet.uu.net (Tim Peters) Organization: Kendall Square Research Corp. Subject: Re: Lists, Timing, and Memory Consumption Message-Id: <9855@ksr.com> References: <9202142005.AA27907@netcom.netcom.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <9202142005.AA27907@netcom.netcom.com> pbewig@NETCOM.NETCOM.COM (Phil Bewig) writes: >I've been studying the chapter on lists in the icon implementation book. ... > ...[stuff deleted]... >... >1) Is there a better way to extract the amount of block memory used >from the &storage keyword? What I did is just too ugly. Suggest hiding the trickery in a procedure. E.g., procedure block_memory() local temp every temp := &storage # block memory is the last one return temp end Co-expressions are another way, but (I believe) less portable. >2) When pre-initializing, why does the memory consumed per item vary? >... >3) Memory consumed per item for successive insertions also varies, ... >... Why? Suspect you'll be surprised if you put the line every write(!memory) at the end of your program; don't think you quite managed to measure what you intended to measure. Here are all the lines that affect the `memory' vrbl: >procedure main(args) > ... > memory := [] > ... > every n := !trials do { > ... > every put(memory, -&storage) > ... > i := 0 > every s := &storage do memory[i +:= 1] +:= s > writes(right(memory[3], 10), right(timer, 8)) > ... > every put(memory, -&storage) > ... > i := 0 > every s := &storage do memory[i +:= 1] +:= s > writes(right(memory[3], 12), right(timer, 8)) > ... The scoop is that `memory' keeps growing in length (6 additional elements are appended on each loop iteration), but the elements after memory[3] are never referenced. Expect that what you really want is to delete the memory := [] line before the loop and insert it before each of the two `put' lines. When I did that, the bytes/element reported for the preinitialized case settled down to a very steady 8; in the successive-insertion case, I believe Icon needs additional memory to chain in overflow blocks as needed. >The moral of the story is to pre-initialize lists whenever possible so >that space is allocated more efficiently, especially when making a >large number of searches in a static array. I don't know much about Icon's implementation, but believe your conclusion holds (albeit with somewhat less force) anyway; on the other hand, there's almost no measurable difference until the number of elements in the list is on the order of a thousand, so for "almost all" lists I wouldn't worry about it. was-actually-quite-surprised-at-how-efficiently-icon-managed-to-implement- dynamic-length-list-indexing!-ly y'rs - tim Tim Peters Kendall Square Research Corp tim@ksr.com, ksr!tim@uunet.uu.net ps: for comparison, here's the output of the program after making the changes described above; this is on a Solbourne (souped-up SPARC): Pre-initialize List Successive Insertions Block Set-Up Search Block Set-Up Search Items Memory Time Time Memory Time Time ------ ------ ------ ------ ------ ------ ------ 25 248 0 0 420 16 0 100 848 0 0 1184 0 0 500 4048 0 17 5200 16 0 1000 8048 34 33 11336 33 17 2000 16048 50 67 16836 66 67 5000 40048 133 117 55912 150 167 10000 79936 266 250 83644 300 317 25000 199936 650 600 281128 766 800 50000 399936 1334 1250 421412 1566 1650 >>> END OF MSG From icon-group-request Sun Mar 1 21:22:35 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 1 Mar 92 21:22:35 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA16165; Sun, 1 Mar 92 21:22:32 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA20359; Sun, 1 Mar 92 20:11:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 92 09:31:44 GMT From: uchinews!ellis!goer@uunet.uu.net (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: NLP & Icon Message-Id: <1992Feb27.093144.1315@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu ############################################################################ # # Name: ichartp.icn # # Title: Iconish implementation of a simple chart parser # # Author: Richard L. Goerwitz # # Version: 1.2 # ############################################################################ # # I was reading Byte Magazine (vol. 17:2 [February, 1992]), and # ran into an article entitled "A Natural Solution" (pages 237-244) # in which a standard chart parser was described in terms of its C++ # implementation. The author remarked at how his optimizations made # it possible to parse a 14-word sentence in only 32 seconds (versus # 146 for a straight Gazdar-Mellish LISP chart parser). 32 seconds # struck me as hardly anything to write home about, so started coding # up a quick system in Icon to see how it compared. This library is # the result. # # The library has a small stub main() procedure that can be used # to get an idea of what is going on. If compiled, the resulting # program takes just a single argument - the name of a BNF file # containing the grammar to use for parsing. Parsing is done # line-by-line on the fly, using the standard input. The results of # the parse are reported using the notation for trees described in # Griswold & Griswold, and also in the IPL collection entitled # "structs.icn." There is often more than one possible parse, and # these are suspended successively, as they are encountered. Unknown # vocabulary is flagged immediately as an error. The tokenizing # routine folds uppercase letters into their lowercase equivalents, # and ignores anything that is not a &letter. # # The parser itself operates in bottom-up fashion, but it might # just as well have been coded as a top-down parser. It also tends # to do things in breadth-first fashion, rather than walking through # each alternative until it is exhausted. BNFs are specified using # the same notation used in Griswold & Griswold, and as described in # the IPL program "pargen.icn," with the difference that all # metacharacters (space, tab, vertical slash, right/left parends, # brackets and angle brackets) can be converted to literals by # prepending a backslash (rendering , , etc. as notations for # these characters unnecessary). Comments can be include along with # BNFs using the same notation as for Icon code (i.e. #-sign). # # Pitfalls to be aware of include things like ::= | ha | # () (a weak attempt at a laugh recognizer). This grammar will # accept "ha," "ha ha," etc. but will suspend an infinite number of # possible parses. The right way to do this sort of thing is ::= # ha | ha, or if you really insist on having the empty string as # a possibility, try things like: # # ::= () | # ::= ha | ha # # Ichartp was kinda thrown together just to see how well Icon # would do at jobs traditionally assigned to LISP, Prolog, etc. I'm # sure it could be very much improved upon. # ############################################################################ # # Links: structs, slashbal, rewrap, strip, stripcom (and ximage for debugging) # # Requires: an up-to-date IPL # ############################################################################ # I use ximage for debugging purposes. link structs, slashbal, rewrap, strip, stripcom#, ximage record stats(edge_list, lhs_table, term_set) record chart(inactive, active) # inactive - set; active - list record retval(no, item) record edge(LHS, RHS, LEN, DONE, BEG, END, SEEN) record short_edge(LHS, RHS) # # For debugging only. # procedure main(a) local res, filename # &trace := -1 filename := \a[1] | "bnfs.byte" while line := read(&input) do { every res := parse_sentence(line, filename, "S") do { if res.no = 0 then write(stree(edge2tree(res.item))) # write(ximage(res.item)) else if res.no = 1 then write("unknown vocabulary item, ", res.item) } } end # # parse_sentence: string x string -> edge records # (s, filename) -> Es # where s is a chunk of text presumed to constitute a sentence # where filename is the name of a grammar file containing BNFs # where Es are edge records containing possible parses of s # procedure parse_sentence(s, filename, start_symbol) local file, e, i, elist, ltbl, tset, ch, tokens, st, memb, new_e, token_set, none_found, active_modified static master, old_filename initial master := table() # # Initialize and store stats for filename (if not already stored). # if not (filename == \old_filename) then { file := open(filename, "r") | p_err(filename, 7) # # Read BNFs from file; turn them into edge structs, and # store them all in a list; insert terminal symbols into a set. # elist := list(); ltbl := table(); tset := set() every e := bnf_file_2_edges(file) do { put(elist, e) # main edge list (active) (/ltbl[e.LHS] := set([e])) | insert(ltbl[e.LHS], e) # index LHSs every i := 1 to e.LEN do # LEN holds length of e.RHS if /e.RHS[i].RHS then # RHS for terminals is null insert(tset, e.RHS[i].LHS) & break } insert(master, filename, stats(elist, ltbl, tset)) old_filename := filename close(file) } elist := fullcopy(master[filename].edge_list) ltbl := fullcopy(master[filename].lhs_table) tset := master[filename].term_set # # Make edge list into the active section of chart; tokenize the # sentence s & check for unrecognized vocabulary. # ch := chart(set(), elist) tokens := tokenize(s) # # Begin parse by entering all tokens in s into the inactive set # in the chart as edges with no RHS (a NULL RHS is characteristic # of all terminals). # token_set := set(tokens) every i := 1 to *tokens do { # Flag words not in the grammar as errors. if not member(tset, tokens[i]) then suspend retval(1, tokens[i]) # Now, give us an inactive edge corresponding to word i. insert(ch.inactive, e := edge(tokens[i], &null, 1, 1, i, i+1)) # Insert word i into the LHS table. (/ltbl[tokens[i]] := set([e])) | insert(ltbl[tokens[i]], e) # Watch out for those empty RHSs. insert(ch.inactive, e := edge("", &null, 1, 1, i, i)) (/ltbl[""] := set([e])) | insert(ltbl[""], e) } *tokens = 0 & i := 0 insert(ch.inactive, e := edge("", &null, 1, 1, i+1, i+1)) (/ltbl[""] := set([e])) | insert(ltbl[""], e) # # Until no new active edges can be built, keep ploughing through # the active edge list, trying to match unconfirmed members of their # RHSs up with inactive edges. # until \none_found do { # write(ximage(ch)) none_found := 1 every e := !ch.active do { active_modified := &null # keep track of inactive edges we've already tried /e.SEEN := set() # # e.RHS[e.DONE+1] is the first unconfirmed category in the # RHS of e; ltbl[e.RHS[e.DONE+1].LHS] are all edges having # as their LHS the LHS of the first unconfirmed category in # e's RHS; we simply intersect this set with the inactives, # and then subtract out those we've seen before in connec- # tion with this edge - # if *(st := \ltbl[e.RHS[e.DONE+1].LHS] ** ch.inactive -- e.SEEN) > 0 then { # record all the inactive edges being looked at as seen e.SEEN ++:= st every memb := !st do { # make sure this inactive edge starts where the # last confirmed edge in e.RHS ends! if memb.BEG ~= \e.RHS[e.DONE].END then next # set none_found to indicate we've created a new edge else none_found := &null # create a new edge, having the LHS of e, the RHS of e, # the start point of e, the end point of st, and one more # confirmed RHS members than e new_e := edge(e.LHS, fullcopy(e.RHS), e.LEN, e.DONE+1, e.BEG, memb.END) new_e.RHS[new_e.DONE] := memb /new_e.BEG := memb.BEG if new_e.LEN = new_e.DONE then { # it's inactive insert(ch.inactive, new_e) insert(ltbl[e.LHS], new_e) if new_e.BEG = 1 & new_e.END = (*tokens+1) then { if new_e.LHS == start_symbol # complete parse then suspend retval(0, new_e) } } else { put(ch.active, new_e) # it's active active_modified := 1 } } } # restart if the ch.active list has been modified if \active_modified then break next } } end # # tokenize: break up a sentence into constituent words, using spaces, # tabs, and other punctuation as separators (we'll need to # change this a bit later on to cover apostrophed words) # procedure tokenize(s) local l, word l := list() s ? { while tab(upto(&letters)) do put(l, map(tab(many(&letters)))) } return l end # # edge2tree: edge -> tree # e -> t # # where e is an edge structure (active or inactive; both are okay) # where t is a tree like what's described in Ralph Griswold's # structs library (IPL); I don't know about the 2nd ed. of # Griswold & Griswold, but the structure is described in the 1st # ed. in section 16.1 # # fails if, for some reason, the conversion can't be made (e.g. the # edge structure has been screwed around with in some way) # procedure edge2tree(e) local memb, t t := [e.LHS] \e.RHS | (return t) # a terminal type(e) == "edge" | (return put(t, [])) # incomplete edge every memb := !e.RHS do # has daughters put(t, edge2tree(memb)) return t end # # bnf_file_2_edges: concatenate backslash-final lines & parse # procedure bnf_file_2_edges(f) while line := read(f) do { line := stripcom(line) while line ?:= 1(tab(-2) || tab(slashupto('\\')), pos(-1)) || !f suspend bnf_2_edges(line) } end # # bnf_2_edges: string -> edge records # s -> Es (a generator) # where s is a CFPSG rule in BNF form # where Es are edges # procedure bnf_2_edges(s) # # Take out non-backslashed whitespace (i.e. spaces and tabs). # stripped_s := "" s ? { while stripped_s ||:= tab(slashupto(' \t')) do tab(many(' \t')) stripped_s ||:= tab(0) } # # Break BNF-style CFPSG rule into LHS and RHS. If there is more # than one RHS (a la the | alternation op), suspend multiple re- # sults. # stripped_s ? { LHS := 1("" ~== tab(slashbal(':', '<', '>')), ="::=") | p_err(s,1) LHS ?:= strip(2(="<", tab(-1), =">"), '\\') | p_err(s, 2) LHS == "" & p_err(s, 6) every RHS := do_slash(tab(0) \ 1) do { RHS := string_2_list(RHS) suspend edge(LHS, RHS, *RHS, 0, &null, &null) } } end # # string_2_list: string -> list # s -> L # where L is a list of partially constructed (short) edges, having # only LHS and RHS; in the case of nonterminals, the RHS is set # to 1, while for terminals the RHS is null (and remains that way # throughout the parse) # procedure string_2_list(s) local RHS_list, LHS (s || "\x00") ? { pos(-1) & (return [short_edge("", &null)]) RHS_list := list() until pos(-1) do { if match("<") then { LHS := ("" ~== tab(slashbal(&cset, '<', '>'))) | p_err(s, 4) LHS ?:= strip(2(="<", tab(-1), =">"), '\\') | p_err(s, 4) put(RHS_list, short_edge(LHS, 1)) } else { LHS := tab(slashupto('<') | -1) slashupto('>', LHS) & p_err(s, 5) put(RHS_list, short_edge(strip(LHS, '\\'), &null)) } } } return RHS_list end # # slashupto: cset x string x integer x integer -> integers # (c, s, i, j) -> Is (a generator) # where Is are the integer positions in s[i:j] before characters # in c that is not preceded by a backslash escape # procedure slashupto(c, s, i, j) if /s := &subject then /i := &pos else /i := 1 /j := *s + 1 /c := &cset c ++:= '\\' s[1:j] ? { tab(i) while tab(upto(c)) do { if (="\\", move(1)) then next suspend .&pos move(1) } } end # # fullcopy: make full recursive copy of object # procedure fullcopy(obj) local retval, i, k case type(obj) of { "co-expression" : return obj "cset" : return obj "file" : return obj "integer" : return obj "list" : { retval := list(*obj) every i := 1 to *obj do retval[i] := fullcopy(obj[i]) return retval } "null" : return &null "procedure" : return obj "real" : return obj "set" : { retval := set() every insert(retval, fullcopy(!obj)) return retval } "string" : return obj "table" : { retval := table(obj[[]]) every k := key(obj) do insert(retval, fullcopy(k), fullcopy(obj[k])) return retval } # probably a record; if not, we're dealing with a new # version of Icon or a nonstandard implementation, and # we're screwed default : { retval := copy(obj) every i := 1 to *obj do retval[i] := fullcopy(obj[i]) return retval } } end # # do_slash: string -> string(s) # Given a|b suspend a then b. Used in conjunction with do_parends(). # procedure do_slash(s) local chunk s ? { while chunk := tab(slashbal('|', '(', ')')) do { suspend do_parends(chunk) move(1) } suspend do_parends(tab(0)) } end # # do_parends: string -> string(s) # Given a(b)c suspend abc; given a(b|c)d suspend abd and acd, etc. # Used in conjuction with do_slash(). # procedure do_parends(s) local chunk, i, j s ? { if not (i := slashupto('(')) then { chunk := tab(0) slashupto(')') & p_err(s, 8) suspend chunk } else { j := i + slashbal(')', '(', ')', s[i+1:0]) | p_err(s, 9) suspend tab(i) || (move(1), do_slash(tab(j))) || (move(1), do_parends(tab(0))) } } end # # p_err: print error message to stderr & abort # procedure p_err(s, n) local i, msg static errlist initial { errlist := [[1, "malformed LHS"], [2, "nonterminal lacks proper <> enclosure"], [3, "missing left angle bracket"], [4, "unmatched left angle bracket"], [5, "unmatched right angle bracket"], [6, "empty symbol in LHS"], [7, "unable to open file"], [8, "unmatched right parenthesis"], [9, "unmatched left parenthesis"] ] } every i := 1 to *errlist do if errlist[i][1] = n then msg := errlist[i][2] writes(&errout, "error ", n, " (", msg, ") in \n") every write("\t", rewrap(s) | rewrap()) exit(n) end -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From icon-group-request Sun Mar 8 12:53:23 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 8 Mar 92 12:53:23 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA05923; Sun, 8 Mar 92 12:53:16 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA27992; Sun, 8 Mar 92 11:48:31 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Feb 92 09:31:44 GMT From: uchinews!ellis!goer@uunet.uu.net (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: NLP & Icon Message-Id: <1992Feb27.093144.1315@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu ############################################################################ # # Name: ichartp.icn # # Title: Iconish implementation of a simple chart parser # # Author: Richard L. Goerwitz # # Version: 1.2 # ############################################################################ # # I was reading Byte Magazine (vol. 17:2 [February, 1992]), and # ran into an article entitled "A Natural Solution" (pages 237-244) # in which a standard chart parser was described in terms of its C++ # implementation. The author remarked at how his optimizations made # it possible to parse a 14-word sentence in only 32 seconds (versus # 146 for a straight Gazdar-Mellish LISP chart parser). 32 seconds # struck me as hardly anything to write home about, so started coding # up a quick system in Icon to see how it compared. This library is # the result. # # The library has a small stub main() procedure that can be used # to get an idea of what is going on. If compiled, the resulting # program takes just a single argument - the name of a BNF file # containing the grammar to use for parsing. Parsing is done # line-by-line on the fly, using the standard input. The results of # the parse are reported using the notation for trees described in # Griswold & Griswold, and also in the IPL collection entitled # "structs.icn." There is often more than one possible parse, and # these are suspended successively, as they are encountered. Unknown # vocabulary is flagged immediately as an error. The tokenizing # routine folds uppercase letters into their lowercase equivalents, # and ignores anything that is not a &letter. # # The parser itself operates in bottom-up fashion, but it might # just as well have been coded as a top-down parser. It also tends # to do things in breadth-first fashion, rather than walking through # each alternative until it is exhausted. BNFs are specified using # the same notation used in Griswold & Griswold, and as described in # the IPL program "pargen.icn," with the difference that all # metacharacters (space, tab, vertical slash, right/left parends, # brackets and angle brackets) can be converted to literals by # prepending a backslash (rendering , , etc. as notations for # these characters unnecessary). Comments can be include along with # BNFs using the same notation as for Icon code (i.e. #-sign). # # Pitfalls to be aware of include things like ::= | ha | # () (a weak attempt at a laugh recognizer). This grammar will # accept "ha," "ha ha," etc. but will suspend an infinite number of # possible parses. The right way to do this sort of thing is ::= # ha | ha, or if you really insist on having the empty string as # a possibility, try things like: # # ::= () | # ::= ha | ha # # Ichartp was kinda thrown together just to see how well Icon # would do at jobs traditionally assigned to LISP, Prolog, etc. I'm # sure it could be very much improved upon. # ############################################################################ # # Links: structs, slashbal, rewrap, strip, stripcom (and ximage for debugging) # # Requires: an up-to-date IPL # ############################################################################ # I use ximage for debugging purposes. link structs, slashbal, rewrap, strip, stripcom#, ximage record stats(edge_list, lhs_table, term_set) record chart(inactive, active) # inactive - set; active - list record retval(no, item) record edge(LHS, RHS, LEN, DONE, BEG, END, SEEN) record short_edge(LHS, RHS) # # For debugging only. # procedure main(a) local res, filename # &trace := -1 filename := \a[1] | "bnfs.byte" while line := read(&input) do { every res := parse_sentence(line, filename, "S") do { if res.no = 0 then write(stree(edge2tree(res.item))) # write(ximage(res.item)) else if res.no = 1 then write("unknown vocabulary item, ", res.item) } } end # # parse_sentence: string x string -> edge records # (s, filename) -> Es # where s is a chunk of text presumed to constitute a sentence # where filename is the name of a grammar file containing BNFs # where Es are edge records containing possible parses of s # procedure parse_sentence(s, filename, start_symbol) local file, e, i, elist, ltbl, tset, ch, tokens, st, memb, new_e, token_set, none_found, active_modified static master, old_filename initial master := table() # # Initialize and store stats for filename (if not already stored). # if not (filename == \old_filename) then { file := open(filename, "r") | p_err(filename, 7) # # Read BNFs from file; turn them into edge structs, and # store them all in a list; insert terminal symbols into a set. # elist := list(); ltbl := table(); tset := set() every e := bnf_file_2_edges(file) do { put(elist, e) # main edge list (active) (/ltbl[e.LHS] := set([e])) | insert(ltbl[e.LHS], e) # index LHSs every i := 1 to e.LEN do # LEN holds length of e.RHS if /e.RHS[i].RHS then # RHS for terminals is null insert(tset, e.RHS[i].LHS) & break } insert(master, filename, stats(elist, ltbl, tset)) old_filename := filename close(file) } elist := fullcopy(master[filename].edge_list) ltbl := fullcopy(master[filename].lhs_table) tset := master[filename].term_set # # Make edge list into the active section of chart; tokenize the # sentence s & check for unrecognized vocabulary. # ch := chart(set(), elist) tokens := tokenize(s) # # Begin parse by entering all tokens in s into the inactive set # in the chart as edges with no RHS (a NULL RHS is characteristic # of all terminals). # token_set := set(tokens) every i := 1 to *tokens do { # Flag words not in the grammar as errors. if not member(tset, tokens[i]) then suspend retval(1, tokens[i]) # Now, give us an inactive edge corresponding to word i. insert(ch.inactive, e := edge(tokens[i], &null, 1, 1, i, i+1)) # Insert word i into the LHS table. (/ltbl[tokens[i]] := set([e])) | insert(ltbl[tokens[i]], e) # Watch out for those empty RHSs. insert(ch.inactive, e := edge("", &null, 1, 1, i, i)) (/ltbl[""] := set([e])) | insert(ltbl[""], e) } *tokens = 0 & i := 0 insert(ch.inactive, e := edge("", &null, 1, 1, i+1, i+1)) (/ltbl[""] := set([e])) | insert(ltbl[""], e) # # Until no new active edges can be built, keep ploughing through # the active edge list, trying to match unconfirmed members of their # RHSs up with inactive edges. # until \none_found do { # write(ximage(ch)) none_found := 1 every e := !ch.active do { active_modified := &null # keep track of inactive edges we've already tried /e.SEEN := set() # # e.RHS[e.DONE+1] is the first unconfirmed category in the # RHS of e; ltbl[e.RHS[e.DONE+1].LHS] are all edges having # as their LHS the LHS of the first unconfirmed category in # e's RHS; we simply intersect this set with the inactives, # and then subtract out those we've seen before in connec- # tion with this edge - # if *(st := \ltbl[e.RHS[e.DONE+1].LHS] ** ch.inactive -- e.SEEN) > 0 then { # record all the inactive edges being looked at as seen e.SEEN ++:= st every memb := !st do { # make sure this inactive edge starts where the # last confirmed edge in e.RHS ends! if memb.BEG ~= \e.RHS[e.DONE].END then next # set none_found to indicate we've created a new edge else none_found := &null # create a new edge, having the LHS of e, the RHS of e, # the start point of e, the end point of st, and one more # confirmed RHS members than e new_e := edge(e.LHS, fullcopy(e.RHS), e.LEN, e.DONE+1, e.BEG, memb.END) new_e.RHS[new_e.DONE] := memb /new_e.BEG := memb.BEG if new_e.LEN = new_e.DONE then { # it's inactive insert(ch.inactive, new_e) insert(ltbl[e.LHS], new_e) if new_e.BEG = 1 & new_e.END = (*tokens+1) then { if new_e.LHS == start_symbol # complete parse then suspend retval(0, new_e) } } else { put(ch.active, new_e) # it's active active_modified := 1 } } } # restart if the ch.active list has been modified if \active_modified then break next } } end # # tokenize: break up a sentence into constituent words, using spaces, # tabs, and other punctuation as separators (we'll need to # change this a bit later on to cover apostrophed words) # procedure tokenize(s) local l, word l := list() s ? { while tab(upto(&letters)) do put(l, map(tab(many(&letters)))) } return l end # # edge2tree: edge -> tree # e -> t # # where e is an edge structure (active or inactive; both are okay) # where t is a tree like what's described in Ralph Griswold's # structs library (IPL); I don't know about the 2nd ed. of # Griswold & Griswold, but the structure is described in the 1st # ed. in section 16.1 # # fails if, for some reason, the conversion can't be made (e.g. the # edge structure has been screwed around with in some way) # procedure edge2tree(e) local memb, t t := [e.LHS] \e.RHS | (return t) # a terminal type(e) == "edge" | (return put(t, [])) # incomplete edge every memb := !e.RHS do # has daughters put(t, edge2tree(memb)) return t end # # bnf_file_2_edges: concatenate backslash-final lines & parse # procedure bnf_file_2_edges(f) while line := read(f) do { line := stripcom(line) while line ?:= 1(tab(-2) || tab(slashupto('\\')), pos(-1)) || !f suspend bnf_2_edges(line) } end # # bnf_2_edges: string -> edge records # s -> Es (a generator) # where s is a CFPSG rule in BNF form # where Es are edges # procedure bnf_2_edges(s) # # Take out non-backslashed whitespace (i.e. spaces and tabs). # stripped_s := "" s ? { while stripped_s ||:= tab(slashupto(' \t')) do tab(many(' \t')) stripped_s ||:= tab(0) } # # Break BNF-style CFPSG rule into LHS and RHS. If there is more # than one RHS (a la the | alternation op), suspend multiple re- # sults. # stripped_s ? { LHS := 1("" ~== tab(slashbal(':', '<', '>')), ="::=") | p_err(s,1) LHS ?:= strip(2(="<", tab(-1), =">"), '\\') | p_err(s, 2) LHS == "" & p_err(s, 6) every RHS := do_slash(tab(0) \ 1) do { RHS := string_2_list(RHS) suspend edge(LHS, RHS, *RHS, 0, &null, &null) } } end # # string_2_list: string -> list # s -> L # where L is a list of partially constructed (short) edges, having # only LHS and RHS; in the case of nonterminals, the RHS is set # to 1, while for terminals the RHS is null (and remains that way # throughout the parse) # procedure string_2_list(s) local RHS_list, LHS (s || "\x00") ? { pos(-1) & (return [short_edge("", &null)]) RHS_list := list() until pos(-1) do { if match("<") then { LHS := ("" ~== tab(slashbal(&cset, '<', '>'))) | p_err(s, 4) LHS ?:= strip(2(="<", tab(-1), =">"), '\\') | p_err(s, 4) put(RHS_list, short_edge(LHS, 1)) } else { LHS := tab(slashupto('<') | -1) slashupto('>', LHS) & p_err(s, 5) put(RHS_list, short_edge(strip(LHS, '\\'), &null)) } } } return RHS_list end # # slashupto: cset x string x integer x integer -> integers # (c, s, i, j) -> Is (a generator) # where Is are the integer positions in s[i:j] before characters # in c that is not preceded by a backslash escape # procedure slashupto(c, s, i, j) if /s := &subject then /i := &pos else /i := 1 /j := *s + 1 /c := &cset c ++:= '\\' s[1:j] ? { tab(i) while tab(upto(c)) do { if (="\\", move(1)) then next suspend .&pos move(1) } } end # # fullcopy: make full recursive copy of object # procedure fullcopy(obj) local retval, i, k case type(obj) of { "co-expression" : return obj "cset" : return obj "file" : return obj "integer" : return obj "list" : { retval := list(*obj) every i := 1 to *obj do retval[i] := fullcopy(obj[i]) return retval } "null" : return &null "procedure" : return obj "real" : return obj "set" : { retval := set() every insert(retval, fullcopy(!obj)) return retval } "string" : return obj "table" : { retval := table(obj[[]]) every k := key(obj) do insert(retval, fullcopy(k), fullcopy(obj[k])) return retval } # probably a record; if not, we're dealing with a new # version of Icon or a nonstandard implementation, and # we're screwed default : { retval := copy(obj) every i := 1 to *obj do retval[i] := fullcopy(obj[i]) return retval } } end # # do_slash: string -> string(s) # Given a|b suspend a then b. Used in conjunction with do_parends(). # procedure do_slash(s) local chunk s ? { while chunk := tab(slashbal('|', '(', ')')) do { suspend do_parends(chunk) move(1) } suspend do_parends(tab(0)) } end # # do_parends: string -> string(s) # Given a(b)c suspend abc; given a(b|c)d suspend abd and acd, etc. # Used in conjuction with do_slash(). # procedure do_parends(s) local chunk, i, j s ? { if not (i := slashupto('(')) then { chunk := tab(0) slashupto(')') & p_err(s, 8) suspend chunk } else { j := i + slashbal(')', '(', ')', s[i+1:0]) | p_err(s, 9) suspend tab(i) || (move(1), do_slash(tab(j))) || (move(1), do_parends(tab(0))) } } end # # p_err: print error message to stderr & abort # procedure p_err(s, n) local i, msg static errlist initial { errlist := [[1, "malformed LHS"], [2, "nonterminal lacks proper <> enclosure"], [3, "missing left angle bracket"], [4, "unmatched left angle bracket"], [5, "unmatched right angle bracket"], [6, "empty symbol in LHS"], [7, "unable to open file"], [8, "unmatched right parenthesis"], [9, "unmatched left parenthesis"] ] } every i := 1 to *errlist do if errlist[i][1] = n then msg := errlist[i][2] writes(&errout, "error ", n, " (", msg, ") in \n") every write("\t", rewrap(s) | rewrap()) exit(n) end -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From icon-group-request Mon Mar 9 02:26:56 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 9 Mar 92 02:26:56 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA03693; Mon, 9 Mar 92 02:26:53 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA28760; Mon, 9 Mar 92 01:17:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Feb 92 22:10:31 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!sdd.hp.com!think.com!rpi!sarah!eve.albany.edu!lg4248@ucbvax.berkeley.edu (The Sea Nymph) Organization: State University of New York at Albany Subject: implementation book[s]? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I have only seen one book on implementing Icon (in C). Unfortunately I can't remember the specific title or author.. but in general, does anyone know if there is more than one book, and can you tell me what book[s] there is/are? many thanks, lg ****************IAMNOTASIGNATUREIAMAFREETHINKINGINDIVIDUAL****************** From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk Thu Mar 12 22:00:41 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 12 Mar 92 22:00:41 MST Received: from by optima.cs.arizona.edu (4.1/15) id AB27665; Thu, 12 Mar 92 22:00:27 MST Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <9035-0@sun2.nsfnet-relay.ac.uk>; Wed, 11 Mar 1992 15:04:49 +0000 Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa17676; 11 Mar 92 11:58 WET Date: 11 Mar 92 11:58:36 gmt From: R.J.Hare@edinburgh.ac.uk Subject: Soundex To: icon-group@cs.arizona.edu Message-Id: <11 Mar 92 11:58:36 gmt 320969@EMAS-A> Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk> Somewhere, recently, I saw Icon code for the Soundex algorithm. I now need this code and can't find it. It doesn't seem to be in the Icon Program Library. Was it posted here? If yes, I'd be grateful if the originator would re-post it. Thanks. Roger Hare. From TENAGLIA@mis.mcw.edu Fri Mar 13 05:14:32 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 13 Mar 92 05:14:32 MST Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15) id AA21865; Fri, 13 Mar 92 05:14:28 MST Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12865) id <01GHL3GOT2CGAFUGQM@mis.mcw.edu>; Fri, 13 Mar 1992 06:15 CST Date: Fri, 13 Mar 1992 06:15 CST From: Chris Tenaglia - 257-8765 Subject: Re: Soundex To: R.J.Hare@edinburgh.ac.uk Cc: icon-group@cs.arizona.edu Message-Id: <01GHL3GOT2CGAFUGQM@mis.mcw.edu> X-Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"R.J.Hare@edinburgh.ac.uk" X-Vms-Cc: IN%"icon-group@cs.arizona.edu" > From: IN%"R.J.Hare@edinburgh.ac.uk" 12-MAR-1992 23:12:53.41 > To: IN%"icon-group@cs.arizona.edu" > Subj: Soundex > Somewhere, recently, I saw Icon code for the Soundex algorithm. I now need > this code and can't find it. It doesn't seem to be in the Icon Program > Library. Was it posted here? If yes, I'd be grateful if the originator would > re-post it. > Thanks. > Roger Hare. Here's my posting from earlier this year. Dr. Griswold also had mentioned that another version is available from the IPL. Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu # # SOUNDEX.ICN 8/28/91 TENAGLIA # # THIS ICON PROGRAM IMPLEMENTS A SOUNDEX CATALOGUING # KEY COMPRESSOR. # procedure main() while map(line := input("Str:")) ~== "quit" do write(soundex(line)) end # # STR IS A STRING (USUALLY A LAST NAME) PHONETICALLY SPELLED. # NUMBER IS RETURNED WHICH IS A CATALOGUE LOOK UP KEY MADE FROM IT. # THE STEPS ARE AS FOLLOWS : # 1. SAVE THE FIRST CHARACTER FOR LATER USE # 2. REMOVE W AND H # 3. REMOVE ALL VOWELS EXCEPT WHEN IN FIRST POSITION # 4. MAP LEFTOVER STRING WITH A NUMBER TABLE # 5. DELETE DUPLICATE ADJACENT DIGITS # 6. MAKE NUMBER 6 CHARACTERS LONG (TRUNCATE OR PAD WITH 0S) # 7. REPLACE FIRST DIGIT WITH SAVED FIRST CHARACTER # procedure soundex(str) static vowels, tbl initial { vowels := 'aeiouy' tbl := "0123012 02245501262301 202" } str := map(str) first := str[1] ; tmp := first ; tmp2 := "" while i := find("w"|"h",str) do str[i] := "" every i := 2 to *str do tmp ||:= if any(vowels,str,i) then "" else str[i] str2 := map(tmp,&lcase,tbl) || "?" every i := 1 to *str2-1 do if str2[i] ~== str2[i+1] then tmp2 ||:= str2[i] number := if *tmp2 < 6 then left(tmp2,6,"0") else tmp2[1+:6] number[1] := first return number end # # GET A STRING OF INPUT FROM THE KEYBOARD # procedure input(prompt) writes(prompt) return read() end From stone@hilbert.math.grin.edu Fri Mar 13 07:47:43 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 13 Mar 92 07:47:43 MST Received: from hilbert.math.grin.edu (HILBERT-GW.MATH.GRIN.EDU) by optima.cs.arizona.edu (4.1/15) id AA25589; Fri, 13 Mar 92 07:47:40 MST Received: from russell.math.grin.edu by hilbert.math.grin.edu (4.1/Stone-5); id AA10637; Fri, 13 Mar 92 08:47:02 CST Date: Fri, 13 Mar 92 08:47:02 CST From: John David Stone Message-Id: <9203131447.AA10637@hilbert.math.grin.edu> Received: by russell.math.grin.edu (4.1/Stone-2); id AA04081; Fri, 13 Mar 92 08:46:59 CST To: icon-group@cs.arizona.edu Subject: Soundex algorithm I'm not the original poster of the Soundex algorithm, but I have a version that should serve your purpose: ---------------------------------------------------------------------------- # When names are communicated by telephone, they are often transcribed # incorrectly. An organization that has to keep track of a lot of names has # a need, therefore, for some system of representing or encoding a name that # will mitigate the effects of transcription errors. One idea, originally # proposed by Margaret K. Odell and Robert C. Russell, uses the following # encoding system to try to bring together occurrences of the same surname, # variously spelled: # # Encode each of the letters of the name according to the # following equivalences: # # a, e, h, i, o, u, w, y -> * # b, f, p, v -> 1 # c, g, j, k, q, s, x, z -> 2 # d, t -> 3 # l -> 4 # m, n -> 5 # r -> 6 # # # If any two adjacent letters have the same code, change the code for the # second one to *. # # The Soundex representation consists of four characters: the initial letter # of the name, and the first three digit (non-asterisk) codes corresponding # to letters after the initial. If there are fewer than three such digit # codes, use all that there are, and add zeroes at the end to make up the # four-character representation. # # This program reads in surnames from standard input, one to a line, and # echoes them with their Soundex representations attached, in the following # format: # # Stone S350 # # Programmer: Exotic Programming Languages Study Group, Grinnell College. # Original version: November 26, 1991. procedure main() local name while name := read() do write(name, repl(" ", 40 - *name), soundex(name)) end procedure soundex(name) local coded_name, new_name coded_name := encode(strip(name)) new_name := name[1] every pos := 2 to *coded_name do { if coded_name[pos] ~== "*" then new_name := new_name || coded_name[pos] if *new_name = 4 then break } return new_name || repl ("0", 4 - *new_name) end procedure encode(name) name := map(name, &ucase, &lcase) name := map(name, "aehiouwybfpvcgjkqsxzdtlmnr", "********111122222222334556") every pos := *name to 2 by -1 do if name[pos - 1] == name[pos] then name[pos] := "*" return name end ------------------------------------------------------------------------------ John David Stone - Lecturer in Computer Science and Philosophy Manager of the Mathematics Local-Area Network Grinnell College - Grinnell, Iowa 50112 - USA stone@math.grin.edu - (515) 269-3181 - stone@grin1.bitnet ------------------------------------------------------------------------------ From stone@hilbert.math.grin.edu Fri Mar 13 08:24:55 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 13 Mar 92 08:24:55 MST Received: from hilbert.math.grin.edu (HILBERT-GW.MATH.GRIN.EDU) by optima.cs.arizona.edu (4.1/15) id AA27079; Fri, 13 Mar 92 08:24:51 MST Received: from russell.math.grin.edu by hilbert.math.grin.edu (4.1/Stone-5); id AA10645; Fri, 13 Mar 92 09:24:09 CST Date: Fri, 13 Mar 92 09:24:09 CST From: John David Stone Message-Id: <9203131524.AA10645@hilbert.math.grin.edu> Received: by russell.math.grin.edu (4.1/Stone-2); id AA04092; Fri, 13 Mar 92 09:24:07 CST To: icon-group@cs.arizona.edu Subject: Missing procedure from Soundex algorithm I see I dropped one procedure from the Soundex algorithm I sent earlier. Here's the missing part: ------------------------------------------------------------------------- procedure strip(name) local result static alphabet initial alphabet := string(&letters) result := "" every ch := !name do if find(ch, alphabet) then result ||:= ch return result end ------------------------------------------------------------------------------ John David Stone - Lecturer in Computer Science and Philosophy Manager of the Mathematics Local-Area Network Grinnell College - Grinnell, Iowa 50112 - USA stone@math.grin.edu - (515) 269-3181 - stone@grin1.bitnet ------------------------------------------------------------------------------ From ralph Fri Mar 13 16:33:16 1992 Date: Fri, 13 Mar 92 16:33:16 MST From: "Ralph Griswold" Message-Id: <9203132333.AA05170@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Fri, 13 Mar 92 16:33:16 MST To: icon-group Subject: Icon electronic mail and news Normally, e-mail to icon-group is passed on to comp.lang.icon newsgroup and news posted to comp.lang.icon is passed on to the icon-group mailing list. At present, however, it appears that news posted to comp.lang.icon is not coming to icon-group. We are looking into the problem. But until it's solved, if you want your postings to get to icon-group, send e-mail to icon-group@cs.arizona.edu (or uunet!arizona!icon-group) rather than posting news to comp.lang.icon. Ralph Griswold / Department of Computer Science The University of Arizona / Tucson, AZ 85721 ralph@cs.arizona.edu / uunet!arizona!ralph voice: 602-621-6609 / fax: 602-621-9618 From goer@midway.uchicago.edu Sat Mar 14 19:12:39 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 14 Mar 92 19:12:39 MST Received: from midway.uchicago.edu by optima.cs.arizona.edu (4.1/15) id AA01733; Sat, 14 Mar 92 19:12:34 MST Received: from ellis.uchicago.edu by midway.uchicago.edu Sat, 14 Mar 92 20:12:32 CST Date: Sat, 14 Mar 92 20:12:32 CST From: "Richard L. Goerwitz" Message-Id: <9203150212.AA18731@midway.uchicago.edu> To: icon-group@cs.arizona.edu Subject: newer puzzle maker I have received some requests for the latest version of the puzzle making toy I posted a while back. Seems sensible just to post it at this point. -Richard ############################################################################ # # Name: makepuzz.icn # # Title: find-the-word puzzle maker # # Author: Richard L. Goerwitz # # Version: 1.18 # ############################################################################ # # This program doesn't do anything fancy. It simply takes a list # of words, and constructs out of them one of those square # find-the-word puzzles that some people like to bend their minds # over. Usage is: # # makepuzz [-f input-file] [-o output-file] [-h puzzle-height] # -w puzzle-width] [-t how-many-seconds-to-keep-trying] # [-r maximum-number-of-rejects] [-s] [-d] # # where input-file is a file containing words, one to a line # (defaults to &input), and ouput-file is the file you would like the # puzzle written to (defaults to &output). Puzzle-height and width # are the basic dimensions you want to try to fit your word game into # (default 20x20). If the -s argument is present, makepuzz will # scramble its output, by putting random letters in all the blank # spaces. The -t tells the computer when to give up, and construct # the puzzle (letting you know if any words didn't make it in). # Defaults to 60 (i.e. one minute). The -r argument tells makepuzz to # run until it arrives at a solution with number-of-rejects or less # un-inserted words. -d turns on certain diagnostic messages. # # Most of these options can safely be ignored. Just type # something like "makepuzz -f wordlist," where wordlist is a file # containing about sixty words, one word to a line. Out will pop a # "word-find" puzzle. Once you get the hang of what is going on, # try out the various options. # # The algorithm used here is a combination of random insertions # and mindless, brute-force iterations through possible insertion # points and insertion directions. If you don't like makepuzz's per- # formance on one run, run it again. If your puzzle is large, try # increasing the timeout value (see -t above). # ############################################################################ # # Links: options, irandom, colmize # Requires: An up-to-date IPL (2/10/92) # ############################################################################ link options, irandom, colmize global height, width, _debug_ procedure main(a) local usage, opttbl, inputfile, outputfile, maxrejects, puzzle, wordlist, rejects, master_list, word, timeout, x, y, l_puzzle, l_wordlist, l_rejects, no_ltrs, l_no_ltrs, try # Filename is the only mandatory argument; they can come in any order. usage := "makepuzz [-f infile] [-o outfile] [-h height] [-w width] _ [-t secs] [-r rejects] [-s]" # Set up puzzle height and width (default 20x20); set up defaults # such as the input & output files, time to spend, target reject # count, etc. opttbl := options(a, "w+h+f:o:t+sr+d") # stop(usage) width := \opttbl["w"] | 20 height := \opttbl["h"] | 20 timeout := &time + (1000 * (\opttbl["t"] | 60)) inputfile := open(\opttbl["f"], "r") | &input outputfile := open(\opttbl["o"], "w") | &output maxrejects := \opttbl["r"] | 0 _debug_ := \opttbl["d"] & try := 0 # Set random number seed. irandom() # Read, check, and sort word list hardest to easiest. master_list := list() every word := "" ~== trim(map(!inputfile)) do { upto(~(&lcase++&ucase), word) & stop("makepuzz: non-letter found in ", word) write(&errout, "makepuzz: warning, ",3 > *word, "-letter word (", word, ")") put(master_list, word) } master_list := sort_words(master_list) if \_debug_ then write(&errout, "makepuzz: thinking...") # Now, try to insert the words in the master list into a puzzle. # Stop when the timeout limit is reached (see -t above). until &time > timeout do { wordlist := copy(master_list); rejects := list() puzzle := list(height); every !puzzle := list(width) blind_luck_insert(puzzle, wordlist, rejects) brute_force_insert(puzzle, wordlist, rejects, timeout) # Count the number of letters left over. no_ltrs := 0; every no_ltrs +:= *(!wordlist | !rejects) l_no_ltrs := 0; every l_no_ltrs +:= *(!\l_wordlist | !\l_rejects) # If our last best try at making a puzzle was worse... if /l_puzzle | (*\l_wordlist + *l_rejects) > (*wordlist + *rejects) | ((*\l_wordlist + *l_rejects) = (*wordlist + *rejects) & l_no_ltrs > no_ltrs) then { # ...then save the current (better) one. l_puzzle := puzzle l_wordlist := wordlist l_rejects := rejects } # Tell the user how we're doing. if \_debug_ then write(&errout, "makepuzz: try number ", try +:= 1, "; ", *wordlist + *rejects, " rejects") # See the -r argument above. Stop if we get to a number of # rejects deemed acceptable to the user. if (*\l_wordlist + *l_rejects) <= maxrejects then break } # Signal to user that we're done, and set puzzle, wordlist, and # rejects to their best values in this run of makepuzz. write(&errout, "makepuzz: done") puzzle := \l_puzzle wordlist := \l_wordlist rejects := \l_rejects # Print out original word list, and list of words that didn't make # it into the puzzle. write(outputfile, "Original word list (sorted hardest-to-easiest): \n") every write(outputfile, colmize(master_list)) write(outputfile, "") if *rejects + *wordlist > 0 then { write(outputfile, "Couldn't insert the following words: \n") every write(outputfile, colmize(wordlist ||| rejects)) write(outputfile, "") } # Scramble (i.e. put in letters for remaining spaces) if the user # put -s on the command line. if \opttbl["s"] then { every y := !puzzle do every x := 1 to *y do /y[x] := ?&ucase # Print out puzzle structure (answers in lowercase). every y := !puzzle do { every x := !y do writes(outputfile, \x | " ", " ") write(outputfile, "") } write(outputfile, "") } # Print out puzzle structure, all lowercase. every y := !puzzle do { every x := !y do writes(outputfile, map(\x) | " ", " ") write(outputfile, "") } # Exit with default OK status for this system. every close(inputfile | outputfile) exit() end procedure sort_words(wordlist) local t, t2, word, sum, l # Obtain a rough character count. t := table(0) every t[!!wordlist] +:= 1 t2 := table() # Obtain weighted values for each word, essentially giving longer # words and words with uncommon letters the highest values. Later # we'll reverse the order (-> hardest-to-easiest), and return a list. every word := !wordlist do { "" == word & next sum := 0 every sum +:= t[!word] insert(t2, word, (sum / *word) - (2 * *word)) } t2 := sort(t2, 4) l := list() # Put the hardest words first. These will get laid down when the # puzzle is relatively empty. Save the small, easy words for last. every put(l, t2[1 to *t2-1 by 2]) return l end procedure blind_luck_insert(puzzle, wordlist, rejects) local s, s2, s3, begy, begx, y, x, diry, dirx, diry2, dirx2, i # global height, width # Try using blind luck to make as many insertions as possible. while s := get(wordlist) do { # First try squares with letters already on them, but don't # try every direction yet (we're relying on luck just now). # Start at a random spot in the puzzle, and wrap around. begy := ?height; begx := ?width every y := (begy to height) | (1 to begy - 1) do { every x := (begx to width) | (1 to begx - 1) do { every i := find(\puzzle[y][x], s) do { diry := ?3; dirx := ?3 s2 := s[i:0] diry2 := 4 > (diry + 2) | 0 < (diry - 2) | 2 dirx2 := 4 > (dirx + 2) | 0 < (dirx - 2) | 2 s3 := reverse(s[1:i+1]) if insert_word(puzzle, s2, diry, dirx, y, x) & insert_word(puzzle, s3, diry2, dirx2, y, x) then break { break break next } } } } # If the above didn't work, give up on spaces with characters # in them; use blank squares as well. every 1 to 512 do if insert_word(puzzle, s, ?3, ?3, ?height, ?width) then break next # If this word doesn't submit to easy insertion, save it for # later. put(rejects, s) } # Nothing useful to return (puzzle, wordlist, and rejects objects # are themselves modified; not copies of them). return end procedure brute_force_insert(puzzle, wordlist, rejects, timeout) local s, start, dirs, begy, begx, y, x # Use brute force on the remaining forms. if *rejects > 0 then { wordlist |||:= rejects; rejects := [] while s := pop(wordlist) do { start := ?3; dirs := "" every dirs ||:= ((start to 3) | (1 to start-1)) begy := ?height; begx := ?width every y := (begy to height) | (1 to begy - 1) do { if &time > timeout then fail every x := (begx to width) | (1 to begx - 1) do { if insert_word(puzzle, s, !dirs, !dirs, y, x) then break { break next } } } # If we can't find a place for s, put it in the rejects list. put(rejects, s) } } # Nothing useful to return (puzzle, wordlist, and rejects objects # are themselves modified; not copies of them). return end procedure insert_word(puzzle, s, ydir, xdir, y, x) local incry, incrx, firstchar # If s is zero length, we've matched it in it's entirety! if *s = 0 then { return } else { # Make sure there's enough space in the puzzle in the direction # we're headed. case ydir of { "3": if (height - y) < (*s - 1) then fail "1": if y < (*s - 1) then fail } case xdir of { "3": if (width - x) < (*s - 1) then fail "1": if x < (*s - 1) then fail } # Check to be sure everything's in range, and that both the x and # y increments aren't zero (in which case, we aren't headed in any # direction at all...). incry := (ydir - 2); incrx := (xdir - 2) if incry = 0 & incrx = 0 then fail height >= y >= 1 | fail width >= x >= 1 | fail # Try laying the first char in s down at puzzle[y][x]. If it # works, head off in some direction, and try laying down the rest # of s along that vector. If at any point we fail, we must # reverse the assignment (<- below). firstchar := !s ((/puzzle[y][x] <- firstchar) | (\puzzle[y][x] == firstchar)) & insert_word(puzzle, s[2:0], ydir, xdir, y + incry, x + incrx) & suspend fail } end From @castle.edinburgh.ac.uk,@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk Thu Mar 19 19:20:50 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 19 Mar 92 19:20:50 MST Received: from by optima.cs.arizona.edu (4.1/15) id AB12498; Thu, 19 Mar 92 19:20:39 MST Received: from castle.edinburgh.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP id <10992-0@sun2.nsfnet-relay.ac.uk>; Wed, 18 Mar 1992 17:01:28 +0000 Received: from emas-a.ed.ac.uk by castle.ed.ac.uk id aa16668; 18 Mar 92 16:58 WET Date: 18 Mar 92 16:58:56 gmt From: R.J.Hare@edinburgh.ac.uk Subject: Matchhing of place names To: icon-group@cs.arizona.edu Message-Id: <18 Mar 92 16:58:56 gmt 320503@EMAS-A> Sender: "R.J.Hare" <@emas-a.edinburgh.ac.uk:R.J.Hare@edinburgh.ac.uk> I'm writing a program to extract map number and grid references from a gazeteer of place names. I want to allow for 'mis-spellings' on entering the place names. I am currently trying soundex as a 'fuzzy' matching procedure for this, but it is not working well, for example, 'Milhill' (a misspelling of Millhill) is turning up only 'Millwell' when doing a soundex match. Is anyone out there aware of any more sophisticated methods of doing this sort of thing? Thanks. Roger Hare. From icon-group-request Thu Mar 19 19:49:18 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 19 Mar 92 19:49:18 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA13569; Thu, 19 Mar 92 19:49:16 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA27989; Thu, 19 Mar 92 18:41:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Mar 92 07:41:35 GMT From: att!linac!uchinews!ellis!goer@ucbvax.berkeley.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: puzzle maker #3 Message-Id: <1992Mar11.074135.3834@midway.uchicago.edu> References: <1992Mar3.225850.28211@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Did anyone notice the two minor, but annoying bugs in puzzle maker #3 (posted a week or so ago)? If you noticed them, you get a cigar. The first is that some words occasionally got inserted l i k e that, instead of l i k e that. The other prevented certain attempts at creating intersecting words from working properly, and under certain rare circumstances brought about the formation of unusual sequences like "tortract" (from "tractor"). Sorry about these bugs. They are fixed in the most recent puzzle-maker version. If anyone wants this version, please contact me directly. My son's diligence in uncovering obscure bugs is what drives the re- vision process onward.... -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From TENAGLIA@mis.mcw.edu Fri Mar 20 05:07:28 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 20 Mar 92 05:07:28 MST Received: from ADM.MIS.MCW.EDU ([141.106.64.10]) by optima.cs.arizona.edu (4.1/15) id AA02759; Fri, 20 Mar 92 05:07:24 MST Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12865) id <01GHUV8YC7Z4BDJEEP@mis.mcw.edu>; Fri, 20 Mar 1992 06:08 CST Date: Fri, 20 Mar 1992 06:08 CST From: Chris Tenaglia - 257-8765 Subject: Re: Matchhing of place names To: R.J.Hare@edinburgh.ac.uk Cc: icon-group@cs.arizona.edu Message-Id: <01GHUV8YC7Z4BDJEEP@mis.mcw.edu> X-Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"R.J.Hare@edinburgh.ac.uk" X-Vms-Cc: IN%"icon-group@cs.arizona.edu" > From: IN%"R.J.Hare@edinburgh.ac.uk" 19-MAR-1992 20:28:57.50 > To: IN%"icon-group@cs.arizona.edu" > Subj: Matchhing of place names > I'm writing a program to extract map number and grid references from a > gazeteer of place names. I want to allow for 'mis-spellings' on entering the > place names. I am currently trying soundex as a 'fuzzy' matching procedure for > this, but it is not working well, for example, 'Milhill' (a misspelling of > Millhill) is turning up only 'Millwell' when doing a soundex match. > Is anyone out there aware of any more sophisticated methods of doing this sort > of thing? > Thanks. > Roger Hare. It almost sounds like a spell checker. If you could redirect the dictionary to point to your place table with some kind of spell check software. Well that may or may not be possible. I wrote I spelling test program for my daughter, that tries to guess which word was wrong. It works as long as the misspelling isn't too lexically different and the list of words aren't too lexically similar. Again, this might not be appropriate to your goals. I am including it, as it might give you other ideas. Good luck! Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu # # SPELLTEST.ICN 11/26/90 BY TENAGLIA # # THIS SIMPLE PROGRAM ADMINISTERS A SPELLING TEST. THE WORDS SHOULD BE LISTED # ONE PER LINE IN AN ANSWER FILE. THE TEACHER CAN ISSUE THE WORDS IN ANY ORDER # AS THE TRIES AND ANSWERS ARE FINALY SORTED AND COMPARED IN PARALLEL. THIS # SORT OF IMPLIES THAT THE WORDS SHOULD NOT BE TOO LEXICALLY ALIKE. THE GOOF # UPS AND SCORES ARE OUTPUT AT THE END OF THE TEST. THE ANSWER FILE IS PIPED # INTO STDIN. USAGE : ICONX SPELLTEST To: icon-group@cs.arizona.edu Subject: Recognizer Generator The February issue of the Icon Analyst had a good, in-depth article about a recognizer generator. The last couple of paragraphs in the article said, "Having posed these problems, we'll now have to solve them ourselves. The result may be in the Icon program library before this issue of the Analyst is published." I've looked through the library and not found a sign of the original program, much less the one that solves the problems mentioned in the article. Anybody know if such a program (or even the original) is forthcoming? o o cargo@escargot.cray.com \_____/ (612) 683-5591 /=O=O=\ _______ DDDD SSSS CCCC / ^ \ /\\\\\\\\ D D S C \ \___/ / /\ ___ \ D D SSS C \_ V _/ /\ /\\\\ \ D D S C \ \__/\ /\ @_/ / DDDDavid SSSS. CCCCargo \____\____\______/ From wgg@cs.ucsd.edu Fri Mar 20 17:48:46 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 20 Mar 92 17:48:46 MST Received: from ucsd.edu by optima.cs.arizona.edu (4.1/15) id AA18306; Fri, 20 Mar 92 17:48:43 MST Received: from odin.ucsd.edu by ucsd.edu; id AA28325 sendmail 5.64/UCSD-2.2-sun via SMTP Fri, 20 Mar 92 16:48:31 -0800 for icon-group@cs.arizona.edu Received: from gremlin.ucsd.edu by odin.ucsd.edu (4.1/UCSDPSEUDO.4) id AA23150 for icon-group@cs.arizona.edu; Fri, 20 Mar 92 16:48:30 PST Received: by gremlin.ucsd.edu (4.1/UCSDPSEUDO.4) id AA10028 for icon-group@cs.arizona.edu; Fri, 20 Mar 92 16:48:29 PST Date: Fri, 20 Mar 92 16:48:29 PST From: wgg@cs.ucsd.edu (William Griswold) Message-Id: <9203210048.AA10028@gremlin.ucsd.edu> To: icon-group@cs.arizona.edu Subject: converting troff bib information to bibtex (and vv) Any of you consummate Icon programs out there have a program for converting from the troff bib format to latex's bibtex format, or vice versa? Thanks. bill From icon-group-request Sat Mar 21 09:44:08 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 21 Mar 92 09:44:08 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA16774; Sat, 21 Mar 92 09:44:06 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA04848; Sat, 21 Mar 92 08:41:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Mar 92 02:32:58 GMT From: rudy.rutgers.edu!pilot.njin.net!gajarsky@rutgers.edu (Bob Gajarsky) Organization: Somewhere in Hoboken Subject: SURVEY:Please read, for scholastic purposes. Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Please note this message is being crossposted to a large number of groups. I am sorry for any inconvenience, but there are members of many newsgroups that I wish to reach , and this is the only way that I can accomplish this. Thank you for your understanding. ========================================================================= My name is Bob Gajarsky. I am a graduate level management student, and am conducting a survey for one of my classes. It would greatly help my studies if you could take a few minutes and complete the following survey. All results will be kept completely confidential, and your e-mail addresses will not be seen by anyone but me. Also, I am only looking for complete surveys from people who are actually out in the workplace as computer programmers, as opposed to those (like me) who are students. Additionally, I would request that only people who work in the United States reply to this. Thank you in advance for your responses. --------------------------- BEGINNING OF SURVEY ----------------------------- What city is your place of work? - (OPTIONAL) What company do you work at? - How many years of programming experience do you have? How many years of post-high school education have you had? How many computer languages do you know? If you program in any of the following languages, please check it: Ada APL Cobol C C++ Fortran Lisp Pascal How many software packages do you know how to use (ie. Lotus, MS-Works, etc.) 1-2 3-5 6-8 9-10 over 10 Do you know any databases? (Y/N) If so, which ones? On the average, how many hours does it take you to learn a application (ie. Word Processor, Graphics Package, etc.)? How do you prefer to learn new applications? More than one may be checked: Tutorials Videos Self-Instruction Other _________________________ Do you personally have a VCR? (Y/N) Does your workplace have a VCR? (Y/N) Have you ever used a video to learn an application before? (Y/N) If so, how would you rate it? (10 is an excellent experience, 1 is an awful experience) Based on your past experiences, would you be receptive to learning another application via video? (10 is very receptive; 1 is not receptive at all) If not, how receptive would you be to learning a application via video? (10 is very receptive; 1 is not receptive at all) How many hours of video would you be able to successfully watch for a specific application? How much would you or your company pay for the following: A) A 15 hour video that teaches how to generally work with databases, program in them, and utilize them. (Between 40$ and 150$) B) A 3 hour video that teaches a specific database, (Oracle, etc.) (Between 15$ and 75$). C) A packaged of both (A) and (B). (Between 50$ and 225$). Which systems do you have a familiarity with? VAX/VMS UNIX Macintosh IBM Compatible Other ------------------- END OF SURVEY --------------------------------- Thanks! - Bob Gajarsky From kohl@socrates.umd.edu Thu Mar 26 09:33:02 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 26 Mar 92 09:33:02 MST Message-Id: <9203261632.AA05499@optima.cs.arizona.edu> Received: from socrates.umd.edu by optima.cs.arizona.edu (4.1/15) id AA05499; Thu, 26 Mar 92 09:32:58 MST Received: by socrates.umd.edu (16.6/16.2) id AA02735; Thu, 26 Mar 92 11:31:33 -0500 From: John Kohl Subject: Windows 3.0 To: icon-group@cs.arizona.edu Date: Thu, 26 Mar 92 11:31:31 EST X-Mailer: ELM [version 2.3 PL11] A friend of mine is developing a game under Windows 3.0 using Microsoft's QuickC. We would like to use Icon for prototyping the computer playing the game. Icon is capable of calling and being called by C. (I haven't tried this yet.) Understandably, Icon hasn't been ported to Windows 3.0. With XIcon there is no serious reason to port. Is there a way to have to have a QuickC Windows 3 program invoke MS-DOS Icon as a subprogram? If so, how. Thanks, John Kohl kohl@socrates.umd.edu From cjeffery Thu Mar 26 11:40:15 1992 Received: from chuckwalla.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 26 Mar 92 11:40:15 MST Date: Thu, 26 Mar 92 11:40:13 MST From: "Clinton Jeffery" Message-Id: <9203261840.AA15783@chuckwalla.cs.arizona.edu> Received: by chuckwalla.cs.arizona.edu; Thu, 26 Mar 92 11:40:13 MST To: kohl@socrates.umd.edu Cc: icon-group@cs.arizona.edu In-Reply-To: John Kohl's message of Thu, 26 Mar 92 11:31:31 EST <9203261632.AA05499@optima.cs.arizona.edu> Subject: Windows 3.0 John Kohl, kohl@socrates.umd.edu, writes: > Understandably, Icon hasn't been ported to Windows 3.0. > With XIcon there is no serious reason to port. Well, there are "good" reasons to port to Windows 3.0, Macintosh, Amiga, etc. Icon runs on all these machines, but can't access the graphics and mouse capabilities on them. Unfortunately, this is not a matter of research. It is up to commercial implementors or dedicated users of each particular window system to add graphics access to Icon. X-Icon proves such a task can be done, but does not purport to be "complete" and implementors on other window systems are likely to add system-specific features. I am always interested in talking to people doing graphics access for Icon. Clint Jeffery From icon-group-request Sat Mar 28 22:05:59 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 28 Mar 92 22:05:59 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA21623; Sat, 28 Mar 92 22:05:55 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA24267; Sat, 28 Mar 92 21:03:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Mar 92 11:06:46 GMT From: mcsun!uknet!pcl!hcvec@uunet.uu.net (John Ditrolio) Organization: Polytechnic of Central London Subject: Tree Implementation Message-Id: <1992Mar24.110646.896@sun.pcl.ac.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu To whoever can help, I am trying to write a grammar checking program and I am intendingto set up a dictionary file with corresponding tokens for each word. Can anyone tell me what is the most efficient way of handling the large amount of data? I could possibly pull the contents of a dictionary file into a tree structure of some sort (maybe records) which I will need to access continuously. I've looked in the Icon "bible" (Icon Programming Language Manual) and I cannot see how I can implement a binary tree structure similar to that in C. Please can someone help ???? I am relatively new to Icon and so beg forgiveness for my stupidity. John Ditrolio. From janpeter@mpi.kun.nl Sun Mar 29 07:20:04 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 29 Mar 92 07:20:04 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA06924; Sun, 29 Mar 92 07:19:58 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA10682; Sun, 29 Mar 92 16:20:50 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA03440; Sun, 29 Mar 92 16:18:53 +0200 Date: Sun, 29 Mar 92 16:18:53 +0200 From: Jan Peter de Ruiter Message-Id: <9203291418.AA03440@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu, mcsun!uknet!pcl!hcvec@uunet.uu.net Subject: Re: Tree Implementation Hi, I'm new to the ICON group as well, but I think I might have a useful suggestion for the representation of a lexicon (the problem that John Ditrolio has in his parser). The problem he stated has not much to do with computer languages, but with representation techniques in general. Once a useful representation is decided upon, implementing it in ICON will probably be not very hard, given the tremendous flexibility of ICON data structures. One of the most efficient techniques for "lexical lookup" is the use of the so called "TRIE" data structure [Fredkin, 1960]. I'll give a reference below, but the basic idea is the following: Suppose (for simplicity) that we want to store the items "apple", "ape", "an" and "bee". The trie then looks like this: [ROOT] / \ [a] [b] / \ \ [p] [n]* [e] / \ \ [p] [e]* [e]* / [l] / [e]* The algorithm to build and search a TRIE is not very complicated, so I won't waste space and time on that. I use this representation for fast lookup in large lexical databases, but i've written that program in C. If any one of you has an implementation of 'TRIES' in ICON, I would be interested!. REFERENCE: Fredkin, E.H. 1960. Trie memory, CACM 3:9 (sept), 490-500. Jan Peter de Ruiter Netherlands (Europe) email: janpeter@mpi.kun.nl From janpeter@mpi.kun.nl Sun Mar 29 11:13:33 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 29 Mar 92 11:13:33 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA12070; Sun, 29 Mar 92 11:13:28 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA11456; Sun, 29 Mar 92 20:14:21 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA03709; Sun, 29 Mar 92 20:12:24 +0200 Date: Sun, 29 Mar 92 20:12:24 +0200 From: Jan Peter de Ruiter Message-Id: <9203291812.AA03709@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu Subject: RE: tree implementation. Hi, I'm new to the ICON group as well, but I think I might have a useful suggestion for the representation of a lexicon (the problem that John Ditrolio has in his parser). The problem he stated has not much to do with computer languages, but with representation techniques in general. Once a useful representation is decided upon, implementing it in ICON will probably be not very hard, given the tremendous flexibility of ICON data structures. In chapter 15 of the "Bible" (second edition) a very clear explanation can be found on how to implement trees in ICON. One of the most efficient techniques for "lexical lookup" is the use of the so called "TRIE" data structure [Fredkin, 1960]. I'll give a reference below, but the basic idea is the following: Suppose (for simplicity) that we want to store the items "apple", "ape", "an" and "bee". The trie then looks like this: [ROOT] / \ [a] [b] / \ \ [p] [n]* [e] / \ \ [p] [e]* [e]* / [l] / [e]* One can also choose to explicitly store whole items at the 'leaves' instead of a marker (like '*') but that is wasting storage. The algorithm to build and search a TRIE is not very complicated, so I won't waste space and time on that. I use this representation for fast lookup in large lexical databases, but I've written that program in C. If any one of you has an implementation of 'TRIES' in ICON, I would be interested!. REFERENCE: Fredkin, E.H. 1960. Trie memory, CACM 3:9 (sept), 490-500. Jan Peter de Ruiter Netherlands (Europe) email: janpeter@mpi.kun.nl From gmt Sun Mar 29 18:22:10 1992 Received: from owl.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 29 Mar 92 18:22:10 MST Date: Sun, 29 Mar 92 18:22:14 MST From: "Gregg Townsend" Message-Id: <9203300122.AA01012@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Sun, 29 Mar 92 18:22:14 MST To: icon-group@cs.arizona.edu, mcsun!uknet!pcl!hcvec@uunet.uu.net Subject: Re: Tree Implementation I think some people can't see the forest for the trees (groan). While you can certainly implement tree structures in Icon, the original question asked for the best way to hold a dictionary for use in a grammar checking program. For that, a table indexed by words is the obvious solution. Internally, it's implemented efficiently by a hash table. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From icon-group-request Tue Mar 31 01:01:04 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 31 Mar 92 01:01:04 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA07738; Tue, 31 Mar 92 01:01:01 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA13393; Mon, 30 Mar 92 23:45:44 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 30 Mar 92 15:45:57 GMT From: mcsun!unido!infbssys!neitzel@uunet.uu.net (Martin Neitzel) Organization: Inst. f. Informatik, TU Braunschweig, FRG Subject: old startup header in icode files Message-Id: <1992Mar30.154557.6906@ips.cs.tu-bs.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I just installed Icon (v8) on a second architecture at our site. Which made me ask myself: Would icode files with old v7-style headers give me architecure independent executables? (For those who need to know: icode files were made executable by directing the unix kernel with the first line '#!/usr/local/bin/iconx' to the proper interpreter for the rest of the file, ie. the icode. Given that there no troubles due to, say, byte sex, you could develop and share icon programs across architectures.) My questions to the experts: Would #defining NoHeader help? And: why were the new machine specific headers introduced, anyway? Martin Neitzel From janpeter@mpi.kun.nl Tue Mar 31 06:13:28 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 31 Mar 92 06:13:28 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA19607; Tue, 31 Mar 92 06:13:20 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA02448; Tue, 31 Mar 92 14:27:07 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA02399; Tue, 31 Mar 92 14:25:20 +0200 Date: Tue, 31 Mar 92 14:25:20 +0200 From: Jan Peter de Ruiter Message-Id: <9203311225.AA02399@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu Subject: ICON-C INTERFACE I have as yet been unable to figure out how to call C from ICON. Speci- fically, I don't know how to build c modules that are callable. Of course the infamous document tr90-8.doc is in my possession, but it is beyond my intellectual capacity to figure out from that document how to do it. Is there any document available that explains the ICON->C interface (I don't care about C->ICON, unless I need that one for ICON->C) to someone who can program in ICON and C, but has no knowledge of how icon is implemented? Greetings, Jan Peter de Ruiter email: janpeter@mpi.kun.nl From ralph Tue Mar 31 06:47:07 1992 Date: Tue, 31 Mar 92 06:47:07 MST From: "Ralph Griswold" Message-Id: <9203311347.AA25651@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Tue, 31 Mar 92 06:47:07 MST To: icon-group@cs.arizona.edu, janpeter@mpi.kun.nl Subject: Re: ICON-C INTERFACE Unfortunately, you cannot, except in the most trivial cases, call C functions from Icon without knowing something about both Icon and C data structures. The two have different representations of data, and it's necessary to convert between them. TR90-8 lists the functions that are available for conversion and gives examples. Admittedly, it's not trivial. But it's the only interface available at the moment. By the way, it is not necessary to know anything about calling Icon from C to call C from Icon; the two facilities are independent. Ralph Griswold / Department of Computer Science The University of Arizona / Tucson, AZ 85721 ralph@cs.arizona.edu / uunet!arizona!ralph voice: 602-621-6609 / fax: 602-621-9618 From mff@princeton.edu Tue Mar 31 14:39:32 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 31 Mar 92 14:39:32 MST Received: from Princeton.EDU by optima.cs.arizona.edu (4.1/15) id AA14201; Tue, 31 Mar 92 14:39:29 MST Received: from fs.Princeton.EDU by Princeton.EDU (5.65b/2.88/princeton) id AA14036; Tue, 31 Mar 92 16:39:26 -0500 Received: from cs.Princeton.EDU (elan.Princeton.EDU) by fs.Princeton.EDU (4.0/1.105) id AA22299; Tue, 31 Mar 92 16:39:24 EST Received: by cs.Princeton.EDU (5.57/1.105) id AA05809; Tue, 31 Mar 92 16:39:23 -0500 Date: Tue, 31 Mar 92 16:39:23 -0500 From: Mary F. Fernandez Message-Id: <9203312139.AA05809@cs.Princeton.EDU> To: icon-group@cs.arizona.edu Subject: Interpreting expressions in strings Version 8 allows the application of an operator represented by a string (e.g. "*"(2,4) === 2*4), but it does not appear to interpret operands which are represented as string (e.g. "*(2,4)" is not 2*4). I thought there was a facility for interpreting an expression read as input. Does this exist? Is it built-in? If not, if you have such an interpreter, could you post it? Thanks, Mary Fernandez mff@cs.princeton.edu Dept. of Computer Science Princeton University 35 Olden St. Princeton, NJ 08544-2087 From ralph Wed Apr 1 17:02:02 1992 Date: Wed, 1 Apr 92 17:02:02 MST From: "Ralph Griswold" Message-Id: <9204020002.AA17860@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Wed, 1 Apr 92 17:02:02 MST To: icon-group Subject: Version 8.6 of Icon for UNIX platforms Version 8.6 of Icon is now available for UNIX platforms. Both the interpreter and the optimizing compiler are included. Version 8.6 adds a few functions to Icon as described in Icon Newsletter 38 and provides support for keyboard functions for some UNIX platforms. The most significant language extension in Version 8.6, however, is the addition of graphics capabilities for platforms that have X Window facilities. The UNIX distribution includes source code, documentation in machine-readable form, the Icon program library, and support for variant translators. The new version is available via anonymous FTP from cs.arizona.edu. cd /icon/packages/unix and get unix_tar.Z in binary (image) mode. Version 8.6 of Icon for UNIX also is available on magnetic media together with printed documentation. Tapes and cartridges can be ordered as described in recent Icon Newsletters. It also is available on three 1.44MB MS-DOS format diskettes. The price for diskettes is $25. Add $5 for shipping to countries other than the United States, Canada, and Mexico. Direct any questions about Version 8.6 of Icon for UNIX to icon-project@cs.arizon.edu Ralph Griswold / Department of Computer Science The University of Arizona / Tucson, AZ 85721 ralph@cs.arizona.edu / uunet!arizona!ralph voice: 602-621-6609 / fax: 602-621-9618 From ms@informatik.uni-hannover.dbp.de Thu Apr 2 06:48:38 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Apr 92 06:48:38 MST Received: from ixgate.gmd.de by optima.cs.arizona.edu (4.1/15) id AA24102; Thu, 2 Apr 92 06:48:02 MST Received: by ixgate.gmd.de id AA14751; Thu, 2 Apr 92 15:48:08 +0200 Date: 2 Apr 92 9:57 From: "(Michael Sperber)" Message-Id: Subject: Icon 8.5 /386 problems Apparently-To: icon-group@cs.arizona.edu RFC-822-HEADERS: Return-Path: <@CDC2.RRZN.UNI-HANNOVER.DE:ms@informatik.uni-hannover.de> To: @CDC2:icon-group@cs.arizona.edu ================== I've been playing around with the 386 version of Icon 8.5 (the one out of Intel's Code Builder). I've written a disk cataloguing system for MSDOS that can look into compressed archives (LHARC, ARJ, PKZIP, PKARC). It shells out to external programs both to get the directory contents and the archive contents. However, bizarre non-reproducible things happen to my output files after any external program has been called (looks like memory dump right in the middle of things). Has anyone else encountered problems like that? Also, Icon/386 doesn't seem to work with GNUish make 3.58. Any comments? Chipsy Sperber :-> ms@wega.informatik.uni-hannover.de In case anyone is interested in the cataloguing system, please mail me. It's free for anyone. From kwalker Thu Apr 2 13:58:08 1992 Received: from ponderosa.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Apr 92 13:58:08 MST Date: Thu, 2 Apr 92 13:58:07 MST From: "Kenneth Walker" Message-Id: <9204022058.AA03343@ponderosa.cs.arizona.edu> Received: by ponderosa.cs.arizona.edu; Thu, 2 Apr 92 13:58:07 MST To: icon-group Subject: Re: old startup header in icode files I didn't see anyone respond to this, so I'll give it a try: > Date: 30 Mar 92 15:45:57 GMT > From: mcsun!unido!infbssys!neitzel@uunet.uu.net (Martin Neitzel) > > I just installed Icon (v8) on a second architecture at our site. > Which made me ask myself: Would icode files with old v7-style headers > give me architecure independent executables? > > (For those who need to know: icode files were made executable by > directing the unix kernel with the first line '#!/usr/local/bin/iconx' > to the proper interpreter for the rest of the file, ie. the icode. > Given that there no troubles due to, say, byte sex, you could develop > and share icon programs across architectures.) > > My questions to the experts: Would #defining NoHeader help? And: why > were the new machine specific headers introduced, anyway? If the C data types, including some structs, used in the implemention of Icon (or at least those stored in the icode file) are implemented the same on both systems, it should work. Defining NoHeader will force you to explicitly call iconx. Here is an untested suggestion: change MaxHdr in h/define.h to 24 (double check this number, it must match the size of array changed in the next step) change the contents of the iconxhdr array in icont/hdr.h to "#!/usr/local/bin/iconx\n" change icont/Makefile so it does not rebuild hdr.h from ixhdr.c rebuild icont and iconx Good luck. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621-4252 kwalker@cs.arizona.edu uunet!arizona!kwalker From cjeffery Thu Apr 2 17:06:12 1992 Received: from chuckwalla.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Apr 92 17:06:12 MST Date: Thu, 2 Apr 92 17:06:11 MST From: "Clinton Jeffery" Message-Id: <9204030006.AA10942@chuckwalla.cs.arizona.edu> Received: by chuckwalla.cs.arizona.edu; Thu, 2 Apr 92 17:06:11 MST To: icon-group In-Reply-To: "Kenneth Walker"'s message of Thu, 2 Apr 92 13:58:07 MST <9204022058.AA03343@ponderosa.cs.arizona.edu> Subject: old startup header in icode files Martin Neitzel recently asked why #!/usr/local/bin/iconx was dropped in favor of the current scheme. I can't speak for the people who made this decision, but I would note that the #! syntax for redirecting "shell scripts" to the appropriate interpreter is not portable and just doesn't work on a lot of UNIX systems. On the other hand, a VERY plain shell script that asks to run iconx on the "shell script" itself ought to be fairly portable if done correctly. I would love to see this if anyone did it well. As another aside, the executable headers we are using now do various interesting things before calling iconx, such as looking at environment variables and allowing patches (in Version 8.5 and above) to override the default name of iconx that icont uses. Martin's questions also raise the possibility of a truly portable icode file format that would run unmodified on *any* iconx. This is in principle not very difficult and should be implemented by someone who needs it, or a commercial Icon implementor who wants to add value to their product. Icode files already contain interesting offset-based instructions that modify themselves into direct pointer-based instructions the first time they are executed. The same approach could be applied to the job of making icode portable, adding extra instructions for things like architecture-neutral integers that convert themselves into machine integers the first time they are executed. Network-knowledgable hackers would see this as simply a matter of adding some calls to ntohl() to the interpreter, and it likely wouldn't slow performance significantly. From alex@laguna.metaphor.com Thu Apr 2 17:55:46 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 2 Apr 92 17:55:46 MST Received: from relay.metaphor.com by optima.cs.arizona.edu (4.1/15) id AA24380; Thu, 2 Apr 92 17:55:43 MST Received: from laguna.Metaphor.COM by relay.metaphor.com (4.1/SMI-4.1) id AA07769; Thu, 2 Apr 92 16:52:37 PST Received: by laguna.Metaphor.COM (4.1/SMI-4.0) id AA07885; Thu, 2 Apr 92 16:56:13 PST Date: Thu, 2 Apr 92 16:56:13 PST From: alex@laguna.metaphor.com (Bob Alexander) Message-Id: <9204030056.AA07885@laguna.Metaphor.COM> To: icon-group@cs.arizona.edu Subject: Re: old startup header in icode files > On the other hand, a VERY plain shell script that asks to run iconx on > the "shell script" itself ought to be fairly portable if done correctly. > I would love to see this if anyone did it well. Your request granted: #!/bin/sh exec "${ICONX-iconx}" "$0" "$@" How "well" this is done is probably a subject for debate! The Icon Newsletter recently had an article on alternative iconx headers (written by me). Included in the article is this shell script approach. The text of the article is attached. This article was printed with a disclaimer stating that the #! approach was once used for icode files, but was discarded because of numerous problems. I think the worst was that the path length is quite limited -- something like 32 characters in Sun UNIX -- which caused a support headache for the Icon Project. Wierdly, if the #! line is omitted from this script (in sun4 UNIX, at least) it won't work. With the #! line, $0 produces the full path name of the command used to invoke the script (which is the icode file name); without the #! only the command name is substituted. The full path is necessary for the script to be able to find the icode file (i.e. itself) if it does not reside in the current working directory. This subtle behavior difference is a likely source of incompatiblilties among UNIX variants. On sun3 and sun4 systems, each icode file is over 10K smaller using this approach! That makes a big difference to me since I have over 100 misc Icon programs around -- a total of over 1M saved. Anyway, header fans, enjoy: -- Bob Alexander Metaphor Computer Systems (415) 961-3600 x751 alex@metaphor.com ====^=== Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex ============================================================ Smaller Icode Files for UNIX-based Icon Implementations ------------------------------------------------------- In this article, a method is discussed that can decrease the size of Icon icode files (the "executable" files produced by icont). The techniques discussed here apply only to Icon implementations that support the "direct execution" feature. Implementations that do not support direct execution, such as MS-DOS, cannot benefit from these techniques. In particular, this discussion applies to UNIX implementations, but the techniques may apply to other platforms (they are currently used in the standard Macintosh Programmer's Workshop implementation). An icode file consists of a header part and an icode part. The icode part contains the operations and data specifications that make up an Icon program. The header is the part that allows the icode file to be directly executable as a command, without having to type "iconx". +---------------+ Beginning of icode file | | | header | | | +---------------+ | | | | | icode | | | | | +---------------+ End of icode file In UNIX implementations of Icon, the header takes the form of a small program that invokes the iconx interpreter to execute the icode part of itself. In some versions of UNIX, the small header program ends up being disturbingly large once all the needed library code is linked in (something like 16K bytes on a Sun 3!). Since the Icon program is contained in the icode part, the header is just an overhead part of the file. For that reason, and since the header is replicated in each icode file, it is desirable that the header be as small as possible. This article discusses some alternative approaches to the header that can result in significantly smaller icode files. The header program as implemented in the current Icon UNIX distribution is a C program. The header itself is the executable code produced by the C compiler and linker. Two other approaches are examined here: (1) using UNIX's shell-invocation format in place of a header, and (2) using a shell script as a header. Shell Invocation Line Approach ------------------------------ A "shell" program to execute a script file can be specified in UNIX by beginning the file with a line of the following format: #!shell-command-name When such a file MyScript is executed as a command (it must have execute permission), the system behaves as if the following command had been issued: shell-command-name MyScript Viewing iconx (the Icon executor program) as a "shell" that executes icode files, the header can consist of a #! line instead of executable machine code. #!/usr/icon/v8/bin/iconx .........icode.......... Advantages: - Very small - Fast execution Disadvantages: - Length of iconx file path name is limited (max of 32 characters in SunOS) - Doesn't fully support the documentation (e.g. doesn't recognize the ICONX environment variable) - Requires full path specification of the iconx interpreter (no variables permitted) Shell Script Approach --------------------- A shell script as a header can match the documentation, but is not as streamlined as the Shell Invocation approach. However, it is the solution that I have adopted, and I've found it to be quite satisfactory in my SPARCstation 2 environment. Advantages: - Small - Fully lives up to the documented behavior - Finds iconx interpreter in PATH directories Disadvantages: - Not quite as fast as the #! method I wanted the script to be for the Bourne shell, since that is the ubiquitous shell available with all UNIX systems. Here is a Bourne shell version that does the job nicely (thanks to Gregg Townsend for suggesting this elegant and compact solution): #!/bin/sh exec "${ICONX-iconx}" "$0" "$@" If the ICONX shell variable is undefined, the iconx executable is located via the current PATH variable. A small variation to this script could point to an iconx executor in a specific hard-wired location; change the second line to: exec "${ICONX-/usr/icon/v8/bin/iconx}" "$0" "$@" Be warned: the first line, "#!/bin/sh", MUST BE PRESENT for this script to work properly under all circumstances. Even though UNIX will default to executing the Bourne shell if no "#!" line is present, the shell behaves somewhat differently depending on whether or not the "#!" line is included. Even if you prefer another shell for interactive command entry (such as the C or Korn shell), usage of the above Bourne shell header presents no conflict. However, just for fun, the following slightly longer C-shell script could be used and is functionally equivalent: #!/bin/csh -f if ($?ICONX) set ICONX=iconx exec "$ICONX" "$0" $*:q Note the -f option provided to csh in the first line of the C shell script. The -f option (for "fast") bypasses the usual act of executing the .cshrc startup script, making it quicker. How do I convert my Icon system to use small headers? ----------------------------------------------------- The required steps are as follows: 1. Modify the icont makefile to omit construction of the C header. 2. Hand-code a .h file for the script header. 3. Reduce the space reserved in each output icode file for the header. The header that is copied to every icode file resides in the the translator/linker tool, icont. The makefiles provided with the Icon distribution compile the C program that comprises the header portion of normal icode files. A utility program is then executed that converts the resulting executable machine code to a .h text file that is #included in icont. The makefile for icont (in the src/icont directory) should be modified: - omit the compile and link of the C header (ixhdr.c -> ixhdr.o -> iconx.hdr) - omit the conversion of the resulting executable to a .h file (iconx.hdr -> hdr.h) Then a hand-coded hdr.h file is constructed containing the desired script; e.g. (note that all lines in this example must be flush against the left margin): static char iconxhdr[MaxHdr+1] = "\ #!/bin/sh\n\ exec \"${ICONX-iconx}\" \"$0\" \"$@"\n"; Be careful; if you didn't modify your makefile correctly, the build could clobber your painstakingly hand-written hdr.h file. Finally, adjust the size of the area reserved for the header in the file src/h/define.h. #define MaxHdr 256 The script I use (the example above) is fewer than 100 characters, but I specify a size of 256 to allow room for, dare I say, future expansion (for example, adding commands to set the region size environment variables). It's still a lot smaller than 16K! Now, rebuild icont, and enjoy smaller icode files! From janpeter@mpi.kun.nl Fri Apr 10 04:26:27 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 10 Apr 92 04:26:27 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA29573; Fri, 10 Apr 92 04:26:20 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA08740; Fri, 10 Apr 92 13:27:26 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA20777; Fri, 10 Apr 92 13:25:20 +0200 Date: Fri, 10 Apr 92 13:25:20 +0200 From: Jan Peter de Ruiter Message-Id: <9204101125.AA20777@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu Subject: ICON debugger Is an interactive debugger available for ICON? Sometimes, playing around with &trace and putting in al lot of write() statements just is not convenient anymore. I gather, people who test and debug large ICON programs must have some means to help their debugging. I would be interested to know how other people debug their ICON programs. Jan Peter de Ruiter Max Planck Institute for Psycholinguistics EMAIL: janpeter@mpi.kun.nl From icon-group-request Sat Apr 11 10:58:43 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 11 Apr 92 10:58:43 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA08205; Sat, 11 Apr 92 10:58:41 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA17253; Sat, 11 Apr 92 10:46:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 92 20:05:49 GMT From: micro-heart-of-gold.mit.edu!wupost!uwm.edu!linac!convex!convex!tchrist@bloom-beacon.mit.edu (Tom Christiansen) Organization: CONVEX Realtime Development, Colorado Springs, CO Subject: Re: should I use ICON for a specific problem ? Message-Id: <1992Apr9.200549.10279@news.eng.convex.com> References: <1992Apr6.163124.15685@midway.uchicago.edu>, , <1992Apr9.045725.15554@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu From the keyboard of goer@midway.uchicago.edu: : :There's no reason to worry about flames here. PERL is a system adminis- :trator's tool par excellance, with a C interface that's actually much bet- :ter than Icon's. Icon is a much cleaner and more disciplined language, :with a lot more options for control and data structures, coexpressions, :and what not. I find PERL a mess, but that's just me. Probably I just :don't know it well enough. Nope, you're right -- in more ways than I care to enumerate, it *is* a mess. The amazing thing is how well it gets the job done anyway. --tom From icon-group-request Sat Apr 11 15:14:43 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 11 Apr 92 15:14:43 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA15023; Sat, 11 Apr 92 15:14:36 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA26737; Sat, 11 Apr 92 15:04:00 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 92 12:50:13 GMT From: mailer.cc.fsu.edu!sun13!sun8.scri.fsu.edu!nall@gatech.edu (John Nall) Organization: SCRI, Florida State University Subject: Re: should I use ICON for a specific problem ? Message-Id: <8139@sun13.scri.fsu.edu> References: <1992Apr6.163124.15685@midway.uchicago.edu>, , <1992Apr9.045725.15554@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr9.045725.15554@midway.uchicago.edu> goer@midway.uchicago.edu writes: [ ... stuff deleted ... ] > >There's no reason to worry about flames here. PERL is a system adminis- >trator's tool par excellance, with a C interface that's actually much bet- >ter than Icon's. Icon is a much cleaner and more disciplined language, >with a lot more options for control and data structures, coexpressions, >and what not. I find PERL a mess, but that's just me. Probably I just >don't know it well enough. It is so refreshing to see a well reasoned discussion of ICON vs PERL that I can't resist the temptation to say "WELL PUT!!" I agree with everything that Richard said, completely, even to the part of "I find PERL a mess, but that's just me". But it is certainly a gawdawful powerful tool in the hands of those who can deal with it :-) John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, FL 32306 "Disclaimer: A world which requires disclaimers has too many lawyers." From icon-group-request Sun Apr 12 06:18:10 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 12 Apr 92 06:18:10 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA12340; Sun, 12 Apr 92 06:18:07 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA01492; Sun, 12 Apr 92 06:03:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Mar 92 11:06:46 GMT From: mcsun!uknet!pcl!hcvec@uunet.uu.net (John Ditrolio) Organization: Polytechnic of Central London Subject: Tree Implementation Message-Id: <1992Mar24.110646.896@sun.pcl.ac.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu To whoever can help, I am trying to write a grammar checking program and I am intendingto set up a dictionary file with corresponding tokens for each word. Can anyone tell me what is the most efficient way of handling the large amount of data? I could possibly pull the contents of a dictionary file into a tree structure of some sort (maybe records) which I will need to access continuously. I've looked in the Icon "bible" (Icon Programming Language Manual) and I cannot see how I can implement a binary tree structure similar to that in C. Please can someone help ???? I am relatively new to Icon and so beg forgiveness for my stupidity. John Ditrolio. From icon-group-request Sun Apr 12 08:03:22 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 12 Apr 92 08:03:22 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA14353; Sun, 12 Apr 92 08:03:19 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA05256; Sun, 12 Apr 92 07:57:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 92 17:39:51 GMT From: micro-heart-of-gold.mit.edu!wupost!csus.edu!netcomsv!mork!nagle@bloom-beacon.mit.edu (John Nagle) Organization: Netcom - Online Communication Services (408 241-9760 guest) Subject: Re: lang comparison (not war) Message-Id: <0#tj+5g.nagle@netcom.com> References: <1992Apr7.212144.13007@xilinx.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu holen@xilinx.com (Victor A. Holen ) writes: >Is there somewhere (book, ftp, ...) a reasonably objective >comparison of icon with eiffel with a few other (perhaps c++, >smalltalk, mainsail..). I haven't heard much about Icon in years. It was intended as a replacement for Snobol, and perhaps as an alternative to the horrible "string languages" ("awk", "sed") that come with UNIX. Icon offers Snobol-like matching with C-like syntax. It's intended for a different class of applications than is Eiffel. John Nagle From ames.arc.nasa.gov!amdcad!cpsolv!para!john@hellgate.utah.edu Mon Apr 13 21:48:50 1992 Received: from univers.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 13 Apr 92 21:48:50 MST Received: from hellgate.utah.edu by univers.cs.arizona.edu; Mon, 13 Apr 92 21:48:49 MST Received: from ames.arc.nasa.gov by hellgate.utah.edu (5.65/utah-2.19s-cs) id AA21107; Mon, 13 Apr 92 22:48:34 -0600 Received: from amdcad.UUCP by ames.arc.nasa.gov (5.65c/1.21) with UUCP id AA11010 for hellgate.utah.edu!arizona!icon-group on Mon, 13 Apr 1992 21:48:27 -0700 Received: from cpsolv.UUCP by amd.com (5.65c/AMD-1.27) with UUCP id AA08329 for ames!hellgate.utah.edu!arizona!icon-group; Mon, 13 Apr 1992 21:46:05 -0700 Received: by cpsolv.CPS.COM (smail2.5rhg) id AA10278; Mon, 13 Apr 1992 20:44:52 CDT Received: by para.UUCP (smail2.5rhg) id AA01808; Mon, 13 Apr 1992 20:37:17 CST Subject: unsub To: icon-group@cs.arizona.edu Date: Mon, 13 Apr 92 20:37:13 CST From: John O'Brien X-Mailer: ELM [version 2.3 PL6] Message-Id: <920413203715.AA01804@para.UUCP> Thanks for the mail the last few months. I don't need this list as I have regained USENET access. See you on the net! john@para.cps.com also jdo@genco.com From cliff Wed Apr 15 09:08:42 1992 Received: from javelina.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 15 Apr 92 09:08:42 MST Date: Wed, 15 Apr 92 09:08:42 MST From: "Cliff Hathaway" Message-Id: <9204151608.AA28692@javelina.cs.arizona.edu> Received: by javelina.cs.arizona.edu; Wed, 15 Apr 92 09:08:42 MST To: icon-group Subject: address for administrative matters If you wish to subscribe/unsubscribe/change your address for the icon-group mailing list, the correct "place" to send it is: icon-group-request@cs.arizona.edu This will ensure that it receives prompt attention, and keep it from being broadcast out to everyone else on the list, and the comp.lang.icon newsgroup, too! Thanks. Cliff Hathaway Dept. of Computer Science (602)621-4291 University of Arizona cliff@cs.arizona.edu (internet) Tucson, Ariz. 85721 {cmcl2,noao,uunet}!arizona!cliff (uucp) From icon-group-request Thu Apr 16 14:25:05 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 16 Apr 92 14:25:05 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA21088; Thu, 16 Apr 92 14:25:02 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA23155; Thu, 16 Apr 92 14:13:06 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Apr 92 16:43:14 GMT From: micro-heart-of-gold.mit.edu!wupost!uwm.edu!linac!uchinews!ellis!goer@bloom-beacon.mit.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: features from Icon Language in lisp Message-Id: <1992Apr15.164314.8991@midway.uchicago.edu> References: <1992Apr14.173407.28762@adobe.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr14.173407.28762@adobe.com> yost@adobe.COM writes: >My first exposure to a seriously higher level language than C >was Icon. (Thank you Ralph Griswold, et al.) Finally, I got around >to learning lisp, where I wish I had started, and found that much >of what I liked about Icon (automatic storage, everything is an >expression, lists, tables, success->value/failure->nil) was there >in Common Lisp with a (shall we say) different syntax (and a whole >lot more, of course). > >Has anyone implemented any other of our favorite iconish things >in Common Lisp or Scheme? Like goal-directed evaluation, >string scanning, ... ? Personally, I feel good about Common LISP. It's even more bloated than Icon, though, and people who are really into clean LISP dialects seem to prefer Scheme. LISP, of course, isn't object-oriented (yes, another level of indirection that seems to be the rage these days). LISP people are always quick to point out that you can do object-oriented pro- gramming in LISP, but this is also true of C, Pascal, or even assembler. The bottom line, I guess, is that we have to be bi- or better yet tri- lingual, if not quadrilingual+ (e.g. Icon, C, LISP, and perhaps a func- tional or object-oriented language, and PERL, sed, awk, etc.). You'll never get into AI (or Emacs :-)) without LISP, and you'll never run any thing in real time without C. You won't get elegant string scanning outside of Icon. You won't get your system adminstration work done un- less you can do shell and awk/sed programming (or PERL). My gut feeling is that you'll be better off using Icon and LISP, Dave, when either is appropriate. -- -Richard L. Goerwitz goer%ellis@uchicago.bitnet goer@ellis.uchicago.edu rutgers!oddjob!ellis!goer From robert@hpfcase.sde.hp.com Thu Apr 16 14:53:24 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 16 Apr 92 14:53:24 MST Received: from hpfcla.fc.hp.com by optima.cs.arizona.edu (4.1/15) id AA21778; Thu, 16 Apr 92 14:53:19 MST Received: from hpfcbig.sde.hp.com by hpfcla.fc.hp.com with SMTP (15.11.1.6/15.5+IOS 3.20) id AA05338; Thu, 16 Apr 92 15:52:17 -0600 Received: from hpfcnml.sde.hp.com by hpfcbig.sde.hp.com with SMTP (16.6/15.5+IOS 3.12) id AA23657; Thu, 16 Apr 92 15:52:48 -0600 Received: by hpfcase.sde.hp.com (16.6/15.5+IOS 3.12) id AA26026; Thu, 16 Apr 92 15:52:46 -0600 From: Robert Heckendorn Message-Id: <9204162152.AA26026@hpfcase.sde.hp.com> Subject: Re: features from Icon Language in lisp To: micro-heart-of-gold.mit.edu!wupost!uwm.edu!linac!uchinews!ellis!goer@bloom-beacon.mit.edu (Richard L. Goerwitz) (Richard L. Goerwitz) Date: Thu, 16 Apr 92 15:52:44 MDT Cc: icon-group@cs.arizona.edu In-Reply-To: <1992Apr15.164314.8991@midway.uchicago.edu>; from "Richard L. Goerwitz" at Apr 15, 92 4:43 pm Physical-Location: Mailer: Elm [revision: 66.25] > In article <1992Apr14.173407.28762@adobe.com> yost@adobe.COM writes: > >My first exposure to a seriously higher level language than C > >was Icon. (Thank you Ralph Griswold, et al.) Finally, I got around > >to learning lisp, where I wish I had started, and found that much > >of what I liked about Icon (automatic storage, everything is an > >expression, lists, tables, success->value/failure->nil) was there > >in Common Lisp with a (shall we say) different syntax (and a whole > >lot more, of course). > > > >Has anyone implemented any other of our favorite iconish things > >in Common Lisp or Scheme? Like goal-directed evaluation, > >string scanning, ... ? I haven't done this yet, but I have thought about it. I think it is an excellent idea. Lisp is a *tremendously* flexible language and adapts well to having layered systems added into it without scrambling the syntax. (It helps that the syntax is simplistic :-)) The CLOS OO extensions are an example of how far you can go. It is great to add on systems to LISP. Go for it! > Personally, I feel good about Common LISP. It's even more bloated than > Icon, though, and people who are really into clean LISP dialects seem > to prefer Scheme. LISP, of course, isn't object-oriented (yes, another There is CLOS for OO LISP. This is a fantastical [sic] OO package. > level of indirection that seems to be the rage these days). LISP > people are always quick to point out that you can do object-oriented pro- > gramming in LISP, but this is also true of C, Pascal, or even assembler. I think it is almost debateable if C++ is OO. :-P > The bottom line, I guess, is that we have to be bi- or better yet tri- > lingual, if not quadrilingual+ (e.g. Icon, C, LISP, and perhaps a func- > tional or object-oriented language, and PERL, sed, awk, etc.). You'll > never get into AI (or Emacs :-)) without LISP, and you'll never run any > thing in real time without C. You won't get elegant string scanning > outside of Icon. You won't get your system adminstration work done un- > less you can do shell and awk/sed programming (or PERL). > > My gut feeling is that you'll be better off using Icon and LISP, Dave, > when either is appropriate. My feeling is that Lisp offers a great playground for experimenting with new ideas in programming functionality. Note that I say functionality and not syntax. If you want to have your cake and eat it to, build a package for the Icon features you like in Lisp and play with it. You may be able to take the knowledge back with you to Icon and suggest changes in the language. Coming up with as elegant an expression in Lisp for the icon expressions may be a little more difficult. Robert Heckendorn robert@fc.sde.hp.com > -Richard L. Goerwitz goer%ellis@uchicago.bitnet > goer@ellis.uchicago.edu rutgers!oddjob!ellis!goer From callas@eris.enet.dec.com Thu Apr 16 15:07:56 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 16 Apr 92 15:07:56 MST Received: from enet-gw.pa.dec.com by optima.cs.arizona.edu (4.1/15) id AA22285; Thu, 16 Apr 92 15:05:37 MST Received: by enet-gw.pa.dec.com; id AA01193; Thu, 16 Apr 92 15:03:26 -0700 Message-Id: <9204162203.AA01193@enet-gw.pa.dec.com> Received: from eris.enet; by decwrl.enet; Thu, 16 Apr 92 15:03:50 PDT Date: Thu, 16 Apr 92 15:03:52 PDT From: What good is rain that falls up? 16-Apr-1992 1800 To: icon-group@cs.arizona.edu Apparently-To: icon-group@cs.arizona.edu Subject: Lisp, Icon, and OO "LISP, of course, isn't object-oriented (yes, another level of indirection that seems to be the rage these days)." Well, actually, it is. The definition of CLOS (Common Lisp Object System) in CLtL2 (Common Lisp : the Language, second edition) and the soon-to-be-ANSI standard make it object oriented. All Lisp objects are in a class hierarchy, and you can write methods that handle ordinary Lisp objects, defstruct structures, and of course CLOS objects. Anyone who isn't writing completely OO Lisp is doing so because they choose to, or they have an old Lisp system. Jon From icon-group-request Thu Apr 16 17:37:17 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 16 Apr 92 17:37:17 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA29194; Thu, 16 Apr 92 17:37:13 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA04367; Thu, 16 Apr 92 17:26:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 92 04:57:25 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.berkeley.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: should I use ICON for a specific problem ? Message-Id: <1992Apr9.045725.15554@midway.uchicago.edu> References: <1992Apr6.104410.12693@news.uni-stuttgart.de>, <1992Apr6.163124.15685@midway.uchicago.edu>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu rantapaa@s6.math.umn.edu (Erik E. Rantapaa) writes: >>> >>>I wrote a long nawk-file for a machine where no awk-compiler is available. >>>Now I'm searching for a language with the following spezifications: > >Not wishing to get into a Perl vs. Icon flame fest, I would suggest that >you seriously consider using Perl. Not only does Perl have many of the >features that you require, but it also comes with a program called 'a2p' >which converts awk programs to Perl. This is probably good advice. PERL is much closer to AWK than Icon is, and if you want familiarity from this standpoint, go with PERL. This answer just didn't occur to me (I'd guess because the question was phrased, "Can I do X in Icon?"). There's no reason to worry about flames here. PERL is a system adminis- trator's tool par excellance, with a C interface that's actually much bet- ter than Icon's. Icon is a much cleaner and more disciplined language, with a lot more options for control and data structures, coexpressions, and what not. I find PERL a mess, but that's just me. Probably I just don't know it well enough. -- -Richard L. Goerwitz goer%ellis@uchicago.bitnet goer@ellis.uchicago.edu rutgers!oddjob!ellis!goer From janpeter@mpi.kun.nl Fri Apr 17 05:00:28 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 05:00:28 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA19956; Fri, 17 Apr 92 05:00:23 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA26259; Fri, 17 Apr 92 14:01:02 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA02910; Fri, 17 Apr 92 13:59:26 +0200 Date: Fri, 17 Apr 92 13:59:26 +0200 From: Jan Peter de Ruiter Message-Id: <9204171159.AA02910@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu Subject: icon/awk I don't know excactly how relevant this is to the discussion of ICON vs PERL vs AWK, but in order to convince colleagues at our institute of the usefulness of ICON, (they're all AWK freaks) I wrote an ICON lib that emulates AWK. Once you load this library into an ICON program, you can do "AWK" and ICON in the same program. Of course, some names (like the $ operator in AWK) have different names in my LIB, but who cares? Of course, is is not exactly the same as AWK. For instance, you cannot use (literally) the /pattern/ { action ... } form of AWK. But this is something ICON is especially suited for, so why not do *that* in ICON qua ICON? So functionally, what you end up with (in my opinion) is a mixture of advanced pattern matching, and the ease of having files conveniently split up in addressable columns. These programs are of course somewhat slower than original gawk or nawk programs, unless you compile them, perhaps. A nice thing about this mixture (seen from the viewpoint of an AWK user) is that you can use CSETs as field separators and that you can use the (beautiful) ICON SET datatype. Currently, I'm trying to implement this module using co-expressions, which would in principle mean that you can open many AWK-streams at the same time, which would make the combination even more fruitful. I'm interested in some comments. Jan Peter de Ruiter Max Planck Institute for Psycholinguistics Nijmegen The Netherlands janpeter@mpi.kun.nl From icon-group-request Fri Apr 17 06:38:37 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 06:38:37 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA23021; Fri, 17 Apr 92 06:38:35 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA18607; Fri, 17 Apr 92 06:29:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Mar 92 20:15:56 GMT From: dog.ee.lbl.gov!network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.berkeley.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Windows 3.0 Message-Id: <1992Mar26.201556.16013@midway.uchicago.edu> References: <9203261632.AA05499@optima.cs.arizona.edu>, <9203261840.AA15783@chuckwalla.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu cjeffery@CS.ARIZONA.EDU ("Clinton Jeffery") writes: > > John Kohl, kohl@socrates.umd.edu, writes: > > Understandably, Icon hasn't been ported to Windows 3.0. > > With XIcon there is no serious reason to port. > >It is up to commercial implementors or dedicated users of each particular >window system to add graphics access to Icon. X-Icon proves such a task >can be done, but does not purport to be "complete" and implementors on >other window systems are likely to add system-specific features. I am >always interested in talking to people doing graphics access for Icon. I just want to add to this that, if anyone is considering adding such functionality to a specific platform, it might be nice to keep close to the X-Icon specs. One of the great virtues of Icon is its portability. -- -Richard L. Goerwitz goer%sophist@uchicago.bitnet goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From icon-group-request Fri Apr 17 09:23:58 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 09:23:58 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA28353; Fri, 17 Apr 92 09:23:51 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA27698; Fri, 17 Apr 92 09:17:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Apr 92 20:55:38 GMT From: adobe!yost@decwrl.dec.com (David Yost) Organization: Adobe Systems Incorporated Subject: Re: features from Icon Language in lisp Message-Id: <1992Apr15.205538.8848@adobe.com> References: <1992Apr14.173407.28762@adobe.com>, <1992Apr15.164314.8991@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr15.164314.8991@midway.uchicago.edu> goer@midway.uchicago.edu writes: >LISP, of course, isn't object-oriented Heavens! I guess you haven't hear of Common Lisp Object System, which is IMHO considerably more advanced than the usual other suspects. Anyone interested in OO programming in any language should read Object Oriented Programmin in Lisp by Sonya Keene. CLOS is a standard part of Common Lisp now. --dave yost From whm@shepard.sunquest.com Fri Apr 17 11:37:21 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 11:37:21 MST Received: from ALPHA.SUNQUEST.COM by optima.cs.arizona.edu (4.1/15) id AA03779; Fri, 17 Apr 92 11:37:12 MST Received: from sunquest.sunquest.com by ALPHA.SUNQUEST.COM with SMTP; Fri, 17 Apr 1992 11:37:00 -0700 (MST) Received: from shepard.sunquest.com by sunquest.sunquest.com (4.1/SMI-4.1) id AA22970; Fri, 17 Apr 92 11:35:48 MST Received: by shepard.sunquest.com (4.1/SMI-4.1) id AA10232; Fri, 17 Apr 92 11:36:33 MST Date: Fri, 17 Apr 92 11:36:33 MST From: whm@shepard.sunquest.com (Bill Mitchell) Message-Id: <9204171836.AA10232@shepard.sunquest.com> To: icon-group@cs.arizona.edu Subject: Icon bloated? Richard L. Goerwitz wrote: ... Personally, I feel good about Common LISP. It's even more bloated than Icon, though, and people who are really into clean LISP dialects seem to prefer Scheme. ... I just can't let this comment pass. "[Common Lisp is] even more bloated than Icon" implies that Icon is bloated. The reference manual in the 2e of the Icon book is a slim forty pages. Icon is certainly not a small language and I've heard Ralph say it's big, but "bloated" goes too far. I think just the opposite -- Icon has very good ratio of expressability to size of language specification. From icon-group-request Fri Apr 17 12:45:40 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 12:45:40 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA06472; Fri, 17 Apr 92 12:45:38 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA06009; Fri, 17 Apr 92 11:43:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Apr 92 21:21:44 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!ispd-newsserver!psinntp!xilinx!holen@ucbvax.berkeley.edu (Victor A. Holen ) Organization: Xilinx Inc. Subject: lang comparison (not war) Message-Id: <1992Apr7.212144.13007@xilinx.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Is there somewhere (book, ftp, ...) a reasonably objective comparison of icon with eiffel with a few other (perhaps c++, smalltalk, mainsail..). Comparison of features, robustness ( maturity of compilers), clarity in use, availability, standard-status (!), development environment (debuger +...), performance, suitability for large CAD (and other) projects .. ? Just the basics :) ? Thanks. -- victor .... ___ ._.. . _. holen@xilinx.com From icon-group-request Fri Apr 17 15:17:48 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 15:17:48 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA11991; Fri, 17 Apr 92 15:17:44 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA14507; Fri, 17 Apr 92 14:15:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 92 12:50:13 GMT From: mailer.cc.fsu.edu!sun13!sun8.scri.fsu.edu!nall@gatech.edu (John Nall) Organization: SCRI, Florida State University Subject: Re: should I use ICON for a specific problem ? Message-Id: <8139@sun13.scri.fsu.edu> References: <1992Apr6.163124.15685@midway.uchicago.edu>, , <1992Apr9.045725.15554@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr9.045725.15554@midway.uchicago.edu> goer@midway.uchicago.edu writes: [ ... stuff deleted ... ] > >There's no reason to worry about flames here. PERL is a system adminis- >trator's tool par excellance, with a C interface that's actually much bet- >ter than Icon's. Icon is a much cleaner and more disciplined language, >with a lot more options for control and data structures, coexpressions, >and what not. I find PERL a mess, but that's just me. Probably I just >don't know it well enough. It is so refreshing to see a well reasoned discussion of ICON vs PERL that I can't resist the temptation to say "WELL PUT!!" I agree with everything that Richard said, completely, even to the part of "I find PERL a mess, but that's just me". But it is certainly a gawdawful powerful tool in the hands of those who can deal with it :-) John -- John W. Nall | Supercomputer Computations Research Institute nall@mailer.scri.fsu.edu | Florida State University, Tallahassee, FL 32306 "Disclaimer: A world which requires disclaimers has too many lawyers." From icon-group-request Fri Apr 17 18:31:09 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 18:31:09 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA18601; Fri, 17 Apr 92 18:31:07 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA27572; Fri, 17 Apr 92 18:09:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 92 20:05:49 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!convex!tchrist@ucbvax.berkeley.edu (Tom Christiansen) Organization: CONVEX Realtime Development, Colorado Springs, CO Subject: Re: should I use ICON for a specific problem ? Message-Id: <1992Apr9.200549.10279@news.eng.convex.com> References: <1992Apr6.163124.15685@midway.uchicago.edu>, , <1992Apr9.045725.15554@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu From the keyboard of goer@midway.uchicago.edu: : :There's no reason to worry about flames here. PERL is a system adminis- :trator's tool par excellance, with a C interface that's actually much bet- :ter than Icon's. Icon is a much cleaner and more disciplined language, :with a lot more options for control and data structures, coexpressions, :and what not. I find PERL a mess, but that's just me. Probably I just :don't know it well enough. Nope, you're right -- in more ways than I care to enumerate, it *is* a mess. The amazing thing is how well it gets the job done anyway. --tom From icon-group-request Fri Apr 17 18:33:45 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 17 Apr 92 18:33:45 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA18792; Fri, 17 Apr 92 18:33:41 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA27458; Fri, 17 Apr 92 18:08:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Apr 92 20:02:08 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!convex!tchrist@ucbvax.berkeley.edu (Tom Christiansen) Organization: CONVEX Realtime Development, Colorado Springs, CO Subject: Re: should I use ICON for a specific problem ? Message-Id: <1992Apr9.200208.6455@news.eng.convex.com> References: <1992Apr6.104410.12693@news.uni-stuttgart.de>, <1992Apr6.163124.15685@midway.uchicago.edu>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu From the keyboard of rantapaa@s6.math.umn.edu (Erik E. Rantapaa): At the risk of raising Richard's ire, I'm going to clarify a couple of Erik's points. :>>2. multidimension arrays should be available (nawk-synax: array[1,2]) : :--- Perl loses here. Only singly dimensioned arrays are supported, but :multi-dimensional arrays can be simulated, e.g. array["1,2"]. Not precisely correct: simulated multi-dimensional arrays via index concatenation are directly supported syntactically you can say $array{$x} or $array{$x, $y} or $array{$x, $y, $z}, etc. :>>5. same loops as for, do and while in C should be available (not the :>> same syntax is needed ...) : :+++ Perl has loops with equivalents for 'continue' and 'break'. Furthermore, since loops can be labeled, you can name which loop you want to break or continue, something you can't do in C. There's also a third form of loop control, redo, which is like continue without doing the 3rd for of the for loop (the re-init portion). Furthermore, there's a "foreach elt (list)" looping construct as well. :>>6. total computer-readable documentation is needed (I don't want to buy a :>> book of a thing, that maybe don't do it ...) : :+++ Perl comes with lots of free documentation -- in texinfo format. You can also use the online man page, which is nearly booklength. Also, the book examples are available on-line, as is all of comp.lang.perl from all time, as well as various database and retrieval methods for perusing it. :Perl has its roots in the Unix utilities sed, ed, grep, sh and, yes, awk. :(Yes, yes is a Unix utility; no, it's not related to Perl :) My knowledge :of genealogical terminalogy is not that great, so maybe someone else can :fill in what relationship Perl, awk and Icon have with each other. The current list of tools from which perl derives something of its eclectic nature includes but is not limited to the Bourne shell, csh, awk, sed, tr, cpp, C (classic and ANSI), BASIC-PLUS, Pascal, Ada, Lisp, APL, Fortran, Algol, egrep, nroff, /bin/test, vi, and emacs. Seriously. :Perl arrays function for the most part just like awk's. Well, Perl has two kinds of things you might call arrays, but are perhaps better characterized as lists and tables. Lists one uses numeric indices on as well as push and pop kinds of operations, whereas tables are generic hash tables employing arbitrary indices. Both data structures dynamically resize internally to avoid performance degradations. Tables can also be bound directly to dbm files for rapid-access persistent data. :In general, Icon has better support for data structures than Perl does. :It's not real easy to implement 'recursive' data structures in Perl, although :it can be done (although usually a way is found to get around it.) True enough. The major hurdle is lack of syntactic sugar. You can make a table of pointers to lists of pointers to lists of pointers to tables, but the dereferencing requires a temporary variable for each dereference. :Icon wins with the arbitrarily large integers. Perl has arbitrarily large integers, rationals, and floats available via the libbig (bigfloat, bigint, bigrat) library package, with normal arithmetic operations on them supported via library routines. Of course, these haven't a change of being as fast as binary machine floats, since they're stored as strings. :>Question #4: Does Icon have subroutines? If by this you mean that you can :>define your own procedures, then yes. If you mean, "does it let you use :>labels," then the answer is "no." : :Perl has labels like C does. Icon has more powerful subroutines, however. :They are, in fact, more like co-routines, something I wish Perl had. Well, perl labels are a little neater than C's because of the way you can use them to label loops and as operands for loop-control statements, as previously explained. Subroutines in perl can also be called indirectly; recursion is supported; they can be autoloaded; they can live in protected namespaces (somewhat like file statics in C); they can for good or evil be overridden via dynamic scoping. --tom From icon-group-request Sat Apr 18 02:47:17 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 18 Apr 92 02:47:17 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA04963; Sat, 18 Apr 92 02:47:13 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA01534; Sat, 18 Apr 92 02:40:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 92 03:05:33 GMT From: att!linac!uchinews!ellis!goer@ucbvax.berkeley.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: upto() with backslash escaping Message-Id: <1992Apr10.030533.16431@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Anybody else need one of these? -Richard ############################################################################ # # Name: slashupto.icn # # Title: slashupto (upto with backslash escaping) # # Author: Richard L. Goerwitz # # Version: 1.1 # ############################################################################ # # Slashupto works just like upto, except that it ignores backslash # escaped characters. I can't even begin to express how often I've # run into problems applying Icon's string scanning facilities to # to input that uses backslash escaping. Normally, I tokenize first, # and then work with lists. With slashupto() I can now postpone or # even eliminate the traditional tokenizing step, and let Icon's # string scanning facilities to more of the work. # # If you're confused: # # Typically UNIX utilities (and probably others) use backslashes to # "escape" (i.e. remove the special meaning of) metacharacters. For # instance, UNIX shells normally accept "*" as a shorthand for "any # series of zero or more characters. You can make the "*" a literal # "*," with no special meaning, by prepending a backslash. The rou- # tine slashupto() understands these backslashing conventions. You # can use it to find the "*" and other special characters because it # will ignore "escaped" characters. # ############################################################################ # # Links: none # # See also: slashbal.icn # ############################################################################ # # slashupto: cset x string x integer x integer -> integers # (c, s, i, j) -> Is (a generator) # where Is are the integer positions in s[i:j] before characters # in c that is not preceded by a backslash escape # procedure slashupto(c, s, i, j) if /s := &subject then /i := &pos else /i := 1 /j := *s + 1 /c := &cset c ++:= '\\' s[1:j] ? { tab(i) while tab(upto(c)) do { if (="\\", move(1)) then next suspend .&pos move(1) } } end -- -Richard L. Goerwitz goer%ellis@uchicago.bitnet goer@ellis.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-request Sun Apr 19 05:33:58 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 05:33:58 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA14073; Sun, 19 Apr 92 05:33:55 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA19963; Sun, 19 Apr 92 05:32:40 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 92 17:39:51 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!wupost!csus.edu!netcomsv!mork!nagle@ucbvax.berkeley.edu (John Nagle) Organization: Netcom - Online Communication Services (408 241-9760 guest) Subject: Re: lang comparison (not war) Message-Id: <0#tj+5g.nagle@netcom.com> References: <1992Apr7.212144.13007@xilinx.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu holen@xilinx.com (Victor A. Holen ) writes: >Is there somewhere (book, ftp, ...) a reasonably objective >comparison of icon with eiffel with a few other (perhaps c++, >smalltalk, mainsail..). I haven't heard much about Icon in years. It was intended as a replacement for Snobol, and perhaps as an alternative to the horrible "string languages" ("awk", "sed") that come with UNIX. Icon offers Snobol-like matching with C-like syntax. It's intended for a different class of applications than is Eiffel. John Nagle From icon-group-request Sun Apr 19 06:49:40 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 06:49:40 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA16210; Sun, 19 Apr 92 06:49:38 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA22845; Sun, 19 Apr 92 06:44:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Apr 92 18:32:35 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!nic!netlabs!lwall@ucbvax.berkeley.edu (Larry Wall) Organization: NetLabs, Inc. Subject: Re: should I use ICON for a specific problem ? Message-Id: <1992Apr10.183235.10731@netlabs.com> References: , <1992Apr9.045725.15554@midway.uchicago.edu>, <1992Apr9.200549.10279@news.eng.convex.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr9.200549.10279@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes: : From the keyboard of goer@midway.uchicago.edu: : : : :There's no reason to worry about flames here. PERL is a system adminis- : :trator's tool par excellance, with a C interface that's actually much bet- : :ter than Icon's. Icon is a much cleaner and more disciplined language, : :with a lot more options for control and data structures, coexpressions, : :and what not. I find PERL a mess, but that's just me. Probably I just : :don't know it well enough. : : Nope, you're right -- in more ways than I care to enumerate, it *is* a : mess. The amazing thing is how well it gets the job done anyway. Perl was intended to be a mess from the start, so it's a very, um, systematic mess... :-) Larry From icon-group-request Sun Apr 19 09:33:55 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 09:33:55 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA19416; Sun, 19 Apr 92 09:33:53 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA01725; Sun, 19 Apr 92 09:20:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Apr 92 17:37:43 GMT From: sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!uicvm.uic.edu!u47041@lll-winken.llnl.gov Organization: University of Illinois at Chicago Subject: wanted:ftp sites for icon Message-Id: <92109.123743U47041@uicvm.uic.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu helo folks, i used snobol for a while and seems its time for the next one. can anyone tell me where can i ftp icon( for pc's and unix)? thanx in advance u47041@uicvm.bintet kapoulas@lac.math.uic.edu From icon-group-request Sun Apr 19 13:06:21 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 13:06:21 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA25497; Sun, 19 Apr 92 13:06:18 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA12880; Sun, 19 Apr 92 12:56:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 92 01:02:53 GMT From: dog.ee.lbl.gov!network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!allbery@ucbvax.berkeley.edu (Brandon S. Allbery KF8NH) Organization: North Coast Public Access *NIX, Cleveland, OH Subject: Re: Icon bloated? Message-Id: <1992Apr19.010253.8767@NCoast.ORG> References: <9204171836.AA10232@shepard.sunquest.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu As quoted from <9204171836.AA10232@shepard.sunquest.com> by whm@SHEPARD.SUNQUEST.COM (Bill Mitchell): +--------------- | | Richard L. Goerwitz wrote: | | Personally, I feel good about Common LISP. It's even more bloated than | Icon, though, and people who are really into clean LISP dialects seem | to prefer Scheme. ... | | I just can't let this comment pass. "[Common Lisp is] even more bloated | than Icon" implies that Icon is bloated. The reference manual in the 2e of | the Icon book is a slim forty pages. Icon is certainly not a small language | and I've heard Ralph say it's big, but "bloated" goes too far. I think just | the opposite -- Icon has very good ratio of expressability to size of | language specification. +--------------- Very much agreed. In fact, I've currently encountered only *one* thing that might make a worthwhile extension to Icon; and it looks like a logical extension of existing features, so it's not exactly out of place. I encountered an application where I wanted to use something like Icon's pattern matching on what amounted to token streams. The generalized form is "pattern matching" on types other than strings; I've implemented it (well, sort of) as a library loosely modeled on Icon's string pattern matching and using coroutines. But I think it also needs a lot more though before it can be considered for inclusion into Icon. (The problem with the library is it's still rather type-dependent.) Other than that one possible future extension (again, ONLY when it's ready, which it very much isn't in at least my current visualization) it seems to me that Icon is quite expressive for all its essential simplicity. It's amazing (at least to those of us accustomed to "conventional" programming languages) how much cruft can be avoided by the use of Iconisms such as goal-directed evaluation, etc. ++Brandon -- Brandon S. Allbery, KF8NH [44.70.4.88] allbery@NCoast.ORG Senior Programmer, Telotech, Inc. (if I may call myself that...) From wgg@cs.ucsd.edu Sun Apr 19 13:43:03 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 13:43:03 MST Received: from ucsd.edu by optima.cs.arizona.edu (4.1/15) id AA26642; Sun, 19 Apr 92 13:43:00 MST Received: from odin.ucsd.edu by ucsd.edu; id AA04163 sendmail 5.64/UCSD-2.2-sun via SMTP Sun, 19 Apr 92 13:42:44 -0700 for icon-group@cs.arizona.edu Received: from gremlin.ucsd.edu by odin.ucsd.edu (4.1/UCSDPSEUDO.4) id AA29599 for dog.ee.lbl.gov!network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!allbery@ucbvax.berkeley.edu; Sun, 19 Apr 92 13:42:43 PDT Received: by gremlin.ucsd.edu (4.1/UCSDPSEUDO.4) id AA24368 for icon-group@cs.arizona.edu; Sun, 19 Apr 92 13:42:42 PDT Date: Sun, 19 Apr 92 13:42:42 PDT From: wgg@cs.ucsd.edu (William Griswold) Message-Id: <9204192042.AA24368@gremlin.ucsd.edu> To: dog.ee.lbl.gov!network.ucsd.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!allbery@ucbvax.berkeley.edu, icon-group@cs.arizona.edu Subject: Re: Icon bloated? Icon is tiny compared to Common Lisp (CL). The recent 2nd edition manual for CL is some 1000 pages, in smaller print than the Icon book. Fortunately for programmers, Icon and CL subset nicely, allowing a gentle introduction to each. However, there is still the problem that it is often faster to code a function yourself than to find the Icon/CL function that does the equivalent thing. Another problem with language bloating is implementing programming tools for a language. Although a programmer can learn one feature at a time, few tools will work at all unless they support the whole language. I would guess that much of Ralph's objection to the size of Icon is due to the cost of maintaining the Icon Project's language systems, not the learning curve. As software engineers push for ever-higher programmer productivity, they are increasingly looking at tool solutions to programming problems, rather than languages. However, language size is a considerable barrier when moving from research into practice. For example, I have a program restructuring tool for a subset of the LISP dialect Scheme. To move this system to CL is such a monumental task that I cannot consider it in a research environment. For the same reason DARPA/DoD is looking for Ada subsets that researchers can use for their tools research. No sane researcher would ever build a tool for a complete language as complex as Ada. Bill Griswold UC San Diego From icon-group-request Sun Apr 19 19:35:17 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 19:35:17 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA06041; Sun, 19 Apr 92 19:35:14 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA05043; Sun, 19 Apr 92 19:26:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 92 18:33:36 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!sun1.ruf.uni-freiburg.de!news.belwue.de!news.uni-stuttgart.de!helpdesk.rus.uni-stuttgart.de!zrzm0111@ucbvax.Berkeley (MUFTI) Organization: User Helpdesk Comp. Cent. (RUS) U of Stuttgart, FRG Subject: Why I can't use perl Message-Id: <1992Apr13.183336.3439@news.uni-stuttgart.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Dear Sirs, Unfortunatly I started a icon vs. perl language war with my question if I should use icon for my awk-script. I thougth about using perl, before I thougth about icon, but perl seams to be too slow: 1. Cause perl don't support "dump" on my system, the program needs with perl the same big amount of time to startup, as with nawk/gawk. In this point wins the semicompiling concect of icon. 2. So I know perl doesn't support integer. Cause my machine has no Floating Point Unit, a perl program is slower than a "tuned" gawk-version where #define AWKTYPE long (instead of double) thanks to all for help yours MUFTI ps: the a2p -program doesn't work for my program, cause it don't know some- thing about the "do { } while()" -loop, which is a nawk-special feature From icon-group-request Sun Apr 19 20:22:03 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 19 Apr 92 20:22:03 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA07247; Sun, 19 Apr 92 20:22:01 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA07843; Sun, 19 Apr 92 20:17:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Apr 92 21:22:01 GMT From: shack@arizona.edu (David Shackelford) Organization: U of Arizona CS Dept, Tucson Subject: Re: wanted:ftp sites for icon Message-Id: <3669@caslon.cs.arizona.edu> References: <92109.123743U47041@uicvm.uic.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <92109.123743U47041@uicvm.uic.edu> U47041@uicvm.uic.edu writes: >helo folks, i used snobol for a while and seems its time for the >next one. can anyone tell me where can i ftp Icon is available by anonymous FTP from the University of Arizona at cs.arizona.edu. Versions are available for many op. systems including UNIX, VMS, DOS, and OS/2. From janpeter@mpi.kun.nl Tue Apr 21 05:55:54 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 21 Apr 92 05:55:54 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA27238; Tue, 21 Apr 92 05:55:45 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA05307; Tue, 21 Apr 92 14:57:00 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA06445; Tue, 21 Apr 92 14:54:49 +0200 Date: Tue, 21 Apr 92 14:54:49 +0200 From: Jan Peter de Ruiter Message-Id: <9204211254.AA06445@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu Subject: icon/awk Since I received many reactions concerning my "icon/awk" library, I will send it to the group-adress (see below). However, I think it is appropriate to add a disclaimer: like I said in my previous mail on the subject, the /pattern/ { action } form is not emulated, for obvious reasons. ICON itself is (in my opinion) better equipped to handle pattern scanning, and I wouldn't like to spend long nights hacking away to emulate grep-type regular expressions, when ICON already has equivalent facilities. Besides, the lib would then become even slower than it is already. However, for some AWK users, exactly this feature (grep-type expressions) is their reason for using AWK. What I like about AWK is the possibility of adressing the columns in a stream, given a certain set of separator characters. It is that aspect that I wanted to use in ICON, and it is that functionality that I've tried to implement in a LIB. If anyone of you improves upon the library, I'd appreciate hearing about it. keil@apollo.hp.com has suggested that the $ symbol *could* be used instead of "FLD" for field identifyers. I do not know, however, how this can be done. Has any of the ICON guru's a suggestion? The lib: # AWK emulation library. # # USAGE: # # compile AWEKA.ICN with the -c option. # At the top of your program declare: # # link aweka # # You can now open a stream (say, "instream") and pass this as # an argument to the procedure awk(). If the stream is at EOF, # the function awk() fails, so the following form is useful: # # while awk(instream) do { # ... # } # # Every time awk(stream) is called, it reads a line from stream, and # sets the global variables FLD, NR, and NF. awk() returns the whole line # that was read from the stream (cf. $0 in AWK). # # FLD is a list, where FLD[n] corresponds to the nth column in the input # line, separated by characters from FS. Note that you can therefore use # FLD as a generator, or with the pop() function, or what have you. # # NR is the number of records read from the input stream. # NF is the number of fields read. # # The global var FS is a cset, specifying the whitespace characters. If you # do not set FS, awk() uses the space and tab character as default. If you # want another set of separator-chars, you can set FS to the desired # cset before calling awk(). It is also possible to change FS # between successive calls to awk() with the same stream. (see example) # # If you call awk() with another stream argument than the one you used in # the previous call to awk(), it resets the value of NR to 0. # # The caller (your icon program) is responsible for opening and closing # the streams. # # # An example program to print out all words in an ascii text on a separate # line. It changes the value of FS from ' ;' to ' ,.;:?!' if the string # "TEXT" is processed, and it sets the value of FS to ' ;' again if the # string "PROGRAM" is encountered. It then opens a new file, and does the # same thing with the default character set, without changing FS. It shows # some of nice awk*icon mixtures that can be used. # # # example and test program for AWEKA lib # link aweka # procedure main() # instream := open("awktest.dat") # FS := ' ;' # # while(awk(instream)) do { # every(i := 1 to NF) do { # case FLD[i] of { # "TEXT" : FS := ' ,.;:?!' # "PROGRAM" : FS := ' ;' # } # write(FLD[i]) # } # } # # secondstream := open("awktest2.dat") # FS := &null # in order to restore the default charset # while awk(secondstream) do every(write(!FLD)) # # close(instream) # close(secondstream) # end # # # global NF, NR, FLD, FS procedure awk(file) static oldfile initial { oldfile := &null } if (oldfile ~=== file) then { NR := 0 oldfile := file } if (/FS) then FS := ' \t' charset := &cset -- cset(FS) NF := 0 FLD := list() if(LSTR := !file) then NR +:= 1 else fail LSTR ? while(tab(upto(charset))) do put(FLD,tab(many(charset))) NF := *FLD suspend LSTR end From MATH0022@rmc.ca Tue Apr 21 10:52:09 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 21 Apr 92 10:52:09 MST Received: from Arizona.edu (Osprey.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15) id AA09366; Tue, 21 Apr 92 10:51:30 MST Received: from RMC.CA (MAILER@RMC) by Arizona.edu (PMDF #12663) id <01GJ3UGERAVWA9OUD2@Arizona.edu>; Tue, 21 Apr 1992 10:51 MST Received: by RMC (Mailer) id 45140317390; Tue, 21 Apr 92 13:47:10 EST Date: Tue, 21 Apr 92 13:22:16 EST From: MATH0022@rmc.ca Subject: References please .... To: icon-group@cs.arizona.edu Reply-To: LINDSAY_JH@rmc.ca Message-Id: <920421.13460935.081750@RMC.CP6> X-Envelope-To: icon-group@cs.Arizona.edu One would not expect the current PERL-AWK-NAWK-&c controversy on THIS board. However, since it's there, would someone please post a list of references to PERL, AWK, NAWK, &c., preferrably including any sort of definitive documents or standards documents and some introductory material. The "perl" that I have references to is plainly not the PERL being discussed here, and my AWK material must be very out of date. It would be a good place to list any sort of comparative document too. Thanks. -------------------------------------------------------------------------------- John H. Lindsay, Department of Mathematics and Computer Science, Royal Military College of Canada, Kingston, Ontario, Canada, K7K 5L0. Phones: Office, (613) 541-6419 Messages, 541-6343 or 541-6458 Home, 546-6988 E-Mail: From Bitnet, NetNorth, ONet: LINDSAY_JH@RMC.CA From Canadian Military Colleges: LINDSAY JH@RMC Fax: (613) 542-8129 From MATH0022@rmc.ca Tue Apr 21 13:24:56 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 21 Apr 92 13:24:56 MST Received: from Arizona.edu (Merlin.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15) id AA17503; Tue, 21 Apr 92 13:24:46 MST Received: from RMC.CA (MAILER@RMC) by Arizona.edu (PMDF #12663) id <01GJ3ZSCQO9OA9UI81@Arizona.edu>; Tue, 21 Apr 1992 13:24 MST Received: by RMC (Mailer) id 45141254084; Tue, 21 Apr 92 16:23:12 EST Date: Tue, 21 Apr 92 16:22:17 EST From: MATH0022@rmc.ca Subject: Algol 60 Call-by-Name & SNOBOL4 & ICON .... ? To: icon-group@cs.arizona.edu Reply-To: LINDSAY_JH@rmc.ca Message-Id: <920421.16221752.081750@RMC.CP6> X-Envelope-To: icon-group@cs.Arizona.edu The ideas of passing a SNOBOL4 (delayed) expression or an ICON co-expression as an argument to a procedure present the thought that these are "almost" like the Algol 60 Call-by-Name facility, painfully so if one wants to use a facility of that sort, but can't because these are not quite like it, and enragingly so if one finds such a facility too mind-boggling to be a part of a readable reliable program. For the Johnny-and-Suzie-come-latelies, in Algol 60 and some related languages, an actual parameter (= argument) of a procedure call which does not correspond to a formal VALUE parameter is reevaluated every time it's referenced in the called procedure, but in the context of the block containing the call. This means that even as simple an argument as an array element can change its meaning or value from reference to reference in the called routine because the subscripting is redone, and reflects any changes in the value of the subscript. The situation shows up well in Algol W (an "Algol 67" -- a step looking forward to Algol 68, and done by Nick Wirth, associates and students at Stanford); that Algol also allowed s to be actual parameters, but the corresponding formal parameters were then declared as parameterless procedures, and one might infer that other types of formal parameters corresponding to a expression as an actual parameter were thought of, if not declared, in that way. The notable "deficiencies" (useful roadblocks ?) that inhibit or prevent the use of delayed expressions and co-expressions in SNOBOL4 and ICON as actual Call-by-Name parameters, as I see it, are: The inability of a SNOBOL4 expression to NRETURN like a function so that such a parameter can't be used as the target of an assignment without doing an indirect, The semantics of the SNOBOL4 save-and-replace formal parameter handling mechanism for function calls which may inhibit anything like evaluation in a context, The one-level procedure nesting of ICON and the semantics of co-expression creation which limit useful contexts to global variables and COPIES of contexts of procedures (without the possibility of sharing local procedure variables between the copies), and The lack of an indirect reference mechanism in ICON. I'd like to swap notes with anyone who has tried anything like this sort of thing: Could you use it? What roadblocks did you find? Could you get around them? How painfully? Would you try it again? -------------------------------------------------------------------------------- John H. Lindsay, Department of Mathematics and Computer Science, Royal Military College of Canada, Kingston, Ontario, Canada, K7K 5L0. Phones: Office, (613) 541-6419 Messages, 541-6343 or 541-6458 Home, 546-6988 E-Mail: From Bitnet, NetNorth, ONet: LINDSAY_JH@RMC.CA From Canadian Military Colleges: LINDSAY JH@RMC Fax: (613) 542-8129 From janpeter@mpi.kun.nl Wed Apr 22 09:12:38 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 22 Apr 92 09:12:38 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA04244; Wed, 22 Apr 92 09:12:33 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA05231; Wed, 22 Apr 92 17:21:18 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA08390; Wed, 22 Apr 92 17:19:01 +0200 Date: Wed, 22 Apr 92 17:19:01 +0200 From: Jan Peter de Ruiter Message-Id: <9204221519.AA08390@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu Subject: ICON/AWK disclaimer I keep getting email from people asking if I can send my ICON/AWK lib to them, and if there are any charges involved. I think that there must be some misunderstanding, for I have *already* sent the lib to the ICON group, and charges are of course out of the question. Perhaps I've used too big a word for it ("library") for which I hereby apologise. Perhaps it would be a good idea to spell things out quite clearly: The lib i've written is a modest 20 line ICON procedure (and some global variables) that enables one to do AWKish processing (using $, NF, NR and FS) on a specified stream. I've already sent the lib to the icon-group, but anyone who's accidentally deleted it and is still interested can mail me to ask for a (free) copy. I use this library extensively (being an ex awk-user), and consider it quite handy. That's why I wanted to mention it in the ICON group. Charges are (of course) out of the question for an almost trivial procedure like the one I've written. Maybe some of you would have liked a "real" icon-to-awk interface, but alas, that's not what I meant. For me it is enough to have the $n-style functionality of AWK in an otherwise ICONic environment. Jan Peter de Ruiter Max Planck Institute for Psycholinguistics Nijmegen The Netherlands EMAIL: janpeter@mpi.kun.nl From janpeter@mpi.kun.nl Thu Apr 23 05:33:15 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 05:33:15 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA01033; Thu, 23 Apr 92 05:33:10 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA22294; Thu, 23 Apr 92 14:34:23 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA09955; Thu, 23 Apr 92 14:32:15 +0200 Date: Thu, 23 Apr 92 14:32:15 +0200 From: Jan Peter de Ruiter Message-Id: <9204231232.AA09955@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu Subject: $ as identifyer In ICON one can use only identifyers that consist of underscores, digits, and letters. Why is this? The '$' character is not an ICON operator (to my surprise, I must add), and it would be nice to be able to use all non-operator ascii-characters. Another point is that someone has recently suggested to me that is would be possible to circumvent this problem; unfortunately he only thought *that* it was possible, but didn't know to do it. Any tips, hints, or comments? Jan Peter de Ruiter Max Planck Institute for Psycholinguistics, Nijmegen, Netherlands EMAIL: janpeter@mpi.kun.nl From ralph Thu Apr 23 05:41:11 1992 Date: Thu, 23 Apr 92 05:41:11 MST From: "Ralph Griswold" Message-Id: <9204231241.AA08471@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 05:41:11 MST To: icon-group@cs.arizona.edu, janpeter@mpi.kun.nl Subject: Re: $ as identifyer The character $ is not an operator in Icon, but it is used in digraphs for alternative representations for a few characters that are not available on some EBCDIC terminals. For example, $< and [ are equivalent in Icon. (See page 293 of the second edition of the Icon language book.) Ralph Griswold / Department of Computer Science The University of Arizona / Tucson, AZ 85721 ralph@cs.arizona.edu / uunet!arizona!ralph voice: 602-621-6609 / fax: 602-621-9618 From ms@informatik.uni-hannover.dbp.de Thu Apr 23 08:49:42 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 08:49:42 MST Received: from ixgate.gmd.de by optima.cs.arizona.edu (4.1/15) id AA07163; Thu, 23 Apr 92 08:49:38 MST Received: by ixgate.gmd.de id AA19527; Thu, 23 Apr 92 17:49:50 +0200 Date: 23 Apr 92 15:45 From: "(Michael Sperber)" Message-Id: Subject: $ in identifiers Apparently-To: icon-group@cs.arizona.edu RFC-822-HEADERS: Return-Path: <@CDC2.RRZN.UNI-HANNOVER.DE:ms@informatik.uni-hannover.de> To: @CDC2:icon-group@cs.arizona.edu ================== It's even nicer to have an at least on character left over for potential language extensions. One of those is Idol from the IPL. :-> Chipsy From TENAGLIA@mis.mcw.edu Thu Apr 23 12:48:16 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 12:48:16 MST Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15) id AA18730; Thu, 23 Apr 92 12:48:11 MST Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12865) id <01GJ6VC0XW2OBXIO3P@mis.mcw.edu>; Thu, 23 Apr 1992 14:48 CST Date: Thu, 23 Apr 1992 14:48 CST From: Chris Tenaglia - 257-8765 Subject: Re: $ as identifyer To: janpeter@mpi.kun.nl Cc: icon-group@cs.arizona.edu Message-Id: <01GJ6VC0XW2OBXIO3P@mis.mcw.edu> X-Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"janpeter@mpi.kun.nl" X-Vms-Cc: in%"icon-group@cs.arizona.edu" > In ICON one can use only identifyers that consist of underscores, digits, > and letters. Why is this? The '$' character is not an ICON operator > (to my surprise, I must add), and it would be nice to be able to use > all non-operator ascii-characters. > Another point is that someone has recently suggested to me that is would > be possible to circumvent this problem; unfortunately he only thought > *that* it was possible, but didn't know to do it. > Any tips, hints, or comments? > Jan Peter de Ruiter > Max Planck Institute for Psycholinguistics, Nijmegen, Netherlands > EMAIL: janpeter@mpi.kun.nl I also noticed that lonely $ character. I started a flame war sometime back suggesting it be used as a user defined operator and I proposed a syntax for defining it. operator { &operand[1] : bits &operand[2] : test_bits &operand[3] : etc,... } val := 192 | procedure bits(n) mask:= 160 | binary := radcon(n,10,2) tmp := $ val | count := 0 write(tmp) 2 | every bit := !binary do tmp := mask $ val | count +:= 1 write(tmp) "partial match" | return count | end etc,... The argument for this is that certain kinds of operations can be made clearer to understand using this notation rather than procedural. It can be argued that the procedural notation is sufficiently powerful to handle currently known contingencies. I thought about defining compound operators like $+ which would be a conceptual analog to an addition operation. However the whole thing seemed to be shot down from the OOPs camp since apparently IDOL uses the character. I also think IBM mainframe ICON uses $( and $) for curly braces, and quoting other non-ibm characters. The thought was fun to toy with for a while. Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu From keil@apollo.hp.com Thu Apr 23 15:00:15 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 15:00:15 MST Received: from amway.ch.apollo.hp.com by optima.cs.arizona.edu (4.1/15) id AA24886; Thu, 23 Apr 92 15:00:06 MST Received: from xuucp.ch.apollo.hp.com by amway.ch.apollo.hp.com id Thu, 23 Apr 92 17:57:57 EDT Received: by xuucp.ch.apollo.hp.com id ; Thu, 23 Apr 92 17:45:37 EDT Message-Id: <9204232145.AA13723@xuucp.ch.apollo.hp.com> Received: by daphne.ch.apollo.hp.com id AA04182; Thu, 23 Apr 92 17:50:48 EDT From: keil@apollo.hp.com Date: Thu, 23 Apr 92 17:16:10 EDT Subject: How tu use $ as identifyer To: icon-group@cs.arizona.edu Cc: janpeter@mpi.kun.nl Folks: I suppose I started this by mentioning this to Jan... SO, here is how I did it. I added the define: #define DollarIdent /* allow $ character as an identifier */ to define.h And then I made the following changes to tlex.c (see below) I had no problems with this change. I used it for procedure names of the form name1_$name2. (I did this because I wanted to make system call visible to the icon program through the external interface, and the system call had the form name1_$nane2) Since I didn't use digraphs, I don't know if it affects their use. Since there is a define to control it, the change can be made invisable to those that don't want it. You can add this to standard ICON if you want to Ralph. -Mark The following comprares were off a august 1990 snapshot of version 8 It should not differ much from the present version 8 (I think...) The Apollo compare (cmf) shows the change in context $ cmf /keil/icon/v8.x6/src/icont/tlex.c.orig /keil/icon/v8.x6/src/icont/tlex.c A254 if (isalpha(c) || (c == '_')) { /* gather ident or reserved word */ changed to B254 #ifdef DollarIdent B255 if (isalpha(c) || (c == '_') || (c == '$')) { /* gather ident or reserved word */ B256 #else B257 if (isalpha(c) || (c == '_')) { /* gather ident or reserved word */ B258 #endif /* VarTran */ A330 } while (isalnum(c) || (c == '_')); changed to B334 #ifdef DollarIdent B335 } while (isalnum(c) || (c == '_') || (c == '$')); B336 #else B337 } while (isalnum(c) || (c == '_')); B338 #endif The diff version for those that like and grok diff ;-) $ diff /keil/icon/v8.x6/src/icont/tlex.c.orig /keil/icon/v8.x6/src/icont/tlex.c 253a254,256 > #ifdef DollarIdent > if (isalpha(c) || (c == '_') || (c == '$')) { /* gather ident or reserved word */ > #else 254a258 > #endif /* VarTran */ 329a334,336 > #ifdef DollarIdent > } while (isalnum(c) || (c == '_') || (c == '$')); > #else 330a338 > #endif From cjeffery Thu Apr 23 16:56:10 1992 Received: from chuckwalla.cs.arizona.edu by cheltenham.cs.arizona.edu; Thu, 23 Apr 92 16:56:10 MST Date: Thu, 23 Apr 92 16:56:08 MST From: "Clinton Jeffery" Message-Id: <9204232356.AA12522@chuckwalla.cs.arizona.edu> Received: by chuckwalla.cs.arizona.edu; Thu, 23 Apr 92 16:56:08 MST To: TENAGLIA@mis.mcw.edu Cc: icon-group@cs.arizona.edu In-Reply-To: Chris Tenaglia - 257-8765's message of Thu, 23 Apr 1992 14:48 CST <01GJ6VC0XW2OBXIO3P@mis.mcw.edu> Subject: $ as identifyer Chris Tenaglia writes about his proposed $ for a user-defined operator: > However the whole thing seemed to be shot down from the OOPs camp > since apparently IDOL uses the character. It is true that the first implementation of Idol uses the $ operator. I don't think you can blame the OOP camp for shooting down your idea though; you can use $ to do whatever you want, if you don't use Idol. The two best ways to try out extensions to Icon that are too complex to code in C, are (a) use a variant translator if your system supports it, or (b) write an Icon program that translates your extended language into Icon and then calls icont. Idol proves that the latter approach is viable, and can be very portable (it even runs on MS-DOS :-). I should warn you, though, that language design is *very hard*, so don't take it personally if people aren't interested in your extension. You might discover its the best thing since sliced bread, but if other people can't immediately grasp its usefulness, it will get ignored. And if its a good idea, but the design is not general enough, or the syntax is clumsy, it will still get ignored. And lastly, you may learn how to do it right, if you do it wrong, and gain experience with it. Good luck. Clint Jeffery From icon-group-request Fri Apr 24 09:54:50 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 24 Apr 92 09:54:50 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA09730; Fri, 24 Apr 92 09:54:48 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA08944; Fri, 24 Apr 92 09:48:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 92 16:20:06 GMT From: wupost!dsuvax.dsu.edu!ghelmer@decwrl.dec.com (Guy Helmer) Organization: Dakota State University, Madison, SD Subject: Computer Programming for the Humanities Course Offering Message-Id: <1992Apr24.162006.6210@dsuvax.dsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu [ The following is a description of an offering of a course via electronic mail by Dakota State University's College of Liberal Arts. Reply-To: is set to ERIC%SDNET.BITNET@vm1.nodak.edu, which is where queries regarding the course should be sent. Flames regarding this massive cross-post should be directed to ghelmer@dsuvax.dsu.edu :-) ] Following is information about a three-credit graduate course in programming for the humanities offered by Dakota State University via BITNET (and other interconnected networks). Students in the course can be anywhere in the world if they can send and receive electronic mail. CHUM 650, COMPUTER PROGRAMMING FOR THE HUMANITIES, is an introduction to programming using SNOBOL4 for applications in the humanities such as analysis of texts, arranging data from research, and formatting for printing and desktop publishing. The primary emphasis in the course will be on computer applications with texts. The course is designed for humanists who want to learn to write useful computer programs for research and teaching. The language of choice for this course is SNOBOL4 because it is a powerful language designed for non-numeric computing; students can write useful programs in SNOBOL4 almost from the start. The course will begin with an introduction to programming, then cover techniques of structuring SNOBOL4 programs, and it will finish with students completing individual projects of their own creation. Students in the course can work at their own pace; they can begin immediately. Students should plan to finish all course requirements by August 1. Programming assignments for the course will be designed for MS-DOS microcomputers. Although most assignments can be modified for Macintosh users, students using a Macintosh would have to purchase MaxSPITBOL, and they would need an understanding of Macintosh file structures. It is a prerequisite for the course that students have a sound understanding of how to upload and download files from the mainframe that runs electronic mail to the DOS microcomputer used for the programming assignments. In addition, students must be familiar with DOS commands. The total cost of the course is $239.82. No textbook is required. Students will be sent a disk containing a public-domain SNOBOL4 compiler and a text editor. Lectures and data files will be sent electronically. Students may audit the course or enroll for credit and receive a grade of Pass or Fail. The cost to audit the course is the same as enrolling for credit. Those who want an electronic registration form or who have questions about the course should send a message to Eric Johnson ERIC@SDNET.BITNET -- Guy Helmer, Dakota State University Computing Services - ghelmer@dsuvax.dsu.edu "Often you fix the wrong thing first." - Karl Auerbach, Interop 91 From icon-group-request Sat Apr 25 07:57:29 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Apr 92 07:57:29 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA00354; Sat, 25 Apr 92 07:57:27 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA28185; Sat, 25 Apr 92 07:41:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 92 05:53:27 GMT From: cs.utexas.edu!qt.cs.utexas.edu!yale.edu!cs.yale.edu!horne-scott@rutgers.edu (Scott Horne) Organization: Computer "Science" Dept, Yale University Subject: Re: Computer Programming for the Humanities Course Offering Message-Id: <1992Apr25.055327.19926@cs.yale.edu> References: <1992Apr24.162006.6210@dsuvax.dsu.edu>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article , ara@zurich.ai.mit.edu (Allan Adler) writes: ghelmer@dsuvax.dsu.edu (Guy Helmer) writes: < < Students will be sent a disk containing a public-domain < SNOBOL4 compiler and a text editor. HA! Why not send them vacuum tubes and copper wire? Yes. References: <1992Apr14.173407.28762@adobe.com>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In this discussion of Icon features in Lisp, I'm surprised that no one has mentioned the obvious embedding of Icon-like control in Scheme. (If someone did, I missed it.) ; For Icon's alternation operator a | b | c, write (either a b c). (define-syntax either (syntax-rules () ((either x) x) ((either x y ...) (%either (lambda () x) (lambda () (either y ...)))))) (define (%either thunk1 thunk2) ;Macro axuiliary (let ((save *fail*)) ((call-with-current-continuation (lambda (k) (set! *fail* (lambda () (set! *fail* save) (k thunk2))) thunk1))))) ; (accumulate a) returns a list of all the possible values of the ; expression a. Prolog calls this "bagof"; I forget what Icon calls it. (define-syntax accumulate (syntax-rules () ((accumulate x) (%accumulate (lambda () x))))) (define (%accumulate thunk) (let ((results '())) (either (begin (set! results (cons (thunk) results)) (fail)) (reverse results)))) ; Generate all the members of list l. E.g. ; (accumulate (+ (member-of '(10 20 30)) (member-of '(1 2 3)))) ; => '(11 12 13 21 22 23 31 32 33) (define (member-of l) (if (null? l) (fail) (either (car l) (member-of (cdr l))))) ; Internal variable representing the failure stack. (define (fail) (*fail*)) (define *fail* (lambda () (error "You didn't do (init)."))) ; Crufty initialization hack that allows you to type failing ; expressions at the R-E-P loop (if there is an R-E-P loop). E.g. try ; evaluating the sequence ; (either 1 2) ; (fail) ; (+ (fail) 10) (define (init) (call-with-current-continuation (lambda (k) (set! *fail* (lambda () (k 'failed))) 'initialized))) (display "Type (init) at the read-eval-print loop.") (newline) -- -- Jonathan Rees jar@cs.cornell.edu member, Cambridge Entomological Club / member, League for Programming Freedom From icon-group-request Sat Apr 25 19:30:16 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sat, 25 Apr 92 19:30:16 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA17509; Sat, 25 Apr 92 19:30:09 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA16070; Sat, 25 Apr 92 19:22:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 92 21:27:53 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!hri.com!noc.near.net!chaos!random.ccs.northeastern.edu!news@ucbvax.berkeley.edu (mitchell wand) Organization: College of Computer Science, Northeastern University Subject: Re: Computer Programming for the Humanities Course Offering Message-Id: References: <1992Apr24.162006.6210@dsuvax.dsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu I didn't think there were any living SNOBOL programmers left! But seriously, I can't imagine doing applications in the humanities such as analysis of texts, arranging data from research, and formatting for printing and desktop publishing. in SNOBOL, which is hardly an industrial-strength language with widespread support! If you want to teach humanists about programming, use Friedman and Felleisen's {Little Lisper}, which converts everything to the kind of game even humanists can understand (:-). If you want to do quick-and-dirty text processing, you can either use Scheme or awk or Icon (or even C!), all of which are widely supported. If you want to do formatting and desktop publishing, you'd be far better off using all the good tools that are available for that, rather than struggling to do it in SNOBOL. [OK, my flameproof suit is on now.] --Mitch -- Mitchell Wand College of Computer Science, Northeastern University 360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 437 2072 Internet: wand@{corwin|flora}.ccs.northeastern.edu Fax: (617) 437 5121 From @um.cc.umich.edu:Paul_Abrahams@MTS.cc.Wayne.edu Sun Apr 26 11:11:55 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Sun, 26 Apr 92 11:11:55 MST Received: from mailrus.cc.umich.edu by optima.cs.arizona.edu (4.1/15) id AA10847; Sun, 26 Apr 92 11:11:52 MST Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.61/1123-1.0) id AA26427; Sun, 26 Apr 92 14:07:50 -0400 Received: from MTS.cc.Wayne.edu by um.cc.umich.edu via MTS-Net; Sun, 26 Apr 92 14:09:23 EDT Date: Sun, 26 Apr 92 14:08:36 EDT From: Paul_Abrahams@mts.cc.wayne.edu To: icon-group@cs.arizona.edu Message-Id: <448138@MTS.cc.Wayne.edu> Subject: Icon versus Snobol for the humanities I agree with Mitch Wand's statement that Icon is far superior to Snobol for the kinds of stuff that people do in the humanities (or for nearly anything else, for that matter). (I wouldn't inflict Lisp on anyone with no ambitions to be a professional programmer, however.) But I think Mitch overlooks one important consideration: if you're used to using Language A, there's a considerable cost in switching to Language B even if Language B is better. If programming is not your main ambition in life, you may be far better off sticking with the devil you know than the one you don't. The arguments for switching from Snobol to Icon are much like the arguments for replacing your old clunker with a new car. If the clunker gets you where you want to go and the repair bills aren't too high, sticking with it is probably your most rational choice. On the other hand, if you know you're going to have to switch eventually, it's better to do it sooner than later. Paul Abrahams abrahams@mts.cc.wayne.edu From janpeter@mpi.kun.nl Mon Apr 27 01:22:36 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 01:22:36 MST Received: from wn1.sci.kun.nl by optima.cs.arizona.edu (4.1/15) id AA06758; Mon, 27 Apr 92 01:22:30 MST Received: by wn1.sci.kun.nl (5.57/2.1) on NUNET id AA29188; Mon, 27 Apr 92 10:23:26 +0200 Received: by mpix10.mpi.kun.nl (5.57/2.0) on NUNET id AA04874; Mon, 27 Apr 92 10:22:58 +0200 Date: Mon, 27 Apr 92 10:22:58 +0200 From: Jan Peter de Ruiter Message-Id: <9204270822.AA04874@mpix10.mpi.kun.nl> To: icon-group@cs.arizona.edu Subject: snoboldtimer I do entirely agree with what Mitch wrote about Snobol, although there is a certain "oldtimer" feeling connected to SNOBOL programming. Like people driving around in old cars, just because they are old. Besides, SNOBOL is to my knowledge the only computer language that combines the speed of LISP with the elegance of assembly language. Jan. Jan Peter de Ruiter Max Planck Institute for Psycholinguistics The Netherlands janpeter@mpi.kun.nl From icon-group-request Mon Apr 27 08:47:11 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 08:47:11 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA22083; Mon, 27 Apr 92 08:47:09 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA27876; Mon, 27 Apr 92 08:33:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Apr 92 14:50:08 GMT From: sdd.hp.com!wupost!dsuvax.dsu.edu!ghelmer@hplabs.hpl.hp.com (Guy Helmer) Organization: Dakota State University Subject: Re: Computer Programming for the Humanities Course Offering Message-Id: <1992Apr27.145008.22240@dsuvax.dsu.edu> References: <1992Apr24.162006.6210@dsuvax.dsu.edu>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In ara@zurich.ai.mit.edu (Allan Adler) writes: >In article <1992Apr24.162006.6210@dsuvax.dsu.edu> ghelmer@dsuvax.dsu.edu > (Guy Helmer) posted: >> Following is information about a three-credit graduate course >> in programming for the humanities offered by Dakota State >> University via BITNET (and other interconnected networks). >> [ details of the course deleted] >> The total cost of the course is $xxx.xx. No textbook is ^^^^^^ Actual cost deleted to avoid affending even more readers. :-) >> required. Students will be sent a disk containing a public-domain >> SNOBOL4 compiler and a text editor. Lectures and data files will >> be sent electronically. >I think this counts as commercial advertising. If someone wants to make the >course materials available to people via anonymous ftp, that is one thing. >If someone wants to organize a network of volunteers to help people in the >humanities learn computers, that is still ok. But this is pure commerce. OK, this may be considered "commercial" advertising by some, but I submit it it not "pure commerce", because: 1) This is an experimental program offering, where the experiment is to offer an unusual course worldwide to users of the net, who, without benefit of the Internet, would not be able to take advantage of the offering. 2) In the spirit of the course (using Internet as the delivery medium), the best method to contact potential "virtual attendees" is Usenet. A very large share of the Internet is funded this moment to promote communication between research and educational institutions, which is what this course is based on. 3) Given tight budgets, lack of support, and funding of time, the academic community must develop "free courses" so that we may post announcements of innovative, experimental, one-of-a-kind opportunities to Usenet? >Aren't there rules about this sort of thing? :-) Rules on Usenet? Seriously, I will grant that perhaps it would have been "more proper" and "less offending" to have posted summary information. However, I have a very hard time finding differences between my posting and the postings you will find in news.announce.conferences, and I don't see y'all flaming each post in n.a.c that lists course costs and materials provided. Followups to misc.misc, since this thread probably doesn't interest everyone. >Allan Adler >ara@altdorf.ai.mit.edu -- Guy Helmer, Dakota State University Computing Services - ghelmer@dsuvax.dsu.edu "Often you fix the wrong thing first." - Karl Auerbach, Interop 91 From icon-group-request Mon Apr 27 10:01:06 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 10:01:06 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA25521; Mon, 27 Apr 92 10:01:02 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA01341; Mon, 27 Apr 92 09:55:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Apr 92 21:25:52 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.berkeley.edu (Richard L. Goerwitz) Organization: University of Chicago Computing Organizations Subject: Re: Computer Programming for the Humanities Course Offering Message-Id: <1992Apr24.212552.9948@midway.uchicago.edu> References: <1992Apr24.162006.6210@dsuvax.dsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu While we're at it, I'd like to advertize a course in COBOL and FORTRAN programming for computer science students. An advanced course in BASIC will be offered as well. -- -Richard L. Goerwitz goer%ellis@uchicago.bitnet goer@ellis.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-request Mon Apr 27 14:32:41 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 14:32:41 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA09622; Mon, 27 Apr 92 14:32:38 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA12719; Mon, 27 Apr 92 14:15:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 92 01:41:36 GMT From: mintaka.lcs.mit.edu!zurich.ai.mit.edu!ara@yale-bulldog.arpa (Allan Adler) Organization: M.I.T. Artificial Intelligence Lab. Subject: Re: Computer Programming for the Humanities Course Offering Message-Id: References: <1992Apr24.162006.6210@dsuvax.dsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr24.162006.6210@dsuvax.dsu.edu> ghelmer@dsuvax.dsu.edu (Guy Helmer) writes: Following is information about a three-credit graduate course in programming for the humanities offered by Dakota State University via BITNET (and other interconnected networks). Students in the course can be anywhere in the world if they can send and receive electronic mail. [ details of the course deleted] The total cost of the course is $239.82. No textbook is required. Students will be sent a disk containing a public-domain SNOBOL4 compiler and a text editor. Lectures and data files will be sent electronically. Students may audit the course or enroll for credit and receive a grade of Pass or Fail. The cost to audit the course is the same as enrolling for credit. Those who want an electronic registration form or who have questions about the course should send a message to I think this counts as commercial advertising. If someone wants to make the course materials available to people via anonymous ftp, that is one thing. If someone wants to organize a network of volunteers to help people in the humanities learn computers, that is still ok. But this is pure commerce. Aren't there rules about this sort of thing? Allan Adler ara@altdorf.ai.mit.edu From icon-group-request Mon Apr 27 15:16:23 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Mon, 27 Apr 92 15:16:23 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA11850; Mon, 27 Apr 92 15:16:22 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA15775; Mon, 27 Apr 92 15:12:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 92 01:37:07 GMT From: s5!sethb@uunet.uu.net (Seth Breidbart) Organization: Morgan Stanley & Co., New York, NY Subject: Re: Computer Programming for the Humanities Course Offering Message-Id: <1992Apr25.013707.17137@fid.morgan.com> References: <1992Apr24.162006.6210@dsuvax.dsu.edu>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article wand@corwin.ccs.northeastern.edu writes: >I didn't think there were any living SNOBOL programmers left! Well, I was once paid for programming in SNOBOL. Does that count? (But I remember how surprised I was the only time I saw a "help wanted" ad for a SNOBOL programmer!) >in SNOBOL, which is hardly an industrial-strength language with widespread >support! No, but it's a lot of fun! Seth sethb@fid.morgan.com From shafto@eos.arc.nasa.gov Tue Apr 28 13:43:08 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 28 Apr 92 13:43:08 MST Received: from eos.arc.nasa.gov by optima.cs.arizona.edu (4.1/15) id AA03700; Tue, 28 Apr 92 13:43:06 MST Received: Tue, 28 Apr 92 13:42:28 -0700 by eos.arc.nasa.gov (5.57/1.2) Date: Tue, 28 Apr 92 13:42:28 -0700 From: Michael Shafto Message-Id: <9204282042.AA26038@eos.arc.nasa.gov> To: icon-group@cs.arizona.edu, s5!sethb@uunet.uu.net Subject: Re: Computer Programming for the Humanities Course Offering Cc: shafto@eos.arc.nasa.gov s5!sethb@uunet.uu.net (Seth Breidbart): "wand@corwin.ccs.northeastern.edu writes: ' ... SNOBOL, which is hardly an industrial-strength language ... '" It's sure no PL/I or Ada! To paraphrase a phrase, "To really mess things up, you need an international standards committee!" Mike From icon-group-request Tue Apr 28 19:33:46 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Tue, 28 Apr 92 19:33:46 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA16798; Tue, 28 Apr 92 19:33:44 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA28705; Tue, 28 Apr 92 19:24:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Apr 92 04:41:35 GMT From: mips!munnari.oz.au!goanna!ok@decwrl.dec.com (Richard A. O'Keefe) Organization: Comp Sci, RMIT, Melbourne, Australia Subject: Re: features from Icon Language in lisp Message-Id: <10400@goanna.cs.rmit.oz.au> References: <1992Apr14.173407.28762@adobe.com>, , <1992Apr25.185854.1374@cs.cornell.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr25.185854.1374@cs.cornell.edu>, jar@cs.cornell.edu (Jonathan Rees) writes: > In this discussion of Icon features in Lisp, I'm surprised that no one > has mentioned the obvious embedding of Icon-like control in Scheme. Thanks for posting it. > ; (accumulate a) returns a list of all the possible values of the > ; expression a. Prolog calls this "bagof"; I forget what Icon calls it. Wrong. Prolog calls it findall/3. There is a *MAJOR* difference between findall/3 and bagof/3, which is not relevant to Scheme. For what it's worth, some functional languages call this "list comprehension". A stream-based version can be found in SICP, of course. -- I am writing a book on debugging aimed at 1st & 2nd year CS students using C/Modula/Pascal-like languages. Please send suggestions (other than "you _must_ cite "C Traps and Pitfalls") to ok@goanna.cs.rmit.oz.au From TENAGLIA@mis.mcw.edu Wed Apr 29 04:23:53 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Wed, 29 Apr 92 04:23:53 MST Received: from ADM.MIS.MCW.EDU by optima.cs.arizona.edu (4.1/15) id AA08177; Wed, 29 Apr 92 04:23:49 MST Received: from mis.mcw.edu by mis.mcw.edu (PMDF #12865) id <01GJERGZM7PCBXIVW3@mis.mcw.edu>; Wed, 29 Apr 1992 06:24 CST Date: Wed, 29 Apr 1992 06:24 CST From: Chris Tenaglia - 257-8765 Subject: Icon Performance Tuning To: icon-group@cs.arizona.edu Message-Id: <01GJERGZM7PCBXIVW3@mis.mcw.edu> X-Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" I've enjoyed the Icon Newsletter and Icon Analyst and their mentioning of tuning and profiling iconware from algorythmic, and implementation viewpoints. But I'm wondering if there has been much done from the host OS point of view to make things run more smoothly. ------------------------------------------------------------------------ VMS : Has several hundred parameters that control memory and disk use. You change a parameter by editing a file, run a utility, and then rebooting. Unix: I think has a similar operation. You edit a parameter file (actually part of a C program) and then 'rebuild' the kernel. DOS : Has CONFIG.SYS with things like FILES, BUFFERS, and other possible memory management doodads. MAC and others : I haven't the foggiest idea ------------------------------------------------------------------------ I'm most interested in DOS at the moment. I'm wondering if anyone has tinkered with FILES, BUFFERS, or running Icon in a LAN (PathWorks mostly, but Novell and Banyan comments are also welcome). Perhaps one has had to actually be in the guts of Icon to know what to do? I have some IO intensive programs, and they actually run slower than interpreted BASICA. (and it's not just inefficient icon code). Any pointers or hints would be greatly appreciated. I use Icon 5.9 (mostly) & 8.0 (sometimes) on DOS 3.3, but I don't think IO methods have changed that much. Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu From icon-group-request Fri May 1 10:46:31 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 1 May 92 10:46:31 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA20861; Fri, 1 May 92 10:46:28 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA01504; Fri, 1 May 92 10:33:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Apr 92 15:22:35 GMT From: ogicse!mintaka.lcs.mit.edu!zurich.ai.mit.edu!ara@decwrl.dec.com (Allan Adler) Organization: M.I.T. Artificial Intelligence Lab. Subject: Re: Computer Programming for the Humanities Course Offering Message-Id: References: <1992Apr27.145008.22240@dsuvax.dsu.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr29.123915.3952@jlc.mv.com> john@jlc.mv.com (John Leslie) writes: In article stephen@estragon.uchicago.edu (Stephen P Spackman) writes: > >A society that makes charging for sex illegal and considers charging >for information only proper is *very seriously twisted*. > As it turns out, there's a very good reason for governments to prohibit free market sex -- the extreme costs of AIDS treatment make it entirely impractical to regulate such a market and allocate the true costs. Surely today's Internetters don't _still_ believe that *information* is as harmful? :) John Leslie The cost of ignorance is also quite high. That is a good argument for free information. Allan Adler ara@altdorf.ai.mit.edu From icon-group-request Fri May 1 18:32:50 1992 Received: from optima.cs.arizona.edu by cheltenham.cs.arizona.edu; Fri, 1 May 92 18:32:50 MST Received: from ucbvax.Berkeley.EDU by optima.cs.arizona.edu (4.1/15) id AA07779; Fri, 1 May 92 18:32:46 MST Received: by ucbvax.Berkeley.EDU (5.63/1.43) id AA00208; Fri, 1 May 92 18:20:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Apr 92 04:38:48 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!hardy.u.washington.edu!ericfw@ucbvax.berkeley.edu (Eric F.) Organization: University of Washington, Seattle Subject: Re: Computer Programming for the Humanities Course Offering Message-Id: <1992Apr28.043848.17093@u.washington.edu> References: , <1992Apr27.145008.22240@dsuvax.dsu.edu>, <1992Apr28.013928.873@coyote.datalog.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu In article <1992Apr28.013928.873@coyote.datalog.com> jmh@coyote.datalog.com (John Hughes) writes: >In article <1992Apr27.145008.22240@dsuvax.dsu.edu> ghelmer@dsuvax.dsu.edu (Guy Helmer) writes: >>In ara@zurich.ai.mit.edu (Allan Adler) writes: >> >>>In article <1992Apr24.162006.6210@dsuvax.dsu.edu> ghelmer@dsuvax.dsu.edu >>> (Guy Helmer) posted: >> >>>> Following is information about a three-credit graduate course >>>> in programming for the humanities offered by Dakota State >>>> University via BITNET (and other interconnected networks). >>>> [ details of the course deleted] >>>> The total cost of the course is $xxx.xx. No textbook is >> ^^^^^^ >>Actual cost deleted to avoid affending even more readers. :-) [arguments concerning whether this is or is not commercial advertising] >>>Aren't there rules about this sort of thing? >> >>:-) Rules on Usenet? >> [more deletia] > >I've been watching the various reactions to the original posting with some >mixed feelings. It is a source of puzzlement to me as to why there aren't >more readily accessible venues for this type of "alternative" education >(please spare me the comments about the comp. sci. degrees by mail in the >Popular Mechanics ads). I, for one, would welcome the opportunity to acquire >additional education in a form that wouldn't tax my already overloaded >school and work schedules. Also, since this is a course offered for credit >by a (presumably) accredited, non-profit academic institution, I don't >really see where it fits into the same category as, say, IBM or DEC trying >to use the Internet to sell their latest workstations. And, as Guy points >out, there really isn't much difference between the posting for the course >offering and those seen regularly for various and sundry conferences. >Perhaps there should be a move to ban conference notices which go into >long and gory detail (including costs). > >But seriously, the technolgy and resources now exist to allow this type of >"electronic classroom" to exist in a way never before possible. I would >suggest that the collective minds of the Internet consider the possibilities >and weigh the benefits before hastily brandishing the "non-commercial" >club and beating such postings senseless. I can make a suggestion: Advertising 'products' that are in whole or in major part information is OK, advertising tangible goods is out. For example, the following could be sold through the net: Software, counseling, on-line magazines and periodicals, training, legal advice, etc. The following would not be OK: Computers, cars, food, booze, condominiums, condoms....etc. The usual classified ad type stuff would still be OK(by the way, I have a used AT for sale ;->). Just a suggestion from off the top of my head. Flame away; I am interested in comments. Especially interested in counter-suggestions. =Eric