Langages interprétés : tirer parti du langage compilé derrière l'interprète

Question

S'il existe des concepteurs de langage (ou des personnes simplement au courant), je suis curieux de connaître la méthodologie derrière la création de bibliothèques standard pour les langages interprétés.Plus précisément, quelle semble être la meilleure approche ?Définir des fonctions/méthodes standards dans le langage interprété, ou effectuer le traitement de ces appels dans le langage compilé dans lequel l'interpréteur est écrit ?

Ce qui m'a fait réfléchir à cela, c'est la question SO sur une fonction de type stripslashes() en Python.Ma première pensée a été "pourquoi ne pas définir le vôtre et l'appeler lorsque vous en avez besoin", mais cela a soulevé la question :est-il préférable, pour une telle fonction, de laisser le langage interprété gérer cette surcharge, ou serait-il préférable d'écrire une extension et d'exploiter le langage compilé derrière l'interpréteur ?

Answer 1

La frontière entre les langages « interprétés » et « compilés » est vraiment floue de nos jours.Par exemple, la première chose que Python fait lorsqu'il voit le code source est de le compiler dans une représentation de bytecode, essentiellement la même chose que ce que fait Java lors de la compilation de fichiers de classe.C'est ce que contiennent les fichiers *.pyc.Ensuite, le runtime python exécute le bytecode sans faire référence à la source d'origine.Traditionnellement, un langage purement interprété ferait référence au code source en permanence lors de l'exécution du programme.

Lors de la création d’un langage, c’est une bonne approche de construire une base solide sur laquelle vous pouvez implémenter les fonctions de niveau supérieur.Si vous disposez d'un système de gestion de chaînes solide et rapide, le concepteur du langage peut (et devrait) implémenter quelque chose comme stripslashes() en dehors du runtime de base.Cela est fait pour au moins plusieurs raisons :

• Le concepteur du langage peut montrer que le langage est suffisamment flexible pour gérer ce type de tâche.
• Le concepteur du langage écrit en fait du vrai code dans le langage, qui comporte des tests et montre donc que les bases sont solides.
• D'autres personnes peuvent plus facilement lire, emprunter et même modifier la fonction de niveau supérieur sans avoir à construire ou même à comprendre le noyau du langage.

Ce n’est pas parce qu’un langage comme Python compile en bytecode et s’exécute qu’il est lent.Il n'y a aucune raison pour que quelqu'un ne puisse pas écrire un compilateur Just-In-Time (JIT) pour Python, à l'instar de ce que font déjà Java et .NET, pour augmenter encore les performances.En fait, IronPython compile Python directement en bytecode .NET, qui est ensuite exécuté à l'aide du système .NET, y compris le JIT.

Pour répondre directement à votre question, la seule fois où un concepteur de langage implémenterait une fonction dans le langage derrière le runtime (par ex.C dans le cas de Python) serait de maximiser les performances de cette fonction.C'est pourquoi des modules tels que l'analyseur d'expressions régulières sont écrits en C plutôt qu'en Python natif.D'un autre côté, un module comme getopt.py est implémenté en Python pur car tout peut être fait là-bas et il n'y a aucun avantage à utiliser la bibliothèque C correspondante.

Answer 2

Il existe également une tendance croissante à réimplémenter des langages traditionnellement considérés comme « interprétés » sur une plate-forme comme la JVM ou le CLR – et à permettre ensuite un accès facile au code « natif » pour l'interopérabilité.Ainsi, depuis Jython et JRuby, vous pouvez facilement accéder au code Java, et depuis IronPython et IronRuby, vous pouvez facilement accéder au code .NET.

Dans de tels cas, la capacité de « tirer parti du langage compilé derrière l’interprète » pourrait être décrite comme le principal facteur de motivation pour la nouvelle implémentation.

Answer 3

Voir la section « Articles » sur www.lua.org.

En particulier La mise en œuvre de Lua 5.0

Lua définit toutes les fonctions standard dans le code sous-jacent (ANSI C).Je pense que c'est principalement pour des raisons de performances.Récemment, c'est-à-direles fonctions 'string.*' ont une implémentation alternative dans Lua pur, ce qui peut s'avérer vital pour les sous-projets où Lua est exécuté sur le runtime .NET ou Java (où le code C ne peut pas être utilisé).

Answer 4

Tant que vous utilisez une API portable pour la base de code compilée comme Bibliothèque de normes ANSI C ou STL en C++, tirer parti de ces fonctions vous empêcherait de réinventer la roue et fournirait probablement un interpréteur plus petit et plus rapide. Lua adopte cette approche et elle est définitivement petite et rapide par rapport à beaucoup d’autres.