Home
FAQ
Feedback
Departments
Discussions
(new topic)
Language Evaluation
PL Courses
Research Papers
Design Docs
Quotations
Genealogical Diagrams
|
|
|
|
DSL
| Axiom Computer Algebra System |
|
Axiom...defines a strongly typed, mathematically correct type hierarchy. It has a programming language and a built-in compiler....In its current state it represents about 30 years and 300 man-years of research work.
This one is a gift for Frank!
Posted to DSL by Mark Evans on 6/5/04; 12:27:46 AM
Discuss (10 responses)
|
|
| When and How to Develop Domain-Specific Languages |
|
When and How to Develop Domain-Specific Languages. Marjan Mernik, Jan Heering, Anthony M.Sloane. Submitted for publication to ACM Computing Surveys
Yet another paper on DSL design patterns.
The paper provides a nice analysis of the tradeoffs of different design approaches (e.g., embedding vs. building a compiler). The bibliography is a good soruce for example DSLs.
As you might expect I don't agree with "Lesson 3" quoted in section 2.4: Design only what is necessary.
Of course, "over-design" is bad. But "no design" is worse. Languages are not as simple as they appear to the casual observer, and some design effort (or great intuition) is required in order to reap the benefits a DSL can provide.
Perhaps the best tip for those trying to design DSLs is to acquaint themselves with well designed DSLs. Experience is, of course, important for any design activity. I think it is of even higher importance for DSL design and language design in general.
Opionions, anyone?
Posted to DSL by Ehud Lamm on 4/28/04; 4:25:25 AM
Discuss (3 responses)
|
|
| UML and DSLs |
|
Forget the Microsoft slant of the referenced blog post, and consider the fundamental issue. Despite the name UML is hardly a language, given the problematic nature of UML semantics (yeah, I know about OCL).
Modelling and specification are just as much in need of well defined semantics as is programming. Perhaps even more.
In order to provide good tool support we need to have a standard syntax, well defined semantics, and rigorous domain models.
Language designers are here to stay... The PL community is likely to produce the next innovation in software engineering.
But that doesn't surprise anyone here, does it?
Posted to DSL by Ehud Lamm on 4/22/04; 3:41:28 AM
Discuss (5 responses)
|
|
| Validating the Unit Correctness of Spreadsheet Programs |
|
Validating the Unit Correctness of Spreadsheet Programs.
Tudor Antoniu and Paul A. Steckler and Shriram Krishnamurthi and Erich Neuwirth and Matthias Felleisen
International Conference on Software Engineering, 2004
More information on XeLda. The unit checking process is explained in detail, and a case study of applying XeLda is presented.
Notice, by the way, that Shriram Krishnamurthi has finally made his publications available.
Posted to DSL by Ehud Lamm on 4/15/04; 2:38:37 AM
Discuss (1 response)
|
|
| The Fault Tolerant Shell |
|
via Slashdot
The Fault-Tolerant Shell (ftsh) is a small language for system integration that makes failures a first class concept. Ftsh aims to combine the ease of scripting with very precise error semantics. It is especially useful in building distributed systems, where failures are common, making timeouts, retry, and alternation necessary techniques. ... If any element of the script fails, all running process trees are reliably cleaned up, and the block is tried again with an exponential backoff.
Posted to DSL by Dan Shappir on 3/16/04; 7:24:17 AM
Discuss (4 responses)
|
|
| Guaranteed Optimization for Domain-Specific Programming |
|
T. Veldhuizen, Guaranteed Optimization for Domain-Specific Programming. In Domain-Specific Program Generation, ed. C. Lengauer and D. Batory, Lecture Notes in Computer Science, Springer-Verlag, 2003.
unless one truly needs a language with radically new semantics or syntax, it's prudent to work with a well-supported, general-purpose language (c.f. [Hud96]). Unfortunately the existing mainstream languages aren't extensible enough to do interesting, high-performance DSL work in a natural way. Therefore a fruitful direction for research is to extend the reach of general-purpose languages; in this we pursue the old, probably unattainable dream of a universal language suitable for all purposes, a dream that goes back at least to Leibniz and his grandiose vision of a Characteristica Universalis in which to formalize all human thought (c.f. [Tho01]). In the past half-century useful connections have been found between logic, type theory, algebra, compilers, and verification; perhaps it is a good time to examine these threads of convergence and take stock of the prospects for universal programming languages.
The focus of the paper is on guaranteed optimization, which addresses some aspects of performance, and proof embeddings, which address safety.
Posted to DSL by Ehud Lamm on 3/8/04; 4:29:03 AM
Discuss (1 response)
|
|
| xtc – eXTensible C |
|
Unfortunately, existing solutions for extending C-like languages are either not expressive enough or [they are] targeted at compiler experts, thus preventing other system builders [non-experts] from reaping similar benefits. In particular, the C preprocessor has limited expressive power and, as a textual substitution system, is inherently unsafe. Next, while C++ templates are Turing-complete, they do not allow for the introduction of new abstraction mechanisms, such as a module system, or changing the compiler itself...to introduce domain-specific extensions. Finally ... existing compilers ... are very large programs and, if they are extensible at all, [are] targeted [only] at compiler experts...
Just recently released from NYU. Note xtc's usage of a packrat parser generator, which perhaps augments the attraction. Not that I am peddling C derivatives, but Ehud likes news with a DSL angle, and of course C is immensely popular. There are a couple of independent, poorly implemented "hacked C" projects to which some benefit might accrue from xtc.
Posted to DSL by Mark Evans on 3/7/04; 10:18:46 PM
Discuss (2 responses)
|
|
| Hancock - a TIA DSL? |
|
Hancock is a C-based domain-specific language designed to make it easy to read, write, and maintain programs that manipulate large amounts of relatively uniform data. - from the site.
A stream of call-detail transactions contains records of telephone calls from an originating phone number to a dialed phone number. [...] Where should analysts focus their attention. [...] use the resulting information to build signatures, which are small profiles of the entities in the stream [...] signatures evolve over time in response to new transactions. - from the journal paper.
Posted to DSL by andrew cooke on 2/14/04; 4:35:40 AM
Discuss
|
|
| Martin Fowler on Domain Specific Languages |
|
Martin Fowler on DSLs...
I've always used the analogy of creating a DSL to help think about building up a design - developing classes and methods with an eye to making them be a DSL. As much as possible I do this within the language I'm using, but if I can't I'm very ready to switch to code generation. At ThoughtWorks we've used code generation and similar techniques widely on our larger systems. The point at which I pull the separate language DSL lever is clearly different between languages. I never really felt the need in Smalltalk to use a separate language, while it's quite common in C++/Java/C#.
Posted to DSL by Patrick Logan on 2/13/04; 12:59:32 PM
Discuss
|
|
| GraphPath |
|
GraphPath is a little-language for analysing graph-structured data, especially RDF. The syntax of GraphPath is reminiscent of Xpath. It has a python implementation that can be teamed up with your favourite python RDF API (e.g. Redland, rdflib, or your own API).
Many interesting things can be represented as graphs (e.g., social networks, web sites, program structure, program call graphs etc. etc.) Indeed, graphs are one the most fundamental abstractions used in computer science (and not just in CS). So it is only natural that I've spent my share of moments trying to design a DSL for graph analysis, the last occasion being when I wanted to give sociologists a tool for exploring social networks. Designing a convinient DSL for this sort of purpose isn't easy.
I haven't checked GraphPath in any depth yet, if someone has - please share your conclusions.
And oh, how is the HotDraw python port coming along Patrick?
Posted to DSL by Ehud Lamm on 2/5/04; 8:53:55 AM
Discuss (5 responses)
|
|
| Graphite DSL for Advanced Typography |
|
The open-source Graphite DSL is a rule-based language to express typographical layout requirements of so-called minority languages. Graphite was developed for non-programming ethnography field workers like Aikhenvald. Of course, not only minority languages have such needs. See the Graphite examples for some instances. Normal fonts do not encode this sort of intelligence.
Ehud, by remarkable coincidence I was composing this post just as you posted Aikhenvald. Great minds think alike? Jupiter conjoined Saturn beneath a full moon? This is getting scary...
Posted to DSL by Mark Evans on 1/30/04; 3:21:51 PM
Discuss (1 response)
|
|
| DSL Implementation in MetaOCaml, Template Haskell, and C++ |
|
Krzysztof Czarnecki, John O’Donnell, Joerg Striegnitz, and Walid Taha.
A very readable and gentle introduction to the metaprogramming facilities in O'caml, Haskell and C++.
Given the authors it is not surprising that the paper is balanced. The facilities in the different languages are compared, but not judged.
Well worth your time if you are interested in DSL implementation, or metaprogramming in general.
Posted to DSL by Ehud Lamm on 1/8/04; 3:23:53 AM
Discuss (2 responses)
|
|
| Comments Requested on SML-Based Graphics DSL |
|
Johnny Andersen has been conducting a one-man mission to convince graphics programmers to use functional programming in their work. To my knowledge, he is the only person currently using SML (or really any functional language) in professional graphics development.
In partial completion of his Bachelor's degree, he has devised an ML-based Domain Specific Language for creating 3D graphics programs.
The language includes a few new ideas:
* Various SML extensions to support more polymorphic behavior
* The "Fieldcase" construct, for branching a program based on the presence of an optional field in a structure
* Optional type arguments
Johnny is seeking input on his language definition, and would appreciate any comments the learned folks at LtU might have.
Posted to DSL by Brent Fulgham on 12/14/03; 11:47:39 AM
Discuss (5 responses)
|
|
| Adding Apples to Oranges |
|
Martin Erwig and Margaret M. Burnett. 4th Int. Symp. on Practical Aspects of Declarative Languages (PADL'02), LNCS 2257, 173-191, 2002.
We define a unit system for end-user
spreadsheets that is
based on the concrete notion of units instead of the abstract concept of
types. Units are derived from header information given by spreadsheets.
The unit system contains concepts, such as dependent units, multiple
units, and unit generalization, that allow the classification of spreadsheet contents on a more fine-grained level than types do. Also, because
communication with the end user happens only in terms of objects that
are contained in the spreadsheet, our system does not require end users
to learn new abstract concepts of type systems.
We discussed typing of spreadsheets before, but I think we didn't discuss this paper.
Winner of The Best Publicity Quote (and/or bogus statistic) Award:
The number of end-user programmers in the United States alone are expected
to reach 55 million by 2005, as compared to only 2.75 million professional programmers
Lecture slides here.
Posted to DSL by Ehud Lamm on 12/9/03; 1:41:03 AM
Discuss (2 responses)
|
|
| DSL in Software Development and Releation to Partial Evaluation |
|
This thesis is divided into three parts and a conclusion. The first part is about
domainspecific languages, more specifically about developing software by de
signing and implementing a new domainspecific language. The second part con
cerns partial evaluation, which was my second major point of interest in this Ph.D.
work. The third and last part describes a concrete case where a domainspecific
language was invented to enhance a specific software development process.
Niels Christensen's Ph.D. thesis.
I guess the main attraction here aside from the discussion of PE is that the work described was done in an industrial setting, and the author discusses the effect this had on how the project evolved.
The third part of the thesis is a detailed real-life example.
Section 1.3 gives the motivation for the project and contains a nice small scale example.
Posted to DSL by Ehud Lamm on 12/8/03; 1:45:35 AM
Discuss (2 responses)
|
|
| A Clockwork Orange: Nadsat |
|
Readers of this blog know that I try to relate programming languages and natural languages, tenuous as these comparisons sometimes are.
I've been reading the excellent introduction written by Blake Morrison to Anthony Burgess's A Clockwork Orange (Penguin Classics edition) in which he discusses Burgess's fictional language Nadsat at some length, and decided that this discussion is somewhat relevant to our discussion of scripting using domain-specific objects (i.e., domain specific vocabulary). And even if not, invented languages are something worth mentioning on LtU from time to time.
As far as I can tell Nadsat is mainly about vocabulary. Burgess used words inspired by German, Russian, and Cockney Slang, while also coining a few original words. You can find a Nadsat dictionary here.
Interestingly enough one can read the novel without a Nadsat dictionary, since the meaning of most words can be understood from context. However, reading the novel can be a bit of a challenge because of the unfamiliar voacabulary - a challenge Burgess obviously knew about, but may still offer a lesson or two about domain specific concepts and abstractions inside computer programs.
There's quite a lot more to say about Nadsat (see here and here) but I'll resist the temptation for the moment. Let me leave you with this insightful explanation of Nadsat from Burgess:
The Vocabulary of my space-age hooligans could be a mixture of Russian and demotic English, seasoned with rhyming slang and the gypsy's bolo. The Russian suffix for -teen was nadsat, and that would be the name of the teenage dialect, spoken by drugi or droogs or friends of violence.
Posted to DSL by Ehud Lamm on 12/6/03; 2:18:35 PM
Discuss (6 responses)
|
|
| Longhorn Command Shell ("Monad") |
|
Some people are quite excited about the new command shell Microsoft is planning for Longhorn. It sure looks like an improvement over cmd.exe. That command shells are micro-languages is not a new observation, so the new shell -- code named Monad -- is on topic for LtU.
It is quite amusing to see the speculation going on about the name. I guess not everyone knows that monads are used in functional programming for stringing operations together. People are actually trying to figure out what Leibniz has to do with Longhorn 
Be that as it may, you may be itnerested in the PDC slide deck (PPT), which contains some useful examples.
It seems that the main innovations are the use of structured date (i.e., objects) instead of text streams, standardized error handling, and support for naviagting multiple hierarchical name spaces in addition to the file system.
Not only are shells DSLs, they are also one of the more successful examples of end user programming. Many so-called super users know how to concatenate and filter the standard shell utilities (e.g., more, sort etc.), even though they lack programming knowledge. This is due to the simplicity of the model.
From what I've seen of Monad, I am not sure if it's going to empower end users, or make the shell less accessible than it is today.
Posted to DSL by Ehud Lamm on 11/8/03; 1:13:22 PM
Discuss (11 responses)
|
|
| LL3 Webcast |
|
This doesn't seem to have been announced here - it's probably too late to attend (tomorrow), but there is a live webcast.
I'm taking a holiday in the middle of my shift and plan to sit here in my office watching...
Posted to DSL by andrew cooke on 11/7/03; 10:56:53 AM
Discuss (12 responses)
|
|
| Domain-specific and general-purpose aspects of spreadsheet languages |
|
Alan Yoder & David Cohn (Univ. of Notre Dame), DSL '97 - First ACM SIGPLAN Workshop on Domain-Specific Languages, 1997.
Spreadsheets comprise a language metaphor which has been found very useful for manipulation and presentation of financial data. As such they may be considered a domain-specific language. The metaphor may have application in other areas, however. For example, spreadsheets simultaneously offer natural parallelism and ease of use. Adapting them to do general-purpose computing while preserving their natural parallelism and ease of use would be highly desirable, especially given the current trend toward massive parallelism. And the ease with which users are able to format their output would be a desirable addition to any general-purpose language.
One of the things I try to do with my SE students is discuss innovative or influential software systems, and try to analyze their essential features and areas of particular strength. Which is why I mentioned spreadsheets to them today. I want to talk about the flexibility spreadsheets give end users.
So just for the fun of it I went googling for spreadsheets, and came across this paper, which isn't very remarkable (I think), but may still be interesting enough for a quick read.
One of the earliest tech reports I wrote comapred SAS and spreadsheets, and discussed some of the same issues discussed in this paper. My agenda at that point was to recommend changes to our in house report generation DSL in order to, you guessed it, make it more flexible...
Posted to DSL by Ehud Lamm on 10/7/03; 12:18:49 PM
Discuss (4 responses)
|
|
| Microsoft DirectX High Level Shading Language |
|
The High Level Shading Language is one of the major new features of Microsoft® DirectX® 9.0 and will change the way we develop shaders forever. With the progression of hardware capabilities, such as additional texture stages and longer instruction counts, real-time shaders are becoming more powerful and complex than ever. This results in algorithms that are difficult to develop using assembler; couple this with the variety of available hardware needing support in your game, and you're in for a shader management nightmare.
This is where the High Level Shader Language helps: Mix with a healthy dose of the Microsoft® Direct3DX (D3DX) Effects framework, and you have a powerful and flexible workspace to create the most awesome shading effects ever seen. Of course you can take advantage of the power of HLSL without even touching D3DX Effects if you wish to.
The DirectX High Level Shading Language is based on a C-style syntax, which eases learning and provides a selection of pre-defined types for scalars, vectors, and matrices. The language also supports a large number of intrinsic functions to help with everyday tasks such as transformation.
Shades (pun intended) of Cg.
Posted to DSL by Dan Shappir on 5/13/03; 2:55:07 AM
Discuss (3 responses)
|
|
| A Language for Bi-Directional Tree Transformations |
|
A Language for Bi-Directional Tree Transformations. Michael B. Greenwald, Jonathan T. Moore, Benjamin C. Pierce, and Alan Schmitt. 2003.
We develop a semantic foundation and a core programming language for bi-directional transformations on tree-stuctured data. In one direction, these transformations, called lenses, map a complex "concrete" tree into a simplified "abstract" one; in the other, they map a modified abstract tree, together with the original concrete tree, to a correspondingly modified concrete tree...
We then instantiate our semantic framework as a small
programming language, called Hocus Focus, whose expressions denote well-behaved lenses operating on tree-structured data. The primitives include familiar constructs from functional programming (composition, mapping, projection, recursion) together with some novel primitives for manipulating trees (splitting, pruning, pivoting, etc.)
The work presented in this paper is part of the Harmony universal data synchronization project.
The paper includes an extended example showing how Hocus Focus can be used for synchronizing browser bookmarks.
This is a nice example of DSL design. The approach taken is to define a set of primitives, and provide standard cominators (e.g., composition, conditionals etc.)
This is, of course, a standard approach. It directly lends itself to implementation via language embedding.
A longer version of the paper can be found here.
Posted to DSL by Ehud Lamm on 5/8/03; 4:35:03 AM
Discuss
|
|
| Scapy - network DSL in Python |
|
The most interesting thing here (apart from the tool itself) is that it's presented as a tool that uses Python, not as a library or set of classes. I'm surprised (don't know why) at how integrated it appears - it looks like a tool with a command line, not Python with some extra classes. Is the DSL meme becoming more popular?
via sweetcode
Posted to DSL by andrew cooke on 4/22/03; 11:38:18 AM
Discuss (1 response)
|
|
| DPROG |
DPROG is a domain specific language for specifying dynamic programming algorithms; given a recursive definition of the problem, the compiler generates code for solving the problem using dynamic programming.
via sweetcode
Posted to DSL by andrew cooke on 4/8/03; 4:08:03 AM
Discuss (17 responses)
|
|
| A Framework for Programming Embedded Systems |
This paper describes CES, a proto-type of a new programming language for robots and other embedded systems, equipped with sensors and actuators. CES contains two new ideas, currently not found in other programming languages: support of computing with uncertain information, and support of adaptation and teaching as a means of programming. These innovations facilitate the rapid development of software for embedded systems, as demonstrated by two mobile robot applications.
It's 46 pages long. I've skim read it and I don't see anything that can't be done as a library function. I suspect that functional reactive robotics the probabilistic lambda-calculus will move you closer to ease of implementation of robot controllers. Perhaps others with more knowledge of probabilistic languages (and more time) can comment?
Posted to DSL by Noel Welsh on 4/6/03; 1:33:02 AM
Discuss
|
|
| Lisp powers Jak & Daxter at Naughty Dog |
|
An interesting success story for a DSL in a very demanding environment.
What is GOAL?
- GOAL is our custom compiler based on Lisp (well, actually Scheme).
- Practically all of the run-time code (approximately half a million
lines of code) was written in GOAL.
- Only the IOP code and a small amount of kernel code was written in C.
Posted to DSL by Noel Welsh on 3/11/03; 12:43:39 PM
Discuss (4 responses)
|
|
| What a URI identifies |
|
Studying little languages (aka DSLs) is perhaps the best way to realize just how powerful the linguistic metaphor is (as well as to realize where and when it isn't enough). Good little languages expose fundamental abstractions relavent to the programming domain, and provide a convinient linguistic structure.
In his famous column about little languages, Jon Bentley mentioned a few microscopic languages such as regexps and picture strings. Very little languages (VLLs) of this sort often exhibit elegant language and notation design.
Still, for something to be a language we must be able to reason about semantics. In this context, the recent thread on the W3C TAG mailing list concrening URIs makes for interesting and amusing reading.
Notice that the issue here is a bit more subtle that simply defining semantics. The (operational) semantics of URIs are well known (they are essentially the HTTP protocol). However, defining what exactly is meant by terms like resource (pointed to by a URI) and representation is not so straightforward, as some examples illustrate.
The www-tag thread inspired interesting comments from both Jon Udell and Phil Windley.
Posted to DSL by Ehud Lamm on 1/29/03; 1:54:55 PM
Discuss (2 responses)
|
|
| Embedding Sequence Analysis in FP |
|
R. Giegerich. Embedding Sequence Analysis in the Functional Programming Paradigm -- A Feasibility Study. Report Nr. 8, Technische Fakultat, Universitat Bielefeld, 1992.
The present paper is a first investigation of the hypothesis that a careful embedding of a sequence analysis system in the functional paradigm can significantly improve transparency, felxibility and desrciptive power.
These are obvious advantages of using a DSL (or should we say DSEL). However, the issue with all such embeddings is efficiency. This is not discussed in any detail in this paper.
There are two basic issues: First, compiling the DSL may improve performance. Second, the domain may direct you to algorithms, data structures and optimizations that, being domain specific, can influence the way DSL code is interpreted or compiled (e.g., using suffix trees for sequence comparisons).
Many of these issues are discussed in related papers.
Posted to DSL by Ehud Lamm on 12/26/02; 2:19:09 AM
Discuss
|
|
| User-defined functions in Excel |
|
Improving the world's most popular functional language: user-defined functions in Excel. Simon Peyton Jones, Margaret Burnett, Alan Blackwell. 10 pages, November 2002. Submitted to PLDI 2003.
We describe extensions to the Excel spreadsheet that integrate user-defined functions into the spreadsheet grid, rather than treating them as a "bolt-on". Our case study is unusual in that it highlights the way that programming language insights can be applied to a product not normally considered as a programming language.
Obviously related to end-user programming, programming by demonstration etc.
Excel is quite an innovative product (flame on!), it would be interesting to see if the work presented in this paper ever appears in the product.
Posted to DSL by Ehud Lamm on 12/1/02; 6:50:13 AM
Discuss (12 responses)
|
|
| smgn: Rapid Prototyping of Small Domain-Specific Languages |
|
smgn: Rapid Prototyping of Small Domain-Specific Languages. Holger Kienle and David Moore, Special Issue on Domain-Specific Languages, Journal of Computing and Information Technology (CIT), Volume 10, Number 1, pages 37-53, 2002.
smgn looks like a small and sweet system for building simple DSLs.
smgn works by parsing the DSL, using a grammer file, and then invoking a user supplied program written in a parse tree processing language (another DSL, of course). Thus, the system is based on concrete syntax rather the ASTs.
The tree processing language (the paper calls it the "macro language") was originally designed for HTML processing, and looks a bit like XSLT.
The paper describes some systems that used smgn. It would be interesting to hear if anyone else has tried it.
(Postscript version)
Posted to DSL by Ehud Lamm on 10/22/02; 7:50:20 AM
Discuss (1 response)
|
|
| Introduction to Special Issue on Domain-Specific Languages |
|
Most papers on DSL's focus on specific implementation technologies such
as Haskell or ASF-SDF, so I'm always a little uneasy when I refer
to something that doesn't use these technologies as a DSL,
e.g.
Mathematica,
S-PLUS,
SAS,
SPSS, or
Autocad.
The definitions in this very short introduction help
clarify what might legitimately be called a DSL
by providing some historical context.
At the far end of the spectrum even
domain specific libraries used in general purpose
languages might qualify:
The poor man's approach to DSL implementation is
to implement a library to be used via an API in the
general-purpose language of choice. This approach is
not suitable when the domain requires:
dedicated notation, that is, syntax,
dedicated abstraction mechanisms,
dedicated scoping or typing rules,
domain-specific optimizations,
domain-specific analyses,
domain-specific error reporting...
There were DSL's long before the term DSL arose:
"The idea of DSL's is presumably as old as the notion of
programming languages."
(APT developed at MIT in 1955 is cited as the first DSL.)
A "DSL provides built-in abstractions and notations specific to the domain of concern"
and it is usually declarative.
The introduction also enumerates the costs and trade-offs
of DSL's.
[Special Issue Homepage]
(Special Issue on Domain-Specific Languages
Guest Editors' Introduction,
Ralf Lammel1 and Marjan Mernik, 2001)
Posted to DSL by jon fernquest on 9/18/02; 12:50:10 AM
Discuss (2 responses)
|
|
| Little Languages: Little Maintenance? |
|
A case study of a DSL used by a bank to describe financial products.
An extensive COBOL library of financial engineering routines
was already used by the bank, but
"using this library directly in COBOL did not provide the right level of abstraction, and
cumbersome encoding tricks were needed to use, e.g., lists without a fixed length."
ASF-SDF
was used to translate the DSL code into a sequence of library calls in COBOL.
The DSL reduced the turnaround time for designing new products, but
"on the negative side, it is not so easy to extend the language.
When a new data type or a new built-in function is required,
the compiler as well as the COBOL library, need to be adapted."
The DSL was made more accessible to financial experts with a front-end:
"End-users can combine existing components into a new product
by filling in the answers of a questionnaire."
Another Tcl/Tk generating DSL created the questionnaires.
The costs and benefits of using a DSL are enumerated,
along with effects on maintainability.
A list of DSL design questions to ask is also given.
(Little Languages: Little Maintenance?,
ARIE VAN DEURSEN and PAUL KLINT, 1997)
Posted to DSL by jon fernquest on 9/2/02; 10:57:26 PM
Discuss (3 responses)
|
|
| Language Design and Implementation by Selection |
|
Peter Pfahler und Uwe Kastens. Language Design and Implementation by Selection. In Proc. 1st ACM-SIGPLAN Workshop on Domain-Specific-Languages, DSL '97, Paris, France, January 18, 1997, S. 97-108. Technical Report, University of Illinois at Urbana-Champaign, 1997.
I came across this paper in the bibliography of a paper discussed here yesterday.
This paper is a case study of a system for language design. I think it is fair to say that the system can be seen as a set of "wizards" that help you through the language design process.
The limitations of such an approach are obvious, but I am quite interested in tools of this sort because I want students to be able to experiment with DSL design (as opposed to implementation).
Does anyone have experience with this system, or something similar?
Posted to DSL by Ehud Lamm on 8/17/02; 3:03:15 AM
Discuss
|
|
| One Day Compilers (Graydon Hoare) |
|
(via Ken Rawlings)
A tutorial on implementing DSLs, using O'caml, syntax extension, and a C backend.
The approach is based on using Camlp4 for embedding the DSL in O'caml, and producing C source code using the author's Cquot package (for C code quasiquoting).
A similar thing can be done using Scheme.
Posted to DSL by Ehud Lamm on 8/12/02; 2:46:33 AM
Discuss (2 responses)
|
|
| Diagrammatic Representations in Domain-Specific Languages |
|
Applies formal methods to visual programming
mandated by industry standard. An embedded control system and programmable logic controller industry standard (IEC 1131-3) defines four DSL's that can be represented either diagrammatically or textually utilizing "circuit (i.e. box-and-wire) diagrams, emphasising a data-flow view" and "Petri net diagrams, suited to a control-flow view." (140) The author notes that in general "diagrams are a very natural syntax for software in certain domains; particularly those in which diagrammatic notations form an integral part of design practice and technical discourse" (139) and that
"domain-specific representations of computer software
should accord with, and ideally be derived from existing notations
in the domain." (9) But deriving rigorous conclusions from common diagrammatic manipulation is not trivial:
"While the use of formal methods in supplying evidence is often recommended
or mandated....their practical application remains undeniably difficult...
...many informal or semi-formal arguments are
guided by the structure of some high-level representation of the system,
such as a diagram...the elevation of such arguments to a level admissible
as rigorous evidence requires their formal underpinning, validation and
justification by logical means...
our aim is to apply the theory connecting diagrammatic representations
to semantics in seeking criteria under which representation-driven arguments are
deemed sufficient to provide rigorous evidence without the need of explicitly constructing
fully formal proofs. (144)"
Posted to DSL by jon fernquest on 8/2/02; 11:48:30 PM
Discuss
|
|
| First-class Attribute Grammars |
|
Seeks to improve attribute grammars so they can
be more easily used in the
rapid proto-typing of Domain Specific Languages.
Attribute grammars
are not in widespread use:
This may be due to restrictions imposed by attribute definition languages,
which are often less flexible than general purpose functional programming
languages. Such general languages tend to yield descriptions that are compact,
but they lack the dedicated structuring mechanisms of attribute grammars. In this
paper we initiate a systematic study of such structuring mechanisms, by giving
them a compositional semantics. The semantics is expressed in the vocabulary
of functional programming. Our semantics thus opens the way towards combining
the powerful structuring mechanisms for attribute grammars with the flexibility of
a general purpose programming language.
Attribute grammars provide the foundation for
Intentional Programming in two detailed overviews:
Intentional Programming: A Host of Language Features,
Intentional Programming Talk at the British Computer Society.
From the
Program Transformation Wiki.
Also see Omniscium's FAQ
Aspects from Aspect Oriented Programming
are discussed in these two papers as well as this prior
LTU post.
Posted to DSL by jon fernquest on 8/1/02; 3:40:11 AM
Discuss (3 responses)
|
|
| Intentional Programming Overview |
|
Full title is too long:
"Transformation and Visualization of Abstractions using the Intentional Programming System."
This is the most sober and simple description of Intentional Programming that
I could find. Written by a German scholar visiting Microsoft,
it provides a brief overview of Abstract Syntax trees in IP,
alternative ways of visualizing a program,
and a classification of program transformations.
Like so much other work associated with the IP project
I get Scheme-hygienic-macro-R5RS-implementation-deja-vu when I read passages like:
The 'if' abstraction known from every general-purpose programming language is
introduced as a new intention. Every node in any source graph referring
to this unique node is an instance of this intention. The three well-known
sub-branches parameterize the instance. Since a declaration is indeed a
reference to a special DCL intention there are only two composition rules,
namely referencing and parameterization.
Posted to DSL by jon fernquest on 7/29/02; 1:11:44 AM
Discuss (5 responses)
|
|
| Application Generators |
|
Excellent survey article from an encyclopedia.
"When a programming activity is well-understood, it can be automated.
Automation transforms software development from
activities like rote coding and tedious debugging to that of specification,
where the "what" of an application is declared and
the “how” is left to a complex, but automatable mapping. Programs that
perform such mappings are application generators
(or just generators). In the technical sense, application generators
are compilers for domain-specific programming languages
(DSLs).....
generators can be viewed as compact representations of software libraries of gigantic size—each library
encoding all the useful code configurations that a generator can produce......
Translation engines and the transformations they support are the heart of all generators.
Found on the
Yannis Smaragdakis's homepage
who was a member of the Intentional Programming team at Microsoft.
Very high-level conceptual with a good bibliography and overview
of programming transformations.
Includes a detailed comparison of two very different systems:
KIDS
from the Kestrel Institute which uses formal methods
and
P2
which uses mainstream C and a more limited
set of transformations.
Posted to DSL by jon fernquest on 7/26/02; 2:37:54 AM
Discuss (1 response)
|
|
| Graphviz: Programmable Graph Editor |
|
Graphviz contains a programmable graph editor "dotty"
that AT&T Labs has released to the public. It seems like
a very good and practical example of a Domain Specific Language:
The procedural interface is convenient for algo-
rithmic operations (e.g. set node color as a function
of degree). The procedural interface also allows re-
programming the WYSIWYG interface. For exam-
ple, the left mouse button can be bound to a func-
tion that highlights all edges attached to the node
under the mouse pointer. The underlying program-
ming language has primitives to start external pro-
cesses and to establish interprocess communication
channels. This makes it possible for dotty to oper-
ate as a graphical front-end for other processes. In
this context, graphs can represent state information
maintained by a back-end process, and user actions
can be bound to functions that translate graph op-
erations to corresponding state change requests sent
to the back-end.
For an overview see the
overview web page and the paper
Applications of Graph Visualization
(by North and Koutsofios, source of above quote)
To see the amazing range of graphs that can be drawn
look at the extensive
directed graph examples
which include finite state machines,
parse trees for computer programs and natural language,
various kinds of flow charts,
graphs with colored nodes, and family trees of unix shells
and programming constructs.
Posted to DSL by jon fernquest on 7/17/02; 4:23:16 AM
Discuss (2 responses)
|
|
| NVIDIA's Cg technology |
|
(via Slashdot)
Cg ("C" for graphics) is a high-level graphics programming language NVIDIA has developed in cooperation with Microsoft for game developers and other 3D content developers to ease the process of bringing 3D objects to life on your computer screen
I'd be the last one to begrudge anybody their right to create their own DSL, but given that this looks like C with some domain-specific types and functions one has to wonder why they couldn't make this happen with C++ and an appropriate library.
Posted to DSL by Dan Shappir on 6/16/02; 10:05:07 AM
Discuss (4 responses)
|
|
| Network Query Language |
|
It's no accident that NQL has a similar name to SQL. NQL is an application of the principles of SQL to apply to all forms of Internet and network programming. Like SQL, NQL allows you to accomplish a great deal in just a few lines of code. Unlike SQL, NQL's domain isn't restricted to the world of databases. There are over 500 powerful building blocks (statements) in NQL, covering everything from crawling web sites to running neural networks!
Aside from the sad fact that the language is proprietary, does anyone know why it didn't catch on? Is it any good?
(I have the feeling this is not really a DSL. The language seems too big and complicated. Why would you need to make neural networks built in?)
Posted to DSL by Ehud Lamm on 6/11/02; 8:08:52 AM
Discuss (2 responses)
|
|
| Scanning, Parsing, and Rewriting Kit - Python |
|
SPARK stands for the Scanning, Parsing, and Rewriting Kit. It formerly had no name, and was referred to as the "little language framework." The first version (circa 1998) was described in the paper Compiling Little Languages in Python at the 7th International Python Conference.
SPARK is written in 100% pure Python, and is made available as open source.
If you want to implement a DSL in Python, this may be a useful tool. Not very practical when efficiency is at stake, but for little languages this may very well be a solution.
The paper provides a decent tutorial, and explains the design of SPARK.
SPARK makes good use (?) of Python's reflection mechanism, which is another reason to take a look. The framework recognizes parsing and tokenizing methods and extracts their exact function from their docstrings (which may contain, for example, a parsing rule). I guess this qualifies as meta-data (which is something we discussed a couple of months ago).
If anyone built something interesting using SPARK, I'd love to see.
Posted to DSL by Ehud Lamm on 5/18/02; 3:32:06 AM
Discuss (3 responses)
|
|
| Domain-specific Embedded Languages and Program Generators |
|
Samuel N. Kamin. Research on Domain-specific Embedded Languages and Program Generators, 1998.
A nice paper about building DSLs by embedding (i.e., your DSL is basically a set of functions inside a host langauge). The paper uses ML. These days I think Haskell would be the language of choice.
The DSLs in the paper are program generators: their execution results in C++ code, which can then be used inside other systems.
Since the programs generated implement parsers, this paper is also a good reminder on the difference between the various parsing techniques (LL vs. LALR etc.).
Posted to DSL by Ehud Lamm on 5/16/02; 12:59:10 PM
Discuss (9 responses)
|
|
| Inside information |
|
Galois seems to be one of the main users of Haskell in industry. I was pleased to learn that Galois is especially interested in DSLs.
Does anyone know more? Success stories etc.? I'd love to know.
(And so that you don't go home empty handed, here's a nice presentation about Haskell and DSLs.)
Posted to DSL by Ehud Lamm on 5/15/02; 7:21:10 AM
Discuss
|
|
| Patterns for Domain Specific Languages |
|
A paper about building DSL's. Discusses when and why DSL's may be more appropriate than hard-wired program logic. The main part of the paper covers some useful patterns for the design and implementation of DSL's (e.g., pipelines, source to source transformation).
Are DSL's really so different? Maybe they should have a seperate LtU department. They are usually implemented rather differently that general purpose languages (i.e, they are often interpreter based, optimization is usually weak, unless the optimizations are specific for the domain etc.)
Posted to DSL by Ehud Lamm on 4/17/01; 12:51:42 PM
Discuss
|
|
|
