Carp/docs/Todo.org

* 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.

* Unsorted Todo:s
* Critical Bugs
** 0.3
*** Memory management inside 'and' & 'or' seems to be wrong.
*** References must keep track of their origin and prevent usage of them if the origin has been given away.
    Currently it's possible to set a ref so it points to a value in a more short-lived scope, leads to 'stack-use-after-scope' error in clang-sanitizer.
* Big Language Features
** 1.0
*** Lambdas
*** Tagged unions (also known as "sum types" or "enums")
*** Stack allocated Array with an explicit size.
* Tests to write
** Tests that make sure all the various type errors are triggered. Requires host specific info to be purged from error messages.
* Smaller Language Features ("niceties")
** 0.4
*** Prevent usage of 'private' functions from outside their module.
*** Type annotations should affect the type, not just check it.
*** Remove StringCopy.append, use String.append in all those cases.
** 1.0
*** Returning refs in functions should be possible to prove safe in some cases, if origin or ref is stored during memory management pass. Requires lifetimes or similar.
*** Array.copy should just do a memcopy for primitive/plain types. Select most concrete version of 'copy'?
*** A way of telling Carp if an external type is primitive (and thus freely copy:able) or not and must be borrowed.
*** Macros for generating 'read' functions to read objects back into memory from string representation.
*** Kind-checking for types (make sure the type variables match, etc).
*** Allow unification of generic struct '(t a)' with concrete struct, i.e. (Array Int).
*** Enable errors when instantiating deps. Requires that the deps function for templates should return an Either.
* Macro System
** 1.0
*** Quasiquote
*** Splicing in macros
*** Pattern matching on arguments in macros?
*** Some lists and similar things generated by built in dynamic functions like 'cons' etc don't create proper Info for their XObjs?

* Tooling
** 0.4
*** The error reporting in Eval is a mess, must make it possible to return errors with correct location for all kinds of errors.
*** Errors in macros should present the code location of _both_ the macro and of the code that uses of it.
*** Flycheck hangs and eats all resources sometimes. One ugly solution would be to have a timer that kills the process after a certain time when running with --check
** 1.0
*** Show "call stack" when getting an error during concretization.
*** Make the flags sent to the compiler be saved into different groups depending on actual compiler.
*** Project templates.
*** Somehow make it possible to enter ":t foo" at the REPL (can't be done now because each atom is evaluated separately)
*** Preserve whitespace to allow saving forms back to disk.
*** Refactorings at the REPL. Rename, extract function, add/remove parameter?
*** Emacs-mode: Make foreach and deftype indent correctly.
*** Emacs-mode: Make foreach, and*, not*, etc. into keywords (highlight them).
*** A way to assert compiler errors in tests.
* Code generation
** [1.X] LLVM backend
** [?] Emit #LINE macros in the generated C code?

* Libraries
** Make Vector generic
** Threading
** Game development libraries with switchable backends
* Documentation
** Generate documentation pages for files like Macros.carp that does not put their functions in a module but dump them in global scope
** Document all core functions
** Write a guide to how the compiler internals work
** Improve the Memory.md docs
* Ugliness
** Would be nice if Info from deftypes propagated to the templates for source location of their member functions.

* Language Design Considerations
** 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?
** Reintroduce the p-string patch but with support for embedded string literals?

** Rename deftype to defstruct?
** Syntax for pointer type, perhaps "^"?
** 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.
* Notes
** Should depsForCopyFunc and depsForDeleteFunc really be needed in Array templates, they *should* instantiate automatically when used?
** Hard to test '(reload)' since it will ignore currently loaded files