4 ms·

Unfortunately, they don't mention the most easy way of defining a DSL: by doing it in the host language itself. Not all programming languages are capable of all

Unfortunately, they don't mention the most easy way of defining a DSL: by doing it in the host language itself. Not all programming languages are capable of allowing that, but some do, and in that case it is by far the most easy and safe solution. It is still much much easier than combining existing language like adding OCL into another language, as suggest in the paper; and you get compiler/IDE support, tooling support and everything else from the "host language" out of the box.

MrJohz 3y ago
I'd go a step further, and suggest that most languages are able to embed some level of DSL, although you might not be able to reach quite the expressiveness that you had in mind. Generally a combination of block closures and being able to chain methods together is usually enough to create something reasonably expressive, although even then there are alternatives - I've seen DSLs in Python that use the class syntax and metaclasses to define quite complex this. You won't be generating your own syntax or anything, but you can often get pretty far.
victorNicollet 3y ago
This is definitely the best idea for "drop down" DSLs (by drop down, I mean that you are working in a general-purpose language and then, for one specific situation, you drop down into the DSL because it is more productive). I think the article is more oriented towards standalone DSLs (where the entry point is the DSL itself), as those get actual maintenance benefits from not being able to invoke arbitrary code in the host language.
- valenterry 3y ago
  Yes. My point is just that I would judge that in 90% of the cases, "drop down" DSLs are the best solution for the problem at hand. So when talking about DSLs they should be mentioned, or at least the term DSL should be defined accordingly, which did not happen in the paper.
chriswarbo 3y ago
Alan Kay describes OOP as defining interactions with/between values via mini languages/algebras. In a language like Smalltalk (using whitespace and mixfix syntax) this very much feels like crafting a lightweight/hosted DSL. Other languages require a lot more squinting, to get past the host language's punctuation and ceremony. For example, compare something like the following: canvas drawA: circle at: topLeft in: red. canvas.draw(circle, at=topLeft, in=red);
- ljm 3y ago
  I think the discoverability of Smalltalk code within the IDE lends nicely to that too. It'd be quite obscure to many these days, but there's something to be said about the ability to browse and experiment with a catalogue of classes like a graphical REPL on steroids.
Too 3y ago
Doesn’t necessarily have to be the host language. Just any other existing language. If it’s static and declarative, just use yaml. (Yes it sucks, but you get it point) If it’s imperative, just use the host language. Then you have some hybrid solutions. HCL allowing rich expression in an otherwise very declarative language. A big list of constant dataclasses in python is another quick way to define complex data structures without having to reinvent anything. This even gives you type safety for free. Heck, MongoDB managed to build big business on a database whose only query language is super verbose json. This isn’t just negative, because by leveraging existing language, a lot of tooling around is ready to plug in on day one.
- valenterry 3y ago
  Actually, I disagree. The _by far_ easiest way is to use the host language itself. Using _any_ other language, e.g. yaml, forces you to do a lot of things that you get for free when using the host language, including syntax, type-checking/linting, build-system if you need one and especially all the tooling that comes with it for free (e.g. autocomplete in IDEs). In fact, there is almost no benefit at all of using yaml _for DSLs_. (And yes, there is widely-available syntaxhighlighting for yaml and others, but that doesn't over anything specific for the DSL, or otherwise you will have to customize it)
  - Too 3y ago
    Host language is rarely ever declarative. Declarative languages are often necessary because they don’t leave any escape hatches that tempt you into writing incorrect code. Build system dependency graphs one common example. It’s also needed to pass data between different systems without recompiling and to constrain the usage boundaries, especially around security. Imagine how absurd it would be if mongodb queries were written in the host language C++ instead of json. For in-house stuff agree. There is no point to make excessive config layers if only developers will touch it anyway.
    - valenterry 3y ago
      > For in-house stuff agree. There is no point to make excessive config layers if only developers will touch it anyway. Yeah, I'm specifically talking about in-house DSLs or those that are only used by/from specific users. That doesn't have to be developers, but they should be using the host language as well - and in that case, an imperative host language can still make it able to use a declarative DSL. (in the most basic way for instance: generate a datastructure that essentially describes a json/yaml or whatever) For non-inhouse DSL, I agree that it is usually worthwhile to make them standalone.
librasteve 3y ago
Raku has a built in Grammar capability that integrates well with regex / tokens / rules in an composable OO context. As mentioned you get all the IDE support (IntelliJ based) including a grammar inspector tool.

MrJohz 3y ago

I'd go a step further, and suggest that most languages are able to embed some level of DSL, although you might not be able to reach quite the expressiveness that you had in mind. Generally a combination of block closures and being able to chain methods together is usually enough to create something reasonably expressive, although even then there are alternatives - I've seen DSLs in Python that use the class syntax and metaclasses to define quite complex this. You won't be generating your own syntax or anything, but you can often get pretty far.

victorNicollet 3y ago

This is definitely the best idea for "drop down" DSLs (by drop down, I mean that you are working in a general-purpose language and then, for one specific situation, you drop down into the DSL because it is more productive). I think the article is more oriented towards standalone DSLs (where the entry point is the DSL itself), as those get actual maintenance benefits from not being able to invoke arbitrary code in the host language.

valenterry 3y ago
Yes. My point is just that I would judge that in 90% of the cases, "drop down" DSLs are the best solution for the problem at hand. So when talking about DSLs they should be mentioned, or at least the term DSL should be defined accordingly, which did not happen in the paper.

chriswarbo 3y ago

Alan Kay describes OOP as defining interactions with/between values via mini languages/algebras. In a language like Smalltalk (using whitespace and mixfix syntax) this very much feels like crafting a lightweight/hosted DSL. Other languages require a lot more squinting, to get past the host language's punctuation and ceremony. For example, compare something like the following: canvas drawA: circle at: topLeft in: red. canvas.draw(circle, at=topLeft, in=red);

ljm 3y ago
I think the discoverability of Smalltalk code within the IDE lends nicely to that too. It'd be quite obscure to many these days, but there's something to be said about the ability to browse and experiment with a catalogue of classes like a graphical REPL on steroids.

Too 3y ago

Doesn’t necessarily have to be the host language. Just any other existing language. If it’s static and declarative, just use yaml. (Yes it sucks, but you get it point) If it’s imperative, just use the host language. Then you have some hybrid solutions. HCL allowing rich expression in an otherwise very declarative language. A big list of constant dataclasses in python is another quick way to define complex data structures without having to reinvent anything. This even gives you type safety for free. Heck, MongoDB managed to build big business on a database whose only query language is super verbose json. This isn’t just negative, because by leveraging existing language, a lot of tooling around is ready to plug in on day one.

valenterry 3y ago
Actually, I disagree. The _by far_ easiest way is to use the host language itself. Using _any_ other language, e.g. yaml, forces you to do a lot of things that you get for free when using the host language, including syntax, type-checking/linting, build-system if you need one and especially all the tooling that comes with it for free (e.g. autocomplete in IDEs). In fact, there is almost no benefit at all of using yaml _for DSLs_. (And yes, there is widely-available syntaxhighlighting for yaml and others, but that doesn't over anything specific for the DSL, or otherwise you will have to customize it)
- Too 3y ago
  Host language is rarely ever declarative. Declarative languages are often necessary because they don’t leave any escape hatches that tempt you into writing incorrect code. Build system dependency graphs one common example. It’s also needed to pass data between different systems without recompiling and to constrain the usage boundaries, especially around security. Imagine how absurd it would be if mongodb queries were written in the host language C++ instead of json. For in-house stuff agree. There is no point to make excessive config layers if only developers will touch it anyway.
  - valenterry 3y ago
    > For in-house stuff agree. There is no point to make excessive config layers if only developers will touch it anyway. Yeah, I'm specifically talking about in-house DSLs or those that are only used by/from specific users. That doesn't have to be developers, but they should be using the host language as well - and in that case, an imperative host language can still make it able to use a declarative DSL. (in the most basic way for instance: generate a datastructure that essentially describes a json/yaml or whatever) For non-inhouse DSL, I agree that it is usually worthwhile to make them standalone.

librasteve 3y ago

Raku has a built in Grammar capability that integrates well with regex / tokens / rules in an composable OO context. As mentioned you get all the IDE support (IntelliJ based) including a grammar inspector tool.