Lichen

Annotated docs/wiki/ToDo

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