home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / comp-lang-icon-faq < prev    next >
Encoding:
Text File  |  2011-01-02  |  15.6 KB  |  380 lines

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!171.64.64.130.MISMATCH!usenet.stanford.edu!newsfeed.news.ucla.edu!news.arizona.edu!news.cs.arizona.edu!not-for-mail
  2. From: icon-project@cs.arizona.edu
  3. Newsgroups: comp.lang.icon,comp.answers,news.answers
  4. Subject: Icon Programming Language FAQ
  5. Supersedes: <comp-lang-icon-faq-1291186807$22274@hisatsinom.cs.arizona.edu>
  6. Followup-To: comp.lang.icon
  7. Date: Sat, 1 Jan 2011 07:00:07 +0000 (UTC)
  8. Organization: University of Arizona Computer Science Department
  9. Lines: 361
  10. Approved: news-answers-request@MIT.Edu
  11. Message-ID: <comp-lang-icon-faq-1293865207$23892@hisatsinom.cs.arizona.edu>
  12. Reply-To: icon-project@cs.arizona.edu
  13. NNTP-Posting-Host: hisatsinom.cs.arizona.edu
  14. X-Trace: hisatsinom.cs.arizona.edu 1293865207 23893 192.12.69.9 (1 Jan 2011 07:00:07 GMT)
  15. X-Complaints-To: lab@cs.arizona.edu
  16. NNTP-Posting-Date: Sat, 1 Jan 2011 07:00:07 +0000 (UTC)
  17. Xref: senator-bedfellow.mit.edu comp.lang.icon:6215 comp.answers:67439 news.answers:328176
  18.  
  19. Posted-by: postfaq 1.15 (Perl 5.8.8)
  20. Archive-name: comp-lang-icon-faq
  21. Posting-Frequency: monthly
  22.  
  23.         Frequently Asked Questions about the Icon programming language
  24.  
  25.    www.cs.arizona.edu/icon/faq.htm
  26.    Last updated October 25, 2010
  27.  
  28.    Learning about Icon
  29.    A1. What is Icon?
  30.    A2. What is Icon good for?
  31.    A3. What are Icon's distinguishing characteristics?
  32.    A4. What is the Icon program library?
  33.    A5. Where can I learn more about Icon?
  34.    A6. Where are some simple examples?
  35.    A7. How about comprehensive documentation?
  36.  
  37.    Implementations
  38.    B1. What platforms support Icon?
  39.    B2. How do I get started with Icon?
  40.    B3. Is there a Unicode version of Icon?
  41.    B4. What happened to the compiler?
  42.  
  43.    Administration
  44.    C1. What is the Icon Project?
  45.    C2. How often is the on-line material updated?
  46.    C3. Where did Icon come from?
  47.    C4. Where is Icon going?
  48.  
  49.    Support
  50.    D1. Is there a users' group for Icon?
  51.    D2. How do I get technical support?
  52.  
  53.    Programming
  54.    E1. Why doesn't read() work with every?
  55.    E2. Why doesn't string invocation such as "foo"() work?
  56.    E3. How can I call a C function?
  57.    E4. Can I open a bidirectional pipe?
  58.      _________________________________________________________________
  59.  
  60. Learning about Icon
  61.  
  62.   A1. What is Icon?
  63.  
  64.    Icon is a very high level general-purpose programming language with
  65.    extensive features for processing strings (text) and data structures.
  66.    Icon is an imperative, procedural language with a syntax that is
  67.    reminiscent of C and Pascal, but with semantics at a much higher
  68.    level.
  69.  
  70.    Icon has a novel expression-evaluation mechanism that integrates
  71.    goal-directed evaluation and backtracking with conventional control
  72.    structures. It has a string scanning facility for pattern matching
  73.    that avoids the tedious details usually associated with analyzing
  74.    strings. Icon's built-in data structures include sets and tables with
  75.    associative lookup, lists that can be used as vectors or stacks and
  76.    queues, and records.
  77.  
  78.    Icon is a strongly, though not statically, typed language. It provides
  79.    transparent automatic type conversion: For example, if an integer is
  80.    used in an operation that requires a string, the integer is
  81.    automatically converted to a string.
  82.  
  83.    Several implementations of Icon have high-level graphics facilities
  84.    with an easily programmed window interface.
  85.  
  86.    Icon manages storage automatically. Objects are created as needed
  87.    during program execution and space is reclaimed by garbage collection
  88.    as needed. The sizes of strings and data structures are limited only
  89.    by the amount of available memory.
  90.  
  91.   A2. What is Icon good for?
  92.  
  93.    As a general-purpose programming language with a large computational
  94.    repertoire, Icon can be used for most programming tasks. It's
  95.    especially strong at building software tools, for processing text, and
  96.    for experimental and research applications.
  97.  
  98.    Icon is designed to make programming easy; it emphasizes the value of
  99.    programmer's time and the importance of getting programs to work
  100.    quickly. Consequently, Icon is used both for short, one-shot tasks and
  101.    for very complex applications.
  102.  
  103.   A3. What are Icon's distinguishing characteristics?
  104.  
  105.      * A high-level, general-purpose programming language
  106.      * Friendly line-oriented syntax (no semicolons needed)
  107.      * Emphasis on programmer productivity
  108.      * Usually interpreted
  109.  
  110.      * Evolved from programming languages (vs. scripting languages)
  111.      * Procedural control flow plus generators and goal-directed
  112.        evaluation
  113.  
  114.      * Values have types; variables are typeless, accept any value
  115.      * Static scoping: global or (procedure) local
  116.      * Automatic garbage collection
  117.  
  118.      * All integers have arbitrary precision
  119.      * Uses strings (not chars) as basic text datatype
  120.      * Has lists that function as arrays, queues, and stacks
  121.      * Also has sets, tables, records (structs), reals (doubles), more
  122.      * No second-class "primitive types"
  123.  
  124.      * Not "object-oriented" (no classes, inheritance, or instance
  125.        methods)
  126.      * No exception catching
  127.      * No concurrency (no threads, monitors, semaphores, or
  128.        synchronization)
  129.      * Has co-expressions (coroutines)
  130.  
  131.      * Basic least-common-denominator system interface (a la ANSI C)
  132.  
  133.      * Procedural graphics (event-driven paradigm available but not
  134.        mandated)
  135.      * Retained windows (programs are never called to repaint)
  136.      * Simple GUI builder that can re-edit its generated code
  137.      * Turtle graphics package
  138.  
  139.      * Large library of contributed procedures and programs
  140.  
  141.   A4. What is the Icon program library?
  142.  
  143.    The library is a collection of programs and procedures written in
  144.    Icon. User contributions form a significant portion of the library.
  145.  
  146.    Library procedures effectively augment the built-in functions
  147.    available to an Icon program. A wide variety of procedures currently
  148.    exists, and most graphically-based programs are built around library
  149.    procedures. The core and graphics core modules are the most carefully
  150.    vetted.
  151.  
  152.    The programs in the library range from simple demonstrations to handy
  153.    tools to complex graphical applications.
  154.  
  155.    The library is a resource for both new and experienced programmers. In
  156.    addition to their basic utility, its programs and procedures serve as
  157.    examples of how things can be written in Icon.
  158.  
  159.    The library is indexed at www.cs.arizona.edu/icon/library/ipl.htm.
  160.  
  161.   A5. Where can I learn more about Icon?
  162.  
  163.    Here are some good places to start.
  164.      * Ralph Griswold's overview: www.cs.arizona.edu/icon/docs/ipd266.htm
  165.      * Dave Hanson's introduction: www.cs.arizona.edu/icon/intro.htm
  166.      * Bill Mitchell's introduction and slides:
  167.        www.mitchellsoftwareengineering.com/icon
  168.      * John Shipman's tutorial: www.nmt.edu/tcc/help/lang/icon
  169.  
  170.    For the graphics facilities:
  171.      * The Icon Project Overview:
  172.        www.cs.arizona.edu/icon/ftp/doc/ipd281.pdf
  173.  
  174.   A6. Where are some simple examples?
  175.  
  176.    For some simple text-based programs, see any of those introductory
  177.    documents in the preceding question. For some simple graphics
  178.    programs, see www.cs.arizona.edu/icon/gb/progs/progs.htm.
  179.  
  180.    Many more examples, typically larger, are found in the Icon program
  181.    library; see the indexes of Basic Programs and Graphics Programs.
  182.  
  183.   A7. How about comprehensive documentation?
  184.  
  185.    Two books define the Icon language. The core language is covered in
  186.    The Icon Programming Language (third edition), by Griswold and
  187.    Griswold. Graphics facilities are described in Graphics Programming in
  188.    Icon by Griswold, Jeffery, and Townsend. These books contain both
  189.    tutorial and reference material.
  190.  
  191.    Icon's internals are detailed in The Implementation of the Icon
  192.    Programming Language by Griswold and Griswold. Although considerable
  193.    changes have occurred since Version 6, described in the book, the
  194.    basic structure of Icon remains the same. Two technical reports,
  195.    IPD112 and IPD239, describe subsequent changes.
  196.  
  197.    Printed copies of the Language and Graphics books are available from
  198.    Jeffery Systems (http://unicon.org/books/). All three books can be
  199.    downloaded at no charge from the Icon books page,
  200.    www.cs.arizona.edu/icon/books.htm.
  201.  
  202.    A 2010 revision of the book Icon Programming for Humanists, by Alan
  203.    CorrΘ, is also available for purchase or download from Jeffery
  204.    Systems.
  205.  
  206.    The Icon Programming Language Handbook, by Thomas W. Christopher, is
  207.    available on the web at www.tools-of-computing.com/tc/CS/iconprog.pdf.
  208.  
  209.    An on-line index to the Icon program library is found at
  210.    www.cs.arizona.edu/icon/library/ipl.htm.
  211.  
  212.    There is a large amount of additional information at the Icon web
  213.    site, www.cs.arizona.edu/icon, including complete sets of back issues
  214.    of the Icon Newsletter and Icon Analyst.
  215.      _________________________________________________________________
  216.  
  217. Implementations
  218.  
  219.   B1. What platforms support Icon?
  220.  
  221.    The current implementation of Icon is a Unix implementation. This
  222.    includes Linux, BSD, Solaris, Macintosh, and the Cygwin environment
  223.    under Windows. Version 9.5 of Icon has been tested on all these
  224.    platforms.
  225.  
  226.    Older versions are available for Windows and some other systems. An
  227.    alternative Java-based implementation for Unix, Jcon, is also
  228.    available.
  229.  
  230.    None of these environments includes a window-based development
  231.    environment. While Icon programs can open windows and use graphics,
  232.    programming is done using Unix editors and other tools from a command
  233.    shell.
  234.  
  235.   B2. How do I get started with Icon?
  236.  
  237.    The current version of Icon for Unix can be downloaded from
  238.    www.cs.arizona.edu/icon/current. Source and binary packages are
  239.    available, each with the complete Icon program library.
  240.  
  241.    For older implementations, start at
  242.    www.cs.arizona.edu/icon/implver.htm. Jcon is at
  243.    www.cs.arizona.edu/icon/jcon.
  244.  
  245.   B3. Is there a Unicode version of Icon?
  246.  
  247.    No. Icon is defined in terms of 8-bit characters, and changing this
  248.    presents several design challenges that would likely break existing
  249.    programs. Also, modifying the C implementation is probably infeasible,
  250.    but a Unicode version of Jcon might be possible.
  251.  
  252.   B4. What happened to the compiler?
  253.  
  254.    For a while, Unix distributions included both an interpreter and a
  255.    compiler. The compiler was an interesting research project but it has
  256.    not been maintained and is no longer supported. The interpreter is
  257.    much easier to use and is generally quite fast enough, even for
  258.    production applications.
  259.      _________________________________________________________________
  260.  
  261. Administration
  262.  
  263.   C1. What is the Icon Project?
  264.  
  265.    The Icon Project is a name used by the group that distributes and
  266.    supports the Icon programming language. The project maintains the Icon
  267.    web site at www.cs.arizona.edu/icon. A non-commercial organization,
  268.    the project is supported by the Department of Computer Science at the
  269.    University of Arizona.
  270.  
  271.   C2. How often is the on-line material updated?
  272.  
  273.    The Icon implementation is now in maintenance mode, with new releases
  274.    produced only when necessary. This typically happens every few years
  275.    when a change in the Gnu tools cause the source to stop building.
  276.  
  277.   C3. Where did Icon come from?
  278.  
  279.    Icon is the latest in a series of high-level programming languages
  280.    designed to facilitate programming tasks involving strings and
  281.    structures. The original language, SNOBOL, was developed at Bell
  282.    Telephone Laboratories in the early 1960s. SNOBOL evolved into
  283.    SNOBOL4, which is still in use. Subsequent languages were developed at
  284.    the University of Arizona with support from the National Science
  285.    Foundation. Although it has similar objectives and many similar
  286.    capabilities, Icon bears little superficial resemblance to SNOBOL4.
  287.  
  288.    Icon implementations were developed by faculty, staff, and students at
  289.    the University of Arizona, with significant contributions from
  290.    volunteers around the world. An Icon history by Ralph and Madge
  291.    Griswold appears in the preprints of the second History of Programming
  292.    Languages Conference (HOPL-II), ACM SIGPLAN Notices, March 1993 (Vol
  293.    28, No 3).
  294.  
  295.    The name Icon is not an acronym, nor does it stand for anything in
  296.    particular, although the word iconoclastic was mentioned when the name
  297.    was chosen. The name predates the now common use of icon to refer to
  298.    small images used in graphical user interfaces. This sometimes
  299.    misleads people into thinking that Icon is designed to create or
  300.    manipulate icons, but there's no good solution to that problem.
  301.  
  302.   C4. Where is Icon going?
  303.  
  304.    We continue to use Icon on a daily basis, but no significant changes
  305.    are planned. We expect to support the Unix version for the foreseeable
  306.    future, and to distribute ports to other systems as supplied by
  307.    volunteers.
  308.  
  309.    The Unicon project is developing an object-oriented language based on
  310.    Icon. For more information, see unicon.sourceforge.net. An earlier
  311.    object-oriented extension to Icon, Idol, can be found in the Icon
  312.    program library.
  313.      _________________________________________________________________
  314.  
  315. Support
  316.  
  317.   D1. Is there a users' group for Icon?
  318.  
  319.    There is no official Icon users' group, but the Usenet newsgroup
  320.    comp.lang.icon is dedicated to issues relating to the Icon language.
  321.  
  322.   D2. How do I get technical support?
  323.  
  324.    The Icon Project is not a commercial organization, and its capacity
  325.    for providing technical support is limited. Please use the appropriate
  326.    resource when you need assistance:
  327.      * For programming questions, submit a query to the Usenet newsgroup
  328.        comp.lang.icon.
  329.      * For porting assistance or Unix problems, contact
  330.        icon-project@cs.arizona.edu.
  331.      * For general information and additional documentation, visit the
  332.        Icon web site: www.cs.arizona.edu/icon.
  333.      _________________________________________________________________
  334.  
  335. Programming
  336.  
  337.   E1. Why doesn't read() work with every?
  338.  
  339.    every s := read() do {...} doesn't loop because read() produces a
  340.    single value and then fails if resumed. Other "consumer" procedures
  341.    such as get() and pop() work the same way. Use a while loop with these
  342.    procedures, and save every for use with generators such as !x or
  343.    key(T).
  344.  
  345.   E2. Why doesn't string invocation such as "foo"() work?
  346.  
  347.    String invocation works if the procedure is present; the catch is that
  348.    the linker removes unreferenced procedures. To ensure a procedure's
  349.    presence, reference it in the main() procedure. A simple reference
  350.    suffices, as in refs := [foo, bar, baz]; it's not necessary to
  351.    actually call it.
  352.  
  353.    (Why does the linker remove unreferenced procedures? To significantly
  354.    reduce the memory requirements of programs that use the library. There
  355.    was a time when this mattered.)
  356.  
  357.   E3. How can I call a C function?
  358.  
  359.    You can't call an arbitrary C function, but you can load and call one
  360.    that is written to Icon's specifications. A tutorial appears in Icon
  361.    Analyst 36. Some examples can be found in the cfuncs and
  362.    packs/loadfuncs directories of the Icon program library.
  363.  
  364.    The Jcon implementation allows Icon programs to call Java code that is
  365.    written to Jcon specifications.
  366.  
  367.   E4. Can I open a bidirectional pipe?
  368.  
  369.    No, this is not possible. Although the concept is simple -- write a
  370.    line to a program via a pipe, then read that program's output -- it
  371.    probably wouldn't work. Most I/O libraries don't write anything to a
  372.    pipe until they've filled a buffer, and the most likely consequence
  373.    would be a deadlock, with each program waiting for the other to send
  374.    more data.
  375.      _________________________________________________________________
  376.  
  377.    This FAQ is edited by Gregg Townsend. It includes contributions from
  378.    Ralph Griswold, Cliff Hathaway, Clint Jeffery, Bob Alexander, and Todd
  379.    Proebsting.
  380.