1 = To Do = 2 3 As always with software, there are still many things that need to be done. 4 Here is a list of a few of them. 5 6 <<TableOfContents(2,3)>> 7 8 == Finish the Core Standard Library == 9 10 Lichen provides its own core standard library featuring the 11 [[../Builtins|built-ins]] and other essential modules, with only a small 12 amount of native code supporting implementations written in the Lichen 13 language. 14 15 === Numeric Types === 16 17 Support all the numeric types. Currently, only `int` is supported, but `float` 18 merely requires some native code handling operations and testing for exception 19 conditions. A representation for `long` needs to be determined, and `complex` 20 probably just needs some methods implementing. 21 22 Support promotion between some of the numeric types. Currently, `int` values 23 that overflow raise `OverflowError`, as was done in Python before automatic 24 promotion to `long`. 25 26 === String Types === 27 28 The remaining methods need defining for byte and Unicode strings. Some methods 29 are more complicated than others, particularly where some interpretation of 30 the content is required: identification of case, whitespace, punctuation, and 31 so on. 32 33 Some Unicode operations could be implemented in the Lichen language, not in C. 34 35 === Sequence and Mapping Types === 36 37 Various methods still need defining in the dictionary, list, tuple and set 38 classes to provide parity with Python. 39 40 === Hashing === 41 42 Unlike Python, the hashing approaches currently employed are not well-tuned. 43 One important difference between Lichen and Python is that the former does not 44 use hashtables as a general structure for objects, meaning that certain 45 desirable criteria for Python hashtables (randomising certain aspects of their 46 behaviour to prevent the exploitation of poorly performing cases) are less 47 important for Lichen. 48 49 == Provide Peripheral Library Support == 50 51 The Python standard library offers support for things like networking which 52 require a degree of system-level integration. The Lichen libraries could be 53 expanded to offer coverage of many of the same APIs. 54 55 === Versatile Native Libraries === 56 57 Currently, the native functionality already exposes things like file 58 descriptors, and a relatively simple versatile interface might be sufficient 59 for many future libraries. 60 61 == Incremental Compilation == 62 63 To some extent, the toolchain supports the caching of inspection results with 64 selective regeneration upon changes to source files. However, deduction and 65 subsequent activities are performed in their entirety every time. 66 67 === Preserving Structures === 68 69 Where source files have changed, it may be possible that the structure details 70 remain the same. Consequently, it is unnecessary to regenerate structures, and 71 it is only necessary to determine the nature of modified program operations. 72 73 Where structures have changed, certain existing operations may need to be 74 updated because such operations may no longer support certain types of object 75 or may support additional types. Meanwhile, changes to structures may be 76 compatible with existing structure layouts and not require such layouts to be 77 recomputed. 78 79 == Exploit Deductions Further == 80 81 So far, deductions have been used to inform the translation of certain 82 operations and to identify situations where suitable operations cannot be 83 generated. However, no attempt has been made to broaden the application of 84 such information. 85 86 === Parameter Type Checking === 87 88 Elementary knowledge about function parameters is currently available when 89 inspecting a program, but the deducer does not attempt to propagate such 90 information to likely callers of such functions. Such propagation in its 91 simplest form would merely use the list of potential targets for each 92 invocation, obtain the parameter types from each target, compare these types 93 to any readily-comparable argument (such as a name), and then determine which 94 targets may still be invoked successfully, potentially imposing restrictions 95 on the suitable targets as a result. 96 97 Such propagation activities can be time-consuming because they can lead to 98 iterative whole-program propagation occurring. Consider the restriction of an 99 invocation target: this may indicate a restriction on a name that provides 100 such a target, thus affecting the function parameter providing the name; such 101 a restriction could then be propagated to callers of that function, initiating 102 further refinement of other invocations, and so on.