Change of docs/wiki/Lichen

     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>>