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