Z:gnu-www-ja-rms-lisp--184634-At that point, people began to/fr

À ce moment-là, les gens ont commencé à se demander comment ils pouvaient obtenir quelque chose de ce genre sur une plateforme sur laquelle ils ne disposaient pas de l'implémentation des services complets de Lisp. Le MacLisp de Multics avait un compilateur aussi bien qu'un interpréteur (c'était un système Lisp complet) mais les gens voulaient implémenter quelque chose comme ça sur d'autres systèmes où il n'y avait pas encore de compilateur Lisp. Car sans compilateur Lisp on ne pouvait écrire l'éditeur entier en Lisp : cela aurait été trop lent, en particulier l'affichage, s'il avait fallu faire tourner du Lisp interprété. Donc nous avons développé une technique hybride. L'idée était d'écrire ensemble l'interpréteur Lisp et les parties bas niveau de l'éditeur, de telle sorte que certaines parties de l'éditeur soient des méthodes intégrées Lisp. C'était toutes les parties dont nous pensions qu'elles avaient besoin d'être optimisées. C'est une technique que nous avions déjà consciemment pratiqué dans l'Emacs original, puisqu'il y avait certaines fonctionnalités de relativement haut niveau que nous réimplémentions en langage machine, les transformant en primitives TECO. Par exemple, il y avait une primitive TECO pour remplir un paragraphe (en fait, pour faire le gros du travail de remplir un paragraphe, parce que certaines des parties du travail les moins exigeantes en temps étaient faites à un niveau supérieur par un programme TECO). On aurait pu faire tout le travail en écrivant un programme TECO, mais c'était trop lent, donc nous l'avons optimisé en en mettant une partie en langage machine. C'est cette idée que nous avons utilisée dans la technique hybride : la plus grosse partie de l'éditeur serait écrite en Lisp, mais certaines parties ayant besoin d'une vitesse d'exécution particulièrement rapide seraient écrites à un niveau inférieur.