Help Wanted!

The Unicon project is looking for help on the following topics as of 5/2015. Thanks to Hugh Sasse for improving the HTML and adding a table of contents!

Most of these topics are requests from the user community. Many of these would make excellent independent study or thesis topics. Net volunteers are also welcome. Anyone willing to pay for any of these projects should drop me a note, and I will hire appropriate students to do it at their bargain wage rates.

An asterisk (*) in the title indicates that Somebody is believed to be working on that topic, or has implemented a feature not yet adopted in the Unicon baseline.


The Unicon Translator .
Iconc, the optimizing compiler .
The (Un)icon VM and runtime system .
Debugging Tools .
Fonts .
Additional OOP Features .
Patterns .
Script support .
Programming Environment .
Easier C-calling interface .
Embeddability; easier calling from C .
Printing Support; Report Generation .
Messaging extensions .
Binary distributions .
Windows-native features .
Google Protocol Buffers .
Unicon for Small Systems.
Compressed Archives.
Storing Structures to Disk .
Immutable Structures .
Graphics .
Parallel Computation Support .
Persistent Structure Types .
Enhance error diagnostics .
IDE - IVIB integration .
Benchmarks .

The Unicon translator.

The Unicon translator (unicon) is written in Unicon and has evolved since around 2000. Purpose: core language. Skills needed: Unicon expert, compilers.

Iconc, the optimizing compiler.

Unicon source distributions incorporate Icon's optimizing compiler iconc, which is built separately ("make Uniconc") and accessed using "unicon -C" on Unix-based systems with an available C compiler. Purpose: faster execution. Skill needed: C expert.

The (Un)icon Virtual Machine and runtime system.

Much of the Unicon virtual machine was written in C in the early 1980's. The VM runtime system was altered in the early 1990's to use an extended-C syntax called RTL (runtime language). This allowed it to be used for both Iconx and Iconc. Skills needed: C expert.

Debugging Tools.

We have gone to considerable effort (like, my Ph.D. dissertation) to enable the authoring of advanced tools for Unicon in Unicon. Our debugging facilities need to be extended to be able to handle new features such as threads. Skills needed: Unicon expert.


Fonts are an important aspect of widening Unicon's suitability to more applications. They are at present the single biggest obstacle to portability across platforms. Skills needed: C expert.

Additional OOP Features.

Skills needed: Unicon expert and/or C expert.
Class Variables
Some additional syntax is needed to make it more convenient to declare variables who are shared among all instances of a class. Currently you can achieve this effect using globals and packages, and method static variables are shared among instances, but a more direct syntax would be handy.
Private and Read-Only-Publics
Unicon's predecessor Idol had private semantics and a public keyword. Private semantics were dropped because they added to complexity and space consumption without adding functionality. But arguably they have value and should be an option. While a distinction between private and protected does not seem very useful in Unicon, a scope that would be really useful would be a read-only public designation, to avoid the need for many accessor methods.


The existing work on a SNOBOL-style pattern data type needs to be integrated better with string scanning. Skills needed: C expert. *Status: a current M.S. thesis project is making headway on this.

Script support.

Iconx needs to be extended to support directly executing .icn source files. Also, support for "one-liners" where the source code is supplied as a command line option. Icon 9.5 added some support for this on UNIX; for Unicon we need a multiplatform solution if possible.

Programming Environment.

Better programming tools are always in demand. An interactive interpreter, or an incremental compilation system, would make an excellent project. There are several ways to execute new unicon on the fly that was typed in interactively:

using system()
slow, doesn't pass non-string parameters easily
using load()
but load() does not "link" into the current program, and currently does not support calling procedures in another program directly, one would have to use a co-expression to change control to the other "program" and then call a desired procedure via some wrapper code. Also, load()'ing a lot may have garbage collection issues that haven't been discovered yet.
develop a new mechanism for linking and loading COMPILED Unicon code as a .so/.dll per loadfunc()
developing a pure interpreter
for strings or syntax trees constructed from a parse of the code.

As an experiment, I wrote a little program that reads lines from the user, and for each one, calls an eval(s) function that writes it to a file, compiles it, uses load(), and activates it. This is "slow", but runs in well under a second, it is not obvious that we have to discard unicon/icont and go with some pure interpreter in order to provide this type of service on modern machines. Handling stored procedures and globals in such an interpretive environment requires more thought, but still seems doable, and would be useful to experimenters and new users.

Easier C-calling interface.

Udaykumar Batchu performed a project to simplify the calling of C functions from within the runtime system, improving on the traditional Icon loadfunc() dynamic loading utility. His work needs some refinement, and student Vincent Ho suggested an "inline C" capability that would fit in nicely. It would be interesting to add such a capability to the compiler and to the interpreter. Skills needed: Unicon expert. C expert.

Embeddability; easier calling from C.

It has been requested that we make the interpreter embeddable within C/C++ applications. Developing a standard mechanism for turning the Unicon VM into a callable C library would make an interesting project. Skills needed: C expert.

Printing Support; Report Generation.

The graphics facilities would benefit from multiplatform printing support, including the generation of postscript or pdf. The database facilities would benefit from a report generator similar to crystal reports. Skills needed: C expert.

Messaging extensions.

The messaging facilities done by Steve Lumos support popular protocols such as HTTP and POP. One thing we need to do is port these from UNIX to Win32. Another thing we need to do is add protocols. We would especially like to see SSL support added, using OpenSSL or some other free implementation of SSL. A critical extension for e-mail support is SMTP AUTH, the authenticated version of the SMTP protocol. We also need FTP, IMAP, NNTP, ...

Windows-native features.

Single-platform enhancements are uninteresting to users on other platforms, but occasionally they are necessary or useful in making Unicon suitable for applications that it otherwise would not be used in. Skills needed: C expert.

There are currently 11 Windows-native functions in the Windows versions of Unicon, implementing buttons, scrollbars, menubars, edit regions, and various dialogs. A larger set-of Windows native GUI capabilities might allow applications to look more "native" on Windows and be usable by screen readers.

One of the requested Windows-specific features is COM support. The technical questions are: (a) is a platform independent interface possible (to support CORBA or javabeans as well, for example, and (b) how high-level can we make this API?

Porting iconx to be an Active Script Engine (at one time documented in the "Visual Programmer" column from Microsoft Systems Journal online) would allow Icon to be an embedded scripting language for many Windows applications.

Google Protocol Buffers.

Skills needed: C expert.

Additional means of automating the transmission of structured or binary data would be valuable to Unicon -- Google's Protocol Buffers are an example.

Unicon for Small Systems*.

Skills needed: C expert.

New platforms of particular interest are smartphones and tablets. There was at one time a preliminary WinCE port including much of the 2D graphics facilities. It might or might not be of any use for a modern Windows phone port. It needs extensions in several areas, such as networking, and a strategy for adapting existing Unicon GUIs to the small screen (touch support, enhanced screen size portability). *Status: a current Java-based Unicon implementation project may be a starting point for a new effort here.

Compressed Archives.

It would be neat if Unicon handled common archive and compressed archive formats such as .zip as easily as it does other file types. Skills needed: C intermediate.

Storing Structures to Disk.

It would be useful to add I/O modes in which arbitrary structure values (tables, objects, etc) could be written to and read from disk, making something like encode()/decode() a built-in. Skills needed: C intermediate.

Immutable Structures.

Unicon's structure types are all mutable, making them next to useless as hash keys. Adding a "freeze" bit, a promise from then on that a structure would never be modified, would enable them to hash on contents instead of on serial number, and might enable various optimizations. Skills needed: C intermediate.


Skills needed: C expert. Graphics API expert.

Parallel Computation.

The rise of multi-core CPU's made it inevitable that Unicon should be extended to support parallel computation, so it was. The interesting questions now are whether it can be extended to support implicit parallelism. Skills needed: C expert

Persistent Structure Types.

It would be neat if Unicon supported persistent structures, structures that survive across program executions. An approximation of this can be accomplished by storing xencoded structures in GDBM files, but it would be nice if it were easier and more direct. Skills needed: C expert

Enhance error diagnostics.

The error messages, particularly from the runtime system, can be enhanced to improve readability and help the programmer have a clue of how to fix the problem encountered. Long error tracebacks should be written to a file and a terser summary printed to standard error output. The default diagnostics style should be friendlier to new Unicon programmers. It might be possible to load/attach udb when a runtime error occurs. Skills needed: C intermediate.

Icont's parser needs to be modified to work with any YACC implementation. At present it fails on some 64-bit Linuxes if -O2 is turned on, apparently due an issue in the old AT&T YACC parser skeleton.

IDE - IVIB integration.

The unicon IDE and IVIB need to to be joined together. Skills needed: Unicon intermediate.


Unicon 12 has a benchmark suite, described in UTR16. It does not yet benchmark all important language features, but does reveal a lot about Unicon's performance. *Status: The public is invited to improve the benchmark implementations, report performance on varying platforms, and propose benchmarks that would improve the suite.

Binary Distributions.

At present, Unicon binaries are only available on MSWindows -- other folks have to build from source code. Unicon needs volunteers to regularly build, test, and submit Unicon binary distributions on their preferred non-Windows platforms, including Mac, Ubuntu, Fedora, etc.

Marketing and Promotion.

The Unicon project is in need of one or more evangelists to see it as their mission to spread the use of the language wherever it is beneficial to do so.