-----------------------
Immediate:

* fix coldcc so it will decompile even on a bad binarydb
* force eval execution in coldcc to be atomic, or handle preempting
* for x in (string) {..}
  Add string capabilities to others too (filter, etc)

-----------------------
Bugs:

* $dictionary.[add/del]_elem bad

-----------------------
Features:

* have open_connection() accept a string for the port, where the string
  is interpreted as a service, i.e.:

      open_connection("x.y.com", "smtp");

  When the port is specified in this way, it looks up the port for the
  service, based of the machine's configuration (getservbyname()).

* hack bind_native object renaming

* get execute to use file i/o, so calling execute would be paramount
  to using fopen() on a file (shag code from apache CGI)

* PERL-extensions to regexps (i.e. \s etc)

-----------------------
Possiblilities:

* multiple scopes to methods (2.0)
  
* forking (requires a bit of rewriting in the actual interpreter)
* 'retry' jump (ala continue, etc, for catch statements)
* "\n" in strings should be character '10', not '\' and 'n'.
* optionally declare a set type for variables, ala:

      varname as 'type

  when it is declared, such as:

      arg cmd as 'string, num as 'integer, [more];
      var i as 'integer, some, other, that;

  When the type is set, it is forced to always be that type,
  and assignments contrary will cause errors (this will allow for
  better optimization).

  Automatic type checking can also be done for method calls.

* Declare the default value of a variable when starting, such as:

      var i = 1;

  Perhaps even allow expressions:

      var i = .default_value();

  When variables are defined at declaration roll out like on objects,
  such as:

      var this, that, there;
      var i = 1; 
      var y = .default_value();

* scatter assignments

      [a, b, c] = @list;

* more powerful 'index' operator to handle ranges inherently.
* with this allow multiple 'var' declarations.
* Change the pcode for a method call.  Currently we have:

   [TO expr], START_ARGS, [ARG1 expr], .., CALL_METHOD, (method_name)
   [TO expr], [NAME expr], START_ARGS, [ARG1 expr], .., CALL_EXPR_METHOD

  Which results in a stack like:

      .. | TO | NAME | ARG1 | ..

  The problem with this is that we often want to diddle with TO and
  NAME.  If we were to change the order to be:

   START_ARGS, [ARG1 expr], .., [TO expr], CALL_METHOD, (method_name)
   START_ARGS, [ARG1 expr], .., [TO expr], [NAME expr], CALL_EXPR_METHOD

  It would be MUCH cleaner and more optimal during execution, as
  CALL_<EXPR_>METHOD could pop the data it needed and then call the
  method (native or regular).  The disadvantage of this is that order
  of execution changes from/to:

      (1).(2)(3, ..)
      (2).(3)(1, ..)

  In general this is not a problem, as the data used for the target (TO)
  and the method name (NAME) is irrelevant to the data used for arguments,
  but it could get confusing.
* The method compiler doesnt handle vars correctly, you MUST have the
  second (and only the second) line be var..;  This also means you cannot
  do (as one line):

      "arg one, two; var a, b, c;"