return page history
α-wwwiki
::
history/lambdaway/20131021-081635.txt
editor : alpha [82.250.155.62] 2013/10/21 08:16:35 {center {i Would you like an english translation ? Ask me in the [[forum]] !}} _h1 °°{λy}°° {div {@ style="display:none;"}{define cod () °° var args = [].slice.call(arguments).join( ' ' ); var style= "font:normal 0.8em arial;" +"background:#888;" +"color:#fff;" +"text-align:center;" +"padding:0 5px;" +"border:1px solid;" +"box-shadow:0px 0px 2px black;" +"-webkit-border-radius:10px;" +"-moz-border-radius:10px;" +"border-radius:10px;"; return '{span {@ style="' + style + '"}' + args + '}'; °°}} _p Evaluer une S-expression dans le cadre d'un dictionnaire pré-défini est une chose assez simple, cf pages [[evaluation]] et [[yaw]]. Cela se complique lorsque certains de ses termes ne sont pas connus au moment de l'écriture. C'est à ce moment-là qu'apparaissent les {cod ifs}, les {cod lambdas} et les {cod defs}, et que le dictionnaire se met à grossir. On entre alors dans le domaine du codage ... _h3 1. S-expression _p L'évaluation d'une S-expression {cod °°{first rest}°°} consiste en l'application de l'opérateur {cod first} aux arguments contenus dans {cod rest}. Le terme {cod first} est un nom de fonction ou une S-expression produisant un nom de fonction, {cod rest} est une chaîne de mots (suite de caractères sans espace), de nombres (au sens où ils sont compris par l'environnement) et de S- expressions. L'évaluation se fait en commençant par les S-expressions terminales (ne contenant pas de S-expression) jusqu'à la S-expression englobante. Le résultat est une chaîne de mots. _h3 2. évaluation immédiate : dico _p Dans l'expression {cod °°{+ 1 2}°°} le symbole {cod +} appartient au dictionnaire de fonctions prédéfinies, {cod 1 et 2} sont deux symboles reconnus comme étant des nombres et évalués à eux-mêmes. L'appel de la fonction avec les deux arguments {cod 1 et 2} produira donc la valeur {cod 3}. Toute calculatrice sait faire cela ! _h3 3. évaluation contrôlée : if {div {@ style="background:#eee; opacity:0.5;"} _p ... à développer ... _p Introduire dans le processus d'évaluation les branchements, les choix, les tests, les boucles, ... _ul {cod °°{if {< 1 2} then {/ 1 2} else {/ 1 0}}°° -> -0.5} : OK !! _ul {cod °°{if {> 1 2} then {/ 1 2} else {/ 1 0}}°° -> Infinity} : oops !!! } _h3 4. évaluation différée : lambda _p L'expression {cod °°{+ a b}°°} contient deux symboles {cod a et b}, qui ne sont ni des nombres ni des S-expressions. Leur valeur n'est pas connue au moment de l'écriture de la S-expression et son évaluation doit être reportée. On la mémorise dans le dictionnaire sous la forme d'une fonction (un enclos, une fermeture, une lambda, une liaison) associant à tous les termes {cod a et b} contenus dans le corps les valeurs qui seront fournies à l'appel de la fonction, par exemple les valeurs {cod 1 et 2}. _p L'expression {cod °° {lambda {:a :b} {+ :a :b} °°} crée cette fonction en lui attribuant un nom aléatoire, du type {cod lambda_12345}, inconnu en principe de l'utilisateur, une fonction anonyme. L'expression {cod °°{lambda_12345 1 2}°°} produirait ainsi la valeur {cod 3}. Dans la mesure où le nom est inconnu, on couple en réalité la définition et l'appel : {cod °° {{lambda {:a :b} {+ :a :b} 1 2} -> 3°°}. Et la fonction anonyme retourne ensuite dans les limbes du "garbage collector". _h3 5. extension du dictionnaire : def _p On aimerait conserver plus longtemps cette fonction, ne serait-ce que pour pouvoir l'utiliser plusieurs fois sans avoir à écrire sa définition. De façon plus pratique on découplera souvent la définition et l'appel de la fonction en lui donnant un nom. L'expression {cod °°{def add {lambda {:a :b} {+ :a :b}}°°} associera le nom {cod add} à la définition de la fonction. Et ceci de façon permanente : l'expression {cod °° {add 1 2}°°} produira {cod 3}, {cod °°{add 3 4}°°} produira {cod 7}, et ainsi de suite. _p De façon générale, {cod °°{def nom expression}°°} associe un nom à une S-expression, augmentant ainsi le dictionnaire des fonctions pré-définies. Si l'expression ne contient que des termes évaluables, par exemple {cod °°{def myPI 3.1416} -> 3.1416°°} ou {cod °°{def 2PI {* 2 {PI}}°° -> 6.283185307179586} elle est évaluée et mémorisée sous forme de constante. Sinon, elle est mémorisée à l'aide de l'opérateur {cod lambda} sous la forme d'une fonction dont l'appel fournira les valeurs manquantes. _h3 6. application : n! {div {@ style="background:#eee; opacity:0.5;"} _p ... à développer ... } _h3 7. coder _p Ecrire un programme, c'est créer un ensemble de fonctions agissant sur un ensemble de données. Les langages courants (Pascal, C, Java, ...) disposent de syntaxes relativement complexes faisant une nette différence entre les données et les fonctions qui les traitent. Dans le cas présent, on notera la similitude des notations entre les opérateurs et les données. C'est le point commun des dialectes du LISP défini au départ en 1960 sur un nombre très réduit de {cod 7} formes primitives capables de générer tous les codes imaginables. _p Mon dernier évaluateur en date, [[lambdatalk|data/lambdatalk/]], tout en s'appuyant sur les principes minimalistes du LISP, bénéficie de la fondation confortable des navigateurs WEB et de leurs langages intégrés, le HTML, le CSS, et le LISP habillé en C malencontreusement appelé JavaScript. Lambdatalk dispose ainsi sans mal de {b 50} opérateurs HTML, de {b 30} fonctions mathématiques de JavaScript, et ajoute à cette base solide {b 20} nouveaux opérateurs et les {b 3} formes spéciales indispensables {cod if, lambda, def}. Associé au moteur PHP d'alphawiki, le [[code de lambdatalk|data/lambdatalk/lambdatalk.js]], réduit à très peu de lignes (une centaine pour l'évaluateur, environ quatre cent pour le dictionnaire pré-défini), se révèle suffisant pour autoriser dans des conditions confortables la composition et le codage de pages multimedia interactives et complexes. _p alain marty 21/10/2013 _p à suivre ...