+
1
|
skin
|
login
|
edit
αwiki++
::
syntax_others_yaw
user:anonymous
{div {@ style="display:none;"} {def r {lambda {:char} {span {@ style="color:red;"}:char}}} } _h1 {r Y}et {r A}nother {r W}iki ! _p Why alphawiki (in ze lambdaway) ? _p In my humble opinion, CMS (Content Management systems, blogs, wikis,...) are not only often unnecessarily complex, but they generally come with obfuscated, limited and rather incoherent syntaxes. The alphawiki project comes from this observation : the fundamental tree structure of digital datas (in an HTML page, a JSON format, a Lisp code, everything !) opens a wide door to light, smart and effective coding style, easy to use by "lambda" people ... provided these people have a minimum level of knowledge. For instance : _ul 1) {b everyone has been (de)formed} to understand that the value of such an expression {b « 1+2*3+4 »} is {b « 1+(2*3)+4 = {u 11} »} and not {b « (1+2)*3+4 = {u 13} »} or {b « 1+2*(3+4) = {u 15} »}. Actually, a lot of people are forever disgusted from maths because it is not evident to know and understand the priority rules to be applied to this kind of expressions. Even in the world of coding, building a syntactic analyzer handling such expressions is far from easy. _ul 2) {b nobody has been formed} to play with such an expression « (+ 1 (* 2 3) 4) » whose value is 11. It's a pity, because the syntactic analyze of such an "s-expression" (a flat representation of a tree) is easy to build. We do that in real-time with sentences which have a tree structure ! Should you have a look in the alphawiki [[parser|?view=syntax_others_parser]], you will be convinced by the simplicity of the engine handling the mathematic and textual s-expressions. In fact, it has (almost) nothing to do. A tree is transformed into another tree. It's nothing but a "skin" change. _ul 3) there remains one main condition : {b the user must be formed} to play with s-expressions like « (+ 1 (* 2 3) 4) » and not with "horrors" like « 1+2*3+4 ». _p And this does clearly exceed the field of mathematics, every languages are concerned ! People are natively accustomed to treat in realtime tree-structured sentences. For instance (see [[source|http://www.lattice.cnrs.fr/sites/itellier/poly_info_ling/]]) : {pre The structure of such a simple sentence : « the bird poses its legs on a branch » can be written like this : (S (GN the bird) (GV poses (GN its legs)) (GP on (GN a branch))) which is a "flat" representation of this tree structure : S / \ / \ / \ / \ / \ / \ / \ / GV / / \ / / \ / / \ GN / \ / \ / \ / \ / \ / \ / \ the bird GV GP / \ / \ / \ / \ / \ / \ poses GN on GN / \ / \ its legs a branch } _p Almost every people is able to do with such a structure to get its meaning. Maybe from the leaves upto the root, like this : {pre 1) memorize "its legs" and "a branch" 2) memorize "poses its legs" and "on a branch" 3) memorize "the bird poses its legs on a branch" } _p or from the left to the right, like this : {pre 1) memorize "the bird" 2) memorize "the bird poses" 3) memorize "the bird poses its legs" 4) memorize "the bird poses its legs on" 5) memorize "the bird poses its legs on a branch" } _p Wo knows ? Have a look to this page [[order|http://www.ecenglish.com/learnenglish/lessons/can-you-read]] or this one [[ordre|../?view=ordredeslettres]], and you should be convinced that it's not so easy to answer such a question. {u The main question is} : why aren't we natively accustomed to treat in realtime much more simple tree-structures like this math expression giving the hypotenuse of a right triangle : {pre (square_root (+ (* 3 3) (* 4 4))) which is a flat representation of this simple tree structure : square_root | + / \ / \ * * / \ / \ 3 3 4 4 } _p The language of mathematics has been corrupted by a complex stacking of horrible notations (prefix, infix, postfix, root_symbol, integral, differential, vectors, matrices, tensors, and so on ... ) created all along the history by (too) clever people (Descartes, Leibnitz, Gauss, Riemann, Lie, ..., Bourbaki). Obviously, these notations are incompatible with a unique structure, as sentences have in natural language. It could be the reason why so numerous people can't understand and hate maths (and coding), while at the same time they are so clever to share complex informations in their native languages. _p People are "{b tree natives}", so let them use {b tree notations} ! So do computers ... _p But this is {r Y}et {r A}nother {r S}tory ! {center {show {@ src="data/sciences_blackboard.jpg" height="350" width="700" title="The STEM Crisis Is a Myth. The STEM are a Babel Tower (Photo: Justin Lewis/Getty Images)"}}} _h4 links _ul [[learn-to-code-code-to-learn|https://www.edsurge.com/n/2013-05-08-learn-to-code-code-to-learn]] _ul ... _h4 some mail exchanges on this topic _p [[Jean-Paul Roy|http://deptinfo.unice.fr/~roy/]] is professor at "Faculté des Sciences de Nice Sophia-Antipolis" _h6 post Alain Marty (5 janv. 2014 à 12:37) to Jean-Paul Roy _p Je compare des expressions algébriques écrites sous la notation classique et sous la notation s-expression (préfixée+parenthèses). Exemples : {pre une égalité exprimée sous la notation classique : (a+b)(a-b) = a{sup 2} - b{sup 2} et en notation s-expression : (* (+ a b) (- a b)) = (- (* a a) (* b b)) } {pre une égalité exprimée sous la notation classique : (a+b){sup 2} = a{sup 2} + 2ab + b{sup 2} et en notation s-expression : (* (+ a b) (+ b a)) = (+ (* a a) (* a b) (* b a) (* b b)) } _p La notation classique est lisible pour celui qui connait les règles de priorité, qui sait que {b 2ab} est une notation convenue pour {b 2*a*b} et que {b a{sup 2}} est une notation convenue pour {b a*a}. La notation s-expression est {i a priori} peu lisible, mais ne suppose aucune connaissance des conventions précédentes et expose de façon logique la {b transformation} entre les côtés gauche et droit des égalités. Cette notation fait découvrir la {b réalité} de ces égalités, invisible sous la forme classique. _p J'essaie d'imaginer un monde où la notation s-expression serait jugée plus puissante sur le plan "pédagogique". Le matheux classique est habitué à la notation standard, mais il est notable que cette notation rebute les non matheux (et notamment les littéraires). Bien sûr, à ce jour, la notation "s-expression" rebute les deux, mais est-ce à considérer comme définitif ? Quand on sait que les "littéraires" sont capables de traiter "à la volée" des structures arborescentes aussi complexes qu'une phrase de Proust ! _p Je sais, bien sûr, que ce genre de réflexion frise la provocation, mais bon, maintenant que j'ai découvert les parenthèses, je les vois partout !!! _p Qu'en pensez-vous ? _p AM _h6 post Jean-Paul Roy (5 janvier 2014 15:10:35) to Alain Marty _p Personnellement je distingue la notation « de surface » (a{sup 2}-b{sup 2}) que voit l’utilisateur et la « représentation interne » utilisée par les algorithmes, préfixée. La conversion entre les deux est réalisée par un analyseur syntaxique (style Lex-Yacc proposé par tous les langages, Scheme compris, ([[voir mon livre chap 15|http://deptinfo.unice.fr/~roy/]]). Transformer la notation « plate » en notation préfixée revient à trouver la grammaire de l’objet, donc à le transformer en arbre syntaxique : {pre « Le chat mange la petite souris » > (phrase (gr-nom (art « le ») (nom « chat »)) (gr-verb (verb « mange ») (gr-nom (art « la ») (adj « petite ») (nom « souris »)))) } _p ce que font en effet constamment les littéraires (et quasiment tout le monde dans à peu près tous les domaines !). La possession de cet arbre permet facilement de procéder à des transformations algorithmiques. _p Le langage LOGO pour enfants supprime les parenthèses de Lisp lorsque les opérateurs ont une arité fixe (exemple {b + * x x * y y}) n’a qu’un seul décodage possible. Je pense qu’au final il faut distinguer une notation pour l’utilisateur (dans son champ de compétence) et une notation pour le programmeur. Si les deux coïncident, je ne me séparerai pour rien au monde de la notation préfixée parenthésée, non ambigüe :-) _p Cordialement. _p -jpr _h6 post Jean-Paul Roy (6 janvier 2014 18:26:10) to Alain Marty _p Avez-vous lu « [[L’Enchâssement|http://findepartie.hautetfort.com/archive/2008/01/13/l-enchassement-de-ian-watson-1-sf-et-langage.html]] » de Ian Watson, un roman de SF (que j’ai lu il y a… 40 ans !) qui parlait si j’ai bonne mémoire de pensée préfixée en Amérique du Sud. A l’époque ça m’avait paru bizarre mais il est resté caché dans un neurone :-) _p -jpr _h6 post Jean-Paul Roy (6 janvier 2014 18:31:29) to Alain Marty _p La [[page suivante|http://findepartie.hautetfort.com/archive/2008/01/16/l-enchassement-de-ian-watson-2-les-experiences-de-chris-sole.html]] du site Web envoyé dans le mail précédent précise les liens entre la pensée « enchâssée » et la récursivité. Il faudra que je relise ce livre… quand j’aurai vidé la pile des autres :-) _p -jpr _h6 ...