3 ms·

To me, you get a DSL either by having a different parser, or by using a macro system. If you just use the flexibility of your language syntax, you just create

To me, you get a DSL either by having a different parser, or by using a macro system. If you just use the flexibility of your language syntax, you just create an API, not a DSL. The L in DSL stands for language, which numpy is, IMO, not.

klibertp 6y ago
Well then, what is the difference between a DSL made using a macro system, and one made with dynamic language features, reflection, operator overloading, and similar? Both approaches embed a sub-language into its parent language: both are DSLs, of the internal kind. A quick google for "internal DSL" returns, for example, this article from Martin Fowler: https://www.martinfowler.com/bliki/InternalDslStyle.html https://www.martinfowler.com/bliki/InternalDslStyle.html which seems to support my take on this. > The L in DSL stands for language I think you use a too narrow definition of a language, then. Any (sub)set of semantics can be called a language, with or without syntax. DSLs encode a set of semantic rules which are best suited for expressing solutions to problems in a given domain. Once you have semantics worked out, you have to think about the environment where the language will be used. Sometimes it's useful to have the DSL code separate, in which case you end up with an external DSL, like HTML or YAML. On the other hand, sometimes you need tighter integration with some environment, in which case you end up with an internal DSL, like JSX, Datalog, Kanren, Rake, Gradle, Gulp, various URL dispatchers, BDD testing frameworks, and yes, Numpy. The syntax of a DSL ("a different parser" vs. not) is secondary at best, and the implementation strategy (macros vs. runtime code generation vs. reflection and syntax overloading) is simply irrelevant to something being a DSL or not. Take a look at PyParsing or LPEG (for Lua) or scala.util.parsing or Parsec (for Haskell). These are all embedded DSLs meant for creating parsers. You work with them in exactly the same way you'd use YACC: you describe the grammar and get a parser for that grammar. That grammar description is done with a language, in all cases. That language - implemented either externally, or internally with host language features - is a DSL.

klibertp 6y ago

Well then, what is the difference between a DSL made using a macro system, and one made with dynamic language features, reflection, operator overloading, and similar? Both approaches embed a sub-language into its parent language: both are DSLs, of the internal kind. A quick google for "internal DSL" returns, for example, this article from Martin Fowler: https://www.martinfowler.com/bliki/InternalDslStyle.html https://www.martinfowler.com/bliki/InternalDslStyle.html which seems to support my take on this. > The L in DSL stands for language I think you use a too narrow definition of a language, then. Any (sub)set of semantics can be called a language, with or without syntax. DSLs encode a set of semantic rules which are best suited for expressing solutions to problems in a given domain. Once you have semantics worked out, you have to think about the environment where the language will be used. Sometimes it's useful to have the DSL code separate, in which case you end up with an external DSL, like HTML or YAML. On the other hand, sometimes you need tighter integration with some environment, in which case you end up with an internal DSL, like JSX, Datalog, Kanren, Rake, Gradle, Gulp, various URL dispatchers, BDD testing frameworks, and yes, Numpy. The syntax of a DSL ("a different parser" vs. not) is secondary at best, and the implementation strategy (macros vs. runtime code generation vs. reflection and syntax overloading) is simply irrelevant to something being a DSL or not. Take a look at PyParsing or LPEG (for Lua) or scala.util.parsing or Parsec (for Haskell). These are all embedded DSLs meant for creating parsers. You work with them in exactly the same way you'd use YACC: you describe the grammar and get a parser for that grammar. That grammar description is done with a language, in all cases. That language - implemented either externally, or internally with host language features - is a DSL.