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