Pour ce qui est du lambda-calcul : euh... oui, bon, le lambda-calcul c'est un truc un peu théorique quand même :) . Si la syntaxe de Lisp colle à quelque chose c'est aux AST.
Alors euh, je suis d'accord avec tout ce que tu dis dans l'ensemble de ce post, sauf ce que j'ai cité au-dessus : j'ai appris LISP avant d'être mis en contact avec le lambda calcul, et sérieusement, oui, LISP colle au lambda calcul avant tout. Dire que ce langage colle aux AST c'est à mon avis trompeur, dans le sens où un AST peut être représenté différemment (on l'a vu avec la syntaxe d'OCaml, ou bien si tu manipules Clang/LLVM directement depuis C++), et manipulé différemment. La syntaxe fonction <liste> vient directement du lambda calcul. D'ailleurs, qu'on parle de Haskell, OCaml, F#, etc., même les opérateurs infixes sont secrètement des fonctions à qui on a ajouté un peu de sucre syntaxique.
[^] # Re: C'est bien dommage
Posté par lasher . En réponse au journal C++17 est sur les rails. Évalué à 3.
Alors euh, je suis d'accord avec tout ce que tu dis dans l'ensemble de ce post, sauf ce que j'ai cité au-dessus : j'ai appris LISP avant d'être mis en contact avec le lambda calcul, et sérieusement, oui, LISP colle au lambda calcul avant tout. Dire que ce langage colle aux AST c'est à mon avis trompeur, dans le sens où un AST peut être représenté différemment (on l'a vu avec la syntaxe d'OCaml, ou bien si tu manipules Clang/LLVM directement depuis C++), et manipulé différemment. La syntaxe
fonction <liste>vient directement du lambda calcul. D'ailleurs, qu'on parle de Haskell, OCaml, F#, etc., même les opérateurs infixes sont secrètement des fonctions à qui on a ajouté un peu de sucre syntaxique.