[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
  - objects [HARD]
  - namespaces [HARD]
  - = "%identity", = "%word_0" etc
  - warning: "`foo' is assigned a value that is later never used"
  - unused globals warning doesn't work for self-recursive functions,
    nor for mutually recursive for that matter
  - don't warn about pattern twice in init sections
  - take advantage of immutable strings
  - maybe some builtin array stuff?
  - error: foo.xgo and bar.xgo did inconsitent assumption about compiled
    interface of Baz

typechecker:
  - allow weak types in globals until end of compilation unit [HARD]
  - use <'a>symbol for type variables
  - change xtyvar.t from <ty>option to union { void Unbound; ty Bound;
    <ty>list Variant; }; use variant typing for struct exprs and builtin
    operators like +, -, < etc.
  - exceptions (and methods for that matter) should be assigned numbers
    not sequentially as it is done now, but dynamically, using hash table;
    this will allow dynamic loading of gont modules

library:
  - add unicode stuff
  - strings as trees?
  - Core: remove print_* and prerr_*, add puts_err()
  - Iconv module
  
documentation:
  - documentation generator
  - language reference
  - next tutorial steps
  
cleanups:
  - split type.g, bind.g ?
  - use new language constructs ({} instead of ({}), [] for list
    construction, record copy with update etc)
  - use Stack::t and similar instead of list variables

language:
  - objects
  - namespaces
  - polimorphism limited to specific objects like 
    <'a : class { void set(int); int get(); }>
  - type foo = TYPE_EXPR instead of typedef
  - top-level `let stack = Stack::t, pop = Stack::pop;' or maybe import
    keyword for this? (to allow also locally) do we really need it?
  - allow `open' local to scope

things that are known to be broken
  - floats in unions [???]

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 identifying such restricted functions (that don't need
    parameters being 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: 922 $ $LastChangedDate: 2002-09-10 11:30:29 +0200 (Tue, 10 Sep 2002) $
# vim:tw=75
