Help Wanted!

The Unicon project is looking for help on the following topics as of 2/25/2021. Thanks to Hugh Sasse for improving this page.

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. (S) after the title indicates that this project would be particularly suitable for a student volunteer.

Contents

The Unicon Translator
Iconc, the optimizing compiler
The (Un)icon VM and runtime system
Debugging Tools
Fonts
Additional OOP Features
Script support
Programming Environment
Easier C-calling interface
Python-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
Marketing/Recruiting/Promotion
Java Runtime System

The Unicon translator

The Unicon translator (unicon) is written in Unicon and has evolved over time. Purpose: core language. Skills needed: Unicon, compilers.

Iconc, the optimizing compiler

Unicon source distributions include 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, a 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 newer language features. Skills needed: Unicon expert.

Fonts

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; possibly a "class static" storage 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.
Instance Variable Initializers
Someone added a "local" syntax for class instance variables, as an alternative to the syntax based on record declarations. But, that local syntax apparently does not support initializers correctly.
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.

Script support (S)

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 and C expert.

Python calling interface

It would be nice if Unicon programs could call Python. It would be nice if Python programs could call Unicon. It would be nice if we figured out ways to make this fairly easy to do. Skills needed: Unicon/C/Python 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.

Automated Testing (S)

Unicon has a test suite that covers many of the language features. However, the test suite can be improved in two ways: first, extending the tests to cover more features, especially the new ones that are under-represented. Second and more importantly, automating multi-platform testing. With light weight virtualization technologies such as LXC, Unicon binaries can be quickly built and tested on a variety of platforms with a mix of 32/64 bit and x86/arm guests to ensure no build problems or bugs. Skills needed: Unicon Language, scripting and virtualization.

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 have simple SSL support, but it may need enhancement. 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.

Java Runtime* (S)

Skills needed: Java proficient.

Our sister site, junicon.sourceforge.net, is the host for a new Java-based implementation of a Unicon-like language called Junicon. The Junicon translator actually translates to either Java or Groovy, and can target either compiled bytecode or interactive interpretation. What Junicon needs in order to be publically released is a runtime system; specifically, a large number of built-in functions, including I/O facilities, to enable it to run typical Icon and Unicon programs unmodified. *Status: many built-in functions have been developed by Junicon's author, and more were implemented by an undergraduate research assistant. Subsequently, a UIdaho senior design project developed a large number of the unimplemented features for Junicon. This work needs to be merged into the main Junicon repository. Another effort to develop a Java+libGDX implementation of Unicon's graphics facilities probably needs to be revisited in light of the Unicon OpenGL 2D graphics implementation.

Compressed Archives (S)

Unicon should handle 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 (S)

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.

Graphics

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. Status: all of this is about finished, except the "load udb when a runtime error happens" part.

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 (S).

The unicon IDE and our interface builder IVIB need to to be joined together. Level 0 of this would be: the two binaries built into one program that switches back and forth with no coordination, communicating only through files, and equivalent to running the programs independently. Level 1 would add file save checks and automatically loading the selected file when switching. Level 2 might reach a point where no file I/O is needed in order to switch back and forth. Compare with Visual Studio or Netbeans. Skills needed: Unicon intermediate.

Benchmarks*

Unicon's benchmark suite, described in UTR16, 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. Additional concurrency benchmarks have been requested.

Binary Distributions

Traditionally Unicon binaries were only available on MSWindows -- other folks had to build from source code. Some Linux and Mac binaries have been developed in recent years, including Debian and MacOS Sierra binaries, but we need 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.