path: root/doc/faq.txt

        Frequently Asked Questions about the Icon programming language

   www.cs.arizona.edu/icon/faq.htm
   Last updated April 12, 2010

   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. Where are some simple examples?
   A7. 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 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 core and graphics core modules are the most carefully
   vetted.

   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.

   The library is indexed at www.cs.arizona.edu/icon/library/ipl.htm.

  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
     * Bill Mitchell's introduction and slides:
       www.mitchellsoftwareengineering.com/icon
     * John Shipman's tutorial: www.nmt.edu/tcc/help/lang/icon

   For the graphics facilities:
     * The Icon Project Overview:
       www.cs.arizona.edu/icon/ftp/doc/ipd281.pdf

  A6. Where are some simple examples?

   For some simple text-based programs, see any of those introductory
   documents in the preceding question. For some simple graphics
   programs, see www.cs.arizona.edu/icon/gb/progs/progs.htm.

   Many more examples, typically larger, are found in the Icon program
   library; see the indexes of Basic Programs and Graphics Programs.

  A7. 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.

   Printed copies of the Language and Graphics books are available from
   Jeffery Systems (http://unicon.org/books/). All three 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.tools-of-computing.com/tc/CS/iconprog.pdf.

   An on-line index to the Icon program library is found at
   www.cs.arizona.edu/icon/library/ipl.htm.

   There is a large amount of additional information at the Icon web
   site, www.cs.arizona.edu/icon, including complete sets of back issues
   of the Icon Newsletter and Icon Analyst.
     _________________________________________________________________

Implementations

  B1. What platforms support Icon?

   The current implementation of Icon is a Unix implementation. This
   includes Linux, BSD, Solaris, Macintosh, and the Cygwin environment
   under Windows. Version 9.5 of Icon has been tested on all these
   platforms.

   Older versions are available for Windows and some other systems. An
   alternative Java-based implementation for Unix, Jcon, is also
   available.

   None of these environments includes a window-based development
   environment. While Icon programs can open windows and use graphics,
   programming is done using Unix editors and other tools from a command
   shell.

  B2. How do I get started with Icon?

   The current version of Icon for Unix can be downloaded from
   www.cs.arizona.edu/icon/current. Source and binary packages are
   available, each with the complete Icon program library.

   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. The compiler was an interesting research project but it has
   not been maintained and is no longer supported. The interpreter is
   much easier to use and is generally quite fast enough, even for
   production applications.
     _________________________________________________________________

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?

   The Icon implementation is now in maintenance mode, with new releases
   produced only when necessary. This typically happens every few years
   when a change in the Gnu tools cause the source to stop building.

  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 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 foreseeable
   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 Usenet newsgroup
   comp.lang.icon is dedicated to issues relating to the Icon language.

  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 questions, submit a query to the Usenet newsgroup
       comp.lang.icon.
     * For porting assistance or Unix problems, contact
       icon-project@cs.arizona.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? To significantly
   reduce the memory requirements of programs that use the library. There
   was a time when this mattered.)

  E3. How can I call a C function?

   You can't call an arbitrary C function, but you can load and call one
   that is written to Icon's specifications. A tutorial appears in Icon
   Analyst 36. Some examples can be found in the cfuncs and
   packs/loadfuncs directories of the Icon program library.

   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.