From icon-group-sender Wed Jan 3 20:09:24 1996 Received: by cheltenham.cs.arizona.edu; Wed, 3 Jan 1996 16:22:01 MST To: icon-group@cs.arizona.edu Date: 3 Jan 1996 20:09:24 GMT From: rsjohnso@students.uiuc.edu Message-Id: <4cenpk$m0q@vixen.cso.uiuc.edu> Organization: University of Illinois at Urbana Sender: icon-group-request@cs.arizona.edu Subject: How does Icon compare to Perl? Errors-To: icon-group-errors@cs.arizona.edu Status: O Hi,I was wondering if anyone could tell me (that is, if anyone posts to this group) how Icon compares to Perl (on the Mac, that is) in terms of text handling capabilities and speed. Thanks in advance, S. Johnson From icon-group-sender Wed Jan 3 19:30:00 1996 Received: by cheltenham.cs.arizona.edu; Thu, 4 Jan 1996 09:33:55 MST Message-Id: Date: Wed, 3 Jan 96 19:30 CST Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: How does Icon compare to Perl? To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >Hi,I was wondering if anyone could tell me (that is, if anyone posts to this group) how Icon compares to Perl (on the Mac, that is) in terms of text handling capabilities and speed. I can't speculate on speed (and least of all for the Mac platform), but certainly in text handling capabilities Perl is a pathetic substitute for either SNOBOL4 or Icon. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Jan 4 18:47:02 1996 Received: by cheltenham.cs.arizona.edu; Thu, 4 Jan 1996 12:27:17 MST Date: Thu, 4 Jan 1996 18:47:02 +0100 From: karczma@calvin.info.unicaen.fr (Jerzy Karczmarczuk) Message-Id: <9601041747.AA12350@obelix.unicaen.fr> To: icon-group@cs.arizona.edu Subject: Re: How does Icon compare to Perl? X-Sun-Charset: US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O Gordon Peterson (obviously, who else...) answered the following query: * > Hi,I was wondering if anyone could tell me (that is, if anyone posts to * > this group) how Icon compares to Perl (on the Mac, that is) in terms of * > text handling capabilities and speed. in the following way: > I can't speculate on speed (and least of all for the Mac platform), but > certainly in text handling capabilities Perl is a pathetic substitute for either > SNOBOL4 or Icon. > > Gordon Peterson This is the 165423109 posting of Gordon Peterson on this issue. WE KNOW ALL that Gordon hates Perl and loves Icon. That is perfectly alright! But it starts to be really boring. Could Gordon add at least once a serious argument in favour of his standpoint??! I tried to exchange some private letters with Gordon, but I still don't know the reason of his personal, partisan attitude. I know why I like Icon. I enjoy the functional 'visage' of the language and I appreciate in general the generators and co-expressions, as the non-determinism is a sine-qua-non methodology for the artificial intelligence. I like Perl because I learned it before I knew Python and I had to write some really lousy CGI scripts. In my opinion the languages ARE comparable. Icon is a well structured procedural language, Perl is $horrible, but it has been built to deal in a simple manner with regexps. This is rather a question of style than of the brute power. All this was discussed here several times. Perhaps we could write one day a decent comparison-FAQ instead of posting slogans. We have to gather some serious questions first, for example: How important for you are modern control structures? (If not at all, use Snobol4...) Yours Jerzy Karczmarczuk Dept. of Comp. Sci., University of Caen, France From icon-group-sender Thu Jan 4 19:01:56 1996 Received: by cheltenham.cs.arizona.edu; Fri, 5 Jan 1996 08:34:02 MST To: icon-group@cs.arizona.edu Date: 4 Jan 1996 19:01:56 -0700 From: icon-project@cs.arizona.edu Message-Id: <4ci0qk$i3h@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 Status: O Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language Last updated: December 4, 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. Icon is available on CD-ROM from Prime Time Freeware (http://www.ptf.com/, 408-433-9662). Contact them for details. 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 Fri Jan 5 06:30:26 1996 Received: by cheltenham.cs.arizona.edu; Fri, 5 Jan 1996 08:34:14 MST Date: Fri, 5 Jan 1996 06:30:26 -0600 (CST) From: "Chris D. Tenaglia" To: rsjohnso@students.uiuc.edu Cc: icon-group@cs.arizona.edu Subject: Re: How does Icon compare to Perl? In-Reply-To: <4cenpk$m0q@vixen.cso.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O I've looked over Perl and it seems like what I'd expect from an early cut at Icon (i.e. V1.0). Some icon concepts are there though not as precise and consistent. It has regular expression pattern matching which some deem extremely cool. Perl looks more like a shell language and it blurrs very easily with the OS, whereas Icon "looks" like a programming language. I've done some limited benchmarks and from a few simple cases that I could code equally in both, and on solaris. In that case I think that it looks as though Perl used more time (30-50%). Perhaps the Perl interpreter is larger than Icon and a fraction of a second is not significant? Perl is interpreted like old BASIC is interpreted. Each line has to be freshly loaded and parsed during execution, whereas, even an "interpreted" Icon program uses a pre-digested icode. Perl programmers claim this is their plus, they can edit-run-edit-run where Icon programmers have to edit-compile-run-edit-compile-run. I think that compile step is a non-issue as icont compiles about 1000 lines per second on a sparc server 1000. Fairly insignificant. The rest is the common sense and discipline of software engineering. I think it's possible to write Perl code that looks like Icon and maybe even to write Icon that looks like Perl (I don't why). 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 ! On 3 Jan 1996 rsjohnso@students.uiuc.edu wrote: > Date: 3 Jan 1996 20:09:24 GMT > From: rsjohnso@students.uiuc.edu > To: icon-group@cs.arizona.edu > Subject: How does Icon compare to Perl? > > Hi,I was wondering if anyone could tell me (that is, if anyone posts to > this group) how Icon compares to Perl (on the Mac, that is) in terms of > text handling capabilities and speed. > > > Thanks in advance, > S. Johnson > > From icon-group-sender Fri Jan 5 10:15:29 1996 Received: by cheltenham.cs.arizona.edu; Fri, 5 Jan 1996 12:36:53 MST Date: Fri, 5 Jan 1996 10:15:29 -0600 From: Richard Scot Johnson Message-Id: <199601051615.KAA14252@ux4.cso.uiuc.edu> To: cdt@post.its.mcw.edu, rsjohnso@students.uiuc.edu Subject: Re: How does Icon compare to Perl? Cc: icon-group@cs.arizona.edu Content-Length: 81 Errors-To: icon-group-errors@cs.arizona.edu Status: O Thanks for the reply, I'm going to get Icon and try my hand at it. S. Johnson From icon-group-sender Fri Jan 5 15:18:11 1996 Received: by cheltenham.cs.arizona.edu; Fri, 5 Jan 1996 16:47:35 MST Date: Fri, 5 Jan 1996 15:18:11 -0500 From: dashiell@nadc.nadc.navy.mil (J. Dashiell) Message-Id: <199601052018.PAA04431@nadc.nadc.navy.mil> To: icon-group@cs.arizona.edu Subject: msdos icon and screen writing Errors-To: icon-group-errors@cs.arizona.edu Status: O Is the screen writing in the interpreter done with writing direct to video or writing to dos or rom bios? Reason this is of interest is that with direct video writing it's more difficult for speech synthesizers. With the other two forms this works better if ascii is used. If graphics are used like forcing the display into ega or vga then speech synthesizer packages can't work with the language. // eoj jude When philosophy fails credability, it has already failed reality. From icon-group-sender Fri Jan 5 20:26:00 1996 Received: by cheltenham.cs.arizona.edu; Mon, 8 Jan 1996 06:09:30 MST Message-Id: Date: Fri, 5 Jan 96 20:26 CST Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Re: How does Icon compare to Perl? To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >I've looked over Perl and it seems like what I'd expect from an early cut at Icon (i.e. V1.0). Actually, a year or two ago I took a Perl program that a French friend was really thrilled with (so easy, so compact, etc. etc.) and rewrote it in SNOBOL4+ with very little effort... and my SNOBOL4+ version was about half the size of his original Perl program. My general feeling is that Perl would be a wonderful tool, if SNOBOL4 and Icon didn't exist. But they DO exist, so why put up with a halfassed dog like Perl? >It has regular expression pattern matching which some deem extremely cool. How so? RegExs are really pitiful compared to a real SNOBOL4-style pattern match or an Icon-style string scanning expression. Who needs a "poor man's" pattern match, when you can have the real thing? >Perl is interpreted like old BASIC is interpreted. Each line has to be freshly loaded and parsed during execution, whereas, even an "interpreted" Icon program uses a pre-digested icode. Perl programmers claim this is their plus, they can edit-run-edit-run where Icon programmers have to edit-compile-run-edit-compile-run. In the case of SNOBOL4 you compile-and-run in a single step, and compilation time (even moreso than for Icon) is generally essentially trivial. Although you CAN pre-compile your programs if you want, which can be useful if you want to sell your programs and don't want to distribute them in source form. >I think it's possible to write Perl code that looks like Icon and maybe even to write Icon that looks like Perl (I don't why). You certainly can't write anything so easily in Perl that handles the kinds of multivalued expressions and goal-directed evaluation that you have in Icon! I don't see that Perl implements anything more than a very small and limited, primitive subset of either SNOBOL4 or Icon. Honestly, if you have and know either or both of Icon or SNOBOL4, I don't see much (if any at all) point in wasting time on Perl too. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Sat Jan 6 01:50:00 1996 Received: by cheltenham.cs.arizona.edu; Mon, 8 Jan 1996 06:10:07 MST Message-Id: Date: Sat, 6 Jan 96 01:50 CST Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Re: How does Icon compare to Perl? To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >This is the 165423109 posting of Gordon Peterson on this issue. WE KNOW ALL that Gordon hates Perl and loves Icon. That is perfectly alright! But it starts to be really boring. There is a simple solution to having my messages represent such a high percentage of all postings. Post more actively yourself!!! As you've noticed, the original poster asked how Icon compared to Perl in terms of text handling capabilities. I've not seen a huge number of replies, and I didn't want the question to go unanswered!!! >Could Gordon add at least once a serious argument in favour of his standpoint??! You know, the Icon book (highly recommended) is chock-full of wonderful examples of the things that Icon does better than other languages. And indeed, the Icon Program Library contains hundreds of large and small routines and programs that are similarly instructive. So it's not as if anybody who's seriously interested doesn't have LOADS of resources to show them copious examples of programs, most of which you'd have a much harder time trying to implement in Perl. >I tried to exchange some private letters with Gordon, I -always- return replies to such letters, but don't recall seeing yours. >but I still don't know the reason of his personal, partisan attitude. I believe I explained it here, more than once. I had a friend in Paris who was very excited about Perl. I asked him for a choice example of one of his Perl applications, to show me why Perl was so wonderful, and I rewrote it (with very little effort... and better, more tolerant, more flexible, and more robust) in SNOBOL4+ in roughly half the lines, half the bytes, and half the statements of source code. What is it about that that you don't understand? >I know why I like Icon. I enjoy the functional 'visage' of the language and I appreciate in general the generators and co-expressions, as the non-determinism is a sine-qua-non methodology for the artificial intelligence. >I like Perl because I learned it before I knew Python and I had to write some really lousy CGI scripts. In my opinion the languages ARE comparable. I don't see how you can claim that. I believe that just about anything you could write in Perl could be easily written in either Icon or SNOBOL4+ (with only perhaps a few minor addons to access specific low-level system functions), but I don't believe that the converse is true. >Icon is a well structured procedural language, Perl is $horrible, but it has been built to deal in a simple manner with regexps. That's just grand, except that regexps are a "poor man's SNOBOL4-pattern substitute", implemented in classical (and still godawful) UNIX/Teletype control-characters-do-everything style. If you like regexps, then you're certainly welcome to them... but I consider them a pitiful excuse for full-fledged SNOBOL4 patterns. >This is rather a question of style than of the brute power. All this was discussed here several times. Perhaps we could write one day a decent comparison-FAQ instead of posting slogans. You know, it's really rather like food. Some people really do not have anything like a gourmet palate... for them, absolutely anything that fills the gnawing hole in their midsection will do them just fine. And perhaps, for them, going anywhere to eat that's fancier than McDonald's or Sizzler is really just a waste of money. On the other hand, if you are sufficiently discerning to appreciate the difference, there really is a world of difference between a Big Mac and a really excellent dinner. I got into a really long debate once in an Intelec BBS conference with a moron who claimed that "Anything you can do in SNOBOL4+, I can write just as easily and quickly in PDS Basic". (Yeah, RIIIIIIGGHTT!!!) So I proposed a programming challenge (actually, this was not the first such challenge we proposed in that conference, although this was certainly the most interesting one). I uploaded to a commonly-accessible BBS a file I'd collected containing something like 20,000 lines from BBS messages. These lines contained normal unformatted message text, sig lines, taglines, price listings, computer model numbers and codes, FIDOnet node addresses, occasional E-mail addresses, ANSI graphics, header lines, and the like. The messages originated from authors in various countries around the world (but were all written in English or French, at least). The programming assignment was to write a program which would extract from this file, and write to an output file, all the complete postal addresses and telephone numbers (name, street or PO Box address, county or district (in England for example), city, state if any, postal code, country, and (maybe) phone number) that were to be found in the input file. Of course, addresses in the USA, Canada, England, Germany, Italy, France and the like don't really look very much alike (both in terms of data values, and how they are typically formatted overall), but all needed to be recognized by the program (and programs earned demerits if they recognized things as postal addresses that clearly (to a human, at least) were not). I designed and implemented (and posted) a program in SNOBOL4+ which met the established criteria. Needless to say, the other fellow never did. :-) >We have to gather some serious questions first, for example: >How important for you are modern control structures? (If not at all, use Snobol4...) So-called "modern" control structures are one paradigm for expressing algorithms, but they are certainly not the only practical or effective one. For example, as the Icon book mentions, the statement (open(file) | write("Can't open the file!")) is every bit as clear as (and more compact than) the more classical IF-THEN statement. Perhaps a more interesting real-world example is a piece of code which one finds in more or less comparable form in nearly every one of my SNOBOL4+ programs. The code is like the below: SCREEN = "Sorry, I cannot open the " + (~INPUT(.INPUT,5,"R,300") "input text file, unit 5.", + ~OUTPUT(.OUTPUT,6,"W,300") "output text file, unit 6.", + ~OUTPUT(.LOG,8,"W,E,300","LOG.TXT") "output file LOG.TXT.") + :S(END) Certainly this does not use the so-called "modern" IF-THEN control structure, but if you try to implement the same functionality as I get using the above with the "modern control structures" that you apparently find so wonderful in other languages, I think you'll have a hard time showing how these so-called "modern" control structures do a better job. Of course, as in the case of McDonald's, some people really don't have the imagination or intellectual drive to want to learn alternative ways of thinking about problems. For them, the clockwork-style "knit-one-perl-two" of classical primitive control structures may better fit their personal and intellectual style. :-) Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Mon Jan 8 12:09:50 1996 Received: by cheltenham.cs.arizona.edu; Mon, 8 Jan 1996 06:10:27 MST Message-Id: Sender: From: "Hamish Lawson" Organization: University of Teesside To: icon-group@cs.arizona.edu Date: Mon, 8 Jan 1996 12:09:50 +0 Subject: Re: How does Icon compare to Perl? Priority: normal X-Mailer: Pegasus Mail/Windows (v1.22) Errors-To: icon-group-errors@cs.arizona.edu Status: O Chris D. Tenaglia wrote: > Perl is interpreted like old BASIC is interpreted. Each line has > to be freshly loaded and parsed during execution, whereas, even > an "interpreted" Icon program uses a pre-digested icode. Much as I prefer Icon over Perl, I wouldn't want its claim to superiority based in part on false assertions about its rivals :-). As I understand it, when Perl is invoked it compiles the given script into memory before running it, rather than parsing each line as the script is executed. This implicit compilation stage undergone every time a Perl script is run may account for the reported longer execution time of Perl scripts compared to equivalent precompiled Icon scripts. | 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 Jan 8 08:23:42 1996 Received: by cheltenham.cs.arizona.edu; Mon, 8 Jan 1996 12:23:21 MST Date: Mon, 8 Jan 1996 08:23:42 -0600 (CST) From: "Chris D. Tenaglia" To: Hamish Lawson Cc: icon-group@cs.arizona.edu Subject: Re: How does Icon compare to Perl? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O > Chris D. Tenaglia wrote: > > Perl is interpreted like old BASIC is interpreted. Each line has > > to be freshly loaded and parsed during execution, whereas, even > > an "interpreted" Icon program uses a pre-digested icode. > > Much as I prefer Icon over Perl, I wouldn't want its claim to > superiority based in part on false assertions about its rivals :-). > As I understand it, when Perl is invoked it compiles the given script > into memory before running it, rather than parsing each line as the > script is executed. This implicit compilation stage undergone every > time a Perl script is run may account for the reported longer > execution time of Perl scripts compared to equivalent precompiled > Icon scripts. > > | 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 > Ooops. sorry. I guess I made the assumption that edit-run-edit-run meant interpreter. Perl programmers told me it was an interpreter too. So it's an edit-(compile&run)-edit-(compile&run) during development, and (compile&run) every time once in production? If one makes modular systems with lots of perls calling each other there'd still be a lot of compiling going on even after programming has completed? It almost sounds like the tokenizing done by some BASICs. I suppose this also rules out self modifying scripts? Thanks for the correction! 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 Mon Jan 8 18:07:03 1996 Received: by cheltenham.cs.arizona.edu; Tue, 9 Jan 1996 08:52:09 MST To: icon-group@cs.arizona.edu Date: 8 Jan 1996 18:07:03 -0700 From: whm@primenet.com (William H. Mitchell) Message-Id: <4csf3n$744@nnrp1.news.primenet.com> Organization: Primenet Services for the Internet Sender: icon-group-request@cs.arizona.edu References: <199601051418.AA21353@gateway.fedex.com>, <4cm6lc$eob@csnews.cs.colorado.edu> Subject: Re: RFD: Programming Language Feature Matrix Errors-To: icon-group-errors@cs.arizona.edu Status: O Tom Christiansen wrote: >Having seen mistaken allegations in this thread against both java and >perl, such as in portability and security, amongst other things, I propose >the various factions on the net cooperate to create a feature matrix that >we can all fill out about many different languages to help for simplistic >at-a-glance comparisons. These already exist for shells, newsreaders, and >web browsers, so it seems a useful thing to have. I think this would be an interesting exercise and if done well, could be useful. There's certainly potential for abuse in the composition of the matrix, but Tom's proposed matrix doesn't look too bad. Let's see some more attempts at filling it out. Tom: Do it for perl! I have a few questions and comments on the list, which are flagged with "whm>". I've elided the items that I didn't have any issue with. data types recursive data types whm> Does this mean that type X can refer directly or indirectly to other instances of type X? Or, does it mean that an object can reference itself, such as a list whose first element is itself? full lexical closures whm> What's this? function calling conventions whm> In this category I suggest adding: provision for default value for omitted parameters named specification of parameters (vs. only positional) memory allocation require explicit allocation/deallocation permit explicit allocation/deallocation can trash memory via bad pointer/array reference reference-based garbage collection mark-sweep style garbage collection thread-based shared memory process-based shared memory whm> Hmm... This is a tough one. I think the fundamental question is whether memory management is manual or automatic (garbage collected). "permit explicit (de)allocation" seems troublesome -- if a language can interface with the C library it can explicitly manage some memory. If you say the language must have native support for allocation, it would eliminate C, which delegates allocation to the library. I'd say the type of garbage collection is more related to a particular implementation than the language itself. I'd say any language that can interface with a C function can get trash memory. For shared memory, what level of interaction is imagined? There's a spectrum from flipping a bit to arbitrary sharing of data between two processes. low-level access native machine language access whm> What do you mean by this? multi-threaded applications (emulated, native, and/or pthreads) whm> With this and the questions above re shared memory in mind, maybe a section on support for concurrency should be added objects fragile superclass problem whm> What's this? (I sense a perjorative wording...) operator overloading function overloading whm> These are more related to data abstraction. Perhaps that should should be a category in itself. whm> I'd surely say add encapsulation control, and class methods and data. But, if you look at the some of the latest trends in OO languages I think you'd find a quite a few things to add here. graphics whm> I suggest adding platforms on which graphic capabilities are present, e.g., X, Windows, Mac, PM, etc. patterns file wildcards (*.*) ed-style regular expression egrep-style regular expressions posix-compliant regular expressions regular expression extensions/improvements whm> There's a world beyond regular expressions. Maybe the classification should be what level of language in Chomsky's hierarchy can be described with the pattern facilities of the language. devel tools introspection (can examine its own state) whm> There are a lot of levels of introspective capability. Perhaps this should be more specific. easy ramp-up for programmer of... whm> Hmm... Another tough one. Maybe a statement of suggested background would be better. target application areas whm> I think that by the time the application areas stop coming in you're going to have a pretty big list. As an alternative, something I often think about is the philosophy of a language. For example, I think of C as a language that's close to the machine with few limitations on the programmer. With this could be included the styles supported by the language, e.g., imperative, functional, oo, logic, etc. size compiler size complete bundled kit size program source size program object size program memory size whm> These are all implementation dependent. Try completing this category for ML! robustness and support formal bug tracking system whm> Maybe I'm interpreting this wrong but wouldn't be dependent on vendors/suppliers? guaranteed virus-free kits whm> What do you mean by this? portability compiles w/ traditional C compiles w/ ansi C whm> What if there were a language not implemented in C? :-) Seriously though, this question leads into implementation dependencies. Maybe it would be appropriate to ennumerate the languages used for various implementations. To me, a thorny issue is that of language vs. library. Via a library, C has graphics, regular expressions, shared memory, threads, etc. If you say that the language must have native support for an element, say windows or regular expressions as a first-class data type, then that's biased against languages like C and Smalltalk that have a small nucleus but have extensive libraries available. I'd like to see a category for the preprocessor, if any. Ada generics and C++ templates are clearly important features, but I see no place for them. I think there should be a category on expression evaluation. That would be a place to put backtracking and another topic there could be well-defined order of evaluation. From icon-group-sender Mon Jan 15 10:54:29 1996 Received: by cheltenham.cs.arizona.edu; Tue, 16 Jan 1996 08:54:28 MST To: icon-group@cs.arizona.edu Date: 15 Jan 1996 10:54:29 GMT From: yschung2@se.cuhk.hk (JASON ~{UES}3I~}) Message-Id: <4ddbp5$f8f@eng_ser1.erg.cuhk.hk> Organization: Engineering Faculty CUHK Sender: icon-group-request@cs.arizona.edu Subject: Icon Program Source Code Errors-To: icon-group-errors@cs.arizona.edu Status: O Hi all, I would like to ask for your help as I need many many source codes of Icon programs to evaluate the performance of the Icon compiler for my final year project. I would especially like the "large" programs. So would you please send the source code to me through e-mail? Thanks for you help. Regards, Jason -- _/_/_/_/_/ _/_/_/_/ _/_/_/_/ _/ // Cheung Y. S. Jason _/ _/ _/_/ _/ _/_/ _/ // ~{UES}3I~} 1i(|&( _/_/_/_/ _/_/ _/ _/ _/_/ // yschung2@se.cuhk.hk (Final Year) _/_/ _/_/_/_/_/_/_/_/_/ _/ // http://www.se.cuhk.hk/~yschung2 From icon-group-sender Sat Jan 13 14:58:33 1996 Received: by cheltenham.cs.arizona.edu; Tue, 16 Jan 1996 08:54:03 MST From: "Hamish Lawson" Organization: University of Teesside (SCM) To: icon-group@cs.arizona.edu Date: Sat, 13 Jan 1996 14:58:33 GMT0BST Subject: Initialising tables Reply-To: H.Lawson@tees.ac.uk Priority: normal X-Mailer: Pegasus Mail/Windows (v1.22) Message-Id: <4B78DE79AC@scm_arkengarthdale.tees.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu Status: O Is there an quick way to initialise tables, along the lines of the list assignment below? aList := ["this","list","is","a","list"] I've cooked up the following, but is there a more concise way? aTable := table() every entry := ![["bob",2],["sue",5],["fred",12],["mary",9]] do aTable[entry[1]] := entry[2] | 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 Jan 15 17:04:58 1996 Received: by cheltenham.cs.arizona.edu; Tue, 16 Jan 1996 08:54:41 MST From: "Hamish Lawson" Organization: University of Teesside (SCM) To: icon-group@cs.arizona.edu Date: Mon, 15 Jan 1996 17:04:58 GMT0BST Subject: ODBC access for Icon Reply-To: H.Lawson@tees.ac.uk Priority: normal X-Mailer: Pegasus Mail/Windows (v1.22) Message-Id: <7D95425DA7@scm_arkengarthdale.tees.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu Status: O Has anyone written an Icon interface to ODBC database sources? | 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 Tue Jan 16 09:28:24 1996 Received: by cheltenham.cs.arizona.edu; Tue, 16 Jan 1996 12:30:17 MST Date: Tue, 16 Jan 1996 09:28:24 -0700 From: swampler@noao.edu Subject: Re: Initialising tables To: H.Lawson@tees.ac.uk Cc: icon-group@cs.arizona.edu Message-Id: In-Reply-To: <4B78DE79AC@scm_arkengarthdale.tees.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu Status: O Hamish Lawson wrote: > Is there an quick way to initialise tables, along the lines of the > list assignment below? > > aList := ["this","list","is","a","list"] > > I've cooked up the following, but is there a more concise way? > > aTable := table() > every entry := ![["bob",2],["sue",5],["fred",12],["mary",9]] do > aTable[entry[1]] := entry[2] > Well, this isn't any more concise in the short term, but it might be better in the long run to use a procedure to do the initialization: aTable := mktable(["bob",2],["sue",5],["fred",12],["mary",9]) where mktable() is: procedure mktable(L[]) local aT, pair aT := table() every pair := !L do { aT[pair[1]] := pair[2] } return aT end -- 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 Tue Jan 16 10:08:39 1996 Received: by cheltenham.cs.arizona.edu; Tue, 16 Jan 1996 12:30:29 MST Message-Id: Date: Tue, 16 Jan 96 12:10 IST Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Initializing tables To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O > aTable := table() every entry := ![["bob",2],["sue",5],["fred",12],["mary",9]] do aTable[entry[1]] := entry[2] For SNOBOL4+/SPITBOL, Gimpel proposes something like the following: dd = "0123456789" ;* define decimal digits atable = table() tinit = "bob2sue5fred12mary9" initl1 tinit fence break(dd) . name span(dd) . num = + ?(atable[name] = num) :s(initl1) If you have many large tables that you need to initialize this way, and in a program you intend to use many times, it can be helpful to go ahead and save the executable/intepretable to disk AFTER this preliminary execution stage is finished. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Tue Jan 16 11:42:13 1996 Received: by cheltenham.cs.arizona.edu; Tue, 16 Jan 1996 12:30:41 MST Date: Tue, 16 Jan 1996 11:42:13 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9601161742.AA15787@dragon.cs.utsa.edu> To: H.Lawson@tees.ac.uk Cc: icon-group@cs.arizona.edu In-Reply-To: <4B78DE79AC@scm_arkengarthdale.tees.ac.uk> (H.Lawson@tees.ac.uk) Subject: Re: Initialising tables Content-Length: 405 Errors-To: icon-group-errors@cs.arizona.edu Status: O How about a helper procedure like: procedure Table(default, x[]) local rv := Table(default) every k := pop(x) do rv[k] := pop(x) return rv end then your example looks like aTable := Table(&null, "bob",2, "sue",5, "fred",12, "mary",9) The built-in table() function could be extended easily along these lines. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Tue Jan 16 11:43:29 1996 Received: by cheltenham.cs.arizona.edu; Tue, 16 Jan 1996 12:30:54 MST Date: Tue, 16 Jan 1996 11:43:29 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9601161743.AA15791@dragon.cs.utsa.edu> To: H.Lawson@tees.ac.uk Cc: icon-group@cs.arizona.edu In-Reply-To: <4B78DE79AC@scm_arkengarthdale.tees.ac.uk> (H.Lawson@tees.ac.uk) Subject: Re: Initialising tables Content-Length: 279 Errors-To: icon-group-errors@cs.arizona.edu Status: O Oops: I can't have a variable named "default" now can I! That last one had better be: procedure Table(def, x[]) local rv := Table(def) every k := pop(x) do rv[k] := pop(x) return rv end Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Wed Jan 17 06:31:40 1996 Received: by cheltenham.cs.arizona.edu; Wed, 17 Jan 1996 08:43:24 MST Date: Wed, 17 Jan 1996 06:31:40 -0600 (CST) From: "Chris D. Tenaglia" To: Hamish Lawson Cc: icon-group@cs.arizona.edu Subject: Re: Initialising tables In-Reply-To: <4B78DE79AC@scm_arkengarthdale.tees.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O I do it two ways depending on whether the initials are constants or may change. If they are constants I actually do: contbl := table("n/a") contbl["xx-xx-xx"] := "###=#+##" contbl["xx-xxx-x"] := "##+###++" contbl["xxx-x-xx"] := "##-=##_#" ... If the case of configurable tables I put them in a file, perhaps referenced by an environmental variable. confile := getenv("CONFTAB") | ".conftab" (in := open(confile)) | stop("Missing ",confile) conftab := table("n/a") every line := !in do conftab[parse(line,' \t')[1]] := parse(line,' \t')[2] close(in) 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 ! On Sat, 13 Jan 1996, Hamish Lawson wrote: > Date: Sat, 13 Jan 1996 14:58:33 GMT0BST > From: Hamish Lawson > To: icon-group@cs.arizona.edu > Subject: Initialising tables > > Is there an quick way to initialise tables, along the lines of the > list assignment below? > > aList := ["this","list","is","a","list"] > > I've cooked up the following, but is there a more concise way? > > aTable := table() > every entry := ![["bob",2],["sue",5],["fred",12],["mary",9]] do > aTable[entry[1]] := entry[2] > > | 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 Jan 22 04:36:00 1996 Received: by cheltenham.cs.arizona.edu; Mon, 22 Jan 1996 11:11:54 MST To: icon-group@cs.arizona.edu Date: Mon, 22 Jan 1996 04:36:00 GMT From: bezeau@jupiter.sun.csd.unb.ca (Larry Bezeau) Message-Id: Organization: New Brunswick Centre for Educational Administration Sender: icon-group-request@cs.arizona.edu Subject: Re MVS version of Icon Errors-To: icon-group-errors@cs.arizona.edu Status: O >> If I understand the FAQ correctly there is a version of Icon that >>works under IBM's MVS system but I have not been able to find it. >>Can anyone suggest an FTP site where the executable for MVS might be >>found? >> >You should try for any Icon materials that you >seek. Icon comes from the University of Arizona, so they stand the best >chance of having what you are looking for. > I tried that already. It isn't in either the packages directory (/icon/packages) or in the binaries directory under icon. Larry Bezeau@UNB.Ca From icon-group-sender Mon Jan 22 01:39:50 1996 Received: by cheltenham.cs.arizona.edu; Mon, 22 Jan 1996 11:11:41 MST To: icon-group@cs.arizona.edu Date: Mon, 22 Jan 1996 01:39:50 GMT From: bezeau@jupiter.sun.csd.unb.ca (Larry Bezeau) Message-Id: Organization: New Brunswick Centre for Educational Administration Sender: icon-group-request@cs.arizona.edu Subject: MVS version of Icon Errors-To: icon-group-errors@cs.arizona.edu Status: O If I understand the FAQ correctly there is a version of Icon that works under IBM's MVS system but I have not been able to find it. Can anyone suggest an FTP site where the executable for MVS might be found? Larry Bezeau@UNB.Ca From icon-group-sender Mon Jan 22 16:04:35 1996 Received: by cheltenham.cs.arizona.edu; Mon, 22 Jan 1996 16:25:25 MST From: Nick Williams Message-Id: <199601222104.QAA03988@styx.ios.com> Subject: Hacking icon src; adding features To: icon-group@cs.arizona.edu Date: Mon, 22 Jan 1996 16:04:35 -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: 2786 Errors-To: icon-group-errors@cs.arizona.edu Status: O I'm not a member of the Icon Project; just an Icon enthusiast. I like the language a lot, but there's a handful of features I wish were there that aren't, in particular I wish it had closures. In the past, when I've brought this up, I was told that this wasn't going to be considered soon, besides which co-expressions provide a rough sort of closures. So I've been looking lately to implement closures myself. After much consideration, the simplest way to do this, with the least amount of work needed is to modify the interpreter to load and save the values of closed local variables in a list a pointer to which is stored in the b_proc structure for each procedure; a new function (closeproc()) is used to create new copies of Icon procedure some, or all of whose local variables have persistent values. Those of you who are familiar with Lisp probably understand what I am talking about, for those who don't, the best way to describe this feature is that with it you can make copies of a procedure that has static variables such that each copy has _different_ static variables. Here's how I'm going about implementing this: - add a new field to the b_proc structure: struct descrip closedvars which should normally be &null or point to an Icon list. - fix invoke.r:invoke() so that when it's done manipulating the stack it copies the stored values of closed variables into the corresponding local variables on the stack. The list pointed to by the new closedvars field of b_proc consists of descriptor pairs, where the first descriptor is an integer representing an index into the local variable array, and the second descriptor is the stored value for that local variable. - fix interp.r:interp() so that the values of closed local variables are copied back into the closedvars list whenever a procedure with closed variables returns or fails. - fix icont/lcode.c:lemitproc() and icont/lcode.c:gentables() so the closedvars field of b_proc structures is initialized to &null. - fix the firstd[] and other tables in rmemmgt.r. - fix init.r (the B_IProc(n) stuff). - add closeproc() to runtime/fmisc.r. This function should take an Icon procedure as its first argument, followed by variable_name:initial_value pairs. A more Lisp-like procedure closing function can be built ontop of this. I would much rather do the above for static procedure variables instead of local dynamic variables, but that would require much larger changes. I've got most of the above complete, and at least I have something that compiles (I have yet to test it). But since I'm have little knowledge of the implementation of Icon, I must ask wether there is any other place I must look in and edit to make this work. Any comments? Ideas? Nick From icon-group-sender Mon Jan 22 21:37:44 1996 Received: by cheltenham.cs.arizona.edu; Tue, 23 Jan 1996 08:35:18 MST To: icon-group@cs.arizona.edu Date: 22 Jan 1996 21:37:44 GMT From: CHD@AZCC.arizona.edu (Chris De Young) Message-Id: <4e1038$fng@news.ccit.arizona.edu> Organization: -- Sender: icon-group-request@cs.arizona.edu Subject: Line continuation in $define ? Errors-To: icon-group-errors@cs.arizona.edu Status: O How do you (or can you) continue a line in a $define macro? What I want to do is: $ define foo "Some really long literal string that won't fit on one line neatly; do I have to make it ugly by forcing it to go on one line (in the process finding a text editor that won't complain about lines longer than 255 characters)?" Thanks... ;) -Chris De Young chd@Arizona.EDU From icon-group-sender Mon Jan 22 18:10:40 1996 Received: by cheltenham.cs.arizona.edu; Tue, 23 Jan 1996 08:34:34 MST Date: Mon, 22 Jan 1996 18:10:40 -0800 Message-Id: <199601230210.SAA29372@ix3.ix.netcom.com> X-Sender: bobalex@netcom.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: Bob Alexander Subject: Win95 DLL version of Icon? Errors-To: icon-group-errors@cs.arizona.edu Status: O Has anyone built a version of iconx that can run as a DLL under Windows 95? Graphics facilities are not necessary (yet). Any suggestions for a Windows novice on how to do that? Bob Alexander bobalex@netcom.com From icon-group-sender Tue Jan 23 20:07:53 1996 Received: by cheltenham.cs.arizona.edu; Tue, 23 Jan 1996 12:21:12 MST Date: Tue, 23 Jan 1996 20:07:53 +0200 (WET) From: Ehud Lamm To: Larry Bezeau Cc: icon-group@cs.arizona.edu Subject: Re: Re MVS version of Icon In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O As far as I reacll the MVS version of Icon is only available on magnetic tape - via the Icon Project. Maybe someone can give more details. If not - either send them mail, or check the Icon WWW site for previous Icon Newletters. Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Thu Jan 25 00:06:53 1996 Received: by cheltenham.cs.arizona.edu; Thu, 25 Jan 1996 08:36:23 MST To: icon-group@cs.arizona.edu Date: 25 Jan 1996 00:06:53 -0500 From: ganntrader@aol.com (Ganntrader) Message-Id: <4e735d$o62@newsbf02.news.aol.com> Organization: America Online, Inc. (1-800-827-6364) Sender: icon-group-request@cs.arizona.edu Reply-To: ganntrader@aol.com (Ganntrader) Subject: icon for the mac Errors-To: icon-group-errors@cs.arizona.edu Status: O Where would I find the current version of Icon for the Macintosh? The only one I have found so far is ver. 8.0 -- is that the "current" version? Any help on an ftp site would be appreciated. Don Fisher <<>> ganntrader@aol.com -------------------------------------------- "The more of the past you can understand, the more of the future you can comprehend". -------------------------------------------- From icon-group-sender Thu Jan 25 13:46:08 1996 Received: by cheltenham.cs.arizona.edu; Thu, 25 Jan 1996 13:47:04 MST Date: Thu, 25 Jan 1996 13:46:08 MST From: "Cliff Hathaway" Message-Id: <199601252046.AA20953@cheltenham.cs.arizona.edu> To: ganntrader@aol.com, icon-group@cs.arizona.edu Subject: Re: icon for the mac Errors-To: icon-group-errors@cs.arizona.edu Status: O The latest Icon materials can always be found at ftp.cs.arizona.edu:/icon. A version 9 implementation of Icon for the Mac is in the works under the guidance of Clint Jeffery at the University of Texas at San Antonio. There are 2 version 8.0 releases of Icon for the Mac available in the /icon/packages/macintosh directory at ftp.cs.arizona.edu (a standalone version, and a version that is more Mac-aware, called ProIcon). A version 9.0 imple- mentation that runs under the Macintosh Programmer's Workbench is also available in that directory. Cliff Hathaway, Icon Project Dept. of Computer Science (520)621-4291 University of Arizona cliff@cs.arizona.edu (internet) Tucson, Ariz. 85721 {cmcl2,noao,uunet}!arizona!cliff (uucp) > From: ganntrader@aol.com (Ganntrader) > Subject: icon for the mac > > Where would I find the current version of Icon for the Macintosh? The > only one I have found so far is ver. 8.0 -- is that the "current" version? > Any help on an ftp site would be appreciated. > > > Don Fisher <<>> ganntrader@aol.com > -------------------------------------------- > "The more of the past you can understand, > the more of the future you can comprehend". > -------------------------------------------- > From icon-group-sender Wed Jan 24 10:20:36 1996 Received: by cheltenham.cs.arizona.edu; Thu, 25 Jan 1996 16:24:24 MST To: icon-group@cs.arizona.edu Date: 24 Jan 1996 10:20:36 -0700 From: gmt@cs.arizona.edu (Gregg Townsend) Message-Id: <4e5pp4$qlf@hawk.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <4e1038$fng@news.ccit.arizona.edu> Subject: Re: Line continuation in $define ? Errors-To: icon-group-errors@cs.arizona.edu Status: O Chris De Young wrote: > How do you (or can you) continue a line in a $define macro? There's no way to do it directly, but you can do something like this: $define part1 "..........................................................." $define part2 "..........................................................." $define part3 "..........................................................." $define part4 "..........................................................." $define part5 "..........................................................." $define longstring (part1 || part2 || part3 || part4 || part5) The concatenation takes place at execution time, so you won't want to use it inside a tight loop, but other than that it should be fine. 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 Sun Jan 28 21:46:33 1996 Received: by cheltenham.cs.arizona.edu; Mon, 29 Jan 1996 06:49:38 MST To: icon-group@cs.arizona.edu Date: 28 Jan 1996 21:46:33 GMT From: rahardj@cc.umanitoba.ca (Budi Rahardjo) Message-Id: Organization: University of Manitoba Sender: icon-group-request@cs.arizona.edu Subject: processing utmp and/or wtmp with icon Errors-To: icon-group-errors@cs.arizona.edu Status: O We are planning to write a program which converts utmp/wtmp file into somekind of database (delimitted, flat file would be good enough). The database is used to produces statistics such as usage, number of logins, how many hours one has logged in to a system this month, etc. We want to produce this stats in real time too. Actually, I have written this in perl but wanted to make it an executable. Icon seems to be a natural approach ( don't want to go to C or C++). Before I start rolling the design, has anybody done this? Any tips. Thanks -- budi -- Budi Rahardjo #include From icon-group-sender Mon Jan 29 10:05:18 1996 Received: by cheltenham.cs.arizona.edu; Mon, 29 Jan 1996 12:22:42 MST Date: Mon, 29 Jan 1996 10:05:18 -0600 (CST) From: "Chris D. Tenaglia" To: Budi Rahardjo Cc: icon-group@cs.arizona.edu Subject: Re: processing utmp and/or wtmp with icon In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O Here's a quick sample of my approach. It worked on solaris, but may need adjustments elsewhere. I did a man utmp to get the record layout. Anyway, the basic approach is: ########################### begin program ####################### # file : get_utmp.icn # desc : reads /etc/utmp and outputs ascii lines # use : get_utmp [>outfile] # warn : Worked on solaris, others? I don't know. Needs calc_date() finished # to convert date to readable form. AS IS. NO WARANTY. # # update by what # 29-jan-1996 tenaglia initial write # procedure main() ut_table := table("Unknown") ut_table[0] := "EMPTY" ut_table[1] := "RUN_LVL" ut_table[2] := "BOOT_TIME" ut_table[3] := "OLD_TIME" ut_table[4] := "NEW_TIME" ut_table[5] := "INIT_PROCESS" ut_table[6] := "LOGIN_PROCESS" ut_table[7] := "DEAD_PROCESS" ut_table[8] := "ACCOUNTING" in := open("/etc/utmp","u") while entry := reads(in,36) do { entry ? { user := map(move(8),"\0"," ") utab := map(move(4),"\0"," ") utli := map(move(12),"\0"," ") pid := move(2) utyp := move(2) tsta := move(2) esta := move(2) utim := move(4) } pid := right(decimal(pid),6) ut_type := left(ut_table[decimal(utyp)],16) tstatus := right(decimal(tsta),4) estatus := right(decimal(esta),4) timus := calc_date(decimal(utim)) write(user," ",utab," ",utli," ",pid," ",ut_type," ",tstatus," ",estatus," ",timus) } close(in) end # # determine the value of a raw hex number # procedure decimal(raw) begin := 0 total := 0 every i := *raw to 1 by -1 do { value := ord(raw[i]) total+:= value * (256^begin) begin+:= 1 } return total end # # calculate date based from seconds after 1970 # needs to be completed. # procedure calc_date(value) static leaps,spy,sply,cury initial { leaps := set([1972,1976,1980,1984,1988,1992,1996,2000,2004]) spy := 31536000 sply := 31622400 cury := &date[1+:4] } if 0 > value > 1000000000 then return "Out of range" yr := 1970 return value repeat { } end #################### END CODE ############################### 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 ! On 28 Jan 1996, Budi Rahardjo wrote: > Date: 28 Jan 1996 21:46:33 GMT > From: Budi Rahardjo > To: icon-group@cs.arizona.edu > Subject: processing utmp and/or wtmp with icon > > We are planning to write a program which converts utmp/wtmp file > into somekind of database (delimitted, flat file would be good enough). > The database is used to produces statistics such as usage, number of logins, > how many hours one has logged in to a system this month, etc. > We want to produce this stats in real time too. > > Actually, I have written this in perl but wanted to make it an executable. > Icon seems to be a natural approach ( don't want to go to C or C++). > Before I start rolling the design, has anybody done this? > Any tips. > > Thanks > -- budi > -- > Budi Rahardjo > #include > > From icon-group-sender Mon Jan 29 20:00:43 1996 Received: by cheltenham.cs.arizona.edu; Tue, 30 Jan 1996 08:56:49 MST Date: Mon, 29 Jan 1996 20:00:43 -0600 Message-Id: <199601300200.UAA15211@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: processing utmp and/or wtmp with icon To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >We are planning to write a program which converts utmp/wtmp file into somekind of database (delimitted, flat file would be good enough). The database is used to produces statistics such as usage, number of logins, how many hours one has logged in to a system this month, etc. We want to produce this stats in real time too. >Actually, I have written this in perl but wanted to make it an executable. Icon seems to be a natural approach ( don't want to go to C or C++). Before I start rolling the design, has anybody done this? Any tips. Does it need to be an actual hard *.EXE file, or is it enough to have it be "protected" rather than source? For example, SNOBOL4+ produces a *.SAV file which cannot be readily decompiled. That plus the one .EXE file is sufficient to run a program. (You could probably rename the interpreter and then patch it to look for *.OVL instead of *.SAV, and then call it an "executable program with an overlay") :-) Alternatively, SPITBOL will generate true .EXE files too... Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Jan 31 21:52:13 1996 Received: by cheltenham.cs.arizona.edu; Thu, 1 Feb 1996 08:49:09 MST Date: Wed, 31 Jan 1996 21:52:13 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9602010352.AA08648@boar.cs.utsa.edu> To: icon-group@cs.arizona.edu Cc: bright@sctc.com Subject: Icon for MS Windows status Content-Length: 372 Errors-To: icon-group-errors@cs.arizona.edu Status: O A new set of MS Windows Icon binaries based on Arizona Version 9.1 is available for FTP from ringer.cs.utsa.edu, directory pub/icon/nt/graphics. In addition to the version update, these binaries have fixed aspects of keystroke handling for non-printing characters and a few reported bugs. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Fri Feb 2 02:56:56 1996 Received: by cheltenham.cs.arizona.edu; Fri, 2 Feb 1996 12:42:23 MST To: icon-group@cs.arizona.edu Date: 2 Feb 1996 02:56:56 GMT From: mustard@interlog.com Message-Id: <4eruho$aj0@steel.interlog.com> Organization: InterLog Internet Services Sender: icon-group-request@cs.arizona.edu References: Reply-To: mustard@interlog.com Subject: Re: processing utmp and/or wtmp with icon Errors-To: icon-group-errors@cs.arizona.edu Status: O In , rahardj@cc.umanitoba.ca (Budi Rahardjo) writes: >We are planning to write a program which converts utmp/wtmp file >into somekind of database (delimitted, flat file would be good enough). What's wrong with "fwtmp" that comes with your wtmp producer? (UNIX) Or "who -a"? I certainly would have one of these in a pipeline to a simpler program (awk (herasy ;-) to do the job. I do infact parse the output of fwtmp with an awk script to detect login/out activity. >The database is used to produces statistics such as usage, number of logins, >how many hours one has logged in to a system this month, etc. >We want to produce this stats in real time too. > >Actually, I have written this in perl but wanted to make it an executable. What's an "executable"? >Icon seems to be a natural approach ( don't want to go to C or C++). Icon works but best on a text, not binary, (IMHO) file. But either perl or icon implies shipping extra stuff with your code that _may_ make support or portability more difficult. Note that wtmp/utmp files are different on different *ix versions. >Before I start rolling the design, has anybody done this? >Any tips. From icon-group-sender Fri Feb 2 05:21:47 1996 Received: by cheltenham.cs.arizona.edu; Fri, 2 Feb 1996 12:42:36 MST To: icon-group@cs.arizona.edu Date: Fri, 2 Feb 1996 05:21:47 GMT From: rpereda@wotangate.sc.ti.com (Ray Pereda) Message-Id: <1996Feb2.052147.25050@newshost.micro.ti.com> Organization: Texas Instruments Inc. Sender: icon-group-request@cs.arizona.edu Reply-To: rpereda@wotangate.sc.ti.com Subject: Eli compiler construction system and Icon Errors-To: icon-group-errors@cs.arizona.edu Status: O In the Sept. 1995 issue of the ACM Tran. on Prog. Lang. and Systems there is a really nice article on a comparison between a hand-coded version of the Icon translator and one generated by Eli. The paper was pretty focused on the performance aspects of Eli. I want some comparison between the maintenance effort between the handed-code icont and an Eli generated icont. Does anyone have any opinion? --- Ray Pereda rpereda@tools.micro.ti.com From icon-group-sender Fri Feb 2 10:20:25 1996 Received: by cheltenham.cs.arizona.edu; Fri, 2 Feb 1996 12:42:47 MST Date: Fri, 2 Feb 1996 10:20:25 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9602021620.AA10426@dragon.cs.utsa.edu> To: jk@soas.ac.uk Cc: icon-group@cs.arizona.edu In-Reply-To: <25A6207A9E@soas.ac.uk> (message from Jonathan Kaye on Fri, 2 Feb 1996 10:46:15 GMT) Subject: Re: nticont for NT (9.1) Content-Length: 832 Errors-To: icon-group-errors@cs.arizona.edu Status: O [Jonathan Kaye writes, asking how to build the Icon Program Library using the Windows Icon 9.1 release:] JK> Can you PLEASE tell us (icon-group) where to find the nticont.exe JK> binary for 9.1. I need it to update all my procs & gprocs to 9.1 JK> without having to do them one by one. wicont.exe accepts *.icn wildcards that help in translating large numbers of files. The window that it opens normally waits for a user keystroke on termination, so that you can read the messages; a -q option disables this for use in scripts. If there are numerous folks who need NT console binaries, I'll produce a set. Since they don't run under Win3.1 and probably don't run on Warp or Windows95, I'm not sure what the level of demand for them is. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Mon Feb 5 13:09:31 1996 Received: by cheltenham.cs.arizona.edu; Mon, 5 Feb 1996 16:57:34 MST To: icon-group@cs.arizona.edu Date: 5 Feb 1996 13:09:31 -0700 From: icon-project@cs.arizona.edu Message-Id: <4f5o5r$b3n@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 Status: O Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language Last updated: January 8, 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 UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and the Acorn Archimedes. There are older versions for 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, and runs on UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and Acorn Archimedes. Other implementations presently are at Version 8. Almost all programs that run under Version 8 and that do not use graphics will run under Version 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. Icon is available on CD-ROM from Prime Time Freeware (http://www.ptf.com/, 408-433-9662). Contact them for details. 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 Wed Feb 7 03:33:29 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Feb 1996 09:14:04 MST Date: Wed, 7 Feb 1996 03:33:29 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9602070933.AA01702@dragon.cs.utsa.edu> To: icon-group@cs.arizona.edu Subject: IPL references coming to the web Content-Length: 774 Errors-To: icon-group-errors@cs.arizona.edu Status: O The Icon Program Library is arguably one of the most valuable and most underutilized resources available to Icon programmers. One way to make it easier to use is to improve its documentation. Thanks to a standard header comment format introduced by Ralph Griswold, it is possible to extract much information automatically from the IPL source files themselves. An example of this is a collection of IPL Web pages rooted at http://www.cs.utsa.edu/research/icon/ipl/HTML/ Suggestions on improving this documentation are welcome. The folks at Arizona have other on-line documents for IPL in the works; look forward to more and better. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio research page: http://www.cs.utsa.edu/research/plss.html From icon-group-sender Tue Feb 6 07:33:41 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Feb 1996 12:30:03 MST To: icon-group@cs.arizona.edu Date: 6 Feb 1996 07:33:41 GMT From: rahardj@cc.umanitoba.ca (Budi Rahardjo) Message-Id: Organization: University of Manitoba Sender: icon-group-request@cs.arizona.edu References: , <4eruho$aj0@steel.interlog.com> Subject: Re: processing utmp and/or wtmp with icon Errors-To: icon-group-errors@cs.arizona.edu Status: O mustard@interlog.com wrote: ... : "fwtmp" and "who -a" Is this portable. ... >>Actually, I have written this in perl but wanted to make it an executable. > >What's an "executable"? I mean binary executable file, not a script. Somebody pointed out "sac". It does the job. So I am using it now. >Icon works but best on a text, not binary, (IMHO) file. But either perl >or icon implies shipping extra stuff with your code that _may_ make >support or portability more difficult. Actually, perl is portable. (I even work with perl on my 286. Yes, 286) -- budi -- Budi Rahardjo #include Unix Support/Administrator - Computer Services - University of Manitoba From icon-group-sender Wed Feb 7 11:47:33 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Feb 1996 12:29:46 MST Date: Wed, 7 Feb 1996 11:47:33 -0600 Message-Id: <199602071747.LAA10210@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: On-line IPL documentation To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >An example of this is a collection of IPL Web pages rooted at http://www.cs.utsa.edu/research/icon/ipl/HTML/ >Suggestions on improving this documentation are welcome. I've taken a look at the Web page. Here are my preliminary comments: 1) The directory listing would be more usable if it were posted as an unordered list, so that entries would be on separate lines (note that not everybody chooses to use Netscape). 2) I think it would also be helpful to give some indication as to how major and/or complete the application is. A trivial fifteen-line program that "counts words and lines of a source file" is obviously in a very different class than a much more ambitious application of several hundred (or thousand) lines. The kind of information that could be collected automatically and which might give at least a hint about program completeness would be lines or bytes of source, and perhaps how many different data files the program uses. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Feb 8 12:06:34 1996 Received: by cheltenham.cs.arizona.edu; Thu, 8 Feb 1996 12:21:59 MST From: Nick Williams Message-Id: <199602081706.MAA01427@styx.ios.com> Subject: Copying procedure blocks To: icon-group@cs.arizona.edu Date: Thu, 8 Feb 1996 12:06:34 -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: 2912 Errors-To: icon-group-errors@cs.arizona.edu Status: O Hi, several days ago I posted a note about adding closures to Icon as a feature. Since then I have realized that it would indeed be much easier to make it so that invoking copy() with a procedure as an argument would return a new procedure block with new copies of any static variables. It has taken me some time to figure out how to do it, but in the end it is relatively simple. I've changed a few lines of code and what I have works, except for a few small bugs that I hope someone can help me with. The main bug is that garbage collection causes core dumps if it also causes procedure blocks to move around; the other main bug is that I have not at all delved into how the compiler works, so this feature is only available with the interpreter. Here's all I did: 1) changed src/icont/lcode.c to output &null descriptors at the end of b_proc structures after the descriptors of local/static/argument names (and adjusting the blksize field accordingly). 2) changed the implementation of the Op_Static and Op_Astatic Icon virtual machine instructions; instead of using the argument to index a global table, Op_Static now uses the argument to index the set of descriptors at the end of the b_proc structure of the current procedure. 3) changed the copy() function to actually make a new copy of its argument if it is a procedure. I have yet to go change getvar() and get_name() so that they work with this scheme, but that too is a fairly simple task. I also intend to change the implementation of Op_Init and of the refresh operation so that new copies of procedures can be "refreshed." I have assumed a few things: a) that the garbage collector will continue to function correctly, since it will sweep the new descriptors at the end of b_proc sturctures because it uses the blksize field to know when to stop; and b) that "argp[0]" points to the b_proc structure of the procedure in whose scope Op_Static and Op_Astatic are being called; and c) that "argp[0]" is updated if the structure it points to is moved as a result of a garbage collection event. The changes I have made, btw, fit in one printed page and what remains to be done to make this scheme work should be just as simple. I just can't get past why I get these core dumps when procedure blocks are relocated during garbage collection. If anyone is interested I will post a set of diffs showing the changes I have made. I plan to use this feature to, among other things, implement a dynamic RPC mechanism. Nick PS: as this hack stands it involves changes these source files: src/icont/lcode.c:lemitproc() src/runtime/interp.r:interp() [Op_Static and Op_Astatic] src/runtime/fmisc.r:copy() I will also change: src/runtime/rmisc.r:get_var() src/runtime/rdebug.r:getname() src/runtime/interp.r:interp() [Op_Init] src/h/rstructs.r:struct b_proc [to add a field to help with Op_Init] From icon-group-sender Thu Feb 8 19:17:25 1996 Received: by cheltenham.cs.arizona.edu; Thu, 8 Feb 1996 14:41:19 MST To: icon-group@cs.arizona.edu Date: 8 Feb 1996 19:17:25 GMT From: millejoh@holly.ColoState.EDU (John Miller) Message-Id: <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> Organization: Colorado State University, Fort Collins, CO 80523 Sender: icon-group-request@cs.arizona.edu Subject: Compiling ELF binaries for Linux1.2.13 Errors-To: icon-group-errors@cs.arizona.edu Status: O Greetings all. I'm curious if anybody has had some experience in compiling ELF binaries of Icon for linux. Using a.out binaries is of course a viable solution, but I would at least like to try getting ELF working first. My problem is as follows: The gcc compiler is failing when trying to link in the object files for icon runtime executable (iconx). It complains of some unidentified symbols in rswitch.o -- namely new_context and syserr. I realize these are for implementing coexpressions, a feature that I can disable, but again I would like to try to get it to work. Any suggestions people? My setup: i486_linux 8MB RAM (486DX33) I'm using the RedHat v2.0 elf distribution with X11R6. Many thanks in advance, John From icon-group-sender Fri Feb 9 02:31:59 1996 Received: by cheltenham.cs.arizona.edu; Fri, 9 Feb 1996 09:17:22 MST To: icon-group@cs.arizona.edu Date: 09 Feb 1996 02:31:59 +0100 From: Gerhard Brey Message-Id: Organization: Institut fuer Geschichte der Naturwissenschafen, Munich, Germany Sender: icon-group-request@cs.arizona.edu References: <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> Subject: Re: Compiling ELF binaries for Linux1.2.13 Errors-To: icon-group-errors@cs.arizona.edu Status: O In article <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> millejoh@holly.ColoState.EDU (John Miller) writes: > > Greetings all. I'm curious if anybody has had some experience in > compiling ELF binaries of Icon for linux. Using a.out binaries is of course > a viable solution, but I would at least like to try getting ELF working > first. My problem is as follows: > The gcc compiler is failing when trying to link in the object > files for icon runtime executable (iconx). It complains of some > unidentified symbols in rswitch.o -- namely new_context and syserr. > I realize these are for implementing coexpressions, a feature that > I can disable, but again I would like to try to get it to work. > Any suggestions people? > My setup: > i486_linux 8MB RAM (486DX33) > I'm using the RedHat v2.0 elf distribution with X11R6. > > Many thanks in advance, > John I had the same problems when I tried to compile iconx as ELF binary. But iconc compiled without problems and works. I would be very grateful for a solution, too. The problems occurred with the configuration for i486_linux (i386_linux didn't work either, but I don't remember why). I guess (but I am not a C- or Assembler-programmer) that the problem has to do with the Assembler code in rswitch.s. Here is my setup: 486DX66, 16MB RAM Slackware 3.0 ELF gcc 2.7.0 Here are the error messages: [...] gcc -o iconx xcnv.o xdata.o xdef.o xerrmsg.o xextcall.o xfconv.o xfload.o xfmath.o xfmisc.o xfmonitr.o xfscan.o xfstr.o xfstranl.o xfstruct.o xfsys.o xfwindow.o ximain.o ximisc.o xinit.o xinterp.o xinvoke.o xistart.o xkeyword.o xlmisc.o xoarith.o xoasgn.o xocat.o xocomp.o xomisc.o xoref.o xoset.o xovalue.o xralc.o xrcoexpr.o xrcomp.o xrdebug.o xrlocal.o xrlrgint.o xrmemmgt.o xrmisc.o xrstruct.o xrsys.o xrwinrsc.o xrgfxsys.o xrwinsys.o xrwindow.o xfxtra.o ../common/long.o ../common/memory.o ../common/time.o ../common/save.o ../common/rswitch.o ../common/redirerr.o ../common/xwindow.o ../common/alloc.o -L../../bin -lXpm -lX11 -lm bfd assertion fail /opt/release/pub/bin/binutils/bfd/elf32-i386.c:624 xrcoexpr.o(.text+0x239): undefined reference to `coswitch' ../common/rswitch.o(.text+0x27): undefined reference to `_new_context' ../common/rswitch.o(.text+0x31): undefined reference to `_syserr' make[3]: *** [iconx] Error 1 [...] Gerhard -- ............................................................................ Gerhard Brey / Institut fuer Geschichte : ug301ab@sunmail.lrz-muenchen.de der Naturwissenschaften d. Univ. Muenchen : Tel.: +49 89 2180-3252 Postfach / 80306 Muenchen / Germany : FAX: +49 89 2180-3162 From icon-group-sender Fri Feb 9 17:34:49 1996 Received: by cheltenham.cs.arizona.edu; Fri, 9 Feb 1996 13:15:32 MST To: icon-group@cs.arizona.edu Date: 9 Feb 1996 17:34:49 GMT From: michal@gortel.phys.ualberta.ca (Michal Jaegermann) Message-Id: <4fg0jp$1vd6@pulp.ucs.ualberta.ca> Organization: Disorganized Bits Sender: icon-group-request@cs.arizona.edu References: <4fdi85$4b7o@yuma.ACNS.ColoState.EDU>, Reply-To: michal@gortel.phys.ualberta.ca Subject: Re: Compiling ELF binaries for Linux1.2.13 Errors-To: icon-group-errors@cs.arizona.edu Status: O Gerhard Brey (G.Brey@lrz.uni-muenchen.de) wrote: : In article <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> millejoh@holly.ColoState.EDU (John Miller) writes: : > unidentified symbols in rswitch.o -- namely new_context and syserr. : I guess : (but I am not a C- or Assembler-programmer) that the problem has to do : with the Assembler code in rswitch.s. If the problem is caused by symbols from an assembler code then most likely it is a trivial one. Elf symbols do not have prepended '_' character; assembler likely assumes that they do. Just adjust names. --mj From icon-group-sender Sun Feb 11 03:03:30 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Feb 1996 10:36:50 MST To: icon-group@cs.arizona.edu Date: 11 Feb 1996 03:03:30 +0100 From: Gerhard Brey Message-Id: Organization: Institut fuer Geschichte der Naturwissenschafen, Munich, Germany Sender: icon-group-request@cs.arizona.edu References: <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> Reply-To: ug301ab@sunmail.lrz-muenchen.de Subject: Re: Compiling ELF binaries for Linux1.2.13 Errors-To: icon-group-errors@cs.arizona.edu Status: O In article <4fg0jp$1vd6@pulp.ucs.ualberta.ca> michal@gortel.phys.ualberta.ca (Michal Jaegermann) writes: > > Gerhard Brey (G.Brey@lrz.uni-muenchen.de) wrote: > : In article <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> millejoh@holly.ColoState.EDU (John Miller) writes: > > : > unidentified symbols in rswitch.o -- namely new_context and syserr. > > : I guess > : (but I am not a C- or Assembler-programmer) that the problem has to do > : with the Assembler code in rswitch.s. > > If the problem is caused by symbols from an assembler code then most > likely it is a trivial one. Elf symbols do not have prepended '_' > character; assembler likely assumes that they do. Just adjust names. > Thanks for the advice. I deleted the `_' in front of the symbol names in rswitch.s. Now `iconx' is built but there is still the bfd assertion fail /opt/release/pub/bin/binutils/bfd/elf32-i386.c:624 and when I try to execute `iconx' it stops with a segmentation fault. Gerhard -- ............................................................................ Gerhard Brey / Institut fuer Geschichte : ug301ab@sunmail.lrz-muenchen.de der Naturwissenschaften d. Univ. Muenchen : Tel.: +49 89 2180-3252 Postfach / 80306 Muenchen / Germany : FAX: +49 89 2180-3162 From icon-group-sender Sun Feb 11 17:50:51 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Feb 1996 10:36:59 MST To: icon-group@cs.arizona.edu Date: 11 Feb 1996 17:50:51 GMT From: millejoh@holly.ColoState.EDU (John Miller) Message-Id: <4fla9r$17oc@yuma.ACNS.ColoState.EDU> Organization: Colorado State University, Fort Collins, CO 80523 Sender: icon-group-request@cs.arizona.edu References: <4fdi85$4b7o@yuma.ACNS.ColoState.EDU>, Subject: Re: Compiling ELF binaries for Linux1.2.13 Errors-To: icon-group-errors@cs.arizona.edu Status: O Gerhard Brey (G.Brey@lrz.uni-muenchen.de) wrote: : In article <4fg0jp$1vd6@pulp.ucs.ualberta.ca> michal@gortel.phys.ualberta.ca (Michal Jaegermann) writes: : > : > Gerhard Brey (G.Brey@lrz.uni-muenchen.de) wrote: : > : In article <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> millejoh@holly.ColoState.EDU (John Miller) writes: : > : > : > unidentified symbols in rswitch.o -- namely new_context and syserr. : > : > : I guess : > : (but I am not a C- or Assembler-programmer) that the problem has to do : > : with the Assembler code in rswitch.s. : > : > If the problem is caused by symbols from an assembler code then most : > likely it is a trivial one. Elf symbols do not have prepended '_' : > character; assembler likely assumes that they do. Just adjust names. : > : Thanks for the advice. I deleted the `_' in front of the symbol names : in rswitch.s. Now `iconx' is built but there is still the : bfd assertion fail /opt/release/pub/bin/binutils/bfd/elf32-i386.c:624 : and when I try to execute `iconx' it stops with a segmentation fault. : Gerhard I'm getting exactly the same results. I'll search around comp.os.linux.* and see what I can come up with. Wish me luck! John From icon-group-sender Fri Feb 9 19:47:44 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Feb 1996 10:36:40 MST To: icon-group@cs.arizona.edu Date: 9 Feb 1996 19:47:44 -0500 From: ganntrader@aol.com (Ganntrader) Message-Id: <4fgpvg$ns0@newsbf02.news.aol.com> Organization: America Online, Inc. (1-800-827-6364) Sender: icon-group-request@cs.arizona.edu Reply-To: ganntrader@aol.com (Ganntrader) Subject: Executables in Icon? Errors-To: icon-group-errors@cs.arizona.edu Status: O Are there any implementations of a Icon which will allow one to produce free-standing applications for both PC and Mac (ie. .exe and double-clickable applications)? Thanks for your help. Don Fisher From icon-group-sender Sat Feb 10 14:56:52 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Feb 1996 10:36:19 MST To: icon-group@cs.arizona.edu Date: 10 Feb 1996 14:56:52 GMT From: mustard@interlog.com Message-Id: <4fibnk$8dh@steel.interlog.com> Organization: InterLog Internet Services Sender: icon-group-request@cs.arizona.edu References: , <4eruho$aj0@steel.interlog.com>, Reply-To: mustard@interlog.com Subject: Re: processing utmp and/or wtmp with icon Errors-To: icon-group-errors@cs.arizona.edu Status: O In , rahardj@cc.umanitoba.ca (Budi Rahardjo) writes: >mustard@interlog.com wrote: >.... >: "fwtmp" and "who -a" > >Is this portable. Not really, but those systems with wtmp _usually_ have a "fwtmp" with fairly constant output format, depending on what fields you need. > >.... >>>Actually, I have written this in perl but wanted to make it an executable. >> >>What's an "executable"? > >I mean binary executable file, not a script. >Somebody pointed out "sac". It does the job. So I am using it now. I'm not familiar with "sac" can you send me a pointer? > >>Icon works but best on a text, not binary, (IMHO) file. But either perl >>or icon implies shipping extra stuff with your code that _may_ make >>support or portability more difficult. > >Actually, perl is portable. (I even work with perl on my 286. Yes, 286) Perl itself is very portable (congrats to the developers) but since it subsumes many OS features those features may or may not be there (sockets are the current bain of my life). But in this context (wtmp) we can assume most of the *ix OS features. If you are trying to hide your code, perl 5 offers encrypted source tools (and compression) that may do the trick with less effort than porting to a new language. > >-- budi >-- Bill Mustard (mustard@interlog.com) From icon-group-sender Mon Feb 12 12:48:47 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Feb 1996 12:26:13 MST Date: Mon, 12 Feb 1996 12:48:47 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9602121848.AA08418@water.cs.utsa.edu> To: ug301ab@sunmail.lrz-muenchen.de Cc: icon-group@cs.arizona.edu In-Reply-To: (message from Gerhard Brey on 11 Feb 1996 03:03:30 +0100) Subject: Re: Compiling ELF binaries for Linux1.2.13 Content-Length: 807 Errors-To: icon-group-errors@cs.arizona.edu Status: O > [Gerhard Brey writes about his attempt to build Linux Icon ELF binaries:] > I deleted the `_' in front of the symbol names > in rswitch.s. Now `iconx' is built but there is still the > > bfd assertion fail /opt/release/pub/bin/binutils/bfd/elf32-i386.c:624 > > and when I try to execute `iconx' it stops with a segmentation fault. This is a bug in the Linux ELF linker ld(1) under Slackware 3.0. One workaround is to build and use a.out executables; the new Linux supports both formats and can build a.out Icon binaries if compiler and library support for a.out is installed. There may be a preferable workaround; if someone has encountered this problem and actually solved it, it would be great to hear how. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Mon Feb 12 11:01:15 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Feb 1996 17:25:53 MST To: icon-group@cs.arizona.edu Date: 12 Feb 1996 11:01:15 -0800 From: Steven L Baur Message-Id: Organization: Miranova Systems, Inc. Sender: icon-group-request@cs.arizona.edu References: <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> Subject: Re: Compiling ELF binaries for Linux1.2.13 Errors-To: icon-group-errors@cs.arizona.edu Status: O >>>>> "John" == John Miller writes: John> Gerhard Brey (G.Brey@lrz.uni-muenchen.de) wrote: John> : In article <4fg0jp$1vd6@pulp.ucs.ualberta.ca> michal@gortel.phys.ualberta.ca (Michal Jaegermann) writes: John> : > John> : > Gerhard Brey (G.Brey@lrz.uni-muenchen.de) wrote: John> : > : In article <4fdi85$4b7o@yuma.ACNS.ColoState.EDU> millejoh@holly.ColoState.EDU (John Miller) writes: John> : > John> : > : > unidentified symbols in rswitch.o -- namely new_context and syserr. John> : > John> : > : I guess John> : > : (but I am not a C- or Assembler-programmer) that the problem has to do John> : > : with the Assembler code in rswitch.s. John> : > John> : > If the problem is caused by symbols from an assembler code then most John> : > likely it is a trivial one. Elf symbols do not have prepended '_' John> : > character; assembler likely assumes that they do. Just adjust names. John> : > John> : Thanks for the advice. I deleted the `_' in front of the symbol names John> : in rswitch.s. Now `iconx' is built but there is still the John> : bfd assertion fail /opt/release/pub/bin/binutils/bfd/elf32-i386.c:624 John> : and when I try to execute `iconx' it stops with a segmentation fault. John> : Gerhard John> I'm getting exactly the same results. I'll search around comp.os.linux.* John> and see what I can come up with. Wish me luck! I've submitted configuration information to the Icon project for getting Icon going with Linux ELF. The two main things to watch out for are the prepended _ in symbol names (for the assembly language routine in rswitch.s), and you *must* avoid the strength-reduce Gcc optimization bug by using the switch -fno-strength-reduce when you compile. The configuration I used is available at ftp://ftp.miranova.com/pub/icon.linux.elf.tar.gz Regards, -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. From icon-group-sender Fri Feb 16 16:25:36 1996 Received: by cheltenham.cs.arizona.edu; Fri, 16 Feb 1996 16:20:29 MST Date: Fri, 16 Feb 96 16:25:36 CST From: escargo@anubis.network.com (David S. Cargo) Message-Id: <9602162225.AA23371@anubis.network.com> To: icon-group@cs.arizona.edu Subject: procedure names Errors-To: icon-group-errors@cs.arizona.edu Status: O Is there any way for a program to find out the names of procedures that are in the program? I'm thinking about measuring test-coverage by determining if a procedure has been called or not. I'd like to use the preprocessor to either insert a prodecure name in a set or increment a counter in a table when a procedure is called. While this can mark when procedures are called, it can't tell when a procedure is not called. This would be something like tcl's "info procs" command. Examining the .u1, .u2, or .icx files might be acceptable, but I'd like a source-level solution. dsc From icon-group-sender Tue Feb 20 15:13:15 1996 Received: by cheltenham.cs.arizona.edu; Tue, 20 Feb 1996 17:50:39 MST Date: Tue, 20 Feb 1996 15:13:15 -0800 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <199602202313.PAA22713@varda.premenos.com> To: icon-group@cs.arizona.edu Subject: Re: procedure names Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: 23afWjlx3XjXsqNJ0X26qg== Errors-To: icon-group-errors@cs.arizona.edu Status: O You can determine procedure names by using the display() function to write information about variables to a file. You can then read the file back in and look for global variables with procedure values. String scanning makes it pretty easy to parse the file. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 > Date: Fri, 16 Feb 96 16:25:36 CST > From: escargo@anubis.network.com (David S. Cargo) > > Is there any way for a program to find out the names of procedures that > are in the program? I'm thinking about measuring test-coverage by > determining if a procedure has been called or not. I'd like to use the > preprocessor to either insert a prodecure name in a set or increment a > counter in a table when a procedure is called. While this can mark > when procedures are called, it can't tell when a procedure is not > called. This would be something like tcl's "info procs" command. > > Examining the .u1, .u2, or .icx files might be acceptable, but I'd > like a source-level solution. From icon-group-sender Wed Feb 21 10:00:00 1996 Received: by cheltenham.cs.arizona.edu; Wed, 21 Feb 1996 12:26:41 MST Message-Id: Date: Wed, 21 Feb 96 10:00 CST From: escargo@mirage.skypoint.com To: kwalker@orville.premenos.com (Ken Walker), icon-group@cs.arizona.edu Subject: Re: procedure names Content-Length: 200 Errors-To: icon-group-errors@cs.arizona.edu Status: O Thanks. Looking at the output of display I can see the information I want. It does seem kind of strange that display() writes directly instead of generating the output, but I can work with it. dsc From icon-group-sender Sat Feb 24 17:40:27 1996 Received: by cheltenham.cs.arizona.edu; Sat, 24 Feb 1996 18:42:00 MST To: icon-group@cs.arizona.edu Date: 24 Feb 1996 17:40:27 GMT From: aaab@acs.ryerson.ca (Al Aab - CNED/W94) Message-Id: <4gniib$dta@ns2.ryerson.ca> Organization: Ryerson Polytechnic University Sender: icon-group-request@cs.arizona.edu References: <41dvur$hvb@horus.infinet.com> Subject: Re: Icon as an editing tool Errors-To: icon-group-errors@cs.arizona.edu Status: O Bruce S. Tobin (btobin@infinet.com) wrote: : I'm looking for a better way to automate (or semi-automate) some heavy : C++ editing I'm going to have to do soon, making lots of similar changes to : lots of different files. Is this a good use for Icon, or would I be : better off with sed, awk, or emacs lisp? Thanks. emacs lisp might be the slowest of them all, awk , i do not know, sed was such a cryptic (beats APL) pain to someone, that he had to modify the DOS C source, to add a trace. if u know C well, it might b a good idea 2 try it. Look in the huge accumulated wealth of C libraries & shareware, first. C is the fastest thing after assembler. do u know icon or snobol ? From icon-group-sender Sun Feb 25 03:52:32 1996 Received: by cheltenham.cs.arizona.edu; Mon, 26 Feb 1996 12:11:36 MST To: icon-group@cs.arizona.edu Date: Sun, 25 Feb 1996 03:52:32 GMT From: rjp@heffer.demon.co.uk (Rob Partington) Message-Id: Sender: icon-group-request@cs.arizona.edu Subject: Icon replacement for a perl script? Errors-To: icon-group-errors@cs.arizona.edu Status: O Ok, I've got a perl script which takes a list of filenames, and processes each one to find out which filter to use on the file (depending on a regexp match on the filename). Then it processes each file in turn, with the appropriate filters (and some default ones that are always applied), to create two new ones (a local copy, and a remote one). Since this takes a while (~11 minutes for 1158 files), and a ridiculous amount of memory (it peaks at about 16M of swap :-), I was wondering if it might be easier/faster/more memory efficient to do this in icon? The most complicated replacement is &title;some text here => some text here All the others are simple text=>text replaces. Does anyone have any suggestions? Any help gratefully appreciated (especially by the drive my swap space is on :-) -- +X------------------------------------------------------------------------oO+ | Bob Partington - rjp@heffer.demon.co.uk - Linux'd and Acorn'd # | work - http://www.adxis.com/ - personal - http://www.adxis.com/staff/rjp/ ^ | This message may not reflect the opinions of Adxis v +<----##############################################################------->+ From icon-group-sender Tue Feb 27 10:33:51 1996 Received: by cheltenham.cs.arizona.edu; Tue, 27 Feb 1996 12:23:41 MST Date: Tue, 27 Feb 1996 10:33:51 -0600 Message-Id: <199602271633.KAA00683@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Icon replacement for a perl script? To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >...I've got a perl script which takes a list of filenames, and processes each one to find out which filter to use on the file (depending on a regexp match on the filename). Then it processes each file in turn, with the appropriate filters (and some default ones that are always applied), to create two new ones (a local copy, and a remote one). >Since this takes a while (~11 minutes for 1158 files), and a ridiculous amount of memory (it peaks at about 16M of swap :-), I was wondering if it might be easier/faster/more memory efficient to do this in icon? It is LUDICROUS to have to do that much swapping for a situation like this, where even Vanilla SNOBOL would comfortably do the same job in less than 100K of memory space, total. >The most complicated replacement is &title;some text here => some text here Clearly pretty trivial stuff. Either Icon or SNOBOL4 would be a better choice. PERL is really *only* interesting, IMHO, if you don't have access to anything better. >Does anyone have any suggestions? Any help gratefully appreciated (especially by the drive my swap space is on :-) Get yourself a copy of Icon, and/or SNOBOL4, and throw PERL away. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Tue Feb 27 22:05:14 1996 Received: by cheltenham.cs.arizona.edu; Wed, 28 Feb 1996 10:38:56 MST To: icon-group@cs.arizona.edu Date: 27 Feb 1996 22:05:14 GMT From: mustard@interlog.com (Bill Mustard) Message-Id: <4gvv6q$bbu@steel.interlog.com> Organization: InterLog Internet Services Sender: icon-group-request@cs.arizona.edu References: <41dvur$hvb@horus.infinet.com>, <4gniib$dta@ns2.ryerson.ca> Reply-To: mustard@interlog.com Subject: Re: Icon as an editing tool Errors-To: icon-group-errors@cs.arizona.edu Status: O In <4gniib$dta@ns2.ryerson.ca>, aaab@acs.ryerson.ca (Al Aab - CNED/W94) writes: >Bruce S. Tobin (btobin@infinet.com) wrote: >: I'm looking for a better way to automate (or semi-automate) some heavy >: C++ editing I'm going to have to do soon, making lots of similar changes to >: lots of different files. Is this a good use for Icon, or would I be >: better off with sed, awk, or emacs lisp? Thanks. > > >emacs lisp might be the slowest of them all, >awk , i do not know, FWIW awk will do the job nicely if your edits are mostly on one line at a time. If your input has many cases where you may have to scan multiple lines to determine your output, I wouldn't normally use it. perl is easier to debug and "more general", runs fairly quickly too. >sed was such a cryptic (beats APL) pain to someone, that he had to modify >the DOS C source, > to add a trace. >if u know C well, it might b a good idea 2 try it. Look in the huge >accumulated wealth of C libraries & shareware, first. >C is the fastest thing after assembler. > >do u know icon or snobol ? Either of these are appropriate tools. Another cryptic but powerful tool is M4, shipped with most *IX development suites. I personally would choose which ever I was most current on and get the job done. Probably perl or icon or awk. > From icon-group-sender Wed Feb 28 03:07:55 1996 Received: by cheltenham.cs.arizona.edu; Wed, 28 Feb 1996 10:39:15 MST To: icon-group@cs.arizona.edu Date: 28 Feb 1996 03:07:55 GMT From: "David A. Gamey" Message-Id: <4h0gub$pk4@nntp208.reach.com> Organization: Reach Networks Sender: icon-group-request@cs.arizona.edu References: <41dvur$hvb@horus.infinet.com>, <4gniib$dta@ns2.ryerson.ca> Subject: Re: Icon as an editing tool Errors-To: icon-group-errors@cs.arizona.edu Status: O aaab@acs.ryerson.ca (Al Aab - CNED/W94) wrote: >Bruce S. Tobin (btobin@infinet.com) wrote: >: I'm looking for a better way to automate (or semi-automate) some heavy >: C++ editing I'm going to have to do soon, making lots of similar changes to >: lots of different files. About two years ago, I worked on a project to rewrite about 3/4M lines of code into C using automated translation software. Because of many fundamental semantic differences between the two languages the translator made many unavoidable mistakes. I used Icon to to pre-process the source language and post-process the output of the translator among many other tasks. The code applied over 60 "rules". I ended up writing about 3000 lines of Icon including whitespace and comments. To do the same in C/C++ would probably have required 12000 to 17000 lines of code. Hope this helps. From icon-group-sender Wed Feb 28 10:19:42 1996 Received: by cheltenham.cs.arizona.edu; Wed, 28 Feb 1996 10:39:30 MST To: icon-group@cs.arizona.edu Date: 28 Feb 1996 10:19:42 GMT From: Gottfried Hogh Message-Id: <4h1a7u$hsm@fiesta.srl.ford.com> Organization: Ford Motor Co. Sender: icon-group-request@cs.arizona.edu Subject: Icon on Linux Errors-To: icon-group-errors@cs.arizona.edu Status: O I am new to this language and am looking for a pointer to any Linux port that might exits out on the net. If I can't find an operational port, does that mean I needs go to cs.arizona.edu for the generic Unix source? Gottfried Hogh, Ford Research, Dearborn, MI, USA From icon-group-sender Wed Feb 28 11:08:57 1996 Received: by cheltenham.cs.arizona.edu; Wed, 28 Feb 1996 11:09:10 MST Date: Wed, 28 Feb 1996 11:08:57 MST From: "Cliff Hathaway" Message-Id: <199602281808.AA16868@cheltenham.cs.arizona.edu> To: ghogh@hill01.srl.ford.com Subject: Re: Icon on Linux Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu Status: O The Univ. of Arizona FTP site (including the Icon distribution archives) have moved to a new machine, ftp.cs.arizona.edu. Previously, cs.arizona.edu and ftp.cs.arizona.edu were the same machine. There is a Linux binary distribution available at ftp.cs.arizona.edu:/icon/binaries/unix/linux-icon.tar.{Z,gz}. The README file in that directory says ========================================================================= README file for /icon/binaries/unix This directory contains executable binaries of version 9.1 of Icon in the form of "Unix Starter Kits" containing everything you need to get started with Icon. Each kit contains executables of the Icon translator and interpreter, the interface builder, documentation in PostScript form, and the library procedures referenced in the documentation. The Icon compiler, for specialized needs, is no longer included in binary packages. Each kit is available as a compressed (.Z) or gzipped (.gz) tar file. Kits are available for the following platforms: Digital Unix (OSF) 3.2 Hewlett-Packard HP-UX 9.01 IBM AIX 3.2 Linux 1.3.30 (Slackware 2.3.0) Silicon Graphics IRIX 5.2 Sun Solaris 2.3 Sun SunOS 4.1.1 Unpacking the tar file creates a directory named "icon.9.1". The README in that directory gives subsequent directions. All that's needed is to run a simple setup script and set some environment variables, and you'll be ready to run Icon programs. ========================================================================= > To: icon-group@cs.arizona.edu > Date: 28 Feb 1996 10:19:42 GMT > From: Gottfried Hogh > Subject: Icon on Linux > > I am new to this language and am looking for a pointer to any Linux > port that might exits out on the net. If I can't find an operational > port, does that mean I needs go to cs.arizona.edu for the generic Unix > source? > > Gottfried Hogh, Ford Research, Dearborn, MI, USA > > > From icon-group-sender Wed Feb 28 15:32:57 1996 Received: by cheltenham.cs.arizona.edu; Thu, 29 Feb 1996 13:14:51 MST To: icon-group@cs.arizona.edu Date: 28 Feb 1996 15:32:57 -0800 From: Steven L Baur Message-Id: Organization: Miranova Systems, Inc. Sender: icon-group-request@cs.arizona.edu References: <4h1a7u$hsm@fiesta.srl.ford.com> Subject: Re: Icon on Linux Errors-To: icon-group-errors@cs.arizona.edu Status: O >>>>> "Gottfried" == Gottfried Hogh writes: Gottfried> I am new to this language and am looking for a pointer to Gottfried> any Linux port that might exits out on the net. If I can't Gottfried> find an operational port, does that mean I needs go to Gottfried> cs.arizona.edu for the generic Unix source? The generic Unix source will work just fine. If you want a configuration for Linux ELF, I've made one available at ftp://ftp.miranova.com/pub/icon.linux.elf.tar.gz Load this into the source you get from arizona.edu. Regards, -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. From icon-group-sender Mon Mar 4 10:39:59 1996 Received: by cheltenham.cs.arizona.edu; Mon, 4 Mar 1996 12:20:29 MST To: icon-group@cs.arizona.edu Date: 4 Mar 1996 10:39:59 -0700 From: icon-project@cs.arizona.edu Message-Id: <4hf9tf$kne@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 Status: O Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language Last updated: February 16, 1996 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 UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and the Acorn Archimedes. There are older versions for the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, 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? 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, and runs on UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and Acorn Archimedes. Other implementations presently are at Version 8. Almost all programs that run under Version 8 and that do not use graphics will run under Version 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 support Icon's graphics facilities are in beta testing. 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), postal money order, or check drawn on a bank with a branch in the United States and made payable to The University of Arizona. Icon is available on CD-ROM from Prime Time Freeware (http://www.ptf.com/, 408-433-9662). Contact them for details. 11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, second edition, 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. 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 subscription 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, revenue from the sale of program material and documentation, and user contributions. 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 updated only 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 twice a year. There also is a subscription service for updates to the Icon program library, which provides new material about twice 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? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please 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. 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 Mon Mar 4 20:58:38 1996 Received: by cheltenham.cs.arizona.edu; Mon, 4 Mar 1996 16:21:13 MST From: "Hamish Lawson" Organization: University of Teesside (SCM) To: icon-group@cs.arizona.edu Date: Mon, 4 Mar 1996 20:58:38 GMT0BST Subject: Production of an operator's left-hand operand Reply-To: H.Lawson@tees.ac.uk Priority: normal X-Mailer: Pegasus Mail for Windows (v2.0-WB2) Message-Id: Errors-To: icon-group-errors@cs.arizona.edu Status: O I understand the logic behind having operators produce their right-hand operand, in order that we can do stuff like if x < y < z then However I frequently want to have the right-hand operand produced, e.g to print x only if it is greater than 5 I cannot say write(x > 5) but must instead say write(5 < x) Aside from the slight artificiality in such a construct this rearrangement may not work (and correct me if I'm wrong) if I want to do something like printing the value of e1 only if e2 succeeds; that is, I cannot necessarily rewrite this as write(e2 & e1) Want would be nice would be parallel operators that produce their left-hand operand; a possible notation would be to prefix the standard operator with a ^ (there may be better schemes, perhaps a suffix ~): write(e1 ^& e2) # produces e1 only if e2 succeeds Aside from the usual problems of getting a new feature adopted in a language, are their any other problems with such an idea? | 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 Tue Mar 5 09:00:00 1996 Received: by cheltenham.cs.arizona.edu; Tue, 5 Mar 1996 12:30:26 MST Message-Id: Date: Tue, 5 Mar 96 09:00 CST From: escargo@mirage To: H.Lawson@tees.ac.uk, icon-group@cs.arizona.edu Subject: Re: Production of an operator's left-hand operand Content-Length: 259 Errors-To: icon-group-errors@cs.arizona.edu Status: O I believe that if you use an expression like the following, you can get the results you want: write( 1(e1, e2)) This evaluates e1 and e2 in that order, succeeds only if both e1 and e2 succeeds, and returns the value of the first expression. David S. Cargo From icon-group-sender Tue Mar 5 08:45:59 1996 Received: by cheltenham.cs.arizona.edu; Tue, 5 Mar 1996 12:30:39 MST Date: Tue, 5 Mar 1996 08:45:59 -0800 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <199603051645.IAA13391@varda.premenos.com> To: icon-group@cs.arizona.edu Subject: Re: Production of an operator's left-hand operand Mime-Version: 1.0 Content-Type: multipart/mixed;boundary=19ee_282f-6c82_497f-5606_700c Errors-To: icon-group-errors@cs.arizona.edu Status: O --19ee_282f-6c82_497f-5606_700c Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: B/v5GdmdxStc1YwCt6/5hg== X-Sun-Data-Type: text > From: "Hamish Lawson" > Date: Mon, 4 Mar 1996 20:58:38 GMT0BST > > if I want to > do something like printing the value of e1 only if e2 succeeds; that > is, I cannot necessarily rewrite this as > > write(e2 & e1) In the particular case of '&', you can replace it with mutual evaluation and write write(1(e1, e2)) However, there is nothing similar you can do with comparisons. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 --19ee_282f-6c82_497f-5606_700c-- From icon-group-sender Wed Mar 6 15:09:39 1996 Received: by cheltenham.cs.arizona.edu; Wed, 6 Mar 1996 12:20:41 MST From: "Hamish Lawson" Organization: University of Teesside (SCM) To: icon-group@cs.arizona.edu Date: Wed, 6 Mar 1996 15:09:39 GMT0BST Subject: Re: Production of an operator's left-hand operand Reply-To: H.Lawson@tees.ac.uk Priority: normal X-Mailer: Pegasus Mail for Windows (v2.0-WB2) Message-Id: <1D200E66B9@scm_arkengarthdale.tees.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu Status: O I've been trying to make a case for a parallel set of operators that that produce their left-hand side. The example I chose was of printing the result of some expression only if a subsequent expression succeeds. It's been pointed out that this can be achieved thus: write(1(e1,e2)) It's my own fault for choosing a poor example. Ken Walker did concede that there is not an equivalent for comparison operators. Let's choose a better (I hope!) example: say I want to print out expression e1 only if its value is less than e2. The order of evaluation may be important and so write(e2 > e1) may not be possible. We're forced to the rather inelegant alternative write((e1 < (temp := e2), temp)) (The temp variable is necessary in the general case because a sceond evaluation of e2 may produce a new value.) Thus my proposal of an alternative set of operators that produce their RH operands (I suggested prefixing the standard operators with ^); our expression then becomes write(e1 ^< e2) | 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 Thu Mar 7 08:53:52 1996 Received: by cheltenham.cs.arizona.edu; Thu, 7 Mar 1996 13:07:36 MST To: icon-group@cs.arizona.edu Date: Thu, 07 Mar 1996 08:53:52 -0700 From: Steve Wampler Message-Id: <313F0690.6BBD@gemini.edu> Organization: Gemini 8m Telescopes Project Sender: icon-group-request@cs.arizona.edu Subject: 'right-handed' operators Errors-To: icon-group-errors@cs.arizona.edu Status: O I'm not I'd be in favor of adding any more operators to Icon, which has already taken more than its share. Why not just use the following for those (hopefully rare) cases where the right-hand side value is needed: rhsv("<",e1,e2) where rhsv is: procedure rhsv(op, l, r) return if op(l,r) then r end You could even eliminate the first argument if you wanted to write operator-specific versions: procedure rhlt(l,r) return if l Date: Fri, 08 Mar 1996 10:23:30 +0000 From: Ken Walker X-Mailer: Mozilla 2.0GoldB1 (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Re: 'right-handed' operators References: <313F0690.6BBD@gemini.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Steve Wampler wrote: > Why not just use the following for those (hopefully rare) > cases where the right-hand side value is needed: > > rhsv("<",e1,e2) > > where rhsv is: > > procedure rhsv(op, l, r) > return if op(l,r) then r > end I don't know if Steve actually meant the left-hand-side value, because it's the RHS that is normally produced by operators. However assuming that we have an equivalent lhsv procedure, then I would agree that write(e1 < lhsv("<",e2,e3)) is better than write(e1 < ((temp := e2) < e3, temp)) # help ma bob! but I still have a partiality for write(e1 < e2 ^< e3) One observation about the lhsv procedure: Because the second expression may not be susceptible to repeated evaluation (e.g. because it might read from a file), the code would have to be return if op(temp:=l,r) then temp While I wouldn't quite say that the RHS was required only rarely, nevertheless I think it's true that we need to have an operator produce its LHS just as often as the RHS. I would like the language to support that without requiring the rather inelegant workarounds currently necessary. | 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 Mar 11 10:48:22 1996 Received: by cheltenham.cs.arizona.edu; Mon, 11 Mar 1996 10:19:59 MST Message-Id: <199603111653.AA04270@optima.cs.arizona.edu> Date: Mon, 11 Mar 96 10:48:22 CST From: Roger Sorrells Subject: error 306 To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: O I am running icon8.10 on a 486 machine with 32megabytes of ram. The operating system is MS dos6.21. I got a run time error 306:inadequate space in string region. How do I allocate more space to the string region? Is there anything else I should check or change? From icon-group-sender Tue Mar 12 03:40:04 1996 Received: by cheltenham.cs.arizona.edu; Tue, 12 Mar 1996 07:17:12 MST To: icon-group@cs.arizona.edu Date: 12 Mar 1996 03:40:04 GMT From: collberg@cs.auckland.ac.nz (Christian Collberg) Message-Id: <4i2rmk$99b@net.auckland.ac.nz> Organization: University of Auckland Sender: icon-group-request@cs.arizona.edu Subject: Viewing lots of circles Errors-To: icon-group-errors@cs.arizona.edu Status: O I need to speed up a program that prints lots of black and white circles. I'm using WAttrib("fg=white", "fillstyle=solid") or WAttrib("fg=white", "fillstyle=solid") followed by FillCircle(c*20, l*20, 10) Is there a faster way? Thanks! Christian -- ___________________________________________________________________________ Christian Collberg | Email: c_collberg@cs.auckland.ac.nz Computer Science Dept | Fax: +64-9-373-7453 University of Auckland | Phone: +64-9-373-7599 x 6137 From icon-group-sender Tue Mar 12 09:28:24 1996 Received: by cheltenham.cs.arizona.edu; Tue, 12 Mar 1996 12:35:43 MST Date: Tue, 12 Mar 1996 09:28:24 -0600 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9603121528.AA18466@water.cs.utsa.edu> To: collberg@cs.auckland.ac.nz Cc: icon-group@cs.arizona.edu In-Reply-To: <4i2rmk$99b@net.auckland.ac.nz> (collberg@cs.auckland.ac.nz) Subject: Re: Viewing lots of circles Content-Length: 1247 Errors-To: icon-group-errors@cs.arizona.edu Status: O > From: collberg@cs.auckland.ac.nz (Christian Collberg) > I need to speed up a program that prints lots > of black and white circles. I'm using > WAttrib("fg=white", "fillstyle=solid") > followed by > FillCircle(c*20, l*20, 10) > > Is there a faster way? There are two options to speed this up, and both of them involve eliminating repeated calls to WAttrib(). Option A is to build a list L of all the white circles (a list of integers where each set of 3 integers represents a set of parameters for FillCircle, and then make a single call to WAttrib() to set the attribute, and then a single call using list invocation: FillCircle ! L Option B is deeper: using Clone() you can set up two or more separate Icon "window" values that both refer to the same window, but have different colors. Then you don't have to call WAttrib() to draw a circle in either color: white := Clone(&window, "fg=white", fillstyle=solid") black := Clone(&window, "fg=black", fillstyle=solid") every i := 1 to 10000 do { FillCircle(white, ...) FillCircle(black, ...) } Clint Jeffery jeffery@ringer.cs.utsa.edu Division of Computer Science The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Wed Apr 10 13:14:22 1996 Received: by cheltenham.cs.arizona.edu; Wed, 10 Apr 1996 12:36:29 MST To: icon-group@cs.arizona.edu Date: 10 Apr 1996 13:14:22 GMT From: espie@bireme.ens.fr (Marc Espie) Message-Id: <4kgc7e$li@nef.ens.fr> Organization: Ecole Normale Superieure, Paris Sender: icon-group-request@cs.arizona.edu References: , , Subject: Re: Coherent Spherical Modulator Errors-To: icon-group-errors@cs.arizona.edu Status: O In article , Andrew Shi-hwa Chen wrote: >But Perl does have some features that might be nice in Icon - like the << >construct and stuff like that. As far as nice Perl features that could be useful in Icon, there are lots of more interesting things. Packages come to mind, definitely. An object extension that would be part of the language would be great too. Idol looks nice, but the parser is somewhat primitive. -- [nosave] microsoft network is EXPLICITLY forbidden to redistribute this message. `Moon purismu powa, make up.... Tsuki ni kawatte, oshiokiyo !' Marc Espie (Marc.Espie@ens.fr) From icon-group-sender Wed Apr 10 08:14:53 1996 Received: by cheltenham.cs.arizona.edu; Wed, 10 Apr 1996 12:36:12 MST To: icon-group@cs.arizona.edu Date: 10 Apr 1996 08:14:53 -0500 From: seebs@solutions.solon.com (Peter Seebach) Message-Id: <4kgc8d$j7h@solutions.solon.com> Organization: Usenet Fact Police (Undercover) Sender: icon-group-request@cs.arizona.edu Reply-To: seebs@solon.com Subject: How to think about Icon? Errors-To: icon-group-errors@cs.arizona.edu Status: O I've made periodic stabs at learning icon for some time now, and I've come to the conclusion that it's completely unlike the languages I've learned previously. In particular, I have no good mental model for backtracking, so I get confused by programs which do it. This makes Icon hard for me to take advantage of. :) What kind of conceptual model do you use for programming in Icon? How do you use it differently from "simple" procedural languages, like C or Perl? -s -- Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach. C/Unix wizard -- C/Unix questions? Send mail for help. No, really! FUCK the communications decency act. Goddamned government. [literally.] The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html From icon-group-sender Wed Apr 10 13:44:12 1996 Received: by cheltenham.cs.arizona.edu; Wed, 10 Apr 1996 12:36:38 MST To: icon-group@cs.arizona.edu Date: 10 Apr 1996 13:44:12 GMT From: espie@bireme.ens.fr (Marc Espie) Message-Id: <4kgdvc$1v6@nef.ens.fr> Organization: Ecole Normale Superieure, Paris Sender: icon-group-request@cs.arizona.edu References: <4kgc8d$j7h@solutions.solon.com> Subject: Re: How to think about Icon? Errors-To: icon-group-errors@cs.arizona.edu Status: O In article <4kgc8d$j7h@solutions.solon.com>, Peter Seebach wrote: >I've made periodic stabs at learning icon for some time now, and I've >come to the conclusion that it's completely unlike the languages I've >learned previously. In particular, I have no good mental model for >backtracking, so I get confused by programs which do it. This makes Icon >hard for me to take advantage of. :) > >What kind of conceptual model do you use for programming in Icon? How >do you use it differently from "simple" procedural languages, like C >or Perl? > I don't know how it works for other people, but `iterator' is the key for me. The classical problem that is difficult to work in other languages is graph traversal. In C, you usually will code a given graph traversal algorithm that takes a call back function as a parameter---this call back will be called with each vertex you encounter. In Icon, you will design a generator that suspends every vertex you encounter. Up to the calling program to decide what to do with the vertex. This goes farther than it seems. For instance, I usually don't hardcode my definition of a graph, but use a generator that gives me the neighbors of a given neighbor instead. Sample Connected Component program (this is what I actually use in practice): procedure build_cc(v, neighors, para, cc) local todo todo := [v] /cc := set() # initialize set if needed insert(cc, v) # cc initially holds v while v := pop(todo) do every neighbor := neighbors(v, para) do member(cc, neighbor) | (insert(cc, neighbor) & put(todo, neighbor)) return cc end As far as backtracking goes, the sanest way is perhaps to just consider it as a kind of shorthand (at first): all the logical structure and all the C variables are there, you just don't have to write it down explicitly, i.e., going from every i:= 1 to 10 do write(i) to every write(1 to 10) or if (i = 0) | (i = 1) to if i = (0|1) isn't that difficult. Then you can go farther to recursive generators and such intricate stuff. This is the same conceptual leap as recursive invariants in functional languages. The only thing you have to watch for is the precise semantics of failure/multiple success... If I counted all the times I had a generator resume on me when I wasn't expecting it, reverse the first result, and finally fail---\1 is very handy at times, or all these procedural functions that forgot to return anything and just failed, simply ! Another fun example: this one generates all permutations of a given list, and is quite nice to understand generator resumption. procedure do_permute(l, i, n) if i >= n then return l else suspend l[i to n] <-> l[i] & do_permute(l, i+1, n) end procedure permute(l) suspend do_permute(l, 1, *l) end I should add that, again, this is a real life example. Icon code tends to be very compact, elegant, and not so easy to understand at times :-) If you haven't already, go out and buy the Icon programming language book, by Griswold. This is a very nice book, that gives lots of applications of the generator/backtracking paradigm. -- [nosave] microsoft network is EXPLICITLY forbidden to redistribute this message. `Moon purismu powa, make up.... Tsuki ni kawatte, oshiokiyo !' Marc Espie (Marc.Espie@ens.fr) From icon-group-sender Wed Apr 10 14:23:35 1996 Received: by cheltenham.cs.arizona.edu; Wed, 10 Apr 1996 16:20:25 MST Date: Wed, 10 Apr 1996 14:23:35 -0700 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <199604102123.OAA08553@varda.premenos.com> To: icon-group@cs.arizona.edu Subject: Re: How to think about Icon? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: JSmsXmNGzG1t3kCMAvGGZQ== Errors-To: icon-group-errors@cs.arizona.edu Status: O > From: seebs@solutions.solon.com (Peter Seebach) > Subject: How to think about Icon? > ... > What kind of conceptual model do you use for programming in Icon? How > do you use it differently from "simple" procedural languages, like C > or Perl? I find it is easiest if I don't try to embrace the full potential of generators and goal-directed evaluation all at once. The concept of a "result sequence" can be very helpful. It lets you think independently about all the potential results of a generator and how the results are used. The concept becomes a little muddied when data structures used to generate results change between results (for example, queens.icn in the Icon Program Library modifies the chess board used to test for moves as it is generating solutions), but in many cases the concept can be applied very cleanly. The concept of a result sequence helps you write generative procedures by allowing you to be concerned only with the sequence in which suspend expressions are executed and not be concerned with why the procedure is being resumed. On the other side of the coin, once you convince yourself that an expression produces the sequence of values you want, you can concentrate on how the sequence is used and forget about how it is produced. There are two basic paradigms for using generator: interation and goad-directed evaluation. In interation, you are using all the values of a generator. For example: every write(!a) writes all the values produced by !a. In goal-directed evaluation, you are looking for a value from a generator that meets a condition. For example, the expression write(s ? (tab(find("name:")) & tab(upto(';')))) locates the first position in s that contains "name:" and prints the string from there upto to the next ";", if there is one. Of course, things can get more complicated; you can also use this expression in interation to produce a sequence of results. The following program demonstrate's Marc Espie's warning about being careful when combining generators and resuming them. procedure main() local s s := "testing name:Jack; name:Jill;" every write(s ? (tab(find("name:")) & tab(upto(';')))) end I expected it to print two results and it printed three: name:Jack name:Jack; name:Jill name:Jill I need to limit tab(upto(';')) to one result if I want to print just the 1st and 3rd result. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Wed Apr 10 21:47:29 1996 Received: by cheltenham.CS.Arizona.EDU; Thu, 11 Apr 1996 07:55:56 MST Date: Wed, 10 Apr 1996 21:47:29 -0500 Message-Id: <199604110247.VAA10835@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: How to think about Icon? To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >I've made periodic stabs at learning icon for some time now, and I've come to the conclusion that it's completely unlike the languages I've learned previously. To say the very least!!! You certainly CAN program Pascal-like techniques in Icon, but it wastes Icon's wonderful talents. I think the main thing is to START USING Icon, using whatever algorithms you want, just to get your feet wet. After you're comfortable with it on a fairly "conventional" programming style, then I think it makes sense to start looking at other example programs and try to advance your paradigms to use the new concepts that Icon makes possible. In the case of SNOBOL4, an excellent resource is "Algorithms in SNOBOL4" by Gimpel, which helps demonstrate just some of the ways that SNOBOL4's marvelous collection of unusual features can be actually employed when writing applications. It helps you develop a "SNOBOL4 programming mentality", and build the reflexes for ways to attack problems using the language. >In particular, I have no good mental model for backtracking, so I get confused by programs which do it. This makes Icon hard for me to take advantage of. :) Sure... rather like pointers, linked data structures in general, and recursion... some things you just have to wrap your mind around, and it's not always trivial to do that in the beginning. Once you have more experience in attacking real-world problems with a given language, you tend to become more convinced about the applicability of these more advanced programming techniques... it's a good motivator. :-) Does this help? Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Apr 11 10:41:58 1996 Received: by cheltenham.CS.Arizona.EDU; Thu, 11 Apr 1996 12:20:20 MST Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 11 Apr 1996 10:41:58 -0600 From: Charlie Hethcoat To: seebs@solutions.solon.com Cc: icon-group@cs.arizona.edu Subject: Re: How to thing about Icon? Errors-To: icon-group-errors@cs.arizona.edu Status: O I'm still learning how to use Icon myself, but I found in the beginning that the only way for me to get comfortable with iterators, backtracking, etc. was to start really simple. I snagged some code from the Icon library that was supposed to do what I wanted to try, more or less. Even though I couldn't understand it so well at first, it did perform as advertised! This gave me a safe way to try little permutations to the code, one at a time, to study the effects. Gradually, I started adding stuff--little five- or ten-line routines--to modify some aspects of the program. The next thing I knew, I had a 200+line Icon program that did some pretty nice, if basic, graph traversal stuff with reasonably pretty text output. I did make use of Icon's features, but I still don't know if I took the best approach on everything I did. Oh yeah--with all the talk about graphical additions to Icon, I haven't yet been able to try it out. That is primarily because I have not had an X platform to use, but even if I had, I might have just been confused by the X Window display stuff on top of the unusual aspects of Icon's semantics. I intend to get to the graphics pretty soon, now that a Windows version is available. But for learning the language itself, stick to text. Another area that is hard for me to see is how to choose the best from among the multiplicity of ways to construct a given data structure. The builtin data structures are for me the most attractive part of Icon. They are just the right balance between rocket science and brain-dead. But sometimes it is hard to decide what is the best way to build what you want. I have gotten to where, if in doubt, I try a list first. Yours, Charles L. Hethcoat III | Where do people Senior Engineer | get all the Oceaneering Space Systems | cute little 16665 Space Center Blvd. | sayings they Houston, Texas 77058 USA | put in this (713) 488-9080 x 3470 | leftover space? The opinions expressed herein are mine and are not necessarily shared by my employer. From icon-group-sender Thu Apr 11 18:55:20 1996 Received: by cheltenham.cs.arizona.edu; Fri, 12 Apr 1996 08:02:38 MST Date: Thu, 11 Apr 1996 18:55:20 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9604112355.AA11976@boar.cs.utsa.edu> To: espie@bireme.ens.fr Cc: icon-group@cs.arizona.edu In-Reply-To: <4kgc7e$li@nef.ens.fr> (espie@bireme.ens.fr) Subject: Re: An object extension...as part of Icon... Content-Length: 1005 Errors-To: icon-group-errors@cs.arizona.edu Status: O > An object extension that would be part of the language would be great > too. Idol looks nice, but the parser is somewhat primitive. Why thank you... The current version of Idol is version 9.06. The parser is written in an object-oriented style rather than using a traditional yacc(1) grammar. And yes, it is still somewhat primitive. :-) Actually, Idol has evolved somewhat, and every time I improve it I'm glad its written in Idol and not C. For example, it took at hour or so to add scope checking so that with a method, references to member variables and functions no longer need to refer to "self". In C it will take...longer to figure it out. But yes, as soon as I find the right person to do it, I intend to integrate Idol features into Icon. I had a student who got most of the way, but abandoned it before it was usable. Clint Jeffery jeffery@ringer.cs.utsa.edu Division of Computer Science The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Fri Apr 12 22:16:06 1996 Received: by cheltenham.cs.arizona.edu; Sat, 13 Apr 1996 07:14:34 MST To: icon-group@cs.arizona.edu Date: 12 Apr 1996 22:16:06 -0600 From: kjs@thelair.zynet.com (Kragen Javier Sittler aka xentrac) Message-Id: <4kn9q6$72e@thelair.zynet.com> Organization: Zynet Southwest Sender: icon-group-request@cs.arizona.edu Subject: Icon without icons Errors-To: icon-group-errors@cs.arizona.edu Status: O I read the old Icon book; it impressed the heck out of me. I read the FAQ. It was very interesting. But I still wasn't quite interested enough in Icon to grab it and (I assumed) compile it. More recently, I started using noweb. Noweb has a bad version written in awk and a good version written in Icon. This is very sensible. It is also sensible that if you want to actually *use* noweb, you should get Icon instead of suffering under awk. I read the FAQ again. I studied the FTP site. I found binaries. I downloaded binaries. I ran Setup. A little later, I tried to run one of the (non-graphics) demo programs. (I think that's what I tried to run; I may have just been checking to see if iconx worked.) That's when I found out that Icon wanted libXpm to run. This is quite reasonable if you're on a system with graphics. But, you see, zynet is hundreds of miles away from my home, and I doubt I will ever run an X client from there again. I just want Icon for text processing, something it's phenomenally good at. But it won't run without Xpm. I read the FAQ again. Apparently, I'm the first person ever to have this problem. Am I on my own? Need I sort through the source to figure out how to compile an Icon without icons or buttons? Or is there someone else out there who has done the same thing as I? I'm *capable* of sorting through source, but it's really something I'd prefer not to have to do. I expect it will take a few hours, with my poor code-reading skills. (I often get lost reading others' code; I have a hard time understanding the grand scheme of things. Maybe this has to do with the poor quality of the code I've been reading, though.) I'd expect this to be a FAQ. But the newsgroup doesn't get much traffic. Maybe I should join the mailing list. But geez, I don't even expect to write any Icon code! I just want to USE the sucker. Alas. -- Peace Kragen From icon-group-sender Sat Apr 13 13:54:37 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 06:58:52 MST Message-Id: <199604131959.NAA33816@huey.cadvision.com> Date: Sat, 13 Apr 96 13:54:37 EDT From: midtoad@cadvision.com (Stewart Midwinter) Reply-To: midtoad@cadvision.com (Stewart Midwinter) To: icon-group@cs.arizona.edu Cc: kjs@thelair.zynet.com X-Mailer: Stewart Midwinter's PMMail v1.1 Subject: Re: Icon without icons Errors-To: icon-group-errors@cs.arizona.edu Status: O On 12 Apr 1996 22:16:06 -0600 you wrote: > I just want Icon for text >processing, something it's phenomenally good at. >But it won't run without Xpm. > >I read the FAQ again. Apparently, I'm the first person ever to have >this problem. > >Am I on my own? Need I sort through the source to figure out how to >compile an Icon without icons or buttons? Or is there someone else >out there who has done the same thing as I? > >I'm *capable* of sorting through source, but it's really something I'd >prefer not to have to do. I expect it will take a few hours, with my >poor code-reading skills. (I often get lost reading others' code; I >have a hard time understanding the grand scheme of things. Maybe this >has to do with the poor quality of the code I've been reading, >though.) > >I'd expect this to be a FAQ. But the newsgroup doesn't get much >traffic. Maybe I should join the mailing list. > >But geez, I don't even expect to write any Icon code! I just want to >USE the sucker. > >Alas. >-- >Peace >Kragen > > Kragen: Maybe even a beginner like I can help you out. You didn't mention what platform or OS you're wanting to install Icon on, but at least in the DOS/OS2/Windows world you don't need XPM to run Icon. Heck, I don't even know what it is! Also, I didn't have to compile anything in order to get Icon to run. I just downloaded the executables (go to ftp://ftp.cs.arizona.edu/icon/packages/msdos, and get de.lzh, or the 386 version, de386.lzh), the library (from /icon/library/bipl.lzh and ..info.lzh), installed them and away we went ... in 1st gear, full low. Now, once you have all installed, you can run ucode.bat to convert all your procedures to u_code, bat that's not the same as compiling... More questions? Let me know. Cheers, ----------------- Stewart Midwinter running under OS/2 Warp and PMMail. From icon-group-sender Sun Apr 14 13:02:51 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 06:59:52 MST Date: Sun, 14 Apr 1996 13:02:51 -0600 (MDT) From: Kragen Javier Sittler aka xentrac To: Stewart Midwinter , gep2@computek.net, eka@corp.cirrus.com, icon-group@cs.arizona.edu Subject: Re: Icon without icons In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O On Sat, 13 Apr 1996, Kragen Javier Sittler aka xentrac wrote: > Ooops :). I am trying to get it to run under some kind of UNIX; Linux > is what I have in mind. I downloaded the Linux executables, and they > require graphics functionality to run. Well, I feel a little silly. Once I downloaded the source, it compiled out of the box, and it was easy not to enable graphics capability. Thank all of you for your helpful information. I haven't seen such immediate helpfulness on Usenet for a long time! Peace Kragen From icon-group-sender Sat Apr 13 14:30:47 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 07:00:15 MST Date: Sat, 13 Apr 1996 14:30:47 -0600 (MDT) From: Kragen Javier Sittler aka xentrac To: Stewart Midwinter , gep2@computek.net, eka@corp.cirrus.com Cc: icon-group@cs.arizona.edu Subject: Re: Icon without icons In-Reply-To: <199604131959.NAA33816@huey.cadvision.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O On Sat, 13 Apr 1996, Stewart Midwinter wrote: > Maybe even a beginner like I can help you out. You didn't mention > what platform or OS you're wanting to install Icon on, but at least in > the DOS/OS2/Windows world you don't need XPM to run Icon. Heck, I > don't even know what it is! Ooops :). I am trying to get it to run under some kind of UNIX; Linux is what I have in mind. I downloaded the Linux executables, and they require graphics functionality to run. I don't know what the DOS version does; I know the Windows/OS/2 versions don't have a problem with this, since if Windows or OS/2 is present, then graphics functionality is also present. It's running Icon on an OS where graphics is not a part of the OS which presents a problem. Someone suggested that I should get Icon version 8 for UNIX. I don't know where I should look for version 8; it's not on the FTP site. I think that maybe the Griswolds have decided that nearly everyone has graphics capacity, and there's no point in cluttering the FTP site with things that nearly no one will use. They do include non-graphic versions of Icon for some other platforms, though, where presumably anyone using such a platforms will not have graphics. MVS, for example. :) They're probably right. I just wish I wasn't nearly no one. :) I'm receiving my third helpful message now... let's see what it says. Oh, it says the DOS/Windows versions run fine without graphics. :) Peace Kragen From icon-group-sender Mon Apr 15 01:29:15 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 07:00:34 MST Date: 15 Apr 96 09:27:09 BST From: R J Hare Subject: random numbers... To: icon-group@cs.arizona.edu Reply-To: rjhare@ed.ac.uk Organisation: Edinburgh University Computing Services Message-Id: <9604150927.ab22893@uk.ac.ed.tattoo> Errors-To: icon-group-errors@cs.arizona.edu Status: O I'm writing a graphics program which requires that I perturb my x and y values randomly by -1|0|1 before plotting the object at the new x and y. There seem to be 2 obvious ways of doing this: x := x-2+?3 y := y-2+?3 or: x := x+?[-1,0,1] y := y+?[-1,0,1] Which is 'best' (quicker, easier to read, etc.)? Opinions please... Thanks Roger Hare. From icon-group-sender Mon Apr 15 15:14:48 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 12:26:50 MST Message-Id: <317259D8.4A6B@tees.ac.uk> Date: Mon, 15 Apr 1996 15:14:48 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Cc: Making@tees.ac.uk, a@tees.ac.uk, list@tees.ac.uk, out@tees.ac.uk, of@tees.ac.uk, a@tees.ac.uk, generated@tees.ac.uk, sequence@tees.ac.uk Subject: Assigning References: <9604112355.AA11976@boar.cs.utsa.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Is there an easy way to make a list out of a generated sequence? I tried enclosing the generator sequence in square brackets, as below, but it doesn't appear to work. every write(sort([!"string"])) Am I obliged to write a loop that appends each item of the generated sequence to a list?: tempList := list() every tempList |||:= [!"string"] every write(!sort(tempList)) If so, it would seem to me to be a curious lack of symmetry that the language provides the ! operator to generate elements of a list, but no corresponding convenient mechanism for collecting into a list a generated sequence of values. | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Mon Apr 15 15:44:01 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 12:26:58 MST Message-Id: <317260B1.7F93@tees.ac.uk> Date: Mon, 15 Apr 1996 15:44:01 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Making a list out of a generated sequence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Is there an easy way to make a list out of a generated sequence? I tried enclosing the generator sequence in square brackets, as below, but it doesn't appear to work. every write(sort([!"string"])) Am I obliged to write a loop that appends each item of the generated sequence to a list?: tempList := list() every tempList |||:= [!"string"] every write(!sort(tempList)) If so, it would seem to me to be a curious lack of symmetry that the language provides the ! operator to generate elements of a list, but no corresponding convenient mechanism for collecting into a list a generated sequence of values. | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Mon Apr 15 09:14:19 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 12:27:19 MST Date: Mon, 15 Apr 1996 09:14:19 -0700 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <199604151614.JAA23070@varda.premenos.com> To: icon-group@cs.arizona.edu Subject: Re: random numbers... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: LpZpYRJRiHqugYwp9aw+jg== Errors-To: icon-group-errors@cs.arizona.edu Status: O > Date: 15 Apr 96 09:27:09 BST > From: R J Hare > > I'm writing a graphics program which requires that I perturb my x and > y values randomly by -1|0|1 before plotting the object at the new x and y. > There seem to be 2 obvious ways of doing this: > > x := x-2+?3 > y := y-2+?3 > > or: > > x := x+?[-1,0,1] > y := y+?[-1,0,1] > > Which is 'best' (quicker, easier to read, etc.)? I find the second easiest to read, but it has the disadvantage of constructing lists every time it is executed. If you are interested in effeciency, you might want to precompute the perturbations: procedure foo() static perturbations initial perturbations := [-1, 0, 1] ... x := x + ?perturbations y := y + ?perturbations ... end Even with this modification, it is likely to run a little slower than the first method, but the difference may not be significant for your application. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Mon Apr 15 09:51:34 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 12:27:30 MST Message-Id: <9604151650.AA26404@odin.ucsd.edu> To: rjhare@ed.ac.uk Cc: icon-group@cs.arizona.edu Subject: Re: random numbers... In-Reply-To: Your message of "15 Apr 1996 09:27:09 -0000." <9604150927.ab22893@uk.ac.ed.tattoo> Date: Mon, 15 Apr 1996 09:51:34 -0700 From: William Griswold Errors-To: icon-group-errors@cs.arizona.edu Status: O Boy, I really like the latter one: x := x+?[-1,0,1] However, you could more easily build a reusable abstraction using your first example, if it is really a range: x := x + chooseInRange(-1, 1) procedure chooseInRange(low, high) return ?(abs(high-low+1)) + (low-1) end --bill From icon-group-sender Mon Apr 15 22:23:35 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 12:27:40 MST Date: Mon, 15 Apr 1996 22:23:35 +0300 (WET) From: Ehud Lamm To: rjhare@ed.ac.uk Cc: icon-group@cs.arizona.edu Subject: Re: random numbers... In-Reply-To: <9604150927.ab22893@uk.ac.ed.tattoo> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O On 15 Apr 1996, R J Hare wrote: > I'm writing a graphics program which requires that I perturb my x and > y values randomly by -1|0|1 before plotting the object at the new x and y. > There seem to be 2 obvious ways of doing this: > > x := x-2+?3 > y := y-2+?3 > > or: > > x := x+?[-1,0,1] > y := y+?[-1,0,1] > The second option is clearly easier to read... This is a good example of the powerful semantics of Icon compared to regualr languages that would make you use the first solution. Soory I can not comment about speed, but of hand it seems the elegent solution is the slower one... :-) Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Mon Apr 15 22:27:25 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 12:27:51 MST Date: Mon, 15 Apr 1996 22:27:25 +0300 (WET) From: Ehud Lamm To: icon-group@cs.arizona.edu Subject: Icon for MVS In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O The graphics thread reminded me of this. Does anyone around here use it??? How good is the port? How FAST is it? (can I use it for big files..?) And last if not least: Can I download it, or do I still have to order a tape? Thanks for any info. Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Mon Apr 15 13:14:58 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 16:55:14 MST Date: Mon, 15 Apr 1996 13:14:58 MST From: "Cliff Hathaway" Message-Id: <199604152014.AA16655@cheltenham.cs.arizona.edu> To: icon-group@cs.arizona.edu, mslamm@pluto.mscc.huji.ac.il Subject: Re: Icon for MVS Errors-To: icon-group-errors@cs.arizona.edu Status: O Apparently you'll need to order the tape. We tried putting the tapeimage in our ftp site, and an intrepid MVS person downloaded it, and tried to do the installation from that. After wrestling with it, he ordered the tape. > To: icon-group@cs.arizona.edu > Subject: Icon for MVS > > The graphics thread reminded me of this. > > Does anyone around here use it??? > > How good is the port? How FAST is it? (can I use it for big files..?) > > And last if not least: Can I download it, or do I still have to order a tape? > > Thanks for any info. > > Ehud Lamm mslamm@pluto.mscc.huji.ac.il > > From icon-group-sender Mon Apr 15 13:44:56 1996 Received: by cheltenham.cs.arizona.edu; Mon, 15 Apr 1996 16:55:26 MST Date: Mon, 15 Apr 1996 13:44:56 -0700 From: swampler@noao.edu Subject: Re: Making a list out of a generated sequence To: H.Lawson@tees.ac.uk Cc: icon-group@cs.arizona.edu Message-Id: In-Reply-To: <317260B1.7F93@tees.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu Status: O Hamish Lawson wrote: > Is there an easy way to make a list out of a generated sequence? I tried > enclosing the generator sequence in square brackets, as below, but it > doesn't appear to work. > > every write(sort([!"string"])) > > Am I obliged to write a loop that appends each item of the generated > sequence to a list?: > > tempList := list() > every tempList |||:= [!"string"] > every write(!sort(tempList)) Yes, you must do something like this, though I'd use the put() function instead of list concatenation; you're building lots of temporary lists that aren't needed. If you're into conciseness, you can do it as: every tempList := put([], !"string") > If so, it would seem to me to be a curious lack of symmetry that the > language provides the ! operator to generate elements of a list, but no > corresponding convenient mechanism for collecting into a list a > generated sequence of values. Well, that's partly because of the nature of goal-directed evaluation. It sounds as though you'd like an operator that incorporates the functionality of the "every" expression. I find the expression put([], expression) sufficient for most such uses, and have only ever used it inside an every expression. If you're fairly new to Icon, however, it might take some time to work out why this works (but when you do, you'll understand a little more about goal-directed evaluation!). If you're not into conciseness, use: TempList := list() # or TempList := [] every put(TempList, !"string) instead. -- 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 Wed Apr 17 17:36:13 1996 Received: by cheltenham.cs.arizona.edu; Wed, 17 Apr 1996 12:46:26 MST Message-Id: <31751DFD.302F@tees.ac.uk> Date: Wed, 17 Apr 1996 17:36:13 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Splitting and joining strings References: <317260B1.7F93@tees.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Before I rolled my own I thought I'd have a look in the Icon Program Library for a couple of procedures I need. The first should split a string on a specified separator, along the lines of split("Joe:Sue:Bob:Ann", ":") produces "Joe", "Sue", "Bob", "Ann" The second should join the elements of a list into a string, with each element separated by a specified separator, along the lines of: join(["Joe", "Sue", "Bob", "Ann"], ":") produces "Joe:Sue:Bob:Ann" I couldn't find any such procedures in the IPL. Have I missed them? | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Wed Apr 17 16:19:37 1996 Received: by cheltenham.cs.arizona.edu; Wed, 17 Apr 1996 17:19:38 MST Date: Wed, 17 Apr 1996 16:19:37 -0500 Message-Id: <199604172119.QAA18647@post.its.mcw.edu> X-Sender: cdt@post.its.mcw.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Hamish Lawson From: cdt@post.its.mcw.edu (Chris D. Tenaglia) Subject: Re: Splitting and joining strings Cc: icon-group@cs.arizona.edu X-Mailer: Errors-To: icon-group-errors@cs.arizona.edu Status: O I have a routine called "parse" I thought was in the IPL. It looks something like: # # parse a string into a list with respect to a delimiter # procedure parse(line,delims) static chars chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end The delimiter is a cset in this case allowing a little more tokenizing flexibility. The join thing can be done in one or two expressions like: text := "" every text ||:= !items || ":" If you don't mind the trailing delimiter. Chris. >Before I rolled my own I thought I'd have a look in the Icon Program Library for a >couple of procedures I need. > >The first should split a string on a specified separator, along the lines of > > split("Joe:Sue:Bob:Ann", ":") produces "Joe", "Sue", "Bob", "Ann" > >The second should join the elements of a list into a string, with each element >separated by a specified separator, along the lines of: > > join(["Joe", "Sue", "Bob", "Ann"], ":") produces "Joe:Sue:Bob:Ann" > >I couldn't find any such procedures in the IPL. Have I missed them? > > >| Hamish Lawson, School of Computing and Mathematics, >| University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA >| Tel: +44 1642 212695 Fax: +44 1642 342604 >| E-mail: H.Lawson@tees.ac.uk > > 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 Wed Apr 17 13:29:42 1996 Received: by cheltenham.cs.arizona.edu; Wed, 17 Apr 1996 17:19:14 MST Date: Wed, 17 Apr 1996 13:29:42 -0700 From: "William H. Mitchell" Message-Id: <199604172029.NAA23296@baskerville.CS.Arizona.EDU> To: H.Lawson@tees.ac.uk Subject: Re: Splitting and joining strings Cc: icon-group@cs.arizona.edu Content-Length: 1858 Errors-To: icon-group-errors@cs.arizona.edu Status: O From icon-group-sender Wed Apr 17 12:48 MST 1996 Date: Wed, 17 Apr 1996 17:36:13 +0100 From: Hamish Lawson Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Splitting and joining strings Content-Transfer-Encoding: 7bit Before I rolled my own I thought I'd have a look in the Icon Program Library for a couple of procedures I need. The first should split a string on a specified separator, along the lines of split("Joe:Sue:Bob:Ann", ":") produces "Joe", "Sue", "Bob", "Ann" The second should join the elements of a list into a string, with each element separated by a specified separator, along the lines of: join(["Joe", "Sue", "Bob", "Ann"], ":") produces "Joe:Sue:Bob:Ann" I couldn't find any such procedures in the IPL. Have I missed them? Here are two routines that I've got: split and atos (aggregate to string). # # split(s, delimiters, keepall) splits the string s into consecutive substrings # that do/do not consist of characters in the cset delimiters, producing a # list of strings. If keepall is null, strings consisting delimiters are not # included in the result list. # # If not specified, delimeters defaults to blank and tab, which essentially # "tokenizes" non-whitespace: # # words := split(read()) # procedure split(s, dlms, keepall) local w, ws, addproc, nullproc ws := [] /dlms := " \t" addproc := put if \keepall then otherproc := put else otherproc := 1 if dlms := (any(dlms, s[1]) & ~dlms) then otherproc :=: addproc s ? while w := tab(many(dlms := ~dlms)) do { addproc(ws, w) otherproc :=: addproc } return ws end procedure atos(a, delim) local e, s /delim := "," every e := !a do (/s := e) | (s ||:= delim || e) return s end From icon-group-sender Wed Apr 17 13:49:11 1996 Received: by cheltenham.cs.arizona.edu; Wed, 17 Apr 1996 17:19:29 MST Date: Wed, 17 Apr 1996 13:49:11 -0700 Message-Id: <199604172049.NAA10393@dfw-ix3.ix.netcom.com> X-Sender: bobalex@ix.netcom.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: swampler@noao.edu, icon-group@cs.arizona.edu From: Bob Alexander Subject: Re: Making a list out of a generated sequence Errors-To: icon-group-errors@cs.arizona.edu Status: O > every tempList := put([], !"string") That is a VERY COOL Icon idiom -- wish I'd thought of it! It consumes a bit of time though, so for cases where that is bad the old-fashioned way is better. I did some trivial timings of every x := put([],1 to 500000) vs. x := []; every put(x,1 to 500000) and came out with about 7.5 vs. 5.7 sec -- apparently the cost of doing 1/2M assignments. Not that I'm likely to actually *notice* that in a real program... -- Bob From icon-group-sender Thu Apr 18 22:55:51 1996 Received: by cheltenham.cs.arizona.edu; Fri, 19 Apr 1996 08:28:53 MST To: icon-group@cs.arizona.edu Date: Thu, 18 Apr 1996 22:55:51 GMT From: bezeau@jupiter.sun.csd.unb.ca (Larry Bezeau) Message-Id: Organization: New Brunswick Centre for Educational Administration Sender: icon-group-request@cs.arizona.edu Subject: Icon in the MVS batch Errors-To: icon-group-errors@cs.arizona.edu Status: O Can anyone with experience using Icon under MVS in batch suggest how one passes ddnames to Icon? I tried opening files using the ddnames but that did not seem to work. Larry Bezeau@UNB.Ca From icon-group-sender Fri Apr 19 18:44:22 1996 Received: by cheltenham.cs.arizona.edu; Fri, 19 Apr 1996 12:23:22 MST Date: Fri, 19 Apr 1996 18:44:22 +0300 (WET) From: Ehud Lamm To: Larry Bezeau Cc: icon-group@cs.arizona.edu Subject: Re: Icon in the MVS batch In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O I still don't have Icon for MVS installed so I can't answer your question. However it seems to me that Icon for MVS is practically not used anywhere. So for the chance of being able to help each other, can any of you who works, or worked with Icon for MVS raise your hand?! I am sure I am going to have more problems, so knowing who can help, can be a big step forward. Bye, Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Fri Apr 19 13:53:43 1996 Received: by cheltenham.cs.arizona.edu; Fri, 19 Apr 1996 19:14:12 MST Date: Fri, 19 Apr 1996 13:53:43 -0700 Message-Id: <199604192053.NAA06439@dfw-ix2.ix.netcom.com> X-Sender: bobalex@ix.netcom.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: Bob Alexander Subject: Re: Making a list out of a generated sequence Errors-To: icon-group-errors@cs.arizona.edu Status: O Since I sent out the following: >> every tempList := put([], !"string") > >That is a VERY COOL Icon idiom -- wish I'd thought of it! > >It consumes a bit of time though, so for cases where that is bad the old-fashioned way is better. I did some trivial timings of > > every x := put([],1 to 500000) (1) > > vs. > > x := []; every put(x,1 to 500000) (2) > >and came out with about 7.5 vs. 5.7 sec -- apparently the cost of doing 1/2M >assignments. ...I received this refinement independently from two separate Icon wizards who reside in different states: every put(x := [],1 to 500000) (3) It runs just as fast as (2), has the terseness if (1), and is maybe even a bit easier to comprehend than (1). Thanks Steve and Clint -- this one's going into my permanent idiom collection. -- Bob From icon-group-sender Mon Apr 22 19:17:47 1996 Received: by cheltenham.cs.arizona.edu; Mon, 22 Apr 1996 17:08:50 MST Message-Id: <317BCD4B.3C65@tees.ac.uk> Date: Mon, 22 Apr 1996 19:17:47 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Why isn't Icon more widely used? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Why doesn't the rest of the world share my fondness for Icon? I don't mean, why are they still using Fortran, Cobol, and C; but even in Icon's niche of text processing I don't seem to come across programs written in Icon. I've come across a LaTeX to HTML convertor, various BiBTeX tools, and several CGI scripts written in Perl, but I've never come across any Icon programs outside of Icon circles - and even in Icon circles, many of these programs don't seem to have been produced. Why this unfortunate state of affairs? | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Mon Apr 22 10:05:05 1996 Received: by cheltenham.cs.arizona.edu; Mon, 22 Apr 1996 17:08:38 MST Date: Mon, 22 Apr 1996 10:05:05 -0700 From: Ralph Griswold Message-Id: <9604221705.AA25670@ursus.cs.arizona.edu> To: icon-group Subject: Icon update Errors-To: icon-group-errors@cs.arizona.edu Status: O Icon Newsletter 49 now is available on the Web. From our home page http://www.cs.arizona.edu/icon/ under Documentation, link to The Icon Newsletter and then to Icon Newsletter 49. Version 9.2 of the Icon Program Library is now available also. We have added several features to our Web site, including indexes to Icon Program Library material and on-line technical reports. You can get to these from our home page or Newsletter 49. We've also added a status report that lists the current state of things related to Icon. Link to Status Report at the beginning of our home page. 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 Mon Apr 22 20:37:23 1996 Received: by cheltenham.cs.arizona.edu; Tue, 23 Apr 1996 08:20:57 MST Date: Mon, 22 Apr 1996 20:37:23 -0500 Message-Id: <199604230137.UAA23142@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Re: Why isn't Icon more widely used? To: Hamish Lawson Cc: icon-group@cs.arizona.edu In-Reply-To: <317BCD4B.3C65@tees.ac.uk> X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O The really good question is why Perl is so widely used in Web CGI scripts, where ICON could probably do the job a great deal better! This is a major new area IMHO where ICON could make a big impact, if it could be better known. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Tue Apr 23 12:40:47 1996 Received: by cheltenham.cs.arizona.edu; Tue, 23 Apr 1996 13:18:28 MST Date: Tue, 23 Apr 96 12:40:47 pst From: cshuster@ccmail.com Encoding: 24 Text Message-Id: <9603238302.AA830288652@smtpgate.ccmail.com> To: icon-group@cs.arizona.edu Subject: Re[2]: Why isn't Icon more widely used? Errors-To: icon-group-errors@cs.arizona.edu Status: O My thoughts exactly! An implementation of html parsing done in Icon would be a compelling example to Perl. Do any already exist? --Cy-- ______________________________ Reply Separator _________________________________ Subject: Re: Why isn't Icon more widely used? Author: gep2@computek.net at internet-mail Date: 4/23/96 8:32 AM The really good question is why Perl is so widely used in Web CGI scripts, where ICON could probably do the job a great deal better! This is a major new area IMHO where ICON could make a big impact, if it could be better known. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Tue Apr 23 18:34:44 1996 Received: by cheltenham.cs.arizona.edu; Tue, 23 Apr 1996 13:18:15 MST Date: Tue, 23 Apr 1996 18:34:44 +0300 (WET) From: Ehud Lamm To: gep2@computek.net Cc: Hamish Lawson , icon-group@cs.arizona.edu Subject: Re: Why isn't Icon more widely used? In-Reply-To: <199604230137.UAA23142@ns1.computek.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O I think the main reason for Perl success as compared to Icon is code reuse. Today, I you are planning to write a CGI script, there is tons of free software, and libraries for Perl. Not so much for Icon. Another point is that people don't know Icon - they don't even know it exists. Two things to do: 1. Add CGI/HTML parsing to the Icon Library. 2. Put some examples on the Icon home page, and advertise on Usenet that they exist. Then wait... Bye, Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Wed Apr 24 09:14:56 1996 Received: by cheltenham.cs.arizona.edu; Wed, 24 Apr 1996 12:34:13 MST Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 24 Apr 1996 09:14:56 -0600 From: Charlie Hethcoat To: cshuster@ccmail.com Cc: icon-group@cs.arizona.edu Subject: Re[2]: Why isn't Icon more widely used? -Reply Errors-To: icon-group-errors@cs.arizona.edu Status: O Everyone is abuzz about HTML nowadays, so if something clever and new could be accomplished in Icon, it might be a Golden Oppty. But what would it be, exactly? What would it look like? Subroutine library? VBXs? Java code? Web browser? Or something totally unheralded? I personally would like to see Icon used in some way to enhance TeX/LaTeX formatting for both paper and screen (HTML) output. But I'm new at this stuff and haven't quite figured out what it would be. Some tools already exist, for example, to convert LaTeX into HTML and into Adobe PDF (written in Perl, if I am not mistaken). What in this area could better be done in Icon? Charles Hethcoat >>> 1996 Apr 23, 01:40pm >>> My thoughts exactly! An implementation of html parsing done in Icon would be a compelling example to Perl. Do any already exist? --Cy-- ______________________________ Reply Separator _________________________________ Subject: Re: Why isn't Icon more widely used? Author: gep2@computek.net at internet-mail Date: 4/23/96 8:32 AM The really good question is why Perl is so widely used in Web CGI scripts, where ICON could probably do the job a great deal better! This is a major new area IMHO where ICON could make a big impact, if it could be better known. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Apr 24 13:18:49 1996 Received: by cheltenham.cs.arizona.edu; Wed, 24 Apr 1996 16:23:05 MST Date: Wed, 24 Apr 1996 13:18:49 -0500 Message-Id: <199604241818.NAA24168@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Re[2]: Why isn't Icon more widely used? -Reply To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >Everyone is abuzz about HTML nowadays, so if something clever and new could be accomplished in Icon, it might be a Golden Oppty. But what would it be, exactly? What would it look like? Subroutine library? VBXs? Java code? Web browser? Or something totally unheralded? Well, for ONE thing, I'd like to see Icon replace Perl as _the_ premier tool for writing CGI scripts. One step in the right direction would be a (probably minor) adaptation to the interpreter to make it more "CGI efficient" (for example, if it were possible to permit reusing the interpreter for multiple applications in series without having to reload it each time). >I personally would like to see Icon used in some way to enhance TeX/LaTeX formatting for both paper and screen (HTML) output. Certainly Icon would be a neat tool for writing a Web browser, but everybody and their brother seems to be active there, and I doubt that Icon will compete performance-wise with whatever others (e.g. Netscape) have done. Certainly it would be relatively easy to make the Icon version more feature-rich, though. >Some tools already exist, for example, to convert LaTeX into HTML and into Adobe PDF (written in Perl, if I am not mistaken). What in this area could better be done in Icon? Icon (and SNOBOL4, for that matter) would be very good for conversions of this sort, too. But I'd really like to see something like CGI, where Icon (perhaps with a few minor tweaks) could meet (the vastly inferior) Perl head-on. I think this is a highly volatile market segment which would be just as happy to learn Icon as they are to learn Perl, and it would be a terrific foot-in-the-door. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Apr 24 16:58:38 1996 Received: by cheltenham.cs.arizona.edu; Wed, 24 Apr 1996 16:23:37 MST Date: Wed, 24 Apr 1996 16:58:38 -0400 From: dashiell@nadc.nadc.navy.mil (J. Dashiell) Message-Id: <199604242058.QAA29909@nadc.nadc.navy.mil> To: cshuster@ccmail.com, Charlie Hethcoat Subject: Re: Re[2]: Why isn't Icon more widely used? -Reply Cc: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: O I don't know that there's a means of getting pdf to ascii yet other than to use adobe's reader. Only problem with that is, that's totally graphical in nature. It writes to the screen using pixels. If someone were able to write a converter that could take both pdf and rip and convert them into ascii under dos using an ascii screen interface they'd make that information useable by the speech synthesizer using community. Right now, it's difficult getting .ps converted and impossible getting .pdf converted unless a computer with windows is involved, and even then it's a tricky operation for the first time windows user. jude From icon-group-sender Wed Apr 24 22:03:55 1996 Received: by cheltenham.cs.arizona.edu; Thu, 25 Apr 1996 06:16:37 MST Date: Wed, 24 Apr 1996 22:03:55 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9604250303.AA13291@water.cs.utsa.edu> To: gep2@computek.net Cc: icon-group@cs.arizona.edu In-Reply-To: <199604241818.NAA24168@ns1.computek.net> (gep2@computek.net) Subject: Re: Re[2]: Why isn't Icon more widely used? -Reply Content-Length: 927 Errors-To: icon-group-errors@cs.arizona.edu Status: O [Gordon Peterson writes:] One step in the right direction would be a (probably minor) adaptation to the interpreter to make it more "CGI efficient" (for example, if it were possible to permit reusing the interpreter for multiple applications in series without having to reload it each time). This is a good idea, and could be done without much work. We already have a capability for one Icon program to load and execute other Icon programs, we just need to work out the protocol for sending a job/program to such an "Icon server". Under those UNIX systems that support the dynamic loading facility and can use the sockets code in the Icon program library, the whole thing is readily implementable, the question is just: who wants to do it? Clint Jeffery jeffery@ringer.cs.utsa.edu Division of Computer Science The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Thu Apr 25 08:32:56 1996 Received: by cheltenham.cs.arizona.edu; Thu, 25 Apr 1996 13:05:47 MST Date: Thu, 25 Apr 1996 08:32:56 -0500 Message-Id: <199604251332.IAA11843@post.its.mcw.edu> X-Sender: cdt@post.its.mcw.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Charlie Hethcoat From: cdt@post.its.mcw.edu (Chris D. Tenaglia) Subject: Re: Re[2]: Why isn't Icon more widely used? -Reply Cc: icon-group@cs.arizona.edu X-Mailer: Errors-To: icon-group-errors@cs.arizona.edu Status: O Need a killer app? I say this only half jokingly, but myself and some colleagues have noticed that the whole world revolves around "mail and labels". Think of using a browser to generate mailing labels or email lookups, or work flow in a way not thought of before. I've made email lookups converting MSaccess extracts and Netware Bindery dumps into HTML. Lots of URLS that look like file:///h|/mine.htm and so forth. Chris. >Everyone is abuzz about HTML nowadays, so if something clever and new >could be accomplished in Icon, it might be a Golden Oppty. But what would >it be, exactly? What would it look like? Subroutine library? VBXs? Java >code? Web browser? Or something totally unheralded? > >Charles Hethcoat > >>>> 1996 Apr 23, 01:40pm >>> > > My thoughts exactly! An implementation of html parsing done in Icon > would be a compelling example to Perl. Do any already exist? > > --Cy-- > >______________________________ Reply Separator >_________________________________ >Subject: Re: Why isn't Icon more widely used? >Author: gep2@computek.net at internet-mail >Date: 4/23/96 8:32 AM > > >The really good question is why Perl is so widely used in Web CGI scripts, >where > >ICON could probably do the job a great deal better! > >This is a major new area IMHO where ICON could make a big impact, if it >could be > >better known. > 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 Apr 27 10:27:41 1996 Received: by cheltenham.cs.arizona.edu; Sat, 27 Apr 1996 07:41:07 MST Message-Id: <3181E88D.7DB5@tees.ac.uk> Date: Sat, 27 Apr 1996 10:27:41 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Re: Splitting and joining strings References: <199604172119.QAA18647@post.its.mcw.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Thanks to everyone who responded to my post about splitting and joining strings. I had hesitated about posting the question, suspecting that it would be thought too trivial, but I was interested by how many different solutions were offered to this 'trivial' problem :-). Bob Alexander provided the solution which came closest to what I was after, which (with some modifications I've made to the join procedure) I present below for anyone who's interested. procedure join(stringList,separator) local result result := get(stringList) every result ||:= separator || !stringList return result end procedure split(string,separator) local result string ? { until pos(0) do { result := tab(find(separator) | 0) suspend result move(*separator) } } end | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Tue Apr 30 14:39:42 1996 Received: by cheltenham.cs.arizona.edu; Tue, 30 Apr 1996 12:20:43 MST Message-Id: <3186181E.449B@tees.ac.uk> Date: Tue, 30 Apr 1996 14:39:42 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: Icon group Subject: File locking in Icon for Unix Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O I need to be able to lock a file to prevent multiple access to it (I'm using SunOS 4). I reckon I will need to have an external C function that calls the flock() function. Before I write it, I thought I'd find out if anyone else has already done this. | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Tue Apr 30 15:58:37 1996 Received: by cheltenham.cs.arizona.edu; Wed, 1 May 1996 05:25:56 MST Date: Tue, 30 Apr 1996 15:58:37 -0400 From: dashiell@nadc.nadc.navy.mil (J. Dashiell) Message-Id: <199604301958.PAA03287@nadc.nadc.navy.mil> To: icon-group@cs.arizona.edu Subject: projects to help icon Errors-To: icon-group-errors@cs.arizona.edu Status: O Thinking about some info I read over on doslynx-dev, specifically that the current alpha version for dos was compiled with alot of broken libraries not least of which was an old version of turbovision and doslynx-dev has also run out of money for repairs to existing alpha software let alone upgrades. The whole doslynx program might be written using icon if broken libraries could be avoided and if performance of software were at reasonable levels. Specifically identical or better than current doslynx performance. If something similar to this project were done, it might be possible to improve forms filling interface and actually implement forms filling for dos, it's not currently supported. It might also be possible for the dos version to play sounds it links to, also not currently supported. In any case I'd not advise anyone to attempt something like this unless they had the bugs list for known bugs in the current executables before starting out. The dos version was compiled on bcc plus. jude // EOJ jude Q: What's the difference between a used car salesman and a used computer salesman? A: The used car salesman knows when he's lying to you. From icon-group-sender Tue Apr 30 16:04:47 1996 Received: by cheltenham.cs.arizona.edu; Wed, 1 May 1996 05:26:16 MST Date: Tue, 30 Apr 1996 16:04:47 -0400 From: dashiell@nadc.nadc.navy.mil (J. Dashiell) Message-Id: <199604302004.QAA03932@nadc.nadc.navy.mil> To: icon-group@cs.arizona.edu Subject: project to help icon cont. Errors-To: icon-group-errors@cs.arizona.edu Status: O Forgot one other feature of doslynx. The dos version doesn't write well to the screen, but I think that's a function of turbovision libraries since those don't support speech friendly screen writing. jude // EOJ jude Q: What's the difference between a used car salesman and a used computer salesman? A: The used car salesman knows when he's lying to you. From icon-group-sender Fri May 3 23:57:34 1996 Received: by cheltenham.cs.arizona.edu; Sat, 4 May 1996 22:36:45 MST From: Jules Gilbert Date: Fri, 3 May 1996 23:57:34 -0400 (EDT) Message-Id: <199605040357.XAA28460@spock.ici.net> To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: O To: icon-group@cs.arizona.edu Subject: Icon and linear algebra I'm looking for Icon based tools to do linear algebra and numerical methods. If anyone has a pointer to an available library, I would appreciate it very much. Thank you, Jules From icon-group-sender Mon May 6 21:38:40 1996 Received: by cheltenham.cs.arizona.edu; Tue, 7 May 1996 06:31:33 MST Message-Id: <318E6350.29CA@tees.ac.uk> Date: Mon, 06 May 1996 21:38:40 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: Icon group Subject: Regular expression to Icon converter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O I know that regexp.icn in the Icon Program Library contains procedures for doing regular-expression matching, but has anyone written a program that will convert a regular expression into equivalent Icon code? For example, given the string ^ab+ the program produces ="a" & move(many('b')) Such a utility could be useful to those coming to Icon with experience in REs, or to those wanting to convert Perl code to Icon. | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Mon May 6 22:17:27 1996 Received: by cheltenham.cs.arizona.edu; Tue, 7 May 1996 06:31:44 MST Message-Id: <318E6C67.294D@tees.ac.uk> Date: Mon, 06 May 1996 22:17:27 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: Icon group Subject: Why are 'every', 'until', and 'while' designed to fail? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Is there some reason why the 'every', 'until', and 'while' contructs were designed so that they inevitably fail? There seems to me to be a certain redundancy in having the control expression's termination or failure signalled in this way, since we only get a value for the loop when the loop has terminated anyway. Would it not be more useful to have these contructs do something like return the value of their 'do' expressions, thus allowing some expressions to be expressed more elegantly and with less 'housekeeping'. I don't envisage that such a change would break existing code, since no-one presumably makes use as yet of the value of 'every', 'until', or 'while' expressions. | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Mon May 6 19:14:09 1996 Received: by cheltenham.cs.arizona.edu; Tue, 7 May 1996 06:31:26 MST To: icon-group@cs.arizona.edu Date: 6 May 1996 19:14:09 -0700 From: icon-project@cs.arizona.edu Message-Id: <4mmblh$f7f@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 Status: O Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language Last updated: February 16, 1996 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 UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and the Acorn Archimedes. There are older versions for the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, 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? 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, and runs on UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and Acorn Archimedes. Other implementations presently are at Version 8. Almost all programs that run under Version 8 and that do not use graphics will run under Version 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 support Icon's graphics facilities are in beta testing. 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), postal money order, or check drawn on a bank with a branch in the United States and made payable to The University of Arizona. Icon is available on CD-ROM from Prime Time Freeware (http://www.ptf.com/, 408-433-9662). Contact them for details. 11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, second edition, 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. 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 subscription 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, revenue from the sale of program material and documentation, and user contributions. 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 updated only 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 twice a year. There also is a subscription service for updates to the Icon program library, which provides new material about twice 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? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please 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. 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 May 7 06:59:08 1996 Received: by cheltenham.cs.arizona.edu; Tue, 7 May 1996 12:21:39 MST Date: Tue, 7 May 1996 06:59:08 -0700 From: Ralph Griswold Message-Id: <9605071359.AA23150@ursus.cs.arizona.edu> To: H.Lawson@tees.ac.uk, icon-group@cs.arizona.edu Subject: Re: Why are 'every', 'until', and 'while' designed to fail? Errors-To: icon-group-errors@cs.arizona.edu Status: O The reason looping control structures fail is because they produce no value, which is equivalent to failure in Icon. The reason there is no value is that there is no consistent way to produce one. E.g., "do" clauses are optional. While there are possible ways to provide an interpretation of a returned *result*, since looping control structures usually are not used in situations where their results are useful, we decided to give a simple, uniform result (failure). Using looping control structures in ways that their results could be used generally is not good programming style -- if nothing else, it's hard to understand. Note that you can produce a result other than failure for a control structure using break, as in while ... do { ... break s } which produces s for the while-do control structure if the break expression is evaluated. 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 Fri May 10 14:59:38 1996 Received: by cheltenham.cs.arizona.edu; Fri, 10 May 1996 16:24:32 MST To: icon-group@cs.arizona.edu Date: Fri, 10 May 1996 14:59:38 -0400 From: Eric Vinson Message-Id: <3193921A.7D467185@cabell.vcu.edu> Organization: Virginia Power Sender: icon-group-request@cs.arizona.edu Subject: Icon Window Interface -- HELP!! Errors-To: icon-group-errors@cs.arizona.edu Status: O HI, I'm trying to find an example for opening files in a Linux X-Win environment. I got the IPD259 on Icon Window Iinterface Tools, I cant find an example for opening files ( the Vdemo has a file submenu , but the cb function isnt implememted ) Any examples would be *GREATLY* appreciated! post or email reply to csc4ecv@cabell.vcu.edu thanks!! From icon-group-sender Thu May 16 03:37:24 1996 Received: by cheltenham.cs.arizona.edu; Thu, 16 May 1996 08:41:13 MST To: icon-group@cs.arizona.edu Date: 16 May 1996 03:37:24 GMT From: midtoad@cadvision.com (Stewart Midwinter) Message-Id: <4ne7tk$17vo@elmo.cadvision.com> Organization: Wings of Gaia Sender: icon-group-request@cs.arizona.edu Reply-To: midtoad@cadvision.com Subject: 'Word wrap' utility Errors-To: icon-group-errors@cs.arizona.edu Status: O I'm only getting started in icon, but want to create a little utility. Before I do though, I should ask whether I'm reinventing the wheel and whether anyone else has already done this. I have written the utility in turbo pascal, and am happy with its performance, but want to test the claim that icon is better at string handling. So far, some of the icon concepts are confusing to me. Anyway, here's the concept of the strip utility: Often we receive mail messages, or FAQs, or other items that, when printed through a word processor or other program in proportional font instead of courier font, look terrible, since the lines are too short and of uneven length. The idea is to strip out all hard carriage returns within paragraphs, so that the full line length is used. Looks much nicer, but manually is not the way! The problem centers around how to tell what carriage returns to strip out: - yes if the line is followed by another line of text - no on lines of text followed by blank lines or lines containing only spaces (we presume these are the last line of a paragraph) - no on lines containing only spaces (we presume these lines are there to create vertical white space) - no on lines whose first non-space character is a number (we presume these are table list items) - no on lines whose first non-space character is in a user-definable list of symbols (e.g.: / \<< >> etc.), typically these symbols would be stored in a *.ini file (we presume that the user may have reason to over-ride the program's logic by manually indicating certain lines should be left as is (e.g. lines of a poem) Some idea of how to approach the problem can be had by looking in the icon library at yescr.icn and nocr.icn, which convert DOS line endings to unix line endings (and vice versa). Any suggestions on how to approach this, or has it been done already? Cheers, Stewart Midwinter created with OS/2 Warp and Neologic News 4.5 From icon-group-sender Thu May 16 12:13:05 1996 Received: by cheltenham.cs.arizona.edu; Thu, 16 May 1996 12:31:27 MST Date: Thu, 16 May 1996 12:13:05 -0700 From: Ralph Griswold Message-Id: <9605161913.AA07017@ursus.cs.arizona.edu> To: icon-group Subject: Help Wanted Errors-To: icon-group-errors@cs.arizona.edu Status: O The Icon Project needs volunteers to help complete implementations of Icon for the Macintosh, OS/2, and Microsoft Windows. The Macintosh implementation is only partially done; most of the work, including graphics and an application interface, remains. The OS/2 implementation is substantially complete; some work on graphics and testing/debugging remains. The Windows implementation is in beta testing; what's needed is a capable application interface. If you are interested in one of these projects, contact icon-project@cs.arizona.edu for more information. From icon-group-sender Wed May 29 23:07:51 1996 Received: by cheltenham.cs.arizona.edu; Thu, 30 May 1996 08:14:20 MST Date: Wed, 29 May 1996 23:07:51 -0400 (EDT) From: "Phillip L. Thomas" To: Stewart Midwinter Cc: icon-group@cs.arizona.edu Subject: Re: 'Word wrap' utility In-Reply-To: <4ne7tk$17vo@elmo.cadvision.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O On 16 May 1996, Stewart Midwinter wrote: ... > > Often we receive mail messages, or FAQs, or other items that, when > printed through a word processor or other program in proportional font > instead of courier font, look terrible, since the lines are too short > and of uneven length. The idea is to strip out all hard carriage > returns within paragraphs, so that the full line length is used. > Looks much nicer, but manually is not the way! > > The problem centers around how to tell what carriage returns to strip > out: The easiest solution in icon (or any other decent text language like snobol4/spitbol) is to handle two lines at a time, beginning with the first line set to "" and then read new lines into the second line: firstline := "" while secondline := read() do { # if secondline should not be appended to firstline # then write the firstline and make firstline := "" # if second line can be printed now, do it # else firstline ||:= secondline } write(\firstline) I'd write a procedure to determine the printability of the second line and use in it icon's excellent matching and addressing functions to code your conditions. -- Phillip Lee Thomas Library of Congress From icon-group-sender Tue Jun 4 16:02:38 1996 Received: by cheltenham.cs.arizona.edu; Wed, 5 Jun 1996 07:39:59 MST To: icon-group@cs.arizona.edu Date: 4 Jun 1996 16:02:38 -0700 From: icon-project@cs.arizona.edu Message-Id: <4p2fae$8sr@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 Status: O Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language Last updated: February 16, 1996 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 UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and the Acorn Archimedes. There are older versions for the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, 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? 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, and runs on UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and Acorn Archimedes. Other implementations presently are at Version 8. Almost all programs that run under Version 8 and that do not use graphics will run under Version 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 support Icon's graphics facilities are in beta testing. 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), postal money order, or check drawn on a bank with a branch in the United States and made payable to The University of Arizona. Icon is available on CD-ROM from Prime Time Freeware (http://www.ptf.com/, 408-433-9662). Contact them for details. 11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, second edition, 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. 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 subscription 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, revenue from the sale of program material and documentation, and user contributions. 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 updated only 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 twice a year. There also is a subscription service for updates to the Icon program library, which provides new material about twice 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? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please 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. 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 Fri Jun 7 15:30:50 1996 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jun 1996 07:59:31 MST To: icon-group@cs.arizona.edu Date: 7 Jun 1996 15:30:50 -0500 From: nr@cs.purdue.edu (Norman Ramsey) Message-Id: <4pa3hq$lpc@labrador.cs.purdue.edu> Organization: Department of Computer Science, Purdue University Sender: icon-group-request@cs.arizona.edu References: <199606071540.LAA18004@morgoth> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O In article <199606071540.LAA18004@morgoth>, Warren Smith wrote: >R.W.Floyd pointed out the desirability of > a <--> b >and > (a,b,c) <-- (f,g,h) >swap and simultaneous assignment - primitives in his Turing >award lecture about 20 years ago, but so far as I know, the SWAP >recommendation has not been provided in a common language >since then. Icon has swap, notated :=: I've wished for multiple assignment many times but have never seen it outside of the LISP family, where it masquerades as `let'. I can't remember; does M3 WITH evaluate all right-hand sides before binding? N -- Norman Ramsey http://www.cs.purdue.edu/homes/nr From icon-group-sender Sat Jun 8 15:50:25 1996 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jun 1996 07:59:41 MST To: icon-group@cs.arizona.edu Date: 8 Jun 1996 15:50:25 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <4pd03h$g3o@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <199606071540.LAA18004@morgoth>, <4pa3hq$lpc@labrador.cs.purdue.edu> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O In article <4pa3hq$lpc@labrador.cs.purdue.edu>, Norman Ramsey wrote: >In article <199606071540.LAA18004@morgoth>, >Warren Smith wrote: > >R.W.Floyd pointed out the desirability of > > a <--> b > >and > > (a,b,c) <-- (f,g,h) > >swap and simultaneous assignment - primitives in his Turing > >award lecture about 20 years ago, but so far as I know, the SWAP > >recommendation has not been provided in a common language > >since then. > >Icon has swap, notated :=: As you say. For my part, the only time I've found 'swap' to be a useful operation is when I am writing sort algorithm (or sort-related algorithms, like heap manipulation). Since (in my experience, anyway) this is not a frequent occurrance, it doesn't seem like the best idea in the world to include 'swap' as part of any language's basic repetoir of operations. Perhaps others have found a more extensive use for swapping? >I've wished for multiple assignment many times but have never seen it >outside of the LISP family, where it masquerades as `let'. What about Icon? record Foo(first, second, third) fghFoo := Foo(f, g, h) abcFoo := copy(fghFoo) Some observations: 1. No, in the most literal sense, this is not 'mulitple assignment', but 2. It accomplishes the same thing, and 3. If three variables are closely related enough to group in a multiple assignment, don't they belong in a Record anyway? 4. The example extends to any language that supports record assignment by copying. -Dave From icon-group-sender Sun Jun 9 01:06:04 1996 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jun 1996 08:00:07 MST To: icon-group@cs.arizona.edu Date: 09 Jun 1996 01:06:04 -0400 From: schwartz@galapagos.cse.psu.edu (Scott Schwartz) Message-Id: <8gd9395zyb.fsf@galapagos.cse.psu.edu> Organization: penn state computer science and engineering Sender: icon-group-request@cs.arizona.edu References: <199606071540.LAA18004@morgoth> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O nr@cs.purdue.edu (Norman Ramsey) writes: | I've wished for multiple assignment many times but have never seen it | outside of the LISP family, where it masquerades as `let'. Alef, a concurrent systems programming language used in Plan 9 from Bell Labs, has simultaneous assignment. From icon-group-sender Sun Jun 9 16:07:46 1996 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jun 1996 08:00:28 MST To: icon-group@cs.arizona.edu Date: Sun, 9 Jun 1996 16:07:46 GMT From: leeo@eskimo.com (Lee Odegard) Message-Id: Organization: Eskimo North (206) For-Ever Sender: icon-group-request@cs.arizona.edu References: <199606071540.LAA18004@morgoth>, <4pa3hq$lpc@labrador.cs.purdue.edu>, <4pd03h$g3o@lectura.CS.Arizona.EDU> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O dave@CS.Arizona.EDU (Dave Schaumann) writes: >As you say. For my part, the only time I've found 'swap' to be a useful >operation is when I am writing sort algorithm (or sort-related algorithms, >like heap manipulation). In my own work, I've seen many instances where algorithms could be described more succintly with designator := expr_designator := expression ; to abbreviate designator := expr_designator ; expr_designator := expression ; In this notation, a swap would appear VAR temp : type_of_designator ; BEGIN temp := item1 := item2 := temp ; END ; --Lee From icon-group-sender Sun Jun 9 22:00:20 1996 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jun 1996 08:01:20 MST To: icon-group@cs.arizona.edu Date: 9 Jun 1996 22:00:20 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <4pga54$2qt@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <199606071540.LAA18004@morgoth>, <4pa3hq$lpc@labrador.cs.purdue.edu>, <8gd9395zyb.fsf@galapagos.cse.psu.edu> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O In article <8gd9395zyb.fsf@galapagos.cse.psu.edu>, Scott Schwartz wrote: >nr@cs.purdue.edu (Norman Ramsey) writes: >| I've wished for multiple assignment many times but have never seen it >| outside of the LISP family, where it masquerades as `let'. > >Alef, a concurrent systems programming language used in Plan 9 from >Bell Labs, has simultaneous assignment. Another language that has true multiple variable assignment is CLU. See _Abstraction and Specification in Program Development_ by Liskov and Guttag, ISBN 0-07-037996-3. I think it's still in print, although the language would appear to be pretty much dead (if the traffic on comp.lang.clu is any indication). CLU has some interesting ideas in it's design (though, as you might guess from my other post on this thread, I don't regard multiple assignment as one of them). -Dave From icon-group-sender Mon Jun 10 20:46:04 1996 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jun 1996 16:54:51 MST Message-Id: <31BC7B7C.300A@tees.ac.uk> Date: Mon, 10 Jun 1996 20:46:04 +0100 From: Hamish Lawson Organization: University of Teesside, School of Computing and Maths X-Mailer: Mozilla 3.0b4Gold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Re: m3 should have SWAP(a,b) References: <199606071540.LAA18004@morgoth>, <4pa3hq$lpc@labrador.cs.purdue.edu>, <8gd9395zyb.fsf@galapagos.cse.psu.edu> <4pga54$2qt@lectura.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O I seem to missed the post that started this thread. What is this m3? And how come it's being discussed in this mailing list -- is it a successor to Icon, as Icon was to SNOBOL? | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Tue Jun 11 13:54:29 1996 Received: by cheltenham.cs.arizona.edu; Tue, 11 Jun 1996 07:45:12 MST To: icon-group@cs.arizona.edu Date: 11 Jun 1996 13:54:29 +1000 From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Message-Id: <4piqll$mpm@goanna.cs.rmit.EDU.AU> Organization: Comp Sci, RMIT, Melbourne, Australia Sender: icon-group-request@cs.arizona.edu References: <4pa3hq$lpc@labrador.cs.purdue.edu>, <8gd9395zyb.fsf@galapagos.cse.psu.edu>, <4pga54$2qt@lectura.CS.Arizona.EDU> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O Concerning swap and rotate. (1) Burroughs Algol had READLOCK(Variable, Value) which stored Value into Variable and returned the old value of Variable. (2) Didnt "Mary" have a swap operator? (3) Mesa allowed record constructors on the left hand side of assignment, Pair[x,y] := Pair[y,x]; for example. (4) Pop-2 allows many forms of rotation. For example, to get the effect of a,b,c := b,c,a do a, c, b -> a -> b -> c (This means Push(a); Push(c); Push(b); PopInto(a); PopInto(b); PopInto(c);) (5) Dijkstra's notation uses parallel assignment; I believe there have been one or two implementations of it. (6) The Lisp equivalent of swap and rotate is not 'let' but PSETF and ROTATEF. When I tried to learn how to play the bagpipes, the reason bagpipers play all those trills and twiddly bits became instantly apparent: if you try to changing fingering from that for note X to that for note Y the way you would with a recorder or flute, it sounds _horrible_, because the air keeps on flowing and you get strange sounds as you pass through intermediate states. Half the art of piping is dancing all around the notes in order to pass from one note to another without hitting intermediate states that will sound bad. That's the reason why parallel assignment is useful: it lets you move from one state to another *without* introducing strange intermediate states. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. From icon-group-sender Tue Jun 11 10:16:10 1996 Received: by cheltenham.cs.arizona.edu; Tue, 11 Jun 1996 07:45:38 MST To: icon-group@cs.arizona.edu Date: 11 Jun 1996 10:16:10 GMT From: fanf2@thor.cam.ac.uk (Tony Finch) Message-Id: <4pjh1a$7ns@lyra.csx.cam.ac.uk> Organization: Coll: SS. et Indiv: Trin: Cant: Sender: icon-group-request@cs.arizona.edu References: <8gd9395zyb.fsf@galapagos.cse.psu.edu>, <4pga54$2qt@lectura.CS.Arizona.EDU>, <4piqll$mpm@goanna.cs.rmit.EDU.AU> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O In article <4piqll$mpm@goanna.cs.rmit.EDU.AU>, Richard A. O'Keefe wrote: > Concerning swap and rotate. [...] > (5) Dijkstra's notation uses parallel assignment; I believe there have been > one or two implementations of it. [...] > That's the reason why parallel assignment is useful: it lets you move from > one state to another *without* introducing strange intermediate states. BCPL has parallel assignment. Tony. -- "What it all amounts to is that english is chiefly a matter of marksmanship." From icon-group-sender Mon Jun 10 17:45:25 1996 Received: by cheltenham.cs.arizona.edu; Tue, 11 Jun 1996 07:45:48 MST To: icon-group@cs.arizona.edu Date: Mon, 10 Jun 1996 17:45:25 GMT From: pardoej@lonnds.ml.com (Julian Pardoe LADS LDN X1428) Message-Id: Organization: Merrill Lynch Europe Sender: icon-group-request@cs.arizona.edu References: Reply-To: pardoej@lonnds.ml.com Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O In article , leeo@eskimo.com (Lee Odegard) writes: -->dave@CS.Arizona.EDU (Dave Schaumann) writes: --> -->>As you say. For my part, the only time I've found 'swap' to be a useful -->>operation is when I am writing sort algorithm (or sort-related algorithms, -->>like heap manipulation). --> -->In my own work, I've seen many instances where algorithms could be described -->more succintly with --> designator := expr_designator := expression ; -->to abbreviate --> designator := expr_designator ; --> expr_designator := expression ; -->In this notation, a swap would appear --> --> VAR temp : type_of_designator ; BEGIN --> temp := item1 := item2 := temp ; END ; -->--Lee This notation might confuse programmers used to right-associative assigment, where a := b := c abbreviates b := c; a :=b Algol68C had the `displacement operator', :=:= which yield the old value of the LHS rather than the new value (as yielded by :=). Thus a swap could be written a := b :=:= a This also gave us the equivalent of C's i++: i +:=:= 1 and some neat syntax for list operations: next OF new item := list head :=:= new item Whether you like such things is a matter of taste. I did because it meant I could expression a logically single operation as one statement (or `unit' in A68C-talk). Likewise, (assuming a C-like stdio library): fclose (file :=:= NULL) meaning "close the file and note that we have no open file" as a single operation. Of course, you can write some pretty bizarre stuff if you want to. My favourite was ( b | x +:= 1; y | x ) +:= 1 -- jP -- From icon-group-sender Tue Jun 11 01:03:56 1996 Received: by cheltenham.cs.arizona.edu; Wed, 12 Jun 1996 09:00:07 MST To: icon-group@cs.arizona.edu Date: Tue, 11 Jun 1996 01:03:56 GMT From: beatty@netcom.com (Derek Lee Beatty) Message-Id: <4pigls$1kq@beatty.slip.netcom.com> Organization: none Sender: icon-group-request@cs.arizona.edu References: <199606071540.LAA18004@morgoth>, <4pa3hq$lpc@labrador.cs.purdue.edu>, <4pd03h$g3o@lectura.CS.Arizona.EDU> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O dave@CS.Arizona.EDU (Dave Schaumann) wrote: >For my part, the only time I've found 'swap' to be a useful >operation is when I am writing sort algorithm (or sort-related algorithms, >like heap manipulation). Since (in my experience, anyway) this is not a >frequent occurrance, it doesn't seem like the best idea in the world to >include 'swap' as part of any language's basic repetoir of operations. > >Perhaps others have found a more extensive use for swapping? > I've found SWAP useful in VLSI circuit analysis. I suspect other domains where the natural representation is nearly a graph might be similar. I'd expect that once you decide to include SWAP, generalizing to multiple assignment might be worthwhile. Perhaps after the right-hand sides are evaluated, all the left-hand sides could be updated atomically? (I'm just guessing here; perhaps that would complicate the runtime unnecessarily.) -- Derek Lee Beatty _ Death beatty@netcom.com _| ~-, Taxes Austin, Texas \, * } C++ \_( From icon-group-sender Wed Jun 12 14:13:52 1996 Received: by cheltenham.cs.arizona.edu; Wed, 12 Jun 1996 09:00:18 MST To: icon-group@cs.arizona.edu Date: 12 Jun 1996 14:13:52 +1000 From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Message-Id: <4plg60$k8e@goanna.cs.rmit.EDU.AU> Organization: Comp Sci, RMIT, Melbourne, Australia Sender: icon-group-request@cs.arizona.edu References: <4pga54$2qt@lectura.CS.Arizona.EDU>, <4piqll$mpm@goanna.cs.rmit.EDU.AU>, <4pjh1a$7ns@lyra.csx.cam.ac.uk> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O fanf2@thor.cam.ac.uk (Tony Finch) writes: >BCPL has parallel assignment. Alas, not true. Quoting a BCPL reference: "The multiple assignment, for example x, y := E1, E2 indicates that the separate assignments x := E1; y := E2 will be performed SEQUENTIALLY (*not* simultaneously). The order of performing the assignments is undefined." This means that x, y := y, x may have either the effect of x := y; y := x (new x = new y = old y) or of y := x; x := y (new x = new y = old x) neither of which is the effect of a true parallel assignment. This caused me enormous trouble when trying to translate a BCPL program to Algol once, because I kept reading multiple assignments as parallel, but they weren't. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. From icon-group-sender Wed Jun 12 13:39:41 1996 Received: by cheltenham.cs.arizona.edu; Wed, 12 Jun 1996 16:25:00 MST To: icon-group@cs.arizona.edu Date: Wed, 12 Jun 1996 13:39:41 -0400 From: Farshad Nayeri Message-Id: <31BF00DD.5535@cmass.com> Organization: Critical Mass, Inc. Sender: icon-group-request@cs.arizona.edu References: <4pa3hq$lpc@labrador.cs.purdue.edu>, <4pd03h$g3o@lectura.CS.Arizona.EDU>, <4pigls$1kq@beatty.slip.netcom.com> Subject: Re: m3 should have SWAP(a,b) Errors-To: icon-group-errors@cs.arizona.edu Status: O Derek Lee Beatty wrote: > > dave@CS.Arizona.EDU (Dave Schaumann) wrote: > >For my part, the only time I've found 'swap' to be a useful > >operation is when I am writing sort algorithm (or sort-related algorithms, > >like heap manipulation). Since (in my experience, anyway) this is not a > >frequent occurrance, it doesn't seem like the best idea in the world to > >include 'swap' as part of any language's basic repetoir of operations. > > > >Perhaps others have found a more extensive use for swapping? > > > > I've found SWAP useful in VLSI circuit analysis. I suspect other domains > where the natural representation is nearly a graph might be similar. > > I'd expect that once you decide to include SWAP, generalizing to multiple > assignment might be worthwhile. Perhaps after the right-hand sides are > evaluated, all the left-hand sides could be updated atomically? (I'm just > guessing here; perhaps that would complicate the runtime unnecessarily.) I would take Derek's point one step further: I am yet to see a concise proposal that clearly describes the semantics of the SWAP or multiple assignment operator (especially in presense of threads.) Sure, it's not so hard to think about the syntax for it, but that's the least of the problem. I'll even be satisfied with a syntactic mapping, e.g., the way the Modula-3 language specification maps LOCK END to TRY FINALLY END. So far, everyone seems to have a different semantic in mind. In fact, I propose that future syntax "wish list" proposals should at least include a syntactic mapping. Of course, they should also mention which features they are willing to cut in order to include the new proposal! (Or God forbid, state that they want to go beyond the 50 pages?!) -- Farshad From icon-group-sender Thu Jun 13 11:24:24 1996 Received: by cheltenham.cs.arizona.edu; Thu, 13 Jun 1996 12:20:23 MST Date: Thu, 13 Jun 1996 11:24:24 -0700 From: david@byrd.ba.msi.com (David Harrison) Message-Id: <199606131824.LAA20218@byrd.ba.msi.com> To: icon-group@cs.arizona.edu Subject: &dateline uses wrong time zone? Errors-To: icon-group-errors@cs.arizona.edu Status: O I am using Icon 9.1 on an SGI IRIX 5.3 machine. Is there support for locking files? I am using Icon to process CGI requests from a web server. Since multiple people might access the programs at once, I would like to lock the file processing phases of these programs. I didn't see anything right off hand in the documentation. David Harrison, Molecular Simulations (david@ba.msi.com) From icon-group-sender Fri Jun 14 08:53:07 1996 Received: by cheltenham.cs.arizona.edu; Fri, 14 Jun 1996 08:18:43 MST Date: Fri, 14 Jun 1996 08:53:07 +0200 From: karczma@calvin.info.unicaen.fr (Jerzy Karczmarczuk) Message-Id: <9606140653.AA00140@canardo.unicaen.fr> To: icon-group@cs.arizona.edu Subject: Locking files X-Sun-Charset: US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O David Harrison writes: > I am using Icon 9.1 on an SGI IRIX 5.3 machine. Is there support for > locking files? I am using Icon to process CGI requests from a web > server. Since multiple people might access the programs at once, > I would like to lock the file processing phases of these programs. > I didn't see anything right off hand in the documentation. > > David Harrison, Molecular Simulations I am not sure whether FCNTL is supported by Icon on all Unix platforms, and so the selective locks you might program by hand, but don't forget that there is a cheap way of locking something globally used for ages: the *creation* of a special "lock" file just before entering the critical section (if it is absent, otherwise sleep/wait), and the destruction after. This has nothing to do in principle with Icon. But it suggests another question. Does Icon support DBM or some other not-so-low level of database management? I found already several times that the explosion of web programs and the 100-fold increase in the number of people who do something in the domain without being extremely technically oriented gurus, increased the number of not very secure programs, because the nice, user-friendly and high-level languages lack some tools adapted to the non-cooperative environments. And worried people will still use Perl... Jerzy Karczmarczuk Dept.of Comp. Sci., University of Caen, Normandy, France. From icon-group-sender Tue Jun 18 13:11:43 1996 Received: by cheltenham.cs.arizona.edu; Tue, 18 Jun 1996 08:58:26 MST Message-Id: <31C69CFF.6292@tees.ac.uk> Date: Tue, 18 Jun 1996 13:11:43 +0100 From: Hamish Lawson Organization: University of Teesside X-Mailer: Mozilla 3.0b4Gold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Re: Locking files References: <9606140653.AA00140@canardo.unicaen.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Jerzy Karczmarczuk wrote: > there is a cheap way of locking something > globally used for ages: the *creation* of a special "lock" file > just before entering the critical section (if it is absent, > otherwise sleep/wait), and the destruction after. Is there not a small risk that in the time between some process finding that the lock file doesn't exist and creating this file, another process might also find that the lock file doesn't exist, thereby breaking the exclusivity mechanism. | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Tue Jun 18 12:57:40 1996 Received: by cheltenham.cs.arizona.edu; Tue, 18 Jun 1996 13:13:45 MST Message-Id: <9606181957.AA24809@ cynic.org> To: Hamish Lawson Cc: icon-group@cs.arizona.edu Subject: Re: Locking files In-Reply-To: Your message of Tue, 18 Jun 1996 13:11:43 BST. <31C69CFF.6292@tees.ac.uk> Date: Tue, 18 Jun 1996 12:57:40 -0700 From: Perry The Cynic Errors-To: icon-group-errors@cs.arizona.edu Status: O >> there is a cheap way of locking something >> globally used for ages: the *creation* of a special "lock" file >> just before entering the critical section (if it is absent, >> otherwise sleep/wait), and the destruction after. > Is there not a small risk that in the time between some process finding > that the lock file doesn't exist and creating this file, another process > might also find that the lock file doesn't exist, thereby breaking the > exclusivity mechanism. For the "lockfile trick" to work between two "lockers", the operating service/system interface must provide "atomic create"; that is, "create this file if it doesn't exist, but fail if it does, atomically." All UNIXes (that I know of) allow this (the O_EXCL flag to the open() system call), and most other operating systems have equivalent functionality (even MS-DOS). On a system that does *not* have this feature, the lockfile trick is not (completely) safe. Icon models its open() function on the UNIX fopen() routine, which (for historic reasons) does not *portably* provide access to the underlying O_EXCL open() flag. Thus, creating a lockfile using Icon's standard open() function is not (completely) safe. This is not really a failure of Icon, since it is supposed to provide *portable* access to whatever system it runs on -- some of which may not support atomic file creation at all. There are other warts on the "simple" lockfile idea. If a process dies unexpectedly (say, killed by system crash or operator), a stale lockfile may be left behind. For a robust system, you must therefore encode extra information (e.g. the process id of the owner) to check for stale lockfiles and recover from them. That in turn is becoming quite system dependent (checking whether a process is alive, choosing timeout periods, etc.), not to mention interesting in the presence of network file systems. -- perry --------------------------------------------------------------------------- Perry The Cynic perry@cynic.org To a blind optimist, an optimistic realist must seem like an Accursed Cynic. --------------------------------------------------------------------------- From icon-group-sender Tue Jun 18 13:09:09 1996 Received: by cheltenham.cs.arizona.edu; Tue, 18 Jun 1996 13:13:57 MST X-Sender: nevin@192.12.69.186 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 13:09:09 -0700 To: "Icon Group" From: nevin@cs.arizona.edu (Nevin ":-]" Liber) Subject: Re: Locking files Errors-To: icon-group-errors@cs.arizona.edu Status: O At 5:11 AM 6/18/96, Hamish Lawson wrote: > Jerzy Karczmarczuk wrote: > > there is a cheap way of locking something > > globally used for ages: the *creation* of a special "lock" file > > just before entering the critical section (if it is absent, > > otherwise sleep/wait), and the destruction after. > Is there not a small risk that in the time between some process finding > that the lock file doesn't exist and creating this file, another process > might also find that the lock file doesn't exist, thereby breaking the > exclusivity mechanism. Under Unix (this stuff is OS dependent, making it difficult to abstract away in a high level language), opening a file is an atomic operation. If you are programming in C, you can set the flags during open to create a file if and only if it does not already exist, making it a very expensive but fully functional TestAndSet instruction (basic primitive needed to implement semaphores). However, there does not appear to be a way to get at this mechanism from Icon itself. -- Nevin ":-)" Liber nevin@CS.Arizona.EDU (520) 293-2799 http://www.cs.arizona.edu/people/nevin/ From icon-group-sender Tue Jun 18 11:15:06 1996 Received: by cheltenham.cs.arizona.edu; Tue, 18 Jun 1996 13:13:27 MST Message-Id: <199606181615.MAA06057@po_box.cig.mot.com> Date: Tue, 18 Jun 1996 11:15:06 -0500 From: Tony J Yeates In-Reply-To: Hamish Lawson "Re: Locking files" (Jun 18, 1:11pm) References: <9606140653.AA00140@canardo.unicaen.fr> <199606181601.MAA05191@po_box.cig.mot.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: Hamish Lawson , icon-group@cs.arizona.edu Subject: Re: Locking files Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Errors-To: icon-group-errors@cs.arizona.edu Status: O On Jun 18, 1:11pm, Hamish Lawson wrote: > Subject: Re: Locking files > Jerzy Karczmarczuk wrote: > > > there is a cheap way of locking something > > globally used for ages: the *creation* of a special "lock" file > > just before entering the critical section (if it is absent, > > otherwise sleep/wait), and the destruction after. > > Is there not a small risk that in the time between some process finding > that the lock file doesn't exist and creating this file, another process > might also find that the lock file doesn't exist, thereby breaking the > exclusivity mechanism. > > | Hamish Lawson, School of Computing and Mathematics, > | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA > | Tel: +44 1642 212695 Fax: +44 1642 342604 > | E-mail: H.Lawson@tees.ac.uk > >-- End of excerpt from Hamish Lawson Hopefully the OS would enforce: 1) uniqueness of a filename within a directory (normal but nes. true for all conceivable OS's I guess) 2) atomic file creation. From icon-group-sender Tue Jun 18 16:48:11 1996 Received: by cheltenham.cs.arizona.edu; Tue, 18 Jun 1996 16:20:23 MST Date: Tue, 18 Jun 96 16:48:11 CDT From: yak@comm.mot.com (Yarko Tymciurak) Message-Id: <9606182148.AA03199@platov8> To: H.Lawson@tees.ac.uk, icon-group@cs.arizona.edu Subject: Re: Locking files Errors-To: icon-group-errors@cs.arizona.edu Status: O | Date: Tue, 18 Jun 1996 13:11:43 +0100 | From: Hamish Lawson | To: icon-group@cs.arizona.edu | Subject: Re: Locking files | | Jerzy Karczmarczuk wrote: | | > there is a cheap way of locking something | > globally used for ages: the *creation* of a special "lock" file | > just before entering the critical section (if it is absent, | > otherwise sleep/wait), and the destruction after. | | Is there not a small risk that in the time between some process finding | that the lock file doesn't exist and creating this file, another process | might also find that the lock file doesn't exist, thereby breaking the | exclusivity mechanism. The lock "file" without this problem on UNIX is a directory - its creation is guarenteed to be autonomous. | | | Hamish Lawson, School of Computing and Mathematics, | | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | | Tel: +44 1642 212695 Fax: +44 1642 342604 | | E-mail: H.Lawson@tees.ac.uk | Yarko Tymciurak Motorola iDEN Group From icon-group-sender Sat Jun 22 06:25:58 1996 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jun 1996 08:30:17 MST Date: Sat, 22 Jun 1996 06:25:58 -0700 From: Ralph Griswold Message-Id: <9606221325.AA26435@ursus.cs.arizona.edu> To: icon-group Subject: New Edition of the Icon Book Errors-To: icon-group-errors@cs.arizona.edu Status: O We are preparing the third edition of the book The Icon Programming Language. This edition will be published by Peer-to-Peer Communications, a company that specializes in books related to computers. The new edition will describe Version 9 of Icon. In addition to covering features that have been added to Icon since Version 8 (which the second edition covered), the new edition will contain new chapters on procedure libraries, debugging, and an overview of graphics. (The forthcoming book on graphics programming in Icon will contain a complete description of Icon's graphic facilities.) There also will be new material on programming techniques, new appendices, and new program examples. The third edition of the Icon book is scheduled for publication in October at a price of $34.95. For more information about Peer-to-Peer Communications, visit their Web site: http://www.peer-to-peer.com/ This notice is being posted on our Web site, along with an image of the cover for the new edition. Visit http://www.cs.arizona.edu/icon/ and follow the link to Third Edition of the Icon Language Book in the Documentation section. 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 Wed Jun 26 18:58:57 1996 Received: by cheltenham.cs.arizona.edu; Wed, 26 Jun 1996 16:33:05 MST To: icon-group@cs.arizona.edu Date: 26 Jun 1996 18:58:57 GMT From: corre@alpha1.csd.uwm.edu (Alan D Corre) Message-Id: <4qs19h$1r@uwm.edu> Organization: Information & Media Technologies, University of Wisconsin - Milwaukee Sender: icon-group-request@cs.arizona.edu Subject: calendar Errors-To: icon-group-errors@cs.arizona.edu Status: O Some years ago, I placed on the Icon programming language newsgroup the code for a "Visually Equivalent Jewish/Civil Calendar." I have now rewritten this for HTML, and placed it on the World Wide Web. You can try it at: http://www.uwm.edu/cgi-bin/corre/calendar I was quite surprised how quickly I was able to emend the code. Of course, I had been thinking about it for several days, but it only took me a couple of hours when I sat down. Icon is nice for this kind of thing. Most of the work was subtraction -- you don't need to bother about all that screen control stuff, and gobbledegook ANSI escape codes become meaningful tags. The browsers take care of so much. Any comments on the calendar will be appreciated before I try to announce it to a larger audience. -- Alan D. Corre Emeritus Professor of Hebrew Studies University of Wisconsin-Milwaukee From icon-group-sender Fri Jun 28 16:29:04 1996 Received: by cheltenham.cs.arizona.edu; Fri, 28 Jun 1996 12:34:35 MST Message-Id: <31D3FA40.1435@tees.ac.uk> Date: Fri, 28 Jun 1996 16:29:04 +0100 From: Hamish Lawson Organization: University of Teesside X-Mailer: Mozilla 3.0b4Gold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Ordered tables References: <9606221325.AA26435@ursus.cs.arizona.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O I'd like to be able to obtain the keys of a table in the order of their creation (key() produces them in random order). Is there a way to do this? Failing that, what is the best way to go about implementing a data structure in Icon that is both indexed and ordered? | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Fri Jun 28 11:14:04 1996 Received: by cheltenham.cs.arizona.edu; Fri, 28 Jun 1996 12:34:53 MST Date: Fri, 28 Jun 1996 11:14:04 -0700 From: Ralph Griswold Message-Id: <9606281814.AA06113@ursus.cs.arizona.edu> To: icon-group Subject: Book Sale Errors-To: icon-group-errors@cs.arizona.edu Status: O We need to make room for the third edition of the Icon language book and must clear out our remaining stock of the second edition. The publisher's closing price for the second edition was $41 (although we lowered our price to make the book more affordable). While our stock lasts, we're offering copies of the second edition for $18 and we'll include at no extra cost technical reports describing Version 9 and Icon's graphics facilities. Shipping by parcel post to addresses in the United States, Canada, and Mexico is included in the price. Overseas shipping, by air parcel post is $16. (This says something about the relative costs of goods and transportation, but there's nothing we can do about it, subtracting the typical cost of delivery in the United States, which we have done.) If you're asking yourself why you should buy the second edition of the book when the third is in the works, here are some reasons: o The package we offer contains all the information about Version 9 of Icon and a complete reference to graphics, which will not be included in the third edition. o There are program examples and exercises in the second edition that will not be in the third edition. o The price is right. If you've been interested in Icon but reluctant to pay the former price, here's a chance to get on board. And even if you plan to buy the third edition when it comes out, you may find use for copies of the second edition -- the book makes a nice gift for someone you want to interest in Icon. The second edition no longer is available from the publisher. As far as we know, we have the only remaining stock. When it's gone, there will be no more. Important note: The third edition will not be available in time for fall classes. If you're planning to use Icon in a class this fall, you should order books from us promptly. To place orders contact the Icon Project: Icon Project Department of Computer Science The University of Arizona P.O. Box 210077 Tucson, Arizona 85721-0077 U.S.A. voice: (520) 621-6613 fax: (520) 621-4246 e-mail: icon-orders@cs.arizona.edu Mention "Book Sale" when ordering. From icon-group-sender Fri Jun 28 15:06:42 1996 Received: by cheltenham.cs.arizona.edu; Fri, 28 Jun 1996 16:27:27 MST Date: Fri, 28 Jun 1996 15:06:42 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <199606282006.PAA10115@coyote25.cs.utsa.edu> To: H.Lawson@tees.ac.uk Cc: icon-group@cs.arizona.edu In-Reply-To: <31D3FA40.1435@tees.ac.uk> (message from Hamish Lawson on Fri, 28 Jun 1996 16:29:04 +0100) Subject: Re: Ordered tables Content-Length: 0 Errors-To: icon-group-errors@cs.arizona.edu Status: O [Hamish Lawson writes:] I'd like to be able to obtain the keys of a table in the order of their creation (key() produces them in random order). Is there a way to do this? No, there is no timestamp or ordering information for elements within tables. Failing that, what is the best way to go about implementing a data structure in Icon that is both indexed and ordered? The easiest way is to maintain a list and table in tandem; when you insert into the table, put into the list at the same time. The Idol technical report has an example class (tabular queue, or taque) that does this, but you can do it by hand in Icon just fine. Clint Jeffery jeffery@ringer.cs.utsa.edu Division of Computer Science The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Sat Jun 29 10:41:11 1996 Received: by cheltenham.cs.arizona.edu; Mon, 1 Jul 1996 08:32:45 MST Date: Sat, 29 Jun 1996 10:41:11 +0200 From: karczma@calvin.info.unicaen.fr (Jerzy Karczmarczuk) Message-Id: <9606290841.AA03532@canardo.unicaen.fr> To: icon-group@cs.arizona.edu Subject: Re: Ordered tables X-Sun-Charset: US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O > From: Hamish Lawson > > I'd like to be able to obtain the keys of a table in the order of their > creation (key() produces them in random order). Is there a way to do > this? Failing that, what is the best way to go about implementing a data > structure in Icon that is both indexed and ordered? > > | Hamish Lawson, School of Computing and Mathematics, Clinton Jeffery answered already. Hashed tables are popular for their efficiency, and overloading them with extra ordering info seems - in general - rather inefficient. So, Clint proposes a mirror list which keeps track of the creation time ordering. There is another possibility - store with each key not the bare item, but the pair [item, ord_index], eventually pair with the item a link to the predecessor/ successor (or both) key(s). The memory overhead seems worse than in the proposal of CJ, but you can do it selectively. Jerzy Karczmarczuk Comp. Sci., University of Caen, France. From icon-group-sender Mon Jul 1 11:35:03 1996 Received: by cheltenham.cs.arizona.edu; Mon, 1 Jul 1996 13:30:56 MST Date: Mon, 1 Jul 1996 11:35:03 -0700 Message-Id: <199607011835.LAA22246@dfw-ix9.ix.netcom.com> X-Sender: bobalex@popd.ix.netcom.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: Bob Alexander Subject: Re: Ordered tables Errors-To: icon-group-errors@cs.arizona.edu Status: O Just to add another thought (this is how I *think* things work, but I didn't try it): Sorting is done first by data type, then by order within type. Structure-types like records and lists are sorted in order of their creation (see p77,78 in the "red" Icon book). So... if you envelope all of the table's values in the same type of record, then sort the table using one of the "sort-values-not-keys" options, you can access the keys in creation-time order. -- Bob From icon-group-sender Thu Jul 4 16:38:09 1996 Received: by cheltenham.cs.arizona.edu; Fri, 5 Jul 1996 08:30:53 MST To: icon-group@cs.arizona.edu Date: 4 Jul 1996 16:38:09 -0700 From: icon-project@cs.arizona.edu Message-Id: <4rhkl1$g4@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 Status: O Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language Last updated: February 16, 1996 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 UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and the Acorn Archimedes. There are older versions for the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, 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? 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, and runs on UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and Acorn Archimedes. Other implementations presently are at Version 8. Almost all programs that run under Version 8 and that do not use graphics will run under Version 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 support Icon's graphics facilities are in beta testing. 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), postal money order, or check drawn on a bank with a branch in the United States and made payable to The University of Arizona. Icon is available on CD-ROM from Prime Time Freeware (http://www.ptf.com/, 408-433-9662). Contact them for details. 11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, second edition, 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. 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 subscription 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, revenue from the sale of program material and documentation, and user contributions. 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 updated only 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 twice a year. There also is a subscription service for updates to the Icon program library, which provides new material about twice 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? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please 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. 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 Sun Jul 7 14:05:22 1996 Received: by cheltenham.cs.arizona.edu; Mon, 8 Jul 1996 08:30:09 MST From: Michael Edward Maul Message-Id: <199607071805.AA06614@cms.uncwil.edu> Subject: loadfunc working w/linux-elf To: icon-group@cs.arizona.edu Date: Sun, 7 Jul 1996 14:05:22 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1792 Errors-To: icon-group-errors@cs.arizona.edu Status: O Linux and Icon users rejoice you can now use loadfunc!!! Sinces the Linux's move to ELF it is now possible to use loadfunc to load c library functions dynamically. Cool huh? To do this simple comple iconx with -rdynamic -ldl linking options...Also add #define LoadFunc to define.h in the config/unix/i386_linux. Basically that is all there is... Well mabey a little more, All files that you are compiled into the library you intend to make must be compiled with -fPIC Finally when building you library you can link with gcc -shared -o Of course I made a patchfile that you can use..instead it sets up changes to the Icon source config and also gets all the samples and tests in shape to compile... I'm not sure where I'm gong to up load this to yet, but some places to try initally are: sol.cms.uncwil.edu/Incomming cs.arizona.edu/Incomming From there it should migrate to icon/contrib on both sites. If you want more information on the Linux implementation of ELF, check out H.J. Lu's ELF:From the Programmers Perspective at tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz By the way currently I am working on creating an interface to MetalBase database. If anyone is interested in it, email me if I get enough intrest I'll put on the ftp sites.... Mike Maul maul@sol.cms.uncwil.edu -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mike Maul | Intrests/hobbies: hacking (is there really CS major (senior) | any thing else) UNC-Wilmington | Like what you see? ........Offer me a job! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E-Mail: maul@sol.cms.uncwil.edu WWW: http://www.cms.uncwil.edu/~maul .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. From icon-group-sender Tue Jul 9 15:08:29 1996 Received: by cheltenham.cs.arizona.edu; Tue, 9 Jul 1996 16:45:18 MST Sender: david@ba.msi.com Message-Id: <31E2D85D.41C6@ba.msi.com> Date: Tue, 09 Jul 1996 15:08:29 -0700 From: "David S. Harrison" Organization: Molecular Simulations X-Mailer: Mozilla 3.0b4 (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Cc: david@ba.msi.com Subject: vidget programming Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O I am playing around with VIB. It seems to work fine. However, maybe I am missing something simple. I can't seem to find any documentation about the vidget programming interface. Is there a document floating around describing the functions for modifying vidgets at runtime? -- David Harrison, Molecular Simulations (david@ba.msi.com) From icon-group-sender Tue Jul 9 20:41:09 1996 Received: by cheltenham.cs.arizona.edu; Wed, 10 Jul 1996 07:48:36 MST Date: Tue, 9 Jul 1996 20:41:09 -0600 (CST) From: Luis M Ibarra X-Sender: mibarra@laplace To: "David S. Harrison" Cc: icon-group@cs.arizona.edu, david@ba.msi.com Subject: Re: vidget programming In-Reply-To: <31E2D85D.41C6@ba.msi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O > I am playing around with VIB. It seems to work fine. However, > maybe I am missing something simple. I can't seem to find any > documentation about the vidget programming interface. Is there > a document floating around describing the functions for modifying > vidgets at runtime? I haven't see any docs either. But you may be able to get some info right from the vidgets code, why don't you look at ipl/gprocs/*.icn? (tought I haven't see that either :) :) ). -- Luis M. Ibarra UNAM, DGAE. From icon-group-sender Wed Jul 10 08:10:46 1996 Received: by cheltenham.cs.arizona.edu; Wed, 10 Jul 1996 08:22:56 MST Date: Wed, 10 Jul 1996 08:10:46 -0700 From: Ralph Griswold Message-Id: <9607101510.AA10081@ursus.cs.arizona.edu> To: david@ba.msi.com, mibarra@galois.dgaesc.unam.mx Subject: Re: vidget programming Cc: cliff, gmt, icon-group@cs.arizona.edu, jeffery@dragon.cs.utsa.edu Errors-To: icon-group-errors@cs.arizona.edu Status: O You cannot easily (feasibly) manipulate vidgets in a VIB-produced interface. The vidgets themselves are difficult to use and modify. There is documentation, but it is not up to date and probably would be more hindrance than help. We do not support the vidgets per-se and cannot provide techincal support for them. 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 Wed Jul 10 10:11:45 1996 Received: by cheltenham.cs.arizona.edu; Wed, 10 Jul 1996 12:27:27 MST From: "David Harrison" Message-Id: <9607101011.ZM11176@byrd.ba.msi.com> Date: Wed, 10 Jul 1996 10:11:45 -0700 In-Reply-To: Ralph Griswold "Re: vidget programming" (Jul 10, 8:10am) References: <9607101510.AA10081@ursus.cs.arizona.edu> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Ralph Griswold Subject: Re: vidget programming Cc: icon-group@cs.arizona.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Errors-To: icon-group-errors@cs.arizona.edu Status: O On Jul 10, 8:10am, Ralph Griswold wrote: > Subject: Re: vidget programming > You cannot easily (feasibly) manipulate vidgets in a VIB-produced > interface. > > The vidgets themselves are difficult to use and modify. There is > documentation, but it is not up to date and probably would be more > hindrance than help. > > We do not support the vidgets per-se and cannot provide techincal > support for them. Maybe my question was too general. I don't intend to change fundamental aspects of a vidget at runtime (i.e., geometry or the number of vidgets). I want to change things like the minimum/maximum/spot of a scroll bar or the text displayed by an edit text vidget. I assume this must be possible. A scroll bar is not very useful if you can't change its minimum/maximum values when the information inside the controlled space changes. After further investigation, I noticed that the vidget source is in the Icon Programming Library. I think I will poke around there and see if I can discover the common vidget programming idioms. >From the tone of your message, I detect a slight distaste for vidgets. Out of curiousity, is the Icon group working on a new interface for doing graphic interfaces? -- David Harrison, Molecular Simulations (david@ba.msi.com) From icon-group-sender Thu Jul 11 13:06:27 1996 Date: Thu, 11 Jul 1996 13:06:27 MST From: icon-group-sender Message-Id: <199607112006.AA10303@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Thu, 11 Jul 1996 13:06:27 MST Errors-To: icon-group-errors@cs.arizona.edu Apparently-To: icon-group-addresses Status: O already) completely locks the color palette, so I can't build my image, unless I use the precise same palette. The only `solution' I've found is to process the image for what it is: a stream of numeric data, not to be loaded in memory as an image for any reason---ludicrous. Unless I've missed something, I think that some better facility for handling color bitmaps would be needed. I don't know, the ability to declare explicit color palettes, and some simple color-mapping algorithm for CopyArea between `incompatible' bitmaps would be nice. I believe that most of the facility is already present---considering color palettes---the ability to have user defined palettes would be crucial. -- [nosave] microsoft network is EXPLICITLY forbidden to redistribute this message. `Seiza no matataki kazoe, uranau koi no yuku e.' Marc Espie (Marc.Espie@ens.fr) From icon-group-sender Thu Jul 11 13:15:59 1996 Received: by cheltenham.cs.arizona.edu; Thu, 11 Jul 1996 13:06:18 MST To: icon-group@cs.arizona.edu Date: 11 Jul 1996 13:15:59 GMT From: espie@chaland.ens.fr (Marc Espie) Message-Id: <4s2uqf$6q2@nef.ens.fr> Organization: Ecole Normale Superieure, Paris Sender: icon-group-request@cs.arizona.edu Subject: Multiple color palettes under X-Icon ? Errors-To: icon-group-errors@cs.arizona.edu Status: O I've been trying to play with algorithms for color palette reduction in Icon. It seems I've run into unsurmountable problems, at least under the current implementation. Correct me if I'm wrong, but it seems that Icon uses just one color palette for all the windows. This may sound reasonable, but it seems that Icon pushes it too far: namely, it uses the same color palette for off-screen images as well. Assuming you want to play with digitized images, this is not good. What I want to do is to read a digitized image, for which WOpen("canvas=hidden", "image=xxx") looks perfect, build an histogram of the pixel values using Pixel(), process what I've got with standard algorithm, and build a modified image on-screen. From icon-group-sender Fri Jul 12 10:39:25 1996 Received: by cheltenham.cs.arizona.edu; Fri, 12 Jul 1996 13:11:09 MST Date: Fri, 12 Jul 1996 10:39:25 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <199607121539.KAA21045@coyote25.cs.utsa.edu> To: espie@chaland.ens.fr Cc: icon-group@cs.arizona.edu In-Reply-To: <4s2uqf$6q2@nef.ens.fr> (espie@chaland.ens.fr) Subject: Re: Multiple color palettes under X-Icon ? Content-Length: 1307 Errors-To: icon-group-errors@cs.arizona.edu Status: O [Marc Espie writes:] > Correct me if I'm wrong, but it seems that Icon uses just one color palette > for all the windows. This may sound reasonable, but it seems that Icon > pushes it too far: namely, it uses the same color palette for off-screen > images as well. > Assuming you want to play with digitized images, this is not good. You are correct that Icon allocates at most a single X Colormap per instance of iconx that runs. I say "at most" because Icon tries not to allocate a private colormap at all, and only does so if it can't allocate colors from the system colormap; the visual appearance of applications with separate colormaps under X is somewhat nauseating. A one-colormap per window policy would be implementable, but might not be desirable for most applications. Doing separate colormaps just for hidden (off-screen) canvases would be implementable, but off-screen canvases can become visible on-screen canvases and vice-versa. Our primary Icon image processing guru is Gregg Townsend; he may contact you privately after he sees your message, or post to the group if he has some more information of general interest. Clint Jeffery jeffery@ringer.cs.utsa.edu Division of Computer Science The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Thu Jul 18 22:31:16 1996 Received: by cheltenham.cs.arizona.edu; Fri, 19 Jul 1996 17:02:31 MST Date: Thu, 18 Jul 96 22:31:16 PDT From: escargo@skypoint.com Subject: Icon 9.0/386 To: icon-group@cs.arizona.edu X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O I am doing some minor development using Icon 9.0 for the 386, using the Windows memory extender. I was trying to discover why my include files weren't including and my link files not linking. I discovered that there is something about how LPATH and IPATH are treated that seems to make a difference. I thought I would be able to do something like this: set ipath="e:\icon\gprocs e:\icon\procs" set lpath="e:\icon\gincl e:\icon\incl" That didn't work. For the include files, I just copied them into the source directories. For the links, though, that was more than I wanted to do. I experimented with different values for ipath. What eventually worked was: set ipath="..\procs" As long as the path was relative, it seemed to work, but if it was e:\icon\procs or \icon\procs it would not. Did I overlook something in the documentation, or is it not supposed to work quite this way? ------------------------------------- Name: David S. Cargo E-mail: escargo@skypoint.com From icon-group-sender Fri Jul 19 16:43:44 1996 Received: by cheltenham.cs.arizona.edu; Fri, 19 Jul 1996 17:03:05 MST Date: Fri, 19 Jul 1996 16:43:44 -0500 (GMT-0500) From: Robotica Experimental To: icon-group@cs.arizona.edu Subject: How can I run tasks using Icon? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O The complete question is: How can I have more than one task running at the same time using Icon on a Linux operating system? TASK: A icon program or procedure. Note: Each task have to communicate with each other. thanks... Andres Buss From icon-group-sender Fri Jul 19 22:22:50 1996 Received: by cheltenham.cs.arizona.edu; Sun, 21 Jul 1996 13:56:49 MST Date: Fri, 19 Jul 96 22:22:50 PDT From: escargo@skypoint.com Subject: Icon 9.0/386 To: icon-group@cs.arizona.edu X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O As a followup of my previous message, I did some more experimenting. If I use the following set lpath="..\procs" then linking does NOT work. If I use set lpath=..\procs then linking DOES work. Curiouser and curiouser. ------------------------------------- Name: David S. Cargo E-mail: escargo@skypoint.com From icon-group-sender Thu Jul 25 05:54:14 1996 Received: by cheltenham.cs.arizona.edu; Thu, 25 Jul 1996 05:55:03 MST Date: Thu, 25 Jul 1996 05:54:14 -0700 From: Ralph Griswold Message-Id: <9607251254.AA12471@ursus.cs.arizona.edu> To: icon-group Subject: Forwarded mail Errors-To: icon-group-errors@cs.arizona.edu Status: O From: ldorfman@li.net (Len Dorfman) Subject: Opportunity: Icon Expert Date: Sun, 07 Jul 1996 18:33:59 GMT Organization: Manning Publications Message-ID: <31e002fb.26818479@newshost.li.net> Reply-To: ldorfman@li.net Manning Publications (Manning/Prentice-Hall PTR Imprint) is interested in publishing a series of short books on programming languages. If you are interested in writing a title on Icon, please feel free to get in touch. with metta, Len ldorfman@li.net __________________________________________________________________ Leonard Dorfman, Ph.D., Senior Editor Manning Publications Co., 3 Lewis Street, Greenwich, CT 06830 E-mail: ldorfman@li.net Voice: 516.331.2915 Fax: fax 203.661.9018 __________________________________________________________________ From icon-group-sender Sat Jul 27 06:11:41 1996 Received: by cheltenham.cs.arizona.edu; Sat, 27 Jul 1996 06:13:24 MST Date: Sat, 27 Jul 1996 06:11:41 -0700 From: Ralph Griswold Message-Id: <9607271311.AA17857@ursus.cs.arizona.edu> To: icon-group Subject: Icon Newsletter 50 Errors-To: icon-group-errors@cs.arizona.edu Status: O Icon Newsletter 50 is now available on the Icon Web site: http://www.cs.arizona.edu/icon/ Under the Documentation section, follow the link to The Icon Newsletter and then to Icon Newsletter 50. From icon-group-sender Mon Jul 29 16:59:26 1996 Received: by cheltenham.cs.arizona.edu; Mon, 29 Jul 1996 11:17:11 MST Message-Id: <31FCDFDE.5814@tees.ac.uk> Date: Mon, 29 Jul 1996 16:59:26 +0100 From: Hamish Lawson Organization: University of Teesside X-Mailer: Mozilla 3.0b5aGold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: What is the value of a valueless return? References: <9606221325.AA26435@ursus.cs.arizona.edu> <31D3FA40.1435@tees.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Given a procedure p() that terminates with a valueless return statement, what value is assigned to x when x := p() is evaluated? assuming that x was null prior to the assignment, is there any way to test subsequently whether the assignment succeeded? | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Mon Jul 29 15:54:02 1996 Received: by cheltenham.cs.arizona.edu; Mon, 29 Jul 1996 11:17:01 MST Message-Id: <31FCD08A.55DC@tees.ac.uk> Date: Mon, 29 Jul 1996 15:54:02 +0100 From: Hamish Lawson Organization: University of Teesside X-Mailer: Mozilla 3.0b5aGold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Optional expressions References: <9606221325.AA26435@ursus.cs.arizona.edu> <31D3FA40.1435@tees.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O What is the Icon idiom for making one of a series of conjoined expressions optional? Let's say I have the following series of expressions e1 & e2 & e3 & e4 and I want e3 to be evaluated if possible but not to cause the failure of the enclosing expression. In a string scanning context I've resorted to e1 & e2 & e3 | move(0) & e4 but this feels kind of ugly to me. | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Mon Jul 29 17:04:44 1996 Received: by cheltenham.cs.arizona.edu; Mon, 29 Jul 1996 11:17:39 MST Message-Id: <31FCE11C.1C7E@tees.ac.uk> Date: Mon, 29 Jul 1996 17:04:44 +0100 From: Hamish Lawson Organization: University of Teesside X-Mailer: Mozilla 3.0b5aGold (Win95; I) Mime-Version: 1.0 To: icon-group@cs.arizona.edu Subject: Preserving success/failure across disjoint expressions References: <9606221325.AA26435@ursus.cs.arizona.edu> <31D3FA40.1435@tees.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@cs.arizona.edu Status: O Suppose that I evaluate some expression, then later in the program I want to evaluate some other expression but only of the earlier one succeeded. What is the most idiomatic way of doing this in Icon? I've done something along the lines below, but I'm just a little uncomfortable with the arbitrariness of the assignment to succeeded. e1 & succeeded := 1 ... if \succeeded then e2 | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 212695 Fax: +44 1642 342604 | E-mail: H.Lawson@tees.ac.uk From icon-group-sender Tue Jul 30 08:34:09 1996 Received: by cheltenham.cs.arizona.edu; Tue, 30 Jul 1996 14:20:04 MST Date: Tue, 30 Jul 1996 08:34:09 -0700 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <199607301534.IAA07013@varda.premenos.com> To: icon-group@cs.arizona.edu, H.Lawson@tees.ac.uk Subject: Re: Optional expressions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: T/Q2/7fIM5nixKZOQBDrFA== Errors-To: icon-group-errors@cs.arizona.edu Status: O > Date: Mon, 29 Jul 1996 15:54:02 +0100 > From: Hamish Lawson > > What is the Icon idiom for making one of a series of conjoined > expressions optional? Let's say I have the following series of > expressions > > e1 & e2 & e3 & e4 > > and I want e3 to be evaluated if possible but not to cause the failure > of the enclosing expression. You can do e1 & e2 & (e3; e4) e3 is evaluated but regardless of whether is succeeds or fails, e4 is always evaluated and e4 determines whether (e3; e4) succeeds or fails. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Sun Aug 4 19:04:03 1996 Received: by cheltenham.cs.arizona.edu; Mon, 5 Aug 1996 07:12:08 MST To: icon-group@cs.arizona.edu Date: 4 Aug 1996 19:04:03 GMT From: russell@nntp1.best.com (Jeff Harrington) Message-Id: <4u2s73$pcc@nntp1.best.com> Organization: Best Internet Communications Sender: icon-group-request@cs.arizona.edu Subject: CGI Library in Icon Errors-To: icon-group-errors@cs.arizona.edu Status: O I'm being encouraged to abandon Perl and was wondering if anybody had developed such a thing. My thinking is that by using iconc and generating compiled programs I'll get the performance advantage of C plus the elegance of Icon. Thanks... Jeff Harrington "Art does not make peace... jeff@parnasse.com That is not its business... http://www.parnasse.com Art is peace." -- Robert Lowell From icon-group-sender Sun Aug 4 21:47:53 1996 Received: by cheltenham.cs.arizona.edu; Mon, 5 Aug 1996 07:12:20 MST To: icon-group@cs.arizona.edu Date: 4 Aug 1996 21:47:53 GMT From: john@nmt.edu (John Shipman) Message-Id: <4u35q9$55g@newshost.nmt.edu> Organization: New Mexico Tech Computer Center Sender: icon-group-request@cs.arizona.edu References: <4u2s73$pcc@nntp1.best.com> Subject: Re: CGI Library in Icon Errors-To: icon-group-errors@cs.arizona.edu Status: O Jeff Harrington wrote: +-- | I'm being encouraged to abandon Perl and was wondering if anybody had | developed such a thing. My thinking is that by using iconc and generating | compiled programs I'll get the performance advantage of C plus the | elegance of Icon. +-- I have written a small set of Icon functions to assist in writing CGI handlers for Web pages. See this URL: http://www.nmt.edu/tcc/help/lang/icon/cgi.html The page includes working examples of both forms and non-forms CGI handlers written in Icon, with complete sources. John Shipman (john@nmt.edu), Applications Specialist, NM Tech Computer Center, Speare 19, Socorro, NM 87801, (505) 835-5950, http://www.nmt.edu/~john ``Let's go outside and commiserate with nature.'' --Dave Farber From icon-group-sender Mon Aug 5 16:29:15 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Aug 1996 07:07:37 MST To: icon-group@cs.arizona.edu Date: 5 Aug 1996 16:29:15 GMT From: russell@nntp1.best.com (Jeff Harrington) Message-Id: <4u57gr$130@nntp1.best.com> Organization: Best Internet Communications Sender: icon-group-request@cs.arizona.edu References: <4u2s73$pcc@nntp1.best.com> Subject: Re: CGI Library in Icon Errors-To: icon-group-errors@cs.arizona.edu Status: O Jeff Harrington (russell@nntp.best.com) wrote: : I'm being encouraged to abandon Perl and was wondering if anybody had : developed such a thing. My thinking is that by using iconc and generating : compiled programs I'll get the performance advantage of C plus the : elegance of Icon. Just to comment about dropping Perl; perl requires the loading and unloading of an interpreter for every process. If your site gets over 200,000 visits a day this is just unmanageable; most programmers at these types of sites use C/C++. Some servers do allow you to maintain the Perl interpreter in memory, but I still think a compiled Icon or C executable would give superior performance. I was getting ready to port my Eliza WWW program back to C when I started thinking.... (http://www.parnasse.com/drwww.shtml) Jeff Harrington "Art does not make peace... jeff@parnasse.com That is not its business... http://www.parnasse.com Art is peace." -- Robert Lowell From icon-group-sender Mon Aug 5 09:25:05 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Aug 1996 07:07:26 MST Date: Mon, 5 Aug 1996 09:25:05 -0500 (CDT) From: "Chris D. Tenaglia" To: Jeff Harrington Cc: icon-group@cs.arizona.edu Subject: Re: CGI Library in Icon In-Reply-To: <4u2s73$pcc@nntp1.best.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O I've been pushed in the opposite direction. I'm looking for icon cgi examples to wow others as to the power, and clarity of icon in a very visible way. I'm getting closer to understanding the process, but I find myself short of time to sink into getting over the hump. 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 ! On 4 Aug 1996, Jeff Harrington wrote: > Date: 4 Aug 1996 19:04:03 GMT > From: Jeff Harrington > To: icon-group@cs.arizona.edu > Subject: CGI Library in Icon > > I'm being encouraged to abandon Perl and was wondering if anybody had > developed such a thing. My thinking is that by using iconc and generating > compiled programs I'll get the performance advantage of C plus the > elegance of Icon. > > Thanks... > > Jeff Harrington "Art does not make peace... > jeff@parnasse.com That is not its business... > http://www.parnasse.com Art is peace." -- Robert Lowell > > > > From icon-group-sender Mon Aug 5 13:58:05 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Aug 1996 07:07:51 MST To: icon-group@cs.arizona.edu Date: Mon, 05 Aug 1996 13:58:05 -0700 From: Mark Emmer Message-Id: <3206605D.4019@rmii.com> Organization: Catspaw, Inc. Sender: icon-group-request@cs.arizona.edu References: <31FB6073.12AB@eden.com>, <4tev3h$2f6@mulga.cs.mu.OZ.AU>, <4to8ea$r91@mulga.cs.mu.OZ.AU> Subject: SNOBOL4 mail list Errors-To: icon-group-errors@cs.arizona.edu Status: O For those who remember, care about, or still use the SNOBOL4 programming language, a mail listserver has been established. To join the list, send a mail message to "listserv@mercury.dsu.edu" with the line "subscribe SNOBOL4 Your Name" as the message body. "Your Name" should be your real name (your e-mail address will be used automatically for the subscription). Submissions to the list may be sent to "SNOBOL4@mercury.dsu.edu". To be removed from the list, send the message "unsubscribe SNOBOL4" to "listserv@mercury.dsu.edu". Mark Emmer From icon-group-sender Tue Aug 6 15:25:19 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Aug 1996 07:08:08 MST Message-Id: <199608062035.AA14689@optima.cs.arizona.edu> Date: Tue, 06 Aug 96 15:25:19 CDT From: Roger Sorrells Subject: dos system call To: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: O when I include the lines system("set") #1 system("set x=y") #2 system("set") #3 in a program, I get the same output from #3 as from #1, no additional X=y among the environment variables. How do I set DOS environment variables from within an Icon program? I am using MS-DOS 6.21 and Icon 8.10 From icon-group-sender Wed Aug 7 10:56:09 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Aug 1996 13:28:49 MST Date: Wed, 7 Aug 1996 10:56:09 -0400 (EDT) From: "Phillip L. Thomas" To: Roger Sorrells Cc: icon-group@cs.arizona.edu Subject: Re: dos system call In-Reply-To: <199608062035.AA14689@optima.cs.arizona.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O I believe I asked Ralph Griswold this question a few years back and he replied that the variation of effects from making a system call were so varied that environment variables could not be set, only read. The system() call has another effect in DOS which is unfortunate: it calls up another copy of COMMAND.COM, meaning you've lost another 64K of critical memory in addition to the process you are trying to start. Most DOS C compilers have other ways (exec..) that do not invoke an addition COMMAND.COM, but this may again be C-compiler dependent. Phillip Lee Thomas On Tue, 6 Aug 1996, Roger Sorrells wrote: > when I include the lines > system("set") #1 > system("set x=y") #2 > system("set") #3 > in a program, I get the same output from #3 as from #1, > no additional X=y among the environment variables. > > How do I set DOS environment variables from within an Icon program? > I am using MS-DOS 6.21 and Icon 8.10 > > From icon-group-sender Wed Aug 7 09:34:22 1996 Received: by cheltenham.cs.arizona.edu; Wed, 7 Aug 1996 13:28:39 MST Date: Wed, 7 Aug 1996 09:34:22 -0500 Message-Id: <199608071434.JAA01511@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: dos system call To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >when I include the lines system("set") #1 system("set x=y") #2 system("set") #3 in a program, I get the same output from #3 as from #1, no additional X=y among the environment variables. >How do I set DOS environment variables from within an Icon program? I am using MS-DOS 6.21 and Icon 8.10 The answer isn't quite "you don't", but it might be, depending on what you want to actually do. Each copy of your command interpreter has its own environment variables area, and when you launch "system()" you get a new (temporary) copy... and that's the copy you're modifying in #2. When the command interpreter you're running terminates, so do the changes you've made to the environment area. If you need to change the environment variables as needed to run another subsequent program using system(), then what you should do is to build a batch file which runs SET to change the environment, then runs the target program. Note too that if you're running in a DOS shell under Windows, you might not actually have ANY available free environment space: at least some versions of Windows collapse the DOS environment to just that actually being used when they start a DOS shell. In that case, you won't be able to add ANYTHING to it, or at least not unless you delete something first that you have already there (i.e. you can have a "dummy" big item there in the beginning, which you can later scrap to give you space for the one(s) you'll be wanting to add later. Hope this helps you. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Aug 7 16:01:39 1996 Received: by cheltenham.cs.arizona.edu; Thu, 8 Aug 1996 08:31:26 MST Message-Id: <199608072101.RAA26561@po_box.cig.mot.com> Date: Wed, 7 Aug 1996 16:01:39 -0500 From: Tony J Yeates In-Reply-To: "Phillip L. Thomas" "Re: dos system call" (Aug 7, 10:56am) References: <199608072030.QAA24305@po_box.cig.mot.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: "Phillip L. Thomas" , Roger Sorrells Subject: Re: dos system call Cc: icon-group@cs.arizona.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Errors-To: icon-group-errors@cs.arizona.edu Status: O On Aug 7, 10:56am, Phillip L. Thomas wrote: > > The system() call has another effect in DOS which is unfortunate: > it calls up another copy of COMMAND.COM, meaning you've lost another > 64K of critical memory in addition to the process you are trying > to start. Most DOS C compilers have other ways (exec..) that do not > invoke an addition COMMAND.COM, but this may again be C-compiler > dependent. This does not only apply to DOS, for UNIX each system() call will also invoke a new shell (at least it does in C). -- Tony Yeates Motorola Inc, CIG Tel.: (847)-435-9803 1501 W Shure Dr. IL27-3227AR FAX: (847)-632-2867 Arlington Heights, IL 60004 USA From icon-group-sender Wed Aug 7 16:35:33 1996 Received: by cheltenham.cs.arizona.edu; Thu, 8 Aug 1996 08:31:37 MST Date: Wed, 7 Aug 1996 16:35:33 -0500 Message-Id: <199608072135.QAA03282@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Re: dos system call To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu Status: O >The system() call has another effect in DOS which is unfortunate: it calls up another copy of COMMAND.COM, meaning you've lost another 64K of critical memory in addition to the process you are trying to start. Actually, no. If you bring up the MEM /C command you'll see that COMMAND.COM takes up a LOT less than 64K... on one of my machines here, COMMAND.COM actually uses 4.736 bytes of conventional (and no upper) memory. So it uses some memory for the extra command shell, but nowhere near 64K worth. >Most DOS C compilers have other ways (exec..) that do not invoke an addition COMMAND.COM, but this may again be C-compiler dependent. That's another option too, although generally that option doesn't let you bring up batch files or shell internal commands, and also generally doesn't search the path for the executable. At least that's typical behavior on MS-DOS systems. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Aug 8 15:16:35 1996 Received: by cheltenham.cs.arizona.edu; Thu, 8 Aug 1996 16:27:25 MST Date: Thu, 8 Aug 1996 15:16:35 -0500 (CDT) From: "Chris D. Tenaglia" To: icon-group@cs.arizona.edu Subject: CGI Tips Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O I'm trying a CGI-SCRIPT in icon. I read some information but I can't quite get mine to work. I think I'm close, but missing some small detail. Here's the scenario... I have an account cdt. Under the home directory is a www directory where I keep my HTMLs, and that works just fine. Also under the home directory I have a cgi-bin directory. I keep the cgi scripts in there. I have one, it's an icon program, httphone. It takes a parameter like: httphone name=fred and returns HTML results to stdout. It also logs it's activity to a log file. It works interactively. I borrowed and modified some other form to send the query. Netscape shows it : http://www.mcw.edu/~cdt/cgi-bin/httphone?name=fred and returns one of those 404 messages about URL not found. The log file indicates no activity. Am I real close and just need a tip? or do I need to dig into a good book or web site for the technical details. Thanx in advance! 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 Thu Aug 8 21:45:53 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Aug 1996 07:46:34 MST Date: Thu, 8 Aug 96 21:45:53 CDT From: yak@comm.mot.com (Yarko Tymciurak) Message-Id: <9608090245.AA06361@platov8> To: X041RS@tamvm1.tamu.edu, icon-group@cs.arizona.edu Subject: Re: dos system call Errors-To: icon-group-errors@cs.arizona.edu Status: O | Errors-To: icon-group-errors@cs.arizona.edu | Date: Tue, 06 Aug 96 15:25:19 CDT | From: Roger Sorrells | Subject: dos system call | To: icon-group@cs.arizona.edu | Errors-To: icon-group-errors@cs.arizona.edu | | when I include the lines | system("set") #1 | system("set x=y") #2 | system("set") #3 | in a program, I get the same output from #3 as from #1, | no additional X=y among the environment variables. | | How do I set DOS environment variables from within an Icon program? | I am using MS-DOS 6.21 and Icon 8.10 | (Now, for some totally deviant technical bable, from old brain cells, loaded a long time ago. Memory may be corrupt or out of date after a dozen years or so since last refresh... ...far more than you wanted to know...enjoy...) Actually, every process (Unix and DOS) get's it's own copy of the parent process environment (what good is setting the environment of a parent process where there are hundreds of child processes, for example?). As a process, it makes sense that you only get to change what you see, and what affects you or your children processes. When you use "SET" in DOS, you are - in effect - using a built-in shell command that sets that shell's own environment. Ergo, system("set...") only sets the environment of the running process. Under a system command, you can't even inspect with your Icon process, since "system" is a call to a new shell- a child of the calling Icon process. It get's a copy of you're Icon environment, which explains your example (each "system" call is a new process, each with its own copy of the Icon environment - which isn't changed anywhere between system calls). Icon has a getenv() function, but no corresponding setenv() as far as I recall, so you can't change the environment you pass to children this way. Now, since DOS is single tasking, and since it's process memory allocation is a simple, singly linked list (last I checked ...), it is possible (and unsupported) to change the "master" (that is, boot-shell's) environment. With pointers, you can find the memory allocation header to your process's environment, and thread (really, search) your way through lower memory until you find the master (which is different from child environment memory allocation headers in that - if I remember - the pointer to the next memory block is to lower instead of higher memory). This is REALLY goofy stuff (and fun!). The only reason I know - I put together a command that read a port and saved info on what was on that port in an environment var once upon a midnight dreary.... (Someone told me there was no way to do it, so I had to). Since memory is allocated in some finite chunks (used to be 16 bytes), you have to be careful not to overwrite other memory. The DOS environment is a contiguous byte string, and you can't ever be sure if you'll have any memory to play with at the end of an allocation chain. Therefor, you can only change existing environment variables (or overwrite space used by existing ones), and practically can't set them to anything longer than what they are already set to. If that's useful (changing characters, "a" to "b", for example).... ...it can be done (not any "simple" way I can see in Icon), but you don't want to do it! Older, and wiser (?), Yarko. From icon-group-sender Thu Aug 8 20:53:08 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Aug 1996 07:46:10 MST Date: Thu, 8 Aug 1996 20:53:08 -0300 (ADT) From: DA To: "Chris D. Tenaglia" Cc: icon-group@cs.arizona.edu Subject: Re: CGI Tips In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O On Thu, 8 Aug 1996, Chris D. Tenaglia wrote: > I'm trying a CGI-SCRIPT in icon. I read some information > but I can't quite get mine to work. I think I'm close, but > missing some small detail. Here's the scenario... > > httphone name=fred > > and returns HTML results to stdout. It also logs it's activity > to a log file. It works interactively. I borrowed and modified > some other form to send the query. Netscape shows it : > > http://www.mcw.edu/~cdt/cgi-bin/httphone?name=fred > > and returns one of those 404 messages about URL not found. > The log file indicates no activity. Am I real close and just > need a tip? or do I need to dig into a good book or web site > for the technical details. Thanx in advance! You have to ask your admin if you are allowed to run CGI scripts, and s/he will be able to tell you how to call them. By creating a subdirectory, cgi-bin, under your $HOME/public_html (or the equivalent) doesn't mean you are ready to run CGI scripts. The server has to be configured in such a way so that you can call them. Usually, the way to call a script is: http://domain/cgi-bin/scrip_name but the file script_name has to be in that directory which you may not have write permission to. The best way is to contact your admin and see if you are allowed to run CGI scripts. Regards, Qusay r to other directories in your home dir), or is it implict (so that perhaps you can refer only to things "below" your "www" directory)? -- jd From icon-group-sender Fri Aug 9 08:49:16 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Aug 1996 08:17:10 MST Date: Fri, 9 Aug 1996 08:49:16 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9608091349.AA24649@water.cs.utsa.edu> To: cdt@post.its.mcw.edu Cc: icon-group@cs.arizona.edu In-Reply-To: (cdt@post.its.mcw.edu) Subject: Re: CGI Tips Content-Length: 1194 Errors-To: icon-group-errors@cs.arizona.edu Status: O [Chris Tenaglia posted a CGI scripting question.] Well, one tip I think I have for you is that I don't think the name=fred part comes to your program as a command line argument, I think it comes via an environment variable ("name") being set to a value ("fred"). But there is something more basic you are up against before you get to that point, since your Icon program is never running. Perhaps your httphome program or your iconx interpreter isn't set to allow everyone to execute it; CGI scripts are executed by a web server process; usually its userid and permissions are different than any regular user. Or, depending on how your web server is configured, its conceivable that the iconx binary might need to be in the cgi-bin directory (that one is a long shot). Also, the "path" and environment variables (such as ICONX) you use won't be present when the web server process tries to execute your script, so you may need to give explicit paths. Lastly, if you try to do this whole CGI thing based on local files read using a web browser, it won't work; the CGI mechanism really depends on using a web server and interprocess communication, which makes it a pain to test and setup. From icon-group-sender Fri Aug 9 13:38:25 1996 Received: by cheltenham.cs.arizona.edu; Mon, 12 Aug 1996 08:17:20 MST Date: Fri, 9 Aug 1996 13:38:25 -0600 (CST) From: Luis M Ibarra X-Sender: mibarra@laplace To: "Chris D. Tenaglia" Cc: icon-group@cs.arizona.edu Subject: Re: CGI Tips In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Status: O On Thu, 8 Aug 1996, Chris D. Tenaglia wrote: > program, httphone. It takes a parameter like: > > httphone name=fred > > and returns HTML results to stdout. It also logs it's activity > to a log file. It works interactively. I borrowed and modified > some other form to send the query. Netscape shows it : > > http://www.mcw.edu/~cdt/cgi-bin/httphone?name=fred > > and returns one of those 404 messages about URL not found. > The log file indicates no activity. Am I real close and just ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The program is not being run by the httpd server. > need a tip? or do I need to dig into a good book or web site > for the technical details. Thanx in advance! This problem, is not related to icon directly. Maybe, you can found more help on a WWW group. In your shoes I would check for these problems: Maybe you need to compile de icon program insted of translating it. I mean, maybe the user id under which the httpd deamon is running can't find or can't run the iconx binary. Maybe the HTTPD server, doesn't want to run programs from /~cdt/cgi-bin/, there a clause in the httpd config file, for setting up, which dirs contains cgi programs. Depending on the method that you are using in the html form, you need to get the query string, not from the comand line parameters (POST method), but from the enviroment variable QUERY_STRING (GET method). [I'm not really sure about the way that each method sends the query string, but is something like what I've tell you]. Hope this helps. Saludos! -- Luis M. Ibarra UNAM, DGAE. From icon-group-sender Tue Aug 13 06:52:30 1996 Received: by cheltenham.cs.arizona.edu; Tue, 13 Aug 1996 16:20:36 MST Date: Tue, 13 Aug 96 14:47:15 BST Message-Id: <24851.9608131347@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: CGI Tips To: Clinton Jeffery , cdt@post.its.mcw.edu In-Reply-To: Clinton Jeffery's message of Fri, 9 Aug 1996 08:49:16 -0500 Cc: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu Status: O > [Chris Tenaglia posted a CGI scripting question.] > > Well, one tip I think I have for you is that I don't think the name=fred part > comes to your program as a command line argument, I think it comes via an > environment variable ("name") being set to a value ("fred"). That depends. There are two "methods": GET and POST. GET puts the args in the env var QUERY_STRING. POST puts them in standard input (stdin). There's also an env var PATH_INFO. If your CGI script is http://.../myscript and the URL used to access the script is http://.../myscript/a/b/c Then PATH_INFO will contain "a/b/c". -- jeff From icon-group-sender Wed Aug 14 03:05:08 1996 Received: by cheltenham.cs.arizona.edu; Wed, 14 Aug 1996 06:04:17 MST Date: 14 Aug 96 11:04:00 BST From: R J Hare Subject: Problem with graphics To: icon-group@cs.arizona.edu Reply-To: rjhare@ed.ac.uk Organisation: Edinburgh University Computing Services Message-Id: <9608141104.aa01335@uk.ac.ed.tattoo> Errors-To: icon-group-errors@cs.arizona.edu Status: RO I have a problemette which I can't think of a solution for: I wish to superimpose a dashed grid on my window to use as a guide for the positioning of objects (and some text) to be drawn in the window. When I save the window, I do not want the positioning grid to be part of the saved image. I cannot redraw the grid with "drawop=reverse" because that may well 'undraw' some components of the objects I have drawn. Any thoughts about how to do this please? Many thanks. Roger Hare From icon-group-sender Wed Aug 14 10:26:46 1996 Received: by cheltenham.cs.arizona.edu; Wed, 14 Aug 1996 13:12:03 MST Date: Wed, 14 Aug 1996 10:26:46 -0500 Message-Id: <199608141526.KAA01341@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Problem with graphics To: rjhare@tattoo.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 Status: RO >I wish to superimpose a dashed grid on my window to use as a guide for the positioning of objects (and some text) to be drawn in the window. When I save the window, I do not want the positioning grid to be part of the saved image. I cannot redraw the grid with "drawop=reverse" because that may well 'undraw' some components of the objects I have drawn. Any thoughts about how to do this please? This is rather like the "sprites" question which comes up all the time in the design and implementation of video games. There are a whole variety of approaches that can be used, which fall into at least three types of categories: 1) reconstruction... prior to saving, you reconstruct the image but without the grid (this is the kind of thing that AutoCAD does). 2) masking... when you're drawing on the grid, you keep a separate mask which records where the objects are that are drawn since the grid. Before saving, you then use the mask to clear (or merge from another image, perhaps) everything drawn previously (i.e. all the background). 3) palette tricks... where you use a special color (or a small number of special colors) in your grid and background and ensure that the same exact colors are not duplicated in the objects drawn later. Then before saving, you either clear all pixels of the "special" colors, or else you reload the palette so that pixels of the "special" colors are displayed in the same color as the surrounding background. In short, there is no one "right" solution to this issue... it all depends on a whole variety of tradeoffs of speed, complexity, memory utilization, etc. etc. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Wed Aug 14 11:02:38 1996 Received: by cheltenham.cs.arizona.edu; Wed, 14 Aug 1996 13:12:12 MST Date: Wed, 14 Aug 1996 11:02:38 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9608141602.AA00042@water.cs.utsa.edu> To: rjhare@ed.ac.uk Cc: icon-group@cs.arizona.edu In-Reply-To: <9608141104.aa01335@uk.ac.ed.tattoo> (message from R J Hare on 14 Aug 96 11:04:00 BST) Subject: Re: Problem with graphics Content-Length: 876 Errors-To: icon-group-errors@cs.arizona.edu Status: O [Roger Hare writes:] > I wish to superimpose a dashed grid on my window to use as a guide for the > positioning of objects (and some text) to be drawn in the window. When I > save the window, I do not want the positioning grid to be part of the saved > image. I cannot redraw the grid with "drawop=reverse" because that may well > 'undraw' some components of the objects I have drawn. Any thoughts about how > to do this please? One brute force way would be to draw your image identically on an on-screen window with a grid, and on an off-screen window ("canvas=hidden") without a grid. When you save, save the off-screen version. This seems like the best solution as long as you can spare the memory. Clint Jeffery jeffery@ringer.cs.utsa.edu Division of Computer Science The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Thu Aug 15 07:08:08 1996 Received: by cheltenham.cs.arizona.edu; Fri, 16 Aug 1996 12:45:56 MST Date: 15 Aug 96 15:06:26 BST From: R J Hare Subject: Problem with graphics To: icon-group@cs.arizona.edu Reply-To: rjhare@ed.ac.uk Organisation: Edinburgh University Computing Services Message-Id: <9608151506.aa28232@uk.ac.ed.tattoo> Errors-To: icon-group-errors@cs.arizona.edu Thanks to those who replied to my query about how to superimpose a guide grid on a window without having the grid saved when I saved the finalk image. The answer is of course to keep a copy of the iamge with "canvas=hidden" which does *not* have the grid, and save this copy rather than the on-screen image. This is a little tedious (every graphics operation except the drawing of the grid has to be performed twice), but it seems to work... Roger Hare From icon-group-sender Thu Aug 15 07:03:48 1996 Received: by cheltenham.cs.arizona.edu; Fri, 16 Aug 1996 12:45:47 MST Date: Thu, 15 Aug 1996 07:03:48 -0500 Message-Id: <199608151203.HAA22106@ns1.computek.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: gep2@computek.net Subject: Re: Problem with graphics To: rjhare@tattoo.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 >The 'obvious' way to do this, and the way I think I am going to have to go is to use 2 windows, one of them off screen wityh the grid drawn on the on screen window. Every time I draw to the on screen window, I draw to the off screen window, and when I save, I save the off screen window thus avoiding saving the grid. It's a pain because I have 2 lines of drawing code where before I had one. However... A lot clearly depends on how much you draw, and how much memory a secondary window will require, versus how many times you actually do save the window to disk. One approach would be to maintain a list containing all the graphics calls (and their parameters) you have made since erasing or creating a graphics window. Then, before saving it, you can run down the list and essentially recreate the window (or do any desired subset of the calls that created it... this is how AutoCAD and other software handle their "layering" stuff I think). If you build a set of suitable graphics front-end routines, this could be transparent to the calling program (and you'd not have to duplicate your calls in-line). Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Aug 15 11:06:35 1996 Received: by cheltenham.cs.arizona.edu; Fri, 16 Aug 1996 12:46:05 MST Date: Thu, 15 Aug 1996 11:06:35 -0700 From: Gregg Townsend Message-Id: <9608151806.AA09531@hawk.CS.Arizona.EDU> To: icon-group, rjhare@tattoo.ed.ac.uk Subject: Re: Problem with graphics Errors-To: icon-group-errors@cs.arizona.edu [ Roger Hare asks how to draw objects atop a grid, then make the grid invisible when saving the image. ] Here's another approach inspired by Gordon Peterson's suggestions. Use a mutable color for drawing the grid: gridcolor := NewColor("pale blue") Fg(gridcolor) drawgrid() Fg("black") drawobjects() Then make it invisible to save the image: Color(gridcolor, Bg()) WriteImage(filename) This works on platforms that support mutable colors, including X windows. 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 Mon Aug 19 10:15:36 1996 Received: by cheltenham.cs.arizona.edu; Mon, 19 Aug 1996 14:11:52 MST Message-Id: From: Chris Fraser To: "'icon-group@cs.arizona.edu'" Subject: evaluating Date: Mon, 19 Aug 1996 10:15:36 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 9 TEXT Errors-To: icon-group-errors@cs.arizona.edu During the evaluation of, say, every (1 to 1000000)/real(n) ... n is converted to floating point once, not one million times, right? Chris Fraser, Microsoft Research From icon-group-sender Mon Aug 19 15:11:58 1996 Received: by cheltenham.cs.arizona.edu; Tue, 20 Aug 1996 08:07:37 MST Date: Mon, 19 Aug 1996 15:11:58 -0700 From: kwalker@orville.premenos.com (Ken Walker) Message-Id: <199608192211.PAA11095@varda.premenos.com> To: icon-group@cs.arizona.edu, cwfraser@microsoft.com Subject: Re: evaluating Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: b9bYLMWJUzCATydTrFLMLA== Errors-To: icon-group-errors@cs.arizona.edu > From: Chris Fraser > Date: Mon, 19 Aug 1996 10:15:36 -0700 > > During the evaluation of, say, > > every (1 to 1000000)/real(n) ... > > n is converted to floating point once, not one million times, right? In general, evaluation is left to right. real(n) is evaluated after (1 to 1000000). If n changes between iterations, the semantics of Icon requires that real(n) be reevaluted. The optimizing compiler does not do enough analysis to determine if the expression can be evaluated just once in this case, so it will be evaluated one million times reguardless of whether you use the interpreter or the compiler. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Mon Aug 19 15:42:30 1996 Received: by cheltenham.cs.arizona.edu; Tue, 20 Aug 1996 08:07:48 MST Date: Mon, 19 Aug 1996 15:42:30 -0700 (MST) Message-Id: <199608192242.PAA06268@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: Chris Fraser From: "William H. Mitchell" Subject: Re: evaluating Cc: icon-group@cs.arizona.edu Errors-To: icon-group-errors@cs.arizona.edu At 10:15 AM 8/19/96 -0700, Chris Fraser wrote: >During the evaluation of, say, > > every (1 to 1000000)/real(n) ... > >n is converted to floating point once, not one million times, right? > I'd say a million. Consider this program: procedure main() every (1 to 10)/f() end procedure f() return 1 end Here's the *icont* output with tracing: : main() x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 2 | f() x.icn : 5 | f returned 1 x.icn : 3 main failed The compiler might do better... From icon-group-sender Mon Aug 19 18:27:25 1996 Received: by cheltenham.cs.arizona.edu; Tue, 20 Aug 1996 08:08:03 MST Date: Mon, 19 Aug 1996 18:27:25 -0500 From: jeffery@dragon.cs.utsa.edu (Clinton Jeffery) Message-Id: <9608192327.AA12311@water.cs.utsa.edu> To: cwfraser@microsoft.com Cc: icon-group@cs.arizona.edu In-Reply-To: (message from Chris Fraser on Mon, 19 Aug 1996 10:15:36 -0700) Subject: Re: evaluating Content-Length: 507 Errors-To: icon-group-errors@cs.arizona.edu > During the evaluation of, say, > every (1 to 1000000)/real(n) ... > n is converted to floating point once, not one million times, right? e1 / e2 are evaluated similar to e1 & e2 which is to say, every time e1 produces another result e2 (which might be a generator) is restarted. A good optimizing compiler ought to be able to figure out whether n changes in the do... clause of the every loop, and if not, skip re-evaluation, but the semantics of the language (and icont...) say: re-evaluate. From icon-group-sender Mon Aug 26 18:39:39 1996 Received: by cheltenham.cs.arizona.edu; Mon, 26 Aug 1996 13:16:52 MST To: icon-group@cs.arizona.edu Date: Mon, 26 Aug 1996 18:39:39 +0200 From: Alexander Steinberg Message-Id: <3221D34B.7FE9@bertelsmann.de> Organization: Customer of EUnet Germany; Info: info@Germany.EU.net Sender: icon-group-request@cs.arizona.edu Subject: Linux Elf binaries and Icon 9.1 Errors-To: icon-group-errors@cs.arizona.edu Hello. Does anybody know how to install the linux a.out version of icon under Linux with ELF installed? I always get the message 'libXpm.so.lib' not find when I start the icont. Thanks for Your help. From icon-group-sender Fri Aug 30 08:45:12 1996 Received: by cheltenham.cs.arizona.edu; Fri, 30 Aug 1996 10:52:52 MST Message-Id: <199608301545.IAA17632@orpheus.gemini.edu> From: swampler@noao.edu Date: Fri, 30 Aug 1996 08:45:12 MST X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: icon-group@cs.arizona.edu Subject: Unbuffered reads from Unix pipes? Errors-To: icon-group-errors@cs.arizona.edu I left my Icon book at home today - can someone tell me the character to add to argument 2 of open to read a pipe unbuffered under Unix? I want to process each line of input from the pipe as it comes in, and now wait for enough lines to fill the input buffer. Thanks! -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The Gods that smiled upon your birth are laughing now. -- fortune cookie 9.2. I'd appreciate any help. Thanks! Christian ------------------- test program -------------- procedure xxx (a) write("xxx", a, "yyy") end procedure main () local p "write"(44) "xxx"(55) p := proc("xxx", 1) p(55) end -------------- output ------------- 44 Run-time error 106 File t.icn; Line 9 procedure or integer expected offending value: "xxx" Trace back: main() "xxx"(55) from line 9 in t.icn -- ___________________________________________________________________________ Christian Collberg | Email: c_collberg@cs.auckland.ac.nz Computer Science Dept | Fax: +64-9-373-7453 University of Auckland | Phone: +64-9-373-7599 x 6137 From icon-group-sender Fri Aug 30 21:41:06 1996 Received: by cheltenham.cs.arizona.edu; Fri, 30 Aug 1996 17:20:58 MST Date: Fri, 30 Aug 1996 21:41:06 -0500 Message-Id: <199608310241.VAA13620@segfault.cs.utsa.edu> From: Clinton Jeffery To: swampler@noao.edu Cc: icon-group@cs.arizona.edu In-Reply-To: <199608301545.IAA17632@orpheus.gemini.edu> (swampler@noao.edu) Subject: Re: Unbuffered reads from Unix pipes? Errors-To: icon-group-errors@cs.arizona.edu > I left my Icon book at home today - can someone tell me the > character to add to argument 2 of open to read a pipe unbuffered > under Unix? I want to process each line of input from the pipe > as it comes in, and now wait for enough lines to fill the input buffer. I am not aware of any such option letter to open(). open(...,"p") calls C language popen(), which similarly does not have such an option letter. Someone could always *add* such a capability and post it as a contribution... I think it would involve calls to fcntl() or ioctl() or some such. Clint Jeffery jeffery@cs.utsa.edu Division of Computer Science, The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Wed Sep 4 01:11:59 1996 Received: by cheltenham.cs.arizona.edu; Wed, 4 Sep 1996 10:08:49 MST From: Michael Edward Maul Message-Id: <199609040511.AA19956@cms.uncwil.edu> Subject: ANNOUNCE:Database interface available for Icon To: icon-group@cs.arizona.edu Date: Wed, 4 Sep 1996 01:11:59 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1122 Errors-To: icon-group-errors@cs.arizona.edu I have just finished an interface to the msql database package for icon. I2cmsql is an Icon interface to the mSQL server. It con- sists of a number of ICON wrapper functions, and a C library which provides access to mSQL. Through the use of this package it is possible to access up to 16 mSQL servers simultaneously over a network or local host. Now who's gonna use it to make a killer Icon powered WEB search engine? I just uploaded it to ftp.cs.arizona.edu/incoming so it should hopefully be in the /icon/contrib directory in a day or two....................... The file name is i2cmsql-0.1.16.tgz -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mike Maul | Intrests/hobbies: hacking (is there really CS major (senior) | any thing else) UNC-Wilmington | Like what you see? ........Offer me a job! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E-Mail: maul@sol.cms.uncwil.edu WWW: http://www.cms.uncwil.edu/~maul .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. From icon-group-sender Wed Sep 4 11:12:19 1996 Received: by cheltenham.cs.arizona.edu; Wed, 4 Sep 1996 13:17:49 MST To: icon-group@cs.arizona.edu Date: 4 Sep 1996 11:12:19 -0700 From: icon-project@cs.arizona.edu Message-Id: <50kgq3$4h@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: February 16, 1996 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 UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and the Acorn Archimedes. There are older versions for the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, 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? 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, and runs on UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, and Acorn Archimedes. Other implementations presently are at Version 8. Almost all programs that run under Version 8 and that do not use graphics will run under Version 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 support Icon's graphics facilities are in beta testing. 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), postal money order, or check drawn on a bank with a branch in the United States and made payable to The University of Arizona. Icon is available on CD-ROM from Prime Time Freeware (http://www.ptf.com/, 408-433-9662). Contact them for details. 11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, second edition, 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. 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 subscription 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, revenue from the sale of program material and documentation, and user contributions. 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 updated only 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 twice a year. There also is a subscription service for updates to the Icon program library, which provides new material about twice 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? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please 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. 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.