Help Wanted!

The Unicon project is looking for a Few Good Men and Women to work on the following topics. 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.

Iconc, the optimizing compiler

Dead Code Elimination -- Icon's optimizing compiler needs to remove unreferenced procedures and classes prior to type inferencing.
Compiler Optimization -- Iconc can use further optimization, both of its own operation and particularly of its generated code. An earlier successful project showed me than even an enterprising undergraduate student can make a real difference.
Windows Compiler -- Iconc needs to be ported to Windows, preferably using a free Windows C compiler. The win32/gcc configuration provides a starting point.

The (Un)icon Virtual Machine and runtime system

VM optimization-- The virtual machine translator (icont), and the interpreter and runtime system (iconx) can be further enhanced for better performance. For example, the memory allocations performed during most string subscripts can be avoided with a relatively simple addition of a new virtual machine instruction.
VM translator type inferencing -- The type inferencing mechanism used by iconc has been sped up to the point where type inferencing could be used to direct VM optimizations, not just C-compiles.
Compact structure representations -- Common special-cases of data structures should have special-purpose representations to save space and time. For example, static size lists and tables whose values are all integers, or all reals, deserve a special internal type.
Dynamic Interpreter Stack -- Short of infinite recursion, it should be almost impossible to cause an interpreter stack overflow. Perhaps Icon's own list data type could be used to implement a dynamic interpreter stack. Alternatively, checking and realloc'ing the interpreter stack might work.
VM dynamic code-- The dynamic loading facility built-in to Unicon needs to be supplemented and extended with dynamic linking to allow new code to be generated and executed on the fly.
Portable bytecode-- It would be nice if Unicon executables could be delivered in a machine neutral format, similar to the Java VM.

Debugging Tools

Unicon Debugger* -- The monitoring facilities described in the book "Program Monitoring and Visualization" have not yet been fully exploited to produce integrated production-quality debugging capabilities. Some additional enhancements in the VM might be coupled with creative design in an Icon debugger (or suite of debuggers) written in Icon.
Unicon Profiler -- A good profiler would tell time and space information about Unicon program executions, including runtime system time and and space, not just source code modules' time and space. Line-level, and built-in level details are needed.
Unicon Lint -- A "lint" for Unicon would detect bugs and probable bugs by static analysis. For example, redundant/repeated type conversions.

Fonts

Unicon Freetype* -- Unicon should add support for the Freetype font engine and provide a set of portable fonts that match, pixel-for-pixel, on all window systems.
Unicon Unicode -- Unicon should add support for Unicode and/or other >8 bit character sets.
Unicon Native Fonts -- It would be nice if Unicon could add new fonts dynamically, in order to support interesting languages that are not well supported by operating systems.
Unicon Deadkeys -- The iconx X11 client code should be updated to use X11R5+ support for locales and "dead keys" to compose accent characters using XmbLookupString and/or the LC_CTYPE stuff.

Additional OOP Features

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.

Patterns

Preliminary work on a pattern data type needs to be integrated better with string scanning.

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

Undergrad-level project: develop a "library" model for Unicon modules, calling them through a co-expression interface using wrapper procedures
Grad-level independent study: fix the VM so inter-program procedure calls work safely.

developing a new mechanism for loading COMPILED code as a .so/.dll as 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 recently 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.

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.

Two-way Pipes

Our ability to create two-way pipes needs to be extended to support external processes that think they are talking to a tty -- we need easy built-in capabilities similar to the popular expect(1) tool.

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.

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

One of the most oft-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 (see 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

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

New platforms of particular interest are PDAs. David Price has performed a preliminary WinCE port including much of the 2D graphics facilities. It needs extensions in several areas, such as networking, and a strategy for adapting existing GUI windows to the small screen (scaling them, or adding automatic scrolling).

Improving reads()

reads(f,n) is often used to read large data in a contiguous chunk. If the amount is not known, it is tempting to use a very large n to get all available data, but asking for a number such as 1000000000 bytes attempts to physically allocate that many bytes, even if the actual data is much smaller. A smarter strategy should be implemented.

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.

Storing Structures to Disk

It would be interesting 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.

Graphics

When a window (possibly 2d, offscreen) is used as a Texture on a 3D object, it should be updated with current contents every time the 3D object is redrawn. :-)
Unicon should support PNG as a standard graphics format.
Subwindows (at least) should support a borderwidth attribute, and have the option of having no border. Perhaps main windows too.
Mac* - We need a Macintosh programmer, proficient in (or willing to learn) native Mac graphics API's, to complete the Mac port of the graphics facilities. A QuickDraw version reached alpha-stage at Icon 9.3.1 but were not distributable. At this point we probably should axe that codebase and instead pursue a Quartz port for Mac OS X.
Other platforms? - We want our portable graphics on all platforms for which our community wants to program. For example, we had an earlier port to OS/2 Presentation Manager, back when that was in wide use.

Parallel Computation Support

The rise of dual-core CPU's makes it inevitable that Unicon should be extended to support parallel computation. The interesting questions are whether it should support implicit or explicit parallelism or both.

Threads

Icon and Unicon support a co-expression data type that is a synchronous thread. How might this type be extended to support true parallel operation? A central challenge would be: how do we make the runtime system (particularly the garbage collector) thread-safe? One option is for a garbage collection to stop all threads, another is for threads to continue to execute until two (or several) of them need to garbage collect. A third option would be to go to a real-time incremental garbage collection model.

DataParallel Operators

Unicon should support (deep) structure-at-a-time operators, such as L1+L2 producing a list L3 with elements of L1 pairwise-summed with L2.

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.

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.

IDE - IVIB integration

The unicon IDE and IVIB need to to be joined together.