From dscargo@cim-vax.honeywell.com Thu Jul 6 12:12:48 1989 Message-Id: <8907061912.AA12575@megaron.arizona.edu> Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA12575; Thu, 6 Jul 89 12:12:48 MST Date: 6 Jul 89 13:57:00 CST From: "DAVE CARGO" Subject: text formatter To: "icon-group" Anybody tried to write a text formatter in Icon? It seems like such a natural application. o o \_____/ /-o-o-\ _______ DDDD SSSS CCCC / ^ \ /\\\\\\\\ D D S C \ \___/ / /\ ___ \ D D SSS C \_ _/ /\ /\\\\ \ D D S C \ \__/\ /\ @_/ / DDDDavid SSSS. CCCCargo \____\____\______/ DSCARGO@CIM-VAX.HONEYWELL.COM From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS Fri Jul 7 11:07:04 1989 Received: from mailgw.cc.umich.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA25361; Fri, 7 Jul 89 11:07:04 MST Received: from him1.cc.umich.edu by mailgw.cc.umich.edu (5.59/1.0) id AA06157; Fri, 7 Jul 89 14:03:02 EDT Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Fri, 7 Jul 89 14:05:48 EDT Date: Fri, 7 Jul 89 13:13:16 EDT From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu To: icon-group@arizona.edu Message-Id: <153527@Wayne-MTS> Subject: Text formatters In response to David Cargo: I wrote a rather large and elaborate formatter in Icon about 18 months ago. It was very ad-hoc: it simulated a subset of IBM Script/GML, with output to the Canon LBP-8 printer. Unfortunately it's not good for anything else. Paul Abrahams From goer@sophist.uchicago.edu Mon Jul 10 00:42:03 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA13457; Mon, 10 Jul 89 00:42:03 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Mon, 10 Jul 89 02:41:49 CDT Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA01903; Mon, 10 Jul 89 02:40:32 CDT Date: Mon, 10 Jul 89 02:40:32 CDT From: Richard Goerwitz Message-Id: <8907100740.AA01903@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: return expressions Why doesn't the following program output "go"? procedure main() write(writeit()) end procedure writeit() (return \stopit) return "go" end I figured that the variable stopit, being null, would cause the return expression in which it is mentioned to fail. This would result only in expression failure, however, and not in failure of the entire procedure. I expected that control would then pass to the next return expression, which would return the string "go" - the string that would ultimately be written to the stdout by the write function in the main procedure. It looks, however, as though the expression return \stopit is the same as fail at least in this instance, where \stopit fails. Why is this so? Why doesn't the program simply print "go"? -Richard L. Goerwitz goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From ralph Mon Jul 10 05:18:43 1989 Date: Mon, 10 Jul 89 05:18:43 MST From: "Ralph Griswold" Message-Id: <8907101218.AA21612@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA21612; Mon, 10 Jul 89 05:18:43 MST To: goer@sophist.uchicago.edu, icon-group@arizona.edu Subject: Re: return expressions In-Reply-To: <8907100740.AA01903@sophist.uchicago.edu> The return expression always returns. It returns the *outcome* of evaluating its argument. If its argument fails, the return causes failure of the procedure invocation in which it occurs. E.g., return &fail has the same effect as fail Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From naucse!sbw Mon Jul 10 16:31:28 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA01077; Mon, 10 Jul 89 16:31:28 MST Message-Id: <8907102139.AA04164@naucse> Date: Mon, 10 Jul 89 14:39:04 MST X-Mailer: Mail User's Shell (6.5 4/17/89) From: naucse!naucse!sbw (Steve Wampler) To: Richard Goerwitz , arizona!icon-group Subject: Re: return expressions On Jul 10 at 1:54, Richard Goerwitz writes: } } Why doesn't the following program output "go"? } } procedure main() } write(writeit()) } end } } procedure writeit() } (return \stopit) } return "go" } end } } It looks, however, as though the expression } } return \stopit } } is the same as } } fail } } at least in this instance, where \stopit fails. } Why is this so? Why doesn't the program simply } print "go"? } One thing to keep in mind is that 'return' is a control regime and not an operator. While I can see arguments for the behavior of 'return' going either way, I prefer it the way it is, as I more often write things like: return f(x) where I want the current function to fail if f(x) fails. You might see if the control regime suspend \stopit fits with what you're trying to do... -- Steve Wampler {....!arizona!naucse!sbw} From naucse!arizona!cheyenne Mon Jul 10 20:39:34 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA09846; Mon, 10 Jul 89 20:39:34 MST Date: Mon, 10 Jul 89 18:37:59 MST From: "Cheyenne Wills" Message-Id: <8907110137.AA05891@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA05891; Mon, 10 Jul 89 18:37:59 MST In-Reply-To: <8907102139.AA04164@naucse> To: arizona!icon-group, arizona!icon-group-sender, naucse!sbw Subject: Re: return expressions >You might see if the control regime > > suspend \stopit > >fits with what you're trying to do... Or you might want to try: procedure writeit() return \stopit | "go" end Cheyenne Wills From goer@sophist.uchicago.edu Wed Jul 12 14:57:01 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA18864; Wed, 12 Jul 89 14:57:01 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Wed, 12 Jul 89 16:56:58 CDT Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA06421; Wed, 12 Jul 89 16:55:35 CDT Date: Wed, 12 Jul 89 16:55:35 CDT From: Richard Goerwitz Message-Id: <8907122155.AA06421@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: xenix I wonder if XENIX users reading this group might take a moment to let a soon-to-be XENIX user know what hardware they are using, and any tips I might want to know about in using Icon in this environ- ment. I'm coming from the BSD 4.3 and MS-DOS worlds, and I'm dread- fully worried about incompatibilities and other assorted chinks in the armor of 32-bit extensions to AT busses and XENIX/386. -Richard L. Goerwitz goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From ralph Thu Jul 13 16:01:47 1989 Date: Thu, 13 Jul 89 16:01:47 MST From: "Ralph Griswold" Message-Id: <8907132301.AA05866@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA05866; Thu, 13 Jul 89 16:01:47 MST To: icon-group Subject: Version 7.5 of Icon for the IBM 370 Version 7.5 of Icon is now available for IBM 370 computers running VM/CMS. It should run on the IBM 30xx and 43xx families of processors and on other 370-type processors that use the VM/CMS operating system. This system is available from the Icon project on a 1600 bpi magnetic tape. The tape includes executables and source code (which compiles under Waterloo C 3.0 and should be easily adaptable to other production- quality C compilers). The tape is available from Icon Project Department of Computer Science Gould-Simpson Building The University of Arizona Tucson, AZ 85721 USA The cost is $30, payable by Visa, MasterCard, or check. Checks must be in US dollars, written on a bank with a branch in the United States, and made payable to The University of Arizona. See Icon Newsletter 30 for more information on ordering. There is no charge for shipping in the United States and Canada. There is a $10 charge for shipment overseas, which is by air. This version of Icon is not available via FTP or RBBS. Please address any questions to me, not to icon-project or icon-group. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From naucse!sbw Thu Jul 13 17:34:32 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA11041; Thu, 13 Jul 89 17:34:32 MST Message-Id: <8907132342.AA09033@naucse> Date: Thu, 13 Jul 89 16:42:54 MST X-Mailer: Mail User's Shell (6.5 4/17/89) From: naucse!naucse!sbw (Steve Wampler) To: arizona!icon-group Subject: Anyone have Icon 7.5 on a DECstation 3100? I guess that just about says it. I'd appreciated hearing from anyone who has brought up Icon on a DECstation. If no one has, I'll give it a go when I get some time, but that's going to be awhile. -- Steve Wampler {....!arizona!naucse!sbw} From naucse!arizona!ralph Thu Jul 13 19:42:41 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA22025; Thu, 13 Jul 89 19:42:41 MST Date: Thu, 13 Jul 89 17:54:21 MST From: "Ralph Griswold" Message-Id: <8907140054.AA11823@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA11823; Thu, 13 Jul 89 17:54:21 MST To: arizona!icon-group, naucse!sbw Subject: Re: Anyone have Icon 7.5 on a DECstation 3100? In-Reply-To: <8907132342.AA09033@naucse> We installed Icon on a DECstation 3100 while we had one on loan for evaluation. We had the same problem with Ultrix as on other DEC machines (documented in earlier mail to icon-group). Otherwise, the installation was trivial. Gregg Townsend implemented co-expressions also (which was not so trivial). Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From icon-group-request Fri Jul 14 23:05:40 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA28085; Fri, 14 Jul 89 23:05:40 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA25671; Fri, 14 Jul 89 22:47:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Jul 89 05:45:59 GMT From: iris!hildum@ucdavis.ucdavis.edu (Eric Hildum) Organization: U.C. Davis - Department of Electrical Engineering and Computer Science Subject: LEX and YACC in/for Icon Message-Id: <4892@ucdavis.ucdavis.edu> References: <8907132342.AA09033@naucse>, <8907140054.AA11823@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Hello there! I have been going through some of the back issues of the Icon digest, and ran across a reference to versions of lex and yacc that would generate Icon code. I have recently installed version 7.5 of Icon, but have not found these amoung the included contributed programs. Did these programs ever get included? If they did, where are they? If not, does anybody have copies that they would be willing to send to me? Eric Hildum hildum@iris.ucdavis.edu dehildum@ucdavis.ucdavis.edu (Internet) dehildum@ucdavis.bitnet (BITNET) ucbvax!ucdavis!dehildum (uucp) From icon-group-request Sat Jul 15 00:22:45 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA01062; Sat, 15 Jul 89 00:22:45 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA28423; Fri, 14 Jul 89 23:47:05 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Jul 89 05:52:17 GMT From: iris!hildum@ucdavis.ucdavis.edu (Eric Hildum) Organization: U.C. Davis - Department of Electrical Engineering and Computer Science Subject: Contributed programs and version 7.5 UNIX installation Message-Id: <4893@ucdavis.ucdavis.edu> References: <8907132342.AA09033@naucse>, <8907140054.AA11823@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Hello! I have just recently installed version 7.5 of Icon on a Sun 3/60 Sun OS 3.5 system. The UNIX tar file contained the ipl directory and associated programs; however, these appear to be out of date, and do not match the listings given the iplv7p1.doc file. The iplv7p1.tar file contains a set of procedures and programs that correspond to the document, but does not include any make files or scripts to install the library. Is the contributed library currently undergoing revision, and should we expect a new tar file soon? Eric Hildum hildum@iris.ucdavis.edu dehildum@ucdavis.ucdavis.edu (Internet) dehildum@ucdavis.bitnet (BITNET) ucbvax!ucdavis!dehildum (uucp) From ralph Sat Jul 15 06:36:51 1989 Date: Sat, 15 Jul 89 06:36:51 MST From: "Ralph Griswold" Message-Id: <8907151336.AA23947@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA23947; Sat, 15 Jul 89 06:36:51 MST To: icon-group@arizona.edu, iris!hildum@ucdavis.ucdavis.edu Subject: Re: Contributed programs and version 7.5 UNIX installation In-Reply-To: <4893@ucdavis.ucdavis.edu> The UNIX and VMS distributions of 7.5 of Icon were assembled before the current Version 7 of the Icon program library was complete. These distributions contail an older versi of the library, as you've noted. We do not plan to update the UNIX and VMS distributions of Icon in the near future. However, the documentation that accompanies Version 7 of the Icon program library contains the information necessary to install it. Granted, there is no "button to push", it's really quite easy. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From uunet!rayssd!mlfarm!ron Sat Jul 15 17:09:50 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA14835; Sat, 15 Jul 89 17:09:50 MST Received: from rayssd.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA06276; Sat, 15 Jul 89 12:01:34 -0400 Received: from mlfarm with UUCP by rayssd.RAY.COM ; Sat, 15 Jul 89 03:00:15 edt Received: by mlfarm.uucp (smail2.5) id AA11817; 14 Jul 89 07:38:13 EDT (Fri) To: goer@sophist.uchicago.edu Cc: arizona!icon-group In-Reply-To: Richard Goerwitz's message of Wed, 12 Jul 89 16:55:35 CDT <8907122155.AA06421@sophist.uchicago.edu> Subject: xenix Message-Id: <8907140738.AA11817@mlfarm.uucp> Date: 14 Jul 89 07:38:13 EDT (Fri) From: uunet!mlfarm!ron (Ronald Florence) Richard, I ported ICON to Xenix/386 with no difficulties. I believe the configuration files for Xenix/386 are now included with the ICON distibution. My own system is an IBM ps2/80, and the ICON benchmark suite produced very acceptable results, faster than a Sun 3/160 or any DOS or OS/2 version of ICON on the same machine, including the protected mode DOS version. The only ICON feature I did not implement is co-expressions. If you need the configuration files or other information, let me know. Ronald Florence ...{hsi!aati,rayssd}!mlfarm!ron From uunet!ladcgw!l66a.ladc.bull.com!ZENITH Mon Jul 17 13:14:22 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA06824; Mon, 17 Jul 89 13:14:22 MST Received: from ladcgw.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA22294; Mon, 17 Jul 89 15:55:23 -0400 Received: from l66a by ladc.bull.com (3.2/SMI-3.2) id AA14202; Mon, 17 Jul 89 11:38:38 PDT Date: Mon, 17 Jul 89 11:33 PDT From: ZENITH Reply-To: Zenith/A_Birner To: icon-group@arizona.edu Really-To: icon-group Subject: porting Icon to machines with strange word sizes Message-Id: <890717.11383092.013057@L66A.CP6> Has anyone worked at porting Icon to a machine with a word size that is _not_ a multiple of eight? I'm entertaining the notion of porting Icon to run on the Bull (nee Honeywell) DPS-8 architecture, under the CP-6 operating system; the salient feature of this hardware is its nine-bit bytes (36-bit words). Am I likely to run into any major headaches as a result of this? - Andy - From kwalker Tue Jul 18 17:01:28 1989 Date: Tue, 18 Jul 89 17:01:28 MST From: "Kenneth Walker" Message-Id: <8907190001.AA07073@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA07073; Tue, 18 Jul 89 17:01:28 MST In-Reply-To: <890717.11383092.013057@L66A.CP6> Has anyone worked at porting Icon to a machine with a word size that is To: icon-group Subject: Re: porting Icon to machines with strange word sizes Date: Mon, 17 Jul 89 11:33 PDT From: ZENITH Reply-To: Zenith/A_Birner Has anyone worked at porting Icon to a machine with a word size that is _not_ a multiple of eight? I'm entertaining the notion of porting Icon to run on the Bull (nee Honeywell) DPS-8 architecture, under the CP-6 operating system; the salient feature of this hardware is its nine-bit bytes (36-bit words). Am I likely to run into any major headaches as a result of this? You will probably run into headaches. The implementation of Icon has become a lot more portable in the last few releases so it is hard to judge just how difficult it will be (some of it depends on how robust your C compiler is, of course). There is actually a configuration parameter for specifying the number of bits/byte. It seems to only be used in the linker. I am not sure anyone has tried setting it to a number other than 8. At one time there were problems with the random number generator, but I think that has been fixed to work as long as you have at least 32 bit integers (someone can correct me if I am wrong.) Is the DPS-8 a byte addressable machine or do byte pointers have a special form like they do in the Cray (so far no one has managed a port of Icon to that machine)? Are pointers and ints (or longs) the same size? We can try to give you some advice if you decide to attempt the port. You can address questions to icon-project@arizona.edu or directly to me (though I may pass them on if I can't answer them). Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker From tenaglia%astroatc.UUCP@cs.wisc.edu Wed Jul 19 11:21:30 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA24574; Wed, 19 Jul 89 11:21:30 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Wed, 19 Jul 89 13:17:35 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA03022; Wed, 19 Jul 89 12:44:34 CDT Date: Wed, 19 Jul 89 12:44:34 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8907191744.AA03022@astroatc.UUCP> To: icon-group@arizona.edu Dear Icon-Group, I am a heavy Icon user. We have icon in DOS, UNIX, and VMS. Having benefitted so much from it, I feel glad to be able to contribute a little. Below is one of my favorite procedures. I realize it can be done in line with the string scanning features. But I discovered, I do the same string scanning over and over. So I composed this software chip that I include in many programs. It could be ucoded too. I leave that up to the programmer. This first one is more general. As a postscript I include a variation that is a little more specific, but still very useful. It can be used in an assignment -> words := parse(line) Or on the fly -> if parse(line,' :,')[3] == "X800" then... ################################################################## # # # THIS PROCEDURE PULLS ALL THE ELEMENTS (TOKENS) OUT OF A LINE # # BUFFER AND RETURNS THEM IN A LIST. A VARIABLE NAMED 'CHARS' # # CAN BE STATICALLY DEFINED HERE OR GLOBAL. IT IS A CSET THAT # # CONTAINS THE VALID CHARACTERS THAT CAN COMPOSE THE ELEMENTS # # ONE WISHES TO EXTRACT. # # # ################################################################## procedure parse(line,delims) if delims === &null then delims := ' \t' chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end #ps procedure parse(line) static chars initial chars := &cset -- ' \t' tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 From icon-group-request Thu Jul 20 08:54:15 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA12235; Thu, 20 Jul 89 08:54:15 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA13910; Thu, 20 Jul 89 08:42:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Jul 89 13:58:52 GMT From: astroatc!tenaglia@speedy.wisc.edu (Chris Tenaglia) Organization: Astronautics Technology Cntr, Madison, WI Subject: handy icon procedure Message-Id: <2378@astroatc.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I am a heavy Icon user. We have icon in DOS, UNIX, and VMS. Having benefitted so much from it, I feel glad to be able to contribute a little. Below is one of my favorite procedures. I realize it can be done in line with the string scanning features. But I discovered, I do the same string scanning over and over. So I composed this software chip that I include in many programs. It could be ucoded too. I leave that up to the programmer. This first one is more general. As a postscript I include a variation that is a little more specific, but still very useful. It can be used in an assignment -> words := parse(line) Or on the fly -> if parse(line,' :,')[3] == "X800" then... ################################################################## # # # THIS PROCEDURE PULLS ALL THE ELEMENTS (TOKENS) OUT OF A LINE # # BUFFER AND RETURNS THEM IN A LIST. A VARIABLE NAMED 'CHARS' # # CAN BE STATICALLY DEFINED HERE OR GLOBAL. IT IS A CSET THAT # # CONTAINS THE VALID CHARACTERS THAT CAN COMPOSE THE ELEMENTS # # ONE WISHES TO EXTRACT. # # # ################################################################## procedure parse(line,delims) if delims === &null then delims := ' \t' chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end #ps procedure parse(line) static chars initial chars := &cset -- ' \t' tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 From icon-group-request Fri Jul 21 11:22:38 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA27601; Fri, 21 Jul 89 11:22:38 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09225; Fri, 21 Jul 89 11:18:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Jul 89 18:06:17 GMT From: notecnirp!mk@princeton.edu (Makoto Kobayashi) Organization: Dept. of Computer Science, Princeton University Subject: MS-DOS version Message-Id: <18305@princeton.Princeton.EDU> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu What is the latest version of icon running on MS-DOS and how I can get the source? From goer@sophist.uchicago.edu Sat Jul 22 11:51:47 1989 Received: from [128.135.4.27] by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA07193; Sat, 22 Jul 89 11:51:47 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Sat, 22 Jul 89 13:47:28 CDT Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA27534; Sat, 22 Jul 89 12:16:29 CDT Date: Sat, 22 Jul 89 12:16:29 CDT From: Richard Goerwitz Message-Id: <8907221716.AA27534@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: sets Recently I ran a simple program like this: lineset := set() while line := !&input do { insert(lineset,line) } every write(!lineset) I used it to remove duplicate lines from a file looking like this: stuffofonesort data data data stuffofanothersort data data data stuffofanothersort data data data stuffofonesort data data data When I printed everything out, all the lines begin- ning with stuffofonesort were together; same with stuffofanothersort. However, sorting stopped there. No sorting was done on the data fields (separated by a space from the first field). They were listed in the order in which they were entered into the set. This is a neat feature. By some wild coincidence this sorting order turned out to be very, very useful to me. But why did it turn out that way? Could someone who understands the implementation better help? -Richard P.S. The Xenix 386 implementation of Icon is, by all report, very fast and nice. I am planning on snarfing a copy over soon (as soon as I get some hardware questions nailed down). Before I get all involved with it, I wonder: Has anyone implemented coexpressions and not told us about it? I wish I could say I was competent to write good 386 assem- bler code, but alas.... If someone else is either working on this, or else had done it, I'd really like to know about it. From wgg@june.cs.washington.edu Sat Jul 22 15:03:12 1989 Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA15732; Sat, 22 Jul 89 15:03:12 MST Received: by june.cs.washington.edu (5.59/6.13+) id AA10995; Sat, 22 Jul 89 14:59:29 PDT Date: Sat, 22 Jul 89 14:59:29 PDT From: wgg@june.cs.washington.edu (William Griswold) Return-Path: Message-Id: <8907222159.AA10995@june.cs.washington.edu> To: goer@sophist.uchicago.edu, icon-group@arizona.edu Subject: Re: sets >Date: Sat, 22 Jul 89 12:16:29 CDT >From: Richard Goerwitz >To: icon-group@arizona.edu >Subject: sets > >Recently I ran a simple program like this: > > lineset := set() > while line := !&input do { > insert(lineset,line) > } > every write(!lineset) > >I used it to remove duplicate lines from a file >looking like this: > >stuffofonesort data data data >stuffofanothersort data data data >stuffofanothersort data data data >stuffofonesort data data data > >When I printed everything out, all the lines begin- >ning with stuffofonesort were together; same with >stuffofanothersort. However, sorting stopped there. >No sorting was done on the data fields (separated >by a space from the first field). They were listed >in the order in which they were entered into the >set. > >This is a neat feature. By some wild coincidence >this sorting order turned out to be very, very >useful to me. But why did it turn out that way? >Could someone who understands the implementation >better help? > >-Richard > What is probably causing this is that the implementation of sets in Icon uses a hash table. Hash tables are used frequently as a way to store values that need to be looked-up quickly by some `key'. In sets, the key is the element itself. In order to make hash tables reasonably efficient, they are implemented as arrays indexed by pseudo-keys (that is, keys that are not unique). Anything that has the same pseudo-key gets put in the same array-slot. However, it the elements are not actually the same, they are all saved in the array-slot as a list. To perform a look-up then, the element is converted into a pseudo-key, the array is indexed by the key, and then the resulting list is searched for the element. For the Icon implementation of sets, the function that produces a pseudo-key for the input strings only looks at the first 10 or so characters of the string (to avoid long key-computation times for long strings). This means that strings that are identical for the first 10 characters will be put in the same array-slot. When the elements of the table are generated, they are generated one array-slot at a time. So all the elements with the same pseudo-key will be in the same array-slot, and will appear consecutively in the generation sequence. Needless to say you can't count on this working consistently, or in the next release of Icon. You probably want a table indexed by the first phrase in the line, and store a set of all lines with that phrase as the element. Then you can sort the table by the phrase, and generate the elements of each set in turn. I hope this wasn't too confusing! Bill Griswold From icon-group-request Sun Jul 23 00:53:10 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA05831; Sun, 23 Jul 89 00:53:10 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA23065; Sun, 23 Jul 89 00:41:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Jul 89 13:01:14 GMT From: ssbell!mcmi!amperif!unocss!payne@uunet.uu.net (Matt Payne) Organization: U. of Nebraska at Omaha Subject: ICON 7.5 for the AMIGA Message-Id: <1106@unocss.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I don't see the amiga executables for Icon 7.5 at the Arizona ftp cite. Would someone please tell me how I may get this executable? I would prefer not to pay any copying charges since I don't have much money. :-( Thanks in advance for the help! -- Matt Payne Internet:conslt10@zeus.unl.edu UUCP:uunet!btni!unocss!payne Bitnet:CONSLT10@UNOMA1 From ralph Sun Jul 23 05:51:54 1989 Date: Sun, 23 Jul 89 05:51:54 MST From: "Ralph Griswold" Message-Id: <8907231251.AA19602@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA19602; Sun, 23 Jul 89 05:51:54 MST To: icon-group@arizona.edu, ssbell!mcmi!amperif!unocss!payne@uunet.uu.net Subject: Re: ICON 7.5 for the AMIGA In-Reply-To: <1106@unocss.UUCP> Icon for the Amiga is not yet available via FTP. We're working on it' perhaps a week or two. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From tenaglia%astroatc.UUCP@cs.wisc.edu Sun Jul 23 06:34:35 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA21363; Sun, 23 Jul 89 06:34:35 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Sun, 23 Jul 89 08:30:57 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA07154; Sun, 23 Jul 89 08:27:43 CDT Date: Sun, 23 Jul 89 08:27:43 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8907231327.AA07154@astroatc.UUCP> To: icon-group@arizona.edu Dear Icon-Group, Here is another goodie. It's targetted to unix machines and the unix plot utility. I use it with a TEK4014 emulation. One can do graphics using icon. This collection of procedures should be made into a ucode type library. Your graphics application would have a link statement to pull them together. Later I may include a sample program using this. Have fun ! Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 ########################################################################## # # # draw.icn 5/23/89 by tenaglia # # # # this is a plotting library routine for icon in unix. # # use these procedures to generate plotting commands # # that can be piped into the unix plot command. # # # # usage: icont draw -c # generate the ucode library # # link draw # include routines when linking # # icont prog -x | plot # compile, run, & pipe into plot # # # ########################################################################## # # move to a given x,y screen location # procedure moveto(x,y) write("m",hex(x),hex(y)) return end # # draw to a given x,y screen location # procedure drawto(x,y) write("n",hex(x),hex(y)) return end # # dot at an x,y screen location # procedure dot(x,y) write("p",hex(x),hex(y)) return end # # plot from x1,y1 to x2,y2 # procedure plot(x1,y1,x2,y2) write("l",hex(x1),hex(y1),hex(x2),hex(y2)) return end # # label text to the screen at current location # procedure label(data) write("t",data,"\n") return end # # arc with x,y center sx,sy beginning point and # fx,fy finishing point. draws counterclockwise. # procedure arc(x1,y1,sx,sy,fx,fy) write("a",hex(x1),hex(y1),hex(sx),hex(sy),hex(fx),hex(fy)) return end # # circle with center at x,y and radius r # procedure circle(x,y,r) write("c",hex(x),hex(y),hex(r)) return end # # clear screen # procedure clear() write("e") return end # # this polyline routine takes a list as its parameter. # the list must have an even number of elements. # procedure polyline(pairs) if *pairs%2 = 1 then fail case *pairs of { 0 : return 2 : write("p",hex(pairs[1]),hex(pairs[2])) default : { write("m",hex(pairs[1]),hex(pairs[2])) every i := 3 to *pairs by 2 do write("n",hex(pairs[i]),hex(pairs[i+1])) } } return end # # style of line. parameter is a string that is either 'dotted', # 'solid', 'longdashed', 'shortdashed', or 'dotdashed' # procedure style(method) case method of { "dotted" : &null "solid" : &null "longdashed" : &null "shortdashed" : &null "dotdashed" : &null default : fail } write("f",method) return end # # window to set up coordinate space with x1,y1 as ll corner # and x2,y2 as ur corner. tek 4014 is (0,0,3120,3120) # procedure window(x1,y1,x2,y2) write("s",hex(x1),hex(y1),hex(x2),hex(y2)) return end # # hex converts a number to a 32 bit binary value # procedure hex(n) n := integer(n) n %:= 65536 if n < 0 then n+:=65536 return (char(integer(n%256)) || char(integer(n/256))) end # end of the graphics program From tenaglia%astroatc.UUCP@cs.wisc.edu Mon Jul 24 08:03:05 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA26146; Mon, 24 Jul 89 08:03:05 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Mon, 24 Jul 89 09:59:14 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA22804; Mon, 24 Jul 89 09:53:52 CDT Date: Mon, 24 Jul 89 09:53:52 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8907241453.AA22804@astroatc.UUCP> To: icon-group@arizona.edu Dear Icon-Group, Here's a sample icon program that takes advantage of the drawing procedures I recently posted. It will generate the recursive Sierpinski triangle. You need a unix system, a tektronix 4014 compatible terminal or emulator, icon, and the drawing procedures compiled to ucode. Step 1. Cut the rest of this file from the # banner on down. Step 2. Compile it (icont triang). draw.u1 & draw.u2 should also be in the same directory. Step 3. Run it. (iconx triang | plot). Step 4. Answer the question and enjoy the picture. Yours truly, Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 ######################################################### # # # TRIANG.ICN 7/19/89 BY TENAGLIA # # # # SIERPINSKI TRIANGLE GENERATOR USING RANDOM FRACTALS # # # ######################################################### link draw global kbd,crt procedure main(p) # # INITIALIZATION # crt := open("/dev/tty","w") ; kbd := open("/dev/cons") &random := map(&clock,":","0") (points := numeric(p[1])) | (points:=numeric(input("_Points>"))) | stop("Points must be integer > 1") px := [] ; py := [] w := 4000 ; h := 3200 window(0,0,w,h) clear() every 1 to 3 do { put(px,?w) put(py,?h) } px |||:= px ; py |||:= py # # ILLUSTRATE # plot(px[1],py[1],px[2],py[2]) drawto(px[3],py[3]) ; drawto(px[1],py[1]) x := ?w ; y := ?h every 1 to points do { p := ?6 x1 := px[p] ; y1 := py[p] x2 := integer((x1 - x) / 2.0 + x) y2 := integer((y1 - y) / 2.0 + y) dot(x2,y2) ; x := x2 ; y := y2 } label("\007Done.") ; read() end # # GET INPUT FROM CONSOLE # procedure input(prompt) writes(crt,prompt) ; value := read(kbd) return value end # END OF PROGRAM From icon-group-request Mon Jul 24 13:56:16 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA19593; Mon, 24 Jul 89 13:56:16 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA02724; Mon, 24 Jul 89 13:47:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Jul 89 16:23:52 GMT From: mcvax!hp4nl!mhres!jv@uunet.uu.net (Johan Vromans) Organization: Multihouse NV, the Netherlands Subject: Icon 7.5 for Ultrix 3.0 Message-Id: <3407@mhres.mh.nl> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu This has probably be answered before, but ... I'm porting Icon 7.5 to a VAX running Ultrix 3.0. I choose the "vax_ultrix" configuration file. First, Ultrix doesn't like fopen(...,"rb") and fopen(...,"wb"), so I changed them. Now I'm running into memory allocation problems. When I run a program, iconx opens the icon-executable with fopen(...), which apparetly calls malloc. However, initalloc is not yet called, so iconx aborts with a stratup error "malloc: static region not initialized". Has anyone solved this problem, and how? Are other problems to be expected? Thanks in advance. Johan -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{mcvax,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500 ------------------------ "Arms are made for hugging" ------------------------- From ralph Mon Jul 24 16:39:08 1989 Date: Mon, 24 Jul 89 16:39:08 MST From: "Ralph Griswold" Message-Id: <8907242339.AA01427@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA01427; Mon, 24 Jul 89 16:39:08 MST To: icon-group@arizona.edu, mcvax!hp4nl!mhres!jv@uunet.uu.net Subject: Re: Icon 7.5 for Ultrix 3.0 In-Reply-To: <3407@mhres.mh.nl> These are known problems with Version 7.5 under Ultrix. They are fixed in our development version, but it will be a while until it's available for distribution. To work around the memory allocation problem, add #define FixedRegions to define.h. Icon's memory regions won't expand automatically, but you can set them to large values with environment variables. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From icon-group-request Tue Jul 25 18:37:54 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA28465; Tue, 25 Jul 89 18:37:54 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA03680; Tue, 25 Jul 89 18:30:11 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Jul 89 22:06:05 GMT From: srcsip!nic.MR.NET!ns!dean@csd4.milw.wisc.edu (Dean Gahlon x2434) Organization: Network Systems Corporation Subject: Re: ICON 7.5 for the AMIGA Message-Id: <1508@ns.network.com> References: <1106@unocss.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Just having gone through this, I have the information you seek. Unfortunately, the Icon Project currently doesn't have an Amiga, so getting the files onto their ftp machine is rather difficult at present. The only way to get it currently is to spend the $15 and order it. (I got a response last week from Dr. Griswold to this effect, whereupon I immediately called the phone number listed and ordered the disk. It hasn't arrived yet, but this doesn't surprise me, since it's been less than a week) Sorry to be the bearer of bad news, Dean C. Gahlon. From icon-group-request Fri Jul 28 11:10:21 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA25138; Fri, 28 Jul 89 11:10:21 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22426; Fri, 28 Jul 89 11:02:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jul 89 19:49:45 GMT From: srcsip!nic.MR.NET!hal!ncoast!davewt@csd4.milw.wisc.edu (David Wright) Organization: Cleveland Public Access UN*X, Cleveland, OH Subject: Re: ICON 7.5 for the AMIGA Message-Id: <14298@ncoast.ORG> References: <1106@unocss.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Please post a reply to this newsgroup, as I am also interested in getting a copy... Dave From ralph Sun Jul 30 06:05:25 1989 Date: Sun, 30 Jul 89 06:05:25 MST From: "Ralph Griswold" Message-Id: <8907301305.AA22938@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA22938; Sun, 30 Jul 89 06:05:25 MST To: icon-group Subject: Icon Version 7.5 for the Amiga Version 7.5 Icon executables and the Icon program library for the Amiga are now available from us via FTP and RBBS. Please let me know of any problems (mail to me, not icon-group, please). Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From tenaglia%astroatc.UUCP@cs.wisc.edu Tue Aug 1 06:57:03 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA11485; Tue, 1 Aug 89 06:57:03 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Tue, 1 Aug 89 08:53:36 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA05853; Tue, 1 Aug 89 07:55:25 CDT Date: Tue, 1 Aug 89 07:55:25 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8908011255.AA05853@astroatc.UUCP> To: icon-group@arizona.edu Dear Icon-Group, ( I recently mailed this to icon-group but had it bounce back as undeliverable. I don't know if it made it or not, so I'm resending it. If it already has been posted, just ignore it. ) Here's a sample icon program that takes advantage of the drawing procedures I recently posted. It will generate the recursive Sierpinski triangle. You need a unix system, a tektronix 4014 compatible terminal or emulator, icon, and the drawing procedures compiled to ucode. Step 1. Cut the rest of this file from the # banner on down. Step 2. Compile it (icont triang). draw.u1 & draw.u2 should also be in the same directory. Step 3. Run it. (iconx triang | plot). Step 4. Answer the question and enjoy the picture. Yours truly, Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 ######################################################### # # # TRIANG.ICN 7/19/89 BY TENAGLIA # # # # SIERPINSKI TRIANGLE GENERATOR USING RANDOM FRACTALS # # # ######################################################### link draw global kbd,crt procedure main(p) # # INITIALIZATION # crt := open("/dev/tty","w") ; kbd := open("/dev/cons") &random := map(&clock,":","0") (points := numeric(p[1])) | (points:=numeric(input("_Points>"))) | stop("Points must be integer > 1") px := [] ; py := [] w := 4000 ; h := 3200 window(0,0,w,h) clear() every 1 to 3 do { put(px,?w) put(py,?h) } px |||:= px ; py |||:= py # # ILLUSTRATE # plot(px[1],py[1],px[2],py[2]) drawto(px[3],py[3]) ; drawto(px[1],py[1]) x := ?w ; y := ?h every 1 to points do { p := ?6 x1 := px[p] ; y1 := py[p] x2 := integer((x1 - x) / 2.0 + x) y2 := integer((y1 - y) / 2.0 + y) dot(x2,y2) ; x := x2 ; y := y2 } label("\007Done.") ; read() end # # GET INPUT FROM CONSOLE # procedure input(prompt) writes(crt,prompt) ; value := read(kbd) return value end # END OF PROGRAM From KARNA@wharton.upenn.edu Tue Aug 1 08:42:14 1989 Received: from REMOTE.DCCS.UPENN.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA15053; Tue, 1 Aug 89 08:42:14 MST Return-Path: Received: from WHARTON.UPENN.EDU by remote.dccs.upenn.edu id AA12843; Tue, 1 Aug 89 11:39:11 -0400 Message-Id: <8908011539.AA12843@remote.dccs.upenn.edu> Date: Tue, 1 Aug 89 11:40 EDT From: KARNA@wharton.upenn.edu To: icon-group@arizona.edu X-Vms-To: IN%"icon-group@arizona.edu" I was wondering if anyone out there that has been using the PC version of Icon has tryed recompiling it using something like 'Heap Expander', or any other virtual memory package. I'm curious as to what troubles you en encountered, what changes were needed, etc. ion I am also curious as to whether anyone has implemented a dBase interface to Icon. --karna@wharton.upenn.edu From ralph Tue Aug 1 10:19:39 1989 Date: Tue, 1 Aug 89 10:19:39 MST From: "Ralph Griswold" Message-Id: <8908011719.AA20235@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA20235; Tue, 1 Aug 89 10:19:39 MST To: KARNA@wharton.upenn.edu Subject: MS-DOS Icon Cc: icon-group In-Reply-To: <8908011539.AA12843@remote.dccs.upenn.edu> Virtual memory for Icon won't help a lot, since it's a large-memory model program, which limits its region sizes to 64K. We've been trying to get it to compile with the huge-memory model, but there are all kinds of problems that we've not been able to fix. There is a 386 32-bit protected-mode version of Icon that runs under MS-DOS and requires extended memory. It will use all the memory you have, and then some. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From tenaglia%astroatc.UUCP@cs.wisc.edu Thu Aug 3 13:20:08 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA15748; Thu, 3 Aug 89 13:20:08 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Thu, 3 Aug 89 15:15:59 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA11677; Thu, 3 Aug 89 14:58:15 CDT Date: Thu, 3 Aug 89 14:58:15 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8908031958.AA11677@astroatc.UUCP> To: icon-group@arizona.edu Dear Icon-Group, Here's a rather curious utility. It's an ASCII/EBCDIC translator. Some of us occasionally get data tapes from IBM mainframes. Unix does supply a dd utility as a translator, but not MS-DOS or VMS. So I constructed this one. You may just find the translate tables useful of themselves. The program is run as a filter. ebasc -a file2 is ebcdic to ascii. ebasc -e file2 is ascii to ebcdic. You may have noticed some special 'metacomments'. In a future submission I will submit an Icon program pretty printer that makes use of them. Yours truly, Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 Our motto : Icon do it! #TITLE EBASC : ASCII/EBCDIC TRANSLATOR #SUB USAGE : ICONX EBASC -OPTION STDOUT #EJECT ############################################################################# # # # EBASC.ICN 3/24/88 BY TENAGLIA # # # ############################################################################# procedure main(option) asc := string(&cset) ebc := "\000\001\002\003\234\011\206\177\227\215\216\013\014\015\016\017"|| "\020\021\022\023\235\205\010\207\030\031\222\217\034\035\036\037"|| "\200\201\202\203\204\012\027\033\210\211\212\213\214\005\006\007"|| "\220\221\026\223\224\225\226\004\230\231\232\233\024\025\236\032"|| "\040\240\241\242\243\244\245\246\247\250\133\056\074\050\053\041"|| "\046\251\252\253\254\255\256\257\260\261\135\044\052\051\073\136"|| "\055\057\262\263\264\265\266\267\270\271\174\054\045\137\076\077"|| "\272\273\274\275\276\277\300\301\302\140\072\043\100\047\075\042"|| "\303\141\142\143\144\145\146\147\150\151\304\305\306\307\310\311"|| "\312\152\153\154\155\156\157\160\161\162\313\314\315\316\317\320"|| "\321\176\163\164\165\166\167\170\171\172\322\323\324\325\326\327"|| "\330\331\332\333\334\335\336\337\340\341\342\343\344\345\346\347"|| "\173\101\102\103\104\105\106\107\110\111\350\351\352\353\354\355"|| "\175\112\113\114\115\116\117\120\121\122\356\357\360\361\362\363"|| "\134\237\123\124\125\126\127\130\131\132\364\365\366\367\370\371"|| "\060\061\062\063\064\065\066\067\070\071\372\373\374\375\376\377" (method := option[1]) | help() case method of { "-a" : while write(map(read(),asc,ebc)) #ebcdic to ascii "-e" : while write(map(read(),ebc,asc)) #ascii to ebcdic default : help() #on line help (default) } end procedure help() if find("nix",map(&host)) then # open screen for vdu := open("/dev/tty","w") # online help. It if find("dos",map(&host)) then # recognizes Unix vdu := open("cons","w") else vdu := open("tt:","b") # DOS & VMS. write(vdu,"USAGE : iconx ebasc -option stdout") write(vdu,"\e[1;7m*** Translate between ascii and ebcdic coded data ***\e[m") write(vdu,"\e[1;7m-a Option translates ebcdic to ascii. \e[m") write(vdu,"\e[1;7m-e Option translates ascii to ebcdic. \e[m") write(vdu,"\e[1;7m-h Option outputs this help paragraph. \e[m") write(vdu,"\e[1;7mstdout Specify output file using redirector symbol. \e[m") stop() end From icon-group-request Thu Aug 3 20:05:07 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA05798; Thu, 3 Aug 89 20:05:07 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA14050; Thu, 3 Aug 89 19:56:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Aug 89 22:42:08 GMT From: oliveb!mipos3!omepd!mipon2!dan@apple.com (Dan Casali) Organization: Oregon Microcomputer Engineering, Intel Corp., Hillsboro, OR Subject: Icon and SNOBOL now available (supported!) on Mac Message-Id: <4755@omepd.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I recently received by direct mailing an annoucement of a supported ICON for the Mac. I purchased it, and with the package came an announcement of a SNOBOL4 for the Mac as well. Both the ICON (called ProIcon) and the SNOBOL4 (called MaxSPITBOL) come with a development environment (editor and windows), and an exportable runtime system. The entire Icon package fits on a single 800Kb diskette. Both have support for file and text dialogs and window manipulation (but no direct access to the Mac toolbox). I have been quite pleased with ProIcon, and have ordered MaxSPITBOL as well. I previously had been running the Arizona Mac Icon, which must be run under MPW and doesn't handle files very nicely. Both ProIcon and MaxSPITBOL can be ordered from Catspaw, Inc. PO Box 1123 Salida, Colorado 81201 (719) 539-3884 ProIcon costs $175.00 plus shipping w/o the Griswold book; implementation documentation is quite comprehensive. MaxSPITBOL costs $195.00. plus shipping. Its great to see my favorite languages supported on the Mac! From R.J.Hare@EDINBURGH.AC.UK Fri Aug 4 03:39:18 1989 Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA19040; Fri, 4 Aug 89 03:39:18 MST Received: from UKACRL.BITNET by rvax.ccit.arizona.edu; Fri, 4 Aug 89 03:07 MST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 3582; Fri, 04 Aug 89 10:58:51 BST Date: 04 Aug 89 11:01:14 bst From: R.J.Hare@EDINBURGH.AC.UK Subject: Speed of Icon To: icon-group@arizona.edu Via: 000015001006.FTP.MAIL; 4 AUG 89 10:58:48 BST Message-Id: <04 Aug 89 11:01:14 bst 340765@EMAS-A> I have written a context editor in Icon which is compatible with our local mainframe editor. The editor is fine but very slow in reading in the text of the file prior to editing, and slow to write out at the end of an editing session. The file to be edited is read in as a list of strings, each line being one item in the list. Does anyone out there have any idea how to speed up the reading/writing process? Thanks. Roger Hare. From tenaglia%astroatc.UUCP@cs.wisc.edu Sat Aug 5 07:09:24 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA15123; Sat, 5 Aug 89 07:09:24 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Sat, 5 Aug 89 09:05:59 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA04910; Sat, 5 Aug 89 08:46:58 CDT Date: Sat, 5 Aug 89 08:46:58 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8908051346.AA04910@astroatc.UUCP> To: icon-group@arizona.edu Dear Icon-Group, This is a rather long goody. Its an icon program pretty printer. I integrated it with the ipxref crossreference program as well. The program itself is written to be printed by itself. It you'd like to keep neat listings of iconware, you'll like this one. You may even customize it to have your company/school header or whatever. It's over 350 lines long, I hope your mail utility has a more filter. Good Luck! Yours truly, Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 #TITLE FANCY LISTER OF ICONWARE #SUB MAIN LINE #EJECT ################################################################# # # # ILIST.ICN 11/26/88 BY CHRIS TENAGLIA # # # # THIS PROGRAM MAKES NICE LIST FILES OF ICONWARE # # # # LISTER DIRECTIVES DESCRIPTION # # #TITLE text..... SET MAIN TITLE INFORMATION # # #SUB text....... SET SUBTITLE INFORMATION # # #EJECT EJECT PAGE # # # # CROSSREFERENCE OF PROCEDURES REQUIRES THAT ALL PROCEDURES BE # # DECLARED STARTING IN COLUMN 1. THIS PROGRAM WAS WRITTEN TO # # DEMONSTRATE ITS USE. IPXREF FROM THE IPL WAS ADDED AS AN OP- # # OPTION TO PROVIDE A DETAILED CROSSREFERENCE AT THE END. # # USAGE : ICONX ILIST [-V] FILE[.ICN] [OUTPUT] # # # ################################################################# global in,out,pgnum,lnum,lcnt,tline,subline,option,source global resword, linenum, letters, digits, var, buffer, qflag, f, fflag, xflag global inmaxcol, inlmarg, inchunk, localvar, lin record procrec(pname,begline,lastline) procedure main(param) init(param) pgnum := 0 lnum := 0 lcnt := 0 tline := "" subline := "" xpage := table() xline := table() every line := !in do { lnum +:= 1 if (i := match("procedure ",line)) then { name := line[i:upto('(',line,i)] xpage[name] := pgnum xline[name] := lnum } if (temp := title(line)) then { tline := temp next } if (temp := subtitle(line)) then { subline := temp next } if match("#eject",map(line)) then { header() next } if lcnt > 55 then header() write(out,ing(line)) lcnt +:= 1 } close(in) subline := "***** CROSSREFERENCE ***** " header() write(out,left("\nPROCEDURE NAME",32),right("PAGE",8),right("LINE",8)) xref1 := sort(xpage,2) xref2 := sort(xline,2) every i := 1 to *xref1 do { proc := xref1[i] page := xref2[i] text := left(page[1],32) || right(proc[2],8) || right(page[2],8) write(out,text) } write(out,left("\nPROCEDURE NAME",32),right("PAGE",8),right("LINE",8)) xref1 := sort(xpage,1) xref2 := sort(xline,1) every i := 1 to *xref1 do { proc := xref1[i] page := xref2[i] text := left(proc[1],32) || right(proc[2],8) || right(page[2],8) write(out,text) } if option == "-v" then ipxref([source]) close(out) write("\nProcess Completed !") end #SUB HANDY SUBROUTINES SECTION #EJECT ################################################################# # # # THIS ROUTINE RECOGNIZES AND RETURNS A TITLE IF ANY # # # ################################################################# procedure title(line) if (i := match("#title ",map(line))) then return line[i:0] end ################################################################# # # # THIS ROUTINE RECOGNIZES AND RETURNS A SUBTITLE IF ANY # # # ################################################################# procedure subtitle(line) if (i := match("#sub ",map(line))) then return line[i:0] end ################################################################# # # # THIS ROUTINE SPECIALLY FORMATS THE LINE # # # ################################################################# procedure ing(line) return (right(lnum,6) || " : " || line) end ################################################################# # # # THIS ROUTINE OUTPUTS THE HEADER # # # ################################################################# procedure header() pgnum +:= 1 write(out,"\f") id := "<> ICON LISTER " || &host || " " || &dateline id ||:= " Page " || pgnum || " <>\n" write(out,center(id,79)) write(out,center("<< "||tline||" >>",79)) write(out,center("< "||subline||" >",79),"\n") lcnt := 1 end #EJECT ################################################################# # # # THIS ROUTINE PERFORMS THE INITIAL SET UP AND OPENS FILES # # # ################################################################# procedure init(param) option := "" parx := 0 if param[1] == "-v" then {option := param[1];parx+:=1} if not(source := param[(parx+:=1)]) then { writes("Source >") source := read() } if not(find(".icn",map(source))) then source ||:= ".icn" (in := open(source)) | stop("Can't open ",source) if not(target := param[(parx+:=1)]) then target := source[1:find(".",source)] || ".lis" (out := open(target,"w")) | stop("Can't open ",target) a := "\e[1m" c := "\e[2J\e[H" z := "\e[0m\n" top := list() put(top, (c || a || center("< Nice ICON Lister >",79) || z)) put(top, (a || center( (&host || " " || &dateline) ,79) || z)) q := center(("Reading " || source || " | Writing " || target),79) b := (a || q || z) put(top, b) put(top, (repl("-",80) || z)) every write(!top) end # IPXREF # # Create Icon program cross-reference # # Allan J. Anderson # # Last modified 4/29/86 by Ralph E. Griswold # procedure ipxref(a) local word, w2, p, prec, i, L, ln initial { resword := ["break","by","case","default","do","dynamic","else", "end","every","fail","global","if","initial","link", "local","next","not","of","procedure", "record","repeat","return","static","suspend","then", "to","until","while"] linenum := 0 var := table() # var[variable[proc]] is list of line numbers prec := [] # list of procedure records localvar := [] # list of local variables of current routine buffer := [] # a put-back buffer for getword proc := "global" letters := &lcase ++ &ucase ++ '_' digits := '1234567890' } i := 0 header() while p := a[i +:= 1] do case p of { "-q": qflag := 1 "-x": xflag := 1 "-w": inmaxcol := integer(a[i +:= 1]) "-l": inlmarg := integer(a[i +:= 1]) "-c": inchunk := integer(a[i +:= 1]) default: if f := open(p,"r") then fflag := 1 else stop("usage: [-q -x -w -l -c] file") } while word := getword() do if word == "link" then { buffer := [] lin := "" next } else if word == "procedure" then { put(prec,procrec("",linenum,0)) proc := getword() | break p := pull(prec) p.pname := proc put(prec,p) } else if word == ("global" | "link" | "record") then { word := getword() | break addword(word,"global",linenum) while (w2 := getword()) == "," do { if Find(word,resword) then break word := getword() | break addword(word,"global",linenum) } put(buffer,w2) } else if word == ("local" | "dynamic" | "static") then { word := getword() | break put(localvar,word) addword(word,proc,linenum) while (w2 := getword()) == "," do { if Find(word,resword) then break word := getword() | break put(localvar,word) addword(word,proc,linenum) } put(buffer,w2) } else if word == "end" then { proc := "global" localvar := [] p := pull(prec) p.lastline := linenum put(prec,p) } else if Find(word,resword) then next else { ln := linenum if (w2 := getword()) == "(" then word ||:= " *" # special mark for procedures else put(buffer,w2) # put back w2 addword(word,proc,ln) } every write(out,!format(var)) write(out,"\n\nprocedures:\tlines:\n") L := [] every p := !prec do put(L,left(p.pname,16," ") || p.begline || "-" || p.lastline) every write(out,!(sort(L))) end procedure addword(word,proc,lineno) if any(letters,word) | \xflag then { /var[word] := table() if /var[word]["global"] | Find(word,\localvar) then { /(var[word])[proc] := [word,proc] put((var[word])[proc],lineno) } else { /var[word]["global"] := [word,"global"] put((var[word])["global"],lineno) } } end procedure getword() local j, c static i, nonwhite nonwhite := ~' \t\n' repeat { if *buffer > 0 then return get(buffer) if /lin | i = *lin + 1 then if lin := myread() then { i := 1 linenum +:= 1 } else fail if i := upto(nonwhite,lin,i) then { # skip white space j := i if lin[i] == ("'" | '"') then { # don't xref quoted words if /qflag then { c := lin[i] i +:= 1 repeat if i := upto(c ++ '\\',lin,i) + 1 then if lin[i - 1] == c then break else i +:= 1 else { i := 1 linenum +:= 1 lin := myread() | fail } } else i +:= 1 } else if lin[i] == "#" then { # don't xref comments; get next line i := *lin + 1 } else if i := many(letters ++ digits,lin,i) then return lin[j:i] else { i +:= 1 return lin[i - 1] } } else i := *lin + 1 } # repeat end procedure format(T) local V, block, n, L, lin, maxcol, lmargin, chunk, col initial { maxcol := \inmaxcol | 80 lmargin := \inlmarg | 40 chunk := \inchunk | 4 } L := [] col := lmargin every V := !T do every block := !V do { lin := left(block[1],16," ") || left(block[2],lmargin - 16," ") every lin ||:= center(block[3 to *block],chunk," ") do { col +:= chunk if col >= maxcol - chunk then { lin ||:= "\n\t\t\t\t\t" col := lmargin } } if col = lmargin then lin := lin[1:-6] # came out exactly even put(L,lin) col := lmargin } L := sort(L) push(L,"variable\tprocedure\t\tline numbers\n") return L end procedure Find(w,L) every if w == !L then return end procedure myread() if \fflag then return read(f) else return read() end From uunet!ukc!arc1 Mon Aug 7 12:50:02 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA06475; Mon, 7 Aug 89 12:50:02 MST Received: from ukc.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA13842; Mon, 7 Aug 89 14:28:25 -0400 Message-Id: <8908071828.AA13842@uunet.uu.net> Received: from harrier by kestrel.Ukc.AC.UK Over Ring with SMTP id ab15752; 7 Aug 89 17:24 BST Date: Mon, 07 Aug 89 17:18:42 +0100 From: uunet!ukc.ac.uk!arc1 To: arizona!icon-group Subject: Icon Sources Hi, sorry if this is the wrong mailing list to send to but I was looking for the latest versions of the sources for Icon. I've checked the UK archive sites but have had no joy, so I looked in comp.lang.icon and found this address. I'm interested in porting it to a parallel system here at UKC (A MEiKO transputer system) and distributing it over a network of processors. Thanks in advance Tony Curtis (...uunet!mcvax!ukc!arc1), Parallel Systems Group Computing Laboratory University of Kent Canterbury England. From icon-group-request Tue Aug 8 09:57:59 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA25571; Tue, 8 Aug 89 09:57:59 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA01286; Tue, 8 Aug 89 09:38:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Aug 89 16:35:32 GMT From: corre@csd4.milw.wisc.edu (Alan D Corre) Organization: University of Wisconsin-Milwaukee Subject: Icon procedure Message-Id: <3722@csd4.milw.wisc.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I wanted to write an Icon procedure to check if a string has precisely 22 characters (the size of the Hebrew alphabet) and no duplicate characters, so I wrote the following: procedure checkstring(abc) local cs, current if *abc ~= 22 then fail #check length cs := '' #initialize cset abc ? every 1 to 22 do { current := move(1) #select a char if cs ** current ~=== '' then fail #char is already a member cs ++:= current } #char is ok return end The procedure worked fine, but I said: "That isn't an Icon procedure. It's a thinly disguised Pascal function. Now write an Icon procedure." So I forsook "IF mouse IN hole" and wrote: procedure checkstring2(abc) local t, current if *abc ~= 22 then fail t := table(22) abc ? every 1 to 22 do { current := move(1) \t[current] | fail t[current] := 1 } return end More Icon constructs, but no better really. Then I wrote: procedure checkstring3(abc) return *abc = *cset(abc) = 22 end Now that's an Icon procedure. -- Alan D. Corre Department of Hebrew Studies University of Wisconsin-Milwaukee (414) 229-4245 PO Box 413, Milwaukee, WI 53201 corre@csd4.milw.wisc.edu From icon-group-request Tue Aug 8 17:39:03 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA23133; Tue, 8 Aug 89 17:39:03 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA27927; Tue, 8 Aug 89 17:23:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Aug 89 23:37:00 GMT From: cjp@apple.com (Chris Plummer) Organization: Apple Computer Inc, Cupertino, CA Subject: Icon ucode Message-Id: <33844@apple.Apple.COM> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I've just started using Icon on the mac under MPW 3.0 and I have a few questions. First of all, the mem01 test goes off the deep end after running for a few minutes. The output file in the "stand" folder shows that it should print out the numbers 1 to 100 and then quit with a runtime error and it seems to do this with the version of Icon I have running under unix, but on the Mac it runs for a few minutes and then crashes with not output. There are also a couple of other things that don't seem to work such as (\system). Has anyone else had these problems? I noticed that the syntax of ucode has changed since the publication of "The Implementation of the Icon Language". Have the changes been documented anywhere? Also, is the format of the binary (linked) version of Icon programs documented anywhere. Thanks in advance for any help. Chris Plummer Apple Computer Inc. cjp@apple.com From dscargo@cim-vax.honeywell.com Thu Aug 10 06:54:37 1989 Message-Id: <8908101354.AA28972@megaron.arizona.edu> Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA28972; Thu, 10 Aug 89 06:54:37 MST Date: 10 Aug 89 08:35:00 CST From: "DAVE CARGO" Subject: Real World Icon Application To: "icon-group" I came across mention of an Icon application that I thought might be worth mentioning. In the ACM SIGPLAN Notices Volume 24, Number 7 (July 1989), Proceedings of the SIGPLAN '89 Conference on Programming Language Design and Implementation there is one paper by Christopher W. Fraser (now of AT&T Bell Laboratories), A Language for Writing Code Generators. This is on page 238 of the Proceedings. On page 244 there is a section named "Discussion" whose first paragraph says in part, "The sample rules above demonstrate all principal features of the rule language. The rule compiler is written in the Icon programming language and takes about 1000 lines." It's nice to see an application of Icon that is part of some cutting-edge research. (The acknowledgements also credit Dave Hanson with some of the work.) David S. Cargo From MYankowski.BSPO@DOCKMASTER.NCSC.MIL Mon Aug 14 14:12:27 1989 Received: from DOCKMASTER.NCSC.MIL by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA10496; Mon, 14 Aug 89 14:12:27 MST Date: Mon, 14 Aug 89 17:04 EDT From: MYankowski@DOCKMASTER.ARPA Subject: compilation problems To: icon-group@arizona.edu Message-Id: <890814210448.224026@DOCKMASTER.ARPA> I am trying to compile an icon source file and a c source file together using iconc under 4.2 BSD. The program complies fine but I get a illegal instruction (core dumped) when I execute the program. The two source files are as follows: =========== one.icn: =========== external two program main() write("this is from main") end ========== two.c ========== Btwo() { printf("this is inside the C function two\n"); } the compile line is: $ iconc one.icn two.c then to execute one $ one this is from main illegal instruction (core dumped) I have the book "The Icon Programming Language" which references a technical report as guidance for inclusion of c source. Since this technical reference is out of date I purchased the book "The Implementation of the Icon Programming Language". I have not thoroughly read the book, but from my examination of the book it would seem that I should write a function to extend the language. Eventually I will try this but for now I would like to just do it as outlined above. Any suggestions would be appreciated. I am running version 5 of ICON which I will upgrade when I get the chance. By the way, how often are the newsletter and the email stuff released. Michael Yankowski DOCKMASTER From icon-group-request Tue Aug 15 10:42:09 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA06591; Tue, 15 Aug 89 10:42:09 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22567; Tue, 15 Aug 89 10:25:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Aug 89 14:55:33 GMT From: hubcap!ncrcae!PEDEV!rogerson@gatech.edu (Dale Rogerson) Organization: NCR Corp., Engineering & Manufacturing - Columbia, SC Subject: Icon for MS Windows Message-Id: <2664@PEDEV.Columbia.NCR.COM> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Is anyone currently working on a port of ICON to Microsoft Windows? I would be interested in preforming this port depending on how "friendly" the source code is. Any information, ideas, or help would be appriciated. -----Dale Rogerson----- From lti!talmage Tue Aug 22 20:16:04 1989 Received: from BU-IT.BU.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA13159; Tue, 22 Aug 89 20:16:04 MST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA09373; Tue, 22 Aug 89 23:12:42 EDT Received: by buita.bu.edu (3.2/4.7) id AA19304; Tue, 22 Aug 89 23:12:53 EDT Received: from waltham.lti.com by lti.com (4.0/SMI-4.0) id AA07400; Tue, 22 Aug 89 18:14:28 EDT Date: Tue, 22 Aug 89 18:14:28 EDT From: lti!talmage (David Talmage) Message-Id: <8908222214.AA07400@lti.com> Received: by waltham.lti.com (4.0/SMI-4.0) id AA02330; Tue, 22 Aug 89 18:13:14 EDT To: icon-group@arizona.edu Subject: Amiga Icon V7.5 environment variables Reply-To: lti!talmage Icon Trouble Report Name David W. Talmage Address P. O. Box 8848 Salem, MA 01971-8848 Telephone (617) 894-4939 (home) Electronic mail address talmage@lti.uucp, talmage@luvthang.uucp Icon version 7.5 Computer Amiga Operating system AmigaDOS 1.3 Date 22 August, 1989 Description of the problem: Icon doesn't use AmigaDOS 1.3-style environment variables. This is easy enough to fix. Enclosed is are getenv() and setenv(), two Icon procedures for manipulating environment variables. You may distribute them freely. Approximately: # Amiga-specific getenv that uses AmigaDOS 1.3-style environment variables. # # parameters: # environment_variable a string that names some environment # variable # # returns: # if environment_variable exists, getenv() returns the string value # of environment_variable. # # if environment_varable does not exist, getenv() fails. # procedure getenv( environment_variable ) local value # if environment_variable exists, this is its value local env_file # the file in ENV: that represents environment_variable # fail if environment_variable doesn't exist (env_file := open( "ENV:"||environment_variable, "r" ) ) | fail # fail if environment_variable doesn't exist (value := read( env_file ) ) | fail close( env_file ) return value # environment variable exists end # getenv # Amiga-specific setenv that uses AmigaDOS 1.3-style environment variables. # # parameters: # environment_variable a string that names some environment # variable # # value a string containing the new value of # environment_variable # # returns: # if setenv() can create or modify environment_variable, it returns # value. # # if setenv() cannot create or modify environment_variable, it fails. # # procedure setenv( environment_variable, value ) local env_file # the file in ENV: that represents environment_variable # fail if we cannot create or modify #environment_variable (env_file := open( "ENV:"||environment_variable, "w" ) ) | fail # fail if we cannot modify environment_variable (write( env_file, value ) ) | fail close( env_file ) return value # we can create or modify environment_variable end # setenv Attach additional information, listings, enclose source code, etc., as appropriate. Send to: Icon Project Department of Computer Science Gould-Simpson Building The University of Arizona Tucson, AZ 85721 U.S.A. (602) 621-2018 icon-project@arizona.edu (Internet) ... {uunet, allegra, noao}!arizona!icon-project (uucp) IPD46a June 2, 1989 From lti!talmage Tue Aug 22 20:16:04 1989 Received: from BU-IT.BU.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA13158; Tue, 22 Aug 89 20:16:04 MST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA09372; Tue, 22 Aug 89 23:12:42 EDT Received: by buita.bu.edu (3.2/4.7) id AA19301; Tue, 22 Aug 89 23:12:52 EDT Received: from waltham.lti.com by lti.com (4.0/SMI-4.0) id AA07392; Tue, 22 Aug 89 17:56:39 EDT Date: Tue, 22 Aug 89 17:56:39 EDT From: lti!talmage (David Talmage) Message-Id: <8908222156.AA07392@lti.com> Received: by waltham.lti.com (4.0/SMI-4.0) id AA02328; Tue, 22 Aug 89 17:55:25 EDT To: icon-group@arizona.edu Subject: Amiga Icon v7.5 trouble Reply-To: lti!talmage Icon Trouble Report Name David W. Talmage Address P. O. Box 8848 Salem, MA 01971-8848 Telephone (617) 894-4939 (home) Electronic mail address talmage@lti.uucp, talmage@luvthang.uucp Icon version 7.5 Computer Amiga Operating system AmigaDOS 1.3 Date 22 August, 1989 Description of the problem: Icont cannot resolve references to files in any directory but the current one. This happens regardless of the value of IPATH. Example program: link "DH0:icon/ipl/procs/dt-strutil" # icont can't find this. link "dt-strutil" # If this is in the current # directory, then icont does find # it. procedure main() local c c := "a" c := upper_case( c ) write( c ) end Attach additional information, listings, enclose source code, etc., as appropriate. Send to: Icon Project Department of Computer Science Gould-Simpson Building The University of Arizona Tucson, AZ 85721 U.S.A. (602) 621-2018 icon-project@arizona.edu (Internet) ... {uunet, allegra, noao}!arizona!icon-project (uucp) IPD46a June 2, 1989 From ralph Wed Aug 23 08:12:20 1989 Date: Wed, 23 Aug 89 08:12:20 MST From: "Ralph Griswold" Message-Id: <8908231512.AA09025@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA09025; Wed, 23 Aug 89 08:12:20 MST To: icon-group Subject: Conference reminder The Fourth International Conference on Symbolic and Logical Computing will be held October 5-6 at Dakota State University. This conference provides an excellent opportunity for persons who are interested in Icon and SNOBOL4 to get together. Conference information is available from Eric Johnson 114 Beadle Hall Dakota State University Madison, South Dakota 57042 605-256-5270 ERIC@SDNET.BITNET I'll also be glad to answer questions about the conference. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From lti!talmage Wed Aug 23 14:17:49 1989 Received: from BU-IT.BU.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA02801; Wed, 23 Aug 89 14:17:49 MST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA10640; Wed, 23 Aug 89 17:14:27 EDT Received: by buita.bu.edu (3.2/4.7) id AA10952; Wed, 23 Aug 89 17:14:39 EDT Received: from waltham.lti.com by lti.com (4.0/SMI-4.0) id AA08104; Wed, 23 Aug 89 11:38:36 EDT Date: Wed, 23 Aug 89 11:38:36 EDT From: lti!talmage (David Talmage) Message-Id: <8908231538.AA08104@lti.com> Received: by waltham.lti.com (4.0/SMI-4.0) id AA02462; Wed, 23 Aug 89 11:37:18 EDT To: icon-group@arizona.edu Cc: icon-project@arizona.edu Subject: Apology Reply-To: lti!talmage By mistake I posted two bug reports to icon-group. Had I two brain cells to rub together, I would have read the bottom of the Icon Trouble Report form and sent them to icon-project instead. I'm sorry. I won't do it again. DT ------------------------------------------------------------------------------ David W. Talmage, Systems Programmer ...!{buita,bbn}!lti!talmage Language Technology, Inc. talmage%lti.uucp@bu-it.bu.edu 27 Congress St., Salem, MA 01970 (508) 741-1507 From icon-group-request Sat Aug 26 16:26:47 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA23912; Sat, 26 Aug 89 16:26:47 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA08990; Sat, 26 Aug 89 16:20:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Aug 89 08:01:00 GMT From: m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh@uxc.cso.uiuc.edu Subject: Why ICON? Message-Id: <223000001@s.cs.uiuc.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I have been reading this notesfile for awhile, and must say I am mystified by its very presence. What is ICON? What is so special about it as a lanaguage that it merits its own notesfile? So far, most of what I've read has been about ICON bugs in Amiga! I would appreciate some explanation about the purpose of this language and whether it is at all worth learning. From icon-group-request Sun Aug 27 02:57:12 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA13325; Sun, 27 Aug 89 02:57:12 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA04742; Sun, 27 Aug 89 02:51:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Aug 89 22:30:17 GMT From: mailrus!sharkey!mcf!mibte!gamma!thumper!clayton@handies.ucar.edu (R. Clayton) Organization: Bellcore, Morristown, N.J. Subject: Another testimonial Message-Id: <1693@thumper.bellcore.com> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu My icon programs often are written as a series of filters on a objects in a stream. The filters do one object look-ahead on the stream with a read/pushback sequence, with read implemented something like this: global push_back_o procedure next_o() local o if \push_back_o then { o := push_back_o push_back_o := &null return o } else return read_o() end # next_o It eventually occurred to me that I could use the local variable's &null initialization to rewrite the then part of the if statement as return o :=: push_back_o which lets the procedure body collapse to return ((\push_back_o & (o :=: push_back_o)) | read_o()) and again to return (o :=: \push_back_o) | read_o() From kwalker Sun Aug 27 12:43:02 1989 Date: Sun, 27 Aug 89 12:43:02 MST From: "Kenneth Walker" Message-Id: <8908271943.AA28708@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA28708; Sun, 27 Aug 89 12:43:02 MST In-Reply-To: <223000001@s.cs.uiuc.edu> To: icon-group Subject: Re: Why ICON? > Date: 25 Aug 89 08:01:00 GMT > From: m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh@uxc.cso.uiuc.edu > > I have been reading this notesfile for awhile, and must say I am mystified by > its very presence. What is ICON? Here is my standard brief description of Icon. Icon is a high level programming language designed for string processing and other non-numeric applications (numeric processing can be done, but the language and implementation are not tuned for it). Goal-directed evaluation with control backtracking is an integral part of the language. However, Icon is very different from other languages, such as Prolog, which use this evaluation scheme. Icon has a rich set of control structures which use and control backtracking. Most of these control structures look and act very much like the control structures of more traditional languages, allowing Pascal-like programming where the full power of goal-directed evaluation is not required. Icon incorporates generators as a natural feature within this goal-directed evaluation scheme. Icon has a flexible run-time type system: variables may take on values of any type and automatic type conversions are preformed as needed by operations. There are a variety of types including strings, sets, associative tables, and lists with positional, queue, and stack access methods. All storage management is automatic; garbage collection is performed as needed. > What is so special about it as a lanaguage > that it merits its own notesfile? So far, most of what I've read has been > about ICON bugs in Amiga! I would appreciate some explanation about the > purpose of this language and whether it is at all worth learning. I am on the Icon Project, so my opinions are somewhat biased. Perhaps others of you can comment on what you find to be Icon's strengths and weaknesses. What do you use Icon for and why? What don't you use Icon for and why? (Perhaps I will express some of my biased opinions after others have commented.) Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker From att!ihuxy!nowlin Sun Aug 27 15:04:06 1989 Date: Sun, 27 Aug 89 15:04:06 MST Message-Id: <8908272204.AA02985@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA02985; Sun, 27 Aug 89 15:04:06 MST From: ihuxy!nowlin (Jerry D Nowlin +1 312 979 0441) To: att!arizona!icon-group Subject: Re: why Icon > Date: Sun, 27 Aug 89 12:43:02 MST > From: "Kenneth Walker" > > > Date: 25 Aug 89 08:01:00 GMT > > From: m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh@uxc.cso.uiuc.edu > > > > I have been reading this notesfile for awhile, and must say I am > > mystified by its very presence. What is ICON? > > What is so special about it as a language > > that it merits its own notesfile? So far, most of what I've read has > > been about ICON bugs in Amiga! I would appreciate some explanation > > about the purpose of this language and whether it is at all worth > > learning. > > I am on the Icon Project, so my opinions are somewhat biased. Perhaps > others of you can comment on what you find to be Icon's strengths > and weaknesses. What do you use Icon for and why? What don't you > use Icon for and why? (Perhaps I will express some of my biased > opinions after others have commented.) I've been using Icon for around five years now. Most of my experience is with languages like FORTRAN, BASIC, and C but Icon is now my favorite language by far. My favorite parts of Icon are dynamic memory allocation, strings as a real data type along with string scanning, goal directed evaluation, and generation. I've written many Icon programs; calculators, spelling checkers, a version of grep, games, text formatting filters, and even some expert systems prototypes. Most of them have operated on text or some other type of symbolic data. My last large Icon project (~4000 lines) was a simulator for a screen generator. The target system for the real screen generator was in limited supply and a simulator that would allow testing on other systems was needed. Icon allowed me to easily parse the screen generation language and implement an interpreter for the executable portions of it. The simulator is easy to modify and maintain since Icon is so understandable. We can now test on all the machines in our computing environment from 3B2s to mainframes since Icon runs on all of those machines. Icon does have some limitations though. I've since converted the parsing portion of the simulator into C for another project because I needed to generate intermediate data files that contained binary C structures. If it weren't for this language specific portion of the requirements Icon would have been used for this project too. One of the real advantages of Icon is the ability to code simple sequences in a simple way. My favorite example is opening files. In C you have to have a minimum amount of code to declare variables and check for errors: FILE *in; if ((in = fopen(infile,"r")) == NULL) { fprintf(stderr,"I can't open '%s' for reading\n",infile); exit(1); } In Icon there is no declaration to bother with and the error checking is simple: (in := open(infile,"r")) | stop("I can't open '",infile,"' for reading") The extra parentheses are to enforce the order of precedence that's wanted but since stop() terminates the program they aren't really needed. I find the Icon example much simpler to read and understand than the C example. If you use examples that take advantage of goal directed evaluation the simplifications become really amazing. I could go on for a long time but you get the idea. I would still be a die hard C fan if I hadn't had a friend practically force me to read The Icon Programming Language by Ralph and Madge Griswold. I'm now a happy convert and busy proselytizing everywhere I go. Try it and you'll get hooked too. Jerry Nowlin (...!att!ihuxy!nowlin) From att!ihuxy!nowlin Sun Aug 27 15:23:45 1989 Date: Sun, 27 Aug 89 15:23:45 MST Message-Id: <8908272223.AA03566@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA03566; Sun, 27 Aug 89 15:23:45 MST From: ihuxy!nowlin (Jerry D Nowlin +1 312 979 0441) To: att!arizona!icon-group Subject: Re: P.S to why Icon Just a P.S. to the last mail I sent. The simulator I was talking about not only parsed a language, it interpreted it, allowed extensive tracing of the language as it was interpreted, and generated screen displays. It also generated PostScript, pic, and another color printer language for hardcopies of the screen displays. The entire source was only 3,909 lines. In contrast the C program that did nothing but parse the same language and generate binary C readable intermediate files was over 7,000 lines. I know these kinds of numbers are open to interpretation but since I wrote both programs I think the comparison is still meaningful. Icon is an elegant language. Jerry Nowlin (...!att!ihuxy!nowlin) From icon-group-request Mon Aug 28 01:26:57 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA22592; Mon, 28 Aug 89 01:26:57 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA04978; Mon, 28 Aug 89 01:16:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Aug 89 22:31:50 GMT From: agate!saturn!ucscb.UCSC.EDU!kellyp@ucbvax.Berkeley.EDU (73716000) Organization: University of California, Santa Cruz; CATS Subject: looking for Emacs setup for icon programming Message-Id: <8901@saturn.ucsc.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I'm looking for an Emacs Icon programming set-up file. Suggestions? Patrick Kelly ----- kellyp@ucscb.UCSC.EDU From icon-group-request Mon Aug 28 09:45:52 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA19537; Mon, 28 Aug 89 09:45:52 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA28017; Mon, 28 Aug 89 09:39:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Aug 89 03:05:41 GMT From: sumax!amc-gw!nwnexus!intek01!mark@beaver.cs.washington.edu (Mark McWiggins) Organization: Integration Technologies Inc. (Intek), Bellevue WA Subject: Re: Why ICON? Message-Id: <236@intek01.UUCP> References: <223000001@s.cs.uiuc.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu mccaugh@s.cs.uiuc.edu writes: >I have been reading this notesfile for awhile, and must say I am mystified by >its very presence. What is ICON? What is so special about it as a lanaguage >that it merits its own notesfile? So far, most of what I've read has been >about ICON bugs in Amiga! I would appreciate some explanation about the >purpose of this language and whether it is at all worth learning. Icon is the successor to Snobol4, a rather weird and wonderful pattern-matching language developed by Ralph Griswold et. al., I guess reaching back into the 60's. Griswold and cohorts took some of the ideas from Snobol and put them into a more structured, Pascal-ish language. (Snobol control structures are unusual.) I haven't really used it, but I have the book and it looks good. I've seen a reference recently on automatic generation of compiler BACK ENDS (not just another parser generator) that was written in Icon, so obviously some high-powered types find it useful. I also understand that it runs pretty much everywhere and on everything, and since it was developed by public money it's pretty much public domain. (Last I heard; I'm sure someone will correct me if I'm wrong.) I've been meaning to look further into Icon myself for a while, and may have just convinced myself ... :) -- Mark McWiggins Integration Technologies, Inc. (Intek) +1 206 455 9935 DISCLAIMER: I could be wrong ... 1400 112th Ave SE #202 Bellevue WA 98004 uunet!intek01!mark Ask me about C++! From icon-group-request Mon Aug 28 14:43:24 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA09589; Mon, 28 Aug 89 14:43:24 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA15597; Mon, 28 Aug 89 14:33:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Aug 89 16:22:30 GMT From: att!cbnewsc!kca@ucbvax.Berkeley.EDU (k.c.archie) Organization: AT&T Bell Laboratories Subject: Re: Why Icon? Message-Id: <2742@cbnewsc.ATT.COM> References: <223000001@s.cs.uiuc.edu>, <8908271943.AA28708@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu > What do you use Icon for and why? What don't you > use Icon for and why? > Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 > +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker We used Icon to prototype a new test management system we were developing several years ago. Since we were experimenting with new testing techniques we decided to experiment with new development techniques as well. One of the team members was well versed in Icon and convinced us to try it. This was a risk as very few people are familiar with Icon. If we had gotten into schedule problems on a C project, we could grab dozens of people out of the hallways here to help. Not so with Icon. But, we found that Icon was simple to pick up, at least a working knowledge. I found that I could read and modify Icon code even before I had read the book. The first release of the system was written largely in Icon and was (and is) a great success. Nevertheless, we converted it entirely to C over the first couple of years of its life. This was done for two reasons. The most important was speed. Since the runtime system is an interpretor, large Icon programs are rather slow. The second reason is that it is easier for new people coming into the project to read C code than Icon. This appears to contradict what I said above about Icon being easy to learn. That is true but most people here are already well versed in C and it is easier not to have to teach them a new language. But the major drawback was speed. If we had had an Icon compiler, we probably would have left the system in Icon. A small study indicated that converting Icon to C doubled the size of the source code and doubled the execution speed. I am convinced by this that Icon is an excellent language for trying out ideas before casting them into stone. It could be used for production code more easily if it had a compiler and if it had easier access to libraries like curses. **kent Kent Archie att!iwtbv!kca From lti!lti.com!talmage Tue Aug 29 08:17:15 1989 Received: from BU-IT.BU.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA23401; Tue, 29 Aug 89 08:17:15 MST Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) id AA22697; Tue, 29 Aug 89 11:13:53 EDT Received: by buita.bu.edu (3.2/4.7) id AA09887; Tue, 29 Aug 89 11:14:07 EDT Received: from waltham.lti.com by lti.com (4.0/SMI-4.0) id AA03066; Tue, 29 Aug 89 09:56:26 EDT Date: Tue, 29 Aug 89 09:56:26 EDT From: talmage@lti.com (David Talmage) Message-Id: <8908291356.AA03066@lti.com> Received: by waltham.lti.com (4.0/SMI-4.0) id AA03695; Tue, 29 Aug 89 09:54:53 EDT To: icon-group@arizona.edu In-Reply-To: (k.c.archie's message of 28 Aug 89 16:22:30 GMT <2742@cbnewsc.ATT.COM> Subject: Why Icon? Reply-To: lti!talmage > What do you use Icon for and why? What don't you > use Icon for and why? > Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 > +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker It took me about two minutes to write a useable "strings" finder (a la UNIX's strings(1)) in Icon. I've built a travesty generator in Icon. It's a toy built around a frequency table. You feed it a pattern length, n, and a text, say 5000 words from Jay McInerney's _Bright Lights, Big City_, and it prints text that looks, statistically, as if Jay McInerney wrote it. The output may not be intelligible, but it is easily verified that patterns of some length n occur with the same frequency in the input and the output. As n increases, the intelligibility of the output increases and so does the output's resemblance to the input. After hours, I'm doing some machine translation experiments in Icon. My Amiga now speaks, more or less, Esperanto. By December, I think I'll have a (possibly useful) Esperanto-to-English translator. Would that I were a student again so I could spend more time on this project! DT ------------------------------------------------------------------------------ David W. Talmage, Systems Programmer ...!{buita,bbn}!lti!talmage Language Technology, Inc. talmage%lti.uucp@bu-it.bu.edu 27 Congress St., Salem, MA 01970 (508) 741-1507 From jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK Tue Aug 29 14:31:08 1989 Received: from NSFNET-RELAY.AC.UK by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA19269; Tue, 29 Aug 89 14:31:08 MST Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP id aa10697; 29 Aug 89 21:49 BST Date: Tue, 29 Aug 89 21:57:06 BST Message-Id: <27070.8908292057@aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: Why Icon? To: icon-group@arizona.edu > What do you use Icon for and why? What don't you > use Icon for and why? I like Icon, but I don't use it very much because it's not (or at least wasn't) interactive. I like to be able to define and call procedures interactively, like I can in Lisp or Prolog. From gudeman Tue Aug 29 14:50:34 1989 Date: Tue, 29 Aug 89 14:50:34 MST From: "David Gudeman" Message-Id: <8908292150.AA20214@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA20214; Tue, 29 Aug 89 14:50:34 MST To: agate!saturn!ucscb.UCSC.EDU!kellyp@ucbvax.Berkeley.EDU Cc: icon-group@arizona.edu In-Reply-To: (73716000's message of 27 Aug 89 22:31:50 GMT <8901@saturn.ucsc.edu> Subject: looking for Emacs setup for icon programming What Emacs are you using, GNU, Unipress, Micro-, etc.? From tenaglia%astroatc.UUCP@cs.wisc.edu Thu Aug 31 06:12:43 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA23228; Thu, 31 Aug 89 06:12:43 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Thu, 31 Aug 89 08:09:12 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA28882; Thu, 31 Aug 89 07:52:07 CDT Date: Thu, 31 Aug 89 07:52:07 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8908311252.AA28882@astroatc.UUCP> To: icon-group@arizona.edu Dear Icon-group, Here's another of my favorite and handy utilities. I include the instructions first, then the code. There is a variable called 'os' which kind of tells it how to behave on different platforms. It works best in unix and vms. In DOS it may run short of memory (I use Icon 5.9 in DOS because it uses less memory). Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 USAGE AND DESCRIPTION OF THE IAWK/IGREP UTILITY INTRODUCTION : This utility was written because of something I observed in the creation of many file mungers/analyzers using the icon language. There were all the same program except for a couple of lines that accomplished the actual filtering or editing. So why should one rewrite the same program over and over again, when the same job could be done by a computer? So that is what IAWK/IGREP is. Actually that is two different names for the same program. 2 different names were chosen because the program is used basically 2 different ways. AWK is a unix utility used to gross global conversions on files. It reads one file and writes another. The AWK language file supplies a series of expressions and rules that perform the filtering of the data file. It is a nonprocedural language. GREP is a directory/file scanning utility. A byte stream is run through it, and a 'regular expression' is beat against the stream. And when the regular expression is matched, the stream record is displayed. These are useful but limitted. The regular expression is a powerful, but nonprocedural construct. Therefore, what about such a utility that used icon expressions? They can be more precise, and do more complex things. And so this is just what was done. When run with only one filespec, the program behaves like GREP, simply displaying the analysis. When run with two filespecs, it is running like AWK, generating the second filespec as the output file. USAGE : USAGE: iawk infile [outfile] Once invoked, you will be prompted for a series of expressions. The prompting will stop after the first empty line. This signals the end of the expression entry phase. The expressions should be icon language expressions. They are inserted into a program called grepawk.icn. Its basic form is as follows : global MOST HANDY VARIABLES procedure main() INITIALIZE GLOBAL VARIABLES while write(update(read())) OUTPUT NUMERICAL SUMMARY IF ANY end procedure update(line) # ... user inputted expressions appear here end procedure parse(text,delims) # ... converts string text to list w/respect to delims end USAGE AND DESCRIPTION OF THE IAWK/IGREP UTILITY USAGE : cont... USAGE: iawk infile [outfile] continued ... As you may have noticed, there is a goodly collection of global variables. These are very useful. The goal of the program is as follows Whatever update() returns, is what is displayed or written to the file. Below is a description of the global variables, in case you haven't figured it out from the source listing above. line - The line read in. num - The line number (position) within the input file. flags - These are used to toggle certain features. Currently only one flag "nocount" is supported. Append "nocount" to flags to suppress the final count summary. count - A table that holds counts of things. All non-zero entries are summarized at the end of the process. w1 is the width of the entry column (default=20). w2 is the width of the tally column (default=8). ebcdic - A mapping table for ascii/ebcdic file translations. unascii - A mapping table useful for wordstar print files. alpha - Alpha characters used with rot13. rot13 - Cheap and dirty encryption table. tty, crt, kbd - Used to force output to screen or take output from keyboard. These are all identical. You may begin the expressions section with such things as ... static var1,var2,... initial { var1 := .... var2 := ... } Remember that the object of the 'return' is what is displayed in an IGREP or written to the file in an IAWK. Upon completion several things happen. If the table count has been loaded with anything, a summary is output. This can be suppressed by appending "nocount" to the flags var- iable. Finally the grepawk files that were created to do the work are deleted unless "keep" is appended to the flags variable. The program itself follows. Clip and use (about 90 to 100 lines). #TITLE ICON EQUIVALENT OF GREP AND AWK #SUB ONE PROGRAM DOES BOTH #EJECT ################################################################# # # # IAWK.ICN 08/29/88 BY CHRIS TENAGLIA # # IGREP.ICN # # # ################################################################# procedure main(param) platform := "vms" # either unix, vms, or dos case platform of { "unix" : vdu := "/dev/tty" "vms" : vdu := "tt:" "dos" : vdu := "con" default : stop("platform ",platform," not recognized.") } front := [ "#################################################################", "# #", "# GREPAWK.ICN " || &dateline || " BY TENAGLIA #", "# #", "# THIS IS THE INTERMEDIATE PROGRAM THAT HANDLES THE MUNGING #", "# #", "#################################################################", "global count,crt,tty,alpha,rot13,ebcdic,kbd,lnum", "procedure main()", " alpha:= \042ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\042", " rot13:= \042NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm\042", " ebcdic:= \042\\000\\001\\002\\003\\234\\011\\206\\177\\227\\215\\216\\013\\014\\015\\016\\017\042||", " \042\\020\\021\\022\\023\\235\\205\\010\\207\\030\\031\\222\\217\\034\\035\\036\\037\042||", " \042\\200\\201\\202\\203\\204\\012\\027\\033\\210\\211\\212\\213\\214\\005\\006\\007\042||", " \042\\220\\221\\026\\223\\224\\225\\226\\004\\230\\231\\232\\233\\024\\025\\236\\032\042||", " \042\\040\\240\\241\\242\\243\\244\\245\\246\\247\\250\\133\\056\\074\\050\\053\\041\042||", " \042\\046\\251\\252\\253\\254\\255\\256\\257\\260\\261\\135\\044\\052\\051\\073\\136\042||", " \042\\055\\057\\262\\263\\264\\265\\266\\267\\270\\271\\174\\054\\045\\137\\076\\077\042||", " \042\\272\\273\\274\\275\\276\\277\\300\\301\\302\\140\\072\\043\\100\\047\\075\\042\042||", " \042\\303\\141\\142\\143\\144\\145\\146\\147\\150\\151\\304\\305\\306\\307\\310\\311\042||", " \042\\312\\152\\153\\154\\155\\156\\157\\160\\161\\162\\313\\314\\315\\316\\317\\320\042||", " \042\\321\\176\\163\\164\\165\\166\\167\\170\\171\\172\\322\\323\\324\\325\\326\\327\042||", " \042\\330\\331\\332\\333\\334\\335\\336\\337\\340\\341\\342\\343\\344\\345\\346\\347\042||", " \042\\173\\101\\102\\103\\104\\105\\106\\107\\110\\111\\350\\351\\352\\353\\354\\355\042||", " \042\\175\\112\\113\\114\\115\\116\\117\\120\\121\\122\\356\\357\\360\\361\\362\\363\042||", " \042\\134\\237\\123\\124\\125\\126\\127\\130\\131\\132\\364\\365\\366\\367\\370\\371\042||", " \042\\060\\061\\062\\063\\064\\065\\066\\067\\070\\071\\372\\373\\374\\375\\376\\377\042", " crt := open(\042" || vdu || "\042,\042b\042)", " kbd := crt ; tty := crt", " lnum := 1", " count := table(0)", " while line := read() do", " {", " write(update(line,lnum))", " lnum +:= 1", " }", " write(crt,\042\\e[1;7mProcess Completed !\\e[m\042)", " end", "procedure parse(line,vals)", " static chars", " initial chars := &cset -- vals", " tokens := []", " line ? while tab(upto(chars)) do put(tokens,tab(many(chars)))", " return tokens", " end", "procedure update(line,num)" ] items := [] if *param = 0 then stop("Missing filespec(s)\n", "Usage: (awk or grep) infile [outfile]") if *param = 1 then write("Grepping ",param[1],"\n") if *param = 2 then write("Awking from ",param[1]," to ",param[2],"\n") repeat { writes("\e[1;7m_expression :\e[m ") if not(line := read()) then break if line == "" then break put(items,(" " || line)) } (out := open("grepawk.icn","w")) | stop("Can't create grepawk.icn !") every write(out,!front) every write(out,!items) write(out," end") close(out) write("\n\e[1;7mCompiling expressions for transmogrification.\e[m\n") From := (" <" || param[1])|"" To := (" >" || param[2])|"" system(("icont grepawk.icn -x" || From || To)) if not find("keep",flags) then { while remove("grepawk.icn") do writes(".") while remove("grepawk.icx") do writes(".") while remove("grepawk") do writes(".") } end ######################################################################### From tenaglia%astroatc.UUCP@cs.wisc.edu Thu Aug 31 08:12:22 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA28445; Thu, 31 Aug 89 08:12:22 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Thu, 31 Aug 89 10:09:02 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA03653; Thu, 31 Aug 89 10:05:57 CDT Date: Thu, 31 Aug 89 10:05:57 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8908311505.AA03653@astroatc.UUCP> To: icon-group@arizona.edu Dear Icon_Group, Here at Astronautics in Milwaukee we have ICON on VAX/VMS, Unix Workstations and superminis, and MS-DOS PCs. We have found it very portable. I'd like to flame a little on the matter. 1. Under VAX/VMS it provides some unix/shell like functionality. For instance a generic filter can be written and the output redirected such as follows, $ iconx filter outputfile. You can also open a process for read or write like a file using 'open' with the "pr" or "pw" option. 2. Icon is fairly quick and easy to learn. It is a very rich language that can be used in very creative fashions. In the projects we've done, we had to agree on rules of style and complexity to keep the code maintainable. Icon styles can be in the spirit of pascal, or lisp, or c, or ada, etc,... We save the clever stuff for our personal research and utilities. Best of all icon doesn't violate structured programming rules by implementing a "goto" statement like BASIC, C, FORTRAN, PASCAL, or ADA. Another great feature is that all of it's functions return something useful, not just a 0 or 1 or -1 or a pointer. This makes everything 'fit' together well. 3. It's in the public domain. There are commercial versions beginning to appear. I think the demand for native mode compilers will drive this, and I think it is OK if the Icon-Project wants it to be this way. I think the public domain nature of the language is fantastic. It's what I used to get my company to obtain it. 4. Disadvantages... (Playing the devils advocate) To be fair I've included what I consider to be disadvantages as well. First is that is can be slow since it doesn't generate optimized pure executables. This is especially true on VAX/VMS on an 11/780 or weaker CPU. The greatest disadvantage is it spoils you after a time. When you return to some of the old languages like BASIC, FORTRAN, PASCAL, or C they seem so awkward(BASIC,FORTRAN), cryptic(C), and nitpicky(PASCAL,ADA) you dread having to come back. 5. Useful work done with ICON here includes such things as ... a. Personal databases. b. BASIC style line editor for hardcopy or graphics devices. c. PLM to C source language transmogrifier. d. Numerous file translation/conversion tools. e. Graphics interface and programs using unix 'plot'. f. VAX System Mgt report generators using the accounting data. g. Unix System management utilities and reports. Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 From dscargo@cim-vax.honeywell.com Thu Aug 31 15:08:17 1989 Message-Id: <8908312208.AA05244@megaron.arizona.edu> Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA05244; Thu, 31 Aug 89 15:08:17 MST Date: 31 Aug 89 16:46:00 CST From: "DAVE CARGO" Subject: IAWK To: "icon-group" After seeing and using IAWK (albeit in a trivial fashion) I realized that it lacked some features that I think would make it much more useful. (1) The code that was input by the user should be written to a log file of some sort, for future reference. (2) There should be some kind of simple include directive that allows the user to retrieve pieces of code from a specified file. (3) There should be an option to suppress output of empty results. (I hadn't tried having update return &fail as a result, but that might work.) (4) The name of the output routine should be a global variable intialized to the standard output routine. The user can then input his own output routine and change the value of the variable containing the routine to call. This allows the user to get more control of the output when needed. Changes 1 and 2 used together would allow some iteration, providing a method for the users to make an initial guess as to what they want and then tuning the results. (Alternatively the deletion of the generated program could be turned off or made optional.) Any responses or other opinions (especially invited from the author). dsc From tenaglia%astroatc.UUCP@cs.wisc.edu Sat Sep 2 07:18:54 1989 Received: from spool.cs.wisc.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA14207; Sat, 2 Sep 89 07:18:54 MST Received: from astroatc.UUCP by spool.cs.wisc.edu; Sat, 2 Sep 89 09:15:32 -0500 Received: by astroatc.UUCP (5.51/4.7) id AA09263; Sat, 2 Sep 89 08:25:14 CDT Date: Sat, 2 Sep 89 08:25:14 CDT From: tenaglia%astroatc.UUCP@cs.wisc.edu (Chris Tenaglia) Message-Id: <8909021325.AA09263@astroatc.UUCP> To: icon-group@arizona.edu, dscargo@cim-vax.honeywell.com Subject: ignature Cc: icon-group@arizona.edu Thanks for the observations. I like the 'include' idea a lot. I'm not sure but I think if you at the 'while remove' lines they are (should) be nested in a 'if not(find("keep",flags)) then' structure. Thus, if you have an 'initial' block with 'flags ||:= "keep"' the grepawk files will not be removed. On supression of empty output, if nothing is returned, it fails automatically, causing the write() in the caller to fail. The static and initial are very useful in the update() procedure. Also if you need more procedures, you can end the update() procedure with 'end' and then start 'procedure ????()' on the next line. There are global variables called tty, crt, and kbd. These equate to stdin and stdout for direct i/o. I use them for debugging usually. I think I will try the 'include' idea, and implement another flags value called "log" that will generate an iawk.log file that will record the expressions for later inclusion. If you add some goodies, don't hesitate to mail me a sample. Yours truly, Chris Tenaglia Astronautics Corporation of America 4115 N. Teutonia Avenue Milwaukee, Wi 53209 USA (414) 447-8200 X-421 From icon-group-request Mon Sep 4 05:48:56 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA07747; Mon, 4 Sep 89 05:48:56 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA13394; Mon, 4 Sep 89 05:35:37 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 89 09:53:44 GMT From: mcsun!sunic!dkuug!iesd!iesd.auc.dk!kasper@uunet.uu.net (Kasper Osterbye) Organization: Mathematics & Computer Science, University of Aalborg Subject: Amiga Icon ? Message-Id: <1989Sep4.095344.24219@iesd.auc.dk> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Hi, I want to get hold of the latest Icon version for the amiga! I know that it is at the university of Arizona, but I need the exact CITENUMBER (that is NUMBER, not name, as our host table is nect to nonexistent). Can anyone please help me? Thanks in advance, Kasper Osterbye. -- Kasper Osterbye Internet: iesd!kasper@uunet.uu.net Institute for electronic systems UUCP: ...!mcvax!iesd!kasper Strandvejen 19, 9000 Aalborg DENMARK. (W) +45 98 13 87 88-285 (H) +45 98 37 30 65 From icon-group-request Wed Sep 6 03:49:29 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA25884; Wed, 6 Sep 89 03:49:29 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22616; Wed, 6 Sep 89 03:35:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 89 00:00:21 GMT From: mstan!amull@uunet.uu.net (Andrew P. Mullhaupt) Organization: Morgan Stanley & Co. NY, NY Subject: Availablility of PD ICON Message-Id: <366@ewr.Morgan.COM> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I was intrigued to find that SNOBOL4 had a successor, reportedly in the public domain. Is this available for IBM-PC/AT boxes running MS-DOS or OS/2? Thanks Andrew Mullhaupt From icon-group-request Wed Sep 6 20:34:50 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA04207; Wed, 6 Sep 89 20:34:50 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA15837; Wed, 6 Sep 89 20:26:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 89 15:50:20 GMT From: esquire!yost@nyu.edu (David A. Yost) Organization: DP&W, New York, NY Subject: anyone have sun4 coexpressions working? Message-Id: <1398@esquire.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu If so, please reply to yost@esquire.dpw.COM and to icon-project@arizona.edu. Thanks. --dave yost From icon-group-request Fri Sep 8 10:06:11 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA12395; Fri, 8 Sep 89 10:06:11 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA11758; Fri, 8 Sep 89 09:54:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 89 16:43:55 GMT From: dino!atanasoff!atanasoff.cs.iastate.edu!lakshmin@uunet.uu.net (Lakshminarayana Rudrabhatla) Organization: Iowa State U. Computer Science Department, Ames, IA Subject: criticism of icon Message-Id: <1489@atanasoff.cs.iastate.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu procedure main() words:=table() line_no:=0 while line:=read() do { line_no +:=1 write(left(line_no,6),left(line,40)) line:=map(line) i:=1 while j:=upto(&lcase,line,i) do { i:=many(&lcase,line,j) if *line[i:j] >= 3 then {if \words[line[i:j]] #line 14 then insert(words[line[i:j]],line_no) #line 15 else {words[line[i:j]]:=set() #line 16 insert(words[line[i:j]], line_no) #line 17 } } } } words:=sort(words) i:=0 while pair:=words[i +:=1] do { writes(left(pair[1],10),":") s:=!pair[2] pair[2]:=delete(pair[2],!pair[2]) every s ||:= ", " ||!pair[2] write(s) } end --------------------------------------------------------- question: in lines 14 thru 17 of the above program i had to implicitly declare the type of assigned value of table "words" as set(){ref: line#16} before i could perform the insert op. in line #15. this problem arose because &null would'nt coerce automatically to set(). this inspite of the claim that icon is dynamically typed. As a user, my "natural" impression was to assume that &null could represent an set() or "" or [] , as the case may be, since this facilitates easier and logical manipulation of the assigned value part of the structure "table" in general. does anyone see any problems with modifying the language to allow coercion of &null to set() or "" or [], as the case maybe depending upon the type of operation being performed on the assigned part of the structure "table". From wgg@june.cs.washington.edu Fri Sep 8 11:43:31 1989 Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA19457; Fri, 8 Sep 89 11:43:31 MST Received: by june.cs.washington.edu (5.61/7.0j) id AA19647; Fri, 8 Sep 89 11:40:09 -0700 Date: Fri, 8 Sep 89 11:40:09 -0700 From: wgg@june.cs.washington.edu (William Griswold) Return-Path: Message-Id: <8909081840.AA19647@june.cs.washington.edu> To: dino!atanasoff!atanasoff.cs.iastate.edu!lakshmin@uunet.uu.net, icon-group@arizona.edu Subject: Re: criticism of icon >Date: 8 Sep 89 16:43:55 GMT >From: dino!atanasoff!atanasoff.cs.iastate.edu!lakshmin@uunet.uu.net (Lakshminarayana Rudrabhatla) >Organization: Iowa State U. Computer Science Department, Ames, IA >Subject: criticism of icon >Sender: icon-group-request@arizona.edu >To: icon-group@arizona.edu >Errors-To: icon-group-errors@arizona.edu > > ... program ... >--------------------------------------------------------- >question: > > in lines 14 thru 17 of the above program i had to implicitly > declare the type of assigned value of table "words" > as set(){ref: line#16} before i could perform > the insert op. in line #15. > this problem arose because &null would'nt coerce automatically > to set(). this inspite of the claim that icon is dynamically typed. > As a user, my "natural" impression was to assume that &null could > represent an set() or "" or [] , as the case may be, since > this facilitates easier and logical manipulation of the > assigned value part of the structure "table" in general. > > does anyone see any problems with modifying the language to allow > coercion of &null to set() or "" or [], as the case maybe depending > upon the type of operation being performed on the assigned part of > the structure "table". > In language design there is a constant tension between flexibility and protecting the programmer from himself or herself. One of the design decisions of Icon was that if the programmer hasn't said what a value is, that it is null. If this weren't the case, every time I used an uninitialized variable (and I had intended it be initialzed with some special value, but had forgotten to do it) it would default to something else (perhaps close), and it could be very difficult to debug. I can personally testify that this feature of Icon has saved me hours of debugging time. When Icon terminates on an error ``Integer expected, offending value: null'', I know what has gone wrong. However, if my porgram terminates normally, and I find the integer result is off by 17, I don't quite know where to begin to look. This feature of Icon is especially valuable for larger programs, in which it is difficult to keep track of everything that is going on, or perhaps many people are writing code. Also, it is not entirely clear from the code you provided whether the value should be a set or table, since table has insert as well (although it wouldn't be doing anything incredibly reasonable here). In fact, you'll run into the same problem whenever you have a polymorphic operation that isn't binary symmetric. If default behavior becomes very complicated, it is better to do without. Actually, there *is* a more concise solution to your problem. Here is the code that you annotated in your previous example, and a shorter version. > then {if \words[line[i:j]] #line 14 > then insert(words[line[i:j]],line_no) #line 15 > else {words[line[i:j]]:=set() #line 16 > insert(words[line[i:j]], line_no) #line 17 > } > } then { /words[line[i:j]] := set() #line 14 insert(words[line[i:j]],line_no) #line 17 } It may not be automatic, but it is only one line longer than the solution you'd like to have. You can actually do it in one line, but it isn't pretty. Bill Griswold From naucse!sbw Fri Sep 8 12:46:40 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA22741; Fri, 8 Sep 89 12:46:40 MST Message-Id: <8909081853.AA12663@naucse> Date: Fri, 8 Sep 89 11:53:29 MST X-Mailer: Mail User's Shell (6.5 4/17/89) From: naucse!naucse!sbw (Steve Wampler) To: arizona!wgg@june.cs.washington.edu (William Griswold) Subject: Re: criticism of icon Cc: arizona!icon-group On Sep 8 at 11:42, William Griswold writes: } then { /words[line[i:j]] := set() #line 14 } insert(words[line[i:j]],line_no) #line 17 } } } } It may not be automatic, but it is only one line longer than the solution } you'd like to have. You can actually do it in one line, but it isn't } pretty. } Is too: words[line[i:j]] := insert(\words[line[i:j]]|set(), line_no) well, maybe if we do the assignment: word := line[i:j] first, then: words[word] := insert(\words[word]|set(), line_no) well, maybe if... nevermind. -- Steve Wampler {....!arizona!naucse!sbw} From icon-group-request Sun Sep 10 08:51:22 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA00773; Sun, 10 Sep 89 08:51:22 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA26355; Sun, 10 Sep 89 08:42:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 89 15:26:23 GMT From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Subject: Re: Why ICON? Message-Id: <7174@rpi.edu> References: <223000001@s.cs.uiuc.edu>, <8908271943.AA28708@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <8908271943.AA28708@megaron.arizona.edu>, kwalker@ARIZONA.EDU ("Kenneth Walker") writes: > > What is so special about it as a lanaguage > > that it merits its own notesfile? So far, most of what I've read has been > > about ICON bugs in Amiga! I would appreciate some explanation about the > > purpose of this language and whether it is at all worth learning. Why does it have its own newsgroup? Well since it is a government funded research project I think many people are interested in being able contibute ideas. It is also handy to have a newsgroup for each language. > I am on the Icon Project, so my opinions are somewhat biased. Perhaps > others of you can comment on what you find to be Icon's strengths > and weaknesses. What do you use Icon for and why? What don't you > use Icon for and why? (Perhaps I will express some of my biased > opinions after others have commented.) Why do I use Icon? Well, I use Icon because I like to experiment with neat computer languages and Icon is one, and (wow neato!) it is almost free (duplication and mailing costs only - or FTP, of course you still have to shell out $30 for the manual but a total cost of $50 for a language of this power is just spectacular. And gee, if you are interested in compiler design etc, the source plus a book describing the implementation may be had for a total cost of $80 or so. What do I program with it? Well one of my interests is writing text adventure games. A major feature of such games is a parser, it took me about 50 hours to write a decent parser in Icon, when I wrote in Pascal, it took me almost that long to write a very trivial parser. When I decided I wanted the program to word wrap its output, it took me 1 hour to write a word wrap routine. Another advantage of Icon: its extremely portable! True there are very few I/O procedures (such as graphics, cursor control {although maybe this is available on bigger systems?}, sound etc) but the bulk of the code is completely portable (well except co-expressions if your target doesn't support them). A developer who desired more fancy I/O could easily get the source code and add the procedures he needed and then for porting considerations, carefully control where these non-standard procedures are used. Since Icon is in the public domain, the modified executor could be distributed with programs. On the subject of portability I have a few questions: are executable images (.ICX) portable to all machines? how about some way to allow a standard call to included assembly language routines (or .OBJ type files from compilers)? Is this what personalized interpreters allow? If so could this feature be ported to the micro domain? how about a standard of some sort for system calls with some standardization for particular calls such as something like - syscall("movecursor",x,y) where x and y would be from 1 to n and translated as required, errors would be the result if the particular system did not support cursor addressing. along with this a variable &syscalls which listed the featured syscalls in the particular implementation (and perhaps any limits) the problem I see (with examples from the IBM-PC) is how to deal with the fact that micros will always come out with some usefull system call which does not yet have a standard name. How does that get standardized? Also how do you select between BIOS and DOS calls. BIOS calls are often faster but DOS calls are more portable, then of course one also has the choice of using ANSI codes and ANSI.SYS. Examples of some calls are the wealth of different keyboard and screen calls on the PC. Perhaps this is best left to commercial versions of the language, but I would like to see support of system calls in the general Icon langauge. Of course another problem is what do these system calls relate to in the Unix and VMS world? I guess movecursor etc would map to curses calls in Unix (I have no programming experience inm Unix, just dropping buzz words here). I also realize that system calls are of low priority to the Icon project. The Icon project is concerned with new language concepts, not how do you create a portable screen I/O system which supports more than teletype level of display control. Frank Filz From icon-group-request Sun Sep 10 20:36:25 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA00227; Sun, 10 Sep 89 20:36:25 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA28446; Sun, 10 Sep 89 20:29:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 89 03:19:09 GMT From: unsvax!arrakis.nevada.edu!doon@uunet.uu.net (Harry W. Reed) Organization: Univ of Nevada System Computing Services - Las Vegas Subject: ICON src Message-Id: <790@unsvax.NEVADA.EDU> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Hi, I am very interested in working with an ICON compiler. Is the ICON source available via ftp anywhere? or "How can I get source code for the ICON compiler?". Thanks, Harry Reed ...!arrakis!doon From goer@sophist.uchicago.edu Sun Sep 10 22:21:18 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA03312; Sun, 10 Sep 89 22:21:18 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Mon, 11 Sep 89 00:19:31 CDT Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA02630; Mon, 11 Sep 89 00:16:18 CDT Date: Mon, 11 Sep 89 00:16:18 CDT From: Richard Goerwitz Message-Id: <8909110516.AA02630@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: &null It is often extremely useful to test whether a variable has the type &null, in much the same way as one might perform boolean operations in other context with other languages. Recently a poster complained that variables of type &null could not be con- verted into other types automatically. Personally, I cannot see using Icon without &null. For instance, if a procedure that is supposed to assign a value to a variable fails, that variable will retain its previous value. In many cases, that value is null, and a simple slash can test whether this is the case or not. Rarely does the lack of any &null -> other types conversions com- plicate a program much. In the program submitted by the above- mentioned poster, it amounts to one extra line (comments are mine): procedure main() words:=table() line_no:=0 while line:=read() do { line_no +:=1 write(left(line_no,6),left(line,40)) line:=map(line) i:=1 while j:=upto(&lcase,line,i) do { i:=many(&lcase,line,j) if *line[i:j] >= 3 # # then {if \words[line[i:j]] #line 14 then insert(words[line[i:j]],line_no) #line 15 else {words[line[i:j]]:=set() #line 16 insert(words[line[i:j]], line_no) #line 17 } # Try instead: # # /words[line[i:j]] := set() # insert(words[line[i:j]],line_no) } } } words:=sort(words) i:=0 while pair:=words[i +:=1] do { writes(left(pair[1],10),":") s:=!pair[2] pair[2]:=delete(pair[2],!pair[2]) every s ||:= ", " ||!pair[2] write(s) } end I might point out that those i:j subscripting operations above are all much more elegantly handled by string scanning operations, such as: while substr := tab(many(&lcase)) do { tab(upto(&lcase)) *substr > 3 | next etc. Oh, and don't forget about sort(x,3)! -Richard L. Goerwitz goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From icon-group-request Mon Sep 11 09:06:49 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA05499; Mon, 11 Sep 89 09:06:49 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA03637; Mon, 11 Sep 89 08:54:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 89 15:40:41 GMT From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Subject: bug in Atari ST v7.5 Icon Message-Id: <7189@rpi.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I have observed whai I think is a bug in ICONX.PRG on the Atari ST. I have a 1040 so it seems that a large program with full sized regions should be able to run on top of ASH but I get memory errors. I think the bug may be that ICONX is using the region sizes (in bytes) as a parameter to a TOS allocation routine which might be using 2 or 4 byte allocation units. Other than this bug, Icon is great on the ST although it would be nice to have some support of the graphics, mouse and cursor addressing etc. Frank Filz From kwalker Mon Sep 11 09:15:35 1989 Date: Mon, 11 Sep 89 09:15:35 MST From: "Kenneth Walker" Message-Id: <8909111615.AA06027@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA06027; Mon, 11 Sep 89 09:15:35 MST In-Reply-To: <790@unsvax.NEVADA.EDU> To: icon-group Subject: Re: ICON src > Date: 11 Sep 89 03:19:09 GMT > From: unsvax!arrakis.nevada.edu!doon@uunet.uu.net (Harry W. Reed) > > I am very interested in working with an ICON compiler. > Is the ICON source available via ftp anywhere? or "How can > I get source code for the ICON compiler?". Icon source is available for a number of systems. To ftp Icon material: ftp arizona.edu log onto ftp with the name anonymous use any password cd icon look at the README file to find out what is available Note that Icon does not currently have a compiler in the sense of producing machine executable code. There is a translator and intepreter. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker From kwalker Mon Sep 11 10:11:13 1989 Date: Mon, 11 Sep 89 10:11:13 MST From: "Kenneth Walker" Message-Id: <8909111711.AA09803@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA09803; Mon, 11 Sep 89 10:11:13 MST In-Reply-To: <7174@rpi.edu> To: icon-group Subject: Re: Why ICON? > Date: 10 Sep 89 15:26:23 GMT > From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) > > On the subject of portability I have a few questions: > > are executable images (.ICX) portable to all machines? Without investigating too thoroughly, I believe there are a number of problems preventing an i-code file from being executed by the iconx intepreters on differenct machines. Numeric constants are stored in the files in binary form. Thus differnt byte ordering within integers will cause problems as will different floating point formats. There may also be problems with different data sizes between some systems. I-code files on Unix systems have an executable header which finds and invokes iconx. This header prevents these i-code files from being used on systems without them or on systems with different sized headers. There may be other portability problems, though none come to mind at the moment. > how about some way to allow a standard call to included assembly language > routines (or .OBJ type files from compilers)? Is this what personalized > interpreters allow? If so could this feature be ported to the micro domain? The assmebly language (or C or Pascal or ...) routine must be called from iconx. This means that either you need a dynamic linking facility or you must relink iconx to specifically include the routine. In addition, any time you do ``mixed language programming'', you may have to translate data from the internal format of one language to that of the other. Iconx is written in C. Becuase values in Icon include type information, even simple Icon types do not map into primative C types; structures must be used. The present method for adding a new function to Icon is to write a C routine which manipulates the structures used to implement Icon types and to tell icont/iconx about the new routine. On most systems, these C routines may call routines in written other languages. The personalized interpreter system just provides a way to compile and link a modified iconx without making a copy of the entire source. If you want the source for several modifications of Icon on one system, it will save you disk space, but does nothing else. > how about a standard of some sort for system calls with some standardization > for particular calls such as something like - > > syscall("movecursor",x,y) This sort of thing would certainly be useful, though it probably won't get done by the Icon Project. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker From wgg@june.cs.washington.edu Mon Sep 11 11:59:27 1989 Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA16681; Mon, 11 Sep 89 11:59:27 MST Received: by june.cs.washington.edu (5.61/7.0j) id AA12798; Mon, 11 Sep 89 11:56:19 -0700 Date: Mon, 11 Sep 89 11:56:19 -0700 From: wgg@june.cs.washington.edu (William Griswold) Return-Path: Message-Id: <8909111856.AA12798@june.cs.washington.edu> To: icon-group@arizona.edu, kwalker@arizona.edu Subject: Re: Why ICON? In response to Ken's last message, I would like to interject something about system calls and the like. > >Date: Mon, 11 Sep 89 10:11:13 MST >From: "Kenneth Walker" >In-Reply-To: <7174@rpi.edu> >To: icon-group@arizona.edu >Subject: Re: Why ICON? >Status: R > > >> how about a standard of some sort for system calls with some standardization >> for particular calls such as something like - >> >> syscall("movecursor",x,y) > >This sort of thing would certainly be useful, though it probably won't >get done by the Icon Project. > > Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 > +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker > There is *planned* for a later version of Icon a facility--called ``call'', I believe--that will allow making system calls and such things without extending the Icon built-in function repetoire. This is necessarily machine dependent, and I am not sure what the interface will be (integers vs. strings for system calls), or if it will even be useful unless a personalized interpreter is built to make it do something reasonable. As mentioned earlier in Ken's message, the handling of different data formats and their translation to and from Icon is non-trivial. The facility certainly won't be a panacea. Bill Griswold From dscargo@cim-vax.honeywell.com Tue Sep 12 07:09:08 1989 Message-Id: <8909121409.AA06843@megaron.arizona.edu> Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA06843; Tue, 12 Sep 89 07:09:08 MST Date: 12 Sep 89 08:29:00 CST From: "DAVE CARGO" Subject: cset comparisons To: "icon-group" I found myself doing some cset manipulations for a program and then realized that I couldn't remember what kinds of comparison operators work for csets. So I tried looking in the Icon book. Nothing seemed to be clearly indicated. At a guess csets are converted to strings for comparisons. Is that the way it works? Is it unavoidable? I wanted to see if the intersection of two csets was empty or not, e. g., if a ** b == '' then ... but then I realized that I wasn't sure if == was the right operator. (Not that I think that every type needs its own equality operator.) Can someone provide some guidance (what to use and why Icon wants it that way)? David S. Cargo DSCARGO@CIM-VAX.HONEYWELL.COM From ralph Tue Sep 12 07:38:14 1989 Date: Tue, 12 Sep 89 07:38:14 MST From: "Ralph Griswold" Message-Id: <8909121438.AA07886@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA07886; Tue, 12 Sep 89 07:38:14 MST To: dscargo@cim-vax.honeywell.com, icon-group@arizona.edu Subject: Re: cset comparisons The correct comparison operation to use is c1 === c2 provided both c1 and c2 are csets (=== does no type conversion). For csets, the bits are compared in about as fast a way as possible. If you write c1 == c2 both operands are converted to strings and then compared. Slow and it also requires storage allocation. Incidentally, to find out if a cset is empty, it's probably better to use *c1 = 0 I'm not positive about this; would have to do timings. The size of a cset is computed only when it's first needed. IF it's used the second time, it's available without additional computation. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From icon-group-request Wed Sep 13 10:56:20 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA14820; Wed, 13 Sep 89 10:56:20 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA18840; Wed, 13 Sep 89 10:51:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 17:23:35 GMT From: mfci!m3!genly@CS.YALE.EDU (Chris Hind Genly) Organization: Multiflow Computer Inc., Branford CT Subject: var params Message-Id: <1027@m3.mfci.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I've done a little bit of icon programming, and I enjoy the language. I use it under Unix, and I've started to use Icon instead of shell scripts. It's nice to switch over to a real language for quick jobs. I was wondering if anyone besides myself misses var parameters. A var parameter being a way to return a value through a parameter. Without them one is limited to returning one value. Or alternatively, multiple values would have to be packaged into a list, or some other aggregate, and then the list returned. I find this a little clumsy. Do you miss var params? Opinions and techniques welcome. -- ======================================================================= Chris Hind Genly, N1GLZ - Multiflow Computer - mfci!genly (203)488-6090 From EM302723@VMTECMEX.BITNET Wed Sep 13 15:26:03 1989 Message-Id: <8909132226.AA11881@megaron.arizona.edu> Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA11881; Wed, 13 Sep 89 15:26:03 MST Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Wed, 13 Sep 89 15:15 MST Received: by VMTECMEX (Mailer R2.03B) id 4543; Wed, 13 Sep 89 08:38:42 MEX Date: Wed, 13 Sep 89 08:36:10 MEX From: "Mario Camou R. (Dr. Mangagoras)" Subject: MS-DOS cursor control, etc? To: icon-group@arizona.edu Hi, Has anybody (working with the Icon source) implemented cursor control & graphics in Icon? How about the "Extension interpreter" that was commented a few Newsletters back? One other thing: How about distributing the Icon Newsletter via email? ------------------------------------------------------------------- This is just my humble opinion. If you like it...great. If you don't... well, who cares for your opinion, anyway? +----------------------------------+------------------------------+ | | Mario Camou Riveroll | | Dr. Mangagoras | Apdo. Postal 41554 | | EM302723@VMTECMEX.BITNET | Lomas de Chapultepec | | | Mexico, D.F. 11001 | | | | | "Don't take life too seriously | "Laugh at life, or life will | | it's just a temporary situation" | laugh at you" | +----------------------------------+------------------------------+ From icon-group-request Thu Sep 14 08:50:05 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA25805; Thu, 14 Sep 89 08:50:05 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA29691; Thu, 14 Sep 89 08:43:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 15:31:00 GMT From: swrinde!cs.utexas.edu!mailrus!uwm.edu!rpi!unix.cie.rpi.edu!vicc@ucsd.edu (VICC Project (Rose)) Subject: Re: var params Message-Id: <7319@rpi.edu> References: <1027@m3.mfci.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I too miss var parameters, unfortuanately they require a new data type (to some extent at least) to implement. I am planning on playing arround with adding some features to Icon and I would like to know what people are interested in and what people have worked on and what their experiences have been. I will be working on the ms-dos version. What I plan to play with are: Arrays - static sized multiple dimnensioned arrays, will be more space and time efficient than lists. A procedure will be used to generate an empty array. A range data type that can be converted into that needed for subscripting strings. (I'm not sure this is really needed, and I'm not sure that the current string range mechanism won't work, I have to read the implementation book. variable parameters, and maybe general pointer variables a system() function like I described earlier anyone who has comments on this please feel free to contact me. I've always wanted to hack with a compiler and Icon seems just right for that, complete source code, a manual which describes the designers philosophy behind everything etc. I wish to maintain as much of Icon's original philosophy as possible in my work. also, what are the additional documents which come with the implementation documentation package? I may need to order them, I've signed out the implementation book from my school library (they have a neat cs section, they have the Snobol implementation book also) Frank Filz From hplabs!hp-sdd!ncr-sd!ncr-fc!avery@ucbvax.Berkeley.EDU Thu Sep 14 10:34:47 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA03098; Thu, 14 Sep 89 10:34:47 MST Received: from hplabs.UUCP by ucbvax.Berkeley.EDU (5.61/1.37) id AA06407; Thu, 14 Sep 89 10:35:39 -0700 From: hplabs!hp-sdd!ncr-sd!ncr-fc!avery@ucbvax.Berkeley.EDU Received: from hp-sdd.sdd.hp.com (hp-sdd) by hplabs.HP.COM with SMTP ; Thu, 14 Sep 89 09:31:59 PST Received: by hp-sdd.sdd.hp.com; Thu, 14 Sep 89 10:31:31 pdt Received: from ncr-sd with uucp; Thu, 14 Sep 89 10:10 PDT Received: by ncr-fc.FtCollins.NCR.com on Thu, 14 Sep 89 11:09:02 MDT Date: Thu, 14 Sep 89 11:09:02 MDT Message-Id: <8909141709.AA18214@ncr-fc.FtCollins.NCR.com> To: ncr-sd!arizona.edu!icon-group Subject: Kill participation in icon group Please remove my name from icon e-mail group. Thanks.... From att!ihcup!pax Thu Sep 14 12:51:44 1989 Date: Thu, 14 Sep 89 12:51:44 MST From: att!ihcup!pax Message-Id: <8909141951.AA11958@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA11958; Thu, 14 Sep 89 12:51:44 MST To: att!arizona!icon-group From arpa!arizona.edu!icon-group-request Thu Sep 14 12:21:19 1989 Date: 14 Sep 89 15:31:00 GMT I too miss var parameters, unfortuanately they require a new data type (to some extent at least) to implement. I agree, they would be useful. I also would like to see the equivalent of argv[0] so that an Icon program could discover its name. I am planning on playing arround with adding some features to Icon and I would like to know what people are interested in and what people have worked on and what their experiences have been. I will be working on the ms-dos version. If you are going to be working with the DOS implementation, let me note that my biggest problem with it has been, without a doubt, memory management. I run Icon on several different types of UNIX machines without any difficulties but on DOS I am forever playing with [STAT,STR,HEAP]SIZE trying to get a large Icon program to just load. Once loaded, there are lots of "dead stops" that seem, somehow, to be associated with running out of some memory resource. It has been a very frustrating task to simply port a running Icon program into the DOS environment. I realize that this is caused, not by the Icon implementation, but by restrictions imposed by DOS. What I need is more help and information from Icon as to what is really going on with memory management. The DOS version needs some tools, or indicators, that monitor or report on memory usage. Where is the memory going, how much, how fast, etc. Perhaps some data could be dumped at the conclusion of every garbage collection that would help in understanding the programs' needs for memory resources. What I plan to play with are: Arrays - static sized multiple dimnensioned arrays, will be more space and time efficient than lists. A procedure will be used to generate an empty array. A range data type that can be converted into that needed for subscripting strings. (I'm not sure this is really needed, and I'm not sure that the current string range mechanism won't work, I have to read the implementation book. variable parameters, and maybe general pointer variables a system() function like I described earlier As an old SNOBOL4/SPITBOL programmer from way the hell back, I must admit that I miss in Icon the SNOBOL4/SPITBOL rather generous capabilities for tracing. I'd like to see the equivalent functionality available in Icon. The features are well documented and were very useful. anyone who has comments on this please feel free to contact me. I've always wanted to hack with a compiler and Icon seems just right for that, complete source code, a manual which describes the designers philosophy behind everything etc. I wish to maintain as much of Icon's original philosophy as possible in my work. also, what are the additional documents which come with the implementation documentation package? I may need to order them, I've signed out the implementation book from my school library (they have a neat cs section, they have the Snobol implementation book also) Frank Filz Joe T. Hall AT&T Bell Laboratories 200 Park Plaza, Room IHP 2B-524 Naperville, Illinois 60566-7050 USA att!ihcup!pax tel: +1 312 713-7285 fax: +1 312 713-7480 tlx:157294384(JTHALL) From gudeman Thu Sep 14 14:35:37 1989 Date: Thu, 14 Sep 89 14:35:37 MST From: "David Gudeman" Message-Id: <8909142135.AA18591@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA18591; Thu, 14 Sep 89 14:35:37 MST To: icon-group@arizona.edu In-Reply-To: Rose's message of 14 Sep 89 15:31:00 GMT <7319@rpi.edu> Subject: Icon additions (was: var params) [I was going to reply directly, but I had doubts about the return address. Frank, you should include a return address in your .signiture file, or maybe add a Reply-To: to your mail header.] Var params require a new _internal_ data type, but they don't really require a new user-accessible one. If you want to go all the way and add C-style pointers, you have to consider things like what operations will be allowed. For example, in C you can add an integer to a pointer to get a new pointer. There is no range check because the C philosophy puts the responsibility for such things on the programmer and because C models memory as one huge continuous array. Icon models memory as a set of independent locations with variable (changing) sizes, so if you want pointer addition, you have to come up with some reasonable Iconesque semantics. Assume that ^expr returns a pointer to the variable produced by expr. Then {ls := list(10); ptr := ls[3]} creates a list, and makes ptr a pointer into the list. Presumably, ptr + 3 returns a pointer to ls[6]. What does ptr + 9 do? It would be terribly non-Iconish for it to produce a random memory location. I can think of two possibilities: (1) pointers wrap around in a list, so ptr + 9 produces a pointer to ls[2], or (2) ptr + 9 fails, just like ls[3+9] would. Here's another consideration: what happens after you do a push(ls, x)? Does ptr still point to ls[3], or does it now point to ls[4]? All of this is relatively simple, when you add pointers to table elements things get complicated... Multiple dimensioned arrays would be useful, and I can see why you want them static-sized (to avoid the semantic complexity of APL) , but I think you are exaggerating the performance penalty of Icon's variable-sized lists. If you create a list with the list() function and never extend it, there is very little difference between access time of the list and that of a fixed-size array. In fact, I would be surprised if you could measure any performance difference by timing programs. And the list() only uses about 10 more words of memory than a fixed-size array would need. Unless you have hundreds of very small arrays, this shouldn't be a problem. From icon-group-request Thu Sep 14 20:19:50 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA05270; Thu, 14 Sep 89 20:19:50 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA10838; Thu, 14 Sep 89 20:15:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 89 02:48:58 GMT From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Subject: Re: Icon additions (was: var params) Message-Id: <7331@rpi.edu> References: <7319@rpi.edu>, <8909142135.AA18591@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <8909142135.AA18591@megaron.arizona.edu>, gudeman@ARIZONA.EDU ("David Gudeman") writes: > [I was going to reply directly, but I had doubts about the return > address. Frank, you should include a return address in your > ..signiture file, or maybe add a Reply-To: to your mail header.] I wasn't thinking about that. We have a central news server here which actually submits the articles. One of the problems is you can not cancel an article. > > Var params require a new _internal_ data type, but they don't really > require a new user-accessible one. If you want to go all the way and > add C-style pointers, you have to consider things like what operations > will be allowed. For example, in C you can add an integer to a > pointer to get a new pointer. There is no range check because the C > philosophy puts the responsibility for such things on the programmer > and because C models memory as one huge continuous array. Icon models > memory as a set of independent locations with variable (changing) > sizes, so if you want pointer addition, you have to come up with some > reasonable Iconesque semantics. If I implemented a user-accessible pointer type I would implement it in a more pascalish way. You can get a pointer to a variable, copy a pointer, or get a pointer to newly allocated space. I think anything more (such as c type operations) would stretch Icon's structure a bit too far (at least for my tastes) > > Assume that ^expr returns a pointer to the variable produced by expr. > Then {ls := list(10); ptr := ls[3]} creates a list, and makes ptr a > pointer into the list. Presumably, ptr + 3 returns a pointer to > ls[6]. What does ptr + 9 do? It would be terribly non-Iconish for it > to produce a random memory location. I can think of two > possibilities: (1) pointers wrap around in a list, so ptr + 9 produces > a pointer to ls[2], or (2) ptr + 9 fails, just like ls[3+9] would. > > Here's another consideration: what happens after you do a push(ls, x)? > Does ptr still point to ls[3], or does it now point to ls[4]? All of > this is relatively simple, when you add pointers to table elements > things get complicated... As far as I can see, it would have to now point to ls[4], it would take a lot of work to change all of the pointers that might exist to ls[3]. This of course is one place that pointers will get messy with Icon even if operations are not defined on pointers. > > Multiple dimensioned arrays would be useful, and I can see why you > want them static-sized (to avoid the semantic complexity of APL) , but > I think you are exaggerating the performance penalty of Icon's > variable-sized lists. If you create a list with the list() function > and never extend it, there is very little difference between access > time of the list and that of a fixed-size array. In fact, I would be > surprised if you could measure any performance difference by timing > programs. And the list() only uses about 10 more words of memory than > a fixed-size array would need. Unless you have hundreds of very small > arrays, this shouldn't be a problem. I see that for a single dimensioned array, but what about a multi-dimensioned array with lists, is not that a list of lists, in which case you have that extra 10 words of overhead for each sub list? Also you have the time of an extra list lookup as opposed to a multiplication. I think you are right though, now that I think about it the speed improvement probably wont be much, but I can see some space improvement by avoiding the list of lists. Of course the programmer could also do the multiplication himself. The other thing I hope to be able to do is to allow arbitrary lower bounds which will improve the readability of some types of algorithms. Another advantage of the array would be that copy would copy all the elements, not just the first dimension. Another reason to play with arrays is that I believe they will be a relatively simple implementation which should be a good practice start. Pointers on the other hand obviously have many ramifications which must be examined. One other question, is it correct that to add an operator one will have to alter ICONT? Frank Filz Center For Integrated Electronics Rensselaer Polytechnic Institute vicc@unix.cie.rpi.edu From icon-group-request Fri Sep 15 05:50:33 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA01532; Fri, 15 Sep 89 05:50:33 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA07535; Fri, 15 Sep 89 05:38:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 89 12:29:53 GMT From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Subject: Re: (none) Message-Id: <7341@rpi.edu> References: <8909141951.AA11958@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <8909141951.AA11958@megaron.arizona.edu>, pax@ihcup.UUCP writes: > I also would like to see the equivalent of > argv[0] so that an Icon program could discover its name. Should be relatively easy actually since ICONX needs to know the name. Have to think about the syntax though. I don't recall off hand the syntax/ strategy for parameters and this is not something to break existing programs over. > If you are going to be working with the DOS implementation, let me note that my > biggest problem with it has been, without a doubt, memory management. I run > Icon on several different types of UNIX machines without any difficulties but > on DOS I am forever playing with [STAT,STR,HEAP]SIZE trying to get a large > Icon program to just load. Once loaded, there are lots of "dead stops" that > seem, somehow, to be associated with running out of some memory resource. > It has been a very frustrating task to simply port a running Icon program > into the DOS environment. I realize that this is caused, not by the Icon > implementation, but by restrictions imposed by DOS. What I need is more help > and information from Icon as to what is really going on with memory management. > The DOS version needs some tools, or indicators, that monitor or report on > memory usage. Where is the memory going, how much, how fast, etc. Perhaps > some data could be dumped at the conclusion of every garbage collection that > would help in understanding the programs' needs for memory resources. From my understanding, Icon requires almost 640k of memory (including system etc., one note is to be carefull of how many TSRs you have loaded. Thus, since a full sized program/memory space won't fit, you have to jiggle for each. Note the new & variables in V7.5 for allocation and garbage collection tracing. They may help your situation some what. How long did you wait for after the dead stop? I'm not sure how Icon's garbage collection compares with others but I remember one LISP interpreter warning that garbage collections could take several minutes. If you are using 90% of a region and the items are small objects, garbage collection could take a while. If that is not the case, perhaps you have discovered a bug when the ammount of space left is really small. I will leave further comments to other more experienced people. >As an old SNOBOL4/SPITBOL programmer from way the hell back, I must admit that > I miss in Icon the SNOBOL4/SPITBOL rather generous capabilities for tracing. > I'd like to see the equivalent functionality available in Icon. The features > are well documented and were very useful. I doubt that I will do much in that line. That could be a major problem actually. If anything, I was thinking of producing a more production model without the tracing. A question there would be how much run time memory allocation and time would actually be saved? If it would only be a few percent I see no reason to do it. This would be set up as a complementary ICONX if done, the tracing is still needed for development purposes. Frank Filz Frank Filz Center For Integrated Electronics Rensselaer Polytechnic Institute vicc@unix.cie.rpi.edu From dscargo@cim-vax.honeywell.com Fri Sep 15 06:57:35 1989 Message-Id: <8909151357.AA03203@megaron.arizona.edu> Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA03203; Fri, 15 Sep 89 06:57:35 MST Date: 15 Sep 89 08:43:00 CST From: "DAVE CARGO" Subject: Icon additions To: "icon-group" There are three things of various levels of complexity that I'd like to see added to Icon. 1) A bit-string type similar in underlying mechanisms to csets. (In other words a 256-bit limit is probably acceptable. The same operations available on csets should be provided. Conversions should be available between bit strings and strings, and possibly between bit strings and csets. I don't see any good way of representing bit string constants. Translating them to strings could be done in a combination of ways: to a string of binary, octal, or hex digits, and padded to full length or truncated (on the left or right) if the remainder is zero filled. I'm inclined to use Icon for some graphics applications and true bit-strings would be very helpful. 2) Formatted translation from bytestrings to integers. Given a specification about width and byte order, translate a string of bytes into a list of integers. Useful for cracking some arbitrary file internal formats (like TIFF and PCX). 3) POSIX compatibility. In particular, if there are screen and keyboard interfaces specified (or drafted), make them accessible to Icon so that portable user interfaces for applications can be developed. In the MS-DOS world alone, support for ANSI or lower-level access to video memory might be nice. dsc From icon-group-request Fri Sep 15 09:06:31 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA09825; Fri, 15 Sep 89 09:06:31 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA17623; Fri, 15 Sep 89 08:55:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 89 15:34:48 GMT From: cs.utexas.edu!uwm.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Subject: Re: Icon additions Message-Id: <7346@rpi.edu> References: <8909151357.AA03203@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <8909151357.AA03203@megaron.arizona.edu>, dscargo@CIM-VAX.HONEYWELL.COM ("DAVE CARGO") writes: > There are three things of various levels of complexity that I'd like to see > added to Icon. > 1) A bit-string type similar in underlying mechanisms to csets. (In other > words a 256-bit limit is probably acceptable. The same operations available This woud seem easy to do, perhaps without the need for a new data type. A few functions would go a long way. > 2) Formatted translation from bytestrings to integers. Given a specification > about width and byte order, translate a string of bytes into a list of > integers. Useful for cracking some arbitrary file internal formats (like > TIFF and PCX). Well there is ord and char, but yes, a few additional functions would be nice. > 3) POSIX compatibility. In particular, if there are screen and keyboard > interfaces specified (or drafted), make them accessible to Icon so that > portable user interfaces for applications can be developed. In the MS-DOS > world alone, support for ANSI or lower-level access to video memory might > be nice. I have some ideas on this that I mentioned a few posts back. Basically the idea would be to implement a function which has a string parameter specifying the function call, and a variable number of parameters to be passed. The reason I would have a single Icon function, is primarily to avoid generating too many function names. Also searches for use of these I/O routines would be easy since you would look for 1 function, not 30 or more. A system variable such as &sysfuncs or so would be a generator like &features. There would be a single addition to &features list. On MS-DOS I would map these to DOS and BIOS calls. ANSI calls might be nice but I think most MS-DOS users these days are PC BIOS compatible. (If I am wrong let me know) The big problem will be in assigning a reasonably standard list of I/O call names. Frank Filz Center For Integrated Electronics Rensselaer Polytechnic Institute vicc@unix.cie.rpi.edu From dscargo@cim-vax.honeywell.com Fri Sep 15 13:14:37 1989 Message-Id: <8909152014.AA25425@megaron.arizona.edu> Received: from CIM-VAX.HONEYWELL.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA25425; Fri, 15 Sep 89 13:14:37 MST Date: 15 Sep 89 14:59:00 CST From: "DAVE CARGO" Subject: string range replacement confusion To: "icon-group" #The following fragment represents part of a program that scans #a file of user names and writes out lines that match, uppercasing #the part of the line that matched. Three methods are used to assign #capital letters to the output string. One uppercases the pattern and #assigns it to the part of the line that matched. Two other methods #copy characters from an uppercased copy of the line. So far #as I can determine, all three methods should work the same. #They don't. I'm using Icon 7.0 for VMS. I'm trying to determine #if methods 2 and 3(represented by the write(pline2) and write(pline3)) #are correct but somehow failing to produce the correct results, or if I'm #misunderstanding how some of this Icon is supposed to work. global sstr procedure main() sstr := "cargo" line := "cargo, dave cargo" write(line) #added for testing print_line(line,"skyler") end procedure print_line(line, nodename) # three copies for the three different methods pline1 := copy(line) pline2 := copy(line) pline3 := copy(line) lower := map(sstr) # this is the desired replacement text upper := map(sstr, &lcase, &ucase) # this is an altermate source for the replacement text uline := map(line, &lcase, &ucase) # the size of the search string starsstr := *sstr # finding all instances of the search string every i := find(lower, line) do { # I think these assignments should replace the same # characters in the same places. # method 1 explicitly calculates the ranges j := i + *sstr pline1[i:j] := uline[i:j] # method 2 uses the same ranges pline2[i:+starsstr] := uline[i:+starsstr] # method three only uses one range, but should have the same text pline3[i:+starsstr] := upper } write(pline1) write(pline2) write(pline3) return end # minus the pound signs, this is what comes out # (from a screen capture) #cargo, dave cargo #CARGO, dave CARGO #CARGO, DAVE cargo #CARGCARGO cargo From goer@sophist.uchicago.edu Fri Sep 15 18:56:44 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA13518; Fri, 15 Sep 89 18:56:44 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Fri, 15 Sep 89 19:49:21 CDT Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA08151; Fri, 15 Sep 89 19:45:56 CDT Date: Fri, 15 Sep 89 19:45:56 CDT From: Richard Goerwitz Message-Id: <8909160045.AA08151@sophist.uchicago.edu> To: icon-group@arizona.edu The problem with the uppercasing procedure just submitted by Dave Cargo boils down to a slight error in subscripting no- tation. The plus sign needs to go before the colon; otherwise it is interpreted as a prefix operator creating a positive in- teger (that integer here being starsstr). pline2[i:+starsstr] := uline[i:+starsstr] #### the correct way of saying this is str[i+:j] #### pline3[i:+starsstr] := upper #### ditto #### This i:j stuff, though, is very un-iconish. But then I'm biased. String scanning can get to be a kind of religion: procedure main() sstr := "cargo" line := "cargo, dave cargo" write(capline(sstr,line)) end procedure capline(word,line) line2 := "" line ? { while line2 ||:= tab(find(word)) do line2 ||:= map(=word,&lcase,&ucase) line2 ||:= tab(0) } return line2 end From att!ihcup!pax Mon Sep 18 06:59:42 1989 Date: Mon, 18 Sep 89 06:59:42 MST From: att!ihcup!pax Message-Id: <8909181359.AA18860@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA18860; Mon, 18 Sep 89 06:59:42 MST To: att!arizona!icon-group Ralph, Cheyenne, I know that you are not really very interested in the 640K DOS situation with Icon. But, I have customers running Icon programs that I've written for them and they sure don't want to trash their existing 640K machines - at least not right now. Any help at all you can give me on memory management will be most appreciated. Especially some words specifically on how to best trim the size of tables and lists as the items are no longer needed. Also, I believe I can recreate dependably a problem with the system() function in DOS Icon. Depending upon how large the program is, system() may or may not do anything. No error or failure return - it's just as if the call was skipped. I have a large program that is made by combining the .U files of six, translated with -c, subprograms. When they are all put together the system() function disappears. I can leave off most any of them and system() works again. Is it possible that some DOS system buffer is getting clobbered by a very large icon executable? I put a simple DOS comand: system("copy a b") stop() at the very beginning of my large program and then tried all kinds of combinations of .U's with it. Leaving off just one of the subprograms seems to be enough to clear up the problem. When it works, I get the normal DOS standard output: 1 File(s) copied and the file is copied. When it fails, I get NOTHING on standard out from the DOS command and there is no copy made. Can you offer any assistance? jth From dscargo@cim-vax.honeywell.com Wed Sep 20 09:14:41 1989 Message-Id: <8909201614.AA16660@megaron.arizona.edu> Received: from cim-vax.Honeywell.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA16660; Wed, 20 Sep 89 09:14:41 MST Date: 20 Sep 89 11:01:00 CST From: "DAVE CARGO" Subject: string scanning vs. assignment To: "icon-group" Richard Goerwitz corrected my problem with the Icon syntax and proposed his solution to the capitalization problem. I tried it and it worked, but I got currious about performance. When I timed his solution with a corrected varient of one of mine,I discovered that the string scanning approach takes more time (about half again more as revealed by timing tests on Icon 7.0 for VMS. Richard's solution: procedure capline(word, line) line2 := "" line ? { while line2 ||:= tab(find(word)) do line2 ||:= map(=word,&lcase,&ucase) line2 ||:= tab(0) } return line2 end my corrected and modified solution: procedure capline(word, line) line2 := copy(line) every line2[find(word, line)+:*word] := map(word, &lcase, &ucase) return line2 end I think my solution is faster because it creates fewer tempory variables and does fewer operations. From att!ihlpb!nevin1 Wed Sep 20 16:35:44 1989 Date: Wed, 20 Sep 89 16:35:44 MST Message-Id: <8909202335.AA19395@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA19395; Wed, 20 Sep 89 16:35:44 MST From: ihlpb!nevin1 (Nevin J Liber +1 312 979 4751) To: att!arizona!icon-group Subject: Re: Icon additions >If I implemented a user-accessible pointer type I would implement it in a more >pascalish way. You can get a pointer to a variable, copy a pointer, or get >a pointer to newly allocated space. My question to you is: what do you wish to be able to do with pointers in Icon? Pointers are needed in languages like Pascal, C, etc. to implement entities such as linked lists and hash tables. But these are already built into Icon! Also, trying to implement user-accessible pointers in conjunction with garbage collection is far from trivial. I just can't see what new types of *implementation-independent* (I know that there basically only one implementation of Icon right now, but language design should not be restricted to one implementation) applications that I cannot now write in Icon solely because I don't have pointers. What power would pointers give me? >The other thing I hope to be able to do is to allow arbitrary lower bounds >[on arrays,] which will improve the readability of some types of algorithms. IMHO, this would not be very Icon-ish. First off, negative indices already are defined in Icon; they allow you to work from the end of a string, list, etc. instead of the beginning; with arbituary lower bounds on arrays, this wouldn't work (there are ways to kludge it in, but code that would take advantage of it would look very messy). Secondly: for the current data types, to generate over them in reverse order the construct "every element := dataType[*dataType to 1 by -1]" works; this would not hold true for non-0 lower-bounded arrays. Thirdly: how does one pass an array to a procedure? A procedure would need some way of determining the lower bound of an array passed to it (unless you want to write different procedures for each differently bounded array as in standard Pascal -- blecch!). Or do you plan on converting all passed arrays into lists, in which case adding an array type doesn't gain you very much at all. NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751 From icon-group-request Thu Sep 21 05:21:59 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA21724; Thu, 21 Sep 89 05:21:59 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA16934; Thu, 21 Sep 89 05:18:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 89 12:10:32 GMT From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Organization: Rensselaer Polytechnic Institute, Troy NY Subject: Re: Icon additions Message-Id: <1989Sep21.121032.14168@rpi.edu> References: <8909202335.AA19395@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <8909202335.AA19395@megaron.arizona.edu>, nevin1@ihlpb.UUCP (Nevin J Liber +1 312 979 4751) writes: > >If I implemented a user-accessible pointer type I would implement it in a more > >pascalish way. You can get a pointer to a variable, copy a pointer, or get > >a pointer to newly allocated space. > > My question to you is: what do you wish to be able to do with > pointers in Icon? Pointers are needed in languages like Pascal, C, > etc. to implement entities such as linked lists and hash tables. But > these are already built into Icon! Pointers could also be used to access non-Icon memory. This would obviously be machine and os dependant, but I think is necessary for any language on a personal computer. The most successeful pc programs are those which directly use the machines resources. They may or may not do so in a structured way. I will agree that this reason for pointers is a VERY touchy subject. Pointers are also usefull for constructing (more efficiently perhaps, or more intuitively) tree structures which might have multiple pointers in each record (and might have data in each record also). > Also, trying to implement > user-accessible pointers in conjunction with garbage collection is far >from trivial. The pointers I would implement would be required always to point to a structure. This would simplify garbage collection in that there would be a block (pointed to by a variable = accessible to garbage collector) which contains a pointer to a block and the type of that block. I understand that setting things up for the garbage collector is most important. > I just can't see what new types of *implementation-independent* > (I know that there basically only one implementation of Icon right now, > but language design should not be restricted to one implementation) > applications that I cannot now write in Icon solely because I don't have > pointers. What power would pointers give me? Pointers are one way to implement pass by reference parameters. Basically, I see an internal pointer type comming out to implement pass by reference parameters without changing syntax in a way which would break existing programs (a very important consideration in any change to Icon). Once these pointers exist, it would be easy to make that pointer structure available to the programmer. > >The other thing I hope to be able to do is to allow arbitrary lower bounds > >[on arrays,] which will improve the readability of some types of algorithms. > > IMHO, this would not be very Icon-ish. First off, negative indices > already are defined in Icon; they allow you to work from the end > of a string, list, etc. instead of the beginning; with arbituary > lower bounds on arrays, this wouldn't work (there are ways to kludge it > in, but code that would take advantage of it would look very messy). I don't see how this would be non-Iconish, also note that the suggested project in the Icon implementation book mentioned lower bounds other than 1. Tables do not follow this indexing. I see arrays as allowing more efficient means of storing data which most logically should be organized in a multi-dimensioned manner by scalar indices. Sparse arrays should be implemented with tables. > Secondly: for the current data types, to generate over them in reverse > order the construct "every element := dataType[*dataType to 1 by -1]" works; > this would not hold true for non-0 lower-bounded arrays. Not for tables. (note also that the "Iconish" way would be a lower bound of 1 not 0 :-) > Thirdly: how does one pass an array to a procedure? A procedure would > need some way of determining the lower bound of an array passed to it The array block will contain the ranges for each dimension. I think image() would be one way to retrieve these. A record type access to them might also work. At the worst case, an internal function may be used. Other than that, arrays will be passed like all other structures (ie effectively a pointer is passed) One other item I was thinking of to go with arrays is a range data type with a constuctor like .. (ie A[1..3]). This could allow reverse order specification (which could even be used by the interpreter). I see that this range data type would be converted to a subrange (1:3) if used anywheres where a subrange is allowed (lists and strings). A[1..3] might construct a list even. Frank Filz Center For Integrated Electronics Rensselaer Polytechnic Institute vicc@unix.cie.rpi.edu From kwalker Thu Sep 21 10:11:26 1989 Date: Thu, 21 Sep 89 10:11:26 MST From: "Kenneth Walker" Message-Id: <8909211711.AA08091@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA08091; Thu, 21 Sep 89 10:11:26 MST In-Reply-To: <1989Sep21.121032.14168@rpi.edu> To: icon-group Subject: Re: Icon additions > Date: 21 Sep 89 12:10:32 GMT > From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) > > Pointers could also be used to access non-Icon memory. This would obviously > be machine and os dependant, but I think is necessary for any language > on a personal computer. The word "necessary" is too strong. It is true that the feature significantly extends the application domain of the language, though. > Pointers are also usefull for constructing (more efficiently perhaps, or > more intuitively) tree structures which might have multiple pointers > in each record (and might have data in each record also). The pointers are already there in the pointer semantics of Icon data structures. Your suggestion would just make them explicit. It seems to me that using them will necessarily make the code to construct trees more verbose, without adding any power. I am confused as to what your pointers would be allowed to point to. You make 3 seemingly conflicting statements: 1) > Pointers could also be used to access non-Icon memory. 2) > The pointers I would implement would be required always to point to a > structure. 3) > Pointers are one way to implement pass by reference parameters. Number 1 could be an "unsafe" pointer type. That is, the programmer would be responsible for avoiding any kind of memory violation. This is somewhat un-Iconish, but one makes compromises in language design. You will probably have to avoid pointing into an Icon structure, because garbage collection won't know how to relocate the pointer (at least not without changes to the garbage collector). Number 2 is no problem; it corresponds to the current pointer semantics of Icon data structures. Number 3 requires pointers to variables. While this is no problem for the garbage collector, there is a problem of dangling pointers to local variables that no longer exist (this is not a problem if you only use the pointers for pass-by-reference). Ignoring the problem would be very un-Iconish! One solution is to allocate local variables in the heap so they don't go away while something is pointing to them. For programs that do a lot of procedure calls, this can significantly increase the number of garbage collections. An other approach would be to keep track of pointers to local variables and change them to the null value when the procedure terminates. This would also be expensive. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker From naucse!sbw Thu Sep 21 11:36:27 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA14503; Thu, 21 Sep 89 11:36:27 MST Message-Id: <8909211737.AA26397@naucse> Date: Thu, 21 Sep 89 10:37:37 MST X-Mailer: Mail User's Shell (6.5 4/17/89) From: naucse!naucse!sbw (Steve Wampler) To: arizona!gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)), arizona!icon-group Subject: Re: Icon additions On Sep 21 at 6:33, VICC Project (Rose) writes: } } } Pointers could also be used to access non-Icon memory. This would obviously } be machine and os dependant, but I think is necessary for any language } on a personal computer. The most successeful pc programs are those which } directly use the machines resources. They may or may not do so in a } structured way. I will agree that this reason for pointers is a VERY } touchy subject. I can see this use, though perhaps there is some other way. } Pointers are also usefull for constructing (more efficiently perhaps, or } more intuitively) tree structures which might have multiple pointers } in each record (and might have data in each record also). I guess I don't see this one. That's already easy to do. Perhaps it's more intuitive to one who things in pointers, but you're really using pointers to represent hierarchies. } The pointers I would implement would be required always to point to a } structure. This would simplify garbage collection in that there would be } a block (pointed to by a variable = accessible to garbage collector) which } contains a pointer to a block and the type of that block. I understand that } setting things up for the garbage collector is most important. If you do this, then... } Pointers are one way to implement pass by reference parameters. Basically, I you're being redundant. Given your constraint above, you already have it in Icon. Try the following program: procedure main() local a call(a := []) every write(!a) end procedure call(x) every put(x,1 to 10) end You must mean to have internal pointers as being different than pointers at the source level? Pointers are not the only way to do this, though they are perhaps the simplest to implement. I do see a lot of redundancy showing up, however, given that structures provide pointer 'functionality' already. It only seems a gain in having pass by reference to simple data types. A more 'Icon-ish' solution would be to extend the co-expression mechanism to do it for you - i.e. have co-expressions exist in the environment of their creation, rather than in a copy of that environment (providing a scheme for isolating the environment if needed). That gives you more flexibility than simple pointers. Of course, it also requires some substantial (and potentially costly) changes to the implementation. -- Steve Wampler {....!arizona!naucse!sbw} From icon-group-request Thu Sep 21 12:23:10 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA16898; Thu, 21 Sep 89 12:23:10 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA08802; Thu, 21 Sep 89 12:06:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 89 18:56:07 GMT From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Organization: Rensselaer Polytechnic Institute, Troy NY Subject: Re: Icon additions Message-Id: <1989Sep21.185607.2120@rpi.edu> References: <1989Sep21.121032.14168@rpi.edu>, <8909211711.AA08091@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <8909211711.AA08091@megaron.arizona.edu>, kwalker@ARIZONA.EDU ("Kenneth Walker") writes: > > Date: 21 Sep 89 12:10:32 GMT > > From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) > > > > Pointers could also be used to access non-Icon memory. This would obviously > > be machine and os dependant, but I think is necessary for any language > > on a personal computer. > > The word "necessary" is too strong. It is true that the feature > significantly extends the application domain of the language, though. Ok, I was too strong here. > > Pointers are also usefull for constructing (more efficiently perhaps, or > > more intuitively) tree structures which might have multiple pointers > > in each record (and might have data in each record also). > > The pointers are already there in the pointer semantics of Icon data > structures. Your suggestion would just make them explicit. It seems > to me that using them will necessarily make the code to construct > trees more verbose, without adding any power. > > I am confused as to what your pointers would be allowed to point to. > You make 3 seemingly conflicting statements: > > 1) > Pointers could also be used to access non-Icon memory. > > 2) > The pointers I would implement would be required always to point to a > > structure. > > 3) > Pointers are one way to implement pass by reference parameters. > > Number 1 could be an "unsafe" pointer type. That is, the programmer > would be responsible for avoiding any kind of memory violation. This > is somewhat un-Iconish, but one makes compromises in language design. > You will probably have to avoid pointing into an Icon structure, because > garbage collection won't know how to relocate the pointer (at least > not without changes to the garbage collector). I agree absolutely, I should have clarified things a bit. I think two types of user pointers are implicated. One should only point to non-Icon memory and the other for pointing to Icon structures (and this type might also include some type information). One possibility is that if all the uses of a non-Icon pointer are easy to enumerate (including possible calls to malloc for non-Icon memory on the heap) Then one could set up a more bomb proof pointer structure. > Number 2 is no problem; it corresponds to the current pointer semantics > of Icon data structures. My intention is to follow Icon as closely as possible here to ease the work of the garbage collector. > Number 3 requires pointers to variables. While this is no problem > for the garbage collector, there is a problem of dangling pointers > to local variables that no longer exist (this is not a problem if you > only use the pointers for pass-by-reference). Ignoring the problem > would be very un-Iconish! One solution is to allocate local variables > in the heap so they don't go away while something is pointing to them. > For programs that do a lot of procedure calls, this can significantly > increase the number of garbage collections. An other approach would > be to keep track of pointers to local variables and change them > to the null value when the procedure terminates. This would also > be expensive. This is one I didn't think about too much. Of course this is one advantage of airing ones ideas in such a forum (of course when I sat down to actually do the implementation I hope I would have seen this). Here is an idea that might work: When a pointer to a local variable (static variables are fine) is generated, we move the variable into the heap and replace the local variable with a construct similar to a trapped variable. Thus if the pointer is left hanging, the pointer is actually pointing to something in the heap which is then accesible to the garbage collector and remains after the procedure returns. I think this would provide protection without too much heap overhead. If the use of a pointer to a local variable was intentional, and the procedure was not re-entrant (recursive or otherwise), then a static variable could be used to avoid the heap allocation. One advantage that I do see to Icon pointers is that with care, you can never end up with a dangling pointer. In Pascal or C it is easy to allocate memory for a structure, set a pointer to it, copy that pointer, release the memory and still have a pointer to the memory. In Icon, to deallocate memory pointed to by a pointer, all we need do is set the variable to &null (or any non-pointer variable). If all pointers to a structure are removed in this way, the garbage collector will free the memory when called. One thing in reference to non-Icon pointers is that I think most of the time one would need them (other than for I/O type activities which can easily be implemented in Icon so that pointers are not needed for them) is that Icon can allocate the memory and then when the pointer need be passed to some C or assembly function, the pointer can just be adjusted to point to the space in the block. If a block is needed which can't be moved, one could use malloc or modify the garbage collector in some way. Frank Filz Center For Integrated Electronics Rensselaer Polytechnic Institute vicc@unix.cie.rpi.edu From vicc@unix.cie.rpi.edu Thu Sep 21 12:34:01 1989 Received: from rpi.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA18009; Thu, 21 Sep 89 12:34:01 MST Received: from unix.cie.rpi.edu by rpi.edu (4.0/SM35-RPI-ITS); id AA02426; Thu, 21 Sep 89 15:03:52 EDT for arizona!icon-group@arizona.edu Date: Thu, 21 Sep 89 15:05:22 EDT From: vicc@unix.cie.rpi.edu (VICC Project (Rose)) Received: by unix.cie.rpi.edu (5.51/1.2-RPI-CIE) id AA19693; Thu, 21 Sep 89 15:05:22 EDT Message-Id: <8909211905.AA19693@unix.cie.rpi.edu> To: icon-group@arizona.edu, naucse!naucse!sbw@arizona.edu, vicc@unix.cie.rpi.edu Subject: Re: Icon additions I have often wanted to be able to refer to a variable containing a simple type. Also, being able to pass a simple type by reference is more efficient than constucting a list with that element and passing the list (although admittedly to a small ammount). Frank Filz From icon-group-request Thu Sep 21 12:36:07 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA18127; Thu, 21 Sep 89 12:36:07 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA10421; Thu, 21 Sep 89 12:34:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 89 17:15:33 GMT From: dasys1!aj-mberg@nyu.edu (Micha Berger) Organization: AishDas Society: 73-32 173 St, Hillcrest NY 11366 (718)380-7572 Subject: Re: var params Message-Id: <10746@dasys1.UUCP> References: <1027@m3.mfci.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu "var" params, as you call it, is normally called "passing by reference. What this means is that you're passing the variable, not the value it holds. "var" is just the keyword Pascal uses, it's not the standard term. (The type of passing ICON allows is "pass-by-value"; i.e. only the value is passed.) Now, back to your question.... Passing by reference is considered by most language feature as dangerous. It allows a function to change the value of a variable without the user realizing. If you came back to your program years later, will you remember all the side effects? The problem is that you can end up with p(a)+a <> a+p(a). If p's parameter is passed by reference, and p changes the value of a, it makes a difference which gets done first. If you want to return a bunch of values from one function, why not return a list? -- Micha Berger ...cucard!dasys1!aj-mberg Imitatio Dei means never having to say "I'm sorry." From icon-group-request Fri Sep 22 05:05:33 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA02746; Fri, 22 Sep 89 05:05:33 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA02509; Fri, 22 Sep 89 05:06:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 89 12:00:00 GMT From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Organization: Rensselaer Polytechnic Institute, Troy NY Subject: Re: var params Message-Id: <1989Sep22.120000.13561@rpi.edu> References: <1027@m3.mfci.UUCP>, <10746@dasys1.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <10746@dasys1.UUCP>, aj-mberg@dasys1.UUCP (Micha Berger) writes: > Passing by reference is considered by most language feature as dangerous. It > allows a function to change the value of a variable without the user > realizing. If you came back to your program years later, will you remember > all the side effects? One must program ones procedures which use pass by reference such that side effects will be obvious. > The problem is that you can end up with p(a)+a <> a+p(a). If p's > parameter is passed by reference, and p changes the value of a, > it makes a difference which gets done first. One of my personal styles is to avoid using a procedure which returns a value (other than some kind of return code) in combination with pass by reference parameters. The result is that the construct p(a) + a should not occur. > If you want to return a bunch of values from one function, why not return a > list? This might in general be fine, but there have been comments about the int86() function for MS-DOS Icon which returns a list. It is a little slower because of this, also in certain programs (which are probably using int86() to speed things up) there is heavy use of int86() which then causes needless garbage collections. Of course in this instance one doesn't need special pass by reference since Icon structures are always passed by reference. Frank Filz Center For Integrated Electronics Rensselaer Polytechnic Institute vicc@unix.cie.rpi.edu From icon-group-request Fri Sep 22 08:22:26 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA09550; Fri, 22 Sep 89 08:22:26 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA12087; Fri, 22 Sep 89 08:15:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 89 15:06:38 GMT From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu (VICC Project (Rose)) Organization: Rensselaer Polytechnic Institute, Troy NY Subject: Re: (none) Message-Id: <1989Sep22.150638.21014@rpi.edu> References: <8909181359.AA18860@megaron.arizona.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I tried e-mail on this and it bounced so... In article <8909181359.AA18860@megaron.arizona.edu>, pax@ihcup.UUCP writes: > Ralph, Cheyenne, > > I know that you are not really very interested in the 640K DOS > situation with Icon. But, I have customers running Icon programs > that I've written for them and they sure don't want to trash their > existing 640K machines - at least not right now. > > Any help at all you can give me on memory management will be most > appreciated. Especially some words specifically on how to best > trim the size of tables and lists as the items are no longer needed. Garbage collection should take care of most of this, also If I remember correctly you can delete from a table. pop, pull or get from a list to dispose of extra entries. > Also, I believe I can recreate dependably a problem with the > system() function in DOS Icon. Depending upon how large the > program is, system() may or may not do anything. No error > or failure return - it's just as if the call was skipped. You may have run out of memory to load COMMAND.COM. It does seem odd however that there is no failure event or value returned to indicate this failure. To resolve the memory problem try the following: 1. Trim your program 2. set the STRSIZE and BLOCKSIZE environment variables so that less than 65k is allocated for these regions 3. trim out TSRs like sidekick Frank Filz Center For Integrated Electronics Rensselaer Polytechnic Institute vicc@unix.cie.rpi.edu From goer@sophist.uchicago.edu Sun Sep 24 11:11:19 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA24862; Sun, 24 Sep 89 11:11:19 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Sun, 24 Sep 89 13:13:20 CDT Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA17945; Sun, 24 Sep 89 13:09:33 CDT Date: Sun, 24 Sep 89 13:09:33 CDT From: Richard Goerwitz Message-Id: <8909241809.AA17945@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: removing one or more elements from a list Having written some slow and inelegant code, I am left wondering whether anyone has evolved other solutions to the problem of how to remove a specific element from a list. Basically, what I need to do is be able to remove a range of members from a given list - removerange(lst,firstone,secondone) # returns lst[1:firstone] ||| lst[secondone+1:0] # unless firstone = 1 in which case, it returns # lst[secondone + 1:0] # same sort of thing when secondone = *lst end Kinda cluttered-looking, when written out in full. I tried a recur- sive procedure where one element is removed for each element from firstone to secondone. That way I really needed only one procedure to remove a single element, and one every loop. But this was slow. Anyone have any ideas? -Richard L. Goerwitz goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From icon-group-request Sun Sep 24 21:07:53 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA14922; Sun, 24 Sep 89 21:07:53 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA08040; Sun, 24 Sep 89 21:09:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Sep 89 10:52:23 GMT From: uhccux!munnari.oz.au!cs.mu.oz.au!ok@ames.arc.nasa.gov (Richard O'Keefe) Subject: Re: var params Message-Id: <2174@munnari.oz.au> References: <1027@m3.mfci.UUCP>, <10746@dasys1.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu [I've lost the original context] In article <10746@dasys1.UUCP>, aj-mberg@dasys1.UUCP (Micha Berger) writes: > "var" params, as you call it, is normally called "passing by reference. If you will be content with pass by value result (as Fortran and Ada are), you can get that effect just by bending the Icon translator. Suppose, for example, that you add Ada syntax for arguments: 'in' value passed in 'out' result passed back 'in out' value passed in and result passed back. A procedure definition like procedure foo(in x, out y, in out z) ... end could be translated as procedure foo(x, OUTARGS) use OUTARGS[1] wherever y appears use OUTARGS[2] wherever z appears end A call foo(eks, out wye, in out zed) would then be translated as temp := [&null, zed]; foo(eks, temp); wye := temp[1], zed := temp[2] This gets a wee bit tricky if wye and zed are expressions, but Icon already has the machinery to represent "references" so that procedure calls can be used on the left hand side of := . This looks as though it should work, and it seems like a better idea to just bend the translator than to hack the low level stuff -- more portable if you do it right. And you'll have to bend the translator anyway. From EM302723@VMTECMEX.BITNET Mon Sep 25 07:09:55 1989 Message-Id: <8909251409.AA13884@megaron.arizona.edu> Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA13884; Mon, 25 Sep 89 07:09:55 MST Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Mon, 25 Sep 89 07:11 MST Received: by VMTECMEX (Mailer R2.03B) id 3045; Mon, 25 Sep 89 07:59:28 MEX Date: Mon, 25 Sep 89 07:57:34 MEX From: "Mario Camou R. (Dr. Mangagoras)" Subject: Re: cursor control on PC To: icon-group@arizona.edu My fault. I was too unspecific on my last posting. What I'm interested in is in an implementation (personalized interpreter?) of Icon which uses some kind of WINDOWING library (curses-like, or something similar). Has anybody worked on that? +----------------------------------+------------------------------+ | | Mario Camou Riveroll | | Dr. Mangagoras | Apdo. Postal 41554 | | EM302723@VMTECMEX.BITNET | Lomas de Chapultepec | | | Mexico, D.F. 11001 | | | | | "Don't take life too seriously | "Laugh at life, or life will | | it's just a temporary situation" | laugh at you" | +----------------------------------+------------------------------+ From goer@sophist.uchicago.edu Tue Sep 26 10:59:39 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA00814; Tue, 26 Sep 89 10:59:39 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Tue, 26 Sep 89 12:15:00 CDT Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA21032; Tue, 26 Sep 89 12:11:08 CDT Date: Tue, 26 Sep 89 12:11:08 CDT From: Richard Goerwitz Message-Id: <8909261711.AA21032@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: tables, efficiency Could someone familiar with the implementation of tables explain how efficient use can be made of storage when the ultimate size of the table is unknown? Or does the interpreter indeed check to see how big the various regions are, and adjust the algorithm to make maximum use of a given memory space? Just dunno, but would like t'know. -Richard L. Goerwitz goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer From wgg@june.cs.washington.edu Tue Sep 26 14:13:47 1989 Received: from june.cs.washington.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA15616; Tue, 26 Sep 89 14:13:47 MST Received: by june.cs.washington.edu (5.61/7.0j) id AA07260; Tue, 26 Sep 89 14:13:49 -0700 Date: Tue, 26 Sep 89 14:13:49 -0700 From: wgg@june.cs.washington.edu (William Griswold) Return-Path: Message-Id: <8909262113.AA07260@june.cs.washington.edu> To: goer@sophist.uchicago.edu, icon-group@arizona.edu Subject: Re: tables, efficiency >Date: Tue, 26 Sep 89 12:11:08 CDT >From: Richard Goerwitz >To: icon-group@arizona.edu >Subject: tables, efficiency >Errors-To: icon-group-errors@arizona.edu > >Could someone familiar with the implementation of tables explain >how efficient use can be made of storage when the ultimate size >of the table is unknown? Or does the interpreter indeed check >to see how big the various regions are, and adjust the algorithm >to make maximum use of a given memory space? > >Just dunno, but would like t'know. > > -Richard L. Goerwitz The current table implementation uses a simple hashing scheme. If you are not familiar with hashing, check your nearest data structures text or the Knuth volume on searching and sorting. The briefest description follows. Basically, a hashing data structure allows computing an array index for an input element (a constant-time operation), and storing the element at that index. If multiple elements are assigned to the same slot, both are stored there on a linked list. Elements on a chain are stored in sorted order of their hash numbers. By simple hashing, I mean that there are a fixed number of hash slots. For small tables, constant-time access is usually achieved for an individual element. For tables over 1000 elements, performance begins to degrade measurably. This is due to the linear-time cost of searching down the hash chain. Hashing does not take memory availability into account in building tables. It is hard to say how this could be done effectively in the face of so many dynamic properties of programs. However, an upcoming version of Icon may have an implementation of tables (and sets) employing dynamic hashing. Dynamic hashing permits increasing the number of slots in a hash table as a table grows. This avoids performance degradation when tables become large, because the collision resolution chains are kept short. This uses an additional 10% of memory over the old hash table implementation. It does not take memory availability characteristics in to account, unless memory is actually exhausted. For a more complete description of dynamic hashing, look for your next issue of the Icon Newsletter. I should note that taking memory characteristics into account on a machine supporting a paging operating system does not make sense. The operating system on such a system makes every attempt to make the finiteness of memory invisible in terms of function *and* performance. They are usually successful. This is not at all the case with PC machines with more primitive operating systems. With any luck, however, all of these machines will be gone in a decade. Bill Griswold From icon-group-request Tue Sep 26 14:19:27 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA15913; Tue, 26 Sep 89 14:19:27 MST Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA13076; Tue, 26 Sep 89 14:00:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 89 18:09:16 GMT From: hsi!mfci!m3!genly@uunet.uu.net (Chris Hind Genly) Organization: Multiflow Computer Inc., Branford CT Subject: var params Message-Id: <1045@m3.mfci.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <10746@dasys1.UUCP> aj-mberg@dasys1.UUCP (Micha Berger) writes: From: vicc@unix.cie.rpi.edu (VICC Project (Rose)) I too miss var parameters, unfortuanately they require a new data type (to some extent at least) to implement. Thanks for the reply. From: aj-mberg@dasys1.UUCP (Micha Berger) "var" params, as you call it, is normally called "passing by reference. I was being informal here. Either pass by reference or copy-in copy-out would accomplish what I want. Passing by reference is considered by most language feature as dangerous. It allows a function to change the value of a variable without the user realizing. This is an issue of exposition. It is not clear from looking at a call using pass-by-reference that it is actually using pass by reference. One must go to the definition of the procedure being called. Rather than the feature of pass-by-reference being dangerous, this seems to be a weakness in the syntax of a language like Pascal. There is no difference in the syntax between passing an argument by value or by reference. If the syntax were different, anyone reading the source would know that the value of an argument could be changed. As an example, if the values which are to be passed by referenced were followed by an '=', then it would be clear which variables could be changed. In the following example, a could not change value, while b and c could. p(a, b=, c=) If you want to return a bunch of values from one function, why not return a list? This is a matter of clarity and efficiency. I want to be able to express pass-by-reference in the language directly. I don't want to introduce an auxiliary structure like a list, and have to pack it and unpack it. The list has nothing to do with the reason I am writing the program. I don't want to introduce it just to work around the lack of call by reference. From: vicc@unix.cie.rpi.edu (VICC Project (Rose)) One must program ones procedures which use pass by reference such that side effects will be obvious. Agreed. I would be interested in what techniques you've been using to do this. From: ok@cs.mu.oz.au (Richard O'Keefe) If you will be content with pass by value result (as Fortran and Ada are), you can get that effect just by bending the Icon translator. Suppose, for example, that you add Ada syntax for arguments: 'in' value passed in 'out' result passed back 'in out' value passed in and result passed back. I wasn't actually proposing to change the language, but this is along the lines I was thinking. I understand how to work around call-by-value, and I see that its possible to change the translator. But I'm still wondering if people miss the ability to return multiple values from a call. Regardless of the mechanism, either by call-by-reference, copy-in copy-out, or by a multi-valued return value. Do you find you have to return multiple value so few times that its not a problem? Are the icon programs you write so small that you resort to using global variables without trading off understandability? Do you find using an auxiliary structure to pack multiple return values to be unobtrusive? -- ======================================================================= Chris Hind Genly, N1GLZ - Multiflow Computer - mfci!genly (203)488-6090 From @ricevm1.rice.edu:EM302723@VMTECMEX.BITNET Mon Oct 9 16:21:06 1989 Message-Id: <8910092321.AA23785@megaron.arizona.edu> Received: from icsa.rice.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA23785; Mon, 9 Oct 89 16:21:06 MST Received: from VMTECMEX.BITNET by ricevm1.rice.edu (IBM VM SMTP R1.2.1) with BSMTP id 8974; Mon, 09 Oct 89 18:21:34 CDT Date: Mon, 09 Oct 89 09:40:02 MEX To: icon-group@arizona.edu From: EM302723%VMTECMEX.BITNET@ricevm1.rice.edu Comment: CROSSNET mail via SMTP@INTERBIT Date: 9 October 89, 09:39:35 MEX From: Mario Camou R. (Dr. Mangagoras) EM302723 at VMTECMEX To: ICON-GROUP at ARIZONA Subject: Icon assembler? Hi, I have been browsing through the Icode files produced by ICONT. They seem to be coded in some kind of assembly code...Has anybody thought about writing some sort of an Icode assembler? It seems to me that a version of ICONX that worked with binary files should be faster than one that works with text files. Also, it SHOULD use less memory (maybe you UNIX hacks with gigabytes of virtual memory don't think much about this...but memory is scarce in the MS-DOS envi- ronment). I really haven't read the implementation book, so I don't know much about what I'm talking about. This is just an idea that cropped up recently. Any comments? +----------------------------------+------------------------------+ | Dr. Mangagoras | Mario Camou Riveroll | | EM302723@VMTECMEX.BITNET | Apdo. Postal 41554 | | | Mexico, D.F. 11001 Mexico | +----------------------------------+------------------------------+ | Don't take life too seriously - it's just a temporary situation | +-----------------------------------------------------------------+ From kwalker Wed Oct 11 17:12:51 1989 Date: Wed, 11 Oct 89 17:12:51 MST From: "Kenneth Walker" Message-Id: <8910120012.AA04649@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA04649; Wed, 11 Oct 89 17:12:51 MST In-Reply-To: <8910092321.AA23785@megaron.arizona.edu> To: icon-group > Date: 9 October 89, 09:39:35 MEX > From: Mario Camou R. (Dr. Mangagoras) EM302723 at VMTECMEX > > Hi, > I have been browsing through the Icode files produced by ICONT. They seem to be > coded in some kind of assembly code...Has anybody thought about writing some > sort of an Icode assembler? It seems to me that a version of ICONX that worked > with binary files should be faster than one that works with text files. Also, > it SHOULD use less memory (maybe you UNIX hacks with gigabytes of virtual > memory don't think much about this...but memory is scarce in the MS-DOS envi- > ronment). You can think of iconx as an intepreter implementing a virtual machine. In which case the ucode (the text files produced with the -c option to icont) can be viewed as a kind of assembly language. In addition to creating ucode files, icont combines (links) them, resolving undeclared variables, and produces icode files. The icode is in binary form and is the "machine code" for iconx. Even when you don't use the -c option, icont creates temporary ucode files and deletes them when it is done. It would probably be more efficient if icont created intermediate code in binary form rather than as text. However, the text files are useful for debugging Icon and for understanding the implementation. No one has yet done a lot of work on improving the efficiency of icont. It is possible to translate ucode into a real machine code. However, you won't necessarily gain in terms of memory. Icode is quite compact. In addition, if you produce a real executable, you will have to link in most of the Icon run-time system (the biggest part of iconx). Each program you have compiled and linked will have a copy of this run-time code, taking up a lot of disk space. If you think you can tell what is called and thus link in only a fraction of the library, consider the problem of string invocation (this is a problem we must tackle in our research into an optimizing compiler for Icon). Real machine code will gain you something in terms of speed, but less than you might think. Icon programs spend most of their time in run-time routines, not in intepreting icode instructions. An earlier version of Icon had a compiler which produced machine code. In addition, Janalee O'Bagy has a prototype compiler which produces machine code (with C code as an intermediate step). The speed improvement for the eariler compiler is usually quoted as being 5%-10% for typical programs. In her dissertation, Janalee O'Bagy lists speed improvements for naive compilation of 6 programs as ranging from 3% to 24%. Better speed improvements require more than simple "assembly" of ucode. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 2858 kwalker@Arizona.EDU {uunet|allegra|noao}!arizona!kwalker From EM302723@VMTECMEX.BITNET Fri Oct 13 18:11:44 1989 Message-Id: <8910140111.AA06348@megaron.arizona.edu> Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA06348; Fri, 13 Oct 89 18:11:44 MST Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Fri, 13 Oct 89 18:11 MST Received: by VMTECMEX (Mailer R2.03B) id 3250; Fri, 13 Oct 89 09:33:49 MEX Date: Fri, 13 Oct 89 09:28:33 MEX From: "Mario Camou R. (Dr. Mangagoras)" Subject: Icon executables? To: icon-group@arizona.edu OK...so you wouldn't get much of a speed gain by directly compiling to machine code. However, that brings up another idea. Seems to me that to have a directly executable Icon program would be a real help in production systems (whether internal use or for external distribution). An idea would be to put an option on ICONT so that ICONX is linked together with the program. That way you would get executable programs without modifying ICONT or ICONX too much. Of course, I'm just speaking from the top of my head. How's this sound, feasi- bility-wise? +----------------------------------+------------------------------+ | Dr. Mangagoras | Mario Camou Riveroll | | EM302723@VMTECMEX.BITNET | Apdo. Postal 41554 | | | Mexico, D.F. 11001 Mexico | +----------------------------------+------------------------------+ | Don't take life too seriously - it's just a temporary situation | +-----------------------------------------------------------------+ From icon-group-request Sat Oct 14 02:54:29 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA21138; Sat, 14 Oct 89 02:54:29 MST Received: by ucbvax.Berkeley.EDU (5.61/1.38) id AA11007; Sat, 14 Oct 89 02:42:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Oct 89 03:15:00 GMT From: ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!petersen@iuvax.cs.indiana.edu Subject: Re: (none) Message-Id: <30300001@uicsrd.csrd.uiuc.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu It seems the one solution to promoting icon programs as first class citizens would be to use dynamic libraries such as used by the Amiga, OS/2, or SunOS 4.0. This would allow compilation to machine code without the need to link in the run time library explicitly into each copy. Has any work been done to support this on the systems that have dynamic libraries? -Paul Petersen (petersen@uicsrd.csrd.uiuc.edu) From icon-group-request Mon Oct 16 11:44:52 1989 Received: from ucbvax.Berkeley.EDU by megaron (5.59-1.7/15) via SMTP id AA01740; Mon, 16 Oct 89 11:44:52 MST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA22589; Mon, 16 Oct 89 11:25:39 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Oct 89 13:35:17 GMT From: esquire!yost@nyu.edu (David A. Yost) Organization: DP&W, New York, NY Subject: Re: icon should use dynamic linking on systems that have it Message-Id: <1487@esquire.UUCP> References: <30300001@uicsrd.csrd.uiuc.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <30300001@uicsrd.csrd.uiuc.edu> petersen@uicsrd.csrd.uiuc.edu writes: >It seems the one solution to promoting icon programs as first class >citizens would be to use dynamic libraries such as used by the >Amiga, OS/2, or SunOS 4.0. This would allow compilation to machine code >without the need to invoke a separate interpreter program at runtime. This is a nice idea. I think the problem of Icon first class citizenry is that there has to be another file installed somewhere (the interpreter). Moving the interpreter from its present home in an executable file to a new home in a shared library doesn't change this. Aside from startup time, would execution time or in-core memory residency really be improved? --dave From EM302723@VMTECMEX.BITNET Fri Oct 27 17:37:27 1989 Message-Id: <8910280037.AA19850@megaron> Received: from rvax.ccit.arizona.edu by megaron (5.59-1.7/15) via SMTP id AA19850; Fri, 27 Oct 89 17:37:27 MST Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Fri, 27 Oct 89 17:37 MST Received: by VMTECMEX (Mailer R2.04) id 9737; Fri, 27 Oct 89 15:45:49 MEX Date: Fri, 27 Oct 89 15:44:11 MEX From: "Dr. Mangagoras" Subject: Are you still alive? To: Icon user's group Hi, Since it's been a couple of weeks since I received anything from this group I was wondering whether everybody's still alive and well in Iconland, or if everybody has left for the next language revolution. What's up?? +----------------------------------+------------------------------+ | Dr. Mangagoras | Mario Camou Riveroll | | EM302723@VMTECMEX.BITNET | Apdo. Postal 41554 | | | Mexico, D.F. 11001 Mexico | +----------------------------------+------------------------------+ | Don't take life too seriously - it's just a temporary situation | +-----------------------------------------------------------------+ From icon-group-request Sun Oct 29 01:16:40 1989 Received: from ucbvax.Berkeley.EDU by megaron (5.59-1.7/15) via SMTP id AA19114; Sun, 29 Oct 89 01:16:40 MST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA01733; Sun, 29 Oct 89 01:10:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Oct 89 03:50:15 GMT From: agate!saturn!ucscg.UCSC.EDU!kellyp@ucbvax.Berkeley.EDU (17531000) Organization: University of California, Santa Cruz CATS Subject: some questions Message-Id: <9551@saturn.ucsc.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Is there a pre-procesor around for making Icon object oriented? In the spirit of C++. If not, how difficult would this be to make? I'm looking for encapsulation and auto-setup/terminate procedures. The main thing is that I don't like to worry about name conflicts when I put modules together. ---- I lost the two messages I received about Emacs helpers for Icon. Could you send them again? ---- In article <1487@esquire.UUCP> yost@esquire.UUCP (David A. Yost) writes: >In article <30300001@uicsrd.csrd.uiuc.edu> petersen@uicsrd.csrd.uiuc.edu ws: >>It seems the one solution to promoting icon programs as first class >>citizens would be to use dynamic libraries such as used by the >>Amiga, OS/2, or SunOS 4.0. This would allow compilation to machine code >>without the need to > invoke a separate interpreter program at runtime. > >Aside from startup time, would execution time >or in-core memory residency really be improved? > > --dave Yes. On the Amiga using a library would make it so that the interpreter stuff is only loaded once. As it is currently, each time you invoke an Icon program the header (interpreter) is also loaded. Another way to fix this is to make the header 'resident'. This requires that the header be re-entrant. In the latest version that I picked up (for the Amiga) there is only icont and iconx. The compiled program can not be invoked itself, you must do 'iconx prg'. I tried making it resident and it did some strange things concerning the command line arguments on the second invocation, and I concluded that it was not re-entrant. For the Amiga, it seems to me, that the simplest way to avoid double loads would be to make the interpreter re-entrant and make it 'resident'. The problems with this is that the load of the interpreter must be made explicitly (with the resident command) or else you are right back where you started (loading multiple copies into memory). To use a library would make it so that the load is done implicitly when a compiled Icon program is invoked. To make a library would be a heck of a lot harder. If this was done, tho, you have an interesting situation: any program may access the library. The library could be used as an imbedded virtual machine within an application. ----------------------------------------------------------------------------- Patrick Kelly ---- mail to kellyp@ucscB.ucsc.edu ---- Zxcvbne Rtyui ----------------------------------------------------------------------------- From cjeffery Sun Oct 29 16:20:19 1989 Date: Sun, 29 Oct 89 16:20:19 MST From: "Clinton Jeffery" Message-Id: <8910292320.AA23794@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA23794; Sun, 29 Oct 89 16:20:19 MST To: icon-group Subject: Making Iconx resident on the Amiga As the Amiga contact at Arizona, I feel obliged to comment on the recent discussion. Yes, making iconx resident would make Icon much more pleasant on the Amiga. There are a lot of other things that would make Icon much more pleasant on the Amiga, for that matter. While I do not have the time available to learn machine-specific environments like the Amiga, I would certainly be glad to talk to any C/Amiga-gurus interested in tackling the residence problem. If anyone makes this work and sends us some reasonable source code we'll be sure to incorporate it into the next release of Amiga Icon. This goes for other niceties that fall under the category of "Amigazation" instead of the category of "computer science research". Clint Jeffery -- P.S. I am speaking for myself. This is not an Icon project opinion. From cjeffery Sun Oct 29 16:49:04 1989 Date: Sun, 29 Oct 89 16:49:04 MST From: "Clinton Jeffery" Message-Id: <8910292349.AA24876@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA24876; Sun, 29 Oct 89 16:49:04 MST To: kellyp@ucscB.ucsc.EDU Cc: icon-group@arizona.edu Subject: Objects and Icon Several people have done work towards an object-oriented Icon. The first person to propose anything concrete was (I think) Bill Griswold; I hope he (and the others working in this area) will comment on the status of their projects and whether they are publicly available. My own hack, an Icon-Derived Object Language (Idol), will be described in the next Icon newsletter. It is a preprocessor rather than a modification to icont or a variant translator. It provides the encapsulation and auto-setup procedures you requested within the framework of classes and multiple inheritance. It looks more like Icon than C++. I will see about placing a copy of Idol in our FTP copying area. Email me if you are interested. Clint Jeffery From uunet!hsi!mlfarm!ron Sun Oct 29 17:06:33 1989 Received: by megaron.arizona.edu (5.59-1.7/15) id AA25935; Sun, 29 Oct 89 17:06:33 MST Received: from hsi.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA00114; Sun, 29 Oct 89 18:06:55 -0500 Received: by hsi.HSI.COM (smail2.5) id AA14032; 29 Oct 89 17:06:30 EST (Sun) Received: by mlfarm.uucp (smail2.5) id AA00374; 29 Oct 89 13:02:40 EST (Sun) To: icon-group-sender@arizona.edu Cc: icon-group@arizona.edu, icon-group-request@arizona.edu, icon-group-errors@arizona.edu Subject: address change Message-Id: <8910291302.AA00374@mlfarm.uucp> Date: 29 Oct 89 13:02:40 EST (Sun) From: uunet!mlfarm!ron (Ronald Florence) I would appreciate very much if you could change my address on the various mailing lists to ron@mlfarm.uucp as the routing via aati is no longer reliable. Thanks. Ronald Florence ...{hsi,rayssd}!mlfarm!ron From EM302723@VMTECMEX.BITNET Mon Oct 30 10:10:57 1989 Message-Id: <8910301710.AA10982@megaron> Received: from rvax.ccit.arizona.edu by megaron (5.59-1.7/15) via SMTP id AA10982; Mon, 30 Oct 89 10:10:57 MST Received: from VMTECMEX.BITNET by rvax.ccit.arizona.edu; Mon, 30 Oct 89 10:12 MST Received: by VMTECMEX (Mailer R2.04) id 3009; Mon, 30 Oct 89 09:26:55 MEX Date: Mon, 30 Oct 89 09:24:15 MEX From: "Dr. Mangagoras" Subject: Discussion logs? To: icon-group@arizona.edu Hi, I was wondering, is there a log of the most recent posts to the newsgroup? I have FTP'ed all logs from GROUP83.TXT to GROUP89A.TXT, but I'm interested in the more recent posts (after GROUP89A). This is because the @$@"$|"@$ operators in our installation sometimes purge the reader before we can read the mail, so I'd like to check whether I've got all posts. Thanx, +----------------------------------+------------------------------+ | Dr. Mangagoras | Mario Camou Riveroll | | EM302723@VMTECMEX.BITNET | Apdo. Postal 41554 | | | Mexico, D.F. 11001 Mexico | +----------------------------------+------------------------------+ | Don't take life too seriously - it's just a temporary situation | +-----------------------------------------------------------------+ From ralph Mon Oct 30 10:37:32 1989 Date: Mon, 30 Oct 89 10:37:32 MST From: "Ralph Griswold" Message-Id: <8910301737.AA12538@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA12538; Mon, 30 Oct 89 10:37:32 MST To: EM302723@VMTECMEX.BITNET, icon-group@arizona.edu Subject: Re: Discussion logs? In-Reply-To: <8910301710.AA10982@megaron> We collect icon-group mail and put it out on out FTP and RBBS areas periodically. Recent material is not available (yet). Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From @um.cc.umich.edu:Paul_Abrahams@Wayne-MTS Tue Oct 31 02:02:06 1989 Received: from shadooby.cc.umich.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA14292; Tue, 31 Oct 89 02:02:06 MST Received: from ummts.cc.umich.edu by shadooby.cc.umich.edu (5.61/gossip-1.1) id AA03900; Tue, 31 Oct 89 04:01:12 -0500 Received: from Wayne-MTS by um.cc.umich.edu via MTS-Net; Tue, 31 Oct 89 04:01:53 EST Date: Mon, 30 Oct 89 23:11:46 EST From: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu To: icon-group@arizona.edu Message-Id: <177711@Wayne-MTS> Subject: Redirecting error output from icont I tried the following way of redirecting error output from the translator: icont -e pgm.err pgm The error output appeared on the standard output file anyway. This was with version 7.5 under MS-DOS. Can it be done? If so, how? Paul Abrahams (abrahams%wayne-mts@um.cc.umich.edu) From ralph Tue Oct 31 06:41:40 1989 Date: Tue, 31 Oct 89 06:41:40 MST From: "Ralph Griswold" Message-Id: <8910311341.AA27751@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA27751; Tue, 31 Oct 89 06:41:40 MST To: Paul_Abrahams%Wayne-MTS@um.cc.umich.edu, icon-group@arizona.edu Subject: Re: Redirecting error output from icont The -e option to redirect error output only applies to iconx. Sorry. Ralph Griswold / Dept of Computer Science / Univ of Arizona / Tucson, AZ 85721 +1 602 621 6609 ralph@Arizona.EDU uunet!arizona!ralph From goer@sophist.uchicago.edu Fri Nov 3 14:21:00 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA05519; Fri, 3 Nov 89 14:21:00 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Fri, 3 Nov 89 15:21:06 CST Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA15615; Fri, 3 Nov 89 15:18:40 CST Date: Fri, 3 Nov 89 15:18:40 CST From: Richard Goerwitz Message-Id: <8911032118.AA15615@sophist.uchicago.edu> To: icon-group@cs.arizona.edu Subject: frivolous child's game I used the following program to teach my son to count. It's extremely simple, but effective enough to encourage a child who knows how to get from 1-10 to take it to 100 or 1000. It runs on any terminal that can accept ANSI color sequences. Mono monitors will work, but gee whiz. Please don't ask why I didn't comment some of the more cryptic sections. It was just a Saturday afternoon hack for my kid. Maybe yours will like it too. procedure main(a) x := integer(\a[1]) | 1 s := "" writes("\e[2J\e[6;1H") every s ||:= string(x) | (" " || |(x +:= 1)) do { (x % ([3,7,11][?4])) = 0 & goodjob() repeat { writes("\n\nWhat's next?\n") outstr := "" every outstr ||:= (format(s) || " \n") writes(trim(outstr,'\n')) if (x + 1) = integer(n := read()) then break else { (any("Q"|"q",n) & stop("\e[0m\e[2J")) write("\nNO. TRY AGAIN.\x07\x07") } } } end procedure format(s) (s || " ") ? { while (nextline := lines(s))[-1] == " " do { nextline ?:= trim((tab(many(' ')) | &null, tab(0))) suspend nextline } } end procedure lines(s) suspend &subject[.&pos:&pos <- (&pos+31 to &pos+39) | 0] end procedure goodjob() writes("\e[2J") every 1 to ((25 * ?6) + 10) do { # T := &time; until &time > (T+3) every i := 1 to 100 + ?5 write("\e[",?24,";",?71,"H\e[",29+?17,";",29+?17,"mGOOD JOB!\e[0m") } T := &time; until &time > (T+1000) write("\e[2J\e[8;1H\e[0m \e[", 37,";",43,"mYOU DID VERY GOOD!!\e[0m") T := &time; until &time > (T+2000) writes("\e[",i := (29+?7),";",(i + 10) ~= (39+|?7),"m") writes("\e[2J\e[8;1H") return end -Richard L. Goerwitz goer@sophist.uchicago.edu goer%sophist@uchicago.bitnet rutgers!oddjob!gide!sophist!goer From goer@sophist.uchicago.edu Fri Nov 3 19:44:22 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA17603; Fri, 3 Nov 89 19:44:22 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Fri, 3 Nov 89 20:44:34 CST Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA16069; Fri, 3 Nov 89 20:42:07 CST Date: Fri, 3 Nov 89 20:42:07 CST From: Richard Goerwitz Message-Id: <8911040242.AA16069@sophist.uchicago.edu> To: icon-group@cs.arizona.edu Subject: more frivolity This is another game I wrote for my son one day when he was being naughty, and we were having a bad time. I hope some- one else finds programming in icon interesting enough to stray into corners like this (assumes an ANSI terminal that accepts color commands). If the field names seem in poor tast, remember that just about everything is in poor taste when a three year-old and his dad are hanging around the house: record wholething(poop,body) procedure main(a) static snake, limit repeat { snake := list(25); snake[1] := [?25, ?80] every x := 2 to 25 do snake[x] := findnext(snake[x-1]) limit := (\a[1] | 2000) every i := 1 to limit do { r := makenew(snake) leftbehind := r.poop snake := r.body display(leftbehind,snake) } every leftbehind := !snake do display(leftbehind) } end procedure findnext(l) i := l[1]; j := l[2] (k := 26 > [i,i+1,i-1][|?3]) > 0 & (l := 81 > [j,j+1,j-1][|?3]) > 0 & not (k = 25, l = 80) return [k, l] end procedure different(l,snake) (l[1] = (bit := !\snake)[1], l[2] = bit[2]) & fail return end procedure display(lb,snake) static i,j,k initial { # kinda have to fool with my implementation to get somewhat # random numbers T := &time; while color := |?3 do &time > T + 90 & break case color of { 1 : { i := "37"; j := "41"; k := "40" } 2 : { i := "31"; j := "44"; k := "40" } 3 : { i := "32"; j := "47"; k := "40" } } writes("\e[",i,";",j,"m") writes("\e[2J") } if different(lb,snake) then writes("\e[",lb[1],";",lb[2],"H\e[",k,"m ") writes("\e[",i,";",j,"m") writes("\e[",snake[*\snake][1],";",snake[*snake][2],"H\xDB") return end procedure makenew(snake) leftbehind := snake[1] every i := 1 to *snake - 1 do snake[i] := snake[i+1] snake[*snake] := findnext(snake[*snake-1]) return wholething(leftbehind,snake) end From @s.ms.uky.edu:mtbb95@ms.uky.edu Sun Nov 5 18:56:32 1989 Received: from e.ms.uky.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA12427; Sun, 5 Nov 89 18:56:32 MST Received: from s.ms.uky.edu by g.ms.uky.edu id aa01196; 5 Nov 89 20:53 EST From: Bob Maras Date: Sun, 5 Nov 89 20:53:32 EST X-Mailer: Mail User's Shell (6.4 2/14/89) To: Richard Goerwitz , icon-group@cs.arizona.edu Subject: Re: more frivolity Message-Id: <8911052053.aa13668@s.s.ms.uky.edu> Richard, As a teacher for 20 years and a parent of two elementary school students, I really appreciate your recent postings re: applicable software in icon. Bob -- _ _ ( ) __ ( ) | O O | B O B M A R A S / __ \ / ( \/ ) __/ \ \__/ / \____/ |_/\_| H A P P Y C O M P U T I N G !!! From R.J.Hare@EDINBURGH.AC.UK Wed Nov 15 05:21:45 1989 Received: from rvax.ccit.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA07506; Wed, 15 Nov 89 05:21:45 MST Received: from UKACRL.BITNET by rvax.ccit.arizona.edu; Wed, 15 Nov 89 05:23 MST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1519; Wed, 15 Nov 89 09:05:16 GMT Date: 15 Nov 89 09:03:40 gmt From: R.J.Hare@EDINBURGH.AC.UK Subject: Icon Mailer To: icon-group@arizona.edu Via: UK.AC.ED.EMAS-A; 15 NOV 89 9:04:09 GMT Message-Id: <15 Nov 89 09:03:40 gmt 340955@EMAS-A> This is by way of being a begging letter... I currently do the newsletter mailshot for a couple of small clubs I am a member of, and will shortly want to pass this job onto someone else. This will necessitate the transfer of the job from one (non-Icon) machine to another (Icon) machine. My current mailshot program is *not* portable, so I want an Icon mailshot program. To save me writing one from scratch, does anyone out there have a (simple) mailshot program they would be prepared to gift to me for the above purpose? Thanks. @ Roger Hare. From goer@sophist.uchicago.edu Thu Nov 16 11:36:52 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA26958; Thu, 16 Nov 89 11:36:52 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Thu, 16 Nov 89 12:36:42 CST Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA08318; Thu, 16 Nov 89 12:33:54 CST Date: Thu, 16 Nov 89 12:33:54 CST From: Richard Goerwitz Message-Id: <8911161833.AA08318@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: frivolity once again It's not as if I only write games for my son, though the code I post here seems inevitably to tend in that direction. Normally I use icon to help me reconstruct the phonology of dead langu- ages by comparing computational models of various phonological processes against known texts to see if they conform to all the known evidence. If anyone else is using Icon for natural langu- age processing of this or any other type, I surely would like to know about it! But anyway, here's a kids' game. Sorry it's IBM charset and ANSI specific. These are the tools I have around the house (Xenix on an AT-type machine, to be specific): global name_of_wordfile, termlength, timing procedure main() name_of_wordfile := "/so/goer/words" termlength := 24 timing := 60 # Kind of a hangman game, built for my three year-old son to peel # him away from Wheel of Fortune (which he calls "the letter game"). # Assumes an ANSI or similar terminal - one has a 256 char IBM set # and accepts color commands. Before running, create a file of words, # phrases, or sentences, and then assign name_of_wordfile to the name # of that file. For 24-line terminals, assign termlength to 24. If # things happen too slowly for you, try resetting the global variable # "timing" to 40 or 30. Oh, by the way, the format of the wordfile # is one word or phrase to a line. Couldn't be simpler. Ask your # kid what words he or she likes, and the interest level will go up # several orders of magnitude. Make sure the user has write permis- # sion on the wordfile. To abort, type "quit." To solve the puz- # zle, type in the entire word or phrase at the prompt. To give up, # type "tell me." hitlst := list() until *(s := readword()) < 33 writes("\e[30;44m\e[2J") every i := upto(~(&ucase++&lcase), s) do put(hitlst,s[i]) writeboxes(s,hitlst) until *hitlst = *s do { hitlst := query(s,hitlst) writeboxes(s,hitlst) } T := &time; until &time > (T + timing*8) writes("\e[37;41m\e[2J") goodjob(); readword(1) stop("\e[",string(termlength - 1),";1H\e[37;40m") end procedure writeboxes(s,l) writes("\e[30;44m") writes("\e[9;11H\e[33m") every i := 1 to *s do { T := &time; until &time > (T + timing/2) if map(s[i]) == map(!\l) then { writes("\e[s\e[30m\xDB") T := &time; until &time > (T + timing/5) writes("\e[u\e[37m",s[i],"\e[30m") } else { writes("\e[s\e[30m\xDB") T := &time; until &time > (T + timing/5) writes("\e[u\e[33m\xDB\e[30m") } i ~= *s & writes(" ") } writes("\e[30;44m") return end procedure query(s,l) static tried initial tried := "" snew := map(s) repeat { ad := string(cset(tried)) writes("\e[",string(termlength),";2HYou've tried: \e[32m",ad,"\e[30m\e[K") sd := &lcase -- string(cset(ad)) writes("\e[",string(termlength),";40HStill left: \e[32m",sd,"\e[30m\e[K") writes("\e[11;11HGuess a letter: \e[K\e[31m") guess := map(read()) writes("\e[30m") if guess == "quit" then readword(1) if *guess ~= 1 then { if guess == map(s) then { hitlst := [] every put(hitlst,!s) return hitlst } if trim(guess,'.?!') == "tell me" then { hitlst := []; every put(hitlst,!s) writeboxes(s,hitlst) readword(1) } writes("\e[14;11HHas to be one letter, not ",*guess," letters!\e[K") T := &time; until &time > (T + timing*10) every j := 12 to (termlength - 1) do writes("\e[",j,";1H\e[K") writes("\e[14;1H\e[K") } else { if any(~(&ucase ++ &lcase),guess) then { writes("\e[14;11HHas to be a letter!\e[K") T := &time; until &time > (T + timing*7) writes("\e[14;1H\e[K") next } if find(guess,tried) then { writes("\e[14;11HYou already did that one!\e[K") T := &time; until &time > (T + timing*7) writes("\e[14;1H\e[K") next } tried ||:= guess if find(guess,snew) then { every find(guess,snew) do put(l,guess) break } else { writes("\e[14;11HSorry, try again!\e[K") T := &time; until &time > (T + timing*4) writes("\e[14;1H\e[K") } } } return l end procedure readword(c) static wordlist, count, position initial { wordlist := list(200,"") count := 0; position := 0 intext := open(name_of_wordfile,"r") | stop("You first have to create a wordfile (see source).") every "" ~== trim(s := !intext) do wordlist[count +:= 1] := s close(intext) } if type(c) == "null" then { position := getpos(count,position) return wordlist[position] } else { outtext := open(name_of_wordfile,"w") | stop() every i := position + 1 to count do write(outtext,wordlist[i]) every j := 1 to (position) do write(outtext,wordlist[j]) # if position = 0 it'll fail close(outtext) stop("\e[",string(termlength - 1),";1H\e[37;40m") } end procedure getpos(count,position) if count < (position +:= 1) then return 1 else return position end procedure goodjob() writes("\e[2J") every 1 to ((50 * ?5) + 90) do { every i := 1 to 100 + ?5 write("\e[",?24,";",?71,"H\e[",29+?17,";",29+?17,"mYOU WON!\e[0m") } return end From cjeffery Fri Nov 17 14:45:31 1989 Received: from caslon.cs.arizona.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA05070; Fri, 17 Nov 89 14:45:31 MST Date: Fri, 17 Nov 89 14:45:29 mst From: "Clinton Jeffery" Message-Id: <8911172145.AA26671@caslon> Received: by caslon; Fri, 17 Nov 89 14:45:29 mst To: icon-group Subject: Object Oriented Icon A copy of Idol, an Icon-derived object language, is available by anonymous ftp from cs.arizona.edu (or arizona.edu). The distribution is in the icon subdirectory, and you can take your pick of file formats: idol.arc, idol.zoo, idol.cpi, idol.tar, and idol.shr (ARC, ZOO, CPIO, TAR, or SHAR format, respectively). Idol is a preprocessor which provides Icon with classes and multiple inheritance in the form of an augmented record data type. The current version has not been tested on non-UNIX systems; feel free to add support for your favorite system and email it to me. Bug reports (and fixes!) concerning Idol should be sent to cjeffery@cs.arizona.edu rather than the Icon project. I would appreciate feedback from anyone who uses Idol in a substantial Icon application. Clint Jeffery From dscargo@cim-vax.honeywell.com Mon Nov 20 09:30:53 1989 Message-Id: <8911201630.AA01326@megaron.arizona.edu> Received: from cim-vax.Honeywell.COM by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA01326; Mon, 20 Nov 89 09:30:53 MST Date: 17 Nov 89 16:53:00 CST From: "DAVE CARGO" Subject: reverse match To: "icon-group" I found myself writing a application where I wanted to make a decision based on characters at the END of a string. I wanted something like match but working from the end rather than the beginning of the string. What I chose by way of implementation was the following: nekot := reverse(token) if match("." | ")." | "\"." | ")\".", nekot) ... I have two questions. In general is there a better way to do this? The strings I wanted to test for are different sizes so a fixed range didn't work. Second, could I have used if match("." | ")." | "\"." | ")\".", reverse(token)) directly without having the reverse(...) evaluated multiple times? (An admittedly lazy question on my part, since I could have tested this.) David S. Cargo (DSCARGO@CIM-VAX.HONEYWELL.COM) From goer@sophist.uchicago.edu Mon Nov 20 18:00:41 1989 Received: from tank.uchicago.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA07924; Mon, 20 Nov 89 18:00:41 MST Received: from sophist.uchicago.edu by tank.uchicago.edu Mon, 20 Nov 89 19:00:48 CST Return-Path: Received: by sophist.uchicago.edu (3.2/UofC3.0) id AA14426; Mon, 20 Nov 89 18:57:56 CST Date: Mon, 20 Nov 89 18:57:56 CST From: Richard Goerwitz Message-Id: <8911210057.AA14426@sophist.uchicago.edu> To: icon-group@arizona.edu Subject: reverse, ends of sentences It looks to me as though you were trying to determine whether a given string ends in a sequence normally associated with sentence-closure. The best way to do this depends on the context in which you are pro- gramming. Are you, say, looking for an accurate sentence count in a document? If so, you will doutless want to use string scanning. If not, then a simple procedure like IsSentence might be invoked (its main virtue is clarity, not speed): procedure main() while line := !&input do { if IsSentenceEnd(line) then write("yes") else write("no") } end procedure IsSentenceEnd(str) punctuation := '\'"()[]?!.' shortstr := trim(str,punctuation) if upto('?!.',str,*shortstr+1) then return end In the context of string scanning, it is hard to use the reverse function. Besides, I find that it tends to obfuscate code I write. This might not be true for you, but I find I have to think too hard about strings that have been bent around backwards, especially when used for string scanning. If you are processing whole texts, something like the following, though not ef- ficient, will do nicely (if you are interested in efficiency, use C :-). There are many things one could to to speed up the code, such as tabbing provisionally up to periods, question marks, exclamations points. Still you get the point, I'm sure - procedure main() count := 0; extrabit := "" while line := !&input do { if line == "" ~== extrabit then { write(string(count+:=1),": ",extrabit) extrabit := "" next } else line := extrabit || line line ? { while sentence := TabSentence() do write(string(count+:=1),": ",sentence) extrabit := tab(0) if extrabit[-1] ~== "-" then extrabit ||:= " " } } end procedure TabSentence() return { End2Front() || tab(upto('!.?')+1) || (tab(many('\'"()[]')) | &null, "") || ((pos(0), "") | =" ") } end procedure End2Front() suspend &subject[.&pos:&pos <- *&subject+1 to &pos by -1] end From icon-group-request@arizona.edu Sun Nov 26 14:04:41 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA12515; Sun, 26 Nov 89 14:04:41 MST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18099; Sun, 26 Nov 89 12:56:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Nov 89 19:22:55 GMT From: mcsun!ukc!sys.uea!superman@uunet.uu.net (System Admin) Organization: Democracy & Freedom Subject: help Message-Id: <876@sys.uea.ac.uk> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Appeal for all hackers and student organizations in world. Please, give morality help and solidarity for Czechoslovak students. Regards, Friendly hacker. (anon) From icon-group-request@arizona.edu Mon Nov 27 10:36:50 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA22868; Mon, 27 Nov 89 10:36:50 MST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA22641; Mon, 27 Nov 89 09:21:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Nov 89 15:29:48 GMT From: esquire!yost@nyu.edu (David A. Yost) Organization: DP&W, New York, NY Subject: Re: a < b < c Message-Id: <1616@esquire.UUCP> References: <192@eiffel.UUCP>,, <182@enea.se>,, <16655@ultima.cs.uts.oz> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In article <16655@ultima.cs.uts.oz> potter@ultima.cs.uts.oz (John Potter) writes: > > From article <192@eiffel.UUCP>, by bertrand@eiffel.UUCP (Bertrand > Meyer): > >From article <182@enea.se>, sommar@enea.se (Erland Sommarskog): >> >> > [...] The rule for a relational expression should be something like: >> > Rel_exp ::= Expression (Rel_op Expression)* >> > [...] The semantic interpretation would be than of a logical AND so >> that: >> > a < b <= c > a + 2 >> > would be a shorthand for >> > a < b AND b <= c AND c > a + 2 >> > [...] Since Eiffel still is open for changes for some more time, >> > why not take the chance and add it? Not an essential thing, >> > but one of those little things that makes life easier. Or >> > is there some problem I have overlooked? >> >> I have tried to find an argument for not following >> Mr. Sommarskog's suggestion and I cannot think of one. >> As a matter of fact, many assertions in the basic Data Structure >> Library and elsewhere would be written more simply in this way. >> >> It may be that the reason why no mainstream language has >> included the form suggested by Mr. Sommarskog is that people feared >> ambiguity. >> But the simple semantics he suggests (``and'') makes any such fear >> unfounded. > >I've just got around to reading these articles and their followups. > >It may be of passing interest to note that the language Miranda allows >precisely this form of relational expression. Miranda is a functional >language with non-strict semantics (i.e. uses lazy evaluation). >The semantic interpretation of > a < b <= c > a + 2 >would be akin to the Eiffel form > a < b and then b <= c and then c > a + 2 >The "then" corresponds to the non-strict semantics in Miranda. OK, I guess it's time someone said that the Icon programming language (available free from icon-project@arizona.edu, but please give them a few bucks) can do this, plus Icon expressions yield more information. In most languages you could divide the world of expression values into two types: boolean (used for control structures) and non- boolean. In Icon, by contrast, every expression acts as both. Every expression either "succeeds" or "fails", giving you your true/false indication, if you want to use it, and, if the expression succeeds, it has a (non-boolean) value, if you want to use it. When any subexpression fails, expression evaluation stops, and the entire expression fails. And everything is an expression in Icon; there are no statements. If a relational expression succeeds, it takes the value of the right side. So, the expression (a < b) + 1 < c evaluates like this a b c expression --- --- --- ----------------- 2 1 3 no value - fails because a < b fails 1 2 3 no value - fails because b + 1 < c fails 1 2 4 c This succeed/fail property of Icon expressions is nice to use in practice. Yet there is more still: if an expression succeeds, it can be resumed, at which point it can yield another value or fail. Thus, you will see many forms of multi-valued "generator" expressions. You can use each value in turn or just the first value, if you like. For instance, the expression 1 to 3 which yields 1, then 2, then 3, ... then fails. There are various control structures that make it easy to take advantage of the multiple values that expressions can generate, such as every expression [ do expression ] while expression [ do expression ] For example, every x := 1 to 3 do write (x) Of course, Icon subroutines either succeed or fail, and can be written to generate additional values when resumed. Icon is neat. My ideal language would be an Icon-ish Eiffel, that is, for example, everything a succeed/fail multi-valued expression instead of some things statements and some things expressions, {} syntax instead of keywords, semicolons optional, and icon-like lists in the library. --dave yost From icon-group-request@arizona.edu Mon Nov 27 14:04:47 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA11460; Mon, 27 Nov 89 14:04:47 MST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA06817; Mon, 27 Nov 89 12:57:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Nov 89 20:34:51 GMT From: mist!budd@cs.orst.edu (Tim Budd) Organization: Oregon State Univ. -- Computer Science Subject: Re: a < b < c Message-Id: <13990@orstcs.CS.ORST.EDU> References: <182@enea.se>, <16655@ultima.cs.uts.oz>, <1616@esquire.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I'm developing a new programming language called LEDA, which is designed to be ``multiparadigm''. That is, you can program in a logical (prolog style), functional, object oriented or imparative style - or in any mix. It provides generators similar (and largely taken from) Icon, as well as many other features. Several papers on LEDA are in various pipelines, but none has seen daylight yet. If you want to see various technical reports let me know and I can send them. --tim budd (budd@cs.orst.edu) From tenaglia@fps.mcw.edu Mon Nov 27 14:46:10 1989 Received: from RUTGERS.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA14407; Mon, 27 Nov 89 14:46:10 MST Received: from uwm.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA11592; Mon, 27 Nov 89 16:45:44 EST Received: by uwm.edu; id AA22193; Mon, 27 Nov 89 15:29:08 -0600 Message-Id: <8911272129.AA22193@uwm.edu> Received: from mis by fps.mcw.edu (DECUS UUCP w/Smail); Mon, 27 Nov 89 14:40:18 CDT Received: by mis.mcw.edu (DECUS UUCP w/Smail); Mon, 27 Nov 89 13:06:40 CDT Date: Mon, 27 Nov 89 13:06:40 CDT From: Chris Tenaglia - 257-8765 To: icon-group@arizona.edu Subject: Handy Dandy List Cooker Dear Icon-Group, Here is another very useful procedure. I call it cook. It takes a list of strings (filenames, usernames, etc,...) and converts them into a list of output lines. It currently assumes that the list is sorted. One can output a list of strings usually by every writes(!elements," ") where elements is a list of strings. But the format is typically like the VMS DIR or DOS DIR/W command. Unix generates a vertically oriented alphabetical list of filenames which is easier to look through. I submit my attempt below. However, my code does not have much of the spirit of icon to it, and many of you may have more elegant (and more efficient) implementations. Please feel free to improve on it. Perhaps even a different approach as a type of sorter? Have fun! The prototype is - procedure cook(lst,cols,width) required : lst is the sorted list of strings to be formatted optional : cols is how many cols are desired (5 is default) optional : width is the output width (80 is default) Yours truly, Chris Tenaglia (System Manager) tenaglia@mis.mcw.edu Medical College of Wisconsin 8701 W. Watertown Plank Rd. Milwaukee, WI 53226 (414)257-8765 ====================================================================== ################################################################## # # # THIS PROCEDURE COOKS A LIST OF STRINGS SO THAT THE LIST COMES # # OUT IN UNIX LS FORMAT RATHER THAN VMS DIR FORMAT # # # ################################################################## procedure cook(lst,cols,width) local limit,size,array,meal,food,i,j,row,column /cols := 5 ; /width := 80 items := *lst ; size := width / cols rows := items / cols + 1 ; limit := rows * cols array := table(" ") ; meal := [] until *lst > limit do put(lst," ") # push for reverse order every column := 1 to cols do every row := 1 to rows do array[row||","||column] := pop(lst) # pull for reverse order every row := 1 to rows do { food := "" every column := 1 to cols do food ||:= left(array[row||","||column],size) put(meal,trim(food)) } return meal end From icon-group-request@arizona.edu Tue Nov 28 20:05:30 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA09536; Tue, 28 Nov 89 20:05:30 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA22872; Tue, 28 Nov 89 19:00:25 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Nov 89 22:16:04 GMT From: ficc!peter@uunet.uu.net (Peter da Silva) Organization: Xenix Support, FICC Subject: Re: a < b < c Message-Id: <7138@ficc.uu.net> References: <192@eiffel.UUCP> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu I would like to note that this syntax has been used before. I implemented a real-time control language that did this about 6 or 7 years ago. It's very easy to implement, and the ambiguity does not produce much difficulty in practice. I was skeptical at first, but now I'm a convert. Too bad that project ended up getting canned due to overengineering. :-< -- `-_-' Peter da Silva . 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM From @mirsa.inria.fr:ol@cerisi.cerisi.Fr Wed Nov 29 11:56:21 1989 Received: from mirsa.inria.fr by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA22015; Wed, 29 Nov 89 11:56:21 MST Received: from cerisi.cerisi.fr by mirsa.inria.fr with SMTP (5.59++/IDA-1.2.8) id AA02956; Wed, 29 Nov 89 19:56:56 +0100 Message-Id: <8911291856.AA02956@mirsa.inria.fr> Date: Wed, 29 Nov 89 19:48:01 -0100 Posted-Date: Wed, 29 Nov 89 19:48:01 -0100 From: Lecarme Olivier To: budd%mist@cs.orst.edu Cc: icon-group@arizona.edu In-Reply-To: (Tim Budd's message of 27 Nov 89 20:34:51 GMT <13990@orstcs.CS.ORST.EDU> Subject: a < b < c I'm interested in ANY new programming language, and especially in any programming language trying to take out some good ideas from Icon. Here is my postal address: Olivier LECARME University of Nice Parc Valrose 06034 NICE cedex FRANCE Olivier Lecarme From tenaglia@fps.mcw.edu Thu Nov 30 14:24:13 1989 Received: from RUTGERS.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA22061; Thu, 30 Nov 89 14:24:13 MST Received: from uwm.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA16946; Thu, 30 Nov 89 16:23:24 EST Received: by uwm.edu; id AA28554; Thu, 30 Nov 89 13:56:48 -0600 Message-Id: <8911301956.AA28554@uwm.edu> Received: from mis by fps.mcw.edu (DECUS UUCP w/Smail); Thu, 30 Nov 89 12:53:11 CDT Received: by mis.mcw.edu (DECUS UUCP w/Smail); Thu, 30 Nov 89 12:49:57 CDT Date: Thu, 30 Nov 89 12:49:57 CDT From: Chris Tenaglia - 257-8765 To: icon-group@arizona.edu Subject: Prompting String Input Procedure Dear Icon-Group : Here is a simple and handy procedure I use all over the place. It's called input. I've used it in DOS, VMS, and UNIX. Although in unix I've had to make it a little different in some cases. Problem : Getting a screen inputted value takes 2 lines. writes("Enter Value>") value := read() Solution: It would be nice to do it in one line. value := input("Enter Value>") Method : Input Procedure... procedure input(prompt) writes(prompt) return read() end Example : Main procedure parameters. This example also makes nice use of what I call the 'either or' construct (alternation). procedure main(files) source := (files[1] | input("Source File:") | stop("Cancelled")) target := (files[2] | input("Target File:") | stop("Cancelled")) VMS : The procedure will fail if CTRL_Z is pressed. This adds a little & of the failure driven stuff. DOS UNIX : However, under unix, CTRL_Z stops the process. And pressing CTRL_D seems to cause a failure avalanch. In one application I ended up defining . as the failure string. The procedure looks like ... procedure input(prompt) local temp writes(prompt) temp := read() if temp ~== "." then return temp else fail end Conclusion : I hope some of you out there may find this helpful/useful. Perhaps there is room for improvement, especially in the UNIX example. Perhaps instead of a single string, it can truly dynamic (like write()). Enjoy ! Chris Tenaglia (System Manager) Medical College of Wisconsin 8701 W. Watertown Plank Rd. Milwaukee, WI 53226 (414)257-8765 tenaglia@mis.mcw.edu From icon-group-request@arizona.edu Sun Dec 3 16:36:47 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA18635; Sun, 3 Dec 89 16:36:47 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA21093; Sun, 3 Dec 89 15:29:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Dec 89 21:55:11 GMT From: clp@wjh12.harvard.edu (Charles L. Perkins) Organization: Harvard University, Cambridge MA Subject: Does anyone have an implementation of the language "Self"? Message-Id: <438@wjh12.harvard.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu (Sorry about the eclectic distribution, but I wanted "O-O People") I am extremely interested in the new language Self that Dave Ungar & Co. are working on at Stanford. They are currently rewriting their old version of the system to make it new and improved, but I would love to get any older version of the system that any of you may have lying around.... There was an early release in Smalltalk, and (I think) one later released with an optimizing compiler as a stand-alone system. Any pointers, ideas, etc. about how and where to find old Selves appreciated. Charles L. Perkins clp@wjh12.harvard.edu From icon-group-request@arizona.edu Tue Dec 12 10:44:20 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA13002; Tue, 12 Dec 89 10:44:20 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA29185; Tue, 12 Dec 89 09:35:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Dec 89 17:34:51 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@tut.cis.ohio-state.edu (Alan D Corre) Organization: University of Wisconsin-Milwaukee Subject: library procedures Message-Id: <1453@uwm.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Chris's useful little input() procedure is a good candidate for a library module. Such modules are very easy to use in v.7 of Icon by compiling with the -c switch and using the link declaration This prompts me to publish a few useful procedures. The version here is for the z-29 terminal, but you can modify it fairly easily. I also have a version for the pc which I can post if someone wants it. I use ANSI mode on the z-29 for a good reason. If you are in ANSI mode already, and you writes the command to switch from ZENITH mode, it is simply ignored, so which ever of the two modes you are in will be fine. Not so if you give the ANSI command to switch to ZENITH mode and you are already in ZENITH! On my installation the system hangs irretrievably, and if you already waited 20 minutes to get on that is pretty frustrating! I dont know why that occurs, but my experience with computers indicates that if something blows up, dont push the button again. Here is the documentation, followed by the code. **** Some of these procedures assume the use of a terminal in ANSI mode. If your terminal is in Zenith mode, it will be switched to ANSI mode and left in that mode. It can be returned to Zenith mode by the use of the setup key. procedure banner(s1,s2..sn) Takes an arbitrary number of strings and places them in a display box on the screen. Strings should be a maximum of 78 characters. procedure instructions(filename) Asks the user if instructions are desired. If so, opens the file "filename" and reads it by screenfuls until ended or user wishes to stop. User is told if file is unavailable. procedure randomize() Sets the random seed to a number determined by the clock time. The seed may be reset to initial value by the statement &random := 0 procedure clear() Clears the screen and puts the cursor in the home position. procedure gotoxy(l,r) Sets the cursor at line l, row r. *** procedure banner(l[]) local n writes("\e<") #go into ansi mode writes("\e[10m") #graphics mode write();write();write() writes(char(102)) #top left right angle writes(repl(char(97),78)) #straight line writes(char(99)) #top right right angle writes(char(96)) #upright line at left writes(right(char(96),79)) #upright line at right every n := 1 to *l do { writes(char(96)) #upright line at left writes("\e[11m",center(l[n],78),"\e[10m",char(96)) #string centered followed by upright line, exit graphics mode for text writes(char(96)) #upright line at left writes(right(char(96),79)) #upright line at right } writes(char(101)) #bottom left right angle writes(repl(char(97),78)) #straight line write(char(100)) #bottom right right angle write("\e[11m") write("Press return to continue.") read() return end procedure instructions(filename) local filvar,counter,line writes("Do you need instructions? y/n ") if upto('yY',read()) then { #The following if-statement fails if the file is not available counter := 0 if filvar := open(filename) then #Read the help file. It's a good idea to keep this kind of info in a #separate file because you can modify it easily without redoing the #program. In general---keep data out of programs! while line := read(filvar) do { #Write out a line and increment the counter write(line) counter +:= 1 #Now we have a screenful; ask if we should continue if counter >22 then { write() writes ("More? y/n ") #User has had enough; break out of loop if upto('nN',read()) then break else #User wants more; reset counter and continue counter := 0}} else #This else goes with the second if-statement; the attempt to open the #help file failed: write("Sorry, instructions not available.")} write ("Press return to continue.") read() #Close the file if it existed and was opened. If it was never opened #the value of filvar will be null. This check has to be made because #an attempt to use close() on a variable NOT valued at a file would #cause an error. See Psalm 130.3 /filvar | close(filvar) end procedure randomize() #extracts the seconds from clock time, and uses the resulting number as seed local clock clock := &clock clock[1:7] := "" &random := clock end procedure clear() #clears the screen writes("\e<\e[2J") end procedure gotoxy(l,r) #sets the cursor at line l, row r writes("\e<\e[",l,";",r,"H") end -- 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@arizona.edu Sat Dec 16 13:42:15 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA14947; Sat, 16 Dec 89 13:42:15 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA14392; Sat, 16 Dec 89 12:33:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Dec 89 20:22:53 GMT From: ns-mx!umaxc.weeg.uiowa.edu!amthor@uunet.uu.net (Geoffrey Amthor) Organization: U of Iowa, Iowa City, IA Subject: WOULD *YOU* BUY A NeXT COMPUTER? (Read even if you wouldn't) Message-Id: <317@ns-mx.uiowa.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Hi. As many of you know, former Apple co-founder Steve Jobs has founded a new company that has produced an advanced personal computer/workstation known as the NeXT computer. This computer has been initially targeted at the university community, with more recent expansion into the mainstream business market. I won't belabor you with the details, but the NeXT computer is viewed as important because of its pioneering application of new technology, an easy interface builder for programmers, and an advanced bundling of both special hardware and software, making the "lowest comon denominator" (to which most developers write applications) rather high. The machine is somewhat controversial, as some are irritated that yet another standard has reached the marketplace, while some others believe the NeXT promises more than it delivers. On the other hand, there is a growing group of NeXT fans who see it as THE platform for the future. Fans and flamers alike share one uncertainty, however: Will the NeXT succeed in the marketplace? I'm not in a position to answer that question, but I CAN tabulate what USENET readers think of the NeXT, and summarize that information for the net. As a graduate student interested in buying a NeXT, I realize that part of what holds me up is my ignorance of what *other* people think of it. My reasoning is this: if most other people aren't even close to buying, the NeXT will fail; if others are held back by mere (fixable) technicalities, the NeXT will likely succeed. Even if you haven't heard of the NeXT, you can help me by at least saying that. Like any survey, this one will benefit from a high percentage of returns--please vote! Of course, since returns are voluntary and readers are preselected by their subscription to USENET, results will be unscientific. But I am certain they will help me, and I WILL SUMMARIZE TO THE NET so that everyone else's curiosity can be satisfied. There are only 10 questions. When multiple choice options are offered, please select as many as apply--but IN ORDER OF PRIORITY. Feel free to add whatever comments you wish, but keep in mind that multiple choice selections are easier to summarize. Also, unless you indicate otherwise, summaries to the net will be ANONYMOUS, so if you secretly love or hate the NeXT, you needn't worry about the secret getting out. PLEASE REPLY BY E-MAIL. Postings will quickly dwarf the net, I may miss your posting, and I will summarize to the net anyway. Be assured that I have no affiliation whatsoever with NeXT or Businessland. Though I am a graduate student at the University of Iowa, this survey does not represent the interest of UI. SURVEY: 1. What is your occupation? 2. What computer(s) do you presently own or use regularly? What other computer(s) do you have actual experience with? 3. What contact have you had with the NeXT computer? A. Never heard of it B. Heard it talked about C. Have seen print ads (name publication) D. Have read articles about it (name publication) E. Have seen one in use or in demonstration (where?) F. Have tried it myself in demo (where?) G. Have used, or borrowed access to it, for some time H. Currently own it or have it provided for my own use I. Other (please specify) 4. How interested are you in purchasing a present or future version of the NeXT, or having your department acquire one for your use? (Specify purchase or department acquisition) A. Not even remotely interested, ever B. Haven't really though about it C. Wouldn't rule it out somday D. Would be interested *if* certain conditions were satisfied E. Would be *very* interested if certain conditions were satisfied F. Am literally ready to buy once certain conditions are met G. Am ready to buy right now H. Already own or have sufficient access to a NeXT I. Other (please specify) 5. If you named conditions in (2), which of the following apply? (Please name only those conditions that are *conditions*, not wish lists.) A. If I can find the money B. If the NeXT comes down in price (How much? Off of university or Businessland prices?) C. If I can get a hands-on look/feel (demo? rent? 30-day guarantee?) D. If color arrives E. If the CPU is upgraded to a 68040 and/or graphics are sped up F. If the floptical drive is made faster G. If the floptical drive is doubled in capacity to 512 MB H. If laser printing can be handled more seamlessly I. If the NeXT can be better integrated with existing equipment (name existing equipment) J. If a 3-1/2" floppy disk drive is bundled K. If a supplemental operating system runs in emulation or via co-processor, or if another UNIX variant runs (name the OS or variant) L. If a certain software category is filled by a high-quality application (name category) M. If a certain software package or language (such as C++) is ported to the NeXT (name item) N. If NeXT applications in general reach a critical mass O. If the NeXTStep interface is improved (name improvement sought) P. If enough NeXTs are sold to make it a "safe" platform Q. If a laptop NeXT arrives R. If a multi-user NeXT arrives (1 cube, several full function inputs that could either be dedicated Megapixel displays or NeXTStep interfaces in non-NeXT boxes. Indicate Megapixel or non-NeXT; if non-NeXT, specify the machine.) S. If IBM, which has licensed the NeXTStep interface, markets it T. If bugs are eliminated in the operating system U. If hardware reliability improves/is proven V. If distribution is widened to include my university (name university) W. If distribution is widened to more commercial vendors (suggest one) X. If my company/university/department endorses it (specify) Y. If customer support is improved (name support sought) Z. If.... (please specify) 6. Which of the above possibilities are not absolute conditions for you, but would carry significant favorable weight in your decision? 7. If you aren't seriously considering acquiring a NeXT in any incarnation, why not? A. Very happy with my own system (please specify) B. Don't have enough (or any) information about NeXT C. Already plan to buy another system (which system?) D. Price of NeXT is prohibitively high E. Don't think the NeXT will ever catch on F. Don't like the user/programmer interface (why not?) G. Require a different primary operating system or UNIX variant (specify OS or variant) H. Hardware is inadequate for needs (what is missing?) I. Have heard too many negative things about NeXT (such as?) J. Think the NeXT is "too much computer" for needs K. Buying a NeXT is politically impossible (why?) L. Other (please specify) 8. Does the NeXT interest you enough that you want to find out more about it? 9. As a computer user, what percent of your interest or time is devoted to end-user computing? To programming? To system administration? To other activities (specify)? How might these percentages change if you acquired a NeXT? 10. What do you think about how the NeXT has been marketed? Any suggestions for improvement? From icon-group-request@arizona.edu Sat Dec 16 19:12:19 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA27249; Sat, 16 Dec 89 19:12:19 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA01476; Sat, 16 Dec 89 18:04:29 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 89 20:56:00 GMT From: pur-phy!tippy!yorkw@ee.ecn.purdue.edu Subject: What is ICON? Message-Id: <134400001@tippy> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Well I have a Basic Question. WHAT IS THE ICON LANGUAGE? I havent been able to get a good idea from these notes. Well just wondering... C-ya. From icon-group-request@arizona.edu Mon Dec 18 17:27:58 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA05157; Mon, 18 Dec 89 17:27:58 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA21885; Mon, 18 Dec 89 16:12:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Dec 89 21:32:58 GMT From: cbmvax!snark!eric@rutgers.edu (Eric S. Raymond) Subject: Re: WOULD *YOU* BUY A NeXT COMPUTER? (Read even if you wouldn't) Message-Id: <1TqpCt#6PkSJw=eric@snark.uu.net> References: <317@ns-mx.uiowa.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In <317@ns-mx.uiowa.edu> Geoffrey Amthor wrote: > Fans and flamers alike share one uncertainty, however: Will the NeXT > succeed in the marketplace? I answered this in email, but I cannot resist the urge to post one question to any NeXT fans reading news. To wit: Why should I buy Steve Jobs's Mac-on-steroids closed-architecture box when I can get cheaper, faster commodity iron with better standards conformance based on the 386? -- Eric S. Raymond = eric@snark.uu.net (mad mastermind of TMN-Netnews) From kwalker Mon Dec 18 18:59:14 1989 Date: Mon, 18 Dec 89 18:59:14 MST From: "Kenneth Walker" Message-Id: <8912190159.AA07877@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA07877; Mon, 18 Dec 89 18:59:14 MST In-Reply-To: <134400001@tippy> To: icon-group Subject: Re: What is ICON? Date: 7 Dec 89 20:56:00 GMT From: pur-phy!tippy!yorkw@ee.ecn.purdue.edu Well I have a Basic Question. WHAT IS THE ICON LANGUAGE? I havent been able to get a good idea from these notes. Well just wondering... The following is my standard reply to that question. Icon is a high level programming language designed for string processing and other non-numeric applications (numeric processing can be done, but the language and implementation are not tuned for it). Goal-directed evaluation with control backtracking is an integral part of the language. However, Icon is very different from other languages, such as Prolog, which use this evaluation scheme. Icon has a rich set of control structures which use and control backtracking. Most of these control structures look and act very much like the control structures of more traditional languages, allowing Pascal-like programming where the full power of goal-directed evaluation is not required. Icon incorporates generators as a natural feature within this goal-directed evaluation scheme. Icon has a flexible run-time type system: variables may take on values of any type and automatic type conversions are preformed as needed by operations. There are a variety of types including strings, sets, associative tables, and lists with positional, queue, and stack access methods. All storage management is automatic; garbage collection is performed as needed. Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 2858 kwalker@cs.arizona.edu {uunet|allegra|noao}!arizona!kwalker From @s.ms.uky.edu:mtbb95@ms.uky.edu Mon Dec 18 20:11:08 1989 Received: from e.ms.uky.edu by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA10320; Mon, 18 Dec 89 20:11:08 MST Received: from s.ms.uky.edu by g.ms.uky.edu id aa11415; 18 Dec 89 22:02 EST From: Bob Maras Date: Mon, 18 Dec 89 22:02:29 EST X-Mailer: Mail User's Shell (6.4 2/14/89) To: Kenneth Walker , icon-group@cs.arizona.edu Subject: Re: What is ICON? Message-Id: <8912182202.aa03359@s.s.ms.uky.edu> Thanks to Ken Walker for a most descriptive summary of the ICON language!!! Bob -- _ _ ( ) __ ( ) | O O | B O B M A R A S / __ \ / ( \/ ) __/ \ \__/ / \____/ |_/\_| H A P P Y C O M P U T I N G !!! From mtbb95@ms.uky.edu Mon Dec 18 20:26:14 1989 Received: from RUTGERS.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA10713; Mon, 18 Dec 89 20:26:14 MST Received: from ukma.UUCP by rutgers.edu (5.59/SMI4.0/RU1.3/3.04) with UUCP id AA21321; Mon, 18 Dec 89 22:25:16 EST Received: from e.ms.uky.edu by g.ms.uky.edu id aa27894; 19 Dec 89 2:57 GMT Received: from s.ms.uky.edu by g.ms.uky.edu id aa11391; 18 Dec 89 21:54 EST From: Bob Maras Date: Mon, 18 Dec 89 21:54:08 EST X-Mailer: Mail User's Shell (6.4 2/14/89) To: tippy!yorkw@newton.physics.purdue.edu, icon-group@arizona.edu Subject: Re: What is ICON? Message-Id: <8912182154.aa02781@s.s.ms.uky.edu> I have really enjoyed following the developments of the ICON language that have been shared with the icon-group. I sort of like the request that was a simple question, "WHAT IS THE ICON LANGUAGE?" It might be of great value if all group recipients could receive a few statementthat share the similarities as well as the differences ICON has with other currently used languages, primarily C, but, also pascal, and even perhaps simpler languages such as BASIC. I think that some of these introductory messages may serve well in the drawing of individuals with programming into the group. Bob -- _ _ ( ) __ ( ) | O O | B O B M A R A S / __ \ / ( \/ ) __/ \ \__/ / \____/ |_/\_| H A P P Y C O M P U T I N G !!! From icon-group-request@arizona.edu Tue Dec 19 14:24:34 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA08601; Tue, 19 Dec 89 14:24:34 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA03973; Tue, 19 Dec 89 13:03:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Dec 89 21:03:47 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@tut.cis.ohio-state.edu (Alan D Corre) Organization: University of Wisconsin-Milwaukee Subject: Library procedures for MS-DOS Message-Id: <1569@uwm.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu By request I am posting the MS-DOS version of the procedures I posted recently for the Zenith terminal. I have added Chris Tenaglia's input procedure, and have gilded his lily by offering a variant, inputl, which insists on a response of a specific length. This can readily be modified to include other determinants, that the response must be an integer, for example. procedure banner(l[]) #Writes to the screen an arbitrary number of strings and encloses them. local n write();write();write() writes(char(201)) #top left right angle writes(repl(char(205),78)) #straight line writes(char(187)) #top right right angle writes(char(186)) #upright line at left writes(right(char(186),79)) #upright line at right every n := 1 to *l do { writes(char(186)) #upright line at left writes(center(l[n],78),char(186)) #string centered followed by upright line writes(char(186)) #upright line at left writes(right(char(186),79)) #upright line at right } writes(char(200)) #bottom left right angle writes(repl(char(205),78)) #straight line write(char(188)) #bottom right right angle write() return end procedure instructions(filename) #writes contents of a file to screen, allows user to stop after any screenful. local filvar,counter,line writes("Do you need instructions? y/n ") if upto('yY',read()) then { #The following if-statement fails if the file is not available counter := 0 if filvar := open(filename) then #Read the help file. It's a good idea to keep this kind of info in a #separate file because you can modify it easily without redoing the #program. In general---keep data out of programs! while line := read(filvar) do { #Write out a line and increment the counter write(line) counter +:= 1 #Now we have a screenful; ask if we should continue if counter >22 then { write() writes ("More? y/n ") #User has had enough; break out of loop if upto('nN',read()) then break else #User wants more; reset counter and continue counter := 0}} else #This else goes with the second if-statement; the attempt to open the #help file failed: write("Sorry, instructions not available.")} write ("Press return to continue.") read() #Close the file if it existed and was opened. If it was never opened #the value of filvar will be null. This check has to be made because #an attempt to use close() on a variable NOT valued at a file would #cause an error. /filvar | close(filvar) end procedure randomize() #deletes the colons from the clock time, and uses the resulting number as seed local clock clock := &clock clock[6] := "" clock[3] := "" &random := clock end procedure clear() #clears the screen writes("\e[2J") end procedure gotoxy(l,r) #sets the cursor at line l, row r writes("\e[",l,";",r,"H") end procedure input(s) #prints the prompt s and returns the user's response writes(s) return read() end procedure inputl(s,n) #prints the prompt s, indicates that the response must be n characters #max, and insists on appropriate response. local ans write(s) writes(n," characters maximum. ") #if ANSI driver is installed omit initial #-sign in following lines # writes("\e[7m\e[s", repl(" ",n),"\e[u\e[0m") #save cursor,reverse video, ##n blanks, restore cursor, normal video while *(ans := read()) > n do { write(s) writes(n," characters maximum. ") # writes("\e[7m\e[s", repl(" ",n),"\e[u\e[0m") } return ans end -- 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@arizona.edu Tue Dec 19 14:33:41 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA08978; Tue, 19 Dec 89 14:33:41 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA05253; Tue, 19 Dec 89 13:23:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Dec 89 21:23:03 GMT From: zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@tut.cis.ohio-state.edu (Alan D Corre) Organization: University of Wisconsin-Milwaukee Subject: Re: What is ICON? Message-Id: <1570@uwm.edu> References: <8912182154.aa02781@s.s.ms.uky.edu> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu In my view, one of the most useful and characteristic features of Icon is the string scanning facility (marked by the question mark "?") which enables strings to be manipulated simply. In my recently published book "Icon Programming for Humanists" I introduced this feature right at the beginning since it can be utilized with a modest understanding of the rest of the language. Another characteristic feature (mentioned recently in this newsgroup) is the fact that results of procedures can be used Boolean fashion, returning something being equivalent to TRUE. There is a difference from Lisp however, in that the return of a null value still counts as a "success". An American visitor to London once commented to me that in that city they erect railings to stop people from crossing the street mid-block. She commented that in America we believe in freedom, so we allow people to cross and kill themselves. Computer languages are a bit like that. Pascal hems you in with railings. Snobol lets your programs blow up. Icon, it seems to me, strikes a good balance between the Germanic coercion of Pascal and the American permissiveness of Snobol. -- 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 gudeman Tue Dec 19 15:02:36 1989 Date: Tue, 19 Dec 89 15:02:36 MST From: "David Gudeman" Message-Id: <8912192202.AA10764@megaron.arizona.edu> Received: by megaron.arizona.edu (5.59-1.7/15) id AA10764; Tue, 19 Dec 89 15:02:36 MST To: icon-group@arizona.edu In-Reply-To: (Alan D Corre's message of 19 Dec 89 21:23:03 GMT <1570@uwm.edu> Subject: What is ICON? From: zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!corre@tut.cis.ohio-state.edu (Alan D Corre) An American visitor to London once commented to me that in that city they erect railings to stop people from crossing the street mid-block. She commented that in America we believe in freedom, so we allow people to cross and kill themselves. In London, perhaps people respect railings. In America we believe in freedom, so we would jump over or go under :-). From spqr%ecs.southampton.ac.uk@NSFnet-Relay.AC.UK Wed Dec 20 02:34:36 1989 Received: from NSFNET-RELAY.AC.UK by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA09720; Wed, 20 Dec 89 02:34:36 MST Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa02097; 20 Dec 89 9:24 GMT Received: from alonzo.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Wed, 20 Dec 89 09:32:46 GMT From: Sebastian P Q Rahtz Date: Wed, 20 Dec 89 09:31:46 GMT Message-Id: <539.8912200931@alonzo.ecs.soton.ac.uk> To: icon-group@arizona.edu In-Reply-To: David Gudeman's message of Tue, 19 Dec 89 15:02:36 MST <8912192202.AA10764@megaron.arizona.edu> Subject: Re: What is ICON? > An American visitor to London once commented to me that in that city > they erect railings to stop people from crossing the street mid-block. > She commented that in America we believe in freedom, so we allow > people to cross and kill themselves. I have to tell you, from these wet and wild shores, that we don't have blocks on our streets. our permissiveness and freedom is such that most of out cities are built higgledy-piggledy. We also tend to have traffic lights that simply go green, rather than instructing pedestrians to WALK. Icon, of course, is neither wet nor higgledy-piggledy; it always strikes me when I defend or describe it that one of the joys is that fact that it has a specific origin, namely Arizona and Ralph Griswold. Of course lots of people have worked on it, but there is still a feeling that a small group is looking after the language because they care, not to make money or satisfy a committee. We'll know to give up when ISO appoint an Icon committee! Sebastian Rahtz S.Rahtz@uk.ac.soton.ecs (JANET) Computer Science S.Rahtz@ecs.soton.ac.uk (Bitnet) Southampton S09 5NH, UK S.Rahtz@sot-ecs.uucp (uucp) From icon-group-request@arizona.edu Wed Dec 20 18:31:34 1989 Received: from ucbvax.Berkeley.EDU by megaron.arizona.edu (5.59-1.7/15) via SMTP id AA04726; Wed, 20 Dec 89 18:31:34 MST Received: by ucbvax.Berkeley.EDU (5.61/1.40) id AA13135; Wed, 20 Dec 89 17:22:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for icon-group@arizona.edu (icon-group@arizona.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Dec 89 20:39:53 GMT From: gvlv2!imagine!chris@burdvax.prc.unisys.com (Chris Sterritt) Organization: Unisys/Automated Document Management Systems, Radnor, PA Subject: ICON wanted Message-Id: <179@imagine.ADMS-RAD.Unisys.COM> Sender: icon-group-request@arizona.edu To: icon-group@arizona.edu Hello, I (and a friend not on the net) would like to get the icon language for various machines. I would appreciate finding out where to FTP source and/or binaries for SUNs, Macs, and AT&T 3b1. Please reply to me directly, and I'll summarize to the net if there's enough interest. I apologize if it's out of line to make this request on this group, however I don't know where else to find this out. thanks very much in advance, chris sterritt chris@adms-rad.unisys.com