To Do List for First Release

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

Syntax Issues

Decide on and implement the final surface syntax for BitC, which will not be an S-expression syntax.
Complexity: Implementation is straightforward, but overall complexity is moderate, because we need to make decisions about how to deal with things like looping constructs.
Figure out what, if anything, we want to do about inheritance and virtual functions in R1, in particular for addressing things along the lines of Common Type System compatibility. This may be something that should be deferred.
Complexity: High. There are type system issues, but more importantly, the whole design space is one in which everyone has an opinion but converging on workable answers is challenging. There has been productive discussion on-going on the BitC list.

Implement the "constantness by path" rule, including the CONST type metaconstructor.
Rationale: Without this, inner references and by-ref can create a number of problems.
Status: Essentially done as of 12/12/2008. Needs to be documented in the specification.
Complexity: This turned out to be moderately nasty.
Define and enforce the rules for initializer ordering. The proposed rules are defined in Rules for BitC Initializers.
Rationale: Without this, our ability to initialize is severely restricted.
Status: Defined. Effect types must be implemented before this can be completed.
Complexity: Straightforward.
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.
Implement typeclass instance resolution by lexical lookup rule.
Rationale: Solves the "colliding type class" problem.
Status: Not yet started.
Complexity: Requires that we switch to a back-tracking solver.
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.

Implement literal instantiation.
Rationale: Essential for efficient I/O implementation.
Status: Dropped. See array-ref. A specialized form of literal instantiation was implemented to support has-field, but this case was straightforward. An integer literal was to have been simultaneously a member of a single-element integer literal type and a member of the usual integer types. That proved to be excessively complicated, which is why we dropped the more general form of literal instantiation.
Complexity: Straightforward.
Array-ref
Rationale: Essential for efficient I/O implementation. Replaces literal instantiation.
Status: Completed
Complexity: Straightforward.
Implement record inference (a.k.a. has-field)
Rationale: Required to state type class dependencies for objects/capsules. Also gives us a form of lateral abstraction.
Status: Straightforward, but not yet started. Ideal implementation requires literal instantiation.
Complexity: Requires updates in the solver. Turned out to be less straightforward than we initially thought, because the method rewrite can occur late (in the instantiator), which required some care about the ordering of AST rewrites and calls to the type checker to re-type things.
Has-field is a specialized form of literal inference, but each field name is a member only of its corresponding unit type. There is no generalized type of field names.

Go through and document (doxygen comment) all of the source code.
Status: In progress, not yet complete.
Specify syntax for function types expressing effects.
Status: Two proposals exist. We need to look at usability issues here.
Update spec to reflect all of the above.
Status: Not yet started.

Implement subtyping on structures
Status: Abandoned in favor of using type classes.
Implement existential types.
Status: Dropped in favor of the capsule/object notion.

Generated on Fri Jul 30 07:59:16 2010 for BitC Compiler by

1.4.7