Search

We reexamine the characterization of incentive compatible single-parameter mechanisms introduced in Archer & Tardos (2001). We argue that the claimed uniqueness result, called 'Myerson's Lemma' was not well established. We provide an elementary proof of uniqueness that unifies the presentation for two classes of allocation functions used in the literature and show that the general case is a consequence of a little known result from the theory of real functions. We also clarify that our proof of uniqueness is more elementary than the previous one. Finally, by generalizing our characterization result to more dimensions, we provide alternative proofs of revenue equivalence results for multiunit auctions and combinatorial auctions.

We briefly discuss the potential of domain-specific languages and domain-specific modeling languages for ULSSIS engineering, some of the scaling challenges involved, and the possibilities for raising expressiveness beyond current levels.

We briefly discuss the potential of domain-specific languages and domain-specific modeling languages for ULSSIS engineering, some of the scaling challenges involved, and the possibilities for raising expressiveness beyond current levels.

Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general-purpose languages in their domain of application. Although the use of DSLs is by no means new, it is receiving increased attention in the context of model-driven engineering and development of parallel software for multicore processors. We discuss these trends from the perspective of the roles DSLs have traditionally played.

Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general-purpose languages in their domain of application. Although the use of DSLs is by no means new, it is receiving increased attention in the context of model-driven engineering and development of parallel software for multicore processors. We discuss these trends from the perspective of the roles DSLs have traditionally played.

Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general-purpose programming languages in their domain of application. DSL development is hard, requiring both domain knowledge and language development expertise. Few people have both. Not surprisingly, the decision to develop a DSL is often postponed indefinitely, if considered at all, and most DSLs never get beyond the application library stage. Although many articles have been written on the development of particular DSLs, there is very limited literature on DSL development methodologies and many questions remain regarding when and how to develop a DSL. To aid the DSL developer, we identify patterns in the decision, analysis, design, and implementation phases of DSL development. Our patterns improve and extend earlier work on DSL design patterns. We also discuss domain analysis tools and language development systems that may help to speed up DSL development. Finally, we state a number of open problems

Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general-purpose programming languages in their domain of application. DSL development is hard, requiring both domain knowledge and language development expertise. Few people have both. Not surprisingly, the decision to develop a DSL is often postponed indefinitely, if considered at all, and most DSLs never get beyond the application library stage. Although many articles have been written on the development of particular DSLs, there is very limited literature on DSL development methodologies and many questions remain regarding when and how to develop a DSL. To aid the DSL developer, we identify patterns in the decision, analysis, design, and implementation phases of DSL development. Our patterns improve and extend earlier work on DSL design patterns. We also discuss domain analysis tools and language development systems that may help to speed up DSL development. Finally, we state a number of open problems

We introduce the notion of 'generative software complexity' to illustrate some of the problems one may run into when trying to tackle a special case of a question recently raised by Brooks.

Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general purpose programming languages in their domain of application. DSL development is hard, requiring both domain knowledge and language development expertise. Few people have both. Not surprisingly, the decision to develop a DSL is often postponed indefinitely, if considered at all, and most DSLs never get beyond the application library stage. While many articles have been written on the development of particular DSLs, there is very limited literature on DSL development methodologies and many questions remain regarding when and how to develop a DSL. To aid the DSL developer, we identify patterns in the decision, analysis, design, and implementation phases of DSL development. Our patterns try to improve on and extend earlier work on DSL design patterns, in particular by Spinellis (2001). We also discuss domain analysis tools and language development systems that may help to speed up DSL development. Finally, we state a number of open problems.

Many systems are at least partly or implicitly based on term rewriting. Examples are functional languages, computer algebra systems, and theorem provers. We give a brief survey of these systems, and provide a more in-depth comparison of the features of systems that use term rewriting as their primary execution mechanism. We give links to rewrite tools and projects as well as pointers to notions and techniques covered in the preceding chapters.

We introduce the notion of 'generative software complexity' to illustrate some of the problems one may run into when trying to tackle a special case of a question recently raised by Brooks.

Domain-specific languages (DSLs) are languages tailored to a specific application domain. They offer substantial gains in expressiveness and ease of use compared with general purpose programming languages in their domain of application. DSL development is hard, requiring both domain knowledge and language development expertise. Few people have both. Not surprisingly, the decision to develop a DSL is often postponed indefinitely, if considered at all, and most DSLs never get beyond the application library stage. While many articles have been written on the development of particular DSLs, there is very limited literature on DSL development methodologies and many questions remain regarding when and how to develop a DSL. To aid the DSL developer, we identify patterns in the decision, analysis, design, and implementation phases of DSL development. Our patterns try to improve on and extend earlier work on DSL design patterns, in particular by Spinellis (2001). We also discuss domain analysis tools and language development systems that may help to speed up DSL development. Finally, we state a number of open problems.

Many systems are at least partly or implicitly based on term rewriting. Examples are functional languages, computer algebra systems, and theorem provers. We give a brief survey of these systems, and provide a more in-depth comparison of the features of systems that use term rewriting as their primary execution mechanism. We give links to rewrite tools and projects as well as pointers to notions and techniques covered in the preceding chapters.

While application software does the real work, domain-specific languages (DSLs) are tools to help produce it efficiently, and language design assistants in turn are meta-tools to help produce DSLs quickly. DSLs are already in wide use (HTML for web pages, Excel macros for spreadsheet applications, VHDL for hardware design, ...), but many more will be needed for both new as well as existing application domains. Language design assistants to help develop them currently exist only in the basic form of language development systems. After a quick look at domain-specific languages, and especially their relationship to application libraries, we survey existing language development systems and give an outline of future language design assistants.

The ASF+SDF Meta-Environment is an interactive language development environment whose main application areas are definition of domain-specific languages, generation of program analysis and transformation tools, production of software renovation tools, and general specification and prototyping. It uses conditional rewrite rules to define the dynamic semantics and other tool-oriented aspects of languages, so the effectiveness of the generated tools is critically dependent on the quality of the rewrite rule implementation. The ASF+SDF rewrite rule compiler generates C code, thus taking advantage of C's portability and the sophisticated optimization capabilities of current C compilers as well as avoiding potential abstract machine interface bottlenecks. It can handle large(10 000+ rule) language definitions and uses an efficient run-time storage scheme capable of handling large (1 000 000+ node) terms. Term storage uses maximal subterm sharing (hash-consing), which turns out to be more effective in the case of ASF+SDF than in Lisp or SML. Extensive benchmarking has shown the time and space performance of the generated code to be as good as or better than that of the best current rewrite rule and functional language compilers.

While application software does the real work, domain-specific languages (DSLs) are tools to help produce it efficiently, and language design assistants in turn are meta-tools to help produce DSLs quickly. DSLs are already in wide use (HTML for web pages, Excel macros for spreadsheet applications, VHDL for hardware design, ...), but many more will be needed for both new as well as existing application domains. Language design assistants to help develop them currently exist only in the basic form of language development systems. After a quick look at domain-specific languages, and especially their relationship to application libraries, we survey existing language development systems and give an outline of future language design assistants.

The ASF+SDF Meta-Environment is an interactive language development environment whose main application areas are definition of domain-specific languages, generation of program analysis and transformation tools, production of software renovation tools, and general specification and prototyping. It uses conditional rewrite rules to define the dynamic semantics and other tool-oriented aspects of languages, so the effectiveness of the generated tools is critically dependent on the quality of the rewrite rule implementation. The ASF+SDF rewrite rule compiler generates C code, thus taking advantage of C's portability and the sophisticated optimization capabilities of current C compilers as well as avoiding potential abstract machine interface bottlenecks. It can handle large(10 000+ rule) language definitions and uses an efficient run-time storage scheme capable of handling large (1 000 000+ node) terms. Term storage uses maximal subterm sharing (hash-consing), which turns out to be more effective in the case of ASF+SDF than in Lisp or SML. Extensive benchmarking has shown the time and space performance of the generated code to be as good as or better than that of the best current rewrite rule and functional language compilers.

By paying more attention to semantics-based tool generation, programming language semantics can significantly increase its impact. Ultimately, this may lead to ``Language Design Assistants'' incorporating substantial amounts of semantic knowledge.

By paying more attention to semantics-based tool generation, programming language semantics can significantly increase its impact. Ultimately, this may lead to ``Language Design Assistants'' incorporating substantial amounts of semantic knowledge.

The abstract mathematical theory of partial differential equations (PDEs) is formulated in terms of manifolds, scalar fields, tensors, and the like, but these algebraic structures are hardly recognizable in actual PDE solvers. The general aim of the Sophus programming style is to bridge the gap between theory and practice in the domain of PDE solvers. Its main ingredients are a library of abstract datatypes corresponding to the algebraic structures used in the mathematical theory and an algebraic expression style similar to the expression style used in the mathematical theory. Because of its emphasis on abstract datatypes, Sophus is most naturally combined with object-oriented languages or other languages supporting abstract datatypes. The resulting source code patterns are beyond the scope of current compiler optimizations, but are sufficiently specific for a dedicated source-to-source optimizer. The limited, domain-specific, character of Sophus is the key to success here. This kind of optimization has been tested on computationally intensive Sophus style code with promising results. The general approach may be useful for other styles and in other application domains as well.

The abstract mathematical theory of partial differential equations (PDEs) is formulated in terms of manifolds, scalar fields, tensors, and the like, but these algebraic structures are hardly recognizable in actual PDE solvers. The general aim of the Sophus programming style is to bridge the gap between theory and practice in the domain of PDE solvers. Its main ingredients are a library of abstract datatypes corresponding to the algebraic structures used in the mathematical theory and an algebraic expression style similar to the expression style used in the mathematical theory. Because of its emphasis on abstract datatypes, Sophus is most naturally combined with object-oriented languages or other languages supporting abstract datatypes. The resulting source code patterns are beyond the scope of current compiler optimizations, but are sufficiently specific for a dedicated source-to-source optimizer. The limited, domain-specific, character of Sophus is the key to success here. This kind of optimization has been tested on computationally intensive Sophus style code with promising results. The general approach may be useful for other styles and in other application domains as well.

A variety of disparate methods have traditionally been used to define the execution semantics of programming languages, to describe partial evaluation, to formalize program analysis as abstract interpretation, and to implement each of these operations in practical systems. We argue here that equational logic can serve to unify each of these aspects of language manipulation.

A variety of disparate methods have traditionally been used to define the execution semantics of programming languages, to describe partial evaluation, to formalize program analysis as abstract interpretation, and to implement each of these operations in practical systems. We argue here that equational logic can serve to unify each of these aspects of language manipulation.

In an earlier paper, one of the present authors presented a preliminary account of an equational logic called PIM. PIM is intended to function as a 'transformational toolkit' to be used by compilers and analysis tools for imperative languages, and has been applied to such problems as program slicing, symbolic evaluation, conditional constant propagation, and dependence analysis. PIM consists of the untyped lambda calculus extended with an algebraic rewriting system that characterizes the behavior of lazy stores and generalized conditionals. A major question left open in the earlier paper was whether there existed a complete equational axiomatization of PIM's semantics. In this paper, we answer this question in the affirmative for PIM's core algebraic component, PIMt, under the assumption of certain reasonable restrictions on term formation. We systematically derive the complete PIM logic as the culmination of a sequence of increasingly powerful equational systems starting from a straightforward 'interpreter' for closed PIM terms.

PIM is an equational logic designed to function as a ``transformational toolkit'' for compilers and other programming tools that analyze and manipulate imperative languages.It has been applied to such problems as program slicing, symbolic evaluation, conditional constant propagation, and dependence analysis.PIM consists of the untyped lambda calculus extended with an algebraic data type that characterizes the behavior of lazy stores and generalized conditionals.A graph form of PIM terms is by design closely related to several intermediate representations commonly used in optimizing compilers. In this paper, we show that PIM's core algebraic component, PIM$_t$, possesses a complete equational axiomatization (under the assumption of certain reasonable restrictions on term formation). This has the practical consequence of guaranteeing that every semantics-preserving transformation on a program representable in PIM$_t$ can be derived by application of PIM$_t$ rules. We systematically derive the complete PIM$_t$ logic as the culmination of a sequence of increasingly powerful equational systems starting from a straightforward ``interpreter'' for closed PIM$_t$ terms. This work is an intermediate step in a larger program to develop a set of well-founded tools for manipulation of imperative programs by compilers and other systems that perform program analysis.

PIM is an equational logic designed to function as a ``transformational toolkit'' for compilers and other programming tools that analyze and manipulate imperative languages.It has been applied to such problems as program slicing, symbolic evaluation, conditional constant propagation, and dependence analysis.PIM consists of the untyped lambda calculus extended with an algebraic data type that characterizes the behavior of lazy stores and generalized conditionals.A graph form of PIM terms is by design closely related to several intermediate representations commonly used in optimizing compilers. In this paper, we show that PIM's core algebraic component, PIM$_t$, possesses a complete equational axiomatization (under the assumption of certain reasonable restrictions on term formation). This has the practical consequence of guaranteeing that every semantics-preserving transformation on a program representable in PIM$_t$ can be derived by application of PIM$_t$ rules. We systematically derive the complete PIM$_t$ logic as the culmination of a sequence of increasingly powerful equational systems starting from a straightforward ``interpreter'' for closed PIM$_t$ terms. This work is an intermediate step in a larger program to develop a set of well-founded tools for manipulation of imperative programs by compilers and other systems that perform program analysis.

In an earlier paper, one of the present authors presented a preliminary account of an equational logic called PIM. PIM is intended to function as a 'transformational toolkit' to be used by compilers and analysis tools for imperative languages, and has been applied to such problems as program slicing, symbolic evaluation, conditional constant propagation, and dependence analysis. PIM consists of the untyped lambda calculus extended with an algebraic rewriting system that characterizes the behavior of lazy stores and generalized conditionals. A major question left open in the earlier paper was whether there existed a complete equational axiomatization of PIM's semantics. In this paper, we answer this question in the affirmative for PIM's core algebraic component, PIMt, under the assumption of certain reasonable restrictions on term formation. We systematically derive the complete PIM logic as the culmination of a sequence of increasingly powerful equational systems starting from a straightforward 'interpreter' for closed PIM terms.