[HARD] -- hard to implement
[LOW]  -- have low priority
[???]  -- dunno if still true

- compiler stuff
  * conditional compilation
  * think about unicode strings [HARD]
  * add compiler switch to turn null-checking off [LOW]
  * assert
  * pattern matching structures
  * "as" keyword in pattern matching
  * chini of globals
  * warn about unused symbols
  * objects [HARD]
  * namespaces [HARD]
  * add error recovery to parser and lexer

- typechecker:
  * test type reconstruction

- cleanups:
  * split codegen.g
  * remove support.c
  * remove List::cons[0-9]
  * do s/({/{/ s/})/}/

- language:
  * allow ,,let pat = expr;'' (binds until end of current block)
  * struct copy with update

- things that are known to be broken
  * floats in unions [???]
  * complex pattern matching with exhaustive warnings [HARD]

- possible optimizations:
  * if function doesn't pass its closure anywhere, we could allocate closure
    with alloca (or even simply put closure as variable on the stack), 
    which would be *a lot* faster. Similarly for passing lambda expressions
    just up the call stack. However this isn't as simple as it first seems.
    The problem is identifing such restricted functions (that don't need
    parameters beeing lambda expressions to be allocated on the heap).
    We would need to require user to annotate them somewhat in the
    interface file, which doesn't seem right. [HARD]
  * when calling top-level functions, not all arguments needs to be of
    pointer size (because auxiliary function needs to be generated anyway,
    if we want to use it as functional value), this is especially nice 
    to floats

# $Rev: 694 $ $LastChangedDate: 2002-08-29 23:02:00 +0200 (Thu, 29 Aug 2002) $
# vim:tw=75
