Lichen

Changeset

903:e42488d172c5
2019-05-27 Paul Boddie raw files shortlog changelog graph Merged changes from the default branch. trailing-data
docs/wiki/FrontPage
     1.1 --- a/docs/COPYING.txt	Mon Feb 04 18:53:56 2019 +0100
     1.2 +++ b/docs/COPYING.txt	Mon May 27 11:58:58 2019 +0200
     1.3 @@ -1,8 +1,8 @@
     1.4  Licence Agreement
     1.5  -----------------
     1.6  
     1.7 -Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
     1.8 -              2014, 2015, 2016, 2017 Paul Boddie <paul@boddie.org.uk>
     1.9 +Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015,
    1.10 +              2016, 2017, 2018, 2019 Paul Boddie <paul@boddie.org.uk>
    1.11  
    1.12  This program is free software; you can redistribute it and/or modify it under
    1.13  the terms of the GNU General Public License as published by the Free Software
     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/docs/tools/make_docs.sh	Mon May 27 11:58:58 2019 +0200
     2.3 @@ -0,0 +1,30 @@
     2.4 +#!/bin/sh
     2.5 +
     2.6 +THISDIR=`dirname "$0"`
     2.7 +INDIR="$THISDIR/../wiki"
     2.8 +OUTDIR="$THISDIR/../html"
     2.9 +
    2.10 +ROOT="Lichen"
    2.11 +
    2.12 +MAPPING='--mapping WikiPedia https://en.wikipedia.org/wiki/'
    2.13 +THEME='--theme mercurial'
    2.14 +
    2.15 +if [ "$1" = '--web' ] ; then
    2.16 +    DOCINDEX=
    2.17 +    shift 1
    2.18 +else
    2.19 +    DOCINDEX='--document-index index.html'
    2.20 +fi
    2.21 +
    2.22 +FILENAMES=${*:-'--all'}
    2.23 +
    2.24 +moinconvert --input-dir "$INDIR" \
    2.25 +            --input-page-sep '--' \
    2.26 +            --output-dir "$OUTDIR" \
    2.27 +            --root "$ROOT" \
    2.28 +            --format html \
    2.29 +            --macros \
    2.30 +            $DOCINDEX \
    2.31 +            $MAPPING \
    2.32 +            $THEME \
    2.33 +            $FILENAMES
     3.1 --- a/docs/tools/make_pages.sh	Mon Feb 04 18:53:56 2019 +0100
     3.2 +++ b/docs/tools/make_pages.sh	Mon May 27 11:58:58 2019 +0200
     3.3 @@ -56,7 +56,7 @@
     3.4      BASENAME=`basename "$FILENAME"`
     3.5      PAGENAME=`echo "$BASENAME" | sed 's/--/\//g'`
     3.6      if [ "$PREFIX" ]; then
     3.7 -        if [ "$PAGENAME" = "FrontPage" ]; then
     3.8 +        if [ "$PAGENAME" = "Lichen" ]; then
     3.9              PAGENAME="$PREFIX"
    3.10          else
    3.11              PAGENAME="$PREFIX/$PAGENAME"
     4.1 --- a/docs/wiki/FrontPage	Mon Feb 04 18:53:56 2019 +0100
     4.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     4.3 @@ -1,95 +0,0 @@
     4.4 -= Lichen =
     4.5 -
     4.6 -|| [[/Downloads|Downloads]] || [[#Language|Language]] || [[#Toolchain|Toolchain]] || [[#Rationale|Rationale]] || [[#Documents|Documents]] ||
     4.7 -
     4.8 -Lichen is both a Python-like [[/Design|language]] and a
     4.9 -[[/Toolchain|toolchain]] for that language.
    4.10 -
    4.11 -Some objectives:
    4.12 -
    4.13 - * Perform analysis on programs to better understand program structure and
    4.14 -   behaviour
    4.15 - * Develop code generation capabilities
    4.16 - * Provide a platform for experimentation independent of existing Python
    4.17 -   language and library implementations
    4.18 - * Provide independence from Python language evolution
    4.19 - * Learn things about writing compilers
    4.20 -
    4.21 -Despite building on a long [[/History|history]] of experimentation, Lichen
    4.22 -still requires some [[/ToDo|work to be done]] for it to be more widely usable.
    4.23 -
    4.24 -<<Anchor(Language)>>
    4.25 -== Language ==
    4.26 -
    4.27 -The Lichen language [[/Design|foregoes]] various dynamic aspects of Python to
    4.28 -provide a foundation upon which more predictable programs can be built, while
    4.29 -preserving essential functionality to make the core of the language seem very
    4.30 -much "like Python" (thus yielding the name "Lichen"). The general syntax is
    4.31 -largely identical to Python, with only certain syntactic constructs being
    4.32 -deliberately unsupported, largely because the associated features are not
    4.33 -desired.
    4.34 -
    4.35 -<<Anchor(Toolchain)>>
    4.36 -== Toolchain ==
    4.37 -
    4.38 -The Lichen [[/Toolchain|toolchain]] employs existing tokeniser and parser
    4.39 -software to obtain an abstract syntax tree which is then inspected to provide
    4.40 -data to support deductions about the structure and nature of a given program.
    4.41 -With the information obtained from these processes, a program is then
    4.42 -constructed, consisting of a number of source files in the target compilation
    4.43 -language (which is currently the C programming language). This generated
    4.44 -program may be compiled and run, hopefully producing the results intended by
    4.45 -the source program's authors.
    4.46 -
    4.47 -Lichen source files use the `.py` suffix since the language syntax is
    4.48 -superficially compatible with Python, allowing text editors to provide
    4.49 -highlighting and editing support for Lichen programs without the need to
    4.50 -reconfigure such tools. However, an alternative, recommended suffix is likely
    4.51 -to be introduced in future.
    4.52 -
    4.53 -<<Anchor(Library)>>
    4.54 -== Library ==
    4.55 -
    4.56 -Unlike other Python compilation efforts, Lichen programs employ a newly-written
    4.57 -library that is distinct from the CPython standard library distribution and
    4.58 -completely independent from the CPython extension and object libraries on which
    4.59 -Python programs being run with CPython must depend. Thus, there is no
    4.60 -dependency on any `libpython` for run-time functionality. Since the parts of
    4.61 -the Python standard library that are written in Python tend to be rather
    4.62 -variable in quality, there has been no real inclination to re-use modules from
    4.63 -that particular source, noting that they would need modifying to be compatible
    4.64 -with Lichen, anyway. However, rewriting such modules provides opportunities to
    4.65 -"do things right": with some functionality being over twenty years old and in
    4.66 -bad shape, this is arguably something that should have been done for Python,
    4.67 -anyway.
    4.68 -
    4.69 -<<Anchor(Rationale)>>
    4.70 -== Rationale ==
    4.71 -
    4.72 -Python has proven to be a readable, productive, comfortable-to-use and popular
    4.73 -programming language. However, as it has accumulated features, the precise
    4.74 -behaviour of programs making use of many of these features has become more
    4.75 -difficult to predict. Features added to provide even more convenience to the
    4.76 -programmer have often incurred run-time costs, introduced layers of
    4.77 -indirection, and have made programs even more inscrutable. Instead of
    4.78 -development tools reaching a point of being able to infer information about
    4.79 -programs, it has been suggested that programmers annotate their programs in
    4.80 -order to help tools understand those programs instead. Beyond superficial code
    4.81 -style analysis and providing tooltips in integrated development environments,
    4.82 -Python code analysis is often portrayed as a lost cause.
    4.83 -
    4.84 -By employing a refined language [[/Design|design]], Lichen aims to let each
    4.85 -program define its [[/Structure|structure]] conveniently, be readily
    4.86 -[[/Inspection|inspected]], and thus support [[/Deduction|deductions]] about the
    4.87 -use of the program's objects by the code. The result should be more predictable
    4.88 -programs that can be [[/Translation|translated]] to other, more efficient,
    4.89 -[[/Representations|representations]]. The Lichen toolchain should be able to
    4.90 -tell the programmer useful things about their programs that it may also be able
    4.91 -to make use of itself. It not only aims to report information about programs
    4.92 -that might be of interest to the developer, but it seeks to produce
    4.93 -functioning, translated programs that can actually be run.
    4.94 -
    4.95 -<<Anchor(Documents)>>
    4.96 -== Document Index ==
    4.97 -
    4.98 -<<FullSearch(title:Lichen/)>>
     5.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     5.2 +++ b/docs/wiki/Lichen	Mon May 27 11:58:58 2019 +0200
     5.3 @@ -0,0 +1,95 @@
     5.4 += Lichen =
     5.5 +
     5.6 +|| [[/Downloads|Downloads]] || [[#Language|Language]] || [[#Toolchain|Toolchain]] || [[#Rationale|Rationale]] || [[#Documents|Documents]] ||
     5.7 +
     5.8 +Lichen is both a Python-like [[/Design|language]] and a
     5.9 +[[/Toolchain|toolchain]] for that language.
    5.10 +
    5.11 +Some objectives:
    5.12 +
    5.13 + * Perform analysis on programs to better understand program structure and
    5.14 +   behaviour
    5.15 + * Develop code generation capabilities
    5.16 + * Provide a platform for experimentation independent of existing Python
    5.17 +   language and library implementations
    5.18 + * Provide independence from Python language evolution
    5.19 + * Learn things about writing compilers
    5.20 +
    5.21 +Despite building on a long [[/History|history]] of experimentation, Lichen
    5.22 +still requires some [[/ToDo|work to be done]] for it to be more widely usable.
    5.23 +
    5.24 +<<Anchor(Language)>>
    5.25 +== Language ==
    5.26 +
    5.27 +The Lichen language [[/Design|foregoes]] various dynamic aspects of Python to
    5.28 +provide a foundation upon which more predictable programs can be built, while
    5.29 +preserving essential functionality to make the core of the language seem very
    5.30 +much "like Python" (thus yielding the name "Lichen"). The general syntax is
    5.31 +largely identical to Python, with only certain syntactic constructs being
    5.32 +deliberately unsupported, largely because the associated features are not
    5.33 +desired.
    5.34 +
    5.35 +<<Anchor(Toolchain)>>
    5.36 +== Toolchain ==
    5.37 +
    5.38 +The Lichen [[/Toolchain|toolchain]] employs existing tokeniser and parser
    5.39 +software to obtain an abstract syntax tree which is then inspected to provide
    5.40 +data to support deductions about the structure and nature of a given program.
    5.41 +With the information obtained from these processes, a program is then
    5.42 +constructed, consisting of a number of source files in the target compilation
    5.43 +language (which is currently the C programming language). This generated
    5.44 +program may be compiled and run, hopefully producing the results intended by
    5.45 +the source program's authors.
    5.46 +
    5.47 +Lichen source files use the `.py` suffix since the language syntax is
    5.48 +superficially compatible with Python, allowing text editors to provide
    5.49 +highlighting and editing support for Lichen programs without the need to
    5.50 +reconfigure such tools. However, an alternative, recommended suffix is likely
    5.51 +to be introduced in future.
    5.52 +
    5.53 +<<Anchor(Library)>>
    5.54 +== Library ==
    5.55 +
    5.56 +Unlike other Python compilation efforts, Lichen programs employ a newly-written
    5.57 +library that is distinct from the CPython standard library distribution and
    5.58 +completely independent from the CPython extension and object libraries on which
    5.59 +Python programs being run with CPython must depend. Thus, there is no
    5.60 +dependency on any `libpython` for run-time functionality. Since the parts of
    5.61 +the Python standard library that are written in Python tend to be rather
    5.62 +variable in quality, there has been no real inclination to re-use modules from
    5.63 +that particular source, noting that they would need modifying to be compatible
    5.64 +with Lichen, anyway. However, rewriting such modules provides opportunities to
    5.65 +"do things right": with some functionality being over twenty years old and in
    5.66 +bad shape, this is arguably something that should have been done for Python,
    5.67 +anyway.
    5.68 +
    5.69 +<<Anchor(Rationale)>>
    5.70 +== Rationale ==
    5.71 +
    5.72 +Python has proven to be a readable, productive, comfortable-to-use and popular
    5.73 +programming language. However, as it has accumulated features, the precise
    5.74 +behaviour of programs making use of many of these features has become more
    5.75 +difficult to predict. Features added to provide even more convenience to the
    5.76 +programmer have often incurred run-time costs, introduced layers of
    5.77 +indirection, and have made programs even more inscrutable. Instead of
    5.78 +development tools reaching a point of being able to infer information about
    5.79 +programs, it has been suggested that programmers annotate their programs in
    5.80 +order to help tools understand those programs instead. Beyond superficial code
    5.81 +style analysis and providing tooltips in integrated development environments,
    5.82 +Python code analysis is often portrayed as a lost cause.
    5.83 +
    5.84 +By employing a refined language [[/Design|design]], Lichen aims to let each
    5.85 +program define its [[/Structure|structure]] conveniently, be readily
    5.86 +[[/Inspection|inspected]], and thus support [[/Deduction|deductions]] about the
    5.87 +use of the program's objects by the code. The result should be more predictable
    5.88 +programs that can be [[/Translation|translated]] to other, more efficient,
    5.89 +[[/Representations|representations]]. The Lichen toolchain should be able to
    5.90 +tell the programmer useful things about their programs that it may also be able
    5.91 +to make use of itself. It not only aims to report information about programs
    5.92 +that might be of interest to the developer, but it seeks to produce
    5.93 +functioning, translated programs that can actually be run.
    5.94 +
    5.95 +<<Anchor(Documents)>>
    5.96 +== Document Index ==
    5.97 +
    5.98 +<<PageList>>