Comment la flexibilité affecte-t-elle la syntaxe d'une langue?

Perl est le langage le plus flexible que je connaisse. C'est un coup d'oeil à Moose , un système d'objets postmoderne pour Perl 5. Sa syntaxe est très différente de celle de Perl mais c'est toujours très Perl-ish.

OMI, le plus gros problème de flexibilité est la préséance dans la notation infixe. Mais aucun que je connaisse n'autorise un type de données à avoir sa propre syntaxe d'infixe. Par exemple, prenez des ensembles. Ce serait bien d'utiliser ⊂ et ⊇ dans leur syntaxe. Mais non seulement un compilateur devrait reconnaître ces symboles, mais il devrait être informé de leur ordre de priorité.

Common Lisp permet de changer la façon dont il est analysé - voir les macros du lecteur. Racket permet de modifier son analyseur, voir les langages de raquette.

Et bien sûr, vous pouvez avoir une analyse flexible et extensible dynamiquement avec des macros puissantes si vous utilisez les bonnes techniques d'analyse (par exemple, PEG). Jetez un œil à un exemple ici - principalement une syntaxe C, mais extensible avec à la fois une syntaxe et des macros sémantiques.

En ce qui concerne la préséance, PEG va très bien avec Pratt.

Pour répondre à votre question mise à jour, il y a de toute façon étonnamment peu de recherches sur la lisibilité des langages de programmation. Vous voudrez peut-être jeter un coup d'œil à ce que le groupe du Dr Blackwell était en place à , mais c'est encore loin d'être concluant.

Je ne peux donc partager que mes anecdotes à la main - les langages de syntaxe flexibles facilitent la construction eDSL et, à mon avis, les eDSL sont le seul moyen d'éliminer la complexité inutile du code, pour rendre le code réellement maintenable à long terme. Je pense que les langues non flexibles sont l’une des plus grosses erreurs commises par ce secteur et qu’elles doivent être corrigées à tout prix, dès que possible.

La flexibilité vous permet de manipuler la syntaxe du langage. Par exemple, les macros Lisp peuvent vous permettre d'écrire des programmes qui écrivent des programmes et manipulent votre syntaxe au moment de la compilation en expressions Lisp valides. Par exemple la macro de boucle:

 ("hello world" nil format)

Et nous pouvons voir comment le code a été traduit avec macroexpand-1:

(defmacro backwards (expr)
   (reverse expr))
BACKWARDS
CL-USER> (backwards ("hello world" nil format))
"hello world"
CL-USER> 

On peut alors voir comment un appel à cette macro est traduit:

  (LET ((X 1))
(DECLARE (TYPE (AND REAL NUMBER) X))
(TAGBODY
 SB-LOOP::NEXT-LOOP
  (WHEN (> X '5) (GO SB-LOOP::END-LOOP))
  (FORMAT T "~a~%" X)
  (SB-LOOP::LOOP-DESETQ X (1+ X))
  (GO SB-LOOP::NEXT-LOOP)
 SB-LOOP::END-LOOP)))

La flexibilité de la langue vous permet simplement de créer votre propre langue intégrée dans une langue et de réduire la longueur de votre programme en termes de caractères utilisés . Donc, en théorie, cela peut rendre un langage très illisible puisque nous pouvons manipuler la syntaxe. Par exemple, nous pouvons créer un code invalide qui est traduit en code valide:

(pprint(macroexpand-1 '(loop for x from 1 to 5
                 do (format t "~a~%" x))))

Il est clair que le code ci-dessus peut devenir complexe puisque:

(loop for x from 1 to 5
      do(format t "~A~%" x))

1
2
3
4
5
NIL

n'est pas une expression Lisp valide.

Merci à la réponse de SK-logic de m'avoir indiqué la direction d'Alan Blackwell. Je lui ai envoyé un e-mail pour lui demander sa position sur la question et il a répondu avec une explication absolument merveilleuse. La voici:

Donc, la personne qui a répondu à votre question StackOverflow en disant cette syntaxe flexible pourrait être utile pour les DSL, est certainement correcte. Il était en fait assez courant d'utiliser le préprocesseur C pour créer une syntaxe alternative (qui serait transformée en syntaxe régulière dans une phase de compilation initiale). Beaucoup des premiers esolangs ont été construits manière.

En pratique, je pense qu'il faudrait dire que beaucoup de DSL sont mis en œuvre en tant que bibliothèques dans les langages de programmation classiques, et que la conception de la bibliothèque est bien plus importante que la syntaxe. Là peut être plus utile pour avoir de la variété dans les langages visuels, mais compilateurs polyvalents personnalisables pour une syntaxe graphique arbitraire est vraiment difficile - bien pire que de changer les fonctionnalités de la syntaxe du texte.

Votre conception pourrait permettre certaines choses intéressantes, alors Je ne découragerais pas l’expérimentation. Cependant, je pense qu'il y a une raison pour laquelle la syntaxe personnalisable n'est pas si courante. Ceci est lié au célèbre éditeur du programmeur EMACS. Dans EMACS, tout est personnalisable - tout les raccourcis clavier et toutes les fonctions de l'éditeur. C'est amusant de jouer avec, et à l'époque, nous étions nombreux à créer notre propre version personnalisée qui seulement nous savions comment opérer. Mais il s'est avéré que c'était un vrai tracas que le rédacteur de chacun a travaillé complètement différemment. Vous pourriez ne vous penchez jamais pour faire des suggestions sur la session d’une autre personne, et les équipes devaient toujours savoir qui était connecté pour savoir si l'éditeur fonctionnerait. Il s'est donc avéré qu'au fil des ans, nous a commencé à utiliser la distribution par défaut et les raccourcis clavier, ce qui a rendu les choses sont plus faciles pour tout le monde.

À ce stade, c'est à peu près une explication suffisante que je cherchais. Si quelqu'un a l'impression d'avoir une meilleure explication ou quelque chose à ajouter, n'hésitez pas à me contacter.