Help Wanted!

The Unicon project is looking for help on the following topics as of 4/17/2010. 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 Unicon preprocessor itself is an appropriate place to implement a number of classic, easy optimizations such as constant folding and common subexpression elimination. Amazingly, icont does not do these. I would also like to see strength reduction, not only for classic arithmetic operations but for string processing; for example, changing upto('s') to find("s"). Also, there are obvious conversions to avoid at compile time, such as changing write(1) to write("1") and the like.

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. As another example, in many or most calling contexts, the translator can identify when a generator cannot be resumed. If this information were passed into the invocation, a suspend might be promoted into a (much faster) return expression.
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.
cset keyword conversions -- are keywords such as &lcase converted to strings often enough to warrant special-cases in the cset conversion code?
Avoid one-char allocations-- Many functions such as map() would not need to allocate a string from the heap, if that string were of length 1, they could just return a pointer to that character in static memory.
Improve large integer string conversion -- A large integer such as 5^4^3^2 takes a long time to convert to a string, like 4+ minutes on an older amd64! This could be made much faster, possibly by reimplementing large integers using GMP or altering their representation to be base-10-compatible on a per-largeint-chunk basis.

Debugging Tools

Unicon Debugger Enhancements -- The monitoring facilities described in the book "Program Monitoring and Visualization" have been used to produce an extensible source level debugger, udb. However, this debugger is relatively new and can use further refinement.
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
The existing 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

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

Direct3D port. Due to Microsoft's shameful crippling of OpenGL on that platform, if someone writes a Direct3D port of Unicon's 3D facilities, Unicon 3D will be more useful.
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. Prototyping for this effort showed that a Cocoa GUI thread creating and calling a VM thread was the right way to organize this execution model.
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. Work is currently underway on a pthreads-based concurrent VM.
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.
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.
Benchmarks
Icon's benchmark suite from long ago is inadequate to compare performances usefully on modern systems. We need a new benchmark suite that (a) exercises the various features of the language, and (b) ideally would fit in with a portable benchmark suite used to compare performance across other very high level languages.