return page history
α-wwwiki
::
history/lambdatalk/20131020-004732.txt
editor : alpha [82.249.146.218] 2013/10/20 00:47:32 _h1 lambdatalk _p The quest of a good parser for the wiki syntax led to 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 is dynamic (at the lambda call) and the dictionary unique. It can be tested in the : {center {@ style="font-size:3em;"} [[monodicolisp console|?view=monodicolisp]]} _ul {b 2) alphalisp}, with nested environments where are bounds the arguments and their values in a function, following a lexical scope. It 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. But they are not an easy answer 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 point is the good behaviour of the engine in a wiki context. _h3 3) todo _p {b lambdatalk} has first to go from the console to the wiki structure. The future could be a twincylinders engine : {b lambdatalk + alphalisp}, the first for the plain text manipulations and the last for the numbers computations. _p A suivre ...