• [^] # Re: C'est bien dommage

    Posté par . En réponse au journal C++17 est sur les rails. Évalué à 3.

    Oui pour la reproduction de la structure en arbre, mais on pourrait dire exactement la même chose de pas mal de langages déclaratifs ou fonctionnels (y compris OCaml, c'est juste que le langage autorise une notation infixe qui est plus « naturelle » dans certains cas).

    Pour le rapprochement avec le lambda-calcul, il me semble que le « parenthésage » n'est qu'un effet de bord du besoin de de séparer les expressions d'une manière ou d'une autre : en 1958, utiliser un opérateur de composition comme on le ferait en maths ou en lambda-calcul n'était pas raisonnable pour des raisons de limitation de caractères de toute manière. :-) Mais honnêtement, entre 

    (f 
 (g 
 (h '(...)
)))

    et

    f∘g∘h (...)

    ... tient juste à l'utilisation de parenthèses ouvrantes et fermantes pour groupe les termes, mais — surprise ! — il faut faire pareil en lambda-calcul pour indiquer la priorité des opérations sur certains opérandes. :-) En LISP, toute parenthèse ouvrante implique l'utilisation d'une fonction (ou d'une macro) sur une liste (potentiellement vide) d'arguments. En lambda-calcul, toute expression commence par l'utilisation d'une fonction...

    De même en OCaml si une fonction s'applique au résultat de l'appel de deux fonctions qui opèrent sur des paramètres séparés, il faudra utiliser les parenthèses pour les grouper pour casser les ambiguïtés.

    let sqr x = x * x
let sum2 a b = 2*a + 2*b
let f a b = (sqr a) + (sum2 a b)
(* On pourrait écrire la même chose ainsi : *)
let sqr x = (*) x x 
let sum2 a b = + ((*) 2 a) ((*) 2 b)
let f a b = (+) (sqr a) (sum2 a b)

    Et soit dit en passant, écrire f∘g∘h a b reproduit relativement explicitement un « AST »...