Pourquoi elisp n'a-t-il pas d'espaces de noms?


40

Q: Pourquoi elisp n'a-t-il pas d'espaces de noms et comment pourrions-nous les obtenir?

Elisp ne possède pas d'espaces de noms autres que les espaces globaux, ce qui a conduit à la convention de codage consistant à préfixer toutes les fonctions, variables et constantes globales avec un préfixe unique.

Mis à part le facteur gêne, cela me semble également être un problème récurrent vu 1) le nombre sans cesse croissant de bibliothèques et de paquets intéressants, et 2) l’existence continue de fonctions et de variables héritées qui ne respectent pas la convention de préfixe ou sont suffisamment idiosyncratiques pour qu’il n’y ait pas vraiment de bonne option de préfixe à utiliser. Cela signifie également que les tentatives périodiques de rationalisation du code ancien (comme pour le passage de clà cl-lib) représentent une charge de travail non négligeable. (Bien que je sois heureux pour le nettoyage, je verse quand même une larme à chaque fois que je tape quelque chose comme cl-find).

Je suis allé fouiller pour voir si je pouvais découvrir pourquoi elisp n'avait toujours pas d'espace de noms après quelques décennies d'utilisation, mais j'étais un peu surpris de la modeste récolte. La page wiki sur les espaces de noms est assez courte. Nic Ferrier a un traitement un peu plus long de la question et un fil assez récent sur emacs-devel également. Il existe un ancien fil de débordement de pile datant de 2010 qui traite de la possibilité d'utiliser des macros pour implémenter des espaces de noms. Un autre exemple de l'approche macro peut être trouvé ici . Il y a au moins quelques implémentations ( ici et ici , avec une description de cette dernière ici), mais ils n’ont pas vu beaucoup d’activité depuis quelques années et je n’ai rencontré aucune bibliothèque qui les utilise.

Je suppose que si l'ajout d'espaces de noms était facile, cela serait déjà fait. Alors:

  • Quels sont les obstacles techniques à l'ajout d'espaces de nommage à elisp?
  • L'ajout d'espaces de noms effacerait-il beaucoup de code existant?
  • Est-ce que cette fonctionnalité est quelque chose qui doit être organique pour améliorer (des modifications à l’interprète lui-même), ou pourrait-elle vraiment être construite sur le dessus via des macros?

6
Vous pouvez jeter un coup d'œil à ceci: github.com/Bruce-Connor/names Cela semble être une implémentation rétrocompatible (avec la méthode manuelle actuelle de séparation des noms) d'espaces de noms automatiques. (Et je suis sûr à 99% que j'ai vu une autre bibliothèque de ce type, permettant au développeur d'exporter un sous-ensemble de fonctions avec des espaces de noms, mentionné récemment sur un blog emacs, mais je ne pouvais pas le retrouver).
T. Verron

2
Je pense que vous devriez regarder le lien ci-dessus. Il s’agit d’une macro très récente (publiée le mois dernier) et très robuste. Je travaille toujours sur quelques problèmes de compatibilité avec des outils comme edebug, mais le paquet fonctionne. Répondre à votre question est un très long essai (les obstacles techniques auxquels j'ai dû faire face étaient nombreux) mais je vais essayer de le mettre dans des articles de blog au cours des prochaines semaines.
Malabarba

1
Je suppose que les espaces de noms signifient différentes choses. J'aurais dit qu'emacs avait plusieurs espaces de noms: un pour les variables, un autre pour les fonctions et les macros, un autre pour les visages et les thèmes, et…
Harald Hanche-Olsen

1
@ HaraldHanche-Olsen, vous pouvez certainement le dire. Dans ce contexte, il demande pourquoi il n'y a pas d'espaces de noms par paquet.
Malabarba

Réponses:


28

Pourquoi pas d'espaces de noms?

Parce que c'est compliqué et que personne n'a jugé suffisamment urgent de franchir le pas. Cela a déjà été discuté dans la liste des développeurs (plus d'une fois), et des promesses ont été faites pour résoudre ce problème après le passage à git.

En attendant, j’ai écrit une solution personnelle (voir ci-dessous pour une liste d’options).

Quels sont les obstacles techniques?

À la sortie de la porte, vous devez surmonter 3 obstacles importants pour que les espaces de noms aient même une chance de travailler sur un Emacs actuel:

  • Vous devez changer le mode d'internement des symboles (c'est la partie la plus facile).
  • Le compilateur d'octets doit comprendre les espaces de noms.
  • La génération de chargement automatique utilisée par package.eldoit comprendre les espaces de noms.

Corriger ces 3 éléments avec lesquels vous travaillez, peu importe la façon dont vous implémentez les espaces de noms, n’est pas trivial. Si vous ne vous consacrez qu'à la dernière version d'Emacs, c'est faisable. Si vous cherchez à écrire une sorte de paquet qui prend également en charge les versions précédentes (comme toute la famille des 24), cela devient un véritable défi.

Au-delà de cela, il existe des tonnes d'autres obstacles optionnels. Elisp est formidable en raison de toute la puissance des outils disponibles et TOUTES celles-ci doivent être corrigées pour fonctionner avec les espaces de noms. Parmi les plus importants sont:

  • edebug
  • eval-defun
  • eval-last-sexp
  • vase

Cela casserait-il beaucoup de code existant?

Pas si tu le fais bien.

Est-ce quelque chose qui doit être organique, ou pourrait-il vraiment être construit sur le dessus via des macros?

Idéalement, ce serait organique, c'est ce dont on discute habituellement quand il apparaît dans la liste des développeurs. Mais cela peut être fait assez bien tout en étant construit sur le dessus.
Voici quelques exemples, tirés de cette liste :


1
Merci - c'était une prise de vue très informative sur la question. Je suis curieux de votre dernier point concernant votre namessolution. Je me demande s'il y a des raisons de croire qu'une organique, solution intégrée est à venir dans un avenir pas trop lointain, ou si nous devrions simplement adopter le intégré sur la solution que vous avez fourni.
Dan

1
@Dan Oui, il y a. . Cela dit, il n’ya aucune raison de ne pas adopter de noms entre-temps. Il est entièrement compatible avec les conventions d'Emacs. Ainsi, tout paquet utilisant Names est libre d'arrêter d'utiliser des noms à tout moment, et l'utilisateur ne saura rien du tout.
Malabarba

Vous devriez vraiment ajouter namelessà cette liste :) C'est une idée brillante et elle résout le problème très proprement.
Clément

22

La dernière fois que nous avons discuté de cette question sur emacs-devel, la discussion s’est arrêtée lorsque des personnes comme Lars ont souligné qu’elles aiment pouvoir faire M-x grepquelque chose. Ajouter des espaces de noms à Elisp ne devrait pas être trop difficile, mais obtenir tous les outils habituels pour les gérer correctement est un autre problème.


Je pense que cela pourrait être facilement "corrigé" en créant des alias pour les fonctions communes les plus utilisées (ou toutes, peut-être)
Jesse

1
Le besoin de "grep" apparaît généralement lors du développement d'un paquet, vous devez savoir où une variable / fonction peut être utilisée dans d'autres paquetages, de sorte qu'elle puisse s'appliquer à toute variable / fonction arbitraire, plutôt qu'à des variables spécifiques importantes. Pour cette raison, l'ajout de quelques alias ne fera aucune différence. Une autre raison pour laquelle mit n’aidera pas, c’est que l’ajout d’un alias ne vous aidera pas à trouver les utilisations qui n’utilisent pas cet alias.
Stefan
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.