TODO

  Yeti TODO.
~~~~~~~~~~~~~~~~~

* Allow any identificators in dotted class names (like fi.etc)
* Allow optional ~ before classname in instanceof and friends.
* Typedefs in REPL
* Compiling simple module a; in REPL results in ClassNotFoundException
* Foreign structs (java dto -> struct?)
* Support as in type definitions for recursive types
* Be smarter on list concatenation - detect if either of arguments is
  a list concatenation and construct list of lists, if it is.
  This would avoid some surprising stack overflow errors.
* Dependency analyses on struct field self-bindings?
  (could be done by binding only free typevars first and
   unifing those with actual function field types later)
  + structType should use asLambda instead of == "lambda"
* Reuse local JVM variables (have a free var list on Ctx and add variable
  to it after last use when it could be nulled). This could compact code
  and help GC with bindings that are not explicitly nulled (type != MAP).
* foo = load bar; foo.x should be optimised into same as load bar; x
* Implicit function to class/interface casts?
* programs should generate static int Main(String[]) method,
  that wouldn't call System.exit() upon receiving Yeti ThreadExit error.
* Context-specific int optimizations for builtins
  (and java method invocation return values)
* Ability to override struct class toString would be probably useful,
  for example by defining special property like { get as string () = "hi!" }
* Struct mapping (as in doc/stmap.yeti)
* Allow cons pattern match (::) on arrays?
* Have fall keyword in case to jump to checking next pattern.
* Exhaustive list match detection probably could be improved by something
  like introducing FL_EMPTY_PATTERN and keeping account about the list tail
  being exhaustive.
* import foo.Bar; Bar$Baz could resolve
  to foo.Bar$Baz instead of current.package.Bar$Baz
* yeti.lang.BigNum should probably use BigDecimal instead of BigInteger
  (BigDecimal contains BigInteger anyway)
* Support A x | B y | variantTypeDef?
* Review the Java<->Yeti type autoconversions?
* Immutable tree map support - this seems to be popular feature. ;)
* Support module field deprecation. One way to do it would be to support only
  function deprecation, a nice syntax would be allowing 'is deprecated type'
  on function literal bindings, that would mark the function _implementation_
  (not type) deprecated. Maybe even better alternative would be the same for
  structure constructor fields. This could then be used to mark the field
  access methods on module class as deprecated (just flipping a access flag)
  and later to mark bindings created on loading the module.
* Optional Java generics support?
* Direct struct-ref optimisation, when only known structs are accessed