Quand une API est-elle considérée comme une DSL intégrée?

Quelle est la différence entre une API et un langage DSL (Domain Specific Language) intégré?

Est-ce juste de la syntaxe?

Considérez une API comme OpenGL. En quoi est-ce différent d'un DSL graphique?

En d'autres termes, si une API est suffisamment complexe, peut-elle être considérée comme une DSL intégrée?

La distinction est difficile à faire et dépend de la langue utilisée. C'est aussi subjectif.

Dans clojure, vous pouvez définir des API qui ressemblent à une DSL. Par exemple, hoquet vous permet de générer du html:

(html [:span {:class "foo"} "bar"])

Cela peut être considéré comme un DSL avec une syntaxe lisp. Le fait qu'il htmlpuisse s'agir d'une macro lui donne la même puissance que si vous écriviez une bibliothèque de modèles HTML avec des expressions s (voir sxml )

En python, la même API peut ressembler à:

html(["span", {"class" : "foo"}, "bar"])

html est une fonction. Son argument sera évalué en premier, puis l'appel de fonction se produira. Le fait que la syntaxe python soit plus spécifique et la sémantique python plus stricte signifie que cette expression est plus difficile à interpréter comme une DSL indépendante du langage.

Une représentation de langage classique est une structure de données arborescente et une fonction d'évaluation appelée récursivement sur ses nœuds. Les langages LISP rendent cette structure arborescente très apparente, donc tout appel de fonction imbriquée ne peut pas être distingué d'une fonctionnalité de langage intégrée. C'est pourquoi la communauté LISP parle des DSL pour presque tout.

Je crois que la programmation consiste à fournir des abstractions utiles. Je trouve que regarder tout ce que vous construisez (une bibliothèque ou même l'interface utilisateur de votre application) comme éléments de langage pour aider les gens à résoudre un problème complexe est un moyen efficace de concevoir la plupart des choses. Dans cette perspective, j'affirme que toutes les bibliothèques sont des DSL, mais certaines d'entre elles sont mal conçues :-)

Les API et les DSL sont des concepts très différents et il n'y a que certains domaines où on pourrait dire qu'ils se chevauchent.

Tous les DSL sont des langages informatiques . Ils peuvent être interprétés, compilés, balisés, langages de requête (par exemple SQL) ou (comme JSON ou certaines utilisations de XML) langages de données qui pourraient être utilisés dans les messages transmis via une API, mais ils doivent être des langages . Le terme décrit la nature , pas le but.

Les API sont des interfaces permettant à un composant logiciel d'être utilisé par d'autres composants. Le terme décrit le but , pas la nature. Une API peut être un ensemble de méthodes d'objet, par exemple - qui n'est pas une DSL. Une API Web peut utiliser une DSL (ou, si elle est reposante, vous pouvez affirmer qu'il s'agit d' une DSL), mais une langue partagée spécifique au domaine ne fait pas partie de la définition. Un pilote logiciel pour un périphérique peut être écrit en C, l'API distribuée sous forme de bibliothèque compilée, le protocole entièrement binaire et tout langage pouvant utiliser la bibliothèque peut être utilisé pour créer un client. Rien dans cette API ne pourrait être appelé DSL (une liste de noms symboliques pour les fonctions API ne le coupe pas).

Je suis un peu confus quant à la raison pour laquelle vous ne pouvez voir que des similitudes, compte tenu des définitions.

En général, non. Une DSL est délibérément rendue non générale dans le but de rendre certaines opérations plus pratiques. Des choses comme HTML ou Logo étaient à l'origine des langues spécifiques au domaine.

En général, vous ne pouvez pas intégrer un DSL dans une autre langue, même avec l'API la plus puissante; tout ce que vous programmez contre cette API ressemblera toujours à une série d'expressions dans le langage hôte et ne sera pas aussi pratique que l'utilisation d'un langage à usage spécial.

Les exceptions sont les langages qui offrent des opportunités exceptionnelles de déformer la syntaxe via une bibliothèque (surcharge d'opérateur comme C ++, inventer de nouveaux opérateurs comme Scala, ou même prédéclarer une syntaxe de lecture complètement différente comme Perl avec des filtres source). Lorsque vous utilisez un tel langage et profitez pleinement de la flexibilité qu'ils offrent, le résultat peut ressembler plutôt à un nouveau langage spécifique (mais la sémantique sera souvent subtilement différente de ce à quoi vous vous attendriez si le langage était vraiment inventé). à partir de zéro pour servir vos fins).

Ici, de DslBoundary par Martin Fowler

D'après l'article, ma compréhension est essentiellement que les DSL et les API intégrées ne sont pas si différentes. Mais cependant, il y a une petite différence ici.

1. L'API met l'accent sur la fourniture d'une nouvelle installation.
2. DSL ne vous fournit pas seulement une nouvelle fonctionnalité, mais également une nouvelle syntaxe et une nouvelle façon de coder.

Mais si on parle de DSL externe, ce sera une autre histoire. Le DSL externe est comme un petit langage de programmation mais pour sûr, ce n'est pas un langage à usage général qui signifie qu'il ne peut pas résoudre tous les problèmes mais un problème spécifique à la place.

Je pense que chaque API est une DSL intégrée mais l'inverse n'est pas vrai: toutes les DSL intégrées ne sont pas une API. Ce n'est que lorsque le langage est utilisé comme un moyen d'intégrer des composants qu'il peut être appelé une API.

Pourquoi une API peut-elle être considérée comme une DSL intégrée? Tout d'abord, il forme un langage: il comporte des éléments primitifs (types et opérations) qui peuvent être combinés (au moyen du langage hôte) pour former des abstractions et résoudre des problèmes complexes. Par exemple, l'API OpenGL peut être utilisée pour rendre des scènes 3D en temps réel. L'API Collections peut être utilisée pour créer des algorithmes qui fonctionnent sur des ensembles d'objets, etc. Deuxièmement, elle est évidemment spécifique au domaine; par exemple, le domaine de l'API Collections gère des ensembles d'objets et le domaine de l'API OpenGL est le rendu 3D. Par conséquent, une API est un langage spécifique au domaine.

Mais chaque DSL n'est pas une API. Par exemple, certains DSL ne doivent pas être implémentés par un composant désigné. Tous les systèmes définissent certaines abstractions, et les abstractions qui traitent d'un domaine spécifique peuvent être considérées comme une DSL, mais cela n'implique pas que les implémentations de ces abstractions doivent être "permutables", en d'autres termes, elles n'ont pas à former une API . Ils le pourraient, mais ce n'est pas toujours nécessaire. Cependant, dans les cas où l'implémentation est "composante" (désolé faute d'un meilleur terme), la DSL devient en effet une API.