Couldn't a DSL be as simple as an API and therefore not need a parser? Or am I misunderstanding what a domain specific language really is? I thought it referred to any organized set of rules for solving a particular domain problem. An API would seem to fit that definition, right?
+1
A:
You would still have only the semantics of the host-language.
E.g.: functional programming in an imperative language does not work. So you have a functional DSL added to this imperative language ...
Leonidas
2009-02-01 23:02:03
Ah. So a DSL is intended to overcome the semantic limitations of a particular language by extending it? And that's where the parser is needed - the parser 'interprets' your custom semantic extensions - is that correct?
2009-02-01 23:14:54
That is my interpretation of DSL, though I only have experience with extern DSL. Say, SQL ;)
Leonidas
2009-02-02 00:12:17
+4
A:
You're confusing the concept with the implementation. A domain-specific language is any representation of an idea that is considered "close" to the problem domain, rather than being a general language for the description of solving problems in general.
Yes, a DSL might be implemented as an API, which provided functions that referred to particular concepts in the problem domain, but a DSL is equally valid when represented as a text file.
The Pragmatic Programmer: From Journeyman to Master contains a good description of DSLs and the circumstances in which they're useful, with examples. Highly recommended.
womble
2009-02-01 23:15:20
+3
A:
You can embed a DSL within a more general programming language. This is often a good solution. (You could say that this DSL takes the form of a particular API.)
You can also create a separate language, with its own interpreter, to represent the concepts of your domain. This tends to be a larger undertaking, and is often not necessary.
Justice
2009-02-01 23:17:17
The fundamental flaw with APIs as "DSLs" is that in a langauge, there are legal orders of syntax and implied semantics. When you use an API, you can write any sequence of API calls that compile, but arbitrary seqeuences aren't legal. The value in a *langauge* is that is defines what sequences are legal, and a good "parser" (e.g., one that parses and checks semantics) will reject nonsensical sequences without you having to run it.
Ira Baxter
2010-02-08 22:07:35
I agree. There are certainly numerous reasons to write an external DSL. One easy example is: if the DSL is intended for untrusted users write programs, then you do not want them writing in any old programming language (such as the language that your DSL might be embedded in). There are pros and cons to both approaches. My view is: it is orders of magnitude easier to write an embedded DSL in a good host language. Therefore, to the extent that it is reasonable to do so, do so. But if an embedded DSL is insufficient, then you need to write an external DSL that is sufficient.
Justice
2010-02-09 03:41:03
A:
Yes, absolutely - a mere API will do nicely as a DSL if the host language has sufficient flexiblity to support it.
Ruby is a very good language for such, particularly given the optional parens and other flexibilities.
Rails is often referred to as a DSL for writing database-driven web applications.
Rake is a build system with a DSL for writing (smarter) makefiles.
My own OOFILE is a framework you can regard as a DSL for writing database applications in C++ - it was inspired by dBase and makes very heavy use of C++ operator overloading, local objects and stream idioms.
Forth is classically a language which blurs the line between DSL and API as a Forth program consists of little more than a series of space-separated words. Probably the most impressive example of a Forth DSL is Abundance - Abundance is a Forth-based business programming language, written in BBL Forth. BBL is a 32 bit DOS FORTH compiler. Distributed as is. See the warnings. This is not for the faint hearted. It would be of interest mainly to someone developing software for the third world where you need fast execution on old klunker XT and AT computers. You can write some very sophisticated data entry programs with it that will run circles around modern data entry programs.
Andy Dent
2009-02-01 23:32:37
A:
And of course, a graphical DSL would require no parsing at all.
John Saunders
2009-05-11 17:55:44
That's a truly misleading answer. Something has to "accept the DSL fragments" from the DSL programmer, and check what was entered is valid. Whether that something is a traditional parser generator for string-based languages, or an adhoc graphic UI that accepts boxes and arrows linking the boxes, or an automatically generated UI from a graph-grammar, you still have to have this machinery. And the machinery for a text-based DSL is presently a lot easier to put together than one for a graphical langauge. You can say that a pig is a dog, but its still a pig.
Ira Baxter
2010-02-06 19:53:19
@Ira: I think you should look at the DSL Toolkit in the Visual Studio SDK. There is no parsing. There is no acceptance of fragments. The UI accepts GUI gestures like dragging and dropping, along with menu or keyboard commands, and builds an in-memory representation of the DSL instance. It's _building_, not _parsing_.
John Saunders
2010-02-07 02:33:10
If there are any illegal gestures, it is "parsing". String parsers "build" data structures in memory too, and I fail to see that makes any difference in the discussion about what parsing is. You might say, "but I didn't have to write the parser". OK, there I might agree, but again the distinction between that and Bison (which you don't have to write) isn't much; somewhere, somebody (you?) has to say what a legal structure is, and something has to check that what you are "gesturing" produces such a legal structure. You *have* a parser, and it is parsing.
Ira Baxter
2010-02-08 21:32:25
John Saunders
2010-02-09 00:54:58
A parser is a predicate that determines if an input entity is an instance of a language. A parser that builds structures is doing double-duty: it provides a yes-or-no answer to "is that a valid lanaguage instance", and stores a structure that represents the language instance (whether it stores original text, an AST or a graph is irrelevant). An "event-driven" sequence of inputs is just a piecemeal way to describe a graph-like structure, in the same way that a stream of characters (interpreted one-by-one) is a piecemeal way to describe a string langauge instance. *Its still a parser!*
Ira Baxter
2010-02-09 15:11:58
@John... I will take a look at your Amazon recommendation. I'm not objecting to graphical DSLs or graphical parsers... just the misleading terminology being used. Software Engineering is hard enough that clean abstract unifying perspectives are extremely important.
Ira Baxter
2010-02-09 15:58:27
@Ira: I still say it's not a parser. It is not determining a valid language instance. It's determining valid UI gestures. The valid gestures build a valid language instance.
John Saunders
2010-02-09 17:44:36
@John: I find that analogy unconvincing. A string parser determines valid "next letters" which are the equivalent of "gestures" that lead to valid langauge instances. * If the UI can say, 'That gesture is not valid', then it is parsing *.
Ira Baxter
2010-02-09 17:57:35
@Ira: I believe you're stretching the term "parsing" to include any validation based on a sequence of event points over time. I see no reason to stretch the definition.
John Saunders
2010-02-09 19:31:50
@John: I don't think its a stretch. It means I can use the idea, and parser generators for strings, graphs, and sequences of timed events [some sequences are legal, some are not, period]. (And we do, based on tools we build, see my bio). This unified view of the world makes me productive. But apparantly I'm not going to convince you. Let's leave it that.
Ira Baxter
2010-02-09 20:36:13
@Ira: from your profile, you should certainly spend a weekend with the DSL toolkit and the book. It's possible that it will add a screwdriver to the hammer in your toolkit.
John Saunders
2010-02-09 20:45:38
@John: Well, that's why I'm looking. I'm very much a fan of DSLs; our DMS Software Reengineering Toolkit is an engine for implementing (in its present state) text-based DSLs, but it is designed to capture graphs for non-text based DSLs, and DMS itself is implemented with an array of 6 cooperating but radically different DSLs that DMS compiles down to machine code. I think I'm already there in terms of the utility of graphical DSLs and how they should be entered. Just not there in terms of being able to do that easily with our present DMS.
Ira Baxter
2010-02-09 20:49:39
@Ira: Then I recommend you read the book. The authors not only discuss the toolkit, but also their rationale on when and how to write a DSL using the toolkit. You'll find the toolkit has been updated for VS2010, and that Visual Studio will include several DSLs created with the toolkit. Another, richer example, with source, is at http://servicefactory.codeplex.com/. That's three cooperating DSLs, which together create the model for a web service.
John Saunders
2010-02-09 21:34:40
I'm with Ira - an event stream from a GUI is either a sequence of tokens or it is reacted to and consumed immediately. If the former, it's a DSL because the tokens are being used to construct something for later processing.
Andy Dent
2010-02-12 15:19:53
If this was a question I'd vote to close this as spam or astroturfing from a Microsoft MVP - apologies for the ad-hominem reference. The answer is not only incorrect but quite misleading. It is nothing but a plug for an MS toolkit with no informative value in answering the OP's question. This toolkit still requires one to build a 'language' definition, so it is not materially different from a parser generator. As an MVP You're supposed to be a semi-official representative of your sponsor. Your posting is fanboy-ism at best, astroturfing at worst. Shame on you.
ConcernedOfTunbridgeWells
2010-02-12 15:36:51
@ConcernedOfTunbridgeWells: use @John to direct a comment at me. I'm only just seeing this. Sorry, I see nothing in the OP's question to rule out a graphical DSL. Sorry if you don't accept a graphical DSL as being a DSL. You might want to read the book I referenced before closing your mind to that. You could also download the SDK, for free, to get the documentation. _Then_ it would be reasonable to close your mind.
John Saunders
2010-03-30 19:17:18