Todo

Milestones

0.3 - Hopefully done "soon", fixing the most pressing issues.
0.4 - A nice minimal version of the language. Should be possible to use for somewhat realistic projects.
1.0 - The completed version of the language with all planned features and extra nice ergonomics.

[0.3] Instantiating generic struct with ref-type fails.
[0.3] Must handle deletion of temporary values used during initialization of global variables.
[0.3] When 'set!':ing a global variable, memory can leak.

[0.4] Doc strings.
[0.4] Kind-checking for types (make sure the type variables match, etc).
[1.0] Tagged unions (also known as "sum types" or "enums")
[1.0] Lambdas (anonymous functions) that compile on Windows and don't leak memory!

[0.3] Implement 'prn' that prints in a readable format, make 'str' print humanly.
[0.3] Make the type of 'set!' be (set! a a) instead of (set! &a a).
[0.3] Errors in macros should present the code location of both the macro and of the code that uses of it.
[0.3] If main returns the value of a function returning a generic type it will fail (because there is no constraint for "Int or ()")
[0.3] Optimization: Don't copy the whole array in Array.swap, Array.aupdate, etc.
[0.3] When registering with an interface, make sure the registered function actually can unify with it's signature.
[0.4] Reintroduce the p-string patch but with support for embedded string literals.
[0.4] Should be possible to read float literal without '.', eg. "3f" (because that's how they print sometimes)
[0.4] Defining a local variable messes up unqualified lookup of function with the same name, e.g. (let [words (words &s)] ...)
[0.4] The type error when setting a variable but missing the '&' is confusing: "Can't unify Int with &Int"
[0.4] Defining a function like 'add-ref' (see the numeric modules), refering to '+' does not resolve to '+' inside the module, which gives the function an overly generic type.
[1.0] A way to assert compiler errors in tests
[1.0] Rename type variables from t0, t1, t2 to a, b, c, etc.

[0.3] Some lists and similar things generated by built in dynamic functions like 'cons' etc don't create proper Info for their XObjs
[1.0] Quasiquote
[1.0] Splicing in macros
[1.0] Pattern matching on arguments in macros?

[0.3] Project setting for turning off bound checks and similar ("--optimize"). Should also run the C compiler at at least -O2.
[0.3] Errors in the parser or emitter don't stop evaluation, only errors during evaluation?
[0.3] Somehow make it possible to enter ":t foo" at the REPL (can't be done now because each atom is evaluated separately)
[0.3] The (project-set! ...) command should accept args of various types, not just String.
[0.3] When running :rb, shouldn't carp stop when :r returns an error, instead of building the wrong main.c?
[0.4] Print a warning when changing the type of a function (can create bugs by overriding earlier declarations with the same name)
[0.4] Hide instances of templates/generic functions when printing the environment (by default, allow it as a setting)
[0.4] Entering the name of a symbol at the REPL prints nothing.
[0.4] Show "call stack" when getting an error during concretization.
[1.0] Preserve whitespace to allow saving forms back to disk
[1.0] Refactorings at the REPL. Rename, extract function, add/remove parameter?

[1.0] Would be nice if Info from deftypes propagated to the templates for source location of their member functions.
[1.0] Remove unnecessary Array-functions and rewrite them in Carp?
[1.0] "Setting" of string literals? (let [x "a"] (set! x @"b"))

What's the correct type of the variable in a set!-form, i.e. (set! &x value) or (set! x value)
How should passing primitive types (that do not care about being referenced) as ref:ed parameters be handled?
How to handle heap allocated values? Box type with reference count?
Fixed-size stack allocated arrays would be useful (also as members of structs)
Macros in modules must be qualified right now, is that a good long-term solution or should there be a 'use' for dynamic code?
Allow use of 'the' as a wrapper when defining a variable or function, i.e. (the (Fn [Int] Int) (defn [x] x))?
Being able to use 'the' in function parameter declarations, i.e. (defn f [(the Int x)] x) to enforce a type?
Distinguish immutable/mutable refs?

Should depsForCopyFunc and depsForDeleteFunc really be needed in Array templates, they should instantiate automatically when used?