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