The need to perform a platform-independent parse + compile is a large part of my personal concept of a DSL. This is not the same thing as writing shims and graf

The need to perform a platform-independent parse + compile is a large part of my personal concept of a DSL. This is not the same thing as writing shims and grafting new methods onto objects to mutate aspects of the language you're writing in already while tying yourself to, for example, variable scoping rules that is inherited from an implementor language. In fact, I've seen some people describe what amounts to a "Fluent API" as a DSL. Fluent APIs are great and help with usability of an API considerably, but I don't think of jQuery or Scalding as DSLs, just libraries that meet all the rules of their implementation languages. Perhaps some people simply don't care and just think of a DSL as a subset of a language regardless of implementation. If I want to be a bit more specific, I think a DSL needs to be independent in syntax and semantics from any implementation environment or platform and that by leveraging the compiler of your implementation language that it limits the "language" aspect of the DSL. I believe most people are concerned about the "DS" aspect and in this respect that reduces a DSL to being just a higher-level API - an API is not necessarily Turing complete, after all, and while some APIs require some parsing to use, they are still. An embedded language like how Lua is used oftentimes is not a DSL to me because it is general purpose and is perfectly fine to implement another DSL - a DSL to me should also imply that you can't use it to implement another arbitrary DSL. This will blur as what used to be DSLs add features that make them Turing complete (lots of crazy things possible with SQL and CSS these days). I don't like to be a terminology Nazi or something, but I have no real rational explanation for why "DSL" in practice rubs me funny.