Lichen

docs/wiki/ToDo

861:f745d151a441
2018-08-17 Paul Boddie Wrapped text in the documentation for more convenient "offline" editing.
     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.