There are a number of things which needs to be done as soon as possible:
Great improvements should be expected in future versions of the language.

TODO LIST FOR THE BOX COMPILER
------------------------------
In order of importance:
7 Copying types of all kinds should be possible, with eventual invocation
  of user defined procedures. It's not clear if we should allow the VM
  to automatically copy objects, by introducing an ad-hoc instruction.
8 Pointers needs to be introduced, so that objects can be referred by other
  objects.
9 We should allow automatic conversion of types, once they have been created.
  This will allow to use a Type as a container for local variables, which
  are needed only for the creation or managing of the object.
  Once the type has been used and the final parenthesis (]) is found,
  the object should be converted to a final object, which does not contain
  the local variables. This will be very useful.
10 Operator overloading: this needs adjustments to the basic operation handling
  routines as well as the Box language. The first is important, because
  it would already allow the addition of a builtin String object, which
  allows to easily concatenate, compare strings.
11 Point 9 would allow the definition of builtin functions to get input
  from files and from stdin.

DONE:
4 The second precedence rule is the following:
  If a procedure for a given type is not found, that type should be once
  resolved and then the procedure should be searched again.
  This will allow to create real inherited types. Example:
    MyInt = Int
    x = MyInt[1]
  Does not work now, because Int@MyInt does not exist. One expects that this
  should work, since Int@Int exists and MyInt = Int.
5 If $, $$, $$$, ... are used without scope level specification, they should
  refer to the procedure which is being defined, rather than to the current
  opened box. This is what one wants to do in 99% of the cases.
  One should specify the level to refer to the current opened box, such as
  in $
1 We now have a problem. If we define Window = Ptr and PointList = Ptr
  then there is no way to distinguish between them. One example is
  Window@Line: this procedure will be invoked both for Window and for
  PointList objects. Another example: LineStyle = (Real, Real, Real, Real)
  is now in conflict with Color = (Real r, g, b, a).
  It is quite important to solve this issue as soon as possible.
  The solution is to introduce a new type operator ++

    Type1 = ++Type2

  Will associate to the name Type1 something which is identical
  to Type2, but is not compatible with it.
2 global variables: quantities defined in the upper scope unit should
  be automatically allocated as global (global register should be used
  instead of local ones);
3 precedence rules for name resolution should be introduced. The first
  refers to subtypes. When object.Subtype is found, Box searches now for
  subtypes of the type of object. If no such a subtype is found, an error
  is reported. We should extend this behaviour: if the subtype is not found
  and object is a subtype itself, Box should try to convert it into its child
  and search among its subtypes. Example:
    w = Window[][
      pl = .Put[...]
      ...
      ... pl.Get[1] ...
    ]
  Now pl has type Window.Put. This subtype has child of type PointList.
  Since no subtype Window.Put.Get exists, Box should convert pl to its child
  (an object of type PointList) and try to find a subtype .Get
  The problem should be faced in a more general way, allowing automatic
  conversion of types at (]), see 8
6 The VM should be instructed about how to create or destroy types.
  This process has already been started, but needs to be completed.
  In the end Box should be able to create hidden procedures for destroying
  those data types that need a special treatment (structures in particular).
  The compiler then should communicate to the VM what procedure to call
  for destroying what type. The destruction will then be operated
  automatically by the VM when the reference count reaches 0.
  Types associated with the destroyed type will be destroyed as well
  in a recursive fashion.

TODO LIST FOR THE GRAPHIC LIBRARY
---------------------------------
In order of importance:
7. Window should be able to take an already existing image
   as a background for the new one. We should be able to include
   existing images.
8. Use ImageMagick for saving to many formats which are not currently
   supported.
9. We need in particular to support gif for animations!

DONE
----
1. Add possibility of setting cap style to Style;
   add possibility of setting the dash offset to Style.Dash
2. Make Window[] to create a WindowPlan without creating the actual Window.
   This will allow to extend the Window.Save syntax in a sensible way:

     w.Save["filename.ext", Window["rgb24", .Res[10]]]

   Be careful! Example:

     w = Window["rgb24"]
     w.Line[...] // Will segfault if w is not initialised

   DONE with the introduction of "incomplete" Windows. Incomplete windows
   are windows which could not be created, due to some missing params
   during initialisation. They cause errors only when the user tries to
   draw something on them. However they can be used as argument for the
   Window.Save method, which will "complete" the window appropriately.
3. Polygons should not be closed, when they are not filled.
   They should be closed only when using Poly.Close[]
4. Add functions Deg[] (convert angle from degrees to radians)
   and Dpi[] (convert resolution from dpi to points per mm.
5. Add function HSV[] useful for expressing colors in HSV components.
   Add HSV@Color and Color@HSV. Add HSV@(Window, Line, Poly, etc.)
6. Add Gradient[] for filling with gradients.

OPEN JOBS
---------
- adjust Box grammar and introduce proper compilation through abstract
  syntax trees. This will allow to add "templates" and make the language
  much more powerful and robust. Error detection will also benefit
  from this improvement;
- develop a bytecode file format for Box, so that already compiled
  sources can be loaded and linked (similar to pyc files for python);
- Add support for LaTeX: we should understand what is the right approach
  (call latex+dvips+imagemagick or can we use directly the dvi file?)
- Integrate imagemagick into the Box graphic library and make it work
  together with Cairo: we want to support as many output formats as possible
  and to be able include pictures (in various file formats) into the working
  Window. We want also to be able to produce animated gifs and maybe
  use mencoder for producing movies.

