To Do List for First Release

The surface syntax for BitC is now mostly converged. There are usability issues that we are discovering, but I would characterize most of these as minor convergence issues.

My original plan had been to get the language converged and release a compiler before moving on to self-hosting. That plan has been abandoned for two main reasons:

• The performance of the current front end is horrible. Valgrind data tells me that the overwhelming majority of time is being spent in reference counting overheads. In short, we need to move to an implementation built on a GC'd runtime.
• There are too many things in the current type system that need to be resolved, and I'm very reluctant to invest that effort in a code base that we know is going away. Most of these issues could be deferred to an evolutionary release, but making ByRef first-class is essential to having a decent story for I/O, and that one requires a major overhaul of the type system and the inference engine.

So the plan at this point is to minimize rework by migrating the compiler into BitC sooner. The current compiler will be slow, but it should hold us until the new compiler is available. This gives us, in effect, three to-do lists:

1. Stuff we need to do before we can begin self-hosting: syntax convergence, bug fixes, and such.
2. Stuff we would like to defer, but may run into while self-hosting. This will almost certainly include some library work.
3. Stuff that needs to be done to release the 1.0 Compiler - including the new type system enhancements.

Here are all of the open "to do" items before we can release R1 of the BitC Research Compiler, along with current status:

Pre Self-Host

A key assumption here is that we will avoid introducing a large number of new type classes in the process of building a self-hosted tool chain. This is important because we still need to see through the "type classes are types" implications.

There are three active bugs in the test tree. Unless we hit something that needs them to be fixed, I don't anticipate fixing them in the current version of the compiler.

1. Make a final decision about whether we will eventually go to curry-style application. I need to get a design note up on this. We want to decide this early, because doing so impacts the syntax of type construction and type definition. For the moment, this is purely an issue in the parser - it's a matter of avoiding future rework by getting the relevant elements of the grammar fixed now.

2. Make a decision about whether we want to admit rank-2 polymorphism and/or higher-order kinding. Review any syntactic consequences that this may carry.

3. Decide what other applications we want the front-end to serve (static analysis?) and consider what impact this may have on the design of the new AST.

4. Hold a bikeshedding session about pattern matching, whether we want to re-introduce it, and if so, how it will impact syntax.

5. Decide how to handle if-then-else chains in the face of layout interference. Do we hack the layout rules or move to a cond-like construct?

6. Update the language specification.

During Self-Host

1. Resolve what (if anything) we will do concerning "type classes as types", "capsules", and inheritance.
2. Resolve what we are doing concerning mutability and permissions within aggregates.
3. Refine the looping construct, and introduce one that is tail-recursive and human-readable at the same time.

After Self-Host

1. Put in a big push on the library.
2. Decide how to handle pinned objects and foreign objects.
3. Make sure initializer ordering rules are enforced and rationalized. The proposed rules are defined in Rules for BitC Initializers.

   Status: Defined. Effect types must be implemented before this can be completed.

   Complexity: Straightforward.

4. Implement and enforce purity of initializer expressions and the (pure ...) form more generally.

   Rationale: Without this, many globals must be declared mutable that could otherwise be constant, which in turn impedes optimization.

   Status: Depends on implementation of effect types.

   Complexity: Trivial once effect types are done.

   Figure out how to handle type class resolution more sensibly.

5. Implement capsule/object notion.

   Rationale: Gives us just enough existential typing to get by.

   Status: Shap has implemented structure methods. Object methods are straightforward, but the associated type constraints cannot be expressed without has-field.

   Complexity: Straightforward.

6. Implement the Nat type per Mark Jones and Habit (we had once referred to the same idea as "literal types").
7. Given nat type, restate the array type in terms of nat type. Given proper region types, eliminate array-ref and friends.

Non-Technical Issues

1. Go through and document (doxygen comment) all of the source code.

   Status: In progress, not yet complete.

2. Specify syntax for function types expressing effects.

   Status: Two proposals exist. We need to look at usability issues here.

3. Update spec to reflect all of the above.

   Status: Not yet started.

Dropped

1. Implement subtyping on structures

   Status: Abandoned in favor of using type classes.

2. Implement existential types.

   Status: Dropped in favor of the capsule/object notion.

---