Lichen

Annotated docs/wiki/ToDo

884:c34258c62630
2019-02-01 Paul Boddie Fixed instance definitions to use the correct size identifiers, not those for classes. This fixes instance size calculations and instance allocation.
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.