nowlin@ihuxy.UUCP (Jerry D Nowlin +1 312 979 0441) (08/28/89)
> Date: Sun, 27 Aug 89 12:43:02 MST > From: "Kenneth Walker" <kwalker@arizona.edu> > > > Date: 25 Aug 89 08:01:00 GMT > > From: m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh@uxc.cso.uiuc.edu > > > > I have been reading this notesfile for awhile, and must say I am > > mystified by its very presence. What is ICON? > > What is so special about it as a language > > that it merits its own notesfile? So far, most of what I've read has > > been about ICON bugs in Amiga! I would appreciate some explanation > > about the purpose of this language and whether it is at all worth > > learning. > > I am on the Icon Project, so my opinions are somewhat biased. Perhaps > others of you can comment on what you find to be Icon's strengths > and weaknesses. What do you use Icon for and why? What don't you > use Icon for and why? (Perhaps I will express some of my biased > opinions after others have commented.) I've been using Icon for around five years now. Most of my experience is with languages like FORTRAN, BASIC, and C but Icon is now my favorite language by far. My favorite parts of Icon are dynamic memory allocation, strings as a real data type along with string scanning, goal directed evaluation, and generation. I've written many Icon programs; calculators, spelling checkers, a version of grep, games, text formatting filters, and even some expert systems prototypes. Most of them have operated on text or some other type of symbolic data. My last large Icon project (~4000 lines) was a simulator for a screen generator. The target system for the real screen generator was in limited supply and a simulator that would allow testing on other systems was needed. Icon allowed me to easily parse the screen generation language and implement an interpreter for the executable portions of it. The simulator is easy to modify and maintain since Icon is so understandable. We can now test on all the machines in our computing environment from 3B2s to mainframes since Icon runs on all of those machines. Icon does have some limitations though. I've since converted the parsing portion of the simulator into C for another project because I needed to generate intermediate data files that contained binary C structures. If it weren't for this language specific portion of the requirements Icon would have been used for this project too. One of the real advantages of Icon is the ability to code simple sequences in a simple way. My favorite example is opening files. In C you have to have a minimum amount of code to declare variables and check for errors: FILE *in; if ((in = fopen(infile,"r")) == NULL) { fprintf(stderr,"I can't open '%s' for reading\n",infile); exit(1); } In Icon there is no declaration to bother with and the error checking is simple: (in := open(infile,"r")) | stop("I can't open '",infile,"' for reading") The extra parentheses are to enforce the order of precedence that's wanted but since stop() terminates the program they aren't really needed. I find the Icon example much simpler to read and understand than the C example. If you use examples that take advantage of goal directed evaluation the simplifications become really amazing. I could go on for a long time but you get the idea. I would still be a die hard C fan if I hadn't had a friend practically force me to read The Icon Programming Language by Ralph and Madge Griswold. I'm now a happy convert and busy proselytizing everywhere I go. Try it and you'll get hooked too. Jerry Nowlin (...!att!ihuxy!nowlin)