==================
Unicon Programming
==================
.. Modified: 2019-10-20/20:52-0400 btiffin
.. Copyright 2016 Brian Tiffin
.. GPL 3.0+ :ref:`license`
.. This file is part of the Unicon Programming documentation.
.. image:: images/unicon.png
:align: center
.. only:: html
:ref:`genindex`
:floatright:`<a href="http://unicon.sourceforge.net/">Unicon</a>`
.. index::
single: Unicon
single: Jeffery; Dr. Clinton
.. index:: programming language; unicon
The Unicon Programming Language
===============================
**Unicon**, Unified extended **Icon**, by `Clinton Jeffery`, Shamim Mohamed,
Jafar Al Gharaibeh, Ray Pereda, Robert Parlett, and team.
.. only:: html
.. rst-class:: rightalign
PDF available at `UniconProgramming.pdf <./UniconProgramming.pdf>`_
**Icon**, an iconoclastic programming language. The design of Icon was led by
Dr. Ralph Griswold at the University of Arizona, starting in 1977, as a
structured successor to **SNOBOL** and refinement of **SL5**. Icon includes a
rich set of datatypes and operators, generators, goal directed evaluation with
implicit backtracking, text scanning, integrated graphics, and other
complementary very high level features. The design facilitates powerfully
concise, yet surprisingly readable program source code. All with an admirable
performance profile.
**Unicon** extends the feature set of Icon by adding classes, a `POSIX`
layer, networking, and a host of other modern development productivity
enhancements. Development of Unicon is led by `clint`.
Well met
--------
.. literalinclude:: examples/introductory.icn
:language: unicon
:start-after: ##+
.. only:: html
.. rst-class:: rightalign
:download:`examples/introductory.icn`
Example run:
.. command-output:: unicon -s introductory.icn -x
:cwd: examples
And that is the ``Hello, world`` program for ``Unicon``, proof that the basic
system is properly installed and functioning.
``Unicon`` deserves a little more than that, so this next introduction lets us
see what features are included in the installation.
.. literalinclude:: examples/introductory-features.icn
:language: unicon
:start-after: ##+
.. only:: html
.. rst-class:: rightalign
:download:`examples/introductory-features.icn`
*This time, all the glorious command line details are also included, but don't
worry, this will all be second nature before you know it.*
.. command-output:: unicon introductory-features.icn -x
:cwd: examples
So, yeah, *wow*, there is a lot of neat stuff in there.
Seeing as there are *graphics*, here is a graphical hello.
.. sourcecode:: unicon
#
# hello-graphics.icn, graphical hello demonstration
#
procedure main()
w := open("hello-graphics", "g")
writes(w, "Hello, graphic world")
Event(w)
close(w)
end
.. image:: images/hello-graphic-borders.png
:align: center
.. only:: html
.. rst-class:: rightalign
:download:`examples/hello-graphic-borders.icn`
*That example is the basics for graphical output in Unicon.*
As simple as console output, to a graphical window.
The next listing is a little more sophisticated, more appropriate for the
automatic image captures shown throughout this docset. Note the different
font choice.
.. literalinclude:: examples/hello-graphics.icn
:language: unicon
:start-after: ##+
.. only:: html
.. rst-class:: rightalign
:download:`examples/hello-graphics.icn`
Giving:
.. command-output:: unicon -s hello-graphics.icn -x
:cwd: examples
.. image:: images/hello-graphics.png
.. only:: html
.. rst-class:: leftalign
:download:`images/hello-graphics.png`
--------
.. index:: overview
Overview of Unicon
------------------
.. note::
Unicon encompasses :ref:`Icon`. Many things attributed to Unicon here,
may have originated in Icon. Attempts will be made to clearly state
when Icon is the origin. *Everything* from Icon is in Unicon, and then
extended out by the Unicon team. This *Unicon centric view* is not
meant as a slight to the Icon project, but merely a convenience when
writing about Unicon.
A quick tour of Unicon syntax and semantics.
Unicon is a very high level, network and graphic savvy, multiple paradigm
programming language. Elements of imperative, procedural, concurrent, object
oriented, reflective, and iterative programming are present and can be freely
mixed. Support library sources add more paradigms in a limited fashion, such
as interactive, list, logic and XML based programming.
Unicon counts as a curly-bracket language.
The reference implementation is written in C (and a specialized C variant
called rtt).
A Java based variant is available, Junicon,
http://junicon.sourceforge.net/site/index.html, but this version is not yet
complete in terms of runtime function support. Junicon translates core Unicon
to Groovy (for an interactive interpreter mode) or Java (for regular compiled
mode) on way to the JVM.
The rest of this page describes the reference implementation, although most of
the material would be the same for Junicon.
The Icon programming language lies at the heart of Unicon. Icon has been in
development in various forms since 1977, with predecessors including SNOBOL
and SL5, which date back even further to the 1960s. Unicon builds on the Icon
feature set.
Icon is marked as complete, and is in maintenance mode. Unicon continues to
evolve, and is in active development.
Unicon includes a vast array of features. One can look at that as tool
*bloat*; but a better, more productive, point of view is to look at Unicon as
a full tool *box*. A single, unified entity containing a well integrated
collection of mechanisms, working together to become greater than the sum of
the parts. (Without bulging at the seams).
Virtual Machine
...............
Unicon source can be compiled for a cross platform virtual machine ``ucode``
readable source and ``icode`` bytecode.
Or Unicon source can be natively compiled to binary executable form using a
``-C`` command line option. Native compiles do not yet support all Unicon
features.
Expressions
...........
Unicon is an expression language; everything is an expression, including
control flow reserved words. Unicon expressions produce a value or fail.
Expressions strive to succeed and will attempt alternatives, within the bounds
of an expression context, before producing a value or eventually failing.
This is termed **goal-directed evaluation**. Goal-directed evaluation works
hand in hand with **generators**, *mentioned below* and works best when
backtracking is kept in mind.
A nice one word synopsis of Unicon is **determination**.
Values and Types
................
There are 6 basic immutable types in Unicon:
- null (with a special keyword name, :ref:`&null`)
- integer
- real
- string
- cset (short for character set)
- pattern
Unicon is an 8 bit clean :ref:`ASCII` system, zero valued bytes are allowed in
strings and character sets. Unicon uses one relative indexing in most cases,
the first element is 1, not 0.
Values have a type, variables do not. Variables can be freely assigned any
value. All values are first class values in Unicon, and can be assigned to
variables, passed as arguments, and returned as results.
Strings are immutable, and subscript assignment or concatenate operations will
produce a new string, not change an existing string value in place.
Unicon has no pointers, but internally manages references to values.
There are high level, mutable, structured data types:
- list
- set
- table
- record
Unicon includes class and method definitions that internally use record
structures for compile time and runtime management.
Unicon also has a set of support data types:
- co-expression (including synchronous tasks and concurrent threads)
- window
- file
Variables not bound to a value default to ``null``, represented by the keyword
:ref:`&null`.
Although Unicon allows variable use without declaration, explicit control over
``local``, ``global`` and ``static`` scope is always preferred and can avoid
unintended name resolution behaviours. This can be a problem when changes to a
program introduce a new ``global`` and previously undeclared, assumed
``local``, variables are no longer local to a particular procedure.
Undeclared variable warnings can be produced with the compiler ``-u`` switch.
Numeric calculations will raise a runtime error when non numeric values (or
values that cannot be unambiguously converted to numeric) are included in a
computation.
Runtime errors normally cause an abnormal program termination with back trace,
but can be transformed and treated as failure conditions through the use of
a special keyword, ``&error``.
Automatic type coercion is attempted between integer, real, string, and
character set values as required by the surrounding expression context.
``null`` and the empty string are not promoted to zero in calculations, but
cause an aforementioned runtime error.
Division with all integer values produces an integer result. Division by zero
causes a runtime error. Zero to the power of zero is deemed an undefined
number and causes a runtime error.
Integer literals can include a base radix\ [#radix]_ prefix, and real
number literals can include an exponent notation\ [#expon]_ suffix. Base
10 integer literals can also include a scaling suffix. Integer literal
scaling includes (case insensitive):
- K scale by :math:`1024`, kilo
- M scale by :math:`1024^2`, mega
- G scale by :math:`1024^3`, giga
- T scale by :math:`1024^4`, tera
- P scale by :math:`1024^5`, peta
Integer literals can be of arbitrary magnitude.
Internally, large integers are a special type and values exceeding native
processor signed value bit widths (commonly 15, 31, or 63 bits) are
automatically managed by Unicon with special software routines. (These large
integer routines are much slower than native hardware integer computation
circuitry and are, by necessity, non-atomic when concurrency is involved).
*Although transition from native to large integer handling is automatic, and
does not usually require any attention when programming, there may be times
when explicit handling is called for.* There is a sample in the :ref:`Program
Library <IPL>` for testing when a number has been promoted to large integer
form.
String literals use double quotes, i.e. ``"a string"``.
Character set literals, called :ref:`cset` in Unicon, use apostrophe (single
quotes), i.e. ``'aaaxyz'``. Please note, ``cset`` data is a *set*. That
previous example will only contain a single occurrence of the ``a`` character
at runtime.
String literals can be extended across lines by ending the source line with an
underscore. Leading spaces on the following line are ignored.
Newlines and other non printable characters can be included in string literals
using backslash escape notation.
.. hlist::
:columns: 2
- \\b ``backspace``
- \\d ``delete``
- \\e ``escape``
- \\f ``form feed``
- \\l ``line feed``
- \\n ``newline``
- \\r ``carriage return``
- \\t ``tab``
- \\v ``vertical tab``
- \\' ``apostrophe``
- \\" ``double quote``
- \\ ``backslash``
- \\ooo ``octal byte value``
- \\xhh ``hexadecimal byte value``
- \\^x ``Control-x, x being @, A-Z (or a-z), [, \, ], ^, _``
Regular expression literals use open and close angle brackets (chevrons), i.e.
``<[a-c]>``, matches ``a`` or ``b`` or ``c`` during a match expression.
List literals are enclosed in square brackets, each element separated by
commas. Elements can be any type, including lists or other high level
aggregate types. Empty lists are expressed as ``[]``. Dangling commas at the
end of a list literal create an extra ``null`` item in the list, as do empty
intermediate entries.
List comprehensions use ``[: expr :]`` bracket colon/colon bracket syntax. The
resulting list will be all the values generated by ``expr``.
.. [#radix]
Integer literal base radix prefix is specified by a base ten number of a
base from 2 through 36 followed by a literal ``r`` or ``R``. For example
8r700 is octal notation, 2r101010 is binary notation.
.. [#expon]
Real number exponent suffixes are expressed as Ennn, where nnn is a
base ten value in the range of -308 to 308 (for 64 bit double precision
floating point). The E is case insensitive, ``e`` or ``E``.
.. index:: scope
Scope
.....
:t:`Unicon` has local, static (local), and global scope. There is also support
for ``package`` variable name spaces.
Undeclared variables inside procedures default to local scope. This can be an
issue during long term maintenance. If a global variable is later declared
with the same name, an "undeclared" procedure variable is now declared and the
procedure may inadvertently change a global value with undesirable outcome.
Long term Unicon development wisdom means fully declaring all local variables
even though it is a default semantic.
``unicon -u`` will cause a compile time error when detecting use of an
undeclared local variable. You will need to run this pass before adding
any new global variables for maximum effect in catching inadvertent name
conflicts.
Static variables are local to a procedure but retain values between
invocations of the procedure. The `initial` clause is handy for preparing
static values when more than simple assignment is required (loading tables
from disk, for instance). The ``initial`` expression is only evaluated once
per procedure during the lifetime of a program.
Procedure names are global. Procedure parameter identifiers are always
explicitly local to the procedure, overriding any global identifier lookup.
*For those rare times when a procedure needs to access a global variable with
the same name as a parameter, the* :ref:`variable` *built in reflective
function can be used*.
Record constructor descriptors are global. Although the inner field names are
somewhat local to the record (there can be duplicate member names across
different records). All instances of a record type have the same field names.
Class definitions are global. Methods follow the same inner-local sharing as
records. All instances of a class have access to all the variable and method
names of the class, but different classes may use duplicate names inside.
The `package` declaration specifies that all global symbols within the source
unit belong to a named package. All global declarations (variables, procedures
records and classes) are invisible outside the package, unless explicitly
imported. This feature, along with class definitions, uses an external compile
time database to help manage namespace and import linkage of resources within
a package.
Package management in Unicon is designed as a "programming in the large"
feature. There are some externally influenced management issues to be aware of
to ease programming at this scale. See the `package` entry and :doc:`objects`
for details.
.. index:: functions
.. _functions:
Functions
.........
Unicon builds with over 300 predefined functions\ [#funcs]_.
User defined functions\ [#term]_ are called ``procedures`` in Unicon. These
are all ``expressions`` that produce values or fail.
Unicon does not have a so called ``void`` type; there is success and a value
(possibly ``null``) or failure.
.. note::
Throughout this documentation, the terms *function* and *procedure* are
used somewhat interchangeably given the context of Unicon.
In comparison to some other programming languages, such as Pascal where
*by definition* procedures do not return values. Or in a mathematical
sense where functions do not cause side effects. Neither of those cases
hold in current or historic Unicon terminology or jargon. *Nothing will
stop you from writing code to meet those stricter definitions if so
desired, but they are not commonly used Unicon terms of art*.
Procedure names can be overridden within scoping rules.
As first class values, procedure and function references can be passed as
arguments, returned from procedures, and bound to variables.
Procedures are invoked with commonly seen ``function(args,...)`` parenthesis
syntax or ``function!list`` application.
Programmer defined control structure invocation is also possible with
``function{expr1; expr2...}`` brace syntax. See :ref:`user defined control
structures`.
Procedures can also be invoked by string name once enabled (see
:ref:`invocable`).
More technically, the syntax is actually ``expr ()``, where the invocation
operator ``()`` follows an expression, any expression.
When the initial invocation expression in an integer, it becomes a grouped
expression and the value determines the parameter to use as the result of the
entire comma separated expression group, counted from 1 going left to right.
For example: ``2(first(), second())`` is a grouped expression returning the
second result.
Procedures compiled for the Unicon virtual machine can be linked into other
Unicon programs with the :ref:`link` reserved word. The link phase is fairly
smart, and will only include procedures actually used (or set as
:ref:`invocable`), so there is no worry of overall program bloat when linking
to files that contain multiple procedures.
Without an explicit ``return`` or ``suspend``, procedures ``fail`` by default.
That means that procedures that "fall through" to the ``end`` reserved word,
``fail`` and produce no value. This has implications that developers should
keep in mind. An empty :ref:`return` can be used to avoid unexpected nested or
chained expression failure.
.. [#funcs] See :ref:`function` for details on listing predefined functions.
.. [#term]
Programmers are sometimes sloppy with the use of the term ``function``,
*this author is guilty of this technical word crime*. In mathematics a
function has no side effects and any given input will always produce the
same result. Step wise procedures and algorithms are allowed side effects
and state change can influence results. Common vernacular has led to a
situation where many (but not all) programmers use the terms ``function``
and ``procedure`` interchangeably. "functions" are often not predictably
reproducible or free of side effect.
String scanning
...............
The Unicon language includes a syntax for string scanning, with bookkeeping of
subject string and current position managed by the scanning environment.
.. sourcecode:: unicon
s ? expr
``s`` is a subject string, and the |expr| scanning expression can be
arbitrarily complex. Results can be nested in other scanning expressions.
String scanning can be far more powerful than ``regular expressions``. The
subject matter does not need to be ``regular`` or finite or free of context.
String scanning expressions can have ever changing contextual state managed
within the expression itself, and are free to move the position of interest
without constraint. *Theoretically*. You will exceed the limits of RAM and
disk space available in the world before you exceed the power inherent in
Unicon string scanning expressions. And if you think you are getting close,
Unicon also supports ``regular expressions`` and SNOBOL style ``patterns``,
so, the Universe is the limit (and then some).
Generators
..........
Functions and operators can :ref:`return` values, or :ref:`suspend` values.
``return`` places a boundary on goal directed evaluation, ``suspend`` allows
the Unicon goal-directed evaluation engine to resume a procedure and attempt
alternatives. ``return`` can be followed by any expression or if omitted,
defaults to a ``null`` value. ``suspend`` can include an optional :ref:`do`
phrase that is evaluated when the expression is resumed before following the
rest of the normal flow of control. In grand Unicon fashion, the expression
that follows ``suspend do`` can also be a generator.
Co-expressions
..............
Unicon co-expressions are encapsulated expression contexts which allow for
parallel evaluation and coroutines, among other power features, like
concurrency and multitasking.
Graphics
........
Unicon builds with 2D, and 3D graphics facilities. Unicon also ships with an
object oriented, :ref:`class` based, graphical user interface builder. The
graphics engine is event driven with features allowing for implicit and
explicit event management.
Audio
.....
Unicon supports sound, including a layer for :ref:`VOIP` if prerequisites are
available during build.
Object oriented
...............
Unicon includes class based object oriented features. This layer is an
integration of the earlier IDOL preprocessor into the Unicon core language.
Unicon classes are quite simple and yet complex; circular inheritance is
supported (*although not overly recommended unless programming routines
dealing with things like the wave/particle duality in quantum physics
theories*).
Flexibility
...........
Unicon leans to the *more than one way of doing things* school of thinking,
but there is also a tendency toward *idiomatic Unicon*, which comes with
experience and shared learning by example.
.. sourcecode:: unicon
# do some thing to each line of an open file
while line := read(f) do {
thing(line)
}
# same, without bracing
while line := read(f) do thing(line)
# another form with nested expressions
while thing(read(f))
# another form, using the generate elements operator
every line := !f do thing(line)
# object oriented forms (if f is a class instance encapsulating file)
every f.thing()
# or an alternative
while f.thing()
# others, yes there are other expression forms...
# and perhaps the idiomatic form (opinions may vary)
every thing(!f)
You are free to choose. Unicon practitioners will accept all of the above
forms as valid source constructs, but that last one sure is concise, sweet
looking code.
Unicon expression and operator syntax is so well designed and flexible
that even after 40 years of study, advanced programmers are still
impressing each other with new techniques. *Ok, maybe that is just this
author's impression from initial readings of some of the conversations
between the Unicon gurus regarding the secrets yet to discover in Unicon
syntax and idioms.*
--------
.. index:: install, build from source
Building Unicon from source
---------------------------
Now on to getting all this Unicon goodness installed on your computer.
.. only:: html
.. actdiag::
actdiag {
Developer -> Get -> SVN -> README -> Configure -> Make;
Make -> Develop -> Unicon -> Enjoy;
lane person {
label = "Developer";
Developer [shape=actor, label="", color="gray"];
Get [label="Get the source", color="lightgreen"];
README [color="lightgreen", label="Peruse README"];
Develop [color="lightgreen"];
Enjoy [color = "lightgreen"];
}
lane machine {
label = "Computer";
SVN [label="svn checkout url-svn", color="lightcyan"];
Configure [label="./configure", color="lightcyan"] ;
Make [label="make", color="lightcyan"];
Unicon [label="unicon program.icn", color="orange"];
}
}
Where ``url-svn`` is ``svn://svn.code.sf.net/p/unicon/code/trunk unicon-svn``.
``./configure`` options are explained in more detail in the ``README`` file. For a
a list of build options, use ``./configure --help``.
GNU/Linux
.........
In the instructions below, ``working-dir``, ``install-dir``, and
``unicon-projects`` are *dealer's choice* directory names (pick a name
appropriate for the local system).
Unicon follows the de facto standard ``./configure; make; sudo make install``
paradigm. There are quite a few options to allow for customized builds. See
``./configure --help`` for details of all the build options. Enable and
disable features and components during the ``./configure`` phase.
- Get the code
::
prompt$ cd $HOME/working-dir/
prompt$ svn checkout svn://svn.code.sf.net/p/unicon/code/trunk unicon
prompt$ cd unicon
- Configure
::
prompt$ ./configure
- Make
::
prompt$ make
- Prep: (somewhere in :file:`~/.bashrc` [#startup]_ add)
::
# add unicon
add-unicon () {
if [[ ! $PATH =~ unicon ]]; then
PATH="$HOME/working-dir/unicon/bin:$PATH"
export PATH
fi
}
You will now have an ``add-unicon`` shell function available. Set it to load
during startup or type the command when you want to have ``unicon`` tools
available.
Or simply use ``make install`` to install Unicon to the configured locations.
- Invoke
::
prompt$ source ~/.bashrc
prompt$ add-unicon
The above step will not be necessary if ``make install`` was used.
::
prompt$ cd $HOME/unicon-projects/
prompt$ cat hello.icn
.. literalinclude:: examples/hello.icn
:language: unicon
.. only:: html
.. rst-class:: rightalign
:download:`examples/hello.icn`
.. command-output:: unicon -s hello.icn -x
:cwd: examples
Party, *like it's 2099*.
- Install
The Unicon source build creates a directory structure and command sequence so
the only thing you really need to do is set the PATH to the ``unicon/bin``
directory. This layout knows where the link libraries are, include
subdirectories, etcetera. If you like a little more control over the
placement, then read through ``$HOME/working-dir/unicon/Makefile`` for details
on setting up an install with::
prompt$ sudo make install
If using the default prefix (``/usr/local`` usually), the above command
(usually) requires ``sudo`` or run the command as the root super user so the
installer has permissions for the system directories.
There are older Make rules to control this as shown below, but using the de
facto standard DESTDIR and PREFIX settings are now recommended.
::
prompt$ make Install dest=install-dir
You can change the ``add-unicon`` function to set the path to this shiny new
``install-dir/bin``, (or, just export that bin path). The ``add-unicon``
function is handy when initially trying out a Unicon build, but you will
probably find that setting the Unicon path becomes part and parcel of your
shell login. *I never type add-unicon anymore, the Unicon path setting is
built into the shell startup now.*
- Package repository
As of Unicon 13.1, Jafar has created package build rules, which can be used to
build your own binary packages. Jafar has also created a PPA (Personal
Package Archive), which can be used to automatically stay up to date with
binary builds of Unicon on Ubuntu. No sourcing around required.
- sudo add-apt-repository ppa:jafaral/unicon
- sudo apt update
- sudo apt install unicon
- Time to enjoy programming in Unicon
Things should now be ready to go; so on with the show...
*But first, a brief word from our sponsors* ... *the people that created
Unicon, not advertising, this is free documentation*.
Feel free to skip over some of this *very exciting* background and history
information and get right into :doc:`datatypes`, or hit :doc:`tools` and leap
right into developing, compiling, and running ``Unicon`` programs.
.. [#startup]
There are quite a few options for shell start up scripts.
:file:`~/.bashrc` is just one of the options. Your local site setup may
use :file:`~/.bash_profile` (which is actually the more current and
correct form of interactive shell start up control, but this author has
been using :file:`~/.bashrc` for over two decades now, and it's an old,
hard to break habit). There are also system wide startup scripts,
:file:`/etc/profile` for instance. Shells other than :command:`bash` will
have different options, and other operating systems will have completely
different details when it comes to setting the :command:`unicon` command
path. Consult your local documentation.
--------
.. index:: history
.. _history:
History
=======
In the early 1960's, :ref:`Ralph Griswold`, :ref:`David Farber`, and
:ref:`Ivan Polonsky`, formed the core team that designed :ref:`SNOBOL`.
*What follows is part lore, part fact, the facts somewhat lost in the mists of
time*.
SNOBOL was a renaming of :ref:`SEXI`, String EXtraction Interpreter, a name that
eventually caused the core team pause, when clerical staff would be smirking
while handing over printouts with title pages of SEXI Ralph Griswold, and SEXI
Dave Farber. The story goes that SNOBOL, StriNg Oriented symBOlic Language,
was a hard found name after hearing "This program doesn't have a snowball's
chance in ..." and SNOBOL was so named, and backronymed later.
.. image:: images/xkcd-1755-olddays.*
:align: center
:alt: XKCD Old Days
.. only:: html
.. rst-class:: rightalign
*XKCD* http://xkcd.com/1755/ by Randall Munroe :ref:`CC BY-NC 2.5 <CC BY-NC 2.5>`
.. only:: not html
*XKCD* http://xkcd.com/1755/ by Randall Munroe :ref:`CC BY-NC 2.5 <CC BY-NC 2.5>`
*Less folklore, more factful, now*.
:ref:`Icon` was a continuation of the string manipulation and pattern matching
strengths of SNOBOL but with a design more in line with ALGOL source code form
and other structured programming languages of the mid 1970s.
.. pending image:: images/iconcube.*
:align: center
:target: http://www.cs.arizona.edu/icon/
.. figure:: images/iconcube.png
:align: right
:alt: Icon cube
*The Icon cube*
Icon is just a name, coined before graphical desktops, and before icons as we
now know them.
Icon pioneered many key concepts that still influences programming language
design and development, and in some ways might be seen as surpassing even the
most modern language feature sets. Generators, goal-directed evaluation,
chained expressions, string scanning and pattern matching to name a few.
Dr. Griswold had less concern for the commercial success of Icon than the
educational potentials of the language. The sources are in the Public Domain,
along with the main books about Icon. This may be part of the reason for Icon
remaining a relatively obscure programming system; lack of commercial backing
meant that there was little vested corporate interest in developments, while
at the same time garnering great respect from the professionals and students
that got a chance to write code in Icon. Icon was developed, from the ground
up, to be very cross-platform, but was not designed to seed any corporate
empires.
This author's first exposure was in the mid 1980s. Having convinced management
to allow some after hours work on another team's VAX/VMS system. They had a C
compiler. We had :ref:`VMS` and :ref:`Forth`, but the other team had a DEC C
compiler. I spent a couple of evenings, off the clock, building an early
version of :ref:`GCC`. That became our team's C compiler. While we were a
Forth shop, having access to C was a boon for some side projects. A few other
evenings later, still off the clock, I built a version of Icon v6 for the
:ref:`VAX`. That soon became an even greater boon for other side and support
projects. Icon can easily chew through utterly complex, raw and structured
data, outputting formats that suit the need of the moment. Icon was put to
great use. As a side benefit, :ref:`Farberisms`, *as the application message
of the day*, was very well received by the telco engineers we supported at the
time.
A few years later, and we had VAX/VMS upgraded with X11 (DECWindows) so the
install of Icon was updated with graphics support built in. That is when
Clint Jeffery's name started making the rounds with the team.
There were early extensions built for Icon; IDOL an object oriented layer,
being one of them. That and other extensions, in particular the POSIX
features, were morphed into early versions of Unicon by Clint Jeffery and
friends.
The Icon roots
--------------
The University of Arizona Computer Science Department is in charge of the Icon
project, and it remains the Icon project. Out of respect for the late Dr.
Griswold and his desire to freeze the Icon feature set, :ref:`Icon` is in
maintenance mode, a completed project. Releases are now only produced for
minor updates or when surrounding C compiler and operating system changes make
it a necessity for clean Icon source code compiles.
--------
And then Unicon
---------------
Unicon is not an official updated version or release of Icon, it is a separate
project. Unicon builds on the public domain :ref:`Icon version 9` sources,
and extends those sources out from a very mature, stable code base. Core
Unicon is a mature product yet still in development. Clinton Jeffery has been
involved with the lead Icon and Unicon development teams since the early days.
Now, in 2016, Unicon has established itself well. A feature rich, actively
developed programming language, ready and able to take on the internet, and
pretty much any problem deserving an automated solution.
.. figure:: images/uniconart.*
:alt: Unicon Art by Serendel Macphereson
*Unicon art, by Serendel Macphereson*
.. pending image:: images/uniconart.*
:align: center
:alt: Unicon Art by Serendel Macphereson
.. *Unicon art, by Serendel Macphereson*
:ref:`jafar` celebrated his 10th anniversary with the project on 2016-08-06.
Nice. :ref:`Clint` has got to be approaching a 30th, or more, Icon years
included. Active developments abound. SNOBOL and regex patterns added to
augment string scanning, all the network messaging protocols, audio and VOIP,
and continual polish and new features. :ref:`Parlett` has created some
terrific code in the ``uni`` directory that ships with the source code, and
highlights the object oriented features of the system. Unicon is a stable,
yet still expanding programming environment. Release 13 alpha is looking
awesome.
*Side blurb:* Almost all the samples in this document are captured while the
documentation markup is processed into HTML and PDF (and the other output
forms). The early pages, August 2016, are all processed with builds of Unicon
13 alpha, pulled live from the SVN source repository on a regular basis, and
rebuilt, before each writing session. Stable. (*Or if not stable, you will be
reading a book full of bugs and broken examples. I bet you are not reading a
book full of build bugs. There* :strike:`might` *will be some mistakes, but
blame the document, not Unicon, for those failures.*)
.. note::
Please be aware that this document is written by an interested programmer,
not by the good folk that work on the internals. Unicon is already a very
well documented system, and these pages are meant to augment and by no
means replace any previous efforts. If there are discrepancies, treat this
document with suspicion, and the original source as likely correct and
more accurate.
See
- http://unicon.sourceforge.net/ubooks.html
- http://unicon.sourceforge.net/reports.html
and
- https://www.cs.arizona.edu/icon/
for access to a vast array of high and low level notes, guides, manuals,
references, thesis, and other documentation. Hint hint, TR78-3 is cool.
1978. The Icon Overview.
- https://www.cs.arizona.edu/icon/ftp/doc/tr78_3.pdf
--------
.. index:: people
.. _people:
People
------
.. index:: Jeffery; Dr. Clinton, Clint
.. _Clinton Jeffery:
.. _Clint:
Clinton Jeffery
...............
Team lead for the development of the Unicon programming language.
University of Idaho, Computer Science Department.
.. index:: Mohamed; Shamim
Shamim Mohamed
..............
Worked with Clinton on the original creation of Unicon; POSIX layer.
.. index:: Balbi; Federico
Federico Balbi
..............
Unicon contributing developer; ODBC interface.
.. index:: Parlett; Robert
.. _Parlett:
Robert Parlett
..............
Unicon contributing developer; Packages, tools, class libraries.
.. index:: Al-Gharaibeh; Jafar
.. _jafar:
Jafar Al-Gharaibeh
..................
Unicon contributing developer; concurrency, 3D graphics.
.. index:: Mahmoud, Qutaiba
Qutaiba Mahmoud
...............
Added support for pseudo terminals in Unicon.
.. index:: Griswold; Dr. Ralph, Ralph
.. _Ralph Griswold:
.. _Ralph:
Ralph Griswold
..............
Dr. Ralph Griswold, 1934-2006
Computer scientist, designed and developed SNOBOL, SL5, and Icon
https://en.wikipedia.org/wiki/Ralph_Griswold
.. index:: Farber; David
.. _David Farber:
David Farber
............
Professor of computer science.
https://en.wikipedia.org/wiki/David_J._Farber
Famous for many things in the field, including :ref:`Farberisms`.
.. index:: Polonsky; Ivan
.. _Ivan Polonsky:
Ivan Polonsky
.............
Computer scientist, designed and developed SNOBOL.
The Unicon Citizen list
.......................
This list is taken from the Unicon project page, at
http://unicon.sourceforge.net/citizens.html
It is separately maintained, and these people deserve the pride of place
within the Unicon ecosystem. The Citizen list is included here for
completeness, but may not always be in synch with the list given above and
will include duplicates.
*A future release of this docset will merge the two lists and hopefully expand
on the entries, as these are the people that we all owe a round of thanks to
when programming in Unicon.*
Federico Balbi
Developer of the ODBC/SQL interface.
Nolan Clayton
Contributor to the Unicon IDE.
Sudarshan Gaikaiwari
Developer of snobol-style pattern datatype, along with operator
overloading.
Jafar al Gharaibeh
Dr. al Gharaibeh developed the concurrent programming feature and has been
an extensive contributor to the 3D facilities.
Clint Jeffery
Father of Unicon, his mission is to make Icon's core expression semantics
useful in as many applications and to as many programmers as possible.
Susie Jeffery
Contributor to the GUI class library, including (especially) the
editabletextlist widget.
Steve Lumos
Developer of the messaging facilities. Co-administrator of the Unicon
sourceforge site and mailing list.
Kazimir Majorinc
Founder of The Generator.
Naomi Martinez
Developer of Unicon's 3D graphics facilities.
Shamim Mohamed
Developer of the POSIX interface, coauthor of the Unicon book; he coined
the name "Unicon".
Shea Newton
Author of Unicon 12's benchmarks.
Robert Parlett
Author of Unicon's package mechanism. Developer of many class libraries
and the IVIB interface tool. Coauthor of the Unicon book chapter on
graphic interfaces.
Ray Pereda
Ported Berkeley YACC to Icon; his iyacc is used in the Unicon translator.
Coauthor of the Unicon book chapters on compilers and genetic algorithms.
Katie Ray
Author of the Ulex lexical analyzer generator.
Hani bani Salameh
Contributor to the Unicon IDE.
Barry Schwartz
Primary contributor to AMD64 port, including its co-expression switch.
Ziad al Sharif
The first Unicon Ph.D. and author of the UDB source level debugger.
Phillip Thomas
Chief critic, user, tester, and visionary supporter.
Ken Walker
Honorary Unicon citizen who developed iconc, the Icon optimizing compiler
which forms the basis for "unicon -C" on some Unicon platforms.
Steve Wampler
Technical reviewer and major contributor to multiple epochs of Icon and
Unicon.
Mike Wilder
Wrote uniconc, a port of iconc to support almost all of Unicon on Linux.
Implemented vector hashing code which improves type inferencing
scalability.
..
--------
.. |gnulinux| image:: images/gnulinux.png
:align: bottom
.. |vimcreated| image:: images/vimcreated.png
:align: bottom
.. |sphinxdoc| image:: images/sphinxdoc.png
:align: bottom
.. |builtwithunicon| image:: images/builtwithunicon.png
:align: bottom
The documentation developed with, and powered by:
============== ================ =============== =====================
|gnulinux| |vimcreated| |sphinxdoc| |builtwithunicon|
============== ================ =============== =====================
GNU/Linux Vim editor Sphinx docgen Unicon
============== ================ =============== =====================
.. only:: html
..
--------
:ref:`genindex` | Previous: :doc:`index` | Next: :doc:`datatypes`
|