Carrot is not the first XSLT-inspired project to provide a shorter syntax than XSLT itself. Syntax shorthands have included Paul Tchistopolskii's XSLScript, Sam Wilmott's RXSLT, and another project called XSLTXT. Although none of these projects provided direct inspiration for Carrot, they all address one of the same desires that Carrot addresses: being able to program in XSLT more concisely ·
Since programmers often build task-specific tools, one way to make them more productive is to give them better tool-making tools. When tools take the form of program generators, this idea leads to libraries for creating languages that are directly extensible. Programmers may even be encouraged to think about a problem in terms of a language that would better support the task. This approach is sometimes called language-oriented programming ·
Im Gespräch mit Tim Pritlove gibt Clemens Schrimpe einen Einblick in die Geschichte der Netzversorgung, die heutige Technik und die Gründe, warum die DSL-Anschlüsse häufig nicht das liefern, was sie könnten und was in der Zukunft für neue Probleme hinsichtlich der Dienstgüte und Netzneutralität zu erwarten ist. ·
demonstrates that sprintf and sscanf can indeed use exactly the same formatting specification, which is a first-class value. We demonstrate typed sprintf and typed sscanf sharing the same formatting specification. Our solution is surprisingly trivial: it defines a simple embedded domain-specific language of formatting patterns. The functions sprintf and sscanf are two interpreters of the language, to build or parse a string according to the given pattern. Our solution relies only on GADTs. We demonstrate that lambda-abstractions at the type level are expressible already in the Hindley-Milner type system; GADT with the included polymorphic recursion help us use the abstractions. ·
c2005 Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness. ·
In our professional software development, we have focused on finding ways to help developers work more effectively. Despite the range of programming languages available today, we are still limited by them. It makes sense to extend the existing languages to create more domain-oriented ones, which allow writing programs on a higher level and in a manner that is more natural to each domain. With an instrument that allows creating language constructs as simple as creating classes or methods is in a conventional language, you can significantly change the way you develop software. This new style of programming, when you create specialized languages, use them to develop software, and extend them when and how required, is called Language Oriented Programming (LOP). MPS Story Meta Programming System started in 2003 as a research project. In 2004, its underlying concepts were described in the Language Oriented Programming article. ·
A Taxonomy of meta-programming systems. In a meta-programming system meta-programs manipulate object-programs. Meta-programs may construct object-programs, combine object-program fragments into larger object-programs, observe the structure and other properties of object-programs, and execute object-programs to obtain their values. There are two important kind of meta-programming scenarios: program generators, and program analyses. Each has a number of distinguishing characteristics 1. Generator 1. Representation: Strings vs. Algebraic datatype vs. Quasi-quote 2. Automatic vs. Manual annotation 3. Static vs. Runtime Generator 4. Homo vs. Heterogeneous 5. Typed vs. un-Typed 1. Statically vs. Dynamically Typed 6. 2-stage vs. N-stage 2. Analysis 1. Homo vs. Heterogeneous 2. HOAS vs. First Order Syntax 3. Typed vs. un-Typed ·
Jaskell is a functional scripting programming language that runs in JVM. The name "Jaskell" stands for Java-Haskell, but it is not haskell 1. Most of the current scripting languages are Object-Oriented. Though they more or less have functional tastes (Ruby's sexy closure, for example), the heart of them are still Object-Oriented. One of the most important essenses of functional programming (combinators) is yet to be brought into Java. 2. Jaskell brings with it higher order function, function currying, pattern match and monadic combinator support. 3. Monadic combinator is ideal for designing Domain Specific Language. It is relatively easy to tailor Jaskell runtime to make domain specific syntax look like simple atomic statements. See Neptune for a real example. 4. Jaskell is nothing but a Java library that passes Java objects in and out of the interpreter. ·
Tim Sheard, Zine-el-abidine Benaissa, and Emir Pasalic * Introduction * Staging in MetaML * Monads in Langauge Design * Monads in METAML * Illustrating our compiler development method o The while-language o The structure of the solution o Step 1: monadic interpreter o Step 2: staged interpreter + Interpreter for Commands. + An example. * Step 3: Back-end translation and intermediate code optimization o Intensional analysis of code fragments ·
au:chlipala Ur introduces richer type system features into FP. Ur is functional, pure, statically-typed, and strict. Ur supports metaprogramming based on row types. Ur/Web is standard library and associated rules for parsing and optimization. Ur/Web supports construction of dynamic web applications backed by SQL databases. The signature of the standard library is such that well-typed Ur/Web programs "don't go wrong" in a very broad sense. They also may not: * Suffer from any kinds of code-injection attacks * Return invalid HTML * Contain dead intra-application links * Have mismatches between HTML forms and the fields expected by their handlers It is also possible to use metaprogramming to build significant application pieces by analysis of type structure - demo includes an ML-style functor for building an admin interface for an arbitrary SQL table. The Ur/Web compiler also produces very efficient object code that does not use gc ·
Ur/Web is a DSL for programming web applications backed by SQL db. It is statically-typed and purely functional. Ur is the base language, and the web-specific features of Ur/Web (mostly) come only in the form of special rules for parsing and optimization. The Ur core looks a lot like Standard ML, with a few Haskell-isms added, and kinder, gentler versions added of many features from dependently-typed languages like the logic behind Coq. The type system is much more expressive than in ML and Haskell, such that well-typed web applications cannot "go wrong," not just in handling single HTTP requests, but across their entire lifetimes of interacting with HTTP clients. Beyond that, Ur is unusual is using ideas from dependent typing to enable very effective metaprogramming, or programming with explicit analysis of type structure. Many common web application components can be built by Ur/Web functions that operate on types ·
Implementing web applications in an object-oriented language such as Java using state-of-the-art frameworks produces robust software, but involves a lot of boilerplate code. (DSLs) replace boilerplate code by high-level models, from which code can be generated. This tutorial shows how to find domain-specific abstractions based on patterns in existing (reference) programs and build domain-specific languages to capture these abstraction using several DSLs for DSL engineering: SDF for syntax definition and Stratego/XT for code generation. The approach is illustrated using the design and implementation of WebDSL, a domain-specific language for web applications, which provides abstractions for data models, page definitions, access control, workflow, and styling. * WebDSL: A Case Study in Domain-Specific Language Engineering * Code Generation by Model Transformation * Domain-Specific Language Engineering. A Case Study in Agile DSL Development ·
Ensuring Correct-by-Construction Resource Usage by using Full-Spectrum Dependent Types Edwin Brady and Kevin Hammond Abstract: Where it has been done at all, formally demonstrating the correctness of functional programs has historically focused on proving essential properties derived from the functional specification of the software. In this paper, we show that correct-by-construction software development can also handle the equally important class of extra-functional properties, namely the correct usage of resources. We do this using a novel embedded domain-specific language approach that exploits the capabilities of full-spectrum dependent types. Our approach provides significant benefits over previous approaches based on less powerful type systems in reducing notational overhead, and in simplifying the process of formal proof. Tags: Dependent types, DSEL, resource aware ·
Panel on Runtime, March 20, 2001 Richard Kelsey, David Moon, Tucker Withington, Kim Barrett, Scott McKay. Panel on Compilation, April 24, 2001 David Detlefs, Will Clinger, Martin Rinard, and Mat Hostetter. Panel on Language Design, May 10, 2001 Paul Graham, John Maeda, Jonathan Rees, Guy Steele. ·
Probably the most important thing to notice about this style is that the intent is to do something along the lines of an internal DomainSpecificLanguage. Indeed this is why we chose the term 'fluent' to describe it, in many ways the two terms are synonyms. The API is primarily designed to be readable and to flow. The price of this fluency is more effort, both in thinking and in the API construction itself. The simple API of constructor, setter, and addition methods is much easier to write. Coming up with a nice fluent API requires a good bit of thought. Indeed one of the problems of this little example is that I just knocked it up in a Calgary coffee shop over breakfast. Good fluent APIs take a while to build. If you want a much more thought out example of a fluent API take a look at JMock. JMock, like any mocking library, needs to create complex specifications of behavior. There have been many mocking libraries built over the last few years, JMock's contains a very nice fluent API ·
Habe das Kabelmodem ''T.Home Speedport 200'' Wie oder wo kann ich das Modem auf den neuen Standart umstellen wenn dieser bis Ende des Jahres eingeführt wird, achja, nutze XP mit SP3. Habe es erst vor 2 Jahren gekauft, und hoffe das ich mir ... ·
Home Learn more Scaladoc Community Follow _squeryl on TwitterTwitter
A Scala ORM and DSL for talking with Databases with minimum verbosity and maximum type safety
Write compiler validated statements.
Squeryl statements that pass compilation won’t fail at runtime. Refactor your schema as often as is required, the Scala compiler and your IDE will tell you exactly which lines of code are affected.
Never repeat yourself
The Composability of Squeryl statements allows you to define them
once and reuse them as sub queries within other statements.
Write as declaratively as SQL, only with less boilerplate. SQL’s declarativeness is preserved, not encapsulated in a lower level API that requires imperative and procedural code to get things done.
Explicitly control retrieval granularity and laziness
A significant part of optimizing a database abstraction layer is to choose for every situation the right balance between fine and large grained retrieval, and the optimal mix of laziness and eagerness. Data retrieval strategies are explicit in Squeryl rather than driven by configuration like current generation Java ORMs read more ·
Papyrus is aiming at providing an integrated and user-consumable environment for editing any kind of EMF model and particularly supporting UML and related modeling languages such as SysML and MARTE. Papyrus provides diagram editors for EMF-based modeling languages amongst them UML 2 and SysML and the glue required for integrating these editors (GMF-based or not) with other MBD and MDSD tools.
Papyrus also offers a very advanced support of UML profiles that enables users to define editors for DSLs based on the UML 2 standard. The main feature of Papyrus regarding this latter point is a set of very powerful customization mechanisms which can be leveraged to create user-defined Papyrus perspectives and give it the same look and feel as a "pure" DSL editor. ·
Sculptor is a simple and powerful code generation platform, which provides a quick start to Model Driven Software Development (MDSD). When using Sculptor you can focus on the business domain, instead of technical details. You can use the concepts from Domain-Driven Design (DDD) in the textual Domain Specific Language (DSL). E.g. Service, Module, Entity, Value Object, Repository...
From the textual DSL Sculptor generates high quality Java code and configuration using openArchitectureWare (oAW). The generated code is based on well-known frameworks, such as Spring Framework, Spring Web Flow, JSF, RCP, Hibernate and Java EE.
Within 15 minutes you can go from scratch to a running application, including build scripts, Eclipse projects, domain model, Hibernate persistence, services, Web Flow application and much more. Thereafter you can continue by evolving the design, add manual code and regenerate, i.e. it is not a one-shot generation.
Sculptor is not an one-size-fits-all product. Even though it is a good start for many systems, sooner or later customization is always needed. Sculptor is designed and documented with this in mind. The generated result can easily be modified to meet your needs. ·
easyb is a behavior driven development framework for the Java platform. By using a specification based Domain Specific Language, easyb aims to enable executable, yet readable documentation. ·