DOCSLIB.ORG

Contracts Be Misunderstood (Functional Pearl)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Contracts Be Misunderstood (Functional Pearl) Oh Lord, Please Don’t Let Contracts Be Misunderstood (Functional Pearl) Christos Dimoulas, Max S. New, Robert Bruce Findler, Matthias Felleisen PLT, USA {chrdimo,maxsnew,robby,matthias}@racket-lang.org Abstract gramming language to not only express logical assertions about Contracts feel misunderstood, especially those with a higher-order their functions but also construct new forms of contracts with soul. While software engineers appreciate contracts as tools for ar- user-defined combinators. Especially in the context of languages ticulating the interface between components, functional program- that shout “domain specific languages” from every roof top—say mers desperately search for their types and meaning, completely Racket—researchers and developers ought to be able to eliminate the problems that plague sophisticated practical applications of forgetting about their pragmatics. 1 This gem presents a novel analysis of contract systems. Applied conventional contract systems. If they put their mind to it, they to the higher-order kind, this analysis reveals their large and clearly could construct linguistic mechanisms that raised the level of ex- unappreciated software engineering potential. Three sample appli- pressiveness and allowed programmers to articulate an unprece- cations illustrate where this kind of exploration may lead. dented detail of precision for a relatively low cost in terms of code. This gem demonstrates how this alternative mind set about con- Categories and Subject Descriptors D.3.3 [Programming Lan- tracts opens new possibilities. It starts with a novel conceptual guages]: Language Constructs and Features analysis of contracts, re-imagining them as an interlocking sys- tem of interposition points, linguistic constructs for contract attach- Keywords Contracts, Specifications, Language design ment, and DSLs for assembling logical assertions from rather sim- ple building blocks (section 2). This abstract analysis is illustrated 1. Contracts, “always left out, never fit in” with three distinct examples of formulating contracts for libraries Design by Contract [44] is a beautiful idea. Programmers articu- and components (section 3). These examples seemingly expand the late behavioral contracts and then the methods design themselves. convex hull of what behavioral software contracts can talk about, Implicitly, Meyer claims that this idea scales from small pieces of though they really just demonstrate untapped potential. Equipped code to large software systems. with these examples, the gem finally (section 4) describes the re- Beugnard et al. [6] confirm this claim with their survey on lationship between contracts and type systems, on one hand, and the lasting impact of contracts in their study of component-based run-time verification on the other. In short, the three of them form software, software adaptation, service oriented architectures, real- a triangle of complementary techniques for helping programmers time and high-performance computing. Contracts have also become with the difficult task of specifying interfaces. instrumental in the design of web-based systems to embedded Racket [27] is our language of choice to explain these ideas. It software. In these settings, contracts express and enforce a wide advertises itself as a tool for making DSLs, and it has been used range of component specifications; from basic null-pointer checks extensively to study contracts. Specifically, Racket comes with a to coordination protocols and quality of service statements. Sadly, triple of superlatives: our father’s parentheses, elegant weapons these achievements get only minimal support from mainstream for a more civilized way of delivering gems; the world’s most so- programming languages; most provide little more than constructs phisticated higher-order contract system [27, §8], and the galaxy’s for adding pre-conditions or post-conditions. To compensate for the best mechanism for formulating DSLs [27, §12]. None of the ideas lack of support from these conventional contract systems, software are Racket-specific, though, and with a sufficient amount of extra- engineers employ a mixture of ad hoc solutions, invent contract ordinary labor, Haskellians and Camelists can articulate the same design patterns, and rely on half-baked IDE support. ideas in the context of their villages. The introduction of contracts into higher-order functional lan- guages [22] offers a solution to these linguistic problems. In a higher-order world, contracts naturally become first-class citi- 2. “You hold the answers deep within your mind” zens, too. As a result, functional programmers may use their pro- Programming language research has struggled with the concept of “meaning” for nearly five decades. Back in 1968, James Morris [47, p. 9] re-phrased the philosopher C. W. Morris to define this key concept via a trichotomy as follows: Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation 1. Syntax delineates the legal forms, or utterances, of a on the first page. Copyrights for components of this work owned by others than ACM language. must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. 1 After the introduction of higher-order contracts, many researchers— ,. including three of the authors—spent valuable time on exploring their se- Copyright © ACM [to be supplied]. $15.00. mantics and their shallow use in the context of gradual typing systems. The http://dx.doi.org/10.1145/ title refers to vast number of these efforts. 2. Semantics treats with the relation between the forms, or values can implement interposition for an expressive set of con- expressions, in the language and the objects they denote. tracts, they are inadequate for others. Consider function contracts 3. Pragmatics treats with the relation between a language that describe temporal protocols. Realizing such a contract relies on and its users (human or mechanical). detecting calls to captured functions during the extent of a call to a closure. Such contracts require an interposition layer that intercepts We argue that from a strictly operational point of view, extensional events as well as intensional ones. Current approaches semantics are unnecessary. To specify a language, we need to obtain these intensional events fall back on aspect-oriented pro- only give its syntax and pragmatics. gramming [51] or code re-writing techniques [35]. Strangely enough, Morris then jumps to the conclusion that “[the] 2.2 The Language of Contracts, the Single pragmatics are most easily specified by how a machine ... will react when presented with a legal form of the language,” completely Eiffel-inspired contract systems allow programmers to articulate ignoring how a human relates to such legal forms. contracts with the constructs of the underlying programming lan- Ever since, efforts to give meaning mostly fall into one of two guage. Indeed, in a simplistic contract system, contracts are merely categories: denotational or operational. In the context of contracts, Boolean expressions over function (method) parameters, local vari- the first draws inspiration from type theory and deals well with ables (fields), and function results. Some contract systems inject @ type-like contracts [7, 23, 31]. The second category, due to Find- and D quantifiers, though because their universes are finite, pro- ler and Felleisen [22], opts for an operational method that speci- grammers consider them alternative names for definable functions. fies how checking contracts involves decomposing a contract into At first glance, Racket’s contract system extends this vocabulary its “atomic” constituents, which can be checked against flat val- with notations that mirror its nature as a higher-order functional ues. Both approaches have significant limitations. The first fails language. For example, to describe the behavior of contract systems with sufficient pre- (-> natural-number/c prime?) cision [13] or to scale to dependent higher-order contracts [20, 23]. The second covers the entire range of contracts but obscures the may specify a contract for a function that maps natural numbers actual workings of the contract system to such an extent that pro- to prime numbers. Restricting the domain even further can be grammers fail to perceive the full expressive power of contracts. accomplished with the and/c combinator: This section instead presents a conceptual analysis of contracts, (->(and/c natural-number/c(between/c0 10)) pulling together various strands of research on Racket’s contract (listof prime?)) system. From this perspective, a contract system consists of three parts: an interposition layer; a contract attachment mechanism; and The range of this function contract says that a list of prime num- a suite of contract combinators. The first controls which aspects of bers is expected. A programmer can specify a dependency among a program’s execution a contract system may monitor. The second several parameters and the result with the ->i notation. Here is an specifies the means for associating a contract with (the result of) an illustrative example: expression and its context. The value of the expression is dubbed (->i([s string?] the carrier of a contract, while the context
Load more

Recommended publications
  • Introduction to Programming in Lisp
    Introduction to Programming in Lisp Supplementary handout for 4th Year AI lectures · D W Murray · Hilary 1991 1 Background There are two widely used languages for AI, viz. Lisp and Prolog. The latter is the language for Logic Programming, but much of the remainder of the work is programmed in Lisp. Lisp is the general language for AI because it allows us to manipulate symbols and ideas in a commonsense manner. Lisp is an acronym for List Processing, a reference to the basic syntax of the language and aim of the language. The earliest list processing language was in fact IPL developed in the mid 1950’s by Simon, Newell and Shaw. Lisp itself was conceived by John McCarthy and students in the late 1950’s for use in the newly-named field of artificial intelligence. It caught on quickly in MIT’s AI Project, was implemented on the IBM 704 and by 1962 to spread through other AI groups. AI is still the largest application area for the language, but the removal of many of the flaws of early versions of the language have resulted in its gaining somewhat wider acceptance. One snag with Lisp is that although it started out as a very pure language based on mathematic logic, practical pressures mean that it has grown. There were many dialects which threaten the unity of the language, but recently there was a concerted effort to develop a more standard Lisp, viz. Common Lisp. Other Lisps you may hear of are FranzLisp, MacLisp, InterLisp, Cambridge Lisp, Le Lisp, ... Some good things about Lisp are: • Lisp is an early example of an interpreted language (though it can be compiled).
    [Show full text]
  • PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63P
    DOCUMENT RESUME ED 290 438 IR 012 986 AUTHOR Cunningham, Robert E.; And Others TITLE Chips: A Tool for Developing Software Interfaces Interactively. INSTITUTION Pittsburgh Univ., Pa. Learning Research and Development Center. SPANS AGENCY Office of Naval Research, Arlington, Va. REPORT NO TR-LEP-4 PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63p. PUB TYPE Reports - Research/Technical (143) EDRS PRICE MF01/PC03 Plus Postage. DESCRIPTORS *Computer Graphics; *Man Machine Systems; Menu Driven Software; Programing; *Programing Languages IDENTIF7ERS Direct Manipulation Interface' Interface Design Theory; *Learning Research and Development Center; LISP Programing Language; Object Oriented Programing ABSTRACT This report provides a detailed description of Chips, an interactive tool for developing software employing graphical/computer interfaces on Xerox Lisp machines. It is noted that Chips, which is implemented as a collection of customizable classes, provides the programmer with a rich graphical interface for the creation of rich graphical interfaces, and the end-user with classes for modeling the graphical relationships of objects on the screen and maintaining constraints between them. This description of the system is divided into five main sections: () the introduction, which provides background material and a general description of the system; (2) a brief overview of the report; (3) detailed explanations of the major features of Chips;(4) an in-depth discussion of the interactive aspects of the Chips development environment; and (5) an example session using Chips to develop and modify a small portion of an interface. Appended materials include descriptions of four programming techniques that have been sound useful in the development of Chips; descriptions of several systems developed at the Learning Research and Development Centel tsing Chips; and a glossary of key terms used in the report.
    [Show full text]
  • Allegro CL User Guide
    Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format
    [Show full text]
  • S Allegro Common Lisp Foreign Function Interface
    Please do not remove this page Extensions to the Franz, Inc.'s Allegro Common Lisp foreign function interface Keane, John https://scholarship.libraries.rutgers.edu/discovery/delivery/01RUT_INST:ResearchRepository/12643408560004646?l#13643533500004646 Keane, J. (1996). Extensions to the Franz, Inc.’s Allegro Common Lisp foreign function interface. Rutgers University. https://doi.org/10.7282/t3-pqns-7h57 This work is protected by copyright. You are free to use this resource, with proper attribution, for research and educational purposes. Other uses, such as reproduction or publication, may require the permission of the copyright holder. Downloaded On 2021/09/29 22:58:32 -0400 Extensions to the Franz Incs Allegro Common Lisp Foreign Function Interface John Keane Department of Computer Science Rutgers University New Brunswick NJ keanecsrutgersedu January Abstract As provided by Franz Inc the foreign function interface of Allegro Com mon Lisp has a number of limitations This pap er describ es extensions to the interface that facilitate the inclusion of C and Fortran co de into Common Lisp systems In particular these extensions make it easy to utilize libraries of numerical subroutines such as those from Numerical Recip es in C from within ACL including those routines that take functions as arguments A mechanism for creating Lisplike dynamic runtime closures for C routines is also describ ed Acknowledgments The research presented in this do cument is supp orted in part by NASA grants NCC and NAG This research is also part of the Rutgers based
    [Show full text]
  • Rash: from Reckless Interactions to Reliable Programs
    Rash: From Reckless Interactions to Reliable Programs William Gallard Hatch Matthew Flatt University of Utah University of Utah USA USA [email protected] [email protected] Abstract them along a spectrum of program maturity and scale. Mov- Command languages like the Bourne Shell provide a terse ing code along this scale is often viewed as a transition from syntax for exploratory programming and system interaction. “scripts” to more mature “programs,” and current research Shell users can begin to write programs that automate their aims to improve that transition, especially through grad- tasks by simply copying their interactions verbatim into a ual typing [18, 20]. In this paper, we address a point in the script file. However, command languages usually scale poorly spectrum that precedes even the “script” level of maturity: beyond small scripts, and they can be difficult to integrate command sequences in an interactive shell. into larger programs. General-purpose languages scale well, Different features and aspects of programming languages but are verbose and unwieldy for common interactive actions are well suited to different stages of program maturity. For such as process composition. example, static types are clearly useful for ensuring and We present Rash, a domain-specific command language maintaining software correctness, but types are often seen embedded in Racket. Rash provides a terse and extensible as burdensome or obstructive when writing scripts, so many syntax for interactive system administration and scripting, scripting languages eschew types. Programmers want brevity as well as easy composition of both Racket functions and and even less formality in interactive settings, so read-eval- operating system processes.
    [Show full text]
  • A Reader Framework for Guile for Guile-Reader 0.6.2
    A Reader Framework for Guile for Guile-Reader 0.6.2 Ludovic Court`es Edition 0.6.2 8 March 2017 This file documents Guile-Reader. Copyright c 2005, 2006, 2007, 2008, 2009, 2012, 2015, 2017 Ludovic Court`es Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the con- ditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. i Table of Contents A Reader Framework for Guile ................ 1 1 Introduction............................... 3 2 Overview .................................. 5 3 Quick Start................................ 7 4 API Reference............................. 9 4.1 Token Readers .............................................. 9 4.1.1 Defining a New Token Reader............................ 9 4.1.2 Token Reader Calling Convention ........................ 9 4.1.3 Invoking a Reader from a Token Reader ................. 10 4.1.4 Token Reader Library .................................. 11 4.1.5 Limitations............................................ 16 4.1.5.1 Token Delimiters .................................
    [Show full text]
  • A Quick Introduction to Common Lisp
    CSC 244/444 Notes last updated Feb 3, 2020 A Quick Introduction to Common Lisp Lisp is a functional language well-suited to sym- bolic AI, based on the λ-calculus and with list structures as a very flexible basic data type; pro- grams are themselves list structures, and thus can be created and manipulated just like other data. This introduction isn't intended to give you all the details, but just enough to get across the essential ideas, and to let you get under way quickly. The best way to make use of it is in front of a computer, trying out all the things mentioned. Basic characteristics of Lisp and Common Lisp: • Lisp is primarily intended for manipulating symbolic data in the form of list struc- tures, e.g., (THREE (BLIND MICE) SEE (HOW (THEY RUN)) !) • Arithmetic is included, e.g., (SQRT (+ (* 3 3) (* 4 4))) or (sqrt (+ (* 3 3) (* 4 4))) (Common Lisp is case-insensitive, except in strings between quotes " ... ", specially delimited symbols like |Very Unusual Symbol!|, and for characters prefixed with \\"). • Common Lisp (unlike John McCarthy's original \pure" Lisp) has arrays and record structures; this leads to more understandable and efficient code, much as in typed languages, but there is no obligatory typing. • All computation consists of expression evaluation. For instance, typing in the above (SQRT ...) expression and hitting the enter key immediately gives 5. • Lisp is a functional language based on Alonzo Church's λ-calculus (which like Turing machines provides a complete basis for all computable functions). For instance, a function for the square root of the sum of two squares can be expressed as (lambda (x y) (sqrt (+ (* x x) (* y y)))).
    [Show full text]
  • Foreign-Function Interfaces for Garbage-Collected Programming Languages
    Foreign-Function Interfaces for Garbage-Collected Programming Languages Marcus Crestani Eberhard-Karls-Universitat¨ Tubingen¨ [email protected] Abstract Programs in high-level, garbage-collected programming languages often need to access libraries that are written in other programming languages. A foreign-function interface provides a high-level lan- guage with access to low-level programming languages and negoti- ates between the inside and the outside world by taking care of the High-Level Foreign low-level details. In this paper, I provide an overview of what differ- Programming Function External Code ent kinds of foreign-function interfaces are in use in today’s imple- Language Interface mentations of functional programming languages to help decide on the design of a new foreign-function interface for Scheme 48. I have revised several mechanisms and design ideas and compared them on usability, portability, memory consumption and thread safety. I discuss the garbage-collection related parts of foreign-function in- terfaces using Scheme as the high-level functional language and C as the external language. Figure 1. Foreign-function interface 1. Introduction Programs in functional programming languages often need to ac- This paper reflects my survey, summarizes the results, and presents cess libraries that are written in other programming languages. Scheme 48’s new foreign-function interface, which will replace the Back in 1996, Scheme 48 [10] received its first foreign-function current one in the near future. interface. Over the years, developers connected many external li- braries to Scheme 48 using this foreign-function interface. Many 1.1 Foreign-Function Interfaces other Scheme implementations use a similar foreign-function in- A foreign-function interface provides a high-level programming terface, for example Elk [12], scsh [18], and PLT Scheme’s static language with access to other (usually low-level) programming lan- foreign interface [6].
    [Show full text]
  • Parallel Programming with Lisp for Performance
    Parallel Programming with Lisp for Performance Pascal Costanza, Intel, Belgium European Lisp Symposium 2014, Paris, France The views expressed are my own, and not those of my employer. Legal Notices • Cilk, Intel, the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries. Other names and brands may be claimed as the property of others. Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. Intel does not control or audit the design or implementation of third party benchmark data or Web sites referenced in this document. Intel encourages all of its customers to visit the referenced Web sites or others where similar performance benchmark data are reported and confirm whether the referenced benchmark data are accurate and reflect performance of systems available for purchase. • Optimization Notice: Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instructions sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. (Notice revision #20110804) • Copyright © 2014 Intel Corporation.
    [Show full text]
  • Common Lisp Quick Reference
    Common Lisp Quick Reference Compiled by W Burger WS Symb ols nil Constant whose value is itself NIL t Constant whose value is itself T symbolp e Returns T if e evaluates to a symb ol otherwise NIL boundp e Returns T if the value of e whichmust b e a symb ol has neither a global nor a lo cal value defvar sym e Denes sym to b e a global variable with initial value e defparameter sym e Denes sym to b e a global parameter whose value initial e will maychange at runtime but is not exp ected to defconstant sym e Denes sym to b e a global constant whose value e will not change while the program is running Value Assignment setf place e Stores the value of e in the place sp ecied by place setq sym e Evaluates e and makes it the value of the symbol sym the value of e is returned InputOutput read stream Reads the printed representation of a single ob ject from stream which defaults to standardinput builds a corresp onding ob ject and returns the ob ject readline stream eoferrorp eofvalue recursivep Reads a line of text terminated by a newline or endoffile character from stream which defaults to standardinput and returns two values the line as a character string and a Bo olean value T if the line was terminated byanendoffile and NIL if it was terminated by a newline readchar stream eoferrorp eofvalue recursivep Reads one character from stream which defaults to standardinput and returns the corre sp onding character ob ject readcharnohang stream eoferrorp eofvalue recursivep Reads and returns a character from stream which defaults to standardinputif
    [Show full text]
  • Functional Package Management with Guix
    Functional Package Management with Guix Ludovic Courtès Bordeaux, France [email protected] ABSTRACT 1. INTRODUCTION We describe the design and implementation of GNU Guix, a GNU Guix1 is a purely functional package manager for the purely functional package manager designed to support a com- GNU system [20], and in particular GNU/Linux. Pack- plete GNU/Linux distribution. Guix supports transactional age management consists in all the activities that relate upgrades and roll-backs, unprivileged package management, to building packages from source, honoring the build-time per-user profiles, and garbage collection. It builds upon the and run-time dependencies on packages, installing, removing, low-level build and deployment layer of the Nix package man- and upgrading packages in user environments. In addition ager. Guix uses Scheme as its programming interface. In to these standard features, Guix supports transactional up- particular, we devise an embedded domain-specific language grades and roll-backs, unprivileged package management, (EDSL) to describe and compose packages. We demonstrate per-user profiles, and garbage collection. Guix comes with a how it allows us to benefit from the host general-purpose distribution of user-land free software packages. programming language while not compromising on expres- siveness. Second, we show the use of Scheme to write build Guix seeks to empower users in several ways: by offering the programs, leading to a \two-tier" programming system. uncommon features listed above, by providing the tools that allow users to formally correlate a binary package and the Categories and Subject Descriptors \recipes" and source code that led to it|furthering the spirit D.4.5 [Operating Systems]: Reliability; D.4.5 [Operating of the GNU General Public License|, by allowing them to Systems]: System Programs and Utilities; D.1.1 [Software]: customize the distribution, and by lowering the barrier to Applicative (Functional) Programming entry in distribution development.
    [Show full text]
  • The Racket Manifesto∗
    The Racket Manifesto∗ Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi Eli Barzilay, Jay McCarthy, Sam Tobin-Hochstadt Abstract The creation of a programming language calls for guiding principles that point the developers to goals. This article spells out the three basic principles behind the 20-year development of Racket. First, programming is about stating and solving problems, and this activity normally takes place in a context with its own language of discourse; good programmers ought to for- mulate this language as a programming language. Hence, Racket is a programming language for creating new programming languages. Second, by following this language-oriented approach to programming, systems become multi-lingual collections of interconnected components. Each language and component must be able to protect its specific invariants. In support, Racket offers protection mechanisms to implement a full language spectrum, from C-level bit manipulation to soundly typed extensions. Third, because Racket considers programming as problem solving in the correct language, Racket also turns extra-linguistic mechanisms into linguistic constructs, especially mechanisms for managing resources and projects. The paper explains these principles and how Racket lives up to them, presents the evaluation framework behind the design process, and concludes with a sketch of Racket’s imperfections and opportunities for future improvements. 1998 ACM Subject Classification D.3.3 Language Constructs and Features Keywords and phrases design
    [Show full text]