1There are a number of things which needs to be done as soon as possible:
2Great improvements should be expected in future versions of the language.
3
4TODO LIST FOR THE BOX COMPILER
5------------------------------
6In order of importance:
77 Copying types of all kinds should be possible, with eventual invocation
8  of user defined procedures. It's not clear if we should allow the VM
9  to automatically copy objects, by introducing an ad-hoc instruction.
108 Pointers needs to be introduced, so that objects can be referred by other
11  objects.
129 We should allow automatic conversion of types, once they have been created.
13  This will allow to use a Type as a container for local variables, which
14  are needed only for the creation or managing of the object.
15  Once the type has been used and the final parenthesis (]) is found,
16  the object should be converted to a final object, which does not contain
17  the local variables. This will be very useful.
1810 Operator overloading: this needs adjustments to the basic operation handling
19  routines as well as the Box language. The first is important, because
20  it would already allow the addition of a builtin String object, which
21  allows to easily concatenate, compare strings.
2211 Point 9 would allow the definition of builtin functions to get input
23  from files and from stdin.
24
25DONE:
264 The second precedence rule is the following:
27  If a procedure for a given type is not found, that type should be once
28  resolved and then the procedure should be searched again.
29  This will allow to create real inherited types. Example:
30    MyInt = Int
31    x = MyInt[1]
32  Does not work now, because Int@MyInt does not exist. One expects that this
33  should work, since Int@Int exists and MyInt = Int.
345 If $, $$, $$$, ... are used without scope level specification, they should
35  refer to the procedure which is being defined, rather than to the current
36  opened box. This is what one wants to do in 99% of the cases.
37  One should specify the level to refer to the current opened box, such as
38  in $
391 We now have a problem. If we define Window = Ptr and PointList = Ptr
40  then there is no way to distinguish between them. One example is
41  Window@Line: this procedure will be invoked both for Window and for
42  PointList objects. Another example: LineStyle = (Real, Real, Real, Real)
43  is now in conflict with Color = (Real r, g, b, a).
44  It is quite important to solve this issue as soon as possible.
45  The solution is to introduce a new type operator ++
46
47    Type1 = ++Type2
48
49  Will associate to the name Type1 something which is identical
50  to Type2, but is not compatible with it.
512 global variables: quantities defined in the upper scope unit should
52  be automatically allocated as global (global register should be used
53  instead of local ones);
543 precedence rules for name resolution should be introduced. The first
55  refers to subtypes. When object.Subtype is found, Box searches now for
56  subtypes of the type of object. If no such a subtype is found, an error
57  is reported. We should extend this behaviour: if the subtype is not found
58  and object is a subtype itself, Box should try to convert it into its child
59  and search among its subtypes. Example:
60    w = Window[][
61      pl = .Put[...]
62      ...
63      ... pl.Get[1] ...
64    ]
65  Now pl has type Window.Put. This subtype has child of type PointList.
66  Since no subtype Window.Put.Get exists, Box should convert pl to its child
67  (an object of type PointList) and try to find a subtype .Get
68  The problem should be faced in a more general way, allowing automatic
69  conversion of types at (]), see 8
706 The VM should be instructed about how to create or destroy types.
71  This process has already been started, but needs to be completed.
72  In the end Box should be able to create hidden procedures for destroying
73  those data types that need a special treatment (structures in particular).
74  The compiler then should communicate to the VM what procedure to call
75  for destroying what type. The destruction will then be operated
76  automatically by the VM when the reference count reaches 0.
77  Types associated with the destroyed type will be destroyed as well
78  in a recursive fashion.
79
80TODO LIST FOR THE GRAPHIC LIBRARY
81---------------------------------
82In order of importance:
837. Window should be able to take an already existing image
84   as a background for the new one. We should be able to include
85   existing images.
868. Use ImageMagick for saving to many formats which are not currently
87   supported.
889. We need in particular to support gif for animations!
89
90DONE
91----
921. Add possibility of setting cap style to Style;
93   add possibility of setting the dash offset to Style.Dash
942. Make Window[] to create a WindowPlan without creating the actual Window.
95   This will allow to extend the Window.Save syntax in a sensible way:
96
97     w.Save["filename.ext", Window["rgb24", .Res[10]]]
98
99   Be careful! Example:
100
101     w = Window["rgb24"]
102     w.Line[...] // Will segfault if w is not initialised
103
104   DONE with the introduction of "incomplete" Windows. Incomplete windows
105   are windows which could not be created, due to some missing params
106   during initialisation. They cause errors only when the user tries to
107   draw something on them. However they can be used as argument for the
108   Window.Save method, which will "complete" the window appropriately.
1093. Polygons should not be closed, when they are not filled.
110   They should be closed only when using Poly.Close[]
1114. Add functions Deg[] (convert angle from degrees to radians)
112   and Dpi[] (convert resolution from dpi to points per mm.
1135. Add function HSV[] useful for expressing colors in HSV components.
114   Add HSV@Color and Color@HSV. Add HSV@(Window, Line, Poly, etc.)
1156. Add Gradient[] for filling with gradients.
116
117OPEN JOBS
118---------
119- adjust Box grammar and introduce proper compilation through abstract
120  syntax trees. This will allow to add "templates" and make the language
121  much more powerful and robust. Error detection will also benefit
122  from this improvement;
123- develop a bytecode file format for Box, so that already compiled
124  sources can be loaded and linked (similar to pyc files for python);
125- Add support for LaTeX: we should understand what is the right approach
126  (call latex+dvips+imagemagick or can we use directly the dvi file?)
127- Integrate imagemagick into the Box graphic library and make it work
128  together with Cairo: we want to support as many output formats as possible
129  and to be able include pictures (in various file formats) into the working
130  Window. We want also to be able to produce animated gifs and maybe
131  use mencoder for producing movies.
132
133