1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/wiki/Lichen Sun Apr 14 19:31:45 2019 +0200
1.3 @@ -0,0 +1,95 @@
1.4 += Lichen =
1.5 +
1.6 +|| [[/Downloads|Downloads]] || [[#Language|Language]] || [[#Toolchain|Toolchain]] || [[#Rationale|Rationale]] || [[#Documents|Documents]] ||
1.7 +
1.8 +Lichen is both a Python-like [[/Design|language]] and a
1.9 +[[/Toolchain|toolchain]] for that language.
1.10 +
1.11 +Some objectives:
1.12 +
1.13 + * Perform analysis on programs to better understand program structure and
1.14 + behaviour
1.15 + * Develop code generation capabilities
1.16 + * Provide a platform for experimentation independent of existing Python
1.17 + language and library implementations
1.18 + * Provide independence from Python language evolution
1.19 + * Learn things about writing compilers
1.20 +
1.21 +Despite building on a long [[/History|history]] of experimentation, Lichen
1.22 +still requires some [[/ToDo|work to be done]] for it to be more widely usable.
1.23 +
1.24 +<<Anchor(Language)>>
1.25 +== Language ==
1.26 +
1.27 +The Lichen language [[/Design|foregoes]] various dynamic aspects of Python to
1.28 +provide a foundation upon which more predictable programs can be built, while
1.29 +preserving essential functionality to make the core of the language seem very
1.30 +much "like Python" (thus yielding the name "Lichen"). The general syntax is
1.31 +largely identical to Python, with only certain syntactic constructs being
1.32 +deliberately unsupported, largely because the associated features are not
1.33 +desired.
1.34 +
1.35 +<<Anchor(Toolchain)>>
1.36 +== Toolchain ==
1.37 +
1.38 +The Lichen [[/Toolchain|toolchain]] employs existing tokeniser and parser
1.39 +software to obtain an abstract syntax tree which is then inspected to provide
1.40 +data to support deductions about the structure and nature of a given program.
1.41 +With the information obtained from these processes, a program is then
1.42 +constructed, consisting of a number of source files in the target compilation
1.43 +language (which is currently the C programming language). This generated
1.44 +program may be compiled and run, hopefully producing the results intended by
1.45 +the source program's authors.
1.46 +
1.47 +Lichen source files use the `.py` suffix since the language syntax is
1.48 +superficially compatible with Python, allowing text editors to provide
1.49 +highlighting and editing support for Lichen programs without the need to
1.50 +reconfigure such tools. However, an alternative, recommended suffix is likely
1.51 +to be introduced in future.
1.52 +
1.53 +<<Anchor(Library)>>
1.54 +== Library ==
1.55 +
1.56 +Unlike other Python compilation efforts, Lichen programs employ a newly-written
1.57 +library that is distinct from the CPython standard library distribution and
1.58 +completely independent from the CPython extension and object libraries on which
1.59 +Python programs being run with CPython must depend. Thus, there is no
1.60 +dependency on any `libpython` for run-time functionality. Since the parts of
1.61 +the Python standard library that are written in Python tend to be rather
1.62 +variable in quality, there has been no real inclination to re-use modules from
1.63 +that particular source, noting that they would need modifying to be compatible
1.64 +with Lichen, anyway. However, rewriting such modules provides opportunities to
1.65 +"do things right": with some functionality being over twenty years old and in
1.66 +bad shape, this is arguably something that should have been done for Python,
1.67 +anyway.
1.68 +
1.69 +<<Anchor(Rationale)>>
1.70 +== Rationale ==
1.71 +
1.72 +Python has proven to be a readable, productive, comfortable-to-use and popular
1.73 +programming language. However, as it has accumulated features, the precise
1.74 +behaviour of programs making use of many of these features has become more
1.75 +difficult to predict. Features added to provide even more convenience to the
1.76 +programmer have often incurred run-time costs, introduced layers of
1.77 +indirection, and have made programs even more inscrutable. Instead of
1.78 +development tools reaching a point of being able to infer information about
1.79 +programs, it has been suggested that programmers annotate their programs in
1.80 +order to help tools understand those programs instead. Beyond superficial code
1.81 +style analysis and providing tooltips in integrated development environments,
1.82 +Python code analysis is often portrayed as a lost cause.
1.83 +
1.84 +By employing a refined language [[/Design|design]], Lichen aims to let each
1.85 +program define its [[/Structure|structure]] conveniently, be readily
1.86 +[[/Inspection|inspected]], and thus support [[/Deduction|deductions]] about the
1.87 +use of the program's objects by the code. The result should be more predictable
1.88 +programs that can be [[/Translation|translated]] to other, more efficient,
1.89 +[[/Representations|representations]]. The Lichen toolchain should be able to
1.90 +tell the programmer useful things about their programs that it may also be able
1.91 +to make use of itself. It not only aims to report information about programs
1.92 +that might be of interest to the developer, but it seeks to produce
1.93 +functioning, translated programs that can actually be run.
1.94 +
1.95 +<<Anchor(Documents)>>
1.96 +== Document Index ==
1.97 +
1.98 +<<PageList>>