Lichen

Change of docs/wiki/FrontPage

898:316708ceb335
docs/wiki/FrontPage
     1.1 --- a/docs/wiki/FrontPage	Mon Feb 04 18:30:28 2019 +0100
     1.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.3 @@ -1,95 +0,0 @@
     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 -<<FullSearch(title:Lichen/)>>