Learning about Icon
A1. What is Icon?
A2. What is Icon good for?
A3. What is the Icon program library?
A4. Where can I learn more about Icon?
A5. How about comprehensive documentation?
Implementations
B1. What platforms support Icon?
B2. How do I get started with Icon?
B3. Is there a Unicode version of Icon?
B4. What happened to the compiler?
Administration
C1. What is the Icon Project?
C2. How often is the on-line material updated?
C3. Where did Icon come from?
C4. Where is Icon going?
Support
D1. Is there a users' group for Icon?
D2. How do I get technical support?
Programming
E1. Why doesn't read() work with every?
E2. Why doesn't string invocation such as "foo"() work?
E3. How can I call a C function?
E4. Can I open a bidirectional pipe?
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 with semantics at a much higher level.
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.
As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's especially strong at building software tools, for processing text, and for experimental and research 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. Consequently, Icon is used both for short, one-shot tasks and for very complex applications.
The library is a collection of programs and procedures written in Icon. User contributions are welcome and form a significant portion of the library.
Library procedures effectively augment the built-in functions available to an Icon program. A wide variety of procedures currently exists, and most graphically-based programs are built around library procedures.
The programs in the library range from simple demonstrations to handy tools to complex graphical applications.
The library is a resource for both new and experienced programmers. In addition to their basic utility, its programs and procedures serve as examples of how things can be written in Icon.
Here are some good places to start.
The definitive work is The Icon Programming Language (third edition) by Griswold and Griswold (Peer-to-Peer Communications, 1996). It contains both tutorial and reference material.
Graphics facilities are described in Graphics Programming in Icon by Griswold, Jeffery, and Townsend (Peer-to-Peer Communications, 1998). Again, both tutorial and reference material is included.
Icon's internals are detailed in The Implementation of the Icon Programming Language by Griswold and Griswold (Princeton, 1986, out of print). Although considerable changes have occurred since Version 6, described in the book, the basic structure is the same. Two technical reports, IPD112 and IPD239, describe subsequent changes.
The Icon Programming Language Handbook, by Thomas W. Christopher, is available on the web at http://www.toolsofcomputing.com/IconHandbook/.
There is a large amount of additional information at the Icon web site, http://www.cs.arizona.edu/icon, but there is no complete on-line documentation.
Current implementations with graphics support are available for Unix and Windows. Somewhat older versions, without graphics, are available for the Macintosh and other systems. Jcon, an alternative Java-based implementation for Unix, is also available. These Icon implementations were developed at the University of Arizona, with significant contributions from volunteers around the world.
Version 9.4 of Icon for Unix can be downloaded from http://www.cs.arizona.edu/icon/v940/. Source and binary packages are available, each with the complete Icon program library.
Version 9.3 of Icon for Windows is compatible at the source level with version 9.4. It can be downloaded from http://www.cs.arizona.edu/icon/v93w.htm. The Version 9.4 library can be obtained separately from http://www.cs.arizona.edu/icon/v940/.
For older implementations, start at http://www.cs.arizona.edu/icon/implver.htm. Jcon is at http://www.cs.arizona.edu/icon/jcon/.
No. Icon is defined in terms of 8-bit characters, and changing this presents several design challenges that would likely break existing programs. Also, modifying the C implementation is probably infeasible, but a Unicode version of Jcon might be possible.
For a while, Unix distributions included both an interpreter and a compiler; but the interpreter is is usually fast enough even for production work, and most people found that using the compiler wasn't worth the extra compilation time or the hassles involved. We no longer advertise the compiler or produce binaries for it. It is still part of the source code distribution, and we have not deliberately broken it, but we no longer support it and we cannot offer help if problems arise.
The Icon Project is a name used by the group that distributes and supports the Icon programming language. The project maintains the Icon web site at http://www.cs.arizona.edu/icon. A non-commercial organization, the project derives support from the University of Arizona, revenue from book sales, and user contributions.
New material is added when it's available. Established implementations usually are updated only when there's a new version. This typically is every year or two. The Icon program library is updated on a similar schedule.
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 1960s. 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. Although it has similar objectives and many similar capabilities, Icon bears little superficial resemblance to SNOBOL4.
The name Icon is not an acronym, nor does it stand for anything in particular, although the word iconoclastic was mentioned when the name was chosen. The name predates the now common use of icon to refer to small images used in graphical user interfaces. This sometimes misleads people into thinking that that Icon is designed to create or manipulate icons, but there's no good solution to that problem.
An Icon history by Ralph and Madge Griswold appears in the preprints of the second History of Programming Langugages Conference (HOPL-II), ACM SIGPLAN Notices, March 1993 (Vol 28, No 3).
We continue to use Icon on a daily basis, but no significant changes are planned. We expect to support the Unix version for the forseeable future, and to distribute ports to other systems as supplied by volunteers.
The Unicon project is developing an object-oriented language based on Icon. For more information, see http://unicon.sourceforge.net. An earlier object-oriented extension to Icon, Idol, can be found in the Icon program library.
There is no official Icon users' group, but The Icon Project maintains a moderated "Icon-group" electronic mailing list. 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 and is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends its announcements and other messages to the mailing list.
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:
read() work with every?
every s := read() do {...}
doesn't loop because read() produces a single value and
then fails if resumed.
Other "consumer" procedures such as get() and pop()
work the same way.
Use a while loop with these procedures, and save
every for use with generators such as !x
or key(T).
"foo"() work?
String invocation works if the procedure is present;
the catch is that the linker removes unreferenced procedures.
To ensure a procedure's presence, reference it in the
main() procedure.
A simple reference suffices, as in
refs := [foo, bar, baz];
it's not necessary to actually call it.
(Why does the linker remove unreferenced procedures? Because this can save huge amounts of memory for programs that use the library.)
You can't call an arbitrary C function,
but if you're willing to write a function to Icon's specifications,
there are two approaches.
Under Unix, which provides loadfunc(),
you can load one or more functions from a shared library,
and afterwards treat them as if they had been written in Icon.
Some examples can be found in the
cfuncs and
packs/loadfuncs directories of the Icon program library.
The more cumbersome approach is to add code to the Icon interpreter
and rebuild it; some hooks are provided for this purpose.
Both approaches are discussed in Calling C Functions from Icon,
http://www.cs.arizona.edu/icon/docs/ipd240.htm.
The Jcon implementation allows Icon programs to call Java code that is written to Jcon specifications.
No, this is not possible. Although the concept is simple -- write a line to a program via a pipe, then read that program's output -- it probably wouldn't work. Most I/O libraries don't write anything to a pipe until they've filled a buffer, and the most likely consequence would be a deadlock, with each program waiting for the other to send more data.