- Email: [email protected]
Language-based software engineering
JID:SCICO AID:1712 /FLA
[m3G; v 1.129; Prn:17/03/2014; 10:13] P.1 (1-4)
Science of Computer Programming ••• (••••) •••–•••
Contents lists available at ScienceDirect
Science of Computer Programming www.elsevier.com/locate/scico
Language-based software engineering Gopal Gupta Department of Computer Science, The University of Texas at Dallas, United States
h i g h l i g h t s • • • •
A language-centric view of software engineering is presented. A software system is a processor of its input language. Success of DSLs depends on rapidly building their implementation infrastructure. Implementation infrastructure can be developed rapidly via logic programming.
a r t i c l e
i n f o
Article history: Received 27 November 2013 Received in revised form 11 February 2014 Accepted 13 February 2014 Available online xxxx Keywords: Domain specific languages Software engineering
a b s t r a c t We present a language-centric view of the software development process. We argue that success of the domain-specific language (DSL) methodology depends on being able to rapidly craft a DSL’s implementation infrastructure. We present logic programming as a rapid way of developing this implementation infrastructure. We also present a languagecentric view of a software system as a processor of its input language. © 2014 Elsevier B.V. All rights reserved.
The three most important things in software development: notation, notation, notation. 1. Introduction Techniques for developing reliable, error free and secure software have been a subject of research for a long time. A number of software engineering methodologies have been proposed, from the waterfall model [16] to aspect oriented methods [8]. In this short paper we present a language-based approach to software engineering. In the language-based software engineering approach the domain experts are the application developers. They program their applications in high level domain-specific languages (DSLs) [10,1,14]. This approach, based on using high level DSLs, may lead to more robust, reliable or secure software. The task of developing a program to solve a specific problem involves two steps. The first step is to devise a solution procedure to solve the problem. This step requires a domain expert to use his/her domain knowledge, expertise, creativity and mental acumen to devise a solution to the problem. The second step is to code the solution in some executable notation (such as a computer programming language) to obtain a program that can then be run on a computer to solve the problem. In the second step the user is required to map the steps of the solution procedure to constructs of the programming language being used for coding. Both steps are cognitively challenging and require considerable amount of thinking and mental activity. The more we can reduce the amount of mental activity involved in both steps (e.g., via automation), the more reliable the process of software construction will be. Not much can be done about the first step as far as reducing the
E-mail address: [email protected]. http://dx.doi.org/10.1016/j.scico.2014.02.010 0167-6423/© 2014 Elsevier B.V. All rights reserved.
JID:SCICO AID:1712 /FLA
2
[m3G; v 1.129; Prn:17/03/2014; 10:13] P.2 (1-4)
G. Gupta / Science of Computer Programming ••• (••••) •••–•••
amount of mental activity is concerned (though significant research is being done in the area of automatic programming and machine learning), however, a lot can be done for the second step. The amount of mental effort the programmer has to invest in the second step depends on the “semantic” gap between the level of abstraction at which the solution procedure has been conceived and the various constructs of the programming language being used. Domain experts usually think at a very high level of abstraction while designing the solution procedures. As a result, the more low-level the programming language, the wider the semantic gap, and the harder the user’s task. In contrast, if we have a language that is right at the level of abstraction at which the user thinks, the task of constructing the program will be much easier. A domain-specific language indeed makes this possible. Note that for any kind of communication (including between programmers/users and the computer) the notation used for the communication determines how effectively and efficiently that communication can be understood and processed. A new, complex notation may take longer time to learn, but if the notation is carefully designed for the task and domain, then it allows far more complex concepts to be expressed and understood considerably more easily. It also encourages creativity, since people now have to simply focus on what to say, rather than on how to say it. This in turn affects productivity of the people (and machines) involved. A prime example of this is the position-based decimal notation for arithmetic, which allows for efficient algorithms for various arithmetic operations (addition, subtraction, multiplication, etc.) to be developed. Imagine developing a method similar to long division for the Roman numeral notation! The importance of notation cannot be overstated for programming. The proliferation of programming languages has come about due to our desire to find the “right” language that will make it easy for programmers to express their algorithms (of course, the choice of algorithm sometimes depends on the notation being used, but here I use the term algorithm in a more general sense, namely, as a method for solving a problem). Since there can be no one perfect notation for all tasks, a plethora of programming languages have been developed, each one optimized for one particular type of use. One could take this proliferation to its logical conclusion and argue that one needs a dedicated (domain-specific) programming language for each type of task and domain. In the DSL-based approach to software engineering, software engineers first design a domain-specific language for the tasks at hand. The implementation of the software system then amounts to implementing a language processor (interpreter/compiler) for this domain-specific language. End-users (who are usually domain experts) then write programs using this domain-specific language. In a similar vain, any software system can be viewed as a language processor. This is because any complex software system can be understood in terms of how a user will interact with it. A user interacts with a software system by providing input data and commands. Thus, to understand a software system, one has to understand the input language used to specify these data and commands. This input language, of course, can be regarded as a domain-specific language. The software system can be thought of as imparting operational semantics to this input language. Thus, the task of developing a complex software system can be thought of as first designing its input language, and then implementing a language processor for this input language. There are a number of advantages to adopting this language-centric approach to software development: (i) issues of usability of the software devolve to how well the input (domain-specific) language has been designed; (ii) software development becomes syntax directed, i.e., the syntax of the input (domain-specific) language largely dictates how the software is developed. (iii) programs can be verified and provably correct machine code can be generated more easily. These are discussed in some more detail next. 2. Implementation infrastructure for domain specific languages With this language-based approach to software engineering comes the problem of having to design the DSL, and once the language is designed, actually realizing the implementation infrastructure of the DSL. Thus, a considerable amount of infrastructure needs to be built before the first program using the DSL can be written and executed. First of all, the DSL should be (manually) designed. The design of the language will require the inputs of both computer scientists and domain experts. Once the DSL has been designed, we need its implementation infrastructure, i.e., a program development environment (an interpreter, a compiler, debuggers, profilers, editors, etc.), to facilitate the development of programs written in this DSL. Observe that the time taken to initially design the DSL is dependent on how rapidly the DSL can be implemented, since the ability to rapidly implement the language allows its designers to quickly experiment with various language constructs and with their various possible semantics. Note also that like any other language, a domain-specific language will evolve as it is used more and more to write programs. Users and language designers gain experience with use of a DSL as more and more programs are written. This inevitably results in language features being modified or added to the DSL. If the DSL changes, then obviously its implementation infrastructure must change as well. The success of the domain-specific language methodology will depend on how rapidly this implementation infrastructure can be modified to reflect the changes in the language. Experience has shown that the time for a domain-specific language to mature can be several years [12]. A significant part of this time is spent developing and modifying the implementation infrastructure as the DSL changes. Clearly, if the implementation infrastructure can be rapidly developed/modified, then the time for the DSL to mature will be reduced, making a DSL-based approach to software engineering viable and practical. With respect to our view of a software system as a language processor of its input language, the software specification phase amounts to designing the software’s input language. The actual implementation of the software system then amounts
JID:SCICO AID:1712 /FLA
[m3G; v 1.129; Prn:17/03/2014; 10:13] P.3 (1-4)
G. Gupta / Science of Computer Programming ••• (••••) •••–•••
3
to developing the implementation infrastructure of the input language. As an example, consider the construction of a command line editor (such as Unix vi) for editing files. The editor commands constitute a language whose semantics is given as a mapping from the input file to the modified file. An implementation of this command language will yield the desired editor. 3. Rapidly prototyping the implementation infrastructure via logic programming The implementation infrastructure of a DSL can be rapidly obtained by using a Horn logical semantics-based approach [4,5]. In the Horn logical semantics approach, both the syntax and semantics of the DSL are specified using Horn clauses [18]. Syntax is expressed using Definite Clause Grammars (DCG) [18], while semantics is denotationally expressed as Horn clauses (the semantic specification maps software’s input to its outputs). Both the syntax and semantics are executable, since they are expressed as Horn clauses. Thus, the DCG specification automatically yields a parser. The semantic specification in effect is a declaratively specified operational semantics, and together with the DCG it automatically yields an interpreter (in other words, a language processor for the DSL). Given a program written in the DSL, the interpreter can be specialized with respect to the program to obtain compiled code [7,4]. Debuggers and profilers can be built by instrumenting the semantic specification [20]. The Horn clause interpreter obtained can also be used to verify and test program properties [11]. With respect to the our view of a software system as a processor of its input language, once the input language is designed, the software system (language processor) itself can be rapidly developed by specifying the (executable) syntax and semantics of the input language. Note that it is not essential that one uses DCGs and declarative operational semantics for obtaining a language processor for the DSL. One could use ‘C’-based implementations, however, these may make take longer to develop compared to the Horn clause approach. Additionally, the other benefits of using the declarative notation of Horn clauses, e.g., being able to verify programs, or automatically obtaining compiled code (so that the code generation process is provably correct), may be difficult to realize. Using a denotational (compositional) approach has the additional advantage that the development of the language processor (and, thus, of the software system) becomes syntax directed. This is because in the denotational approach, there is one semantic rule per syntax (grammar) rule. Additionally, compositionality implies that the semantic rules have to be specified in a way such that the meaning of a syntactic category is given in terms of meaning of its syntactic components. Thus, the Horn logical semantics-based approach provides strong guidance on how the software is developed, making the software development process faster. The main challenge that remains in the software development process is the design of its input language (i.e., its syntax): the implementation is then realized with ease in a syntax-directed manner. 4. Applications The DSL-based approach described in this paper has been used in a number of applications listed below. These applications range from developing programming environments for computational biology, to property verification and provably code generation for safety critical systems. Their details can be found in the cited references. 1. DSLs for solving phylogenetic inference problems in computational biology [15] as well as for programming applications in the supply-chain management domain [13] have been designed; DSLs for programming applications in the health-care domain are being developed. 2. A complete implementation environment for SCR [9], a DSL for designing real-time controllers in avionics systems, has been developed [19] including a provably correct code generator [21]. 3. Software systems for translating notation from one format to another (Nemeth Braille Math code to LATEX, computational biology formats to Nexus, etc.) have been developed [2], as well as for test-scripting languages in commercial use [6]. 4. Verifiers of program properties (including real-time properties) have been developed [3,17]. 5. Conclusions In this paper we present a language-centric view of software engineering. We argue that success of the domain-specific language methodology depends on being able to rapidly craft a DSL’s implementation infrastructure. We present logic programming as a rapid way of developing this implementation infrastructure. We also present a language-centric view of a software system as a processor of its input language. Acknowledgements This paper is dedicated to Paul’s 65th birthday. Paul has made significant contributions to programming language design, implementation, and application. He has also contributed greatly to software engineering through his pioneering work on domain-specific languages. The hallmark of his career has been his focus on practicality of research. Paul has also been a great contributor to the community: he has been instrumental in the set up and nurturing of the European Association for Programming Languages and Systems. Paul is a great inspiration to all of us.
JID:SCICO AID:1712 /FLA
4
[m3G; v 1.129; Prn:17/03/2014; 10:13] P.4 (1-4)
G. Gupta / Science of Computer Programming ••• (••••) •••–•••
I am grateful to Enrico Pontelli, Qian Wang, Hai-Feng Guo and Michael Leuschel for discussions. Support from the Erik Jonsson Endowed Chair is also gratefully acknowledged. A preliminary version of this paper appeared in the Newsletter of the Association for Logic Programming, May 2005. References [1] A. van Deursen, P. Klint, J. Visser, Domain-specific languages: an annotated bibliography, SIGPLAN Not. 35 (6) (2000) 26–36. [2] G. Gupta, H.-F. Guo, A. Karshmer, E. Pontelli, et al., Semantic-based filtering: logic programming’s killer app?, in: 4th International Symposium on Practical Aspects of Declarative Languages, in: LNCS, vol. 2257, Springer Verlag, Jan. 2002, pp. 82–100. [3] G. Gupta, E. Pontelli, A constraint-based approach to specification and verification of real-time systems, in: Proc. IEEE Real-Time Symposium, San Francisco, Dec. 1997, pp. 230–239. [4] G. Gupta, Horn logic denotations and their applications, in: The Logic Programming Paradigm: The Next 25 Years, Springer Verlag, May 1999, pp. 127–160. [5] G. Gupta, E. Pontelli, Specification, implementation, and verification of domain specific languages: a logic programming-based approach, in: Advances in Logic Programming: Essays in Honor of 60th Birthday of Robert Kowalski, in: Lecture Notes in AI, vol. 2407, Springer Verlag, 2002, pp. 211–239. [6] Interoperate, Inc. WR2QTP: semantic translator of WinRunner scripts to QTP, White paper http://interoperate.biz.Interoperate_WhitePaper.pdf, 2011. [7] N. Jones, Introduction to partial evaluation, ACM Computing Surveys 28 (3) (1996) 480–503. [8] G. Kiczales, et al., Aspect-Oriented Programming (AOP), ACM Comput. Surv. 28A (4) (December 1996). [9] J. Kirby, M. Archer, C.L. Heitmeyer, SCR: A practical approach to building a high assurance COMSEC system, in: Proceedings of ACSAC, 1999, pp. 109–118. [10] P. Klint, T. van der Storm, J.J. Vinju, On the impact of DSL tools on the maintainability of language implementations, in: LDTA, 2010, Article 10. [11] M. Leuschel, A. Podelski, C.R. Ramakrishnan, U. Ultes-Nitsche, Special issue on verification and computational logic, TPLP 4 (5–6) (2004) 543–544. [12] N.G. Leveson, M.P.E. Heimdahl, J.D. Reese, Designing specification languages for process control systems: lessons learned and steps to the future, in: Software Engineering – ESEC/FSE, Springer Verlag, 1999, pp. 127–145. [13] K. Marple, N. Saeedloei, J. Fu, F. Bastani, G. Gupta, I. Yen, V. Chong, A. Mukherjee, A domain specific language for inventory management, Technical report, The University of Texas at Dallas, 2008. [14] M. Mernik, J. Heering, A.M. Sloane, When and how to develop domain-specific languages, ACM Comput. Surv. 37 (4) (2005) 316–344. [15] E. Pontelli, D. Ranjan, G. Gupta, B. Milligan, Design and implementation of a domain specific language for phylogenetic inference, J. Bioinform. Comput. Biol. 1 (2) (2003) 201–230. [16] W. Royce, Managing the development of large software systems, in: Proc. IEEE WESCON, August 1970, pp. 1–9. [17] N. Saeedloei, G. Gupta, Logic-based modeling and verification of cyberphysical systems, SIGBED Rev. 8 (2) (2011) 31–34. [18] L. Sterling, E. Shapiro, The Art of Prolog, 2nd edition, MIT Press, 1994. [19] Qian Wang, Gopal Gupta, Provably correct code generation: a case study, in: Electronic Notes in Theoretical Computer Science, vol. 118, 2005, pp. 87–109. [20] Qian Wang, G. Gupta, Rapidly prototyping implementation infrastructure of domain specific languages: a semantics-based approach, in: ACM Symposium on Applied Computing, ACM Press, Mar. 2005. [21] Qian Wang, G. Gupta, M. Leuschel, Towards provably correct code generation via Horn logical continuation semantics, in: Proc. International Conf. on Practical Aspects of Declarative Languages, 2005, Springer Verlag, 2005, pp. 98–112.
[m3G; v 1.129; Prn:17/03/2014; 10:13] P.1 (1-4)
Science of Computer Programming ••• (••••) •••–•••
Contents lists available at ScienceDirect
Science of Computer Programming www.elsevier.com/locate/scico
Language-based software engineering Gopal Gupta Department of Computer Science, The University of Texas at Dallas, United States
h i g h l i g h t s • • • •
A language-centric view of software engineering is presented. A software system is a processor of its input language. Success of DSLs depends on rapidly building their implementation infrastructure. Implementation infrastructure can be developed rapidly via logic programming.
a r t i c l e
i n f o
Article history: Received 27 November 2013 Received in revised form 11 February 2014 Accepted 13 February 2014 Available online xxxx Keywords: Domain specific languages Software engineering
a b s t r a c t We present a language-centric view of the software development process. We argue that success of the domain-specific language (DSL) methodology depends on being able to rapidly craft a DSL’s implementation infrastructure. We present logic programming as a rapid way of developing this implementation infrastructure. We also present a languagecentric view of a software system as a processor of its input language. © 2014 Elsevier B.V. All rights reserved.
The three most important things in software development: notation, notation, notation. 1. Introduction Techniques for developing reliable, error free and secure software have been a subject of research for a long time. A number of software engineering methodologies have been proposed, from the waterfall model [16] to aspect oriented methods [8]. In this short paper we present a language-based approach to software engineering. In the language-based software engineering approach the domain experts are the application developers. They program their applications in high level domain-specific languages (DSLs) [10,1,14]. This approach, based on using high level DSLs, may lead to more robust, reliable or secure software. The task of developing a program to solve a specific problem involves two steps. The first step is to devise a solution procedure to solve the problem. This step requires a domain expert to use his/her domain knowledge, expertise, creativity and mental acumen to devise a solution to the problem. The second step is to code the solution in some executable notation (such as a computer programming language) to obtain a program that can then be run on a computer to solve the problem. In the second step the user is required to map the steps of the solution procedure to constructs of the programming language being used for coding. Both steps are cognitively challenging and require considerable amount of thinking and mental activity. The more we can reduce the amount of mental activity involved in both steps (e.g., via automation), the more reliable the process of software construction will be. Not much can be done about the first step as far as reducing the
E-mail address: [email protected]. http://dx.doi.org/10.1016/j.scico.2014.02.010 0167-6423/© 2014 Elsevier B.V. All rights reserved.
JID:SCICO AID:1712 /FLA
2
[m3G; v 1.129; Prn:17/03/2014; 10:13] P.2 (1-4)
G. Gupta / Science of Computer Programming ••• (••••) •••–•••
amount of mental activity is concerned (though significant research is being done in the area of automatic programming and machine learning), however, a lot can be done for the second step. The amount of mental effort the programmer has to invest in the second step depends on the “semantic” gap between the level of abstraction at which the solution procedure has been conceived and the various constructs of the programming language being used. Domain experts usually think at a very high level of abstraction while designing the solution procedures. As a result, the more low-level the programming language, the wider the semantic gap, and the harder the user’s task. In contrast, if we have a language that is right at the level of abstraction at which the user thinks, the task of constructing the program will be much easier. A domain-specific language indeed makes this possible. Note that for any kind of communication (including between programmers/users and the computer) the notation used for the communication determines how effectively and efficiently that communication can be understood and processed. A new, complex notation may take longer time to learn, but if the notation is carefully designed for the task and domain, then it allows far more complex concepts to be expressed and understood considerably more easily. It also encourages creativity, since people now have to simply focus on what to say, rather than on how to say it. This in turn affects productivity of the people (and machines) involved. A prime example of this is the position-based decimal notation for arithmetic, which allows for efficient algorithms for various arithmetic operations (addition, subtraction, multiplication, etc.) to be developed. Imagine developing a method similar to long division for the Roman numeral notation! The importance of notation cannot be overstated for programming. The proliferation of programming languages has come about due to our desire to find the “right” language that will make it easy for programmers to express their algorithms (of course, the choice of algorithm sometimes depends on the notation being used, but here I use the term algorithm in a more general sense, namely, as a method for solving a problem). Since there can be no one perfect notation for all tasks, a plethora of programming languages have been developed, each one optimized for one particular type of use. One could take this proliferation to its logical conclusion and argue that one needs a dedicated (domain-specific) programming language for each type of task and domain. In the DSL-based approach to software engineering, software engineers first design a domain-specific language for the tasks at hand. The implementation of the software system then amounts to implementing a language processor (interpreter/compiler) for this domain-specific language. End-users (who are usually domain experts) then write programs using this domain-specific language. In a similar vain, any software system can be viewed as a language processor. This is because any complex software system can be understood in terms of how a user will interact with it. A user interacts with a software system by providing input data and commands. Thus, to understand a software system, one has to understand the input language used to specify these data and commands. This input language, of course, can be regarded as a domain-specific language. The software system can be thought of as imparting operational semantics to this input language. Thus, the task of developing a complex software system can be thought of as first designing its input language, and then implementing a language processor for this input language. There are a number of advantages to adopting this language-centric approach to software development: (i) issues of usability of the software devolve to how well the input (domain-specific) language has been designed; (ii) software development becomes syntax directed, i.e., the syntax of the input (domain-specific) language largely dictates how the software is developed. (iii) programs can be verified and provably correct machine code can be generated more easily. These are discussed in some more detail next. 2. Implementation infrastructure for domain specific languages With this language-based approach to software engineering comes the problem of having to design the DSL, and once the language is designed, actually realizing the implementation infrastructure of the DSL. Thus, a considerable amount of infrastructure needs to be built before the first program using the DSL can be written and executed. First of all, the DSL should be (manually) designed. The design of the language will require the inputs of both computer scientists and domain experts. Once the DSL has been designed, we need its implementation infrastructure, i.e., a program development environment (an interpreter, a compiler, debuggers, profilers, editors, etc.), to facilitate the development of programs written in this DSL. Observe that the time taken to initially design the DSL is dependent on how rapidly the DSL can be implemented, since the ability to rapidly implement the language allows its designers to quickly experiment with various language constructs and with their various possible semantics. Note also that like any other language, a domain-specific language will evolve as it is used more and more to write programs. Users and language designers gain experience with use of a DSL as more and more programs are written. This inevitably results in language features being modified or added to the DSL. If the DSL changes, then obviously its implementation infrastructure must change as well. The success of the domain-specific language methodology will depend on how rapidly this implementation infrastructure can be modified to reflect the changes in the language. Experience has shown that the time for a domain-specific language to mature can be several years [12]. A significant part of this time is spent developing and modifying the implementation infrastructure as the DSL changes. Clearly, if the implementation infrastructure can be rapidly developed/modified, then the time for the DSL to mature will be reduced, making a DSL-based approach to software engineering viable and practical. With respect to our view of a software system as a language processor of its input language, the software specification phase amounts to designing the software’s input language. The actual implementation of the software system then amounts
JID:SCICO AID:1712 /FLA
[m3G; v 1.129; Prn:17/03/2014; 10:13] P.3 (1-4)
G. Gupta / Science of Computer Programming ••• (••••) •••–•••
3
to developing the implementation infrastructure of the input language. As an example, consider the construction of a command line editor (such as Unix vi) for editing files. The editor commands constitute a language whose semantics is given as a mapping from the input file to the modified file. An implementation of this command language will yield the desired editor. 3. Rapidly prototyping the implementation infrastructure via logic programming The implementation infrastructure of a DSL can be rapidly obtained by using a Horn logical semantics-based approach [4,5]. In the Horn logical semantics approach, both the syntax and semantics of the DSL are specified using Horn clauses [18]. Syntax is expressed using Definite Clause Grammars (DCG) [18], while semantics is denotationally expressed as Horn clauses (the semantic specification maps software’s input to its outputs). Both the syntax and semantics are executable, since they are expressed as Horn clauses. Thus, the DCG specification automatically yields a parser. The semantic specification in effect is a declaratively specified operational semantics, and together with the DCG it automatically yields an interpreter (in other words, a language processor for the DSL). Given a program written in the DSL, the interpreter can be specialized with respect to the program to obtain compiled code [7,4]. Debuggers and profilers can be built by instrumenting the semantic specification [20]. The Horn clause interpreter obtained can also be used to verify and test program properties [11]. With respect to the our view of a software system as a processor of its input language, once the input language is designed, the software system (language processor) itself can be rapidly developed by specifying the (executable) syntax and semantics of the input language. Note that it is not essential that one uses DCGs and declarative operational semantics for obtaining a language processor for the DSL. One could use ‘C’-based implementations, however, these may make take longer to develop compared to the Horn clause approach. Additionally, the other benefits of using the declarative notation of Horn clauses, e.g., being able to verify programs, or automatically obtaining compiled code (so that the code generation process is provably correct), may be difficult to realize. Using a denotational (compositional) approach has the additional advantage that the development of the language processor (and, thus, of the software system) becomes syntax directed. This is because in the denotational approach, there is one semantic rule per syntax (grammar) rule. Additionally, compositionality implies that the semantic rules have to be specified in a way such that the meaning of a syntactic category is given in terms of meaning of its syntactic components. Thus, the Horn logical semantics-based approach provides strong guidance on how the software is developed, making the software development process faster. The main challenge that remains in the software development process is the design of its input language (i.e., its syntax): the implementation is then realized with ease in a syntax-directed manner. 4. Applications The DSL-based approach described in this paper has been used in a number of applications listed below. These applications range from developing programming environments for computational biology, to property verification and provably code generation for safety critical systems. Their details can be found in the cited references. 1. DSLs for solving phylogenetic inference problems in computational biology [15] as well as for programming applications in the supply-chain management domain [13] have been designed; DSLs for programming applications in the health-care domain are being developed. 2. A complete implementation environment for SCR [9], a DSL for designing real-time controllers in avionics systems, has been developed [19] including a provably correct code generator [21]. 3. Software systems for translating notation from one format to another (Nemeth Braille Math code to LATEX, computational biology formats to Nexus, etc.) have been developed [2], as well as for test-scripting languages in commercial use [6]. 4. Verifiers of program properties (including real-time properties) have been developed [3,17]. 5. Conclusions In this paper we present a language-centric view of software engineering. We argue that success of the domain-specific language methodology depends on being able to rapidly craft a DSL’s implementation infrastructure. We present logic programming as a rapid way of developing this implementation infrastructure. We also present a language-centric view of a software system as a processor of its input language. Acknowledgements This paper is dedicated to Paul’s 65th birthday. Paul has made significant contributions to programming language design, implementation, and application. He has also contributed greatly to software engineering through his pioneering work on domain-specific languages. The hallmark of his career has been his focus on practicality of research. Paul has also been a great contributor to the community: he has been instrumental in the set up and nurturing of the European Association for Programming Languages and Systems. Paul is a great inspiration to all of us.
JID:SCICO AID:1712 /FLA
4
[m3G; v 1.129; Prn:17/03/2014; 10:13] P.4 (1-4)
G. Gupta / Science of Computer Programming ••• (••••) •••–•••
I am grateful to Enrico Pontelli, Qian Wang, Hai-Feng Guo and Michael Leuschel for discussions. Support from the Erik Jonsson Endowed Chair is also gratefully acknowledged. A preliminary version of this paper appeared in the Newsletter of the Association for Logic Programming, May 2005. References [1] A. van Deursen, P. Klint, J. Visser, Domain-specific languages: an annotated bibliography, SIGPLAN Not. 35 (6) (2000) 26–36. [2] G. Gupta, H.-F. Guo, A. Karshmer, E. Pontelli, et al., Semantic-based filtering: logic programming’s killer app?, in: 4th International Symposium on Practical Aspects of Declarative Languages, in: LNCS, vol. 2257, Springer Verlag, Jan. 2002, pp. 82–100. [3] G. Gupta, E. Pontelli, A constraint-based approach to specification and verification of real-time systems, in: Proc. IEEE Real-Time Symposium, San Francisco, Dec. 1997, pp. 230–239. [4] G. Gupta, Horn logic denotations and their applications, in: The Logic Programming Paradigm: The Next 25 Years, Springer Verlag, May 1999, pp. 127–160. [5] G. Gupta, E. Pontelli, Specification, implementation, and verification of domain specific languages: a logic programming-based approach, in: Advances in Logic Programming: Essays in Honor of 60th Birthday of Robert Kowalski, in: Lecture Notes in AI, vol. 2407, Springer Verlag, 2002, pp. 211–239. [6] Interoperate, Inc. WR2QTP: semantic translator of WinRunner scripts to QTP, White paper http://interoperate.biz.Interoperate_WhitePaper.pdf, 2011. [7] N. Jones, Introduction to partial evaluation, ACM Computing Surveys 28 (3) (1996) 480–503. [8] G. Kiczales, et al., Aspect-Oriented Programming (AOP), ACM Comput. Surv. 28A (4) (December 1996). [9] J. Kirby, M. Archer, C.L. Heitmeyer, SCR: A practical approach to building a high assurance COMSEC system, in: Proceedings of ACSAC, 1999, pp. 109–118. [10] P. Klint, T. van der Storm, J.J. Vinju, On the impact of DSL tools on the maintainability of language implementations, in: LDTA, 2010, Article 10. [11] M. Leuschel, A. Podelski, C.R. Ramakrishnan, U. Ultes-Nitsche, Special issue on verification and computational logic, TPLP 4 (5–6) (2004) 543–544. [12] N.G. Leveson, M.P.E. Heimdahl, J.D. Reese, Designing specification languages for process control systems: lessons learned and steps to the future, in: Software Engineering – ESEC/FSE, Springer Verlag, 1999, pp. 127–145. [13] K. Marple, N. Saeedloei, J. Fu, F. Bastani, G. Gupta, I. Yen, V. Chong, A. Mukherjee, A domain specific language for inventory management, Technical report, The University of Texas at Dallas, 2008. [14] M. Mernik, J. Heering, A.M. Sloane, When and how to develop domain-specific languages, ACM Comput. Surv. 37 (4) (2005) 316–344. [15] E. Pontelli, D. Ranjan, G. Gupta, B. Milligan, Design and implementation of a domain specific language for phylogenetic inference, J. Bioinform. Comput. Biol. 1 (2) (2003) 201–230. [16] W. Royce, Managing the development of large software systems, in: Proc. IEEE WESCON, August 1970, pp. 1–9. [17] N. Saeedloei, G. Gupta, Logic-based modeling and verification of cyberphysical systems, SIGBED Rev. 8 (2) (2011) 31–34. [18] L. Sterling, E. Shapiro, The Art of Prolog, 2nd edition, MIT Press, 1994. [19] Qian Wang, Gopal Gupta, Provably correct code generation: a case study, in: Electronic Notes in Theoretical Computer Science, vol. 118, 2005, pp. 87–109. [20] Qian Wang, G. Gupta, Rapidly prototyping implementation infrastructure of domain specific languages: a semantics-based approach, in: ACM Symposium on Applied Computing, ACM Press, Mar. 2005. [21] Qian Wang, G. Gupta, M. Leuschel, Towards provably correct code generation via Horn logical continuation semantics, in: Proc. International Conf. on Practical Aspects of Declarative Languages, 2005, Springer Verlag, 2005, pp. 98–112.