Lichen

Changeset

898:316708ceb335
2019-04-14 Paul Boddie raw files shortlog changelog graph Renamed FrontPage to Lichen, also changing the FullSearch macro to PageList. Updated the page packaging script and added a script for moinconvert.
docs/tools/make_docs.sh (file) docs/tools/make_pages.sh (file) docs/wiki/FrontPage docs/wiki/Lichen (file)
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/tools/make_docs.sh	Sun Apr 14 19:31:45 2019 +0200
     1.3 @@ -0,0 +1,28 @@
     1.4 +#!/bin/sh
     1.5 +
     1.6 +THISDIR=`dirname "$0"`
     1.7 +INDIR="$THISDIR/../wiki"
     1.8 +OUTDIR="$THISDIR/../html"
     1.9 +
    1.10 +MAPPING='--mapping WikiPedia https://en.wikipedia.org/wiki/'
    1.11 +THEME='--theme mercurial'
    1.12 +
    1.13 +if [ "$1" = '--web' ] ; then
    1.14 +    DOCINDEX=
    1.15 +    shift 1
    1.16 +else
    1.17 +    DOCINDEX='--document-index index.html'
    1.18 +fi
    1.19 +
    1.20 +FILENAMES=${*:-'--all'}
    1.21 +
    1.22 +moinconvert --input-dir "$INDIR" \
    1.23 +            --input-page-sep '--' \
    1.24 +            --output-dir "$OUTDIR" \
    1.25 +            --root Lichen \
    1.26 +            --format html \
    1.27 +            --macros \
    1.28 +            $DOCINDEX \
    1.29 +            $MAPPING \
    1.30 +            $THEME \
    1.31 +            $FILENAMES
     2.1 --- a/docs/tools/make_pages.sh	Mon Feb 04 18:30:28 2019 +0100
     2.2 +++ b/docs/tools/make_pages.sh	Sun Apr 14 19:31:45 2019 +0200
     2.3 @@ -56,7 +56,7 @@
     2.4      BASENAME=`basename "$FILENAME"`
     2.5      PAGENAME=`echo "$BASENAME" | sed 's/--/\//g'`
     2.6      if [ "$PREFIX" ]; then
     2.7 -        if [ "$PAGENAME" = "FrontPage" ]; then
     2.8 +        if [ "$PAGENAME" = "Lichen" ]; then
     2.9              PAGENAME="$PREFIX"
    2.10          else
    2.11              PAGENAME="$PREFIX/$PAGENAME"
     3.1 --- a/docs/wiki/FrontPage	Mon Feb 04 18:30:28 2019 +0100
     3.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.3 @@ -1,95 +0,0 @@
     3.4 -= Lichen =
     3.5 -
     3.6 -|| [[/Downloads|Downloads]] || [[#Language|Language]] || [[#Toolchain|Toolchain]] || [[#Rationale|Rationale]] || [[#Documents|Documents]] ||
     3.7 -
     3.8 -Lichen is both a Python-like [[/Design|language]] and a
     3.9 -[[/Toolchain|toolchain]] for that language.
    3.10 -
    3.11 -Some objectives:
    3.12 -
    3.13 - * Perform analysis on programs to better understand program structure and
    3.14 -   behaviour
    3.15 - * Develop code generation capabilities
    3.16 - * Provide a platform for experimentation independent of existing Python
    3.17 -   language and library implementations
    3.18 - * Provide independence from Python language evolution
    3.19 - * Learn things about writing compilers
    3.20 -
    3.21 -Despite building on a long [[/History|history]] of experimentation, Lichen
    3.22 -still requires some [[/ToDo|work to be done]] for it to be more widely usable.
    3.23 -
    3.24 -<<Anchor(Language)>>
    3.25 -== Language ==
    3.26 -
    3.27 -The Lichen language [[/Design|foregoes]] various dynamic aspects of Python to
    3.28 -provide a foundation upon which more predictable programs can be built, while
    3.29 -preserving essential functionality to make the core of the language seem very
    3.30 -much "like Python" (thus yielding the name "Lichen"). The general syntax is
    3.31 -largely identical to Python, with only certain syntactic constructs being
    3.32 -deliberately unsupported, largely because the associated features are not
    3.33 -desired.
    3.34 -
    3.35 -<<Anchor(Toolchain)>>
    3.36 -== Toolchain ==
    3.37 -
    3.38 -The Lichen [[/Toolchain|toolchain]] employs existing tokeniser and parser
    3.39 -software to obtain an abstract syntax tree which is then inspected to provide
    3.40 -data to support deductions about the structure and nature of a given program.
    3.41 -With the information obtained from these processes, a program is then
    3.42 -constructed, consisting of a number of source files in the target compilation
    3.43 -language (which is currently the C programming language). This generated
    3.44 -program may be compiled and run, hopefully producing the results intended by
    3.45 -the source program's authors.
    3.46 -
    3.47 -Lichen source files use the `.py` suffix since the language syntax is
    3.48 -superficially compatible with Python, allowing text editors to provide
    3.49 -highlighting and editing support for Lichen programs without the need to
    3.50 -reconfigure such tools. However, an alternative, recommended suffix is likely
    3.51 -to be introduced in future.
    3.52 -
    3.53 -<<Anchor(Library)>>
    3.54 -== Library ==
    3.55 -
    3.56 -Unlike other Python compilation efforts, Lichen programs employ a newly-written
    3.57 -library that is distinct from the CPython standard library distribution and
    3.58 -completely independent from the CPython extension and object libraries on which
    3.59 -Python programs being run with CPython must depend. Thus, there is no
    3.60 -dependency on any `libpython` for run-time functionality. Since the parts of
    3.61 -the Python standard library that are written in Python tend to be rather
    3.62 -variable in quality, there has been no real inclination to re-use modules from
    3.63 -that particular source, noting that they would need modifying to be compatible
    3.64 -with Lichen, anyway. However, rewriting such modules provides opportunities to
    3.65 -"do things right": with some functionality being over twenty years old and in
    3.66 -bad shape, this is arguably something that should have been done for Python,
    3.67 -anyway.
    3.68 -
    3.69 -<<Anchor(Rationale)>>
    3.70 -== Rationale ==
    3.71 -
    3.72 -Python has proven to be a readable, productive, comfortable-to-use and popular
    3.73 -programming language. However, as it has accumulated features, the precise
    3.74 -behaviour of programs making use of many of these features has become more
    3.75 -difficult to predict. Features added to provide even more convenience to the
    3.76 -programmer have often incurred run-time costs, introduced layers of
    3.77 -indirection, and have made programs even more inscrutable. Instead of
    3.78 -development tools reaching a point of being able to infer information about
    3.79 -programs, it has been suggested that programmers annotate their programs in
    3.80 -order to help tools understand those programs instead. Beyond superficial code
    3.81 -style analysis and providing tooltips in integrated development environments,
    3.82 -Python code analysis is often portrayed as a lost cause.
    3.83 -
    3.84 -By employing a refined language [[/Design|design]], Lichen aims to let each
    3.85 -program define its [[/Structure|structure]] conveniently, be readily
    3.86 -[[/Inspection|inspected]], and thus support [[/Deduction|deductions]] about the
    3.87 -use of the program's objects by the code. The result should be more predictable
    3.88 -programs that can be [[/Translation|translated]] to other, more efficient,
    3.89 -[[/Representations|representations]]. The Lichen toolchain should be able to
    3.90 -tell the programmer useful things about their programs that it may also be able
    3.91 -to make use of itself. It not only aims to report information about programs
    3.92 -that might be of interest to the developer, but it seeks to produce
    3.93 -functioning, translated programs that can actually be run.
    3.94 -
    3.95 -<<Anchor(Documents)>>
    3.96 -== Document Index ==
    3.97 -
    3.98 -<<FullSearch(title:Lichen/)>>
     4.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     4.2 +++ b/docs/wiki/Lichen	Sun Apr 14 19:31:45 2019 +0200
     4.3 @@ -0,0 +1,95 @@
     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 +<<PageList>>