From icon-group-sender Tue Sep 19 03:20:42 1995 Received: by cheltenham.cs.arizona.edu; Tue, 19 Sep 1995 08:37:13 MST To: icon-group@cs.arizona.edu Date: 19 Sep 1995 03:20:42 GMT From: ggraham@crchha98.bnr.ca (Gregory Graha) Message-Id: Organization: Bell Northern Research, Richardson, TX. Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu>, Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In article oakley@healthcare.com (Bryan Oakley) writes: In article <43d0g9$aal@magus.cs.utah.edu>, carr@fast.cs.utah.edu (Harold Carr) wrote: > What do programmers who implement and use real programming languages > like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or > PERL? > > (sounds like a straight line but I am really asking) > > Harold Uh, Lisp, Prolog, Smalltalk, Eiffel, and Icon? On a more serious note, what makes you think that users of Lisp, etc. *don't* use TCL or PERL? What exactly do you mean by "use instead of TCL or PERL"? Use for what? Programming? Perhaps they also use the Korn or Bourne shell, python, C, FORTRAN, COBOL, awk, hypercard, and the list goes on and on. A valid issue to discuss, however, has to do with the fact that Tcl and Perl were pretty much designed to enhance the C/Unix programming environment. Their existance is a testement to the fact that C was considered not suitable for the tasks Tcl and Perl were invented for. Tcl was designed to provide a way to imbed a scripting language into a tool so that the tool could be customized by the user without digging into the C code and recompiling. Although I am new to Smalltalk, the impression I get is that tools in a Smalltalk environment are customized in Smalltalk. The browser makes it easier to deal with the source, and subclassing makes it easier to reuse and customize. Also, the interactive nature of Smalltalk is similar to Tcl. Perl was designed to provide a lot of the high level tools that C lacks, and to provide an interactive programming environment that is more productive for quick jobs than compiled C. Again, these are areas where Smalltalk already excels, with its rich class library and interactive programming environment. Now, I will admit that Tcl and Perl, have definately grown beyond their original vision, and people are using them for all kinds of things. Also, I know that Smalltalk is not the end-all, and there will be cases where a Smalltalk programmer might want to use something like Tcl or Perl. But in general, I think a Smalltalk programmer would have less need for these kinds of tools than a C/C++ programmer. -- Greg Graham ggraham@bnr.ca From icon-group-sender Tue Sep 19 14:06:47 1995 Received: by cheltenham.cs.arizona.edu; Tue, 19 Sep 1995 08:37:35 MST To: icon-group@cs.arizona.edu Date: 19 Sep 1995 14:06:47 GMT From: "George J. Carrette" Message-Id: <43mipn$d53@news1.delphi.com> Organization: Genuine Internet Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu carr@fast.cs.utah.edu (Harold Carr) wrote: > > >What do programmers who implement and use real programming languages >like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL? The answer is: C Lisp programmers were always assembly language programmers at heart. From icon-group-sender Tue Sep 19 20:22:13 1995 Received: by cheltenham.cs.arizona.edu; Wed, 20 Sep 1995 09:17:47 MST To: icon-group@cs.arizona.edu Date: 19 Sep 1995 20:22:13 GMT From: corre@alpha1.csd.uwm.edu (Alan D Corre) Message-Id: <43n8pl$u1i@uwm.edu> Organization: Information & Media Technologies, University of Wisconsin - Milwaukee Sender: icon-group-request@cs.arizona.edu Subject: ProIcon Errors-To: icon-group-errors@cs.arizona.edu I recently completed a program written in ProIcon for the Macintosh computer to help students study foreign language texts. I said: "John, let's transfer this to your machine, so that you can put it on the system for the kids to try out." Now in that program there was a line: filename := getfile("Text to study? ",,"Greek_Texts") which looks into a folder containing the various texts available and allows the user to choose a text for study. For some reason, when the program was transferred, instead of displaying the names of the texts, it accessed a folder higher up, revealing, like the Calvin Klein ads, things that students are not supposed to think about, let alone actually see. Of course, this is no problem for a seasoned Mac user. A few shakes of the mouse's tail, and you can navigate to the folder you need. But this can be confusing for untutored students, and is, in any case, inelegant. I said: "That's funny. That wasn't happening on my machine." John said: "That's because you have a slightly older version of the system software. I just installed the upgrade, and those things don't work the way they used to. It has happened to all my programs too." (He does not use Icon.) Hallelujah. Apple, as usual, "improves" its software and causes you all kinds of agony. I am always amused when computer companies talk about "enhancement" of their software, which is an euphemistic way of saying that they have taken bugs out of their software, put in new ones, and are charging you $89 for the privilege. I said: "What do you suggest I do?" He said: "I have had to build my own lists, and you can probably do the same." So I went back to the drawing board at this eleventh hour and wrote: fnm := gettext("Enter name of text: " || filegen(1),"","","") .......... procedure filegen(n) local fold,fnm,str #initialize str to zero length string str := "" #treat digits as chars to avoid possible system intervention if n == "1" then fold := "Greek_Texts" else if n == "2" then fold := "Hebrew_Texts" else if n == "3" then fold := "Other_Texts" else stop("Problem in filegen") #generate and catenate filenames every fnm := file(fold) do str ||:= (fnm || "; ") #remove last semicolon and space str[0:-2] := "" return str end #filegen This corrected the problem, but causes extra work for the unfortunate students, who are harried enough already. A while ago I expressed on this newsgroup some unhappiness with the Apple system, which evoked a huffy letter from Apple. But I suppose the fact is that as things get more complicated, it is difficult to check out every side effect of what you change. A reminiscence. Around 1980 I was traveling in Belgium and saw a book on Ap-L-Isp in French on a station newsagent's stall. I had been using this Lisp on the Apple II+, so I bought the book, and found it quite informative. I rather liked Ap-L-Isp. Of course, it had some limitations. For example, it was limited to upper case letters, but as a Hebraist I appreciated that. (Hebrew has only upper case letters. Or mebbe it has only lower case letters. Who knows?) I think the human race lost an opportunity to dump our silly habit of capitalizing when computers came in, but we muffed it. english, french and german All have different capitalization rules, and all of them serve only to torture school children. But that is neither here nor there. When the Apple IIE came in, Apple claimed that it would run II+ software. But I want to tell you that Ap-L-Isp went looking for its cars in the wrong garage, and was dead in the water. You couldn't get it to work at all on the IIE. I'm glad I am a hebraist (or is it Hebraist) rather than a computer scientist. The Hebrew Bible has been around for thousands of years, and that nice book on Lisp did not last even a thousand days. Another thing about the IIE. If I had had the ability of Keats, I would have written a poem entitled: "On First Looking into Ken Bowles' Apple Pascal." ...Then felt I like some watcher of the skies/When a new planet swims into his ken... I had been using Pascal on the Univac 1100, and the speed and ease of Apple Pascal was unbelievable. No more typing in IBM cards to correct a little error! Apple Pascal came in four 5.25 disks, and you could run it with one or two disk drives. When the IIE came along, Apple Pascal worked fine with two disk drives, but would not work properly with one any more! Apparently it did not occur to them that anyone was still using one disk drive. Well, the University of Wisconsin-Milwaukee is no Yale University (in funding, I mean. Not sure that the education is all that different.) And there was not enough money to buy that extra disk drive at UWM. So... The French have a saying: "Plus ca change, plus c'est la meme chose." "The more it changes, the more it's the same thing." Don't apply to operating systems. Plus ca change, plus c'est un pain dans le neck. -- Alan D. Corre Emeritus Professor of Hebrew Studies University of Wisconsin-Milwaukee From icon-group-sender Wed Sep 20 14:05:16 1995 Received: by cheltenham.cs.arizona.edu; Wed, 20 Sep 1995 09:18:09 MST To: icon-group@cs.arizona.edu Date: Wed, 20 Sep 1995 14:05:16 +0200 From: "Maarten v. Casteren" Message-Id: Organization: University of Nijmegen, The Netherlands Sender: icon-group-request@cs.arizona.edu Subject: change Table's default Errors-To: icon-group-errors@cs.arizona.edu Is there a method to change the default value a table returns without building a completely new table, creating it with table(default)? I did try something like tab[&null] := default-value , but this doesn't work. Maarten van Casteren casteren@mpi.nl From icon-group-sender Wed Sep 20 00:51:45 1995 Received: by cheltenham.cs.arizona.edu; Wed, 20 Sep 1995 09:17:59 MST To: icon-group@cs.arizona.edu Date: Wed, 20 Sep 1995 00:51:45 GMT From: nagle@netcom.com (John Nagle) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu>, <43mipn$d53@news1.delphi.com> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu "George J. Carrette" writes: >carr@fast.cs.utah.edu (Harold Carr) wrote: >>What do programmers who implement and use real programming languages >>like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL? Either Visual Basic or Java is a decent choice for little programs. John Nagle From icon-group-sender Wed Sep 20 18:39:53 1995 Received: by cheltenham.cs.arizona.edu; Thu, 21 Sep 1995 09:41:53 MST To: icon-group@cs.arizona.edu Date: 20 Sep 1995 18:39:53 GMT From: jmc0@roger.gte.com (John Chambers) Message-Id: <43pn5p$e83@ceylon.gte.com> Organization: GTE Laboratories Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu>, <43fgn3$1g4@nntp.crl.com>, Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In article tgg@hplb.hpl.hp.com () writes: >J.M. Ivler (ivler@crl.com) wrote: > >|Consider the programmer as a carpenter. He has to sink a screw. Now he could >|use a hammer to sink it, and it would work, but it would work much better >|if he used a screwdriver. Additionally, the screw is a philips head. Now >|he could use a flathead screwdriver, but wouldn't the better tool be a >|philipshead screwdriver? Now, if he had only one screw to sink, he might >|use a hand screwdriver, but he has 1000, so might it not be wise to >|attach a philipshead screwdriver to a powertool to help? > >Carpenters often _do_ use hammers to insert screws; they hit them in for most >of the distance and then screw them in for only the last 1cm or so. Much >faster, and it works! > >Know your tools, and use the appropriate _mix_ of tools! As an example of yet another logical fallacy in the presuppositions implied above: Carpenters who have square-drive bits very often use them to drive (mostly remove ;-) Phillips screws. The smaller square bits fit quite well into a Phillips screw's slots, and unlike the Phillips bits, they don't tend to pop out so easily. If you are trying to remove a stuck or damaged screw, the square bit will usually work better than the Phillips bit. This is an example of the fallacy in the "obvious" advice to use the appropriate tool for the job. Few people would consider mixing bits like this to be "appropriate" (in the usual sense of the term). But this is an example where the "wrong" tool actually does a better job than the "right" tool. To be more accurate, this is a case in which tool X does tool Y's job better than tool Y does, despite the fact that X wasn't designed to do Y's job. Similar examples abound in the computing world. Thus, csh was designed as a C-like scripting language; it was supposed to be better for writing scripts than sh. There have been a lot of summaries posted explaining why 1) (k)sh is a better scripting tool than csh, and 2) csh is a better interactive shell than (k)sh. This is exactly the opposite to what you'd expect from their design goals. Another curious example I ran across a few years back: I did a speed test comparing various file-transfer packages across various networks. One of the results was that, when uucp worked across tcp, it beat out ftp by a *factor* of 3 to 4. Now, uucp was designed to work across poor-quality links like modems and phone lines; the tcp driver was a late add-on. On the other hand, ftp was designed to run on tcp. So how does uucp beat ftp so badly on ftp's "home court"? A 10% difference wouldn't be worth noticing, but how did ftp's authors blow the job so badly as to lose by more than a factor of 2? (Not only that, but you don't have to hold uucp's hand like you do with ftp; it keeps trying until it succeeds, and optionally tells you when it's done. So despite the fact that it's not interactive, it's much more user-friendly than the interactive ftp. Of course, ftp's problems won't be fixed, due to the unwillingness of the Internet crowd to learn anything from things like uucp. ;-) The computer industry is full of examples of tools that do their job poorly, while a tool not designed for the job does it better. -- if (HEART(getenv("USER"),'C')) printf("Honk!\n"); print "Honk!\n" if &HEART($ENV{'USER'},'perl'); if {[HEART $env(USER)] == {tcl}} {button .h -text honk ; pack .h} YOU 4TH HEART IF HONK THEN From icon-group-sender Thu Sep 21 00:38:11 1995 Received: by cheltenham.cs.arizona.edu; Thu, 21 Sep 1995 09:42:05 MST To: icon-group@cs.arizona.edu Date: 21 Sep 1995 00:38:11 GMT From: msfriedm@bingster.us.oracle.com (Mark S. Friedman) Message-Id: Organization: Oracle Corporation. Redwood Shores, CA Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu>, <43mipn$d53@news1.delphi.com> Reply-To: msfriedm@us.oracle.com Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In article nagle@netcom.com (John Nagle) writes: * >carr@fast.cs.utah.edu (Harold Carr) wrote: * >>What do programmers who implement and use real programming * >>languages like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use * >>instead of TCL or PERL? * * Either Visual Basic or Java is a decent choice for little programs. Tcl is an embeddable scripting language. Perl is mainly a system administration and shell script language. Both are primarily Unix based. In what sense are Visual Basic or Java appropriate for the typical uses of Tcl or Perl? To start with, Visual Basic runs only on PC's and Java isn't even in Beta yet! -Mark -- Mark Friedman msfriedm@us.oracle.com Oracle Corporation 500 Oracle Parkway Box 659410 Redwood Shores, CA 94065 The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. From icon-group-sender Thu Sep 21 18:30:48 1995 Received: by cheltenham.cs.arizona.edu; Thu, 21 Sep 1995 12:21:05 MST To: icon-group@cs.arizona.edu Date: 21 Sep 1995 18:30:48 GMT From: Paul Gipson Message-Id: <43sb0o$d01@murrow.corp.sgi.com> Organization: Silicon Graphics Ltd Sender: icon-group-request@cs.arizona.edu Subject: Icon V6 Errors-To: icon-group-errors@cs.arizona.edu Is there, was there an ICON V6 ?? If so is it still available on the net ? Thanks in advance Paul -- .......................................................................... Paul Gipson . Opinions are mine, . Sales Support Mgr, High Performance Systems. not my paymaster's. . Email: paul@reading.sgi.com . . Tel: +44-1734-257618 (direct) . Cracking Toast, Gromit ! . Voicemail: +44-1734-257501 (7618#) . . Fax: +44-1734-257699 . . URL: http://reality.sgi.com/employees/paul_reading . .......................................................................... From icon-group-sender Thu Sep 21 16:28:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 21 Sep 1995 16:20:18 MST Message-Id: <199509212030.QAA12821@transfer.stratus.com> Date: Thu, 21 Sep 95 16:28 EDT From: Steve_Graham@vos.stratus.com To: icon-group@cs.arizona.edu Cc: Steve_Graham@vos.stratus.com Subject: Questions on map() and / Errors-To: icon-group-errors@cs.arizona.edu I have been using Icon Version 8.8 recently for some file cleanup and verification and I really enjoy the ease with which it allows me to accomplish my objectives. I have been able to figure out most of my questions with the aid of the accompanying documentation and by reading/posting questions to the newsgroup. questions have to do with the following code fragment: # Add line number to citations for word # procedure tabulate(word) /uses[word] := table() uses[word][lineno] := 1 return end # Generate words # procedure words() while line := read() do { lineno +:= 1 write(right(lineno,6)," ",line) map(line) ? while tab(upto(&letters)) do { s := tab(many(&letters)) if *s < 3 then next # skip short words suspend s } } end What does the / in /uses mean? What does function does map serve? Thanks in advance. Steve Graham Steve Graham@vos.stratus.com From icon-group-sender Fri Sep 22 12:41:15 1995 Received: by cheltenham.cs.arizona.edu; Fri, 22 Sep 1995 09:39:03 MST To: icon-group@cs.arizona.edu Date: 22 Sep 1995 12:41:15 GMT From: snowball@se.cuhk.hk (Project Snowball) Message-Id: <43uatb$at1@eng_ser1.erg.cuhk.hk> Organization: Engineering Faculty CUHK Sender: icon-group-request@cs.arizona.edu Subject: Icon V9 implementation Errors-To: icon-group-errors@cs.arizona.edu Hi, Our project group is implementing a chinese compatible icon compiler. Our implementation is based on the vitual stack machine of the original icon interpreter but we found that it is not very efficient comparing with the original icon compiler. Is there anyone know how the icon compiler was build? Is it still based on the virtual stack machine as the interpreter or there is better representation? And where can we find more information on icon compiler implementation? Thanks. Project snowball Department of systems engineering The Chinese University of Hong Kong From icon-group-sender Fri Sep 22 14:17:59 1995 Received: by cheltenham.cs.arizona.edu; Fri, 22 Sep 1995 09:39:44 MST To: icon-group@cs.arizona.edu Date: 22 Sep 1995 14:17:59 GMT From: copydata@infi.net (Mike McCoy-Sys. Admin) Message-Id: <43ugin$dbm@allnews.infi.net> Organization: Copy Data Group Sender: icon-group-request@cs.arizona.edu Subject: Binaries For SCO Errors-To: icon-group-errors@cs.arizona.edu Does anyone know if there are ICON binaries for SCO v4.2? If so, where? Thanks ! From icon-group-sender Sun Sep 24 15:37:46 1995 Received: by cheltenham.cs.arizona.edu; Mon, 25 Sep 1995 09:39:08 MST To: icon-group@cs.arizona.edu Date: 24 Sep 1995 15:37:46 GMT From: espie@lotus.ens.fr (Marc Espie) Message-Id: <443u0a$3f0@nef.ens.fr> Organization: Ecole Normale Superieure, PARIS, France Sender: icon-group-request@cs.arizona.edu Subject: Makefiles and icon Errors-To: icon-group-errors@cs.arizona.edu First, un unrelated apology, for my previous post which was blatantly out of place, I won't do it again sorry. Then, a question. I've got a rather big project in Icon, and I would like my source files to be in several subdirectories, the whole coordinated by one Makefile. So far, I have, let's say: AVERELL_OBJS = averell/get_value.u1 \ averell/draw_segment.u1 \ util/comments.u1 \ util/congruence.u1 \ util/cc.u1 \ averell/std_congr.u1 \ averell/averell.u1 averell: $(AVERELL_OBJS) icont -o $@ -u $(AVERELL_OBJS) .icn.u1: icont -c -s $* .SUFFIXES: .u1 .icn the main problem is that icont does build object files in the main directory, that is averell/get_value.icn -> get_value.u[12], NOT averell/get_value.u[12]. I can always get it back in order by wedging a shell script between the Makefile and icont that builds the object file in the correct directory, but I keep wondering if I'm not missing something. A Makefile local to each directory seems a bit heavy, and using link declarationss is somewhat inappropriate since all parts of the project are liable to change. Any ideas ? -- [nosave] microsoft network is EXPLICITLY forbidden to redistribute this message. `Moon purismu powa, make up.... Tsuki ni kawatte, oshiokyo !' Marc Espie (Marc.Espie@ens.fr) From icon-group-sender Mon Sep 25 14:49:44 1995 Received: by cheltenham.cs.arizona.edu; Mon, 25 Sep 1995 09:39:41 MST To: icon-group@cs.arizona.edu Date: Mon, 25 Sep 1995 14:49:44 GMT From: gmb@onions.natcorp.ox.ac.uk (Glynis Baguley) Message-Id: <1995Sep25.144944.9349@onionsnatcorp.ox.ac.uk> Organization: British National Corpus, Oxford University, GB Sender: icon-group-request@cs.arizona.edu Subject: Icon on-line help Errors-To: icon-group-errors@cs.arizona.edu I tried to get the on-line reference manual at http://www.cs.arizona.edu/icon/www/reference.html and got an error. Can anyone tell me if it's moved or gone? Thanks -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ { Glynis.Baguley@oucs.ox.ac.uk } { Oxford University Computing Services } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From icon-group-sender Mon Sep 25 10:29:30 1995 Received: by cheltenham.cs.arizona.edu; Mon, 25 Sep 1995 12:34:53 MST Date: Mon, 25 Sep 1995 10:29:30 -0700 From: Gregg Townsend Message-Id: <9509251729.AA06258@hawk.CS.Arizona.EDU> To: icon-group@cs.arizona.edu Subject: Re: Questions on map() and / Cc: Steve_Graham@vos.stratus.com Errors-To: icon-group-errors@cs.arizona.edu From: Steve_Graham@vos.stratus.com procedure tabulate(word) /uses[word] := table() uses[word][lineno] := 1 return end What does the / in /uses mean? It means "uses[word], if null". The first time a word is seen, a table must be created for that word. This checks for that situation, indicated by a null entry for uses[word], and assigns a new table to that slot in "uses". ... map(line) ? while tab(upto(&letters)) do { ... What does function does map serve? Map transliterates characters like the "tr" utility of Unix. With default parameters, it translates upper case characters into lower case. The purpose of this is to make the program case-insensitive. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Mon Sep 25 10:59:36 1995 Received: by cheltenham.cs.arizona.edu; Mon, 25 Sep 1995 12:35:07 MST Date: Mon, 25 Sep 1995 10:59:36 -0700 From: Gregg Townsend Message-Id: <9509251759.AA07040@hawk.CS.Arizona.EDU> To: snowball@se.cuhk.hk Subject: Re: Icon V9 implementation Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu From: snowball@se.cuhk.hk (Project Snowball) Is there anyone know how the icon compiler was build? Is it still based on the virtual stack machine as the interpreter or there is better representation? And where can we find more information on icon compiler implementation? Thanks. Ken Walker's dissertation describes the implementation in detail. It is published as Technical Report 91-16 by the University of Arizona's Department of Computer Science. Contact the TR librarian (tr-libr@cs.arizona.edu) for information about obtaining a copy. The source code for the compiler is included in the Unix distribution package for Icon. I should maybe add a warning that the Icon group's efforts have mostly focused on the interpreter lately. The compiler by its very nature is much more complex and you don't want to mess with it unless you *really* need to. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Mon Sep 25 13:48:52 1995 Received: by cheltenham.cs.arizona.edu; Mon, 25 Sep 1995 16:25:18 MST Date: Mon, 25 Sep 1995 13:48:52 -0700 From: Gregg Townsend Message-Id: <9509252048.AA08850@hawk.CS.Arizona.EDU> To: gmb@onions.natcorp.ox.ac.uk, icon-group@cs.arizona.edu Subject: Re: Icon on-line help Errors-To: icon-group-errors@cs.arizona.edu From: gmb@onions.natcorp.ox.ac.uk (Glynis Baguley) I tried to get the on-line reference manual at http://www.cs.arizona.edu/icon/www/reference.html and got an error. Can anyone tell me if it's moved or gone? It's moved to: http://www.cs.arizona.edu/icon/www/reference/ref.html (There actually is a simple page at the old location that says that; you shouldn't have received an error.) Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Mon Sep 25 17:44:47 1995 Received: by cheltenham.cs.arizona.edu; Mon, 25 Sep 1995 16:25:28 MST To: icon-group@cs.arizona.edu Date: Mon, 25 Sep 1995 17:44:47 GMT From: mufti@pls.com (Saad Mufti) Message-Id: <1995Sep25.174447.23298@pls.com> Organization: Personal Library Software, Inc. Sender: icon-group-request@cs.arizona.edu References: <43mipn$d53@news1.delphi.com>, , Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In article , Mark S. Friedman wrote: >In article nagle@netcom.com (John Nagle) writes: > >* >carr@fast.cs.utah.edu (Harold Carr) wrote: > >* >>What do programmers who implement and use real programming >* >>languages like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use >* >>instead of TCL or PERL? >* >* Either Visual Basic or Java is a decent choice for little programs. > >Tcl is an embeddable scripting language. Perl is mainly a system >administration and shell script language. Both are primarily Unix >based. In what sense are Visual Basic or Java appropriate for the >typical uses of Tcl or Perl? > >To start with, Visual Basic runs only on PC's and Java isn't even in >Beta yet! > A good very high level object oriented language that offers a good compromise b/w scripting and general purpose development and is not too Unix specific is Python. Visit http://www.python.org/ for more info. To my knowledge, Python has stable ports on all sorts of Unix platforms as well as Windows, Windows/NT and Macs. ------------------------- Saad Mufti Personal Library Software From icon-group-sender Tue Sep 26 02:47:21 1995 Received: by cheltenham.cs.arizona.edu; Tue, 26 Sep 1995 06:29:33 MST To: icon-group@cs.arizona.edu Date: 26 Sep 1995 02:47:21 GMT From: Charles Richmond Message-Id: <447pjp$f2c@dns.plano.net> Organization: Canine Computer Center Sender: icon-group-request@cs.arizona.edu References: <1995Sep25.144944.9349@onionsnatcorp.ox.ac.uk> Subject: Re: Icon on-line help Errors-To: icon-group-errors@cs.arizona.edu gmb@onions.natcorp.ox.ac.uk (Glynis Baguley) wrote: >I tried to get the on-line reference manual at > The reference manual is now reachable via the following URL: http://www.cs.arizona.edu/icon/www/reference/ref.html From icon-group-sender Tue Sep 26 08:24:17 1995 Received: by cheltenham.cs.arizona.edu; Tue, 26 Sep 1995 10:34:17 MST Date: Tue, 26 Sep 1995 08:24:17 -0700 From: kwalker@sirtur.premenos.com (Ken Walker) Message-Id: <9509261524.AA18067@sirtur.sirtur.premenos.com> To: snowball@se.cuhk.hk Subject: Re: Icon V9 implementation Cc: icon-group@cs.arizona.edu X-Sun-Charset: US-ASCII Errors-To: icon-group-errors@cs.arizona.edu > From: Gregg Townsend > To: snowball@se.cuhk.hk > > The source code for the compiler is included in the Unix distribution > package for Icon. I should maybe add a warning that the Icon group's > efforts have mostly focused on the interpreter lately. The compiler > by its very nature is much more complex and you don't want to mess with > it unless you *really* need to. If you do decide to look more at the compiler and have questions that are not addressed in TR 91-16, I can try to answer them for you. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Tue Sep 26 16:25:06 1995 Received: by cheltenham.cs.arizona.edu; Tue, 26 Sep 1995 12:21:37 MST To: icon-group@cs.arizona.edu Date: Tue, 26 Sep 1995 16:25:06 GMT From: gmb@natcorp.ox.ac.uk (Glynis Baguley) Message-Id: <1995Sep26.162506.10714@onionsnatcorp.ox.ac.uk> Organization: British National Corpus, Oxford University, GB Sender: icon-group-request@cs.arizona.edu References: <1995Sep25.144944.9349@onionsnatcorp.ox.ac.uk>, <447pjp$f2c@dns.plano.net> Subject: Re: Icon on-line help Errors-To: icon-group-errors@cs.arizona.edu In article <447pjp$f2c@dns.plano.net> Charles Richmond writes: > gmb@onions.natcorp.ox.ac.uk (Glynis Baguley) wrote: > >I tried to get the on-line reference manual at > > > The reference manual is now reachable via the following URL: > > http://www.cs.arizona.edu/icon/www/reference/ref.html Thanks everyone! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ { Glynis.Baguley@oucs.ox.ac.uk } { Oxford University Computing Services } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From icon-group-sender Tue Sep 26 21:41:40 1995 Received: by cheltenham.cs.arizona.edu; Wed, 27 Sep 1995 08:56:28 MST To: icon-group@cs.arizona.edu Date: 26 Sep 1995 21:41:40 GMT From: Tom Christiansen Message-Id: <449s2k$hu8@csnews.cs.colorado.edu> Organization: scant Sender: icon-group-request@cs.arizona.edu References: <43mipn$d53@news1.delphi.com>, , Reply-To: tchrist@mox.perl.com (Tom Christiansen) Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu :-> In comp.lang.tcl, msfriedm@us.oracle.com writes: :Tcl is an embeddable scripting language. Perl is mainly a system :administration and shell script language. Both are primarily Unix :based. In what sense are Visual Basic or Java appropriate for the :typical uses of Tcl or Perl? : :To start with, Visual Basic runs only on PC's and Java isn't even in :Beta yet! Perl is used for CGI scripting and general tools work, and runs not just on Unix, but also VMS, MVS, MsDOS, NT, Amigas, Macs, and many other systems as well. I would not say its use is restricted to Unix sysadmins, and if you haven't looked at it in the last five years, then you are probably working under some misunderstandings about the language. --tom From icon-group-sender Wed Sep 27 16:35:39 1995 Received: by cheltenham.cs.arizona.edu; Wed, 27 Sep 1995 15:36:16 MST From: diaz@Uni.Rain.NI (Jose Leonidas Diaz Chow) Message-Id: <9509272235.AA02189@tango.uni.rain.ni> Subject: About Artificial Intelligence To: icon-group-sender@cs.arizona.edu Date: Wed, 27 Sep 95 16:35:39 CST X-Mailer: ELM [version 2.3 PL0] Errors-To: icon-group-errors@cs.arizona.edu -- Hi, Everybody I am looking for material and information about works related to artificial intelligence and/or expert systems developed in Icon. Does somebody there have done something in this way? May send me a little information about it, specifically the subject, area or application field and how much facilities does Icon offer in the implementation of such programs. Thanks in advance. Any help would be highly appreciated. Regards, _____________________________________________________________________ Xdc. Jose Leonidas Diaz Chow Dept. Arquitectura de Sistemas universidad Nacional de Ingenieria Telf: 492695 (082)534 e-mail : diaz@tango.uni.rain.ni _____________________________________________________________________ From icon-group-sender Fri Sep 29 10:47:52 1995 Received: by cheltenham.cs.arizona.edu; Fri, 29 Sep 1995 07:05:32 MST To: icon-group@cs.arizona.edu Date: Fri, 29 Sep 95 10:47:52 PDT From: csts Message-Id: Organization: NetVision LTD. Sender: icon-group-request@cs.arizona.edu Subject: Looking for a Tutorial for ICON Errors-To: icon-group-errors@cs.arizona.edu Hi there ~~~~~~~~ I'm new to ICON and am looking for a tutorial. Where can I find a tutorial I can download and read on my computer at home ? Pre-Thanks ~~~~~~~~~~ Yaniv From icon-group-sender Fri Sep 29 12:59:53 1995 Received: by cheltenham.cs.arizona.edu; Fri, 29 Sep 1995 07:05:53 MST To: icon-group@cs.arizona.edu Date: 29 Sep 1995 12:59:53 GMT From: qbchsod@ebcw131.ericsson.se (Soderstrom Hakan) Message-Id: Organization: Ericsson Business Networks AB Sender: icon-group-request@cs.arizona.edu Subject: Q: icont error message Errors-To: icon-group-errors@cs.arizona.edu I took a *working* program from an Icon 8.9 environment and tried to run it in a 9.0 environment. Now it wouldn't compile; icont complains: pltodb.icn: Line 85 # :"d_bname": no record having this field is ever created pltodb.icn: Line 86 # :"ie_short": no record having this field is ever created pltodb.icn: Line 96 # :"d_bname": no record having this field is ever created What!? I can't understand how icont arrives at this conclusion. There are plenty of record-creating instances in the code. Line 85 contains this construct: every (dsc := (!(ie_t|iegr_t))).d_bname == ie_type_name do { i.e. a simple search through two tables for a record whose d_bname field matches a certain string. Besides, the identical source code worked fine and produced the expected results in the previous version of Icon. Any light on this out there? Platform: Sun SPARC under SunOS 4.1.4, Icon Interpreter Version 9.0. July 16, 1994. -- ---------------------------------------------------------------------- Hakan Soderstrom (contractor) | qbchsod@ebc.ericsson.se | Memo: EXTR.QBCHSOD Ericsson Business Networks AB | Voice: +46 8 422 0616 NA/EBC/FB/TV | S-13189 Stockholm, SWEDEN | Fax: +46 8 422 0630 From icon-group-sender Fri Sep 29 15:00:34 1995 Received: by cheltenham.cs.arizona.edu; Fri, 29 Sep 1995 12:29:27 MST To: icon-group@cs.arizona.edu Date: Fri, 29 Sep 1995 15:00:34 GMT From: npg@demon.net (Nic Gibson) Message-Id: <812386834.3216@nic.demon.net> Organization: Demon Internet Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Q: icont error message Errors-To: icon-group-errors@cs.arizona.edu In article , qbchsod@ebcw131.ericsson.se (Soderstrom Hakan) says... > >I took a *working* program from an Icon 8.9 environment and tried to run >it in a 9.0 environment. Now it wouldn't compile; icont complains: > >pltodb.icn: Line 85 # :"d_bname": no record having this field is ever created >pltodb.icn: Line 86 # :"ie_short": no record having this field is ever created >pltodb.icn: Line 96 # :"d_bname": no record having this field is ever created > OK. I *think* there was a change in the errors/warnings between 8 & 9. Anyway, as far as I remember what icont is actually saying is that you never defined the record. It's looking for a "record x(a, b, c)" type declaration. Of course, I may be wrong :) Nic -- ----------------------------------------------------------------------- Nic Gibson Demon Internet Work: npg@demon.net Home: nic@skin.demon.co.uk ----------------------------------------------------------------------- From icon-group-sender Fri Sep 29 13:06:50 1995 Received: by cheltenham.cs.arizona.edu; Fri, 29 Sep 1995 16:21:57 MST Date: Fri, 29 Sep 1995 13:06:50 -0700 From: Gregg Townsend Message-Id: <9509292006.AA18733@hawk.CS.Arizona.EDU> To: csts@mail.netvision.net.il, icon-group@cs.arizona.edu Subject: Re: Looking for a Tutorial for ICON Errors-To: icon-group-errors@cs.arizona.edu From: csts I'm new to ICON and am looking for a tutorial. Where can I find a tutorial I can download and read on my computer at home ? There's a nice tutorial on the Web, courtesy of John Shipman, at http://www.nmt.edu/tcc/help/lang/icon/ or you could curl up in an armchair at home with a copy of the Griswold & Griswold book. I'm not aware of anything that can be downloaded and run off-line. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Fri Sep 29 13:35:14 1995 Received: by cheltenham.cs.arizona.edu; Fri, 29 Sep 1995 16:22:10 MST Date: Fri, 29 Sep 1995 13:35:14 -0700 From: Gregg Townsend Message-Id: <9509292035.AA16487@hawk.CS.Arizona.EDU> To: icon-group@cs.arizona.edu, qbchsod@ebcw131.ericsson.se Subject: Re: Q: icont error message Errors-To: icon-group-errors@cs.arizona.edu From: qbchsod@ebcw131.ericsson.se (Soderstrom Hakan) I took a *working* program from an Icon 8.9 environment and tried to run it in a 9.0 environment. Now it wouldn't compile; icont complains: pltodb.icn: Line 85 # :"d_bname": no record having this field is ever created ... Short answer: If this was a working program, it probably is using string invocation at some point and requires an "invocable all" declaration to run under Icon version 9.0. If you see this error message in any other situation, just ignore it. It's so confusing that we're removing it from Icon 9.1. Long answer: Version 9 of Icon removes unreferenced procedures at the linking phase. That makes it feasible to construct and use libraries by linking files of many procedures: there's no penalty, because the unreferenced procedures are tossed out instead of occupying space. Run "icont -v3" to see the list of objects being discarded. This optimization breaks down in the case of string invocation. If the only call to procedure foo is via something like s := "foo" s() this doesn't count as a reference; the *procedure* foo is never referenced in the program, and so is discarded. You need to add invocable "foo" to prevent this, or invocable all if you don't know exactly what procedures to name. Now, back to the original question. Suppose that the only procedure that creates a record of type R is suppressed -- perhaps it was not called due to oversight or typographical error. All the places that reference fields of record type R now produce the warning message, which is technically correct but not at all helpful towards identifying the real problem. Accordingly, we are removing the link-time warning message from Icon version 9.1. In the mean time, just ignore it and concentrate on any other problems. If the reference causes problems during execution, an error will be genenrated at that time. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Sun Oct 1 10:35:00 1995 Received: by cheltenham.cs.arizona.edu; Sun, 1 Oct 1995 11:57:59 MST Message-Id: <9510011035.AA26522@ns1.computek.net> Mime-Version: 1.0 Content-Length: 614 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sun, 1 Oct 95 10:35 CDT From: gep2@computek.net Subject: Re: Questions on map() and / To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >Map transliterates characters like the "tr" utility of Unix. With default parameters, it translates upper case characters into lower case. The purpose of this is to make the program case-insensitive. Speaking of which... has anybody there at the Icon Project given thought to the whole can of worms opened up by all this "Unicode" nonsense? Is this something that ought to be taken into account by a version of Icon? Or should we all really just ignore Unicode in hopes it will go away? I'd be interested in everyone's opinion on this whole issue... Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Sat Sep 30 21:49:00 1995 Received: by cheltenham.cs.arizona.edu; Sun, 1 Oct 1995 11:57:34 MST Message-Id: <9509302149.AA04950@ns1.computek.net> Mime-Version: 1.0 Content-Length: 2236 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 30 Sep 95 21:49 CDT From: gep2@computek.net Subject: HTML/Word Converters To: icon-group@cs.arizona.edu Cc: bnielsen@logicon.com X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu > Is anyone on this list aware of publicly available ICON or SNOBOL4 programs that will convert Microsoft Word 6.0 documents to hypertext markup language (HTML) files and/or convert the other direction. I certainly can envision writing programs to help convert existing files from various formats to HTML, but the real problem here is that HTML is really NOT AT ALL a page layout language... in the normal version at least, you can't really control font, point size, where lines start and end, exactly how images and text interact with each other... as opposed to a desktop publishing system or high-powered word processor where you can get JUST what you [THINK you] want. It's hard to drive this point home to people, but I finally got one friend to get closer to an understanding of the point when he noticed that, under his Web browser on his Mac at least, simply changing the width of his browser's window on the screen caused all the text on the Web page he was looking at to be reformatted and re-laid out... And of course, the VIEWER gets to control point sizes, font selections, and the like. Of course, there IS Adobe Acrobat (for those people who feel they HAVE to control what the user sees) but I think that's a damned poor idea... part of the whole idea of a PERSONAL computer is that the VIEWER should be able to control the way the stuff they're getting looks to them. I wish that information providers would be content to PROVIDE INFORMATION, along with Web-style SUGGESTIONS as to the flavor of how it's presented, instead of trying to force the viewers into some specific straightjacket regarding presentation. Anyhow, given the fact that probably 90% of the stuff that something like Word for Windows can do can't possibly be done with most Web browsers, it's pretty hard to justify using WORD for such documents. A simple text editor is fine (or, better, a good hypertext HTML editor). If it's a one-time conversion that someone needs to do, there are all kinds of ways to get that done. The best choice depends on what the original document(s) look like, and how much of them there is to be converted to HTML. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Sat Sep 30 23:05:00 1995 Received: by cheltenham.cs.arizona.edu; Sun, 1 Oct 1995 11:57:46 MST Message-Id: <9509302305.AA08566@ns1.computek.net> Mime-Version: 1.0 Content-Length: 1832 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 30 Sep 95 23:05 CDT From: gep2@computek.net Subject: Re: what to use instead of TCL or PERL To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >:Tcl is an embeddable scripting language. Perl is mainly a system :administration and shell script language. Both are primarily Unix :based. In what sense are Visual Basic or Java appropriate for the :typical uses of Tcl or Perl? : :To start with, Visual Basic runs only on PC's and Java isn't even in :Beta yet! First off, "only on PCs" isn't a huge problem... since there are probably an order of magnitude more PCs in use in the world than all other general-purpose computers EVER built, put together. And as the power of PC-platform machines inexorably increases, (not surprising, given the huge volumes of money available to improve PC performance) the edge that the higher-end machines have over PC-platform machines gets slimmer and slimmer. But there are plenty of other interesting languages, in any case, which have been ported to just about all nontrivial platforms. >Perl is used for CGI scripting and general tools work, But aren't other languages just as good (or better) for this kind of thing? Frankly, I've looked at Perl, and (coming from a SNOBOL4+/ICON perspective) I was NOT impressed by it. Obviously Perl looks great, to someone who doesn't know any better. But just because someone ELSE is relatively-speaking in the dark doesn't necessarily make me want to follow in their ill-informed footsteps. >and runs not just on Unix, but also VMS, MVS, MsDOS, NT, Amigas, Macs, and many other systems as well. I think there are versions of SNOBOL4 and ICON available for each of those other platforms as well. >I would not say its use is restricted to Unix sysadmins, Certainly. But just because THEY aren't better informed about the better alternatives is hardly a compelling reason for the rest of us to do like they do. :-) Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Tue Oct 3 10:38:02 1995 Received: by cheltenham.cs.arizona.edu; Tue, 3 Oct 1995 12:31:39 MST Date: Tue, 3 Oct 1995 10:38:02 -0700 From: Gregg Townsend Message-Id: <9510031738.AA01734@hawk.CS.Arizona.EDU> To: gep2@computek.net, icon-group@cs.arizona.edu Subject: Re: Questions on map() and / Errors-To: icon-group-errors@cs.arizona.edu From: gep2@computek.net Speaking of which... has anybody there at the Icon Project given thought to the whole can of worms opened up by all this "Unicode" nonsense? We have speculated about a Unicode version of Icon. As I recall we figured it would take over half a year, full time, for somebody who's already an expert on the implementation to convert Icon to Unicode and do it "right". That's not likely to happen. There are some intriguing questions about a Unicode implementation. For example, should the representation of csets change? If so, how? The current representation would cost 8K bytes (64K bits) for each cset of Unicode. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Tue Oct 3 15:27:31 1995 Received: by cheltenham.cs.arizona.edu; Tue, 3 Oct 1995 16:20:52 MST Date: Tue, 3 Oct 1995 15:27:31 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9510032027.AA03524@dragon.cs.utsa.edu> To: gmt@cs.arizona.edu Cc: gep2@computek.net, icon-group@cs.arizona.edu In-Reply-To: <9510031738.AA01734@hawk.CS.Arizona.EDU> (message from Gregg Townsend on Tue, 3 Oct 1995 10:38:02 -0700) Subject: Re: Questions on map() and / Content-Length: 1110 Errors-To: icon-group-errors@cs.arizona.edu > Gregg Townsend writes: > We have speculated about a Unicode version of Icon. As I recall we figured > it would take over half a year, full time, for somebody who's already an > expert on the implementation to convert Icon to Unicode and do it "right". > That's not likely to happen. Of course that much effort is not likely to happen unless it is funded as part of a research agenda or a commercial effort. Who pays for it? I would add that until operating systems and hardware devices to support Unicode are widespread, software support for it is almost moot. Is Unicode in wide use internationally? > There are some intriguing questions about a Unicode implementation. > For example, should the representation of csets change? If so, how? > The current representation would cost 8K bytes (64K bits) for each cset > of Unicode. Yes, the representation of csets should change. The design and implementation of this change is not that hard and affects a limited number of places in the code; the pervasive change of all of the string analysis functions to do Unicode would be more painful. From icon-group-sender Wed Oct 4 00:30:17 1995 Received: by cheltenham.cs.arizona.edu; Wed, 4 Oct 1995 09:13:49 MST Date: 04 Oct 95 08:29:00 BST From: R J Hare Subject: Genetic algorithms/scheduling To: icon-group@cs.arizona.edu Organisation: Edinburgh University Computing Services Message-Id: <9510040829.aa27644@uk.ac.ed.festival> Errors-To: icon-group-errors@cs.arizona.edu Does anyone have any experience with using Icon for either Genetic programming techniques or scheduling applications (or both)? Thanks. Roger Hare From icon-group-sender Mon Oct 9 13:19:39 1995 Received: by cheltenham.cs.arizona.edu; Mon, 9 Oct 1995 13:20:25 MST Date: Mon, 9 Oct 1995 13:19:39 -0500 From: jeffery@ringer.cs.utsa.edu (Clinton L. Jeffery) Message-Id: <9510091819.AA18066@alamo.cs.utsa.edu> To: icon-group@cs.arizona.edu Subject: Icon for MS Windows general beta Content-Length: 7907 Errors-To: icon-group-errors@cs.arizona.edu Icon for MS Windows has taken excessively long, but it is time for a general beta. For those of you who have been on the beta mailing list, the main news for this beta is that BoundsChecker(tm) was used to find several problems in the use of Windows resources that have been resolved. The READ.ME file from this distribution is included below; it includes instructions for obtaining the software by anonymous FTP. I appreciate any and all feedback; I will attempt to resolve bugs in a timely fashion, subject to my other obligations. This will be the last MS Windows beta prior to the update to Icon version 9.1. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio Division of Computer Science --- Installing and running Icon 9.0 for MS Windows, beta-3 test version Clint Jeffery, University of Texas at San Antonio jeffery@ringer.cs.utsa.edu Highlights of Changes in this Beta Release Windows 3.1 program launching improved by a windowing launcher complements of Bob Goldberg. A volunteer to work further on the front end is needed. VIB, the visual interface builder, is improved in functionality. Numerous small bug fixes. System Requirements Intel 386 or higher, 8 MB of RAM, MS DOS and Windows 3.1 or higher. These are estimated minimums; I'd appreciate it if someone tried them on a 4 MB machine to see if it works at all, or just hangs. A set of 16-bit "Windows Lite" binaries might be an option for users of 4 MB Windows PC's -- send me e-mail if you need such a set of binaries and I'll see what I can do. Installation Instructions (32-bit binaries) 1) Install OS support for the Microsoft Win32 API. This means install Windows NT or Windows 95 or OS/2 Warp (these binaries untested on Warp at this time), or if you have DOS + Windows, you need to install a package from Microsoft called "Win32s". A version of Win32s is available by FTP to ringer.cs.utsa.edu:pub/icont/nt/win32s; copy all the files there onto a floppy disk, insert the disk in your Windows 3.1 machine, fire up Windows, and run a:setup.exe (or b:setup.exe if the floppy is in your b: drive). Follow the setup program's instructions. 2) Install Windows Icon binaries. The files are available by FTP from ringer.cs.utsa.edu:pub/icon/nt/graphics; copy all the files to a directory in your path. There are two icont binaries in this distribution (editor's note: only one is here at the moment, the portable one). nticont.exe is a Windows NT console application and will not work under DOS (it is untested under Windows 95). wicont.exe is a Win32s application which writes its messages out to a new window that it opens since Win32s does not support console applications. Note: the files are provided in regular (.EXE) and compressed (.lzh files, uncompress using lharc) formats. Compiling and Running Programs How these binaries are best used depends on what version of Windows you have. Under Windows 3.1, a program launcher named winicon.exe provided by Bob Goldberg let's you translate and run programs and specify their arguments. In the absence of winicon.exe, wicont and wiconx are launched by the Run... menu item in the Windows Program Manager. Alternately, you can configure Windows to launch icont whenever you double click on a .icn or .u1 file's icon. To do this, select a .icn or .u1 file in the File Manager or its equivalent, and then pick the Associate... option from the File menu. The same technique can configure Windows to launch wiconx whenever you double-click on a translated icon program, which has the extension .cmd. All of this is simpler under Windows NT, where these programs can be launched from the command line in a manner similar to their behavior under UNIX. When you translate an Icon program with wicont, the outfile file extension is .cmd; it is an executable script under Windows NT which looks for a wiconx binary. FEATURES Attribute linetype has values "dashed", "dotted", "solid", "dashdotted", and "dashdotdotted". Files with extension .icp are treated as command-line argument lists (one argument per line) and may be useful on DOS systems since wicont.exe cannot be launched from "make" or from .bat scripts. Setup .icp files for batch jobs, associate .icp extensions with wicont.exe, and you can run the batch job by double-clicking it in the file manager. .bmp image files are supported (and are very fast for reading and writing) wicont allows an option -q that causes it to exit on termination without waiting for a user keystroke; this is useful in batch compiles. system() supports launching Windows applications including wicont from inside Icon. I expect we/you will be able to implement an attractive IDE for developing Icon programs in Icon. BUGS The program now runs cleanly as far as BoundsChecker(tm) can determine, but still leaks resources under Windows 3.1/Win32s on some programs. Default font/leading are strange Default window size is not quite right for 80x12 window Font width attribute incorrect for fonts after the first font in each window. Program termination hotkey (ALT-F4) does not always work. Probably other hotkeys do not work either. Attribute linetype treats "striped" as "dashed"; there is no "striped" semantics under MS Windows. Under Windows 95 beta, the focus does not return to the command line window after an Icon program is launched. Windows 95 does not run batch files with the .cmd extension that NT uses. wicont may be changed to generate a .bat if it detects Windows 95. Some off-by-one errors in drawing, compared with X version Mutable colors do not work unless the window is the active window Mutable colors sometimes do not work as expected Colors are never freed Dithered colors are sometimes used when solid colors are expected GIF file processing is slow and may cause system to hang. Attribute iconpos is not implemented Attribute iconimage is not implemented Attribute pointername is not implemented Attribute pointer's shape is not restored when the pointer moves outside the application window Attribute visual is not implemented Deprecated attribute iconicstate is not supported; use canvas Attribute iconlabel is not implemented Default() is not implemented Windows are not closed on program termination until after a key is pressed on the console window, if there is one. LIMITATIONS and PROBLEM AREAS Most colors are dithered on 16-color machines, and color-intensive applications are ugly or unusable on those systems. Attribute display is not implemented Attribute pointer supports only "arrow", "cross", "ibeam", "uparrow", and "wait"; these might not work under 3.1. I have no plans to support the entire X cursor font Although some simple examples work, the drawop's may not work the same as in X. APPLICATION NOTES AND APPLICATION BUGS Some sample binaries are now included to demonstrate various features. These applications are from the Icon Program Library. VIB, the Visual Interface Builder, is a drawing tool that generates code for simple user interfaces that you design by drawing them. Its prototype function runs "wicont" but the translation console window may never appear. Two versions of VIB are provided, one with a nice light-gray backround for machines with 256+ colors, and one with a dark gray that may be more legible on 16-color machines. GED, a Graphical EDitor, is a Mac-like text editor. It has numerous features, most of which are untested under MSWindows. Features such as the "compile" command that depend on reading other program's output through pipes will not work since Windows applications do not have pipes or stdio. Under MS Windows 3.1 on a 16-color server, GED and/or wiconx has a scrolling bug which makes it unusable. ACKNOWLEDGEMENTS This work was made possible in part by a software donation from Microsoft, a hardware donation from Icon Project, and a UTSA faculty research award. From icon-group-sender Mon Oct 9 19:26:20 1995 Received: by cheltenham.cs.arizona.edu; Mon, 9 Oct 1995 16:20:23 MST To: icon-group@cs.arizona.edu Date: 9 Oct 1995 19:26:20 GMT From: CHENANDRE@urvax.urich.edu (Andrew Shi-hwa Chen) Message-Id: Organization: None, Inc. 1975 Sender: icon-group-request@cs.arizona.edu References: , <449s2k$hu8@csnews.cs.colorado.edu>, Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu > > Perl is used for CGI scripting and general tools work, and runs > > not just on Unix, but also VMS, MVS, MsDOS, NT, Amigas, Macs, and > > many other systems as well. I would not say its use is restricted > > to Unix sysadmins, and if you haven't looked at it in the last five years, > > then you are probably working under some misunderstandings about the > > language. > I said that it was primarily a sysadmin and shell script language. To > me that more or less includes CGI scripting and general tools. I did > not say that its use is restricted to Unix sysadmins. And whether it's > ported or not I still believe that it is primarily in use on Unix > systems. > > Regardless of agreement on the above, my point (in response to a part > of the message that you edited out) was that neither Visual Basic nor > Java could be said to be appropriate for typical uses of Perl (or > Tcl). I use MacPerl, the only Macintosh variant of Perl that I know of, and IT'S GOOD! I've found it very handy for a variety of things that I would have had to write in other languages. While I can't really compare it with Visual Basic since I haven't seem Visual Basic on a Mac (it doesn't exist) or perl on a PC, I can say that everything I've ever in Visual Basic (on a PC - I've used it to write small handy utilities) I could have done in Perl (had it been available on that machine) with less environment overhead (i.e. - I wouldn't have had to worry about Visual Basic Forms, etc...). While I hate making the comparison (between Visual Basic and HyperCard), I must say that for somethings that Perl would typically be considered ideal for (certain text processing uses, for instance) I've found HyperTalk and AppleScript to be better languages for. Thus conceptually Visual Basic might be appropriate for some of the typical uses of Perl, if it has a degree of text processing capability comparable to HyperTalk's. It didn't last I checked, but then, maybe I wasn't looking that hard (despite it's high learning curve, it's still more difficult to learn than HyperCard). In summary, I'm trying to say Visual Basic might be appropriate for some of the typical uses of Perl. (The HyperCard example illustrating the main point in my argument is available upon request.) From icon-group-sender Mon Oct 9 22:47:04 1995 Received: by cheltenham.cs.arizona.edu; Tue, 10 Oct 1995 09:45:25 MST To: icon-group@cs.arizona.edu Date: 09 Oct 1995 22:47:04 GMT From: krishna@shamu.csd.sgi.com (Krishna Sethuraman) Message-Id: Organization: Silicon Graphics Computer Systems Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu>, <43mipn$d53@news1.delphi.com> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu Don't forget one very interesting use of Perl -- because of its facility in manipulating long strings, it's being used in the human genome mapping project (I think that's what it's called). I wouldn't try that in the other scripting languages I know of ... Krishna From icon-group-sender Tue Oct 10 00:30:00 1995 Received: by cheltenham.cs.arizona.edu; Tue, 10 Oct 1995 09:45:37 MST Date: Tue, 10 Oct 95 00:30 CDT Message-Id: <9510100030.AA02981@ns1.computek.net> Mime-Version: 1.0 Content-Length: 1611 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: More on PERL etc. To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >While I hate making the comparison (between Visual Basic and HyperCard), I must say that for somethings that Perl would typically be considered ideal for (certain text processing uses, for instance) I wouldn't consider Perl "ideal" for ANY kind of text processing things I could imagine. Comparing Perl to something like Icon or SNOBOL4, I can't see how Perl would even stand a -prayer-. >I've found HyperTalk and AppleScript to be better languages for. Can you suggest ANYTHING that they're better at, in terms of text processing, than either SNOBOL4 or Icon? Perl is a POOR second to either one, and I doubt that HyperTalk or AppleScript are any more competitive. >Thus conceptually Visual Basic might be appropriate for some of the typical uses of Perl, if it has a degree of text processing capability comparable to HyperTalk's. It didn't last I checked, but then, maybe I wasn't looking that hard (despite it's high learning curve, it's still more difficult to learn than HyperCard). Visual Basic is, also, pathetic for text processing compared to anything like the languages we're all so indebted to Ralph Griswold for! Jeez, I can hardly believe that we're even carrying on such a ludicrous discussion here, in the Icon group, where presumably we all KNOW better than to waste our time trying to even THINK about doing text processing with junk like Perl, or HyperCard, or AppleScript. I mean, this isn't exactly like a dumb general programming conference where people could claim ignorance of Icon or SNOBOL4 or anything. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Mon Oct 9 16:49:46 1995 Received: by cheltenham.cs.arizona.edu; Tue, 10 Oct 1995 09:46:00 MST To: icon-group@cs.arizona.edu Date: Mon, 9 Oct 1995 16:49:46 GMT From: ceejac@cee.hw.ac.uk (Jonathan Collins) Message-Id: Organization: Dept of Computing and Electrical Engineering, Heriot-Watt University Sender: icon-group-request@cs.arizona.edu Subject: Icon History Errors-To: icon-group-errors@cs.arizona.edu Can anyone tell me where I can get a history about icon. I have been to the icon home page at cs.arizona, and there is alot of info about icon, but there seems to be nothing on the history about it. I know that there is an article in ACM SIGPLAN notice vol 28, num 3 that is called 'the history of the icon programming language', but unfortunately my library has not got it (strange, we have number 1,2 and 4,5,6..) but there is no record of it being taken out! So if anyone can even tell me where I can get a copy of this article, I would appreciate it. Thanks. -- Jonathan Collins From icon-group-sender Tue Oct 10 13:42:54 1995 Received: by cheltenham.cs.arizona.edu; Tue, 10 Oct 1995 12:32:12 MST Date: Tue, 10 Oct 95 13:42:54 CDT From: johnp@utafll.uta.edu (John Paolillo) Message-Id: <9510102042.AA25964@utafll.uta.edu> To: icon-group@cs.arizona.edu Subject: Icon and HyperTalk/AppleScript Errors-To: icon-group-errors@cs.arizona.edu (A breakaway from the Perl and other lgs. thread) Hypertalk has a "chunking" construct for referring to pieces of text between delimiters. Oftentimes this is more convenient and understandable than the kinds of expressions you need in Icon to do the same thing (I don't know about SNOBOL). I have found myself in situations where I wished I could use chunking in Icon. For more flexible text processing (i.e where parsing higher-order constructs is necessary) Hypertalk is a very poor choice, and Icon (because of its data structures and backtracking, both absent in Hypertalk) works very well. AppleScript is somewhere between the two because it has better data structures than Hypertalk, and it doesn't inherently have the chunking of Hypertalk (you need an application or an OSAX to give you that), but since it does have lists (but no built-in backtracking) you could do parsing in AppleScript a bit easier. So, for text processing in which simply-delimited constructs are all that is needed (e.g. reading the header lines of a mail file), Hypertalk is easier to use than Icon. But if you care to go further (e.g. indexing the content of the mail messages of the same file), then Icon is much more flexible, and hence tons better. It was because of these similarities/differences that I originally suggested an OSA (open scripting architecture -- Apple's standard for scripting languages) implementation of Icon. Both Hypertalk and Applescript are now OSA compliant. A few other languages are too (TCL and J/APL for instance, I'm not sure about Perl). Generally I prefer what I write to be in Icon, since there are features of AppleScript and HyperTalk that I don't like (for instance, AppleScript has a really bogus semantics for list concatenations that flattens out some lists), and Icon is overall more flexible than the other 2. I hope this clarifies why someone might use Hypertalk instead of Icon for some text processing tasks. John C. Paolillo Linguistics Program University of Texas at Arlington From icon-group-sender Tue Oct 10 20:13:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 11 Oct 1995 09:40:18 MST Date: Tue, 10 Oct 95 20:13 CDT Message-Id: <9510102013.AA19012@ns1.computek.net> Mime-Version: 1.0 Content-Length: 620 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Re: what to use instead of TCL or PERL To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >Don't forget one very interesting use of Perl -- because of its facility in manipulating long strings, it's being used in the human genome mapping project (I think that's what it's called). I wouldn't try that in the other scripting languages I know of ... Fair enough, since you can hardly call SNOBOL4 or Icon mere "scripting languages". SNOBOL4+ allows individual strings up to 32K in length, and that's really only an implementation limit, there's no inherent limitation in the design of the language. How long of a single character string do you need? Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Oct 11 07:45:59 1995 Received: by cheltenham.cs.arizona.edu; Wed, 11 Oct 1995 09:41:09 MST To: icon-group@cs.arizona.edu Date: 11 Oct 1995 07:45:59 -0400 From: pperucci@access5.digex.net (Phil Perucci) Message-Id: <45gapn$cv5@access5.digex.net> Organization: Express Access Online Communications, Greenbelt, MD USA Sender: icon-group-request@cs.arizona.edu References: <449s2k$hu8@csnews.cs.colorado.edu>, , Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In article , Krishna Sethuraman wrote: > >Don't forget one very interesting use of Perl -- because of its facility in >manipulating long strings, it's being used in the human genome mapping project >(I think that's what it's called). I wouldn't try that in the other scripting >languages I know of ... Or... Expect! While Perl excels at text-processing, Expect (Tcl-based) is intended for "interaction automation". Expect lets you automate utilities such as telnet, ftp, passwd - ANYTHING with a character-based interface. Very handy for those cgi-bin scripts which call other existing applications. Search the web for "expect" and "nist" (NIST is the home-site) for more info... -- ============================================================================== Phil Perucci ......... pperucci@access.digex.net ........ Systems Integrator "Visit the Hydrologic Information Center at http://www.nohrsc.nws.gov/~hic" ============================================================================== From icon-group-sender Wed Oct 11 14:24:35 1995 Received: by cheltenham.cs.arizona.edu; Wed, 11 Oct 1995 09:41:20 MST To: icon-group@cs.arizona.edu Date: 11 Oct 1995 14:24:35 GMT From: Tom Christiansen Message-Id: <45gk33$c72@csnews.cs.colorado.edu> Organization: scant Sender: icon-group-request@cs.arizona.edu References: , , <45gapn$cv5@access5.digex.net> Reply-To: tchrist@mox.perl.com (Tom Christiansen) Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu :-> In comp.lang.perl.misc, pperucci@access5.digex.net (Phil Perucci) writes: :Or... Expect! : :While Perl excels at text-processing, Expect (Tcl-based) is intended for :"interaction automation". Well, perl is a language, and expect is an application. These aren't the same thing. You're comparing fields with fungus. There is, however, a perl applications library for expect stuff. Son of Chat2, is Eric Arnold @ Sun's new expect-like library. --tom From icon-group-sender Wed Oct 11 12:00:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 11 Oct 1995 12:21:20 MST Date: Wed, 11 Oct 95 12:00 CDT Message-Id: <9510111200.AA10030@ns1.computek.net> Mime-Version: 1.0 Content-Length: 289 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Re: what to use instead of TCL or PERL To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >While Perl excels at text-processing, Oh, give us all a break. Perl's text-processing features are primitive in the extreme, next to what's available in Icon or SNOBOL4. Perl's better than C, sure, but that's not saying much!! Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Oct 11 11:02:39 1995 Received: by cheltenham.cs.arizona.edu; Wed, 11 Oct 1995 12:21:31 MST To: icon-group@cs.arizona.edu Date: 11 Oct 1995 11:02:39 GMT From: hightec@rz.uni-sb.de (Michael Schumacher) Message-Id: <45g88f$b12@hades.rz.uni-sb.de> Organization: HighTec EDV-Systeme GmbH Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu>, <43mipn$d53@news1.delphi.com> Reply-To: mike@hightec.saarlink.de Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu Krishna Sethuraman (krishna@shamu.csd.sgi.com) wrote: : Don't forget one very interesting use of Perl -- because of its facility in : manipulating long strings, it's being used in the human genome mapping project : (I think that's what it's called). I wouldn't try that in the other scripting : languages I know of ... Is there any built-in limit for the length of strings in Tcl? mike From icon-group-sender Wed Oct 11 15:47:42 1995 Received: by cheltenham.cs.arizona.edu; Wed, 11 Oct 1995 16:37:18 MST From: Nick Williams Message-Id: <199510111947.PAA15648@styx.ios.com> Subject: Strange loadfunc related bug in iconc To: icon-group@cs.arizona.edu Date: Wed, 11 Oct 1995 15:47:42 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1715 Errors-To: icon-group-errors@cs.arizona.edu Hi, I just started playing again with loadfunc having stopped a few months ago and having changed platforms from a Sun sparc (SunOS 4.1.3) to a PC running FreeBSD. I had written up a small library of routines to interface to system calls and functions (such as fork, getuid, etc..). Now, as I tried to use them once again I have run into a problem: everything works fine when the Icon code is interpreted, but the return values of external functions are screwed up when the Icon code is compiled. For example, getuid() returns the integer 1000, the C stub that I wrote to interface Icon to getuid() returns this integer just fine using the RetInteger macro. If the Icon program that makes use of this interface is interpreted everything goes as expected, but if it is compiled instead, then the result is very strange: the type() function returns 1000 instead of the string "integer"!!, moreover, the the bug is not in the type() function because the value in question cannot be printed with write() either. I have spent the last half hour poring over src/runtime/fload.r, C code generated for the programs in ipl/packs/loadfunc as well as my own program and I can't tell for sure where the bug is. The C code loaded via loadfunc _does_ execute, I have tested this. I don't think the bug lies in the glue() function or in invoke(), or in apply(). Perhaps the bug is in the code that iconc generates, which I have serious trouble following (it wasn't meant to be read, was it? :) Any ideas? Nick PS: To get Icon to run under FreeBSD I had to perform two changes to the source code: a) change "RTLD_LAZY" in fload.r to 1 and b) include a copy of ecvt() in rmisc.r surrounded by ifdefs (BSD_4_4_LITE). From icon-group-sender Wed Oct 11 16:56:14 1995 Received: by cheltenham.cs.arizona.edu; Thu, 12 Oct 1995 09:17:57 MST To: icon-group@cs.arizona.edu Date: 11 Oct 95 16:56:14 GMT From: eric.arnold@sun.com (Eric Arnold) Message-Id: Organization: Sun Microsystems Sender: icon-group-request@cs.arizona.edu References: , , <45gapn$cv5@access5.digex.net> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu There is an "expect"-like package for Perl (was "chat2.pl"; I've recently posted a revised version, "Comm.pl"). So, you can stay in Perl (with its robust binary data manipulation, speed, and real arrays), and still do the same kind of "interaction automation" as TCL/Expect. -Eric In article <45gapn$cv5@access5.digex.net> pperucci@access5.digex.net (Phil Perucci) writes: >In article , >Krishna Sethuraman wrote: >> >>Don't forget one very interesting use of Perl -- because of its facility in >>manipulating long strings, it's being used in the human genome mapping project >>(I think that's what it's called). I wouldn't try that in the other scripting >>languages I know of ... > >Or... Expect! > >While Perl excels at text-processing, Expect (Tcl-based) is intended for >"interaction automation". Expect lets you automate utilities such as >telnet, ftp, passwd - ANYTHING with a character-based interface. Very >handy for those cgi-bin scripts which call other existing applications. > >Search the web for "expect" and "nist" (NIST is the home-site) for more >info... > From icon-group-sender Wed Oct 11 19:23:49 1995 Received: by cheltenham.cs.arizona.edu; Thu, 12 Oct 1995 09:18:09 MST Date: Wed, 11 Oct 1995 19:23:49 -0700 From: Gregg Townsend Message-Id: <9510120223.AA01683@hawk.CS.Arizona.EDU> To: nmw@styx.ios.com Subject: Re: Strange loadfunc related bug in iconc Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu From: Nick Williams ... I had written up a small library of routines to interface to system calls and functions (such as fork, getuid, etc..). Now, as I tried to use them once again I have run into a problem: everything works fine when the Icon code is interpreted, but the return values of external functions are screwed up when the Icon code is compiled. ... Perhaps the bug is in the code that iconc generates, which I have serious trouble following (it wasn't meant to be read, was it? :) ... Not really. And your speculation is probably right. Try compiling with "iconc -n t" and see if that fixes it. If not, add "iconc -f s" and try that. PS: To get Icon to run under FreeBSD I had to perform two changes to the source code: a) change "RTLD_LAZY" in fload.r to 1 and b) include a copy of ecvt() in rmisc.r surrounded by ifdefs (BSD_4_4_LITE). Thanks for that info. Can you tell us what would be a correct FreeBSD entry for ipl/packs/loadfunc/mklib.sh? Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Thu Oct 12 03:18:24 1995 Received: by cheltenham.cs.arizona.edu; Thu, 12 Oct 1995 09:18:55 MST To: icon-group@cs.arizona.edu Date: 12 Oct 1995 03:18:24 GMT From: dgameynn@reach.com Message-Id: <45i1e0$qad@nntp208.reach.com> Organization: Reach Networks Sender: icon-group-request@cs.arizona.edu References: <44vs3q$gmc@newsbf02.news.aol.com>, <450dl3$ecm@nntp208.reach.com>, <45fbdg$m4c@nntp208.reach.com> Subject: Interval wiring (was Re: **********questions re rotor systems ******) Errors-To: icon-group-errors@cs.arizona.edu Following up on the original question by WHorton877@aol.com (Wesley) and replies by Wesley and myself: After thinking a bit about the problem of how to construct rotors in the fashion of the "interval method", described in Machine Cryptography & odern Cryptanalysis [Deavours 1985], I came up with an approach using a matrix. I will descibe it below. Please bear in mind that this is a first cut and there may also be more efficient approaches. There may even be some formal approach to this - please chime in if anyone knows one. I also think that this problem could be cast as a recursive generator in Icon or a similar construct in Prolog. The problem appears on the surface to be similar to the 8-queens chessboard problem, which appears on the cover of the Icon Programming Language book. APL might be good for the matrix approach. 1. construct an empty N*N matrix for a rotor of size N 2. WHILE select an unmarked entry in the matrix DO { 2.1 record that entry 2.2 mark all entries in that row 2.3 mark all entries in that column 2.4 mark all entries in the diagonals corresponding to the interval just selected, i.e. for row r and interval i then mark all matrix[r,r+i+N mod N] and matrix[r,r-i+N mod N] } 3. examine the matrix and deal with any outstanding connections which will duplicate an interval already used 4. normalize the rotor so that the smallest interval is from the same point, e.g. 'a' - this will allow for easy comparison of rotors In the above, - 2.2 & 2.3 ensure we wire one to one mapping of input & output terminals - 2.4 marking diagonals eliminates the interval just used from contention - 3. is needed because (a) according to Deavours the best that can be done for an even N, is a rotor with one duplicate and one ommitted interval and (b) we might not be optimal The last point is where the generator approach comes in, but I haven't had time to think that through yet. Wesley, I Hope this helps. David From icon-group-sender Thu Oct 12 01:01:43 1995 Received: by cheltenham.cs.arizona.edu; Thu, 12 Oct 1995 09:19:08 MST From: Nick Williams Message-Id: <199510120501.BAA23678@styx.ios.com> Subject: Re: Strange loadfunc related bug in iconc To: gmt@cs.arizona.edu (Gregg Townsend) Date: Thu, 12 Oct 1995 01:01:43 -0400 (EDT) Cc: icon-group@cs.arizona.edu In-Reply-To: <9510120223.AA01683@hawk.CS.Arizona.EDU> from "Gregg Townsend" at Oct 11, 95 07:23:49 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2459 Errors-To: icon-group-errors@cs.arizona.edu > From: Nick Williams > ... > I had written up a small library of routines to interface to system > calls and functions (such as fork, getuid, etc..). Now, as I tried to > use them once again I have run into a problem: everything works fine > when the Icon code is interpreted, but the return values of external > functions are screwed up when the Icon code is compiled. > ... > Perhaps the bug is in the code that iconc generates, which I have > serious trouble following (it wasn't meant to be read, was it? :) > ... >Not really. And your speculation is probably right. Try compiling with >"iconc -n t" and see if that fixes it. If not, add "iconc -f s" and try >that. This worked. Thanks. I will experiment a little further, at least I want to determine what exactly the return values are mangled into, I bet there's a pattern. More on this tomorrow (or the day after, or something). > PS: To get Icon to run under FreeBSD I had to perform two changes to the > source code: a) change "RTLD_LAZY" in fload.r to 1 and b) include a > copy of ecvt() in rmisc.r surrounded by ifdefs (BSD_4_4_LITE). RTLD_LAZY should probably be a define somewhere; the name should probably be something else as well. >Thanks for that info. Can you tell us what would be a correct FreeBSD >entry for ipl/packs/loadfunc/mklib.sh? ld -Bshareable -o $LIBNAME "$@" -lc There is going to be a problem parsing the output of uname -sr as it returns "FreeBSD 2.0.5-RELEASE" and this changes very often for FreeBSD :) These are the defines I use (config/i486_freebsd/define.h): #define Standard #define IconGcvt #define index strchr #define rindex strrchr #define GetHost #define Hz 100 #define MaxHdr 13400 #define MaxStatSize 20480 #define GenericBSD #define BSD_4_4_LITE 1 /* This is new, for 4.4Lite specific stuff */ #define UNIX 1 #define LoadFunc #define ExecImages #define KeyboardFncs #define HaveTioc #define USE_OLD_TTY #define AllowConst #define SysOpt #define CComp "gcc" #define COpts "-O2" I put the code for ecvt within an ifdef/endif using BSD_4_4_LITE, thinking that ecvt() is probably missing from the other 4.4Lite variants. I may be wrong. The rswitch stuff I copied from the i486_linux config. > Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 > +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m > Thanks, Nick From icon-group-sender Fri Oct 13 10:29:19 1995 Received: by cheltenham.cs.arizona.edu; Sat, 14 Oct 1995 11:09:47 MST To: icon-group@cs.arizona.edu Date: Fri, 13 Oct 1995 10:29:19 -0700 From: Eric Brown Message-Id: <307EA1EF.4DE1@mty.sca.sony.com> Organization: Sony Corporation of America, San Jose, CA Sender: icon-group-request@cs.arizona.edu Subject: icon and java Errors-To: icon-group-errors@cs.arizona.edu Icon and Java seem very similiar: * Both look like C * Both have garbage collection * Both have a p-code/VM implementation (see note 1 below) Has anybody thought about modifying the icon compilier to generate instructions for the Java VM? Icon is a relatively unknown but very useful language. Making it work with the Java VM might bring some popularity back to the language. Who knows, maybe some grad student at Arizona can even get funding to do it. For Java-heads, see http://www.cs.arizona.edu/icon/www/ for Icon Programming Language info. Hopeful, Eric. Note 1: I haven't programmed in Icon for a while, but that's the way it used to work. I guess the latest implementations now have native compiliers but Icon appears to still support some intermediate form called ucode. From icon-group-sender Sun Oct 15 19:40:30 1995 Received: by cheltenham.cs.arizona.edu; Mon, 16 Oct 1995 09:25:43 MST To: icon-group@cs.arizona.edu Date: 15 Oct 1995 19:40:30 -0400 From: bsa@kf8nh.apk.net (Brandon S. Allbery KF8NH) Message-Id: <45s65e$74v@kf8nh.apk.net> Organization: Brandon's own server in Parma (Cleveland) OH Sender: icon-group-request@cs.arizona.edu References: <307EA1EF.4DE1@mty.sca.sony.com> Subject: Re: icon and java Errors-To: icon-group-errors@cs.arizona.edu Also sprach Eric Brown (<307EA1EF.4DE1@mty.sca.sony.com>): +----- | way it used to work. I guess the latest implementations now have | native compiliers but Icon appears to still support some | intermediate form called ucode. +--->8 There is an *experimental* Icon-to-C translator in the Icon distribution; in version 8.x it worked fairly well, but in 9.0 it's rather buggy --- and, being unsupported, it's unlikely to be fixed (or so I have been informed). (I don't have the time to overhaul it myself to track down the show-stoppers that made me stop using it.) The "main track" of Icon still involves compiling to interpreted u-code. -- ++brandon s allbery telotech, inc beachwood oh bsa@kf8nh.wariat.org (work address) bsa@telotech.com From icon-group-sender Sun Oct 15 20:38:56 1995 Received: by cheltenham.cs.arizona.edu; Mon, 16 Oct 1995 09:26:25 MST Date: Sun, 15 Oct 1995 20:38:56 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9510160138.AA22328@dragon.cs.utsa.edu> To: ebrown@mty.sca.sony.com Cc: icon-group@cs.arizona.edu In-Reply-To: <307EA1EF.4DE1@mty.sca.sony.com> (message from Eric Brown on Fri, 13 Oct 1995 10:29:19 -0700) Subject: Re: icon and java Content-Length: 755 Errors-To: icon-group-errors@cs.arizona.edu [Eric Brown writes] Has anybody thought about modifying the icon compilier to generate instructions for the Java VM? Is Java an open system with a VM that is documented? I and several other Icon folks have played with Java or read about it with interest, but Sun seems to be fairly proprietary about Java, so only Sun could undertake (or sponsor) the kind of project you suggest. For the record, without the ability to modify/enhance the Java VM, it might be just as difficult to translate Icon to Java's VM as it is to translate Icon into C. Icon's VM specifically supports generators and backtracking in ways that would be awkward to emulate in another VM. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Mon Oct 16 08:08:48 1995 Received: by cheltenham.cs.arizona.edu; Mon, 16 Oct 1995 09:27:48 MST To: icon-group@cs.arizona.edu Date: 16 Oct 1995 08:08:48 -0500 From: gmribeir@david.wheaton.edu (Glauber Ribeiro) Message-Id: <45tlh0$37h@david.wheaton.edu> Organization: The Bossa Nova University Sender: icon-group-request@cs.arizona.edu Subject: Looking for a carton-packing algorithm Errors-To: icon-group-errors@cs.arizona.edu Sorry this is not a specifically Icon issue, but i know Icon people are interested in this kind or "real-world" problem, so maybe someone here can at least give me pointers. I'm writing a warehouse-management program, and part of the shipping side of it is assigning the right size carton to ship an order. We have the carton sizes, and the sizes of the several items. How to find a carton that will fit the items we want to ship? The solution doesn't need to be optimal, but it must work 80% of the time or more. It is better to err towards a carton that is too large than too small. I appreciate any help or pointers. If at all possible, PLEASE EMAIL, because i've been too busy to check news every day, and things expire very quickly in this site. Thank you very much. glauber -- glauber ribeiro glauber@david.wheaton.edu ------------------------- practice random kindness and senseless acts of beauty From icon-group-sender Mon Oct 16 15:57:29 1995 Received: by cheltenham.cs.arizona.edu; Mon, 16 Oct 1995 10:06:33 MST To: icon-group@cs.arizona.edu Date: 16 Oct 1995 15:57:29 GMT From: swampler@noao.edu () Message-Id: <45tvd9$9vu@noao.edu> Organization: National Optical Astronomy Observatories, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <307EA1EF.4DE1@mty.sca.sony.com> Subject: Re: icon and java Errors-To: icon-group-errors@cs.arizona.edu In article <307EA1EF.4DE1@mty.sca.sony.com>, Eric Brown writes: |> Icon and Java seem very similiar: |> * Both look like C |> * Both have garbage collection |> * Both have a p-code/VM implementation (see note 1 below) |> |> Has anybody thought about modifying the icon compilier to generate |> instructions for the Java VM? |> |> Icon is a relatively unknown but very useful language. Making it |> work with the Java VM might bring some popularity back to the |> language. Who knows, maybe some grad student at Arizona can even |> get funding to do it. |> Unfortunately, the VM's for Icon and Java are probably very disparate virtual architecture's. Icon's expression evaluation is a superset of the Java language, and Java's reliance on threads wouldn't be well supported on the Icon VM (though coexpressions are somewhat similar). It might be interesting to see what VM would serve both languages, but I doubt either group has the time and inclination to do so. -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The Gods that smiled upon your birth are laughing now. -- fortune cookie From icon-group-sender Mon Oct 16 12:02:00 1995 Received: by cheltenham.cs.arizona.edu; Mon, 16 Oct 1995 10:07:31 MST Message-Id: <9510161202.AA16146@ns1.computek.net> Mime-Version: 1.0 Content-Length: 3010 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 16 Oct 95 12:02 CDT From: gep2@computek.net Subject: Looking for a carton-packing algorithm To: gmribeir@david.wheaton.edu Cc: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >Sorry this is not a specifically Icon issue, but i know Icon people are interested in this kind or "real-world" problem, so maybe someone here can at least give me pointers. As it turns out, Icon is probably at least conceptually the IDEAL language for precisely this problem. I can't imagine any other language better suited. >I'm writing a warehouse-management program, and part of the shipping side of it is assigning the right size carton to ship an order. We have the carton sizes, and the sizes of the several items. How to find a carton that will fit the items we want to ship? Or several smaller cartons, perhaps of various sizes. I actually worked on developing a fully automated/robotized PC-based pick/pack/ship system almost ten years ago in France, (the ultimate customer of the system, as it turns out, was IBM France) where we had this exact same problem (and solved it, but it was my colleagues in the company I was working with who worked on this part of the problem). It's actually an EXTREMELY interesting problem, for several reasons including the following: 1) Shipping cost is a function of the number, sizes and weights of individual packages, but cartons bigger than a certain size or weight cannot be shipped at all by some carriers (and it's probably a good idea to ship all the cartons of a given shipment together by the same carrier, when possible); 2) The items that go into each carton should (ideally) come as close as possible to filling each carton (this is the most obvious criteria); 3) Some items that are being packed may have distinct orientations to be respected during shipment (This Side Up, etc.) 4) Fragile or delicate or irregulary-shaped items should generally not be packed underneath heavy or boxed items. 5) The resulting fully-packed carton should have a center of gravity which is as low as possible in the carton, and centered in the carton. Otherwise, the sealed carton will be unstable and have an increased tendency to tip over. 6) As the carton is being packed, the contents need to be at least reasonably stable in all the intermediate conditions as each new item is added to the ones already in the carton. Otherwise, as the robot leaves the carton to fetch the next item to be packed in it, the stuff shifts and the new item can no longer be placed where it belongs. The solution that the company I worked at implemented was done in C, and might or might not be adaptable to your situation. If you're interested in contacting them, the company is "I.R.C.I." and is located in Villejuif, a suburb south of Paris. You should be able to get their phone and fax numbers from international directory assistance, or through the French Minitel directory assistance which is available through the Net. IRCI may be willing to license that portion of their software to your company. Ask for Philippe Auphelle there (he speaks perfect English, by the way). Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Oct 18 14:54:52 1995 Received: by cheltenham.cs.arizona.edu; Wed, 18 Oct 1995 15:06:20 MST To: icon-group@cs.arizona.edu Date: 18 Oct 1995 14:54:52 -0400 From: marcok24@aol.com (MarcoK24) Message-Id: <463ihs$2e0@newsbf02.news.aol.com> Organization: America Online, Inc. (1-800-827-6364) Sender: icon-group-request@cs.arizona.edu Reply-To: marcok24@aol.com (MarcoK24) Subject: Requesting Assitance w/ Icon Errors-To: icon-group-errors@cs.arizona.edu I have to write a scanner in Icon for the Euler programming lang. The scanner must be implemented as a subroutine such that each call to the scanner will return the next token from the Euler program as a record of the form: (token_type, token, line_number, column_number) Anything can help! Please E-mail me w/ any suggestions or anything that might be of some help. Thank you! From icon-group-sender Wed Oct 18 15:32:12 1995 Received: by cheltenham.cs.arizona.edu; Wed, 18 Oct 1995 16:00:43 MST Date: Wed, 18 Oct 1995 15:32:12 -0700 From: swampler@noao.edu Subject: Re: Requesting Assitance w/ Icon To: marcok24@aol.com Cc: icon-group@cs.arizona.edu Message-Id: In-Reply-To: <463ihs$2e0@newsbf02.news.aol.com> Errors-To: icon-group-errors@cs.arizona.edu The Icon book (2nd edition) has examples of routines that could be adapted to this purpose. Right now the examples simply return the next 'word' of the input text, but by changing the definition of the word and by returning a record instead of the word itself, you should be able to get a Euler scanner fairly quickly. Are you sure it is to *return* the tokens and not *generate* them? (Whomever is requiring you to do this in Icon should know the answer.) -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The Gods that smiled upon your birth are laughing now. -- fortune cookie From icon-group-sender Sat Oct 21 07:03:11 1995 Received: by cheltenham.cs.arizona.edu; Sat, 21 Oct 1995 10:51:26 MST Date: Sat, 21 Oct 1995 07:03:11 -0500 (CDT) From: "Chris D. Tenaglia" To: icon-group@cs.arizona.edu Subject: Perl vs Icon Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Real world problem here. Perl vs Icon. On a given unix system I've been using Icon quite successfully for: o Scripting o Small programs and utilities o Data conversions Mostly in the role of system admin. However, some new backup sys admins have been brought on and their recommendation is to scrap this Icon stuff and standardize on Perl, because : o They know Perl o They don't know Icon o Thousands of sys admins can't be wrong o There's two of them and one of me o They're closer to the CIO than I am And so I find myself on the defensive. I don't want to start flaming and look like a raving fanatic in mgt eyes, but has anyone been through such a coup? And is there any advice or or layout of reason I could use defense of Icon. Right now, all I have to offer is years of reliable running (but Perl has that on some other systems too), and that I've written over 100 programs to support this particular system. I've also developed my own software chip library, in addition to the IPL, and that helps a lot with productivity and code reuse. I am already aware of one answer, "Learn Perl, it's a marketable trade." No sweat, it probably can be mastered in a weekend with a good manual, but my goal is to defend Icon, and maybe uplift the consciousness of some. Even though I think my real problem is politics. Chris Tenaglia (system manager) | cdt@post.its.mcw.edu Medical College of Wisconsin | 8701 W. Watertown Plank Rd. | Ce que vous voyez est Milwaukee, WI 53226 (414)456-8765 | ce que vous obtenez ! From icon-group-sender Sat Oct 21 15:17:38 1995 Received: by cheltenham.cs.arizona.edu; Sat, 21 Oct 1995 16:39:34 MST Message-Id: <199510212011.AA11175@optima.cs.arizona.edu> Date: Sat, 21 Oct 1995 15:17:38 -0500 From: John David Stone To: icon-group@cs.arizona.edu Cc: cdt@post.its.mcw.edu, stone@post.math.grin.edu Subject: Perl vs Icon In-Reply-To: References: Errors-To: icon-group-errors@cs.arizona.edu Chris D. Tenaglia writes: > No sweat, it probably can be mastered in a weekend with a good > manual ... Hoo hoo, have you got a surprise in store for you, Chris. Except perhaps for JCL and C++, Perl is the worst-designed language ever to win the hearts of hackers. It's full of tiny little inconsistencies and misfeatures that will reach out and bite you in unexpected ways. Check with those sysadmins who claim to know and use it and find out how many weekends they spend trying to debug their Perl scripts by trial and error. Ask them for a Perl script that they've worked on and do a walkthrough with them; I predict that you'll find a bug every ten lines or so. In short, the case for Icon over Perl is that well-written Icon programs are relatively robust, intelligible, and maintainable. There are almost no well-written Perl programs, but even if your colleagues manage to provide one, you'll almost certainly be able to show them how to do the job better in Icon. You're more likely to win if you can get them to agree to a direct comparison of particular programs that do the same job. ------ John David Stone - Lecturer in Computer Science and Philosophy ----- -------------- Manager of the Mathematics Local-Area Network -------------- -------------- Grinnell College - Grinnell, Iowa 50112 - USA -------------- ---------- stone@math.grin.edu - http://www.math.grin.edu/~stone/ --------- From icon-group-sender Sat Oct 21 15:11:00 1995 Received: by cheltenham.cs.arizona.edu; Sat, 21 Oct 1995 16:41:56 MST Message-Id: <9510211511.AA07893@ns1.computek.net> Mime-Version: 1.0 Content-Length: 3159 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Sat, 21 Oct 95 15:11 CDT From: gep2@computek.net Subject: Perl vs Icon To: cdt@post.its.mcw.edu, icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >Real world problem here. Perl vs Icon. On a given unix system I've been using Icon quite successfully for: > o Scripting o Small programs and utilities o Data conversions >Mostly in the role of system admin. Sounds to me like you have demonstrated quite adequately the workability of your approach... you've been doing it, and it works. >However, some new backup sys admins have been brought on and their recommendation is to scrap this Icon stuff and standardize on Perl, because : > o They know Perl SHIT, they probably know C, too... not a good reason to change to that! > o They don't know Icon They didn't USED to know Perl... > o Thousands of sys admins can't be wrong Hey, the standard language USED to be Fortran... > o There's two of them and one of me So might makes right, huh? > o They're closer to the CIO than I am ...and so they're going to stomp on you, mostly just because they can get away with it, huh? >And so I find myself on the defensive. I don't want to start flaming and look like a raving fanatic in mgt eyes, but has anyone been through such a coup? And is there any advice or or layout of reason I could use defense of Icon. Generally, I can justify using SNOBOL4 or Icon based on: 1) reduced development and debugging time 2) smaller, simpler applications programs 3) easier maintainability due to smaller program size 4) versatility and power in adapting to more demanding requirements in the future As for (2), you can usually demonstrate this by taking a common Perl script (or better yet, one they've written) and coding it up in SNOBOL4 or Icon that's half the size (and, often, more tolerant of formatting and other details, more robust, etc. etc.). If you can turn the tables on them and make it look like THEY are the ones pressing to stay with an older, less versatile and less powerful technology just because they don't want to move to a more cost-effective and powerful one, and that they would hold the company back just to avoid learning a newer and better tool, then you can help make them look like the horses' asses they are. >Right now, all I have to offer is years of reliable running (but Perl has that on some other systems too), and that I've written over 100 programs to support this particular system. I've also developed my own software chip library, in addition to the IPL, and that helps a lot with productivity and code reuse. Sounds to me like a reasonably powerful argument too. >I am already aware of one answer, "Learn Perl, it's a marketable trade." No sweat, it probably can be mastered in a weekend with a good manual, but my goal is to defend Icon, and maybe uplift the consciousness of some. I think you probably ought to look at Perl, at least well enough that you can explain from a VERY informed point of view why Icon is so much better, and so much more cost-effective for your company's needs. :-) >Even though I think my real problem is politics. Sure. The important part in a political discussion is to never look like the person who does NOT know what they're talking about. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Sat Oct 21 22:23:12 1995 Received: by cheltenham.cs.arizona.edu; Mon, 23 Oct 1995 00:15:42 MST Date: Sat, 21 Oct 1995 22:23:12 -0400 From: Paul Abrahams Message-Id: <199510220223.WAA10092@equinox.shaysnet.com> To: icon-group@cs.arizona.edu Subject: Icon vs. Perl Errors-To: icon-group-errors@cs.arizona.edu I certainly know Icon but I've never bothered to learn Perl. So here's a question relative to Chris Tenaglia's predicament: is there anything one can do in Perl that one can't do in Icon (assuming equal familiarity with both)? Paul Abrahams From icon-group-sender Sat Oct 21 23:17:12 1995 Received: by cheltenham.cs.arizona.edu; Mon, 23 Oct 1995 00:17:17 MST To: icon-group@cs.arizona.edu Subject: Re: Perl vs Icon Message-Id: <814317432@mse> Date: Sat, 21 Oct 95 23:17:12 UTC From: whm@mse.com (William H. Mitchell) Errors-To: icon-group-errors@cs.arizona.edu From: "Chris D. Tenaglia" Subject: Perl vs Icon To: icon-group@cs.arizona.edu Real world problem here. Perl vs Icon. On a given unix system I've been using Icon quite successfully for: o Scripting o Small programs and utilities o Data conversions Mostly in the role of system admin. However, some new backup sys admins have been brought on and their recommendation is to scrap this Icon stuff and standardize on Perl, because [of five bad reasons]. And so I find myself on the defensive. I don't want to start flaming and look like a raving fanatic in mgt eyes, but has anyone been through such a coup? You say you've got a lot of existing Icon code that does real work. If the two new guys want to throw that code out and rewrite it in perl, they're more interested in writing perl than getting work done. As both languages come out of the box I'd have to agree perl is the more ready to use for system administration because of the broad system interface. But, I think Icon has a much more solid core language. It's easy to add a routine to do this or do that, but if the core language is weak, that's hard to overcome. I am already aware of one answer, "Learn Perl, it's a marketable trade." No sweat, it probably can be mastered in a weekend with a good manual... Only if you've got a strong stomach! :-) perl was becoming popular at about the time the time I was starting to move away from system adminstration work. I'd been using Icon for SA programming, but since perl was spoken of highly by other SA's I got it and printed up the man page, the only documentation at the time. I tried to read it, but finally decided to wait for a book. Well, "Programming perl" came out and I bought it. I started reading it and gave up in disgust. I'd never been bombarded by such an uncohesive set of rules for a language. The book sat on the shelf for a while, perl continued to gain in popularity, and I continued to use Icon. I decided to give perl another chance and started reading the book again. I again quit in disgust. Shortly after that I moved away from all system administration responsibilities and I stopped worrying about perl. Last Fall, I attended the Usenix Very High Level Language conference in Santa Fe. The first day of conference featured (I thought) tutorials on various languages, one of which was perl and was being given by Larry Wall. I said, Ok, here's another chance to learn about perl. If memory serves, Mr. Wall devoted the tutorial to new features in version 5 of perl. Oh well. Recently, after I gave a presentation on Icon, a person in the audience approached me and said I should take a look at perl. I told them my sad story about trying to learn perl and they responded by loaning me a copy of "Learning perl", by Schwartz. I found it to be much more readable than "Programming perl" and I made it through the whole book. Instead of being disgusted by perl I'm now simply unimpressed. But back to your problem, I'd simply argue for coexistence. If the perl twins can best get their work done with perl, let them. If you can do your work best with Icon, you should be able to use it. The best observation I've heard regarding programmng languages is this: The hobbyist can afford to religiously stick with one language for everything, but the professional programmer uses whatever is necessary to best get the job done. (Roughly paraphrased from Grady Booch.) If these guys are open minded, offer a deal: you read a perl book and they read the Icon book. Maybe you'll expand their horizons and maybe in learning more about perl you'll be able to better argue for Icon. In learning perl, I discovered some interesting idioms that I'll express in Icon with procedures, but I found no motivation to put peril in my toolbox. /------------------------------\ /----------------\ / William H. Mitchell \ / 7120 E. Kiva Way \ / Mitchell Software Engineering \o----/ Tucson, AZ, 85715 \ \ Consulting/Development/Training / \ 520-577-6431 / \ OO Methods/C++/Icon/UNIX / \ whm@mse.com / \------------------------------/ \----------------/ From icon-group-sender Sun Oct 22 13:27:00 1995 Received: by cheltenham.cs.arizona.edu; Mon, 23 Oct 1995 00:17:55 MST From: Nick Williams Message-Id: <199510221727.NAA12878@styx.ios.com> Subject: Could an embedded Icon interpreter rival Java? To: icon-group@cs.arizona.edu Date: Sun, 22 Oct 1995 13:27:00 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 923 Errors-To: icon-group-errors@cs.arizona.edu I understand that MT Icon can load ucode files dynamically. If this is so, and if the Icon executor could be adapted into an embedded interpreter library it could probably be used in the same sort of way that Java is being used. The interpreter would have to be crippled in some ways so as to enhance security (restrict file IO and manipulation, restrict loadfunc(), etc.). Additionally, link declarations in Icon could be made to use URLs for referring to other modules. I suspect most of the effort needed would be spent adapting the executor into an embedded library. I have no idea how complex this would be. Is there any interest on the part of the Icon project? Should this idea be proposed in any other mailing-lists? Also, where can I get documentation on ucode, the translator and the interpreter? What is the ISBN of "The Implementation of Icon"? Would that book be any use today, or is it too outdated? Nick From icon-group-sender Mon Oct 23 15:05:33 1995 Received: by cheltenham.cs.arizona.edu; Mon, 23 Oct 1995 16:55:34 MST To: icon-group@cs.arizona.edu Date: 23 Oct 1995 15:05:33 -0400 From: davidf@mks.com (David J. Fiander) Message-Id: <46gp1u$slb@deci.mks.com> Organization: Mortice Kern Systems, Inc. Sender: icon-group-request@cs.arizona.edu Subject: embedding iconx? Errors-To: icon-group-errors@cs.arizona.edu Since embedding one's favourite VHLL interpreter in another application seems to be all the rage these days, I was wondering if anybody had considered making iconx embeddable. - David From icon-group-sender Tue Oct 24 10:51:53 1995 Received: by cheltenham.cs.arizona.edu; Tue, 24 Oct 1995 08:57:50 MST To: icon-group@cs.arizona.edu Date: Tue, 24 Oct 1995 10:51:53 GMT From: dkenny@atlantis.actrix.gen.nz (Des Kenny) Message-Id: Organization: Actrix - Internet Services Sender: icon-group-request@cs.arizona.edu References: , , <462sdg$qqs@archangel.terraport.net> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In article <462sdg$qqs@archangel.terraport.net>, Red to Black Management wrote: > In article , > CHENANDRE@urvax.urich.edu (Andrew Shi-hwa Chen) wrote: > >> > Perl is used for CGI scripting and general tools work, and runs > >> > not just on Unix, but also VMS, MVS, MsDOS, NT, Amigas, Macs, and > >> > many other systems as well. I would not say its use is restricted > >> > to Unix sysadmins, and if you haven't looked at it in the last five years, > >> > then you are probably working under some misunderstandings about the > >> > language. > > > I'm presently working with Appware from Novell, it works on macs and PC's. > If you purchase the CD version both Mac & PC are included. I find it better > then Visual Basic. You can also write custom objects called ALM's > for constant reuse. Worth to look at. > > Marcel Are these Objects or "Components"? It is all a bit confusing. I have seen one definition that makes a strong distinction: Objects have inheritance and consequently polymorphism. Components do not have inheritance and so no polymorphism. I think some people call "Component" systems Object-Based systems in contrast to Object-Oriented Systems. The word Component may be a better way to separate out the concepts of "objects" that belong to an explicit type hierarchy ( object-oriented inheritance) and "objects" that have no explicit type hierarchy ( encapsulated modules with no explicit ancestors). Personally I prefer to have an explicit type hierarchy. Components are a sort of orphan concept, little waif modules that have no sense of belonging to the big picture of life. Of course designing a type hierarchy is no overnight task and it is understandable that some may shy away from it at first blush and lean towards the apparently simpler component approach. Unfortunately, the benefits of the more simplistic approach are considerably less than the more advanced approach. In the longer term it is a better choice to classify knowledge into a more manageable , more meaningfull structure than a collection of orphan components. All science eventually collects information into classification structures - it is the only way to comprehend and retrieve the rapidly growing body of knowledge. Type hierarchies are a sign that software is entering a new phase of maturity as a body of knowledge. Cheers Des Kenny dkenny@swell.actrix.gen.nz From icon-group-sender Tue Oct 24 09:09:25 1995 Received: by cheltenham.cs.arizona.edu; Tue, 24 Oct 1995 12:31:49 MST From: mitch@roll.csd.sgi.com (Tom Mitchell) Message-Id: <199510241609.JAA02791@roll.csd.sgi.com> Subject: Re: embedding iconx? To: icon-group@cs.arizona.edu Date: Tue, 24 Oct 1995 09:09:25 -0700 (PDT) In-Reply-To: <46gp1u$slb@deci.mks.com> from "David J. Fiander" at Oct 23, 95 03:05:33 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 283 Errors-To: icon-group-errors@cs.arizona.edu The obvious -- would be to mung it into perl. ;-) Would anyone even notice.? > > Since embedding one's favourite VHLL interpreter in another application > seems to be all the rage these days, I was wondering if anybody had > considered making iconx embeddable. > > - David > From icon-group-sender Wed Oct 25 12:09:22 1995 Received: by cheltenham.cs.arizona.edu; Wed, 25 Oct 1995 08:48:50 MST To: icon-group@cs.arizona.edu Date: Wed, 25 Oct 1995 12:09:22 GMT From: borbor@divsun.unige.ch (Boris Borcic) Message-Id: Organization: TECFA - University of Geneva Sender: icon-group-request@cs.arizona.edu References: <307EA1EF.4DE1@mty.sca.sony.com> Subject: Translating Icon to Lisp or Prolog (Re: icon and java) Errors-To: icon-group-errors@cs.arizona.edu In article <307EA1EF.4DE1@mty.sca.sony.com>, Eric Brown wrote: > Icon and Java seem very similiar: > * Both look like C > * Both have garbage collection > * Both have a p-code/VM implementation (see note 1 below) > > Has anybody thought about modifying the icon compilier to generate > instructions for the Java VM? > Discussing targets for Icon compilation, has anybody considered : - Common lisp + screamer (nondeterminism package) - Prolog variants with destructive assignment (e.g. Life, Aquarius ?) Both language variants appear to me as pretty close to icon (based on doc, I've not programmed in Icon). There are good compilers for CL; I am not certain about Aquarius Prolog's destructive assignment's adequation to emulate Icon assignment, but (in the case it is) it's rumored as a very good PD compiler. Both might provide feasible paths to fast executables for Icon. Regards, Boris Borcic rom icon-group-sender Wed Oct 25 12:47:41 1995 Received: by cheltenham.cs.arizona.edu; Wed, 25 Oct 1995 08:49:05 MST To: icon-group@cs.arizona.edu Date: 25 Oct 1995 12:47:41 GMT From: Balaji Srinivasa Message-Id: <46lble$5en@alterdial.UU.NET> Organization: CGI Systems Sender: icon-group-request@cs.arizona.edu References: , <462sdg$qqs@archangel.terraport.net>, Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In that case take a look at Python http://www.python.org it might take care of your needs From icon-group-sender Wed Oct 25 13:15:42 1995 Received: by cheltenham.cs.arizona.edu; Wed, 25 Oct 1995 08:49:21 MST To: icon-group@cs.arizona.edu Date: 25 Oct 1995 13:15:42 GMT From: rtor@ansa.co.uk (Owen Rees) Message-Id: <46ld9u$o5v@plato.ansa.co.uk> Organization: ANSA Sender: icon-group-request@cs.arizona.edu References: , <462sdg$qqs@archangel.terraport.net>, Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu Des Kenny (dkenny@atlantis.actrix.gen.nz) wrote: : Are these Objects or "Components"? It is all a bit confusing. : I have seen one definition that makes a strong distinction: : Objects have inheritance and consequently polymorphism. Object does not imply inheritance - see Wegner's taxonomy and his distinction between object-based and object-oriented. Inheritance is neither necessary nor sufficient for polymorphism. See Cardelli and Wegner on polymorphism, and consider a subclass that redefines everything it has inherited. Inheritance can be used to create useful type relationships including polymorphism but this is not an inevitable consequence of using inheritance. Remember that "better" and "progress" are meaningless in the absence of a system of measurement and that "more" and "less" are just a matter of sign convention until related to a real problem. Attempts to compare programming languages without reference to a system of values, or a problem to be solved, are a waste of time. Conjecture: for all programming languages L there exists some context and system of values in which L is 'best'. -- Owen Rees , Information about ANSA is at . From icon-group-sender Wed Oct 25 11:27:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 25 Oct 1995 12:25:43 MST Message-Id: <9510251127.AA03601@ns1.computek.net> Mime-Version: 1.0 Content-Length: 2729 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 25 Oct 95 11:27 CDT From: gep2@computek.net Subject: Translating Icon to Lisp or Prolog (Re: icon and java) To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >> Has anybody thought about modifying the icon compilier to generate > instructions for the Java VM? >Discussing targets for Icon compilation, has anybody considered : - Common lisp + screamer (nondeterminism package) - Prolog variants with destructive assignment (e.g. Life, Aquarius ?) >Both language variants appear to me as pretty close to icon (based on doc, I've not programmed in Icon). I'm surprised that someone who hasn't even bothered to program in Icon would hang out here. You ought to try it!! Come on in, the water's fine! :-) >There are good compilers for CL; I am not certain about Aquarius Prolog's destructive assignment's adequation to emulate Icon assignment, but (in the case it is) it's rumored as a very good PD compiler. >Both might provide feasible paths to fast executables for Icon. I must confess to being rather surprised and perhaps amused at all the apparent interest in trying to compile Icon down into the model of other high-level languages. Other than the purely academic challenge of doing so, I really don't see much point in this. First, there's already a compiler (more or less) for Icon which reduces an Icon program to C (not Lisp, not Prolog, not Perl). And numerous good C compilers (including public domain ones) exist. Second, the whole point of Icon was to create a language with novel features and constructs not well supported (or not supported at all) within existing languages. It's not as if the only difference between Icon and these other languages is merely cosmetic. Third, there are many languages (like Icon) where even in a "compiled" program, the vast majority of the execution time is spent in the library routines. Whether those routines are linked into the program, or built into an "interpreter", those routines still in either case run in native mode and are going to execute in very nearly the same amount of time. The overhead of interpreting the code can be VERY low (possibly even less than the overhead of even just loading a much larger direct-executable). And from a systems standpoint, which would you rather have... A system of 500 "compiled" programs of 3-10K each, plus a 250K interpreter? Or a system of 500 "directly executable" programs, each containing a redundant copy of the runtime library, and consuming (say) 150K each? In the "interpreter" case, you can upgrade your whole system with a corrected version of the interpreter by updating one file. In the compiled case, you will have to recompile and (or at least) relink all of your 500 programs to incorporate a new and corrected update to the runtime library. Which makes more sense??? Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Oct 25 20:38:06 1995 Received: by cheltenham.cs.arizona.edu; Thu, 26 Oct 1995 08:35:20 MST To: davidf@mks.com Subject: Re: embedding iconx? Cc: icon-group@cs.arizona.edu Message-Id: <814653486@mse> Date: Wed, 25 Oct 95 20:38:06 UTC From: whm@mse.com (William H. Mitchell) Errors-To: icon-group-errors@cs.arizona.edu From rcm!sashimi!cs.arizona.edu!icon-group-sender Tue Oct 24 03:15:09 1995 From: davidf@mks.com (David J. Fiander) Subject: embedding iconx? Since embedding one's favourite VHLL interpreter in another application seems to be all the rage these days, I was wondering if anybody had considered making iconx embeddable. Once upon a time I embedded iconx in Gosling's Emacs. I wrote a U of Arizona CS Department report (TR 84-8) about the project, but I don't know if the report is still available or not. (The software is definitely not available any more!) It would be interesting to think about a broadly usable interface that applications could provide for the use of an embedded interpreter. To some extent, I suppose that's what OLE and OpenDoc try to provide. From icon-group-sender Thu Nov 2 19:26:00 1995 Received: by cheltenham.cs.arizona.edu; Fri, 3 Nov 1995 08:22:19 MST Message-Id: <199511030027.TAA00984@transfer.stratus.com> Date: Thu, 2 Nov 95 19:26 EST From: Steve_Graham@vos.stratus.com To: icon-group@cs.arizona.edu Subject: Graphics Question Errors-To: icon-group-errors@cs.arizona.edu I have just started using Icon ver 9 for Windows NT and I have a question. I would like to be able to do 3 things: . Clear a window . Go to a cursor position in the window . Write text to a window When I try to use GotoXY(x,y) to do the second item, the system responds with an error: Run-time error 140 Window expected Offending value: &null What did I do wrong? How can I do the above actions? Thanks in advance for the help. Steve Graham Steve_Graham@vos.stratus.com From icon-group-sender Sat Nov 4 01:53:49 1995 Received: by cheltenham.cs.arizona.edu; Sat, 4 Nov 1995 07:02:15 MST Return-Path: Date: Sat, 4 Nov 95 01:53:49 UT From: "Eric Armstrong" Message-Id: To: "'icon-group@cs.arizona.edu'" Subject: Icon and OLE? Errors-To: icon-group-errors@cs.arizona.edu OLE is microsoft's new mechanism for sharing binary objects. My initial reading of it is that is pretty impressive. Time will tell whether the fire remains undimmed. One of OLE's potential windfalls is OLE Automation. This mechanism allows any OLE object that exports its API to be driven by any other application, regardless of the language its written in. If I read this right, there is a brand new capacity to create "command scripts" that use any number of powerful utilities to achieve its ends. (And not statically, either, since one of OLE's functions is to permit querying objects to find out what interfaces they support.) OLE would therefore seem to open up a couple of great markets for Icon developers. One market would be to give other languages (like the woefully deficient Visual Basic), access to Icon's powerful data structures by encapsulating them in a program that exports an OLE interface. Another opportunity might be setting up Icon as an OLE-aware scripting tool, making it the "command language" of choice for Windows automation. I would like to see Icon take advantage of one of both of these opportunities so it can develop a larger base of users. (I look forward to the Windows 95 version.) I must point out, however, that the name "Icon" will create visibility problems in a windowing world, since it will be immediately assumed that it is some kind of tool for making pretty little pictures. (But of course, you know that.) From icon-group-sender Sat Nov 4 15:42:21 1995 Received: by cheltenham.cs.arizona.edu; Sun, 5 Nov 1995 22:33:56 MST Date: Sat, 4 Nov 1995 15:42:21 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9511042142.AA17722@dragon.cs.utsa.edu> To: EricArmstrong@msn.com Cc: icon-group@cs.arizona.edu In-Reply-To: (EricArmstrong@msn.com) Subject: Re: Icon and OLE? Content-Length: 1209 Errors-To: icon-group-errors@cs.arizona.edu [Eric Armstrong made several good points in favor of Windows Icon adding OLE support. ] OLE support would add a great deal of usefulness to Icon for Windows users. Like most features, it will only happen if a user volunteers to write it and contribute the code to the public domain, or if someone funds it. The "reference port" of Windows Icon has been a volunteer effort on my part, with hardware assistance from Icon Project and a software donation from Microsoft allowing the work to be done. Most of Icon's development was the result of a funded research program, but the user community has contributed substantially, with ports to many platforms, and major features such as arbitrary precision integers. Although I am not volunteering to do the OLE support at present, I am pursuing a variety of improvements to Icon in San Antonio (http://www.cs.utsa.edu/research/icon/icon.html has a partial list) with help from interested students. When such improvements become stable, I offer the code to Arizona, or make it available from here. If anyone has suggestions, or wants to help, I always appreciate your comments. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Sat Nov 4 15:27:47 1995 Received: by cheltenham.cs.arizona.edu; Sun, 5 Nov 1995 22:34:22 MST To: icon-group@cs.arizona.edu Date: 4 Nov 1995 15:27:47 GMT From: ac865@freenet.hamilton.on.ca (Bill Bell) Message-Id: <47g0pj$3rf@main.freenet.hamilton.on.ca> Organization: Hamilton-Wentworth FreeNet, Ontario, Canada. Sender: icon-group-request@cs.arizona.edu Subject: Q: Interactive Development Environment Errors-To: icon-group-errors@cs.arizona.edu -- I just love Icon but there is one thing that keeps me from embracing it fully. Is there a developer's workbench (aka an interactive development environment) for Icon? Even an antique one, resembling what used to come with Borland Pascal years ago--particularly if I could use the same workbench for both MS-DOS or Windows and HPUX--would be very useful. Has anyone seen such a beast? TIA. - Bill From icon-group-sender Mon Nov 6 09:21:39 1995 Received: by cheltenham.cs.arizona.edu; Mon, 6 Nov 1995 12:26:55 MST Date: Mon, 6 Nov 1995 09:21:39 -0800 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <9511061721.AA21143@orville.orville.premenos.com.> To: icon-group@cs.arizona.edu Subject: an observation on Icon semantics X-Sun-Charset: US-ASCII Errors-To: icon-group-errors@cs.arizona.edu I few months ago there was a discussion on whether DeMorgan's Law "worked" in Icon. We concuded that it did. However, I've realized that an equivalence relationship in boolean algebra does not apply to all Icon expressions. In general, ~== "A" and not ( == "A") produce different success/failure results when is a generator. For example !strings ~== "A" succeeds if there exists an element x in strings such that x ~== "A", but not (!strings == "A") succeeds if there does not exist an x in strings, such that x == "A". This is the same as saying that for all x in strings, x ~== "A". The difference in semantics is the difference between "there exists" and "for all". It's nice to know that there is a short expression like not (!strings ~== "A") which succeeds when all elements of strings equal "A", but to me it looks a little perverse :-) Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Mon Nov 6 19:36:00 1995 Received: by cheltenham.cs.arizona.edu; Tue, 7 Nov 1995 06:43:08 MST Message-Id: <199511070037.TAA15823@transfer.stratus.com> Date: Mon, 6 Nov 95 19:36 EST From: Steve_Graham@vos.stratus.com To: icon-group@cs.arizona.edu Cc: Steve_Graham@vos.stratus.com Subject: Determining cursor position Errors-To: icon-group-errors@cs.arizona.edu If I have opened a window and written some text to it, how do I find the x,y coordinates of the position immediately following the last character which I output? Thanks. Steve Graham Steve_Graham@vos.stratus.com From icon-group-sender Mon Nov 6 19:56:55 1995 Received: by cheltenham.cs.arizona.edu; Tue, 7 Nov 1995 06:43:27 MST To: icon-group@cs.arizona.edu Date: 6 Nov 1995 19:56:55 GMT From: worf!davidf@agate.berkeley.edu (David J. Fiander) Message-Id: <47lpa7$5gi@ia.mks.com> Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA Sender: icon-group-request@cs.arizona.edu Subject: An odd bit of code Errors-To: icon-group-errors@cs.arizona.edu This code is from the Icon programming library program "c2icn": while line := trim(read(),' \t') do line ? { line := comment := "" They're scanning C source here. What I find interesting is the intialisation of "line" on the second line. Since it's in the string scanning environment, I would guess that &subject points at the input line, so "line" can be set to "" to start building the output. I'm just wondering if this code is guaranteed to work, or if it's just chance? From icon-group-sender Tue Nov 7 15:01:41 1995 Received: by cheltenham.cs.arizona.edu; Tue, 7 Nov 1995 12:22:20 MST Date: 07 Nov 95 15:01:41 GMT From: R J Hare Subject: Determining cursor position To: icon-group@cs.arizona.edu Organisation: Edinburgh University Computing Services Message-Id: <9511071501.aa15271@uk.ac.ed.festival> Errors-To: icon-group-errors@cs.arizona.edu > If I have opened a window and written some text to it, how do I find the x,y > coordinates of the position immediately following the last character which I > output? > > Thanks. > > Steve Graham Me too! I was just about to send the message. Is there a library routine which allows me to convert columns & rows to x,y positions? Roger Hare From icon-group-sender Tue Nov 7 19:00:40 1995 Received: by cheltenham.cs.arizona.edu; Wed, 8 Nov 1995 06:23:56 MST Date: Tue, 7 Nov 95 19:00:40 CST From: yak@comm.mot.com (Yarko Tymciurak) Message-Id: <9511080100.AA07218@platov8> To: icon-group@cs.arizona.edu Subject: Re: Determining cursor position Errors-To: icon-group-errors@cs.arizona.edu | Date: 07 Nov 95 15:01:41 GMT | From: R J Hare | Subject: Determining cursor position | To: icon-group@cs.arizona.edu | | > If I have opened a window and written some text to it, how do I find | the x,y | > coordinates of the position immediately following the last character which I | > output? | > | > Thanks. | > | > Steve Graham | | | Me too! I was just about to send the message. | | Is there a library routine which allows me to convert columns & rows to x,y | positions? | | Roger Hare | Example: link graphics procedure main() WOpen() WWrites( "hello" ) # no new line; leaves cursor at end of "hello" x := WAttrib("x") # captures canvas pixel coordinates y := WAttrib("y") WWrite( "\nx = ", x, "\ny = ", y) WDone() end See Appendix C of IPD255 for more info. Yarko From icon-group-sender Thu Nov 9 12:43:18 1995 Received: by cheltenham.cs.arizona.edu; Thu, 9 Nov 1995 16:20:52 MST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Nov 1995 12:43:18 -0800 To: worf!davidf@agate.berkeley.edu (David J. Fiander), icon-group@cs.arizona.edu From: bobalex@netcom.com (Bob Alexander) Subject: Re: An odd bit of code Errors-To: icon-group-errors@cs.arizona.edu >This code is from the Icon programming library program "c2icn": > > while line := trim(read(),' \t') do line ? { > line := comment := "" > >They're scanning C source here. What I find interesting is the >intialisation of "line" on the second line. Since it's in the >string scanning environment, I would guess that &subject points >at the input line, so "line" can be set to "" to start building >the output. > >I'm just wondering if this code is guaranteed to work, or if it's >just chance? It's guaran-dang-teed to work! The assignment of "" to line assigns a separate string object to line and has nothing to do with the former value of line (which was previously assigned to &subject). I've used that technique in a few places to avoid creating an unneeded variable, but I've often wondered whether the potential to be confusing is worth the "savings". Bob Alexander bobalex@netcom.com From icon-group-sender Fri Nov 10 14:58:00 1995 Received: by cheltenham.cs.arizona.edu; Fri, 10 Nov 1995 16:26:32 MST Message-Id: <199511102023.PAA25400@transfer.stratus.com> Date: Fri, 10 Nov 95 14:58 EST From: Steve_Graham@vos.stratus.com To: icon-group@cs.arizona.edu Cc: Steve_Graham@vos.stratus.com Subject: Out of memory errors Errors-To: icon-group-errors@cs.arizona.edu I have developed a program under Icon which is 58066 bytes in size and when I try to run icont against it I get the following messages/errors: DOS Extender: Error X0135: Extended memory exhausted during application load DOS Extender: Error X0134: Insufficient extended memory DOS Extender: Error X0130: Failure detected during program load I had run in to similar problems under ver 8.8 (DOS running under Windows for Workgroups), but switching to Ver 9 seemed to fix the problem. I have not had any problems under the NT Ver 9. Any ideas? Thanks. Steve Graham Senior Technical Consultant S2 Systems, Inc. (Steve_Graham@vos.stratus.com) From icon-group-sender Fri Nov 10 18:45:06 1995 Received: by cheltenham.cs.arizona.edu; Sat, 11 Nov 1995 10:04:15 MST Date: Fri, 10 Nov 1995 18:45:06 -0500 (EST) From: "Phillip L. Thomas" To: Steve_Graham@vos.stratus.com Cc: icon-group@cs.arizona.edu, Steve_Graham@vos.stratus.com Subject: Re: Out of memory errors In-Reply-To: <199511102023.PAA25400@transfer.stratus.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu I generally get the problem after doing C during a series of badly thought out compiles. Just shut your computer off for 5 seconds and try again. Phillip Lee Thomas Library of Congress On Fri, 10 Nov 1995 Steve_Graham@vos.stratus.com wrote: > I have developed a program under Icon which is 58066 bytes in size and when I > try to run icont against it I get the following messages/errors: > > DOS Extender: Error X0135: Extended memory exhausted during application > load > DOS Extender: Error X0134: Insufficient extended memory > DOS Extender: Error X0130: Failure detected during program load > > I had run in to similar problems under ver 8.8 (DOS running under Windows > for Workgroups), but switching to Ver 9 seemed to fix the problem. I have > not had any problems under the NT Ver 9. > > Any ideas? > > Thanks. > > Steve Graham > Senior Technical Consultant > S2 Systems, Inc. > (Steve_Graham@vos.stratus.com) > > From icon-group-sender Sun Nov 12 20:23:40 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 10:43:36 MST To: icon-group@cs.arizona.edu Date: 12 Nov 1995 20:23:40 GMT From: john@nmt.edu (John Shipman) Message-Id: <485l4c$erl@newshost.nmt.edu> Organization: New Mexico Tech Computer Center Sender: icon-group-request@cs.arizona.edu Subject: Comparing sets for equality Errors-To: icon-group-errors@cs.arizona.edu I need an Icon function to test two sets to see if they're identical. Is there an operator that does this, that I have somehow missed? If not, here's how I implemented it. I reasoned that if the two sets are the same size, and their set difference is zero, then they must be identical. Questions: 1. Is my reasoning correct? 2. Is this more or less the fastest way to do this? 3. Is there anything wrong with my implementation (below)? ---------------------------------------------------------------- #-[ If x and y are sets with identical elements -> # returns y # | else if x and y are sets with non-identical elements -> # fails #-] procedure Set_Equal ( x, y ) if ( ( * x ) = ( * y ) ) & # If element counts are the same... ( ( * ( x -- y ) ) = 0 ) then # ...and set difference is empty return y else fail; end John Shipman, js@cs.nmt.edu, http://www.nmt.edu/~john Zoological Data Processing, 507 Fitch NW, Socorro, NM 87801 USA From icon-group-sender Sat Nov 18 15:55:45 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 10:44:02 MST To: icon-group@cs.arizona.edu Date: 18 Nov 1995 15:55:45 +0100 From: janpeter@mpi.nl (Jan-Peter de Ruiter) Message-Id: Organization: Max-Panck Institut f|r Psycholinguistik, Nijmegen, the Netherlands Sender: icon-group-request@cs.arizona.edu References: <485l4c$erl@newshost.nmt.edu> Subject: Mathematical sets in Icon (Re: Comparing sets for equality) Errors-To: icon-group-errors@cs.arizona.edu In article <485l4c$erl@newshost.nmt.edu> john@nmt.edu (John Shipman) writes: I need an Icon function to test two sets to see if they're identical. Is there an operator that does this, that I have somehow missed? No, this is a problem. A few years ago we discussed this problem here too, and Icon's definition of identical is not the mathematical definition, because implementing it in the mathematically correct way will decrease Icon's performance, if I remember correctly. Your solution will only work partially. If you insert the same string twice, Icon will think there's two elements in your set, which is not the way it should work, if you think of sets as mathematical sets. Here's a complete implementation that I wrote to solve this problem. It can also be used to check if two Icon values are identical in the sense that they have the same values (not that they refer to the same objects). If there's anyone from the Icon project who likes to put this extension in the IPL, please be my guest. Greetings, Jan ############################################################################# # MSET LIBRARY # # # # by Jan P. de Ruiter, 1992 # # Public domain software. # # # # Implements the "mset" type. # # # # The idea of the mset type is that no two identical data-structures can be # # present in a set, where identity is defined as "containing the same # # elements". # # # # This seemingly radical idea is actually quite common in mathematics. :-) # # # # Definitions implicit in the procedure same_value(..,..): # # # # TYPE IDENTITY TEST # # # # all types === and if this test fails... # # # # integer = # # real = # # cset, string == # # record all fields have same value # # list all elements are the same, and the ordering is the same # # table same keys, and every key has the same associated value # # set contain the same elements # # # ############################################################################# # # This is the core routine. # It succeeds if two things have the same value(s). # procedure same_value(d1,d2) if d1 === d2 then return # same object else if type(d1) ~== type(d2) then fail # not the same type else if *d1 ~= *d2 then fail # not the same size else case type(d1) of { # the same type and size ("set" | "table" ) : return same_elements(sort(d1,1),sort(d2,1)) ("list") : return same_elements(d1,d2) ("real" | "integer") : return(d1 = d2) ("cset" | "string" ) : return(d1 == d2) default : return same_elements(d1,d2) # user defined type } end # # used in same_value: # procedure same_elements(l1,l2) if l1 === l2 then return # same objects else if *l1 ~= *l2 then fail # not the same size else { if *l1 = 0 then return # both lists empty else { every(i := 1 to *l1) do if not same_value(l1[i],l2[i]) then fail # recursion return } } end # # The new insert operation. Insert2 always succeeds # procedure insert2(S,el) if same_value(el,!S) then return return insert(S,el) end # # The new member operation, that also detects equal-valued elements # procedure member2(S,el) if same_value(!S,el) then return fail end # # The new delete operation, that detects equal-valued elements. # Always succeeds # procedure delete2(S,el) every(t := !S) do if same_value(t,el) then return delete(S,t) return end # # conversion of standard icon set into new mset. # procedure reduce(iset) temp := set() every(insert2(temp,!iset)) return temp end From icon-group-sender Sun Nov 19 16:28:03 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 10:46:08 MST To: icon-group@cs.arizona.edu Date: Sun, 19 Nov 1995 16:28:03 -0500 From: Mik Kvitchko Message-Id: <30AFA163.6D76@cnj.digex.com> Organization: MIKSoft, Inc. Sender: icon-group-request@cs.arizona.edu References: <48lp3j$k0r@ixnews6.ix.netcom.com> Subject: Re: Any method of editing/changing an .exe icon? Errors-To: icon-group-errors@cs.arizona.edu skye wrote: > > Hi everybody, > > Is there just no way to do the above given DOS > limitations? I've got a program in my start-up > taskbar under Windows 95 that has the butt-ugliest > icon, I'd give just about anything to give it the > heave ho. Suggestions? > > skye :) > frnetwrk@ix.netcom.com Any resource editor can be used to change the icon of the EXE file, like Borland's Resource Workshop or MS Application Studio. Also there are some other programs that can help with this, IconMaster(?)... -- Mik Kvitchko MIKSoft, Inc. Internet: mik@cnj.digex.com CompuServe: 74127,3671 http://www.cnj.digex.net/~mik/ From icon-group-sender Sat Nov 18 23:09:39 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 10:45:49 MST To: icon-group@cs.arizona.edu Date: 18 Nov 1995 23:09:39 GMT From: frnetwrk@ix.netcom.com (skye ) Message-Id: <48lp3j$k0r@ixnews6.ix.netcom.com> Organization: Netcom Sender: icon-group-request@cs.arizona.edu Subject: Any method of editing/changing an .exe icon? Errors-To: icon-group-errors@cs.arizona.edu Hi everybody, Is there just no way to do the above given DOS limitations? I've got a program in my start-up taskbar under Windows 95 that has the butt-ugliest icon, I'd give just about anything to give it the heave ho. Suggestions? skye :) frnetwrk@ix.netcom.com From icon-group-sender Tue Nov 21 13:39:41 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 10:47:52 MST From: "Hamish Lawson" Organization: University of Teesside (SCM) To: icon-group@cs.arizona.edu Date: Tue, 21 Nov 1995 13:39:41 GMT0BST Subject: Parsing structured text Reply-To: H.Lawson@tees.ac.uk Priority: normal X-Mailer: Pegasus Mail/Windows (v1.22) Message-Id: <5F2E5628FD@scm_arkengarthdale.tees.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu Are there any general techniques for parsing text (and structured text in particular) that may be spread over several lines, e.g. HTML or LaTeX files? Most examples in the Icon book (1st edition) assume that the input can be dealt with a line at a time. What approach should I take when dealing with structured text, such as HTML or LaTeX, in which the entities to be parsed may be embedded inside other entities and may extend over several lines? Do I preprocess the file to make it all just a single line, or split the source text into more logical lines that reflect better the structure of the text. Is it possible to scan across several lines? | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 218121 x3611 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Wed Nov 22 10:23:41 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 12:26:29 MST Date: Wed, 22 Nov 1995 10:23:41 -0800 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <9511221823.AA18673@orville.orville.premenos.com.> To: icon-group@cs.arizona.edu Subject: Re: Parsing structured text X-Sun-Charset: US-ASCII Errors-To: icon-group-errors@cs.arizona.edu > From: "Hamish Lawson" > Date: Tue, 21 Nov 1995 13:39:41 GMT0BST > > Are there any general techniques for parsing text (and structured > text in particular) that may be spread over several lines, e.g. HTML > or LaTeX files? Most examples in the Icon book (1st edition) assume > that the input can be dealt with a line at a time. What approach > should I take when dealing with structured text, such as HTML or > LaTeX, in which the entities to be parsed may be embedded inside > other entities and may extend over several lines? Do I preprocess the > file to make it all just a single line, or split the source text into > more logical lines that reflect better the structure of the text. Is > it possible to scan across several lines? Structured text is usually easiest to parse if you tokenize it. If your version of Icon supports co-expressions, you can write a procedure that uses string scanning to tokenize the text a line at a time, generating the tokens, you can then call the procedure using an argument that generates all the lines you want to tokenize, and finally you can place the entire expression in a co-expression so you can retrieve tokens one at a time at different places in your parser. parse.icn described on p 323 of appendix F of the 2nd edition of the Icon book uses this technique. This program is also in the Icon Program Library. If you don't have co-expressions, you can still use string scanning in a tokenizer that does not generate results, but you have to do more work to keep track of where you left off when the lexical analyser was last called. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Wed Nov 22 12:28:39 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 12:26:39 MST Date: Wed, 22 Nov 1995 12:28:39 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9511221828.AA06617@dragon.cs.utsa.edu> To: janpeter@mpi.nl Cc: icon-group@cs.arizona.edu In-Reply-To: (janpeter@mpi.nl) Subject: Re: Mathematical sets in Icon (Re: Comparing sets for equality) Content-Length: 1323 Errors-To: icon-group-errors@cs.arizona.edu {Jan Peter de Ruiter posts a useful implementation of mathematical sets for Icon, with the commentary:} JPdR> If you insert the same string JPdR> twice, Icon will think there's two elements in your set, which is not JPdR> the way it should work, if you think of sets as mathematical sets. Well, that's not exactly true. Icon has "value semantics" for atomic first class types (integers, reals, strings, csets) and "pointer semantics" for mutable structure types (lists, sets, tables, records). You are OK with sets of strings, but not with sets of sets. And you can't compare two sets for equality with === because it is a pointer comparison. And if some of the elements of your sets can be structures (such as other sets) then you need a full-bore mathematical sets such as Jan Peter implemented. And if your sets can contain themselves (perfectly legal under pointer semantics) then you'd better worry about cycles in your equality test. We could go back and forth about whether mathematical sets are more useful than Icon's mutable-structure sets (I think perhaps they are), but in any case, Icon's set type is a close relative of Icon's table type and Icon's set semantics are consistent with the rest of Icon's structure types. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Wed Nov 22 13:12:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 12:26:50 MST Message-Id: <9511221312.AA17401@ns1.computek.net> Mime-Version: 1.0 Content-Length: 932 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 22 Nov 95 13:12 CST From: gep2@computek.net Subject: Parsing structured text To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >Are there any general techniques for parsing text (and structured text in particular) that may be spread over several lines, e.g. HTML or LaTeX files? Most examples in the Icon book (1st edition) assume that the input can be dealt with a line at a time. What approach should I take when dealing with structured text, such as HTML or LaTeX, in which the entities to be parsed may be embedded inside other entities and may extend over several lines? Personally, the approach I tend to use in most cases like this is to create a super-line which consists of (say) three or four adjacent lines concatenated together. This way, I have the whole construct I want to parse in one string. On the other hand, if you have constructs that are several pages separated from each other, that sorta calls for alternative approaches, outside the scope of a mailing list posting. :-) Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Nov 22 14:10:23 1995 Received: by cheltenham.cs.arizona.edu; Wed, 22 Nov 1995 14:16:06 MST Date: Wed, 22 Nov 1995 14:10:23 -0700 From: Gregg Townsend Message-Id: <9511222110.AA28551@hawk.CS.Arizona.EDU> To: bmonsell@census.gov, js@cs.nmt.edu Subject: Re: Comparing sets for equality Cc: icon-group, icon-project@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Sets are kept in hashed form, and the size is available in constant time. It's certainly worth checking the size first to avoid other work. You'd have to run experiments to see whether union, intersection, or difference would be faster. It might depend on the "usual" case -- whether the sets being compared are typically very similar or very different. If you wanted to be really cryptic you could do something like this: procedure Set_Equal(x, y) return *x = *y = *(x**y) & x end Gregg Townsend / gmt@CS.Arizona.EDU / +1 520 621 4325 / 32 13 45N 110 57 16W Computer Science / Univ of Arizona / 1040 E 4th St / Tucson AZ 85721-0077 From icon-group-sender Sat Nov 25 09:01:33 1995 Received: by cheltenham.cs.arizona.edu; Sat, 25 Nov 1995 15:45:53 MST From: Art Eschenlauer Message-Id: <199511251501.JAA07194@biosci.cbs.umn.edu> Subject: icon configuration for mac - Help To: icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) Date: Sat, 25 Nov 1995 09:01:33 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 783 Errors-To: icon-group-errors@cs.arizona.edu I am trying to port version 9.0 of Macintosh MPW icon to ThinkC 5.0.4. However, I am somewhat stumped when it comes to fixing config.h in particular and, to a lesser extent, define.h and sys.h. Specifically, how do I figure out which features of the language to enable? How do I determine which letters to set in the IconOptions string and in the Usage strings? Do I need a copy of _The Implementation of the Icon Programming Languaage_? Thanks for your help. -art eschen@biosci.cbs.umn.edu (Art Eschenlauer, U of M Agronomy & Plant Genetics) anagram for "information superhighway": in what rough pain of misery "We did not weave the web of life, we are merely a strand in it. Whatever we do to the web, we do to ourselves." - (mis?)attributed to Chief Seattle, ca. 1854 From icon-group-sender Sun Nov 26 11:38:07 1995 Received: by cheltenham.cs.arizona.edu; Mon, 27 Nov 1995 06:50:01 MST Date: Sun, 26 Nov 1995 11:38:07 -0700 From: Gregg Townsend Message-Id: <9511261838.AA01424@hawk.CS.Arizona.EDU> To: eschen@biosci.cbs.umn.edu, icon-group@cs.arizona.edu Subject: Re: icon configuration for mac - Help Errors-To: icon-group-errors@cs.arizona.edu You should get a copy of IPD 238, "Configuring the Source Code for Version 9 of Icon". It's in the /icon/doc subdirectory on ftp.cs.arizona.edu. Gregg Townsend / gmt@CS.Arizona.EDU / +1 520 621 4325 / 32 13 45N 110 57 16W Computer Science / Univ of Arizona / 1040 E 4th St / Tucson AZ 85721-0077 From icon-group-sender Wed Nov 29 01:04:23 1995 Received: by cheltenham.cs.arizona.edu; Wed, 29 Nov 1995 08:35:49 MST Date: Wed, 29 Nov 1995 01:04:23 -0700 (MST) Message-Id: <199511290804.BAA12313@usr4.primenet.com> X-Sender: whm@mailhost.primenet.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: icon-group@cs.arizona.edu From: "William H. Mitchell" Subject: Another introductory book on Icon? Errors-To: icon-group-errors@cs.arizona.edu Several weeks ago I was struck with an urge to write an introductory book on Icon. I've been involved with Icon for a number of years and I'm of course familiar with the Griswolds' book. I think that book is good but I've come to believe that another Icon book would be of use to the programming community. The focus I have in mind for an Icon book is to be more tutorial and less encyclopedic than the Griswolds' book. I think Icon is a very clean language, but it has many important concepts that I think could stand to be explored in more detail than is present in the Griswolds' book. In addition to a more tutorial focus I think another book would have the simple benefit of offering another perspective on the language and how to effectively use it. Also, many idioms have emerged since the Griswolds' book was published and I'd like to cover some of them. I wondered if my urge to write a book on Icon might subside, but I've found myself to be gaining enthusiasm as time passes. I'm writing this note to probe the on-line Icon community to see what interest there might be in another introductory book on Icon. What do you think? Might another book be of possible use? From icon-group-sender Wed Nov 29 18:24:22 1995 Received: by cheltenham.cs.arizona.edu; Wed, 29 Nov 1995 16:21:21 MST From: "Richard L. Goerwitz III" Message-Id: <199511300024.SAA00789@typo.uchicago.edu> Subject: Re: Another introductory book on Icon? To: icon-group@cs.arizona.edu Date: Wed, 29 Nov 1995 18:24:22 -0600 (CST) In-Reply-To: <199511290804.BAA12313@usr4.primenet.com> from "William H. Mitchell" at Nov 29, 95 01:04:23 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Errors-To: icon-group-errors@cs.arizona.edu > I've come to believe that another Icon book would be of use to the > programming community. If you write an Icon book, be sure you have the question of future support nailed down. If you start writing today, it will doubtless be at least 1.5 years before you are in the bookstores, so the lifetime of the language is a concern. Ralph has retired, and most of the former Icon Pro- ject members have since moved on to other things. The language, as such, may not even be around five years from now, except as a legacy system. Then again, some research group might pick it up (or pick up some streamlined version of it) and revitalize it. Ralph was very good about user support, though, and I have to wonder how another acad- emic research group could even come close to what he and his cohorts did from the mid 70s up until the early 90s. Maybe some of the old hands might want to comment. I have to con- fess that the last major project I did in Icon was several years ago. Now I pretty much do everything with shell scripts and C. A derivative language might be nice, because it could fix a lot of old bugs that it is too late to fix now (e.g., the random number generator, the way generation of table elements is done, etc.). But with grants drying up for language research, how could anyone short of a Linus or Larry take this on? -- -Richard L. Goerwitz *** *** r-goerwitz@uchicago.edu From icon-group-sender Thu Nov 30 10:01:06 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 09:06:02 MST Date: Thu, 30 Nov 1995 10:01:06 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9511301601.AA11175@dragon.cs.utsa.edu> To: richard@mithra-orinst.uchicago.edu Cc: icon-group@cs.arizona.edu In-Reply-To: <199511300024.SAA00789@typo.uchicago.edu> (richard@mithra-orinst.uchicago.edu) Subject: Re: Another introductory book on Icon? Content-Length: 1415 Errors-To: icon-group-errors@cs.arizona.edu [Richard Goerwitz' recent message concerning the future of Icon contains important facts, but probably gives some false impressions.] Goer> Ralph has retired, and most of the former Icon Project members Goer> have since moved on to other things. The language, as such, may Goer> not even be around five years from now, except as a legacy system. Ralph Griswold has retired, but is still teaching at Arizona, and still involved with Icon. Most "former Icon Project members" have graduated, so of course they have moved on. The language, as such, will be just fine five years from now, but the NSF is no longer funding a troupe of Ph.D. students at Arizona to make it faster or add new features. As far as support goes, knowledgable people remain active at Arizona and in this group to answer questions. Ports to new CPU's and operating systems continue to be contributed by users who have such machines. Icon Project is in the process of releasing version 9.1 this fall. It might be useful for this community to decide how to coordinate efforts and provide support for itself. I can imagine us forming an Icon Developer's Guild to provide consulting and coordinate improvements to the language. My feeling is that as long as Icon Project continues to play its leadership role, its not clear that such a step is called for. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Wed Nov 29 22:57:22 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 09:05:53 MST Date: Wed, 29 Nov 1995 22:57:22 -0500 Message-Id: X-Sender: mail08621@alterdial.uu.net X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: icon-group@cs.arizona.edu From: Jerry Nowlin Subject: Re: Another introductory book on Icon? Errors-To: icon-group-errors@cs.arizona.edu At 01:04 11/29/95 -0700, you wrote: > > ... > >I wondered if my urge to write a book on Icon might subside, but I've >found myself to be gaining enthusiasm as time passes. I'm writing this >note to probe the on-line Icon community to see what interest there might >be in another introductory book on Icon. What do you think? Might >another book be of possible use? I think another book would be great. Look how many books there are on other languages I don't like nearly as much as Icon. How about taking some of the more current programming applications; like programs to support web servers, CGI script tools, HTML converters, system administration tools, etc.; and building them with Icon to illustrate some of the useful features of the languages. I bet you could get lots of feedback on problems people currently use Icon to solve. Jerry Nowlin nowlin@nowlin.com From icon-group-sender Thu Nov 30 10:11:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 12:21:58 MST Message-Id: Date: Thu, 30 Nov 95 10:11 CST From: escargo@mirage.skypoint.com To: "William H. Mitchell" , icon-group@cs.arizona.edu Subject: Re: Another introductory book on Icon? Content-Length: 473 Errors-To: icon-group-errors@cs.arizona.edu I was in a situation with time on my hands, and I exchanged some mail with Ralph about writing an Icon book. Part of the issue will be getting rights to include at least some reference material in another book. (If your publisher is not Prentice Hall.) My book has only gotten as far as an outline. I was planning on using Icon as an implementation language for a variety of tools. Icon features would be introduced as required to implement tools. Best of luck. dsc From icon-group-sender Thu Nov 30 11:54:18 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 12:22:11 MST From: "Richard L. Goerwitz III" Message-Id: <199511301754.LAA00328@typo.uchicago.edu> Subject: Re: Another introductory book on Icon? To: icon-group@cs.arizona.edu Date: Thu, 30 Nov 1995 11:54:18 -0600 (CST) In-Reply-To: <9511301601.AA11175@dragon.cs.utsa.edu> from "Clinton Jeffery" at Nov 30, 95 10:01:06 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Errors-To: icon-group-errors@cs.arizona.edu > It might be useful for this community to decide how to coordinate efforts > and provide support for itself. My feeling is that Icon has essentially matured, and will be "around" in one sense or another for a long time. But the world moves on. Operating systems change. Character representations widen. Interprocess communi- cation facilities expand. Interfaces improve. If Icon lives on in a way that would make it viable as a real-world lang- uage, I tend to think that it will do so in a simplified form. The im- plementation was always fairly complex, and despite what some others have told me, it has gotten increasingly difficult to work on since the com- piler was introduced (no insult intended to Ken's ground-breaking work). It is also large, and with the addition of the windowing system as part of the core language itself has gotten even larger. There are also some design features that really ought to be fixed, but which won't, because it's "too late" (Ralph's words - and he's right). What really made Icon what it is, at least in my opinion, was Ralph's perfectionism and inexplicable feeling of responsibility to the average user, as well as to researchers. He also had good people working for and with him, too. Still does, I gather. I'd personally love to see a language like Icon that did away with auto- matic type conversions (I rarely used them anyway), redid sets, expanded csets to include wide characters, had file-level scoping, and (most im- portantly) got rid of all the extra functions that crept in because Icon didn't originally have a decent C interface and needed low-level func- tionality of one kind or another (e.g., getch()). Although I've written hundreds of thousands of lines of Icon code, I have to emphasize here that I am no hacker. I'm a humanities scholar (currently teaching Near Eastern Languages & Civilizations). I have no special training in computer science. And what I say here may well be nonsense, therefore. I am just concerned about the fellow who suggested writing a book. This might or might not be the right thing to do just now. I don't know. It really depends on whether there are other Ralphs to be found. If there are, I suspect they won't just work on Icon as-is, but will redesign and simplify the language, then add some unique contribution. That is what researchers (like Ralph) do. Right now Ralph is having fun, presumably, and still working on visual- ization. One would hope that he's gotten past the headaches of supporting Icon users like me :-). He's paid his dues, and we've all benefitted. But the end of an era is at hand. Icon is, as I said, big, mature, and has a relatively small community of users whose labors can be counted on for implementation work. What will happen? I don't know. But is it unreasonable for me to ques- tion the wisdom of writing another book on it at this juncture? -- -Richard L. Goerwitz *** *** r-goerwitz@uchicago.edu From icon-group-sender Thu Nov 30 10:15:25 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 12:22:49 MST Date: Thu, 30 Nov 1995 10:15:25 -0700 From: Gregg Townsend Message-Id: <9511301715.AA04975@hawk.CS.Arizona.EDU> To: icon-group Subject: Announcing Version 9.1 of Icon Errors-To: icon-group-errors@cs.arizona.edu Version 9.1 of Icon for Unix is now available by anonymous FTP. Memory allocation algorithms and default region sizes have been modified to reduce the time spent in garbage collection and the likelihood of thrashing. Other internal changes improve the performance of table references and allow the use of string invocation for assignment operations. Execution time on the Dec Alpha has been reduced by 10% to 20%. The most significant changes are in the area of graphics. Many small changes were made to improve utility or consistency, and bugs were fixed. Related changes were made to the graphics portion of the program library, most notably to give interfaces a 3-dimensional (Motif-like) appearance. The new edition of the graphics documentation includes an appendix detailing the changes. Executable binaries are now packaged in "Unix Starter Kits" containing everything needed to run Icon: icont, iconx, documentation, and the critical subset of the library needed by graphics programs. Kits are available for Dec, HP, IBM, Linux, SGI, and Sun systems. Source code is available separately and can be configured for almost any Unix system. All components of 9.1 can be accessed through this Web page: http://www.cs.arizona.edu/icon/www/v91.html For FTP access, connect to ftp.cs.arizona.edu and visit these directories: /icon/binaries/unix starter kits /icon/packages/unix source code (includes the program library) /icon/library Icon program library /icon/doc separate documentation Any questions should be directed to icon-project@cs.arizona.edu. Gregg Townsend / gmt@CS.Arizona.EDU / +1 520 621 4325 / 32 13 45N 110 57 16W Computer Science / Univ of Arizona / 1040 E 4th St / Tucson AZ 85721-0077 From icon-group-sender Thu Nov 30 13:59:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 17:03:26 MST Message-Id: <9511301400.AA21916@ns1.computek.net> Mime-Version: 1.0 Content-Length: 1868 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 30 Nov 95 13:59 CST From: gep2@computek.net Subject: "Simplification" of Icon To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >I'd personally love to see a language like Icon that did away with auto- matic type conversions (I rarely used them anyway), Are You Kidding!!!??? That is one of the things that is the MOST BASIC about the appeal of something like ICON (or SNOBOL4, for that matter)... that if something is numeric, you can treat it like a number... without having to do manual conversions on it! And that likewise, you can treat numbers like strings when it's appropriate and desirable to do so! Just because YOU don't use something is a damn poor reason to put it at the top of a list of things to propose to "simplify" out of the language!!! Hey, if you want something "simplified", use C... it's VERY simple (by comparison, anyhow). (It's also pathetic, but most of us realized THAT a LONG time ago!) And as for languages becoming stabilized, note that a bunch of us out here have NO objections at all to working on a stable, robust development platform... hey, the version of SNOBOL4+ which I use on almost a daily basis was compiled in September, 1988. Do you think I =mind= not being hit up for an "essential" upgrade (of course, inevitably incorporating NEW bugs of its own) every 18 months??? I certainly don't mind this at all!!! You want a 'simpler' version of ICON? Hey, I probably still have a copy of Version 5 on a diskette around here somewhere... :-) I think it's particularly sinister to claim that the language is going to die because nobody is going to be around to continue to evolve it, and then at the same time to say that it ought to be simplified (and gutted of what makes it the wonderful tool that it is). Which do you want, more evolution (inevitably complicating the language further, and adding features) or gutting it of the (*major!*) features it already has??!! Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Nov 30 13:57:38 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 17:04:13 MST Date: Thu, 30 Nov 1995 13:57:38 -0700 From: Ralph Griswold Message-Id: <9511302057.AA16495@ursus.cs.arizona.edu> To: icon-group Subject: Icon Newsletter 48 Errors-To: icon-group-errors@cs.arizona.edu Icon Newsletter 48 is now available on the Web: http://www.cs.arizona.edu/icon/www/ Follow the links to the Icon Newsletter and Icon Newsletter 48. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science The University of Arizona 520-621-6609 (voice) P.O. Box 210077 Tucson, AZ 85721-0077 520-621-4246 (fax) From icon-group-sender Thu Nov 30 14:03:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 17:04:01 MST Message-Id: <9511301404.AA22297@ns1.computek.net> Mime-Version: 1.0 Content-Length: 989 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 30 Nov 95 14:03 CST From: gep2@computek.net Subject: Re: Another introductory book on Icon? To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >....exchanged some mail with Ralph about writing an Icon book. Part of the issue will be getting rights to include at least some reference material in another book. (If your publisher is not Prentice Hall.) Frankly, if another good book about Icon is written, I would -hope- that they NOT make the mistake of going with Prentice Hall. Prentice Hall has not only NOT promoted the ICON books they have had, they haven't even DISPLAYED them at all at their booth at major trade shows such as CeBIT. As a result of the terribly limited distribution and lack of presence in the retail channels, the language has not received the attention by the trade press or the public that it deserves. I would think that a new book ought to be pushed out through a publisher which has a significantly better record of getting their books into the retail and popular-book channels, so that more of the public will be likely to see it. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Nov 30 16:30:50 1995 Received: by cheltenham.cs.arizona.edu; Thu, 30 Nov 1995 17:04:31 MST Date: Thu, 30 Nov 1995 16:30:50 -0700 (MST) Message-Id: <199511302330.QAA27413@usr1.primenet.com> X-Sender: whm@mailhost.primenet.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: icon-group@cs.arizona.edu From: "William H. Mitchell" Subject: Re: Another introductory book on Icon? Errors-To: icon-group-errors@cs.arizona.edu At 06:24 PM 11/29/95 -0600, Richard L. Goerwitz III wrote: > >If you write an Icon book, be sure you have the question of future >support nailed down. > >If you start writing today, it will doubtless be at least 1.5 years >before you are in the bookstores, so the lifetime of the language >is a concern. Ralph has retired, and most of the former Icon Pro- >ject members have since moved on to other things. The language, as >such, may not even be around five years from now, except as a legacy >system. Richard's note raises some good points, but my view is that Icon is alive and well. Additionally, I think the new graphics features will generate a lot of interest in the language. Also, there's a question of whether language usage drives book sales or vice versa. I think both forces clearly come into play. The Griswolds' book (TIPL) currently lists at $47. I'm enthusiastic about Icon but I have hard time encouraging people to go shell out fifty bucks to just take a good look at the language. I'd like to put an introductory Icon book on the market at a substantially lower price, say under $30. I also suspect that for whatever reason, some persons haven't found success in learning Icon with TIPL. My interest is in writing a book that will increase Icon's popularity, not merely try to tap into the existing Icon user community. If for some reason the Icon Project closes up shop I don't think there will be any shortage of persons willing to fill the void. (I'm one of them!) From icon-group-sender Thu Nov 30 20:56:25 1995 Received: by cheltenham.cs.arizona.edu; Fri, 1 Dec 1995 07:19:05 MST From: "Richard L. Goerwitz III" Message-Id: <199512010256.UAA01172@typo.uchicago.edu> Subject: Re: "Simplification" of Icon To: icon-group@cs.arizona.edu Date: Thu, 30 Nov 1995 20:56:25 -3000 (CST) In-Reply-To: <9511301400.AA21916@ns1.computek.net> from "gep2@computek.net" at Nov 30, 95 01:59:00 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Errors-To: icon-group-errors@cs.arizona.edu > >I'd personally love to see a language like Icon that did away with auto- > >matic type conversions (I rarely used them anyway), > > Are You Kidding!!!??? That is one of the things that is the MOST BASIC about > the appeal of something like ICON (or SNOBOL4, for that matter)... I've always heard this, but suprisingly I rarely use the feature. When I do use it, it's usually in simple write() operations. Only rarely do I use it in any significant way. And only rarely do I ready anyone else's code that uses it in any significant way. Even in those cases, I might add, a few judicious calls to integer() or string() would generally rid the code of automatic type conversions. > if something is numeric, you can treat it like a number... without having > to do manual conversions on it "Manual" conversions are trivial, if you have the right utility functions (which Icon does). > Just because YOU don't use something is a damn poor reason to put it > at the top of a list of things to propose to "simplify" out of the > language!!! I expressed an opinion. Trust me: My opinions aren't going to guide the future development of Icon. So there's no panic or shout, for heaven's sake. > Hey, if you want something "simplified", use C... it's VERY simple (by > comparison, anyhow). (It's also pathetic, but most of us realized THAT > a LONG time ago!) Don't be ridiculous. Icon is implemented in C. Does that mean that the Icon development team is a bunch of pathetic fools? > I think it's particularly sinister to claim that the language is going > to die because nobody is going to be around to continue to evolve it, > and then at the same time to say that it ought to be simplified... Whenever features are removed from a language, users always gripe. That is why Ralph, I think, got into a support nightmare. When version 6 did away with some of the coexpression features, users went crazy. They were put back in later, despite that fact that they are little used (and where they are used, generally they are used needlessly). We're now to the point where very old bugs (e.g., the random number generator) and wrong design decisions (generation of elements in tables) have become immortal- ized by user intransigence. That's why I think Icon itself won't be revised. I think that if it goes on, it will go on in some other form, as the pet project of some energetic and well-connected academic like Ralph. You must understand, though, that I will not be doing any development work on Icon. Although I helped in trivial ways with the implementation several years ago (e.g., starting the Unix getch code out), I'm nowhere near the core development team. So there's no need to take fright over anything I've said here or bombard me with capital letters and exclama- tion points. I'm simply voicing harmless opinions. As you can see from recent postings, development is pushing on, thanks to the energies of people like Gregg. -- -Richard L. Goerwitz *** *** r-goerwitz@uchicago.edu From icon-group-sender Fri Dec 1 09:54:05 1995 Received: by cheltenham.cs.arizona.edu; Fri, 1 Dec 1995 07:19:36 MST Date: Fri, 1 Dec 1995 09:54:05 +0200 (WET) From: Ehud Lamm To: gep2@computek.net Cc: icon-group@cs.arizona.edu Subject: Re: "Simplification" of Icon In-Reply-To: <9511301400.AA21916@ns1.computek.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu On Thu, 30 Nov 1995 gep2@computek.net wrote: > >I'd personally love to see a language like Icon that did away with auto- > matic type conversions (I rarely used them anyway), > > Are You Kidding!!!??? That is one of the things that is the MOST BASIC about > the appeal of something like ICON (or SNOBOL4, for that matter)... that if > something is numeric, you can treat it like a number... without having to do > manual conversions on it! And that likewise, you can treat numbers like strings > when it's appropriate and desirable to do so! I think the Icon group survived quite well without flaming. I think we can continue with this tradition. Ad-hominem remarks are really disgusting (don't YOU think) :-) Anyway the issue raised is an important one. Automatic conversion can be terrible (see PL/1 for an example), when they don't work as expected - and I have seen many such cases in other languages. On the other hand hidden type information and conversions are also basic tools used in many VHLL (very high level languages) such as Rexx, SNOBOL, Icon etc. The problem is to find the right combination of ease of use ("123"+4) and type safety ("0.1" + 1 is an integer, a float or maybe it doesn't matter which??). I think Icon is pretty good in this respect, though I must add I didn't really try to break its type system recently. We have to remember the VHLL raise many issues not found in normal HLL design. A VHLL must allow you to rapidlly code and debug, without having to deal with to many technical obstacles. This also means that it is not always such a great idea to say "you can just link to C" since this adds to the work of the programmer. On the other hand VHLLs like all languages should be orthogonal and clean - and not suffer from to many diconected features. But again, I think this hardly characterizes Icon. Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Mon Dec 4 19:22:13 1995 Received: by cheltenham.cs.arizona.edu; Mon, 4 Dec 1995 13:15:44 MST Message-Id: Sender: From: "Hamish Lawson" Organization: University of Teesside To: icon-group@cs.arizona.edu Date: Mon, 4 Dec 1995 19:22:13 +0 Subject: Can't find path for Icon Priority: normal X-Mailer: Pegasus Mail/Windows (v1.22) Errors-To: icon-group-errors@cs.arizona.edu I'm using Icon version 9 for MS-DOS running under Windows 95. I wanted to make use of version 9's ability to make 'executable' scripts, but I didn't want to have to add the Icon directory to my path as was apparently required. Instead I placed into a directory that is on the path a batch file, iconx.bat, which calls iconx.exe with its full pathname. However the batch file is not called and I get the error message Couldn't execvp( "IconX", ... ): IconX.Exe isn't on your DOS Path. Although the argument to execvp (whatever that is) doesn't explicitly specify that the program it's trying to run has a .exe extension, is this what in fact is happening? If so, is it possible to change it so that no particular extension is assumed, thus allowing iconx.bat to be found? | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 218121 x3611 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Mon Dec 4 11:53:00 1995 Received: by cheltenham.cs.arizona.edu; Mon, 4 Dec 1995 13:15:05 MST Message-Id: <9512041153.AA21669@ns1.computek.net> Mime-Version: 1.0 Content-Length: 867 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 4 Dec 95 11:53 CST From: gep2@computek.net Subject: Re: Another introductory book on Icon? To: rjhare@festival.ed.ac.uk, icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >> I would think that a new book ought to be pushed out through a publisher \ which has a significantly better record of getting their books into the retail \ and popular-book channels, so that more of the public will be likely to see it. >I may have something to say on other aspects of publishing a new Icon book later, but on this particular point, is there a case for getting a university publishing house to do the job? Some of them are quite active and high profile? I think, from a popularization standpoint, that would be WORSE than going with Prentice-Hall. I don't know what they're like to work with AS PUBLISHERS, but just from the standpoint of what I see in the bulk of the retail places (and what gets the shelf space), I personally would be inclined to talk to Que or somebody like that. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Mon Dec 4 17:01:09 1995 Received: by cheltenham.cs.arizona.edu; Mon, 4 Dec 1995 13:15:34 MST To: icon-group@cs.arizona.edu Date: 4 Dec 1995 17:01:09 GMT From: John Lindsay Message-Id: <49v9gl$ksu@cs6.rmc.ca> Organization: Royal Military College Sender: icon-group-request@cs.arizona.edu Subject: Generators and/vs. coroutines ? Errors-To: icon-group-errors@cs.arizona.edu Generators are extremely useful and neat where they are needed (even a sine qua non in some cases), maddening to understand for the first time, and totally infuriating to even think of implementing in a 'normal' C, FORTRAN, Pascal .... call-stack environment where full tasking and multithreading and exception-handling may be involved. Hence I pose the following: Is an Icon generator anything more or less than a coroutine which can be instantiated by an explicit call with value arguments, and can 'return' a function value across the coroutine boundary ? -- All the best ! John H. Lindsay, Phone: (613) 541-6000 - 1 - 6419 Department of Mathematics and Computer Science, Royal Military College of Canada, Internet: Lindsay_J@RMC.CA Kingston, Ontario, Canada, K7K 5L0. Fax: (613) 542-8129 From icon-group-sender Mon Dec 4 14:17:05 1995 Received: by cheltenham.cs.arizona.edu; Mon, 4 Dec 1995 16:34:33 MST Date: Mon, 4 Dec 1995 14:17:05 -0800 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <9512042217.AA05047@orville.orville.premenos.com.> To: icon-group@cs.arizona.edu, lindsay-j@rmc.ca Subject: Re: Generators and/vs. coroutines ? X-Sun-Charset: US-ASCII Errors-To: icon-group-errors@cs.arizona.edu > Date: 4 Dec 1995 17:01:09 GMT > From: John Lindsay > >... > > Is an Icon generator anything more or less than a coroutine which can > be instantiated by an explicit call with value arguments, and can > 'return' a function value across the coroutine boundary ? A generator is less than a coroutine (but, as they say, "less is more" ;-). This can been seen in the way the two are implemented. A coroutine is given its own call stack, but a generator isn't. A generator is a function that stays on the call stack as long is it might be resumed to produce another value. This works well because a generator is never resumed until everything called after it has terminated and been removed from the stack; backtracking is last-in first-out. When a generator is resumed, the call stack has returned to the state it was in when the generator suspended. Note, if you are trying to use the call stack as an expression evaluation stack (as is sometimes done in interpreters), the long-lived stack frames get in the way, but that can be dealt with by employing some extra copying of intermediate values around the suspended stack frames to the top of the stack. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Mon Dec 4 19:44:02 1995 Received: by cheltenham.cs.arizona.edu; Tue, 5 Dec 1995 06:04:20 MST From: Nick Williams Message-Id: <199512050044.TAA07372@styx.ios.com> Subject: Icon lifespan To: icon-group@cs.arizona.edu Date: Mon, 4 Dec 1995 19:44:02 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 512 Errors-To: icon-group-errors@cs.arizona.edu Well, I certainly wish Icon were better known. It has all the functionality of Perl (except pack/unpack, which, someday, I may just go and implement anyways if someone doesn't beat me to it; Icon also lacks C-to-Icon calling, which is needed to make it embeddable) and more still; Icon is also by far one of the cleanest, most consistent languages out there. What can we do to help keep Icon alive? Nick PS: The Icon group will start getting monthly donations from me soon, though these will be modest. From icon-group-sender Mon Dec 4 16:58:11 1995 Received: by cheltenham.cs.arizona.edu; Tue, 5 Dec 1995 06:04:35 MST To: icon-group@cs.arizona.edu Date: 4 Dec 1995 16:58:11 -0700 From: icon-project@cs.arizona.edu Message-Id: <4a01uj$20r@cheltenham.cs.arizona.edu> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu Reply-To: icon-project@cs.arizona.edu Subject: Icon Programming Language FAQ Errors-To: icon-group-errors@cs.arizona.edu Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language Last updated: November 29, 1995 This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. The master copy of this FAQ is the Web page http://www.cs.arizona.edu/icon/www/faq.html. Other on-line documentation is available via the main Icon page at http://www.cs.arizona.edu/icon/www/. This FAQ is written by Ralph Griswold and Gregg Townsend, with help from Cliff Hathaway, Clint Jeffery, and Bob Alexander. * 1. What is Icon? * 2. What is Icon good for? * 3. Where did Icon come from? * 4. What does "Icon" stand for? * 5. On what computers does Icon run? * 6. Who did all these implementations? * 7. Are there other implementations in the works? * 8. What about different versions of Icon? * 9. Which implementations of Icon have graphics/window capabilities? * 10. Where can I get Icon? * 11. Where can I get documentation about Icon? * 12. How do I get started with Icon? * 13. What is the Icon Project? * 14. Where can I find examples of Icon programs? * 15. What is Idol? * 16. How often is material in Icon's FTP area updated? * 17. How do I stay up to date with what's going on with Icon? * 18. Is there a users' group for Icon? * 19. How do I get technical support? * 20. Should I use the Icon interpreter or compiler? * 21. What do I need to run the interpreter? * 22. What do I need to run the compiler? * 23. Can I build my own implementation of Icon for a new platform? ---------------------------------------------------------------------------- 1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal-directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. 2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used as a prototyping tool, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. 3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. 4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word "iconoclastic" was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. 5. On what computers does Icon run? The implementation of Icon is highly portable. Version 9 runs on Macintosh/MPW, MS-DOS, UNIX, and VAX/VMS. There are older versions for the Acorn Archimedes, the Amiga, the Atari ST, IBM CMS and MVS, and OS/2. Icon programs also are highly portable. Most Icon programs can run on any platform that supports Icon. 6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. 7. Are there other implementations in the works? Yes, work is constantly underway on implementations of Icon for new platforms. Present projects include Microsoft Windows, Windows NT, and a new Macintosh implementation. 8. What about different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area. As of this writing, Macintosh/MPW, MS-DOS, UNIX, and VAX/VMS implementations are up to 9. There are other implementations that presently are at Version 8. Almost all programs that run under 8 and that do not use graphics will run under 9. 9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on UNIX and VAX/VMS. The Windows NT and Microsoft Windows implementations that are in progress will support Icon's graphics facilities. A Macintosh implementation to support graphics also is in the works. 10. Where can I get Icon? Icon is available via anonymous FTP and on the Web. For FTP, use ftp.cs.arizona.edu and cd /icon. For the Web, use http://www.cs.arizona.edu/icon/www/ and check out the links there. For FTP, the directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have README files with additional information. Icon also is available on diskettes for prices ranging from $15 to $25. Contact: Icon Project Department of Computer Science The University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077 520-621-6613 (voice) 520-621-4246 (fax) icon-orders@cs.arizona.edu Purchases can be made by credit card (MasterCard or Visa) or by check drawn on a bank with a branch in the United States and made payable to The University of Arizona. 11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, Prentice-Hall, 1990, 368 pages, ISBN 0-13-447889-4. This book is a complete description and reference manual for Version 8 of Icon. A technical report describes changes since that version. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed considerably since then, the basic structure is the same. Technical reports describing recent implementation changes are included with copies of the book purchased from the Icon Project. These books are available from the Icon Project or from book stores that handle special orders. Additional documentation is available via FTP in /icon/doc. Notable documents are: * IPD266: An Overview of Icon (text, PostScript, PDF) * IPD268: Graphics/window facilities (PostScript, PDF) * IPD267: Version 9.1 of Icon (text, PostScript, PDF) There are manual pages for UNIX systems, and more documentation under the Icon web page, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year and is available on the Web. There is a $20 one-time fee for an on-going subscription by postal mail. The Icon Analyst, a technically-oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on the Web. All back issues of both newsletters are available for purchase. 12. How do I get started with Icon? If you're running under Unix, check first in the /icon/binaries/unix FTP directory to see if there is a "starter kit" for your platform. Starter kits include executables, documentation, and other material. Otherwise, go to the /icon/packages directory and get the appropriate package. Packages include documentation and other material; see the README file in that directory for more details. There is a Unix package for platforms that lack starter kits. If the non-Unix package you pick up does not contain executable files, check /icon/binaries. You also may want to get the overview of Icon: /icon/doc/ipd266.doc or ipd266.ps.Z. You'll find pointers to other documents of interest in the package you pick up. 13. What is the Icon Project? The Icon Project is a name used by the group that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona and (primarily) revenue from the sale of program material and documentation. 14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers. The library contains numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available via FTP in /icon/library and on diskettes from the Icon Project. 15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that support Icon. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. 16. How often is material in Icon's FTP area updated? New material is added when it's available. Established implementations usually are only updated when there's a major new release. This typically is every year or two. The Icon program library is updated on a similar schedule. 17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to read the Icon Newsletter. You can stay up to date on the source code, which is changed much more frequently than the version on FTP is updated, by subscribing to the source update service, which provides a new version about three times a year. There also is a subscription service for updates to the Icon program library, which provides new material about three times a year. There is on-line information about subscribing to these services. 18. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains an electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list, is less intrusive, but sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. 19. How do I get technical support? Since the Icon Project is not a commercial organization, its capacity for providing technical support is limited. It will help if you use the appropriate resource when you need assistance: Ordering Icon Material mail: Icon Project Department of Computer Science The University of Arizona P.O. Box 210077 Tucson, Arizona 85721-0077 U.S.A. fax: (520) 621-4246 voice: (520) 621-6613 e-mail: icon-orders@cs.arizona.edu Getting On-Line Information and Material web: http://www.cs.arizona.edu/icon/www/ ftp: ftp.cs.arizona.edu (cd /icon) e-mail: ftpmail@cs.arizona.edu Send a message consisting of the word help. Assistance with Installing Icon e-mail: icon-project@cs.arizona.edu Bug Reports e-mail: icon-project@cs.arizona.edu fax: (520) 621-4246 Assistance with Programming Problems e-mail: icon-group@cs.arizona.edu news: comp.lang.icon Uploading Files ftp: ftp.cs.arizona.edu (cd /incoming) After uploading, send e-mail to icon-project@cs.arizona.edu. 20. Should I use the Icon interpreter or compiler? As the question indicates, there are two forms of the implementation of Icon, an interpreter and a compiler. The interpreter gets a program into execution quickly and is recommended for program development, debugging, and most production situations. The compiler produces code that executes somewhat faster than interpreted code (a factor of 2 or 3 is typical), but the compiler requires a large amount of resources and is very slow in producing executable code. It also requires additional time and effort at installation time. The compiler is recommended only for small programs where execution speed is the paramount concern. 21. What do I need to run the interpreter? The Icon interpreter will run on most computers. It requires a reasonable amount of memory, however. Under MS-DOS, the Icon interpreter needs 500 KB of application RAM to work well. 22. What do I need to run the compiler? The Icon compiler is another matter. It requires a C compiler, a fast CPU for tolerable compilation times, a considerable amount of disk space, and a lot of memory -- at least several megabytes. The Icon compiler generates C code, which must then be compiled to produce an executable program. The flexibility that Icon provides to programmers makes compilation technically difficult and the process requires a large amount of memory. The C code it produces is voluminous and stresses the most robust C compilers. Generally speaking, the Icon compiler is practical for platforms in the workstation class but not for personal computers. 23. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available. The existing implementations are testament to its portability. (A small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting most of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architectures may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it asks that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. From icon-group-sender Tue Dec 5 07:59:51 1995 Received: by cheltenham.cs.arizona.edu; Tue, 5 Dec 1995 12:20:22 MST From: Art Eschenlauer Message-Id: <199512051359.HAA27194@biosci.cbs.umn.edu> Subject: Calling all Macintosh Icon implementors To: icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) Date: Tue, 5 Dec 1995 07:59:51 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 992 Errors-To: icon-group-errors@cs.arizona.edu Hello, Macintosh Icon implementors: It's time for me to stop working in a vacuum (it's difficult to breathe). But seriously, I'd like to start talking to the others who are working on bringing Icon 9.X up on the Macintosh. Currently I'm trying to learn how to use the open scripting architecture (OSA) and the Thread Manager for the Mac, after which I hope to work one something somewhat like Proicon. With scriptability, other applications could "call up" Icon's functionality at will, not to mention that Icon could also call upon other apps to share in a task. I know that I'm on the steep part of the learning curve, but I see the value of a modern Macintosh interface for Icon. I also see the uselessness of duplicating effort (instructive though it may be). So let's start talking to one another, sharing ideas and distributing the effort! - Art -- Arthur Eschenlauer, eschen@biosci.cbs.umn.edu "If you're going to follow the herd, you'd better watch your step." - Garrison Keillor From icon-group-sender Tue Dec 5 10:41:12 1995 Received: by cheltenham.cs.arizona.edu; Tue, 5 Dec 1995 12:20:33 MST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Dec 1995 10:41:12 -0800 To: Nick Williams , icon-group@cs.arizona.edu From: bobalex@netcom.com (Bob Alexander) Subject: Re: Icon lifespan Errors-To: icon-group-errors@cs.arizona.edu Nick Williams writes: >It has all the >functionality of Perl (except pack/unpack, which, someday, I may just go >and implement anyways if someone doesn't beat me to it Sorry, someone has (me). There is a procedure in the Icon Program Library called "binary.icn" that has an exact replica of Perl's pack and unpack, as well as a access to the primitive conversion functions that are used by pack and unpack. When I use it, I usually opt for the lower-level functions, since the linker can optimize-out the functions I don't use. Using pack/unpack is like using printf() in C -- the linker has to include *all* the conversions because it doesn't know which ones you might use. Now -- when you finish implementing a really nice "foreign function" interface for Icon, I'll be your first customer :-) That would remove a major obstacle in Icon's acceptance by many folks. Other Icon wish-list items? Just read the Java feature list -- it seems to have captured much of what I've desired for Icon: platform-independent virtual machine, compact executable representation, dynamic loading of programs. Having object oriented facilities is probably a good survival characteristic for the next decade, although I don't really miss that in Icon. Of course, the Java language itself is not nearly as cool as Icon! BTW, Icon fans might be interested in having a peek JavaScript, just announced by Sun and Netscape. Info and demos can be found by following the "JavaScript" link from Netscape's home page. (In case there is still anyone left in the world who doesn't know, the URL is http://www.netscape.com/). Bob Alexander bobalex@netcom.com From icon-group-sender Tue Dec 5 14:14:01 1995 Received: by cheltenham.cs.arizona.edu; Tue, 5 Dec 1995 16:43:36 MST Date: Tue, 5 Dec 1995 14:14:01 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9512052014.AA29357@dragon.cs.utsa.edu> To: H.Lawson@tees.ac.uk Cc: icon-group@cs.arizona.edu In-Reply-To: (H.Lawson@tees.ac.uk) Subject: Re: Can't find path for Icon Content-Length: 946 Errors-To: icon-group-errors@cs.arizona.edu [Hamish Lawson asks a query about DOS Icon's executable headers] Although the argument to execvp (whatever that is) doesn't explicitly specify that the program it's trying to run has a .exe extension [... the error message in fact indicates that an iconx.exe is needed] execvp() is a C function that Icon's executable header calls in order to run iconx. As far as I know, execvp requires a .EXE file, a .bat file won't do. If so, is it possible to change it so that no particular extension is assumed, thus allowing iconx.bat to be found? In order to execute a batch file from C code (in the Icon header), you'd have to invoke a new version of command.com. We probably can't do that in the general case because it would eat up valuable memory. Someone else knows more about DOS executable headers than I; perhaps someone can confirm this. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Wed Dec 6 11:04:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 6 Dec 1995 12:36:23 MST Message-Id: <9512061104.AA07152@ns1.computek.net> Mime-Version: 1.0 Content-Length: 879 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 6 Dec 95 11:04 CST From: gep2@computek.net Subject: Re: Can't find path for Icon To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >execvp() is a C function that Icon's executable header calls in order to run iconx. As far as I know, execvp requires a .EXE file, a .bat file won't do. > If so, is it possible to change it so that no particular extension is assumed, thus allowing iconx.bat to be found? >In order to execute a batch file from C code (in the Icon header), you'd have to invoke a new version of command.com. We probably can't do that in the general case because it would eat up valuable memory. If it was me, what I'd probably do would be simply to write a tiny executable program in assembler (to avoid having to link in and load a large C runtime library or something) that would in turn invoke COMMAND.COM and ask it to run the batch file you want to execute. I'd think that a few dozen lines (maybe less) would be plenty. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Fri Dec 8 19:16:25 1995 Received: by cheltenham.cs.arizona.edu; Sat, 9 Dec 1995 09:45:06 MST To: icon-group@cs.arizona.edu Date: 8 Dec 1995 19:16:25 -0500 From: nr@cs.purdue.edu (Norman Ramsey) Message-Id: <4aakgp$n8k@labrador.cs.purdue.edu> Organization: Department of Computer Science, Purdue University Sender: icon-group-request@cs.arizona.edu Subject: ihelp in IPL Errors-To: icon-group-errors@cs.arizona.edu Has anybody taken the ihelp program from the IPL and made it into an HTTP server, or otherwise ``html-ified'' the online help available there? N Ramsey -- ``They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.'' ---Franklin Norman Ramsey I support the Phil Zimmermann Legal Defense Fund. http://www.cs.purdue.edu/homes/nr (http://www.netresponse.com/zldf) From icon-group-sender Sun Dec 10 22:02:19 1995 Received: by cheltenham.cs.arizona.edu; Mon, 11 Dec 1995 10:04:00 MST From: Art Eschenlauer Message-Id: <199512110402.WAA03767@biosci.cbs.umn.edu> Subject: Has anyone written make.icn To: icon-group@cs.arizona.edu (icon-group@cs.arizona.edu) Date: Sun, 10 Dec 1995 22:02:19 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 144 Errors-To: icon-group-errors@cs.arizona.edu I was wondering if anyone had written an approximation of the unix 'make' program in Icon. Thanks in advance. -Art (eschen@biosci.cbs.umn.edu) From icon-group-sender Fri Dec 15 15:32:34 1995 Received: by cheltenham.cs.arizona.edu; Sat, 16 Dec 1995 08:51:10 MST Date: Fri, 15 Dec 1995 15:32:34 -0500 (EST) From: John Kohl X-Sender: kohl@nova To: icon-group@cs.arizona.edu Subject: Using Icon for CGI scripts on the Web In-Reply-To: <199512110402.WAA03767@biosci.cbs.umn.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Has anyone used Icon for CGI scripts for the WWW? In particular using a Mac server? While moderately knowledgable on Icon, I have little knowledge of programming for the Web. How feasible is Icon rather than Perl for these tasks? John Kohl University of Maryland, University College From icon-group-sender Sat Dec 16 17:42:37 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Dec 1995 08:54:42 MST Date: Sat, 16 Dec 1995 17:42:37 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9512162342.AA04887@dragon.cs.utsa.edu> To: kohl@nova.umuc.edu Cc: icon-group@cs.arizona.edu In-Reply-To: (message from John Kohl on Fri, 15 Dec 1995 15:32:34 -0500 (EST)) Subject: Re: Using Icon for CGI scripts on the Web Content-Length: 745 Errors-To: icon-group-errors@cs.arizona.edu {John Kohl writes:} Has anyone used Icon for CGI scripts for the WWW? In particular using a Mac server? While moderately knowledgable on Icon, I have little knowledge of programming for the Web. How feasible is Icon rather than Perl for these tasks? I don't know anything about CGI scripts on Mac web servers, but on UNIX CGI scripts are ordinary applications that happen to make use of numerous environment variables to receive information from the web server that invokes them. They tend to generate/write HTML as their output. Icon (and Perl) make excellent CGI script languages because of the ease with which they manipulate strings. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Mon Dec 18 08:24:27 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Dec 1995 08:54:55 MST Date: Mon, 18 Dec 1995 08:24:27 -0500 (EST) From: "Phillip L. Thomas" To: John Kohl Cc: icon-group@cs.arizona.edu Subject: Re: Using Icon for CGI scripts on the Web In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu On Fri, 15 Dec 1995, John Kohl wrote: > Has anyone used Icon for CGI scripts for the WWW? > In particular using a Mac server? I've prototyped some CGI applications with Icon. Since a CGI script primarily needs to read standard in and write to standard out while having the capability of running other programs, there is no reason not to use Icon. It also has better structures and debugging capability than I've managed to extract from Perl. --Phillip Lee Thomas From icon-group-sender Mon Dec 18 14:54:46 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Dec 1995 17:19:45 MST Date: Mon, 18 Dec 95 14:54:46 CST From: yak@comm.mot.com (Yarko Tymciurak) Message-Id: <9512182054.AA25710@platov8> To: icon-group@cs.arizona.edu Subject: Re: Using Icon for CGI scripts on the Web Errors-To: icon-group-errors@cs.arizona.edu | From: "Phillip L. Thomas" | To: John Kohl | Cc: icon-group@cs.arizona.edu | Subject: Re: Using Icon for CGI scripts on the Web | | | On Fri, 15 Dec 1995, John Kohl wrote: | | > Has anyone used Icon for CGI scripts for the WWW? | > In particular using a Mac server? | | I've prototyped some CGI applications with Icon. Since a CGI | script primarily needs to read standard in and write to | standard out while having the capability of running other | programs, there is no reason not to use Icon. It also has better | structures and debugging capability than I've managed to extract | from Perl. | | --Phillip Lee Thomas | Also, on the Unix side (and, I presume, Windows - and soon Mac???) generating graphics on a hidden canvas, then saving & sending resulting GIF images is pretty trivial.