|Page 23 of 800||Search internet|
Knuths WEB programming language allows to express Pascal programs in a 'psychologically correct order'. Versions like CWEB allow to do the same for other languages. The Logiweb programming language has a similar aim. It is suggested to authors to write Logiweb pages in a 'pedagogically correct order', i.e. to organize each Logiweb page in an order which is convenient for the reader.
In the WEB programming language, the author can express a program in one order and arrange that the program is presented to the Pascal compiler in some other order. When using the Logiweb programming language for writing Logiweb programs, the approach is somewhat different: Except for pathological examples, the order in which definitions are stated does not matter.
Order independence comes at a cost: Translation of a Logiweb program requires much more computing resources than tangling a WEB program.
This becomes particularly evident when considering macros. It may be pedagogically correct to give a macro definition after first time the macro is used. To cope with that, the lgc compiler reads each source text more than once.
At first reading, the lgc compiler macro expands the source text according to all macro definitions present on referenced pages. After that, the lgc compiler 'harvests' the page, i.e. it scans the page for definitions. All definitions, including macro definitions, end up in a structure called the 'codex' which resides inside the 'rack' of the page.
At second reading, the lgc compiler does the same, except that it also uses all macro definitions present in the codex from the first reading.
The lgc compiler keeps reading the page over and over again until it reaches a fixed point (if ever). A fixed point is one where the codices of two, consecutive readings are identical.
Reading the same page over and over is like running a TeX source through TeX until there are no more 'references may have changed' messages.
The lgc compiler only parses a source text one time, even if it does more than one reading. In this context, 'reading a page' involves macro expansion of the parse tree of the page followed by harvesting (plus a few small additional activities). The parse tree is the output the parser and each reading is based on the same parse tree.
The lgc compiler always reads a page at least two times because it needs two versions of the codex to see if it has reached a fixed point.
The base page is particularly complicated. At the time of writing, the lgc compiler has to read the base page nine times to reach a fixed point. That is because the base page does lots of non-trivial things like macro defining constructs for making macro definitions, using macros for defining pattern matching let constructs, and many other things.
If you ever modify the base page, be sure to keep the old versions of the base page during the development. All facilities for debugging are defined on the base page, so it you screw up something, you may loose all debugging facilities at the same time. A good starting point for modifying the base page may be to rename it to e.g. mybase and its source file to e.g. mybase.lgs.
The Logiweb programming language is most suited for expressing Logiweb programs, but is also quite suited for expressing programs in arbitrary, other languages. Extraction of programs expressed in arbitrary languages can be done during rendering. As mentioned, the rendering capabilities of Logiweb are Turing complete so rendering can do anything a computer can do.
|Page 23 of 800||Search logiweb.eu|