5 ms·

Why a mini language instead of a library? Python has Numpy to satisfy most array programming needs, for example.

by qznc 6y ago

BiteCode_dev 6y ago
Good point, and I'm not a big fan of DSL. I think most of the time, we should make a better API. But for regexes, it has been a success: they are rarely used, but when they are, you are glad you have them. In fact you probably need to do both: re in Python is a library. A library that implements the regex DSL. Maybe there is a way to create an API around numpy that translates a J/K/APL like DSL into numpy operations. Just like regexes, this is not something you want to use often. But I assume that, just like I don't want to describe a whole parser when I just need to match/split/extract text, people doing array processing probably don't want to describe every single steps for very common operations in some cases.
- Y_Y 6y ago
  I did exactly that a couple of years ago, turned out it wasn't hard to translate J expressions into the equivalent numpy code and then eval it in the current context. I'm afraid I've lost the code, otherwise I'd post it.
klibertp 6y ago
Numpy is a mini-language, effectively a DSL. It's just that Python offers some features which allow for embedding the DSL into the language, making it an internal DSL. In languages with less flexible/overridable syntax - for example, if indexing would be limited to a single expression only - you'd have to write all the indexing, searching, and assignment operations "long-hand", with method calls. Well, depending on the API this may still be workable, but it would be much less convenient, slower, and more error-prone. The external DSLs are a way around this. TL;DR: if the language is permissive enough, a library may well provide a DSL for whatever it's doing, it's not an "either lib or DSL" situation.
- BiteCode_dev 6y ago
  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.

Why a mini language instead of a library? Python has Numpy to satisfy most array programming needs, for example.

by qznc 6y ago

Why a mini language instead of a library? Python has Numpy to satisfy most array programming needs, for example.

Good point, and I'm not a big fan of DSL. I think most of the time, we should make a better API. But for regexes, it has been a success: they are rarely used, but when they are, you are glad you have them. In fact you probably need to do both: re in Python is a library. A library that implements the regex DSL. Maybe there is a way to create an API around numpy that translates a J/K/APL like DSL into numpy operations. Just like regexes, this is not something you want to use often. But I assume that, just like I don't want to describe a whole parser when I just need to match/split/extract text, people doing array processing probably don't want to describe every single steps for very common operations in some cases.

Y_Y 6y ago
I did exactly that a couple of years ago, turned out it wasn't hard to translate J expressions into the equivalent numpy code and then eval it in the current context. I'm afraid I've lost the code, otherwise I'd post it.

klibertp 6y ago

Numpy is a mini-language, effectively a DSL. It's just that Python offers some features which allow for embedding the DSL into the language, making it an internal DSL. In languages with less flexible/overridable syntax - for example, if indexing would be limited to a single expression only - you'd have to write all the indexing, searching, and assignment operations "long-hand", with method calls. Well, depending on the API this may still be workable, but it would be much less convenient, slower, and more error-prone. The external DSLs are a way around this. TL;DR: if the language is permissive enough, a library may well provide a DSL for whatever it's doing, it's not an "either lib or DSL" situation.

BiteCode_dev 6y ago
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.