+
1
|
list
|
skin
|
login
|
editor
α-wwwiki
::
lambdatalk
user:none
(1873 bytes)
_h1 lambdatalk _p The quest of a good parser for the wiki syntax has been a long travel in the Lisp world. Two approaches were analyzed in parallel, the "string way" and the "array way". Some explanations can be seen in the page [[evaluation]] (in french). _h3 1) array way _p A slow progression led to a mini dialect of Lisp built on a standard "tokenize->build_nested_array->evaluate" engine. With two alternatives in the way is built the lambda function : _ul {b 1) monodicolisp}, where the binding between the arguments and the values is dynamic (at the lambda call) and the dictionary is unique. This can be tested in the : {center {@ style="font-size:3em;"} [[monodicolisp console|?view=monodicolisp]]} _ul {b 2) alphalisp}, with nested environments where are bound the arguments and their values, following a lexical scope. This can be tested in the : {center {@ style="font-size:3em;"} [[alphalisp console|?view=lisp_evaluator]]} _p The positive point is the good set of Lisp standard functionalities. The negative is that they are not easy to manipulate in a wiki context. _h3 2) string way _p Begining with the actual parser of alphawiki, another progression led to a rather different approach based on a single loop working with a unique regular expression and a single dictionary. The last step is {b lambdatalk} which can be tested in the : {center {@ style="font-size:3em;"}[[lambdatalk console|data/lambdatalk/]]} _p The negative point is the very small set of Lisp standard functionalities. The positive is their good behaviour in a wiki context. _h3 3) todo _p {b lambdatalk} has first to be translated from the console into the wiki structure. The future could be a twin cylinders engine : {b lambdatalk + alphalisp}, the first for the plain text manipulations and the last for the numbers computations. _p A suivre ...