| paul@810 | 1 | = Lichen = |
| paul@810 | 2 | |
| paul@810 | 3 | || [[/Downloads|Downloads]] || [[#Language|Language]] || [[#Toolchain|Toolchain]] || [[#Rationale|Rationale]] || [[#Documents|Documents]] || |
| paul@810 | 4 | |
| paul@810 | 5 | Lichen is both a Python-like [[/Design|language]] and a [[/Toolchain|toolchain]] for that language. |
| paul@810 | 6 | |
| paul@810 | 7 | Some objectives: |
| paul@810 | 8 | |
| paul@810 | 9 | * Perform analysis on programs to better understand program structure and behaviour |
| paul@810 | 10 | * Develop code generation capabilities |
| paul@810 | 11 | * Provide a platform for experimentation independent of existing Python language and library implementations |
| paul@810 | 12 | * Provide independence from Python language evolution |
| paul@810 | 13 | * Learn things about writing compilers |
| paul@810 | 14 | |
| paul@810 | 15 | Despite building on a long [[/History|history]] of experimentation, Lichen still requires some [[/ToDo|work to be done]] for it to be more widely usable. |
| paul@810 | 16 | |
| paul@810 | 17 | <<Anchor(Language)>> |
| paul@810 | 18 | == Language == |
| paul@810 | 19 | |
| paul@810 | 20 | The Lichen language [[/Design|foregoes]] various dynamic aspects of Python to provide a foundation upon which more predictable programs can be built, while preserving essential functionality to make the core of the language seem very much "like Python" (thus yielding the name "Lichen"). The general syntax is largely identical to Python, with only certain syntactic constructs being deliberately unsupported, largely because the associated features are not desired. |
| paul@810 | 21 | |
| paul@810 | 22 | <<Anchor(Toolchain)>> |
| paul@810 | 23 | == Toolchain == |
| paul@810 | 24 | |
| paul@810 | 25 | The Lichen [[/Toolchain|toolchain]] employs existing tokeniser and parser software to obtain an abstract syntax tree which is then inspected to provide data to support deductions about the structure and nature of a given program. With the information obtained from these processes, a program is then constructed, consisting of a number of source files in the target compilation language (which is currently the C programming language). This generated program may be compiled and run, hopefully producing the results intended by the source program's authors. |
| paul@810 | 26 | |
| paul@810 | 27 | Lichen source files use the `.py` suffix since the language syntax is superficially compatible with Python, allowing text editors to provide highlighting and editing support for Lichen programs without the need to reconfigure such tools. However, an alternative, recommended suffix is likely to be introduced in future. |
| paul@810 | 28 | |
| paul@810 | 29 | <<Anchor(Library)>> |
| paul@810 | 30 | == Library == |
| paul@810 | 31 | |
| paul@810 | 32 | Unlike other Python compilation efforts, Lichen programs employ a newly-written library that is distinct from the CPython standard library distribution and completely independent from the CPython extension and object libraries on which Python programs being run with CPython must depend. Thus, there is no dependency on any `libpython` for run-time functionality. Since the parts of the Python standard library that are written in Python tend to be rather variable in quality, there has been no real inclination to re-use modules from that particular source, noting that they would need modifying to be compatible with Lichen, anyway. However, rewriting such modules provides opportunities to "do things right": with some functionality being over twenty years old and in bad shape, this is arguably something that should have been done for Python, anyway. |
| paul@810 | 33 | |
| paul@810 | 34 | <<Anchor(Rationale)>> |
| paul@810 | 35 | == Rationale == |
| paul@810 | 36 | |
| paul@810 | 37 | Python has proven to be a readable, productive, comfortable-to-use and popular programming language. However, as it has accumulated features, the precise behaviour of programs making use of many of these features has become more difficult to predict. Features added to provide even more convenience to the programmer have often incurred run-time costs, introduced layers of indirection, and have made programs even more inscrutable. Instead of development tools reaching a point of being able to infer information about programs, it has been suggested that programmers annotate their programs in order to help tools understand those programs instead. Beyond superficial code style analysis and providing tooltips in integrated development environments, Python code analysis is often portrayed as a lost cause. |
| paul@810 | 38 | |
| paul@810 | 39 | By employing a refined language [[/Design|design]], Lichen aims to let each program define its [[/Structure|structure]] conveniently, be readily [[/Inspection|inspected]], and thus support [[/Deduction|deductions]] about the use of the program's objects by the code. The result should be more predictable programs that can be [[/Translation|translated]] to other, more efficient, [[/Representations|representations]]. The Lichen toolchain should be able to tell the programmer useful things about their programs that it may also be able to make use of itself. It not only aims to report information about programs that might be of interest to the developer, but it seeks to produce functioning, translated programs that can actually be run. |
| paul@810 | 40 | |
| paul@810 | 41 | <<Anchor(Documents)>> |
| paul@810 | 42 | == Document Index == |
| paul@810 | 43 | |
| paul@810 | 44 | <<FullSearch(title:Lichen/)>> |
