todo.txt

1.0 RELEASE CRITERIA:
* max, min (look at functional.sum for inspiration)
* Support for Scala-style late-evaluated macros
* Buffer::convert(String)
* Make a special syntax for assigning to constants before running __init__
* Some kind of super()-syntax
* Use either new internal init code or null constructor for range, node-wrappers, type-wrapper, stack-wrapper, module-wrapper, function-wrapper, member-wrapper and every other native anna type
* Null() should return the null object
* String::convert should do something clever for modules.
* Modify while loop to be able to handle cool iterator things like breaks in map
* Modify function definition syntax to put return type after argument list?
* Decide on argument order for all string functions
* Go over naming of C functions, e.g. count vs. size vs. length
* Do something clever with inherited methods to make sure the type of the 'this' member is correctly handled.
* Use setLocation on ast stuff in various macros to make error messages more readable.
* Drop __staticReturnTypeOf__ and __staticInputTypeOf__
* Constructors for intersected types should return null.
* HashMap types should look up the appropriate comparison and hash method during type creation. Same with lists.
* List.reverse
* List::convert(Iterator iter)
* List.iterator--
* List.iterator += x;
* List.iterator -= x;
* Type::Iterator
* Continuation/Function::Iterator
* struct::Iterator
* Bindings
  - Drop ctime and make unix.time complete feature complete
* anna-game as a proof that the language works for solving reasonably complex problems
* Documentation:
  - Split base documentation into multiple files
  - Check for dead links
* Check that node compare supports all ast node types
* Remove code duplication between types and functions when performing templatization
* The Member.value() method can't currently handle properties.
* Types should have constant members. They should only be assignable during construction using some kind of funky attribute syntax, which will not allow any kind of member write access.
* Maybe List["getRange"] should return the getRange member object? If so, it would probably make a lot more sense for Continuation["foo"] to return the ContinuationMember object, and not the actual value.
* There should be a type flag «sendable», that is used to tell the world that a specified type only has imutable members, and in addition, that all member values are also have the sendable attribute.
* There should be a goroutine-like concurrency framework where messages can be sent through sockets. The only message requirement is that anything sent through the socket must be sendable (see previous bullet). This can be implemented using threads at a very high efficiency level without introducing any hard lock problems. (This is reasonably close to what Erlang does, too)
* Interactive debugger
  - Better breakpoint insertion that can reach inside sub-blocks of functions
  - break someModule:330
  - next
  - bt (Alias for frame.trace)
  - clear function for clearing a breakpoint
  - Function.source property to show the source code of non-native function definitions.
  - Function.toString() should show the source code with line numbers, in order to make break easier to work with.
  - Breakpoint insertion at start of any native method
  - variable write access in debugger? 

1.0 RELEASE CRITERIA (Done):
* Rename __staticTypeOf__ to staticType
* Rename the Object type to Any. 
* Alternative Lua-like string syntax, /==="This is another string literal"===/, with arbitraryily many '='
* NaN-boxing
* Named arguments in template specialization
* Make annadoc show documentation for all the build in macros.
* Move all bootstrapped macros into the same namespace as the builtin macros, so they are easier to find.
* Drop all members from Object type.
  - Drop Object::__cmp__ - not all objects can be used as hash table key types any more
  - Drop Object::hashCode - not all objects can be used as hash table key types any more
  - Drop Object::toString. Use String::convert instead.
  - Replace obj.__type__ with lang.type(obj)
* Iterators for all collection types
* Iterator.iterator
* Switch each, map and friends over to using iterators
* Write macros to transform f"Hello, %(userName)" => "Hello, %" % [userName]
* Interactive debugger
  - debug.here() function call that launches the debugger in the current location
  - breakpoint bytecode launches the interactive debugger
  - debug.breakpoint function to insert a breakpoint
  - continue
  - break someFunction:330 
  - variable access in the debugger repl
* Revise api of Continuation. We want a way to tell the static type of every variable in the frame.
* HashMap::clear
* List::clear
* List::push should accept a variadic list of items to push
* List::indexOf
* repl
  - basic line editing
  - basic eval loop
  - sane handling of use/expand
  - Capture variable declarations
  - save history to file
  - detect multi-line stuff
  - variadic arguments aren't shown as such
  - argument default values aren't shown
* Simplified member declaration
* When no method alias matches a call, output a clearer and more helpful error message. including a list of all candidate methods.
* Reconsider making function aliases have equal priority to function names when performing calls
* Remove code duplication for alias matching in methods
* Documentation coverage of standard API functions and types should be at least 90 %.
* Function specialization
* Write a 'class' macro that performs some of the code transforms currently done by the anna_type_mangle_methods c function, and use pure types for slightly less magical type definitions
* assign/declare list of variables, e.g. [foo, bar, baz] = qux(); or [foo, bar, baz] := qux();
* Don't differentiate between macros and functions anymore. How a function/macro should be invoked only depends on how it is imported, so there really is no point in differentiating between them. 
* More validation:
  - If explicit function return type exists, return type of return expressions aren't abides checked against it
  - Can't assign to constants 
 - Only static members can be accessed statically
  - Check argument types to function calls better...
* Introductory segment in the documentation
* Working error handling
  - raise function
  - collect function
  - option to catch only some error types
* List.sort
  - Basic sort function in place
  - Sort function
* Base documentation:
  - Make code links actually work
  - binding generator doesn't pass on the doc attribute
* HTML api documentation extractor
  - Nicer prototype for function arguments that are functions
  - Show aliases
  - Use local storage for storing internal member visibility attribute
  - Show operator syntax
  - Show operator syntax in header
  - Split out functions in header
  - Vararg support in function prototype
  - Show short description in header
  - Hide internal elements by default
  - document attribute for modules
  - document attribute for properties
  - Basic iteration working
  - document attribute for memebers and types
  - HTML templates
  - File output working
  - Iterate over global namespace
  - Correct path for links
  - document default values
  - Inherit documentation attribute from base classes
  - Handle regular module functions
  - Sort members
  - Better module templates (pretty)
* Inheritance and method overloading fully working
* Static member access fully working 
* Add memory overhead of Ints and Floats to GC estimates
* Smarter GC timing algorithm
* Mutable and Imutable versions of List and String, switch between them using freeze/thaw properties
* Default argument values
* Check that node each, print supports all ast node types
* Usable File type
* Usable Date type
* Access attributes of variables and properties
* Rename vmstack to context
* Fix if/else snafu. Current solution is hardly elegant and it fails in some edge cases. Hopefully, we can come up with something significantly better...
* The GC uses recursion, we should switch to a stack instead in order to not smash the call stack on e.g. a huge linked list.
* Update the 'struct' macro so that it can be used to easily define types geared towards data storage. 
* Move most of gc to separate thread

1.1 RELEASE CRITERIA:
* MutableList::removeValue might be useful?
* ImutableCall
* ImutableHashMap
* repl
  - tab completion
* During startup, cache contents of all directories in ANNA_PATH so that we don't have to do crazy numbers of stat calls
* getopt replacement
  - basic design
  - implementation
  - use it in annabind, annaxgettext and annadoc  
* anna should use getopt to provide switches for setting the path, making dry runs, controlling the GC, etc.
* Working error handling
* Documentation coverage of standard API functions and types should be over 99 %.
* Constructors and inheritance _fully_ working
  - multiple constructors through aliases
* Add internal memory usage of Hashes, Buffers and Lists to GC estimates
* Function for obtaining the amount of memory used by an object
* Protected members
* Multiple inheritance clashes handled sanely
* List.__get__(List«Int» index)
* List.__set__(List«Int» index, List value)
* Range.rest
* List.rest
* Binding generator
  - cerror should be generated through the bindings
  - math module through bindings

1.2 RELEASE CRITERIA:
* HTML api documentation extractor
  - Search functionality
  - expand/minimize docs
  - Handle complex documentation attributes, e.g. named stuff
* Regexp library
* Query library (SQL Alchemy/Linq/etc. replacement)
* Live debugger library
* Multithreading support using message passing and a common frozen object store
* Cache for mpz_t numbers? Is this meaningful?
* Set type
* Faster imutable lists/strings, supporting zero copy slicing, substringing, etc.
* Imutable Map/Set? Maybe...
* List.sort
  - List specialization
  - Return ImutableList when calling ImutableList.sort
  - Reverse sorting
  - Sort structure member

MISC:
What should be the return value for iterator methods like map and filter when given a null value as a function body?
An error injection tool that randomly turns stack values into null objects would be cool. Need to make sure that the «this» object of method calls aren't flipped, though, which means we must do something clever in order to make it work.
Make api more consistent. Make naming of wrapper types consistent. Make naming of native type methods consistent.
Go over list of built in functions and methods and mark the right ones as pure
Can the list of anna_node_*_t structs be reduced? Can the node type specific code in anna_node*.c be simplified? It currently looks a lot like spagetti with huge numbers of switch statements. One possibility would be to add function pointers to the node types.
Should finalizers be completely dropped? If we drop them, we get a lot more freedom with regards to GC algorithms, but we on the other hand can't e.g. close files on exit, and we'd have to use the GC for a bunch of extra stuff, like list payloads
It might be useful to have a function to construct an instance of a specific list type. Should this be generalized to runtime template specialization support? Might be useful. Means a whole bunch of future potential optimizations become way harder, though.
How should the argument list for inherited constructors be handled?
We may want reverse aliases for static methods, something like (aliasReverseStatic(String::convert))
Type member setup needs some dependency resolution in order for type calculations to work properly.

What is the best way to convert between String and List«Char»? In one direction, "".join(list) works ok and might be sufficient, but in the other direction? string.map(i){i} is too wordy, imo.

LANGUAGE FEATURES:
Submodules written in Anna (C submodules already work)

STDLIB FEATURES:
The rest of the hashtable functions (filter, find, properties for key and value lists, etc.)
Set type
List.milter 
Range.milter
Hash.milter
List and Hash types should be made fail fast

Partial application and saner function argument handling, e.g. it should be possible to write (0..5).map(apply(Int::__add__, 4)), which is equivalent to (0..5).map(val){4+val}

RELIABILITY:
Use gcov to make sure the test/regression suite is reasonably close to complete (It's currently not even close)
Test suite should be at lest 10 % of total code in project. (Currently ~ 9 %)
More tests for complex math
More tests for floating point math
More tests for type checking on invalid specialization
Lots more coverage of using null value as function argument

DOCUMENTATION:
Document all vm ops w.r.t. manipulating the stack, etc.

PERFORMANCE:
Mandel test should be no more than one order of magnitude slower than the corresponding C implementation
Implement more of the language benchmark game tests to compare performance against various other languages. It should be possible to make Anna roughly comparable to Python in performance without too much work.
More builtin integer ops, e.g. mod, shift, etc.
Variable lookup instruction version for looking up in current frame?
Variable lookup instruction version for looking up in first parent frame?
Implement tail recursion
Optimization idea: Avoid creating trampolines when possible - push other stack onto call stack and have special case instruction for call with stack-on-stack. 
Add profiling information to the VM
Make a version of the fold op that takes a count parameter
Lazy loading of modules
Instead of a static «in use» flag for the mark phase of the GC, the value should switch back and forth. That way, we don't need to touch all objects a second time when iterating. Also opens up to the possibility of not bothering to check old objects for GC:ing on every GC run.
Make Char and Float fast when used as HashMap keys
Store floats directly on stack

UNUSED OPERATORS:
Currently, the @, & and ` symbols are unused and # is only used at the start of a line.

PLANS FOR APPS WRITTEN IN ANNA:
live: Debug a running application using command line or web browser.
Compiler front end rewritten in Anna.

Idea: Macros could be used in the file they're part of, but only below their definition. Slight conceptual uglieness here, but very pragmatic and useful. Also very nice for tutorials and teaching.