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