• [^] # Re: lisp ?

    Posté par (site web personnel) . En réponse au journal [Letlang] Écrire un compilateur en Rust. Évalué à 3.

    Dites les critiques, vous êtes sûrs que vous ne réagissez pas de manière un peu 'instinctive'?

    Lorsque l'on propose un changement de syntaxe à un langage, il faut regarder comment ça s'intègre avec le reste du langage.


    Par exemple, l'opérateur de pipeline en Elixir:

    a |> b() |> c()
    # vs
    c(b(a))

    Si je voudrais l'ajouter tel quel en C, ça donnerait :

    a |> b() |> c()

    Mais est-ce que ça a du sens en C ? En C un opérateur s'applique sur des valeurs, or b() n'est pas une valeur.

    Du coup, est-ce que a |> b est un pointeur de fonction ? Si oui, cela pointe vers quoi ? Est-ce que cela produit un nouveau symbole dans le .o ?

    Toutes ces questions me font répondre que : non, l'opérateur de pipeline n'a pas sa place dans le langage C.


    La totalité du langage Lisp repose sur le principe suivant : ( expression ), et f a b c est une expression ou f est une fonction. Ce qui veut dire qu'en Lisp, il n'y a pas d'opérateurs, + est aussi une fonction.

    Dans mon exemple, f prend 3 arguments, maintenant pour le second exemple : (g (cons a b c)). Ici g prend un seul argument, une liste, construite avec cons.

    On a (defvar a 42), (defun ...), (lambda ...) et (defmacro ...). Tout se ressemble. C'est cohérent. Du coup introduire f(a b c), ça casse la cohérence.

    Le Lisp classique a d'ailleurs '(x y) pour l'abbréviation de (quote x y)..

    Après m'être documenté, 'x est l'abbréviation de (quote x). Et donc '(x y) devrait être (quote (x y)). Il semble que les différents Lisp (Scheme et compagnie) gèrent ça différemment.

    cf: https://stackoverflow.com/a/20643658/1020897

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg