Toward the next major Coalton revision

[stylewarning]

The next major push for Coalton should represent getting us into a state where Coalton is good enough to be published. In my opinion, the primary criterion for that is to show that Coalton can do something measurably (i.e., quantitatively) better than Common Lisp for roughly the same effort. In my opinion, the greatest lever we have is performance, which is an interesting and practical target.

On Mar 25, several Coalton developers got together and discussed what they'd like to see in the next major push for Coalton. This list isn't necessarily exhaustive or in priority order. The list is broken into 5 main categories:

1. Type System: Main features of the Coalton type system.
2. Language: Syntax and semantics of Coalton.
3. Compiler: Implementation of Coalton, especially optimizations.
4. Standard Library: Features of the standard library.
5. Developer Experience (DX): Tooling for writing Coalton and how it feels to write Coalton.

These are brief accounts of each of the issues.

Type System

1. Weak types: Implement weak types a la OCaml.
2. Scoped type variables
3. Associated types / type families: probably a far-off feature since this would be quite a lift.

Language

1. Non-function definitions: How do we deal with top-level, possibly mutually recursive, non-constant definitions? Languages like Rust only allow toplevel functions.
2. Mutually recursive instances: An extension of the above, when non-function values are present.
3. Deriving mechanism
4. Default type class methods
5. Error handling: Improve error reporting even further.
6. Better matching: More ergonomic syntax for matching.
7. Tuple syntax: Revisit the syntax for tuples, especially to improve matching.
8. Type aliases
9. Syntax for lists and dictionaries and strings: Make the syntax "overloadable", like integers are, so that the same syntax can be used to work with multiple collection types.

Compiler

1. Currying / heuristics for over/underapplication: Eliminating currying would require essentially a rewrite of everything. Instead, build in more heuristics for currying errors.
2. Monomorphization bugs: Fix more corner cases of monomorphization.
3. Inlining: Build in support for manual and automatic inlining.

Standard Library

1. File I/O, string formatting
2. Debug output (blocked on a deriving mechanism): Make it easier to add debug logging to programs.
3. Dictionary type
4. Revisit the prelude
5. Overall standard library design: The standard library was built piecemeal in an ad hoc fashion. It should go through an actual design phase.

DX

1. Coalton file format: A reader that doesn't rely on hacks.
2. Better error rendering (SLIME interop)
3. Working jump-to-definition
4. Redefinition semantics: The behavior of a redefinition, especially if we have inlining, isn't well defined. What should happen? Dev/release modes?