From rad@MITRE-BEDFORD@UDel.CSNET Thu Jan 3 08:40:08 1985 From: rad@MITRE-BEDFORD.CSNET To: ralph%arizona.csnet@CSNET-RELAY.CSNET Cc: icon-group%arizona.csnet@CSNET-RELAY.CSNET Subject: Re: Icon Newsletter #16 In-Reply-To: Your message of Thursday, 27 Dec 1984 17:00-EST. <8412272200.AA03363@arizona.UUCP> Status: R >Icon Newsletter #16 was sent out several weeks ago (bulk rate in the United >States). If you are on the mailing list but have not received your copy, >let me know (and provide a postal address). Nope, haven't seen one yet. I would like to receive one, though. My mail address is: Dick Dramstad c/o The MITRE Corp., M/S B065 Burlington Road Bedford, MA 01730 Thanks, Dick D. rad@mitre-bedford.arpa From rad@MITRE-BEDFORD@UDel.CSNET Tue Jan 15 12:38:39 1985 From: rad@MITRE-BEDFORD.CSNET To: info-pyramid@MARYLAND.CSNET, Icon-Group.Arizona@CSNET-RELAY.CSNET Sender: "Dick Dramstad"@MITRE-BEDFORD.CSNET Subject: Icon ported to Pyramid? Status: R I'm curious as to whether anyone has ported Icon to the Pyramid 90x Unix supermini yet. Is anyone working on it? I'd be glad to post a recap of replies if there's enough interest. Dick Dramstad rad@mitre-bedford.arpa From whm Mon Jan 21 19:08:30 1985 From: whm (Bill Mitchell) To: icon-group@arizona, sun-spots@rice.CSNET Subject: Icon for the Sun Workstation Status: R We are pleased to announce the availability of Release 5.9 of the Icon programming language for the Sun workstation. This release of Icon is known to work on Sun's Release 1.2. Assuming the Sun documentation is correct, Icon should also work on releases dating back as far as 0.4, but this has not been substantiated. The Sun-specific code is an addition to our current distribution for UNIX VAXs and split I/D PDP-11s with V7; the new distribution can be configured to run on any of these three types of systems. Icon is entirely in the public domain and complete source code for all system components is included. To get an Icon system, please t/nroff the form below with -ms, complete it, and send it in along with a 1/2" 9-track reel tape at least 600 feet long. All tapes are written in tar format. Please note that the only available distribution media is 1/2" reel tape; we do not have facilities to write 1/4" tape cartridges. The only up-to-date and complete documentation of Version 5 of Icon is contained in the following book (generally referred to as "the Icon book"): The Icon Programming Language, Ralph E. Griswold and Madge T. Griswold. Prentice-Hall, Inc., Englewood Cliffs, NJ. 1983. 313 pages, paperback. This book should be available through any seller of new books. It is not available through the University of Arizona. There is a brief (9-page) overview of Icon available as University of Arizona technical report TR 83-3a. This report will be sent via the Postal Service, free of charge, to anyone who requests it. The Icon run-time system has knowledge of C stack frames and thus this version may or may not work on other 68000 systems. I'll be circulating around the UniForum vendor show to attempt to determine what other machines this version of Icon might work on if any. Requests for further information about Icon should be directed to: icon-project.arizona@csnet-relay -or- {noao,mcnc,purdue,utah-cs}!arizona!icon-project We try to answer all mail promptly; if you do not receive a response to your letter in a day or two, it is quite possible that a letter was lost somewhere along the line. In such cases, please try again. Bill Mitchell Request form: ============= .nr LL 6.5i .ds CF .de LE \l'3.9i' .sp 1 .. .de Ip .IP "\\$1" 25 .LE .. .LP .ce 1 \f3Version 5.9 UNIX Icon Distribution Request\fR .sp 2 \fINote:\fR This system can be configured for PDP-11s with separate I and D spaces, VAX-11s, or Sun workstations. .sp 1.5 Contact Information: .sp 1 .Ip name .Ip address .LE .LE .LE .Ip telephone .Ip "electronic mail address" .sp 1 .Ip computer .Ip "operating system" .sp 1 .LP All tapes are written in 9-track \fItar\fR format. Preferred tape recording density: .sp 1 \(sq 1600 bpi\h'|1.8i'\(sq 800 bpi .sp 1.2 Return this form to: .DS Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 .DE Enclose a magnetic tape (at least 600\(fm) \fIor\fR a check for $15 payable to the University of Arizona. From whm Sun Feb 3 04:14:37 1985 From: whm (Bill Mitchell) To: rad@Mitre-Bedford.CSNET Subject: Re: Icon ported to Pyramid? Cc: icon-group@Arizona, info-pyramid@Maryland.CSNET Status: R We've had a lot of interest in Icon for the Pyramid, but we think that the current implementation can't possibly work a Pyramid due to the way that the Pyramid stack is implemented. The basic capability that the current implementation of Icon needs is to be able to duplicate a portion of the stack in such a way that a piece of code such as: f(a,b,c) { dupframe(); printf("a = %d, b = %d, c = %d\n",a,b,c); return; } Will execute the printf twice, dupframe having duplicated the top of the stack thus causing the return to be manifested as a return from dupframe rather than from f. (Things are lots more complicated than this, but if the above could be done, then Icon could probably be made to work.) We're in the process of obtaining a Pyramid architecture manual to see if we can settle this question once and for all. Bill Mitchell p.s. Sorry to have not replied sooner; for some reason your mail didn't get redistributed to the local Icon-Group members here at Arizona and I just happened to stumble across your note a couple of days ago. From whm Thu Feb 14 07:40:53 1985 From: whm (Bill Mitchell) To: icon-group@arizona Subject: Sorry about... Status: R ...this test. Looks like we're losing messages right and left somehow. From whm Thu Feb 14 08:04:42 1985 From: whm (Bill Mitchell) To: icon-group Subject: More testing Status: R Still looking for the problem... From whm Thu Feb 14 08:35:29 1985 From: whm (Bill Mitchell) To: icon-group@arizona Subject: Icon-Group mail lossage? Status: R It looks like we may be having some mail lossage in Icon-Group; I've heard some reports of mail that we don't have any evidence of locally. According to our records, the last five messages were: Dec 27 ralph@Arizona "Icon News Letter #16" Jan 3 rad@Mitre-Bedford "Re: Icon News Letter #16" Jan 15 rad@Mitre-Bedford "Icon Ported to Pyramid?" Jan 21 whm@Arizona "Icon for the Sun Workstation" Feb 3 whm@Arizona "Re: Icon Ported to Pyramid?" If you've sent any other messages since Dec 27, please send them again if you would, and also send a copy to me personally. Also, if you haven't seen all of the above messages, send me a note about that as well. Thanks, Bill Mitchell From icon%ucbmonet@UCB-VAX@UDel.CSNET Fri Feb 15 08:12:50 1985 From: "Icon (U of Arizona" Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA To: icon-group%arizona@CSNET-RELAY.CSNET Subject: Testing... Status: R Sorry about this test. Bill Mitchell From whm@lectura Fri Feb 15 08:42:44 1985 From: whm@lectura (Bill Mitchell) To: icon-group@arizona Subject: Even more testing Status: R What can I say? From ucbvax!zehntel!zinfandel!ed Sat Feb 23 04:02:49 1985 From: ucbvax!zinfandel!ed (Ed Hirgelt) Subject: Dynamic loading for Icon To: zehntel!ucbvax!arizona!icon-group Status: R An idea: Is it reasonable? Has someone done it? The dynamic loading feature of ld (on 4.1 and 4.2) allows the program to load a function at run-time and execute it. It is possible to build up libraries of such run-time routines and call them as needed. This lets me build a general purpose system that a user can customize by specifying his own set of procedures. It seems that it should be straight-forward to do this with Icon. Has anyone done this? Is it as straight-forward as I think? What are the problems I can expect to run into if I attempt this? Thanks, Ed ---------------------------------------------------------------- Ed Hirgelt Zehntel Automation Systems 2625 Shadelands Drive Walnut Creek, Ca 94598 ihnp4!zehntel!ed decvax!sytek!zehntel!ed From whm Sun Feb 24 02:18:57 1985 From: whm (Bill Mitchell) To: ihnp4!zenhtel!ed Subject: Re: Dynamic loading for Icon Cc: icon-group Status: R There are essentially two problems with dynamic loading: Where in memory are the functions going to go? Icon uses a compacting garbage collector and has no provision for non- relocatable items in the heap. A cheap way around this would be to just grab a block of memory that lies before the co-expression stacks. A more elaborate scheme would involve adding a general way to allocate non-relocatable memory at run-time. How are the functions going to be invoked? Currently, builtin functions and Icon procedures are represented by global variables which reference a procedure block that contains pertinent information about the function. The globals are stored in an array, so adding a global would mean expanding the array. Again, this can be hacked by just having some extra space in the global array. An additional problem is actually referencing the global variable that names a newly-loaded procedure. The linker has knowledge of all the possible function names, so it turns a reference to a global variable into a reference into the global variable array. You'd need a way to reference newly-loaded globals. If you're willing to specify functions to load at translation time, the (now-defunct) compiler's "external" keyword could be reintroduced and you could load the functions and layout the global array as part of the initialization phase of the interpreter. A project that I did about a year ago, which was the incorporation of Icon as a subsystem in Unipress Emacs as sort of a sibling of MLisp, solved the above problems and allowed one to load Icon procedures dynamically. I think it would be fairly trivial to augment this system to load C functions dynamically. The current interface is via "load(f)", which loads the interpretable file named by f, incorporating the definitions f contains for globals, records, and Icon procedures. To make this work for C, load could be modified to look at f and determine if it is an interpretable file or a C object file. If a C object file, just link against the interpreter and load the result. Hmmm, that sounds so easy I might just do it. Report TR 84-8 describes the system alluded to above; we can send you a copy of the report if you'd like. Bill Mitchell p.s. for everybody: It looks like I've fixed the distribution problems I mentioned several days ago. If you *didn't* receive the message this note is a response to, please let me know. Thanks. From G.TI.DAK@UTEXAS-20@UDel.CSNET Fri Mar 8 07:41:56 1985 From: G.TI.DAK@UTEXAS-20.CSNET Subject: Please drop To: icon-group%arizona.csnet@CSNET-RELAY.CSNET Status: R Please drop G.TI.DAK@Utexas from you mail distribution ------- From ralph Wed Mar 20 07:06:24 1985 From: ralph (Ralph Griswold) To: icon-group@arizona Subject: Icon Newsletter #17 Status: R Icon Newsletter #17 is in the mail. Bulk rate is used for addresses in the United States, so it may take a couple of weeks to get to everyone. There is an error on the form in the Newsletter for requesting Version 5.9 of Icon for VAX/VMS -- it says tapes are written in tar format. In fact, they are written in VMS COPY format. From ralph@bocklin Wed Aug 21 21:01:24 1985 From: ralph@bocklin (Ralph Griswold) To: icon-group@arizona Subject: Next Icon Newsletter Status: R We are in the process of assembling the next Icon Newsletter. If you have something to contribute, a suggestion, or whatever, let me know. Possibilities are comments on language features, experiences using Icon, applications, suggestions for the Programming Corner, and such. ralph.arizona@csnet-relay From gudeman@bocklin Thu Aug 22 18:51:03 1985 From: gudeman@bocklin (David Gudeman) To: icon-group@az Subject: condition-at-end loops Status: R Many programming languages have loops which do the test at the end of the loop instead of the beginning (i.e., do-while loop in C, repeat-until loop in Pascal). Although this structure is useful, (I won't argue *how* useful), it doesn't exist directly in Icon. If the Icon programmer wants such a construction, there are two choices, the first one (boring) is to use a repeat loop and insert an if at the end repeat { if then break } The other possibility takes advantage of Icon's expression structure, specifically the fact that {expr1; ...; exprn} returns the result sequence of exprn as its value (see TIPL page 80), so you can write while { } Obviously, it would work just as well to write until { not } This suggests an expression of the form every { } in which the generator would produce some sequence of results, but before each result, the body is executed. This does not work. (why not?) What structure will do what I wanted this one to do? From mark@bocklin Fri Aug 23 11:57:13 1985 From: mark@bocklin (Mark Langley) To: icon-group@arizona Subject: Controll Flow Discussion. Cc: icon@bocklin Status: R This is the summary of a recent mail discussion on which we would like to get feedback from the outside world. The subject is control flow. >From mark Wed Aug 21 15:53:00 1985 Subject: Stumper... Here is a (broke) baroque program. It uses only backtracking for control. And was an experiment to see if you could actually write a program which did something 'procedural' without ALGOL like control structures. procedure main() tab := "\t" words := lines := chars := 0 alphas := blanks := 0 (c := getc()) & (1) (chars +:= 1) & (2) (((c == "\n") & (lines +:= 1)) | 1) & (3) ((alpha(c) & (alphas +:= 1)) | 1) & (4) ((white(c) & (alphas := 0)) | 1) & (5) (((alphas = 1) & (words +:= 1)) \ 1 ) & (6) &fail end (janalee) the problem with using only backtracking is that what takes you forward also takes you back. (?) well, to be specific, you have used alternation to drive expression evaluation forward when necessary. for example, on the first letter of a file, the part of the expression labeled (5) will fail in white(), but the alternation takes evaluation forward to (6) and thus words is incremented. now the whole thing is forced to fail, which drives us back, but not back far enough. note that since (4) succeeded in alpha(), we still have the alternative of 1 left; so forward it goes, through (5) again and unfortunately to (6). hence the double word count. you used alternation in (4) because you need to go forward to recognize white space when something is not an alpha. maybe you chose the wrong alternative... (mark) Very Good. So I need to limit the results of (4) and (5) (... \ 1) I forgot that it would just try again... I really 'meant' to say something like here is a side-effect, keep going, and don't interfere with the backtracker... I guess, with all the seque stuff, you have given a lot of thought to the sort of thing which motivated this in the first place. Namely, what does one really *need* to make minimum control structures which are both necessary and sufficient to express the algorithmic conception. The problem, as I see it, is what control should be imbedded in explicit syntax and what in mechanisms like goal direction. I guess I am groping for a common denominator between the two... The above kind of problem is inherent in a language like prolog where the backtracking semantics are really all you have... Any thoughts? Anyone? (sbw) well, i know you can get by with: goal-directed evaluation, alternation, repeated evaluation, and limitation, if you also have &fail, &null, and conjunction. though it's a little like trying to do all math using only Peano's Postulates. (you might try to get an if-then-else control structure out of the above). (mark) Yea, you're right, it is a kind of Turing Tarpit, where everything is possible, but nothing easy. I guess what I would like is for the language environment to try to figure out which expression it should evaluate next (!). Namely, if it could figure out which expressions where *blocked* and which could possibly produce a result... Kind of like the way the UNIX kernel figures out which processes to schedule... First check to see if it is waiting for something, then try it. It seems like it be kind of like the way backward chained rule systems work (Gag Ack)... Namely, you determine if there is a goal to be satisfied, and what states (recursively) must be satisfied first. There are a lot of analogs to reaching definitions in compiler theory, too... The neat thing about this is that you wouldn't have to specify what order things get evaluated in, the language would figure that out. All you have to specify is how to get back to a stable-state... As such this turns the notion of an algorithm on its head! The way you would think about programming would be: imagine a stable state. How do you correct if you get away from it. The looming problem with this is whether this makes the process harder or easier! Namely, do you have to go back and think of a normal algorithm and then factor out the control, or do you think (really) in the two-stepper above. This is kind of an hallucinogen. Please kibitz! . . (sbw) Hey, this is neat stuff. How about giving me an example of a steady state program to mull over (i'm from the days when everyone still liked von Neumann). I've diddled with prolog a bit, so if that's what you mean... i've always wanted an icon machine where every expression was on a separate processor, anyway. (mark) Ok. What I originally had in mind was those class of programs which are typically stated as an infinite loop. Process control, operating system kernels etc. What the task involves then is essentially handling exceptions. Or, from another perspective, perhaps the loop-and-a-half problem, or the use of 'break' in C is not an artifact of sloppy coding, but is essential to algorithmic conception. The particular program I had in mind was a rule based expert system which does airplane navigation. What I would have *liked* it to look like was a series of exceptions which get called when they are needed. For example on time % 30 seconds == zero do a navigation update on A & B ... Assert C ... on C ... Thus I could have a general method for scheduling tasks, some of which need to be done all the time, and some of which need only be done when something special happens. (Note that this looks a lot like a (Blech) Rule Base.) One of the problems with the above beasts (Rule Bases) -- (Note how you want to touch them when they're safely behind parens)-- is some kind of intuitive inference structure such that you can specify what you want to do and determine the order it will get done in. Namely, one is hard pressed to find a rule base which, by itself, has even the conceptual power of simple fortran. Furthermore, rules are 'write only.' If the knowledge base does anything interesting, it becomes highly intractable. Cf debugging a grammar to debugging a program... And Presto, two problems (ie knowledge programming and control structures for programming language) are the same problem. Yes? PLEASE COMMENT! -- Thanks -- mark From rogerh Fri Aug 23 13:47:48 1985 From: rogerh (Roger Hayes) To: icon-group Subject: Re: Controll Flow Discussion. Newsgroups: fcs.icon-group In-Reply-To: <302@bocklin.UUCP> Organization: University of Arizona, Tucson Cc: Status: R Another neat way to think of specifying the behavior of a computer is by using "constraint langauges". The original of these was Sketchpad [Sutherland, mid-60's, not yet surpassed]. Another is Bertrand [Wm Leler, U. of N. Carolina + Tektronix -- I have a report somewhere]. The idea is that the programmer specifies what conditions are to be maintained, and the system figures out how to maintain them. The actual constraint satisfaction is a little like attribute computation in attribute grammars. For example, you can tell Bertrand a = 4 + c b = 2 * a c = a + b and ask it for any of a, b, or c. It actually precomputes how to satisfy constraints -- it doesn't do any backtracking; it just flows information forward as far as it can. This works surprisingly well. Things that (at last check) Wm Leler is still puzzling over are: How to handle ephemeral data -- this ties in with Mark's navagation problem, process control, graphics How to make it an online system -- at present, it's static; you submit the constraints, they are compiled, and the result pops out. From kwalker@bocklin Fri Aug 23 15:21:12 1985 From: kwalker@bocklin (Kenneth Walker) To: gudeman@bocklin Subject: Re: condition-at-end loops Cc: icon-group@arizona Status: R From gudeman Fri Aug 23 15:02:29 1985 Received: by bocklin.arizona.uucp (4.12/3.14) id AA24880; Fri, 23 Aug 85 15:02:26 mst Date: Fri, 23 Aug 85 15:02:26 mst From: gudeman (David Gudeman) Message-Id: <8508232202.AA24880@bocklin.arizona.uucp> To: kwalker Subject: condition-at-end loops ... This suggests an expression of the form every { } in which the generator would produce some sequence of results, but before each result, the body is executed. This does not work. (why not?) What structure will do what I wanted this one to do? This does not work because only the generator is resumed on each iteration. One solution is as follows: every (&null | ) & {; &null} The generator is skipped on the first iteration so the body of the loop is executed fisrt. On resumption, the second &null fails to produce another value, then the 1st &null fails to produce another value, so the generator is tried. If the generator succeeds, the body of the loop is evaluated again. The generator continues to be resumed and the body of the loop evaluated until the generator fails. Does anyone have a more elegant solution? From sbw@bocklin Mon Aug 26 10:13:25 1985 From: sbw@bocklin (Steve Wampler) To: gudeman@bocklin, kwalker@bocklin Subject: Re: condition-at-end loops Cc: icon-group@arizona Status: R From kwalker@bocklin Fri Aug 23 15:21:27 1985 Received: from arizona.uucp (arizona.ARPA) by bocklin.arizona.uucp (4.12/3.14) id AA25464; Fri, 23 Aug 85 15:21:12 mst Received: from bocklin.arizona.uucp (bocklin.ARPA) by arizona.uucp (4.12/3.14) id AA04433; Fri, 23 Aug 85 15:22:14 mst Received: by bocklin.arizona.uucp (4.12/3.14) id AA25456; Fri, 23 Aug 85 15:21:02 mst Date: Fri, 23 Aug 85 15:21:02 mst From: kwalker@bocklin (Kenneth Walker) Message-Id: <8508232221.AA25456@bocklin.arizona.uucp> To: gudeman@bocklin Subject: Re: condition-at-end loops Cc: icon-group@arizona From gudeman Fri Aug 23 15:02:29 1985 Received: by bocklin.arizona.uucp (4.12/3.14) id AA24880; Fri, 23 Aug 85 15:02:26 mst Date: Fri, 23 Aug 85 15:02:26 mst From: gudeman (David Gudeman) Message-Id: <8508232202.AA24880@bocklin.arizona.uucp> To: kwalker Subject: condition-at-end loops ... This suggests an expression of the form every { } in which the generator would produce some sequence of results, but before each result, the body is executed. This does not work. (why not?) What structure will do what I wanted this one to do? This does not work because only the generator is resumed on each iteration. One solution is as follows: every (&null | ) & {; &null} The generator is skipped on the first iteration so the body of the loop is executed fisrt. On resumption, the second &null fails to produce another value, then the 1st &null fails to produce another value, so the generator is tried. If the generator succeeds, the body of the loop is evaluated again. The generator continues to be resumed and the body of the loop evaluated until the generator fails. Does anyone have a more elegant solution? how about: every (&null | ) & ( \ 1) From gudeman@bocklin Thu Aug 29 13:21:09 1985 From: gudeman@bocklin (David Gudeman) To: icon-group@arizona Subject: Re: condition-at-end loops Status: R >>>From gudeman Fri Aug 23 15:02:29 1985 >>> every { >>> >>> >>> } >>> >>>What structure will do what I wanted this one to do? >>From kwalker@bocklin Fri Aug 23 15:21:27 1985 >> every (&null | ) & >> {; &null} >From sbw Mon Aug 26 10:13:17 1985 > every (&null | ) & ( \ 1) What's wrong with "do"? As long as you're going to cheat by having a fake value generated, you may as well use every &null | do I don't want everyone to get the idea that I may be a little miffed about Ken Walker's solution, just because I thought co-expressions were needed. Especially when he showed me his first draft of the solution, and I said it wouldn't work. (&null | ) & {; &fail} I chuckled knowingly and told him to try it, he did and it works. But I can take it like a man. The problem, as I saw it, was that you wanted parallel evaluation, which is hard to get in Icon. Ken observed that there is no resumption of , just re-evaluation. Of course, by the very nature of Icon evaluation, the second argument is re-evaluated when the first is resumed. Humph. I still say it's cheating. David Gudeman From ralph@bocklin Fri Sep 13 18:26:02 1985 From: ralph@bocklin (Ralph Griswold) To: icon-group@arizona Subject: Version 5.10 of Icon for UNIX Systems Status: R Version 5.10 of Icon for UNIX systems is now available for distribution. This distribution can be configured to run on the AT&T 3B20, the PDP-11, the Ridge 32, the Sun Workstation, and the VAX-11. The main features of this version are: New options for sorting tables that require less space. Faster execution than Version 5.9. Several bug fixes. Reorganization of the code to make porting easier. Version 5.10 of Icon is in the public domain. Program material and documentation is provided without charge. To obtain a copy, format the t/nroff text following the dashed line using -ms and mail it to us as indicated. -------------------------------------------------------------------- .nr LL 6.5i .ds CF .de LE \l'3.9i' .sp 1 .. .de Ip .sp -1 .IP "\\$1" 25 .LE .. .LP .ce 1 \f3Request for Version 5.10 of Icon for UNIX\fR .sp 1 .LP This implementation can be configured to run on the AT&T 3B20, the PDP-11, the Ridge 32, the Sun Workstation, and the VAX-11. The distribution package contains a brief description of Icon, installation instructions, and supporting documentation. Documentation regarding the porting of Icon to other computers is optional and is supplied only if requested below. .sp 1 .Ip name .Ip address .LE .LE .LE .Ip telephone .Ip "electronic mail address" .sp 1 .Ip computers .Ip "operating systems" .sp 1 .LP Tapes are written in 9-track \fIcpio\fR or \fItar\fR format. Specify preferred format and tape recording density: .sp .8 .in .5i \(sq cpio\h'|1.5i'\(sq tar .sp .5 \(sq 6250 bpi\h'|1.5i'\(sq 1600 bpi\h'|3i'\(sq 800 bpi .sp .8 .in 0 \(sq Enclose documentation on porting Icon to other computers. .sp .8 Send this form, together with a magnetic tape (600\(fm is sufficient) \fIor\fR a check for $20 payable to the University of Arizona, to: .DS .ft R Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 .DE From J.Dalton%edxa@UCL-CS@UDel Tue Sep 24 18:37:30 1985 From: DALTON FHL (on ERCC DEC-10) To: "icon-group.arizona" , J.Dalton%edxa@UCL-CS Subject: address change Status: R -------- Because of certain changes in Edinburgh, my network mail address will become invalid at the end of the week. My new address is just like the old, except that "edxa" must be replaced by "uk.ac.edinburgh". Thus, my new address is j.dalton%uk.ac.edinburgh@ucl-cs Please change your address list; the new address should already be valid. Cheers, Jeff Dalton, AIAI, University of Edinburgh sent on 24 Sep 85 -------- From ralph@bocklin Mon Sep 30 16:39:14 1985 From: ralph@bocklin (Ralph Griswold) To: icon-group@arizona Subject: Version 5.9 of Icon for MS-DOS Status: R An implementation of Version 5.9 of Icon for MS-DOS has been completed by Cheyenne Wills of Mechanicsburg, Pennsylvania. This implementation requires MS- or PC-DOS Version 2.0 or higher and has been tested on a number of computers, including the IBM PC, XT, and AT. It should run on any computer with an 8086/88/186/286-family processor; IBM hardware compatibility is not required. This is a small memory model implementation, using only two segments. As a result, the amount of space for Icon programs and data is limited. Nevertheless, many useful programs run quite well and this implementation offers many persons the opportunity to use Icon who otherwise could not. This implementation is in the public domain. We are distributing copies for the cost of media, handling, and shipping. To obtain a copy, format the t/nroff text following the dashed line using -ms and mail it to us with payment as indicated. -------------------------------------------------------------------- .nr LL 6.5i .ds CF .ds RF \s8\*(DY\s0 .de LE \l'3.9i' .sp 1 .. .de Ip .IP "\\$1" 25 .LE .. .LP \0 .br .sp 3 .ce 1 \f3Request for Version 5.9 of Icon for MS-DOS\fR .sp 2 .LP This system is distributed on a 5-1/4\(fm\(fm 2S/2D diskette. Enclose a check for $15 payable to the University of Arizona to cover the costs of media, handling, and shipping. .sp 2 Ship to: .sp 1 .Ip name .Ip address .LE .LE .LE .Ip telephone .Ip "electronic mail address" .sp 3 .LP Return this form with payment to: .DS Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 .DE From ralph@bocklin Sat Nov 30 06:35:40 1985 From: ralph@bocklin (Ralph Griswold) To: icon-group@arizona Subject: Icon Newsletter #19 Status: R Icon Newsletter #19 was mailed (bulk rate in the U.S.) early in October. If you haven't received your copy, presume it lost and send me a US mailing address for a replcement. Ralph Griswold arizona%ralph@csnet-relay From sbw@bocklin Sun Dec 15 19:07:12 1985 From: sbw@bocklin (Steve Wampler) To: icon-group@arizona Status: R I came across the following little ditty while cleaning out my files and thought people might like to play with it... The following is an Icon program to ngram analysis of text to develop a 'profile' of an author's style. It then produces randomly generated text in the same style. There are a number of sources of information on ngram analysis and the problem is well studied. To my mind, no language offers a 'cleaner' solution than Icon. ----ngrams.icn---- # the old million monkeys problem... # # the program uses ngram analysis to randomly generate text # in the same 'style' as the input text. arguments are: # # -s {show the input text} # -n n {use 'n' as the ngram size (default:4)} # -l n {output at most 'n' lines (default:10)}} # -r n {set random number seed to n} global showtxt procedure main(args) n := 4 linecount := 10 nextarg := create !args while arg := @nextarg do case arg of { "-s" : showtxt := "yes" "-n" : n := integer(@nextarg) "-l" : linecount := integer(@nextarg) "-r" : &random := integer(@nextarg) } ngrams := table() Show("Orginal Text is: \n\n") preline := "" every line := preline || !&input do { line ? { while ngram := move(n) & nextchar := move(1) do { /firstngram := Show(ngram) /ngrams[ngram] := "" ngrams[ngram] ||:= Show(nextchar) move(-n) } preline := tab(0) || "\n" } } Show("\n\nGenerating Sentences\n\n") ngram := writes(firstngram) while linecount > 0 do { if /ngrams[ngram] then stop() # if hit EOF ngram early ngram := ngram[2:0]||writes(nextchar:=?ngrams[ngram]) if (nextchar == "\n") then linecount -:= 1 } end procedure Show(text) if \showtxt then writes(text) return text end ----end of ngrams.icn---- sample output of the program follows. First the source text: ----ngram.dat----- If Youth, throughout all history, had had a champion to stand up for it; to show a doubting world that a child can think; and, possibly, do it practically; you wouldn't constantly run across folks today who claim that "a child don't know anything." A child's brain starts functioning at birth; and has, amongst its many infant convolutions, thousands of dormant atoms, into which God has put a mystic possibility for noticing an adult's act, and figuring out its purport. Up to about its primary school days a child thinks, naturally, only of play. But many a form of play contains disciplinary factors. "You can't do this," or "that puts you out," shows a child that it must think, practically, or fail. Now, if, throughout childhood, a brain has no opposition, it is plain that it will attain a position of "status quo," as with our ordinary animals. Man knows not why a cow, dog or lion was not born with a brain on a par with ours; why such animals cannot add, subtract, or obtain from books and schooling, that paramount position which Man holds today. -- The first two paragraphs of the novel "GADSBY", written by Ernest Wright (1939). GADSBY is unique in that the story consists of over 50,000 words, yet never uses the letter 'E'. ----end of ngram.dat--- Now, three different analyses, for 2grams, 4grams, and 7grams. ---2 gram output--- If primanin at cals. -- The links of You of the it pary factionly, ory runimannows this a folks a fol ding or was thatten that playsticho obtractod toms, doughout ad thaturs; a chin outs novel dongstichinstaing anythild's do ch of obtion't brampion wo cally; a plainfantand that th; wrinaturposs out," subticals nary Ernest pary sciplain whooks throssits nows ad hatten "th of do ormally, whistat not ithas an to a by suchinar 50,00 wildn't add, plithinat Writ ching." sciplaim the ---4 gram output--- If Youth, throughout a child thinks, naturally, only of the novel "GADSBY is plain that a mystic possibility for it; to about childhood, a brain starts functions, throughout child can that a child can that puts you wouldn't consists of over uses the novel "GADSBY is play. But many infant convolution was not add, subtractically, dog or fail. Now, dog or obtain has purport. ---7 gram output--- If Youth, throughout childhood, a brain has no opposition of "status quo," as with ours; why such animals. Man knows not why a cow, dog or lion was not born with a brain has no opposition, it is plain that it must think, practically; you wouldn't constantly run across folks today who claim that "a child thinks, naturally, only of play contains disciplinary factors. "You can't do this," or "that puts you out," shows a child that it will attain a position, it is plain that it will attain a position which Man holds today. -- The first two paragraphs of the novel "GADSBY", written ---end of sample runs--- The program is fun to run on MS-DOS icon, as it becomes obvious whenever the garbage collector kicks in. Some open questions: The program is very memory intensive, can that be improved, or does the problem inherently require tons of memory? The program is very weak on handling the last few characters of the text file. Can anyone suggest some improvements? -Steve Wampler From root@arizona Sun Dec 22 02:24:36 1985 From: root@arizona (Charlie Root) To: icon-group@arizona, sbw@arizona Subject: uucp mail delay at arizona Status: R During the period 12/15 to Dec. 12/21, a condition existed on the system 'arizona' that caused unreliable delivery of outgoing mail sent via uucp. It is believed that, fortunately, all mail that was not delivered properly, in addition to some that was delivered properly, accumulated in one of the uucp spool directories. Each of these such messages has been remailed to the intended recipient and the following message is one of them. As mentioned above, it is believed that no mail was lost, but it is probably advisable to "resynchronize" with any correspondents that you have been communicating with via 'arizona'. We sincerely apologize for this problem. Please mail to arizona!lab if you have any questions. Bill Mitchell UUCP Adminstrator Department of Computer Science The University of Arizona ---------- From sbw Sun Dec 15 19:09:14 1985 remote from arizona Received: by arizona.uucp (5.15/3.14) id AA06119; Sun, 15 Dec 85 19:09:14 MST Received: from arizona.uucp (arizona.ARPA) by bocklin.arizona.uucp (4.12/3.14) id AA29027; Sun, 15 Dec 85 19:07:12 mst Received: by arizona.uucp (5.15/3.14) id AA06086; Sun, 15 Dec 85 19:07:58 MST Received: by bocklin.arizona.uucp (4.12/3.14) id AA29021; Sun, 15 Dec 85 19:07:04 mst Date: Sun, 15 Dec 85 19:07:04 mst From: arizona!sbw (Steve Wampler) Message-Id: <8512160207.AA29021@bocklin.arizona.uucp> To: arizona!icon-group I came across the following little ditty while cleaning out my files and thought people might like to play with it... The following is an Icon program to ngram analysis of text to develop a 'profile' of an author's style. It then produces randomly generated text in the same style. There are a number of sources of information on ngram analysis and the problem is well studied. To my mind, no language offers a 'cleaner' solution than Icon. ----ngrams.icn---- # the old million monkeys problem... # # the program uses ngram analysis to randomly generate text # in the same 'style' as the input text. arguments are: # # -s {show the input text} # -n n {use 'n' as the ngram size (default:4)} # -l n {output at most 'n' lines (default:10)}} # -r n {set random number seed to n} global showtxt procedure main(args) n := 4 linecount := 10 nextarg := create !args while arg := @nextarg do case arg of { "-s" : showtxt := "yes" "-n" : n := integer(@nextarg) "-l" : linecount := integer(@nextarg) "-r" : &random := integer(@nextarg) } ngrams := table() Show("Orginal Text is: \n\n") preline := "" every line := preline || !&input do { line ? { while ngram := move(n) & nextchar := move(1) do { /firstngram := Show(ngram) /ngrams[ngram] := "" ngrams[ngram] ||:= Show(nextchar) move(-n) } preline := tab(0) || "\n" } } Show("\n\nGenerating Sentences\n\n") ngram := writes(firstngram) while linecount > 0 do { if /ngrams[ngram] then stop() # if hit EOF ngram early ngram := ngram[2:0]||writes(nextchar:=?ngrams[ngram]) if (nextchar == "\n") then linecount -:= 1 } end procedure Show(text) if \showtxt then writes(text) return text end ----end of ngrams.icn---- sample output of the program follows. First the source text: ----ngram.dat----- If Youth, throughout all history, had had a champion to stand up for it; to show a doubting world that a child can think; and, possibly, do it practically; you wouldn't constantly run across folks today who claim that "a child don't know anything." A child's brain starts functioning at birth; and has, amongst its many infant convolutions, thousands of dormant atoms, into which God has put a mystic possibility for noticing an adult's act, and figuring out its purport. Up to about its primary school days a child thinks, naturally, only of play. But many a form of play contains disciplinary factors. "You can't do this," or "that puts you out," shows a child that it must think, practically, or fail. Now, if, throughout childhood, a brain has no opposition, it is plain that it will attain a position of "status quo," as with our ordinary animals. Man knows not why a cow, dog or lion was not born with a brain on a par with ours; why such animals cannot add, subtract, or obtain from books and schooling, that paramount position which Man holds today. -- The first two paragraphs of the novel "GADSBY", written by Ernest Wright (1939). GADSBY is unique in that the story consists of over 50,000 words, yet never uses the letter 'E'. ----end of ngram.dat--- Now, three different analyses, for 2grams, 4grams, and 7grams. ---2 gram output--- If primanin at cals. -- The links of You of the it pary factionly, ory runimannows this a folks a fol ding or was thatten that playsticho obtractod toms, doughout ad thaturs; a chin outs novel dongstichinstaing anythild's do ch of obtion't brampion wo cally; a plainfantand that th; wrinaturposs out," subticals nary Ernest pary sciplain whooks throssits nows ad hatten "th of do ormally, whistat not ithas an to a by suchinar 50,00 wildn't add, plithinat Writ ching." sciplaim the ---4 gram output--- If Youth, throughout a child thinks, naturally, only of the novel "GADSBY is plain that a mystic possibility for it; to about childhood, a brain starts functions, throughout child can that a child can that puts you wouldn't consists of over uses the novel "GADSBY is play. But many infant convolution was not add, subtractically, dog or fail. Now, dog or obtain has purport. ---7 gram output--- If Youth, throughout childhood, a brain has no opposition of "status quo," as with ours; why such animals. Man knows not why a cow, dog or lion was not born with a brain has no opposition, it is plain that it must think, practically; you wouldn't constantly run across folks today who claim that "a child thinks, naturally, only of play contains disciplinary factors. "You can't do this," or "that puts you out," shows a child that it will attain a position, it is plain that it will attain a position which Man holds today. -- The first two paragraphs of the novel "GADSBY", written ---end of sample runs--- The program is fun to run on MS-DOS icon, as it becomes obvious whenever the garbage collector kicks in. Some open questions: The program is very memory intensive, can that be improved, or does the problem inherently require tons of memory? The program is very weak on handling the last few characters of the text file. Can anyone suggest some improvements? -Steve Wampler ----------