Tart release criteria, revisisted

The last time we talked about this (November 2010), we talked about what things needed to be done before I could make an official "0.1" release of Tart. One of the items discussed was garbage collection, which has now been implemented. Although the collector is very rudimentary level (for example, the heap is a fixed size, and there's no way to increase it), I'm satisfied that it is functioning at a level that it should no longer count as a release blocker.

Other features that have been implemented during this period were variadic templates, integer parsing, and improved debugging support.

The next question is, what are the remaining release blockers? Here's my current list.

• Packaging and installation. At the moment, the only way to run the tart compiler is to check out the source tree and compile it. There is no "make install" build target or package builder. There are a number of tasks which need to be done:
• CMake supports installation via the 'install' command - this creates the appropriate 'make install' targets. There is also CPack, a companion to CMake, which will generate package installers for various platforms.
• TASK: investigate these tools and write the appropriate rules for the Tart build files. This needs to include:
• Executables tartc and tartln
• Bitcode files for the standard library and the testing library.
• The static library for the Tart runtime.
• Shared objects for the Tart linker plugins (these plug into LLVM tools for people who don't want to use tartln).
• Possibly docs, although maybe those should have a separate install.
• Currently the Tart compiler has no way to import a compiled module - it has to reparse every imported module from source. This means that a Tart installation will have to install all of the source files for the standard library somewhere. It would be much better to have a single library file for the standard library. The plan is to serialize the AST tree for a module as metadata nodes in the LLVM bitcode files. That way, when all of the bitcode files for the standard library are linked together, the compiler can simply import this one file and find the definitions of all the standard library classes within it.
• TASK: Implement serialization (both directions) of the AST for a module.
• TASK: Implement some scheme for determining if the AST in a library is out of sync with it's source, so that the compiler can use the up-to-date source if it's available.
• Samples. It would be good to have some sample programs, in particular samples that have build scripts that don't require the full Tart source tree and don't require CMake.
• Because the Tart compiler and linker are only part of a tool chain for creating programs, we need to explain to people all of the steps needed to create a program.
• Input. The Tart I/O library is incomplete, and in particular there's no means to read from stdin or the command line.
• TASK: Finish the implementation of StdFileStream to allow for reading from a file.
• TASK: Work on a library for passing command-line options. I done a little bit of work on this, but it's not checked in.

Of course, some of the above tasks are not required if we're willing to stipulate that the initial release requires the complete source tree in order to create programs in Tart.

In addition to this, there's a refactoring change that I'm in the middle of that I want to get done before I start on any of the tasks listed above.

There is also a giant TODO list of things that need to be done eventually, but aren't release blockers. One open question is at what point do I need to start using the bug tracker on the Tart project page to track these tasks (as opposed to a text file which I do now.) Some of the items on that list are worthy of note:

• A documentation extractor for Tart files. I've been writing all of the source code comments in the Tart standard library on the assumption that there will eventually be a JavaDoc-style program for generating documentation from these (although I think my markup syntax is better than the @javadoc style.)
• Unicode support (so we can write things like String.toLower()). My plan here is to write Python scripts that process the unicode database files and generate Tart code that represents the compressed form of those tables.
• Exception backtracing.
• Debugging support is still lacking in many ways - for example, you can't currently inspect the contents of a local variable.
• Foreign Function Interface for calling C functions. (Partly done, but only works with the most primitive data types. One thing completely missing is Pinning in the garbage collector.)
• Finalizer functions (to be called when an object gets deleted).
• "finally" and "with" statements.
• Package up the Tart eclipse plugin and make it available as an Eclipse package.