Icon Programming Language FAQ
icon-p...@cs.arizona.edu
Posting-Frequency: monthly
Frequently Asked Questions about the Icon programming language
www.cs.arizona.edu/icon/faq.htm
Last updated February 19, 2003
Learning about Icon
A1. What is Icon?
A2. What is Icon good for?
A3. What are Icon's distinguishing characteristics?
A4. What is the Icon program library?
A5. Where can I learn more about Icon?
A6. 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?
_________________________________________________________________
Learning about Icon
A1. 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 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.
A2. 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
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.
A3. What are Icon's distinguishing characteristics?
* A high-level, general-purpose programming language
* Friendly line-oriented syntax (no semicolons needed)
* Emphasis on programmer productivity
* Usually interpreted
* Evolved from programming languages (vs. scripting languages)
* Procedural control flow plus generators and goal-directed
evaluation
* Values have types; variables are typeless, accept any value
* Static scoping: global or (procedure) local
* Automatic garbage collection
* All integers have arbitrary precision
* Uses strings (not chars) as basic text datatype
* Has lists that function as arrays, queues, and stacks
* Also has sets, tables, records (structs), reals (doubles), more
* No second-class "primitive types"
* Not "object-oriented" (no classes, inheritance, or instance
methods)
* No exception catching
* No concurrency (no threads, monitors, semaphores, or
synchronization)
* Has co-expressions (coroutines)
* Basic least-common-denominator system interface (a la ANSI C)
* Procedural graphics (event-driven paradigm available but not
mandated)
* Retained windows (programs are never called to repaint)
* Simple GUI builder that can re-edit its generated code
* Turtle graphics package
* Large library of contributed procedures and programs
A4. What is the Icon program library?
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.
A5. Where can I learn more about Icon?
Here are some good places to start.
* Ralph Griswold's overview: www.cs.arizona.edu/icon/docs/ipd266.htm
* Dave Hanson's introduction: www.cs.arizona.edu/icon/intro.htm
* John Shipman's tutorial: www.nmt.edu/tcc/help/lang/icon
A6. How about comprehensive documentation?
Two books define the Icon language. The core language is covered in
The Icon Programming Language (third edition), by Griswold and
Griswold. Graphics facilities are described in Graphics Programming in
Icon by Griswold, Jeffery, and Townsend. These books contain both
tutorial and reference material.
Icon's internals are detailed in The Implementation of the Icon
Programming Language by Griswold and Griswold. Although considerable
changes have occurred since Version 6, described in the book, the
basic structure of Icon remains the same. Two technical reports,
IPD112 and IPD239, describe subsequent changes.
The Language and Graphics books are available from Jeffery Systems
(www.zianet.com/jeffery/books). The Language and Implementation books
can be downloaded at no charge from the Icon books page,
www.cs.arizona.edu/icon/books.htm.
The Icon Programming Language Handbook, by Thomas W. Christopher, is
available on the web at www.toolsofcomputing.com/IconHandbook.
There is a large amount of additional information at the Icon web
site, www.cs.arizona.edu/icon.
_________________________________________________________________
Implementations
B1. What platforms support Icon?
Current implementations with graphics support are available for Unix
and Windows. On the Apple Macintosh, Icon runs in the Unix development
environment of MacOS X, with graphics using XFree86. Older versions of
Icon are available for some other systems. An alternative Java-based
implementation for Unix, Jcon, is also available.
B2. How do I get started with Icon?
Version 9.4.1 of Icon for Unix can be downloaded from
www.cs.arizona.edu/icon/v941. 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.1. It can be downloaded from
www.cs.arizona.edu/icon/v93w.htm. The Version 9.4.1 library can be
obtained separately from www.cs.arizona.edu/icon/v941.
For older implementations, start at
www.cs.arizona.edu/icon/implver.htm. Jcon is at
www.cs.arizona.edu/icon/jcon.
B3. Is there a Unicode version of Icon?
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.
B4. What happened to the compiler?
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.
_________________________________________________________________
Administration
C1. What is the Icon Project?
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 www.cs.arizona.edu/icon. A non-commercial organization,
the project is supported by the Department of Computer Science at the
University of Arizona.
C2. How often is the on-line material updated?
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.
C3. 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 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.
Icon implementations were developed by faculty, staff, and students at
the University of Arizona, with significant contributions from
volunteers around the world. An Icon history by Ralph and Madge
Griswold appears in the preprints of the second History of Programming
Languages Conference (HOPL-II), ACM SIGPLAN Notices, March 1993 (Vol
28, No 3).
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.
C4. Where is Icon going?
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 unicon.sourceforge.net. An earlier
object-oriented extension to Icon, Idol, can be found in the Icon
program library.
_________________________________________________________________
Support
D1. Is there a users' group for Icon?
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-grou...@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.
D2. 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:
* For programming assistance, submit a query to the mailing list or
newsgroup (see above).
* For porting assistance or Unix problems, contact
icon-p...@cs.arizona.edu.
* For problems with the Windows implementation, contact the
implementor, jef...@cs.nmsu.edu.
* For general information and additional documentation, visit the
Icon web site: www.cs.arizona.edu/icon.
_________________________________________________________________
Programming
E1. Why doesn't 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).
E2. Why doesn't string invocation such as "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.)
E3. How can I call a C function?
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 then 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, www.cs.arizona.edu/icon/docs/ipd240.htm.
The Jcon implementation allows Icon programs to call Java code that is
written to Jcon specifications.
E4. Can I open a bidirectional pipe?
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.
_________________________________________________________________
This FAQ is edited by Gregg Townsend. It includes contributions from
Ralph Griswold, Cliff Hathaway, Clint Jeffery, Bob Alexander, and Todd
Proebsting.