Lisibilité des expressions S


9

En bref et pour ceux qui ne le savaient pas, les fonctions / opérateurs / constructions Lisp sont tous uniformément appelés comme ceci:

(function arg0 arg1 ... argN)

Donc, dans un langage de type C, vous exprimeriez

if (a > b && foo(param))

est transformé en un sexp Lisp comme

(if (and (> a b) (foo param)))

. Au fur et à mesure que les choses deviennent plus réelles / compliquées, il en va de même pour leurs expressions s correspondantes.

Je suis conscient que c'est probablement une question subjective, mais - est-ce que pour de nombreux hackers Lisp, ce petit ennui devra toujours être traité?

Ou est-ce que l'on s'habitue principalement à cette (absence de) syntaxe tôt ou tard?

Dans tous les cas, l'ajout de lignes de rupture (que vous n'ajouteriez pas dans votre équivalent C, la plupart du temps) pour la lisibilité est-il une bonne idée, surtout à long terme? Toute autre suggestion serait la bienvenue.


1
Avez-vous essayé d'utiliser Lisp dans un environnement prenant en charge Lisp comme emacs? Je ne le toucherais pas autrement.
David Thornley

Non, je ne l'ai pas fait, sous quelles formes peut-il améliorer mon expérience Lisp?
vemv

écrire des fonctions courtes est également très important, même si je n'ai fait que jouer avec clojure.
Kevin

3
Dans un bon environnement Lisp, vous ignorez les parenthèses et lisez la structure par l'indentation. Comme vous l'avez remarqué, lire la structure en comptant les parenthèses est vraiment très ennuyeux.
David Thornley

Réponses:


8

Comment analysez-vous

if (a > b && foo(param)) {
  doSomething();
} else {
  doSomethingElse();
}

L'arbre d'analyse ressemble probablement à quelque chose comme

if:
  condition:
    and:
      lt:
        left: a
        right: b
      function:
        name: foo
        param: param
  true-block:
    function:
      name: doSomething
  false-block:
    function:
      name: doSomethingElse

hmm ... sérialisons cet arbre dans une liste, notation de préfixe

if(and(<(a, b), function(foo, param)), function(doSomething), function(doSomethingElse))

Ce format d'arbre d'analyse est assez facile à manipuler, mais j'ai un problème. Je déteste les séparateurs. J'aime les terminateurs. En même temps, j'aime saupoudrer dans les espaces.

if( and (<(a b) function(foo param)) function (doSomething) function ( doSomethingElse))

hmm ... l'espace blanc supplémentaire rend certaines choses plus difficiles à analyser ... Peut-être que je pourrais simplement faire une règle selon laquelle l'arbre est représenté comme (racine feuille feuille feuille).

(if (and (< a b) (function foo param)) (function doSomething) (function doSomethineElse)

Maintenant, ma sérialisation d'un arbre d'analyse est lisp (renommer la fonction à appliquer, et cela s'exécute probablement). Si je veux des programmes qui écrivent des programmes, c'est plutôt sympa de simplement manipuler les arbres d'analyse.

Ce n'est pas entièrement ainsi que les expressions s sont apparues, mais elles ont été identifiées très tôt, et c'est une fonctionnalité que les programmeurs lisp utilisent. Nos programmes sont pré-analysés dans un certain sens, et écrire des programmes pour manipuler des programmes est assez facile à cause du format. C'est pourquoi le manque de syntaxe est parfois considéré comme une force.

Mais comme l'a dit David, utilisez un éditeur prenant en charge l'expression s. Vous risquez plus de perdre la trace d'une accolade fermante dans une expression s que d'une accolade fermante en xml ( </foo>ferme uniquement <foo>, mais le paren droit ferme TOUT expression s). En raquette, l'utilisation de crochets pour certaines expressions, associée à un bon style de retrait, résout la plupart des problèmes.

La version lisp:

(if (and (< a b) (foo param))
  (doSomething)
  (doSomethingElse))

Pas mal.


Les listes sont plus polyvalentes et puissantes que les instructions exprs + sans aucun doute. Essayer Emacs (ou quoi d'autre?) Est tentant mais la dernière fois que je l'ai essayé, cela m'a fait très peur. Qu'apporte exactement la conscience sexuelle?
vemv

Truc simple: ils font rebondir une surbrillance sur des parenthèses fermées et ouvertes (ou mettent en évidence des expressions s entières différemment). Ils ont de belles règles de retrait. Emacs a d'autres choses, mais elles ne sont probablement pas aussi importantes pour la lisibilité. Il existe d'autres éditeurs prenant en charge l'expression s. Vous n'avez pas besoin d' emacs. Si emacs vous fait peur, essayez les bundles pour textmate, sublime, etc. Une fois que votre éditeur commence à aider à la lisibilité, les choses deviennent un peu plus faciles. Je fais la plupart des trucs croustillants en raquette, ce qui permet d'utiliser des crochets partout où des parens peuvent être utilisés. La possibilité de basculer améliore la lisibilité.
ccoakley

1
En aparté, utilisez des lettrages, des définitions, etc. imbriqués pour diviser ces éléments en petits morceaux. Si vous ne pouvez pas trouver un bon nom pour un morceau, traitez-le comme un avertissement concernant votre conception. Trouvez l'équilibre entre trop petit pour nommer et trop grand pour lire.
ccoakley

Oh, ce dernier conseil est ... mémorable :) Essayer Sublime pendant que j'écris ceci.
vemv

5

Ce qui est vraiment bien avec s-exp, c'est qu'après une courte période de temps, vous ne les voyez plus, c'est comme du python à vos yeux MAIS l'ordinateur a toujours l'arbre facilement.

  • L'indentation est donc automatique, il n'y a pas d'ambiguïté, vous n'avez pas besoin d'appuyer deux fois sur tab ou quelque chose comme ça quand vous voulez terminer un bloc.

  • Si vous choisissez du code aléatoire, tout est facilement indenté avec une seule commande de votre éditeur préféré

  • Vous pouvez naviguer dans votre code très facilement, basculer entre s-exp, les échanger et ainsi de suite avec un bon éditeur

De plus, comme les données que vous manipulez sont les mêmes que le code que vous écrivez, vous pouvez utiliser le même langage pour manipuler votre code, n'est-ce pas?

Eh bien, vous pouvez le faire, c'est ce que sont les macros, vous manipulez le code que vous écrivez avant qu'il ne soit évalué comme n'importe quelle liste, c'est pourquoi on dit que Lisp est un "langage de programmation programmable". Vous écrivez du code qui écrit votre code pour vous.

Voici un bel article qui décrit la nature de Lisp et pourquoi les programmeurs Lisp ont souri quand ils voient XML.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.