path: root/doc/faq.txt

        Frequently Asked Questions about the Icon programming language

   www.cs.arizona.edu/icon/faq.htm
   Last updated November 14, 2005

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

   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

  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 (www.zianet.com/jeffery/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.
     _________________________________________________________________

Implementations

  B1. What platforms support Icon?

   Current implementations with graphics support are available for Unix
   (including Linux) and Windows. The Unix implementation also runs on Darwin,
   the Macintosh development environment, or the Cygwin environment under
   Windows. 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.3 of Icon for Unix can be downloaded from
   www.cs.arizona.edu/icon/v943. 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.3. It can be downloaded from www.cs.arizona.edu/icon/v93w.htm.
   The Version 9.4.3 library can be obtained separately from
   www.cs.arizona.edu/icon/v943.

   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 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 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 problems with the Windows implementation, contact the implementor,
       jeffery@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.