Ecmascript est-il vraiment un dialecte de Lisp?

Question

Un de mes amis a attiré mon attention le message de bienvenue de 4e Symposium européen LISP:

... Implémentation et application de l'un des dialectes LISP, y compris le schéma commun, le schéma commun, Emacs Lisp, Autolisp, Islisp, Dylan, Clojure, ACL2, Ecmascript, ...

Et puis a demandé si Ecmascript est vraiment un dialecte de Lisp. Cela peut-il vraiment être considéré comme? Pourquoi?

Existe-t-il un ensemble de critères bien définis et claire pour nous aider à détecter si une langue est un dialecte de LISP? Ou est un dialecte pris dans un sens très lâche (et dans ce cas, pouvons-nous ajouter Python, Perl, Haskell, etc. à la liste des dialectes LISP?)

Answer 1

Brendan Eich voulait faire un langage semblable à un programme pour Netscape, mais la réalité est intervenue et il a fini par devoir se contenter de quelque chose qui avoir regardé vaguement comme c et java pour les gens "normaux", mais qui travaillé comme un langage fonctionnel.

Personnellement, je pense que c'est un tronçon inutile d'appeler Ecmascript "Lisp", mais à chacun le sien. L'essentiel à propos d'un vrai LISP semble être la caractéristique que la notation de structure de données et la notation de code sont les mêmes, et ce n'est pas vrai à propos d'Ecmascript (ou Ruby ou Python ou tout autre langage fonctionnel dynamique qui est ne pas Zézayer).

CALDE: Je n'ai pas de références LISP :-)

Answer 2

Ce n'est pas. Il a beaucoup de racines fonctionnelles, mais faites de nos autres langues non-LISP de nos jours, comme vous l'avez souligné.

Les LISP ont une caractéristique restante qui en fait des LISP, c'est-à-dire que le code LISP est écrit en termes de structures de données LISP (homoiciicité). C'est ce qui permet un système macro puissant LISPS, et pourquoi il a l'air si bizzare pour les non-listes. Un appel de fonction n'est qu'une liste, où le premier élément de la liste est le nom de la fonction.

Étant donné que le code LISP n'est que des données LISP, il est possible de faire des choses extrêmement puissantes avec la métaprogrammation, cela ne peut tout simplement pas être fait dans d'autres langues. De nombreux LISP, même modernes comme Clojure, sont largement mis en œuvre en eux-mêmes comme un ensemble de macros.

Answer 3

Même si je n'appellerais pas JavaScript un LISP, il est, à mon humble avis, plus proche de la manière LISP de faire les choses que la plupart des langues traditionnelles (même fonctionnelles).

D'une part, tout comme Lisp, c'est, en substance, un langage simple et impératif basé sur le calcul Lambda non typé qui convient à être motivé par un REP.

Deuxièmement, il est facile d'intégrer des données littérales (y compris du code sous forme d'expressions Lambda) en JavaScript, car un sous-ensemble est équivalent à JSON. Il s'agit d'un motif LISP commun.

Troisièmement, son modèle de valeurs et de types est très Lispy. Il est orienté objet dans un large sens du mot en ce que toutes les valeurs ont un concept d'identité, mais il n'est pas particulièrement orienté objet dans les sens les plus étroits du mot. Tout comme dans LISP, les objets sont dactylographiés et très dynamiques. Le code est généralement divisé en unités de fonctions, pas dans les classes.

En fait, il y a quelques (plus ou moins) développements récents dans le monde JavaScript qui rendent la langue à certains moments assez liscy. Prenez jQuery, par exemple. L'intégration de sélecteurs CSS en tant que sous-language est une approche assez semblable à un lippe, à mon avis. Ou considérez le protocole MetaObject d'Ecmascript Harmony: il ressemble vraiment à un port direct de Lisp commun (bien plus que les systèmes de métaobject de Python ou de Ruby!). La liste continue.

JavaScript manque de macros et d'une implémentation sensible d'un REP avec l'intégration de l'éditeur, ce qui est regrettable. Certes, les influences d'autres langues sont également très visibles (et pas nécessairement dans le mauvais sens). Pourtant, il existe une quantité importante de compatibilité culturelle entre les camps LISP et JavaScript. Une partie peut être une coïncidence (comme la récente montée de la compilation JavaScript JIT), certaines systématiques, mais elle est définitivement là.

Answer 4

Non ce n'est pas.

Pour être considéré comme un LISP, il faut être homoiconique, ce que ECMAScript n'est pas.

Answer 5

Si vous appelez Ecmascript Lisp, vous affirmez essentiellement que tout langage dynamique est LISP. Comme nous avons déjà du "langage dynamique", vous réduisez "Lisp" à un synonyme inutile pour cela au lieu de lui permettre d'avoir une signification plus spécifique.

LISP doit se référer correctement à une langue avec certains attributs.

Une langue est lisp si:

• Son code source est des données structurées par les arbres, qui ont une notation imprimée simple en tant que listes imbriquées. Chaque structure d'arbre possible a un rendu dans la notation correspondante et est susceptible d'être donné un sens en tant que construction; La notation elle-même ne doit pas être étendue pour étendre la langue.

• Les données structurées des arbres sont une structure de données principale dans la langue elle-même, qui rend les programmes susceptibles de manipuler par des programmes.

• La langue a un type de données de symbole. Les symboles ont une représentation imprimée qui est interné: Lorsque deux ou plusieurs instances de la même notation imprimée pour un symbole apparaissent dans la notation, ils désignent tous le même objet.

  • La vertu principale d'un objet symbole est qu'elle est différente de tous les autres symboles. Les symboles sont associés à diverses autres entités de diverses manières dans la sémantique des programmes LISP et servent ainsi de noms à ces entités.
  • Par exemple, le dialecte de Lisp a généralement des variables, tout comme les autres langues. Dans LISP, les variables sont indiquées par des symboles (les objets en mémoire) plutôt que par des noms textuels. Lorsque une partie d'un programme LISP définit une variable a, la syntaxe pour ça a est un objet symbole et non la chaîne de caractères "a", qui est juste le nom de ce symbole aux fins d'impression. Une référence à la variable, l'expression écrite comme a Ailleurs dans le programme, est également un objet sur. En raison de la façon dont les symboles fonctionnent, c'est le même objet; Cette similitude d'objet relie ensuite la référence à la définition. La similitude des objets peut être mise en œuvre comme égalité du pointeur au niveau de la machine. Nous savons que deux valeurs de symbole sont les mêmes car elles sont des pointeurs vers le même emplacement de mémoire dans le tas (un objet de type de symbole).
  • Exemple: le dialecte NewLisp qui a Une gestion de la mémoire non traditionnelle pour la plupart des types de données, y compris les listes imbriquées, fait une exception pour les symboles en les faisant se comporter de la manière ci-dessus. Sans cela, ce ne serait pas LISP. Devis: "Objets dans NewLisp (à l'exclusion des symboles et les contextes) sont passés par copie de valeur à d'autres fonctions définies par l'utilisateur. Par conséquent, chaque objet NewLisp ne nécessite qu'une seule référence. " met l'accent sur la mienne]. Passer des symboles également, comme par la copie de valeur, détruirait leur identité: une fonction recevant un symbole ne serait pas l'origine, et ne recevrait donc pas correctement son identité.
• Expressions composées dans un langage LISP - celles qui ne sont pas des primaires simples comme les nombres ou les chaînes - constitué d'une liste simple, dont le premier élément est un symbole indiquant l'opération. Les éléments restants, le cas échéant, sont des expressions d'arguments. Le dialecte LISP applique une sorte de stratégie d'évaluation pour réduire l'expression à une valeur et évoquer les effets secondaires qu'il peut avoir.
• Je voudrais provisoirement soutiennent que les listes étant faites de cellules binaires qui contiennent des paires de valeurs, terminées par un objet de liste vide spécial, devraient probablement être considérés comme faisant partie de la définition de LISP: l'ensemble de la possibilité de faire une nouvelle liste à partir d'une liste existante par une nouvelle liste existante par une nouvelle liste existante "Consigne" un nouvel élément à l'avant, et la récursivité facile sur les "premier" et le "repos" d'une liste, etc.

Et puis je m'arrêtais juste là. Certaines personnes croient que les systèmes LISP doivent être interactifs: fournir un environnement avec un auditeur, dans lequel tout est mutable, et peut être redéfini à tout moment, etc. Certains croient que les LISP doivent avoir des fonctions de première classe: qu'il doit y avoir un lambda opérateur et ainsi de suite. Les traditionalistes convaincants pourraient même insister sur le fait qu'il doit y avoir car et cdr Fonctions, la notation en pointillés prenant en charge les listes inappropriées, et que les listes doivent être composées de cellules, et terminées par spécifiquement le symbole nil indiquant la liste vide, et aussi un faux booléen. Insister sur car et cdr permet au schéma d'être un lisp, mais nil Être le terminateur de liste et les fausses règles

Plus nous pesons dans la définition du "dialecte Lisp", mais plus il devient politique; Les gens se fâchent que leur dialecte préféré (peut-être qu'ils ont créé eux-mêmes) sont exclus sur une certaine technicité. Insister sur car et cdr permet au schéma d'être un lisp, mais nil Être la liste Terminator et False le règle. Quoi, schémas pas un lisp?

Ainsi, sur la base de ce qui précède, Ecmascript n'est pas un dialecte de LISP. Cependant, une implémentation ECMAScript contient des fonctionnalités qui peuvent être exposées sous forme de dialecte LISP et De nombreux dialectes de ce type ont été développés. Quelqu'un qui a besoin que Ecmascript soit considéré comme un LISP pour certaines raisons émotionnelles devrait peut-être se contenter de cela: que la sémantique pour soutenir LISP est là, et a juste besoin d'une interface appropriée à cette sémantique, qui peut être développée dans ECMascript et qui peut interopérer avec le code ECMAScript.

Answer 6

Je pense que Ecmascript est un dialecte de Lisp dans le même sens que l'anglais est un dialecte du français. Il y a des points communs, mais vous aurez des problèmes avec les affectations dans un seulement armé de connaissances de l'autre :)

Je trouve intéressant que une seule des trois présentations clés mises en évidence pour le 4e Symposium européen LISP concerne directement Lisp (les deux autres étant environ x86 / jvm / python et scala).

Answer 7

Pas un «dialecte». J'ai appris Lisp dans les années 70 et je ne l'ai pas utilisé depuis, mais quand j'ai appris JavaScript récemment, je me suis retrouvé à penser que c'était semblable à LISP. Je pense que cela est dû à 2 facteurs: (1) JSON est une structure associative semblable à la liste et (2) il semble que les objets JS sont essentiellement JSON. Donc, même si vous n'écrivez pas de programmes JS dans JSON car vous écririez LISP dans les listes, vous le faites presque.

Ma réponse est donc qu'il y a suffisamment de similitudes que les programmeurs familiers avec Lisp le rappellent lorsqu'ils utilisent JavaScript. Des déclarations comme JS = Lisp dans un costume java expriment seulement ce sentiment. Je crois que c'est tout ce qu'il y a.

Answer 8

Oui c'est le cas. Citant Crockford:

"JavaScript a beaucoup en commun avec le schéma. C'est un langage dynamique. Il a un type de données flexible (tableaux) qui peut facilement simuler les expressions S. Et surtout, les fonctions sont des lambdas.

En raison de cette profonde similitude, toutes les fonctions dans [amorce de programmation récursive] «Le petit schéma» peut être écrit en javascript. "
http://www.crockford.com/javascript/little.html

En ce qui concerne l'homoiciicité, je recommanderais de rechercher ce mot avec JavaScript. Dire que ce n'est "pas homoiconique" est vrai mais pas la fin de l'histoire.

Answer 9

Le "dialecte" l'étire définitivement trop loin. Pourtant, en tant que personne qui a appris et utilisé Python, JavaScript et Scheme, JavaScript a clairement une sensation de LISP-WIP-WIER (et CoffeeScript probablement encore plus) que Python.

Quant aux raisons pour lesquelles le Symposium européen LISP voudrait dépeindre JavaScript comme un LISP, il veut évidemment se reproduire sur la popularité du JavaScript pour lequel la population du programmeur est beaucoup plus grande que le reste des dialectes LISP dans leur liste combinée combinée .