DOCSLIB.ORG

You Say 'JML' ? Wikipedia (En)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

You say 'JML' ? Wikipedia (en) PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Mon, 06 Jan 2014 09:58:42 UTC Contents Articles Java Modeling Language 1 Design by contract 5 Formal methods 10 References Article Sources and Contributors 15 Image Sources, Licenses and Contributors 16 Article Licenses License 17 Java Modeling Language 1 Java Modeling Language The Java Modeling Language (JML) is a specification language for Java programs, using Hoare style pre- and postconditions and invariants, that follows the design by contract paradigm. Specifications are written as Java annotation comments to the source files, which hence can be compiled with any Java compiler. Various verification tools, such as a runtime assertion checker and the Extended Static Checker (ESC/Java) aid development. Overview JML is a behavioural interface specification language for Java modules. JML provides semantics to formally describe the behavior of a Java module, preventing ambiguity with regard to the module designers' intentions. JML inherits ideas from Eiffel, Larch and the Refinement Calculus, with the goal of providing rigorous formal semantics while still being accessible to any Java programmer. Various tools are available that make use of JML's behavioral specifications. Because specifications can be written as annotations in Java program files, or stored in separate specification files, Java modules with JML specifications can be compiled unchanged with any Java compiler. Syntax JML specifications are added to Java code in the form of annotations in comments. Java comments are interpreted as JML annotations when they begin with an @ sign. That is, comments of the form //@ <JML specification> or /*@ <JML specification> @*/ Basic JML syntax provides the following keywords requires Defines a precondition on the method that follows. ensures Defines a postcondition on the method that follows. signals Defines a postcondition for when a given Exception is thrown by the method that follows. signals_only Defines what exceptions may be thrown when the given precondition holds. assignable Defines which fields are allowed to be assigned to by the method that follows. pure Declares a method to be side effect free (this shorthand for assignable \nothing). invariant Defines an invariant property of the class. loop_invariant Defines a loop invariant for a loop. also Java Modeling Language 2 Combines specification cases and can also declare that a method is inheriting specifications from its supertypes. assert Defines a JML assertion. spec_public Declares a protected or private variable public for specification purposes. Basic JML also provides the following expressions \result An identifier for the return value of the method that follows. \old(<expression>) A modifier to refer to the value of the <expression> at the time of entry into a method. (\forall <decl>; <range-exp>; <body-exp>) The universal quantifier. (\exists <decl>; <range-exp>; <body-exp>) The existential quantifier. a ==> b a implies b a <== b a is implied by b a <==> b a if and only if b as well as standard Java syntax for logical and, or, and not. JML annotations also have access to Java objects, object methods and operators that are within the scope of the method being annotated and that have appropriate visibility. These are combined to provide formal specifications of the properties of classes, fields and methods. For example, an annotated example of a simple banking class may look like public class BankingExample { public static final int MAX_BALANCE = 1000; private /*@ spec_public @*/ int balance; private /*@ spec_public @*/ boolean isLocked = false; //@ public invariant balance >= 0 && balance <= MAX_BALANCE; //@ assignable balance; //@ ensures balance == 0; public BankingExample() { this.balance = 0; } //@ requires 0 < amount && amount + balance < MAX_BALANCE; //@ assignable balance; Java Modeling Language 3 //@ ensures balance == \old(balance) + amount; public void credit(final int amount) { this.balance += amount; } //@ requires 0 < amount && amount <= balance; //@ assignable balance; //@ ensures balance == \old(balance) - amount; public void debit(final int amount) { this.balance -= amount; } //@ ensures isLocked == true; public void lockAccount() { this.isLocked = true; } //@ requires !isLocked; //@ ensures \result == balance; //@ also //@ requires isLocked; //@ signals_only BankingException; public /*@ pure @*/ int getBalance() throws BankingException { if (!this.isLocked) { return this.balance; } else { throw new BankingException(); } } } Full documentation of JML syntax is available in the JML Reference Manual [1]. Java Modeling Language 4 Tool support A variety of tools provide functionality based on JML annotations. The Iowa State JML tools provide an assertion checking compiler jmlc which converts JML annotations into runtime assertions, a documentation generator jmldoc which produces Javadoc documentation augmented with extra information from JML annotations, and a unit test generator jmlunit which generates JUnit test code from JML annotations. Independent groups are working on tools that make use of JML annotations. These include: • ESC/Java2 [2], an extended static checker which uses JML annotations to perform more rigorous static checking than is otherwise possible; • Daikon [3], a dynamic invariant generator; • KeY, which provides a theorem prover with a JML front-end; • Krakatoa [4], a static verification tool based on the Why [5] verification platform and using the Coq proof assistant; • JMLeclipse [6], a plugin for the Eclipse integrated development environment with support for JML syntax and interfaces to various tools that make use of JML annotations. • Sireum/Kiasan [7], a symbolic execution based static analyzer which supports JML as a contract language. • JMLUnit [8], a tool to generate files for running JUnit tests on JML annotated Java files. • TACO [9], open source program analysis tool that statically checks the compliance of a Java program against its Java Modeling Language specification. References • Gary T. Leavens and Yoonsik Cheon. Design by Contract with JML; Draft tutorial. • Gary T. Leavens, Albert L. Baker, and Clyde Ruby. JML: A Notation for Detailed Design; in Haim Kilov, Bernhard Rumpe, and Ian Simmonds (editors), Behavioral Specifications of Businesses and Systems, Kluwer, 1999, chapter 12, pages 175-188. • Gary T. Leavens, Erik Poll, Curtis Clifton, Yoonsik Cheon, Clyde Ruby, David Cok, Peter Müller, Joseph Kiniry, Patrice Chalin, and Daniel M. Zimmerman. JML Reference Manual (DRAFT), September 2009. HTML [10] External links • JML website [11] References [1] http:/ / jmlspecs. org/ jmlrefman/ jmlrefman_toc. html [2] http:/ / secure. ucd. ie/ products/ opensource/ ESCJava2/ [3] http:/ / pag. csail. mit. edu/ daikon/ [4] http:/ / krakatoa. lri. fr/ [5] http:/ / why. lri. fr/ [6] http:/ / jmleclipse. projects. cis. ksu. edu/ [7] http:/ / www. sireum. org/ ?q=node/ 21/ [8] http:/ / www. eecs. ucf. edu/ ~leavens/ JML2/ docs/ man/ jmlunit. html [9] http:/ / www. dc. uba. ar/ inv/ grupos/ rfm_folder/ TACO [10] http:/ / www. jmlspecs. org/ jmlrefman/ jmlrefman_toc. html [11] http:/ / www. jmlspecs. org/ Design by contract 5 Design by contract Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts. "Design by Contract" is a registered trademark of Eiffel Software in the United States, and should not be confused with the general design approach. Microsoft calls their design-by-contract programming implementation "Code Contracts".[1] History The term was coined by Bertrand Meyer in connection with his design of the Eiffel programming language and first described in various articles starting in 1986[2][3][4] and the two successive editions (1988, 1997) of his book Object-Oriented Software Construction. Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004.[5][6] The current owner of this trademark is Eiffel Software.[][7] Design by contract has its roots in work on formal verification, formal specification and Hoare logic. The original contributions include: • A clear metaphor to guide the design process • The application to inheritance, in particular a formalism for redefinition and dynamic binding • The application to exception handling • The connection with automatic software documentation Description The central idea of DbC is a metaphor on how elements of a software system collaborate with each other on the basis of mutual obligations and benefits. The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" that defines for example that: • The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit). • The client must pay the fee (obligation) and is entitled to get the product (benefit). • Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts. Similarly, if a routine
Recommended publications
  • The Java Modeling Language

    The Java Modeling Language

    The Java Modeling Language Software Fiável Mestrado em Engenharia Informática Mestrado em Informática Faculdade de Ciências da Universidade de Lisboa 2015/2016 Vasco T. Vasconcelos, Antónia Lopes Software Fiável The Java Modeling Language Contracts I The key ingredient of Design by contract, software design methodology promoted by Bertrand Meyer and the Eiffel programming language in 1986. I Inspired by assertions of Hoare logic, contracts place special obligations on both clients and suppliers of a procedure or method. I What does a method require from it’s caller? I What does the method ensure? Software Fiável The Java Modeling Language DBC DBC key idea is to associate a specification with every software element. These specifications (or contracts) govern the interaction of the element with the rest of the world. I Forces the programmer to write exactly what the method does and needs I No need to program defensively (defensive checks can be exensive and increases the complexity of the code of the method and worsen its maintainability) I Assigns blame: specifies who is to blame for not keeping the contract I Provides a standard way to document classes: client programmers are provided with a proper description of the interface properties of a class that is stripped of all implementation information but retains the essential usage information: the contract. Software Fiável The Java Modeling Language Language support for Contracts Language support for contracts exists in different forms: I Eiffel is an object-oriented language that includes contracts I JML adds contracts to the Java language. JML specifications are conventional Java boolean expressions, with a few extensions I Spec# adds contracts to C# I Code Contracts is an API (part of .NET) to author contracts In this course we focus on JML.
  • Génération Automatique De Tests Unitaires Avec Praspel, Un Langage De Spécification Pour PHP the Art of Contract-Based Testing in PHP with Praspel

    Génération Automatique De Tests Unitaires Avec Praspel, Un Langage De Spécification Pour PHP the Art of Contract-Based Testing in PHP with Praspel

    CORE Metadata, citation and similar papers at core.ac.uk Provided by HAL - Université de Franche-Comté G´en´erationautomatique de tests unitaires avec Praspel, un langage de sp´ecificationpour PHP Ivan Enderlin To cite this version: Ivan Enderlin. G´en´eration automatique de tests unitaires avec Praspel, un langage de sp´ecificationpour PHP. Informatique et langage [cs.CL]. Universit´ede Franche-Comt´e,2014. Fran¸cais. <NNT : 2014BESA2067>. <tel-01093355v2> HAL Id: tel-01093355 https://hal.inria.fr/tel-01093355v2 Submitted on 19 Oct 2016 HAL is a multi-disciplinary open access L'archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destin´eeau d´ep^otet `ala diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publi´esou non, lished or not. The documents may come from ´emanant des ´etablissements d'enseignement et de teaching and research institutions in France or recherche fran¸caisou ´etrangers,des laboratoires abroad, or from public or private research centers. publics ou priv´es. Thèse de Doctorat école doctorale sciences pour l’ingénieur et microtechniques UNIVERSITÉ DE FRANCHE-COMTÉ No X X X THÈSE présentée par Ivan Enderlin pour obtenir le Grade de Docteur de l’Université de Franche-Comté K 8 k Génération automatique de tests unitaires avec Praspel, un langage de spécification pour PHP The Art of Contract-based Testing in PHP with Praspel Spécialité Informatique Instituts Femto-ST (département DISC) et INRIA (laboratoire LORIA) Soutenue publiquement
  • Assertions, Pre/Post- Conditions and Invariants

    Assertions, Pre/Post- Conditions and Invariants

    9/14/12 Assertions, pre/post- conditions and invariants Section 2.1 in Walls and Mirrors Section 4.5 Rosen Programming as a contract n Specifying what each method does q Specify it in a comment before method's header n Precondition q What is assumed to be true before the method is executed q Caller obligation n Postcondition q Specifies what will happen if the preconditions are met q Method obligation 1 9/14/12 Class Invariants n A class invariant is a condition that all objects of that class must satisfy while it can be observed by clients n What about Points in Cloud? q boundaries? q center? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } // what could you state here? 2 9/14/12 What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //more? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //n is the smallest power of 2 >= limit 3 9/14/12 assert Using assert: assert n == 1; while (n < limit) { n = 2 * n; } assert n >= limit; When to use Assertions n We can use assertions to guarantee the behavior.
  • Chapter 23 Three Design Principles

    Chapter 23 Three Design Principles

    23 Three Design Principles Chapter 23 ContaxT / Kodax Tri-X Nunnery — Chichen Itza, Mexico Three Design Principles Learning Objectives • List the preferred characteristics of an object-oriented application architecture • State the definition of the Liskov Substitution Principle (LSP) • State the definition of Bertrand Meyer's Design by Contract (DbC) programming • Describe the close relationship between the Liskov Substitution Principle and Design by Contract • State the purpose of class invariants • State the purpose of method preconditions and postconditions • Describe the effects weakening and strengthening preconditions have on subclass behavior • Describe the effects weakening and strengthening postconditions have on subclass behavior • State the purpose and use of the Open-Closed Principle (OCP) • State the purpose and use of the Dependency Inversion Principle (DIP) • State the purpose of Code Contracts and how they are used to enforce preconditions, postconditions, and class invariants C# For Artists © 2015 Rick Miller and Pulp Free Press — All Rights Reserved 757 Introduction Chapter 23: Three Design Principles Introduction Building complex, well-behaved, object-oriented software is a difficult task for several reasons. First, simply programming in C# does not automatically make your application object-oriented. Second, the pro- cess by which you become proficient at object-oriented design and programming is characterized by expe- rience. It takes a lot of time to learn the lessons of bad software architecture design and apply those lessons learned to create good object-oriented architectures. The objective of this chapter is to help you jump-start your object-oriented architectural design efforts. I begin with a discussion of the preferred characteristics of a well-designed object-oriented architecture.
  • Grammar-Based Testing Using Realistic Domains in PHP Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet

    Grammar-Based Testing Using Realistic Domains in PHP Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet

    Grammar-Based Testing using Realistic Domains in PHP Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet To cite this version: Ivan Enderlin, Frédéric Dadeau, Alain Giorgetti, Fabrice Bouquet. Grammar-Based Testing using Realistic Domains in PHP. A-MOST 2012, 8th Workshop on Advances in Model Based Testing, joint to the ICST’12 IEEE Int. Conf. on Software Testing, Verification and Validation, Jan 2012, Canada. pp.509–518. hal-00931662 HAL Id: hal-00931662 https://hal.archives-ouvertes.fr/hal-00931662 Submitted on 16 Jan 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Grammar-Based Testing using Realistic Domains in PHP Ivan Enderlin, Fred´ eric´ Dadeau, Alain Giorgetti and Fabrice Bouquet Institut FEMTO-ST UMR CNRS 6174 - University of Franche-Comte´ - INRIA CASSIS Project 16 route de Gray - 25030 Besanc¸on cedex, France Email: fivan.enderlin,frederic.dadeau,alain.giorgetti,[email protected] Abstract—This paper presents an integration of grammar- Contract-based testing [5] has been introduced in part to based testing in a framework for contract-based testing in PHP. address these limitations. It is based on the notion of Design It relies on the notion of realistic domains, that make it possible by Contract (DbC) [6] introduced by Meyer with Eiffel [7].
  • Design by Contract: the Lessons of Ariane

    Design by Contract: the Lessons of Ariane

    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
  • Contracts for Concurrency Piotr Nienaltowski, Bertrand Meyer, Jonathan S

    Contracts for Concurrency Piotr Nienaltowski, Bertrand Meyer, Jonathan S

    Contracts for concurrency Piotr Nienaltowski, Bertrand Meyer, Jonathan S. Ostroff To cite this version: Piotr Nienaltowski, Bertrand Meyer, Jonathan S. Ostroff. Contracts for concurrency. Formal Aspects of Computing, Springer Verlag, 2008, 21 (4), pp.305-318. 10.1007/s00165-007-0063-2. hal-00477897 HAL Id: hal-00477897 https://hal.archives-ouvertes.fr/hal-00477897 Submitted on 30 Apr 2010 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. DOI 10.1007/s00165-007-0063-2 BCS © 2007 Formal Aspects Formal Aspects of Computing (2009) 21: 305–318 of Computing Contracts for concurrency Piotr Nienaltowski1, Bertrand Meyer2 and Jonathan S. Ostroff3 1 Praxis High Integrity Systems Limited, 20 Manvers Street, Bath BA1 1PX, UK E-mail: [email protected] 2 ETH Zurich, Zurich, Switzerland 3 York University, Toronto, Canada Abstract. The SCOOP model extends the Eiffel programming language to provide support for concurrent programming. The model is based on the principles of Design by Contract. The semantics of contracts used in the original proposal (SCOOP 97) is not suitable for concurrent programming because it restricts parallelism and complicates reasoning about program correctness. This article outlines a new contract semantics which applies equally well in concurrent and sequential contexts and permits a flexible use of contracts for specifying the mutual rights and obligations of clients and suppliers while preserving the potential for parallelism.
  • The Java Modeling Language

    The Java Modeling Language

    The Java Modeling language JML Erik Poll Digital Security Radboud University Nijmegen JML • formal specification language for sequential Java by Gary Leavens et. al. – to specify behaviour of Java classes & interfaces – to record detailed design decisions by adding annotations to Java source code in Design-By- Contract style, using eg. pre/postconditions and invariants • Design goal: meant to be usable by any Java programmer Lots of info on http://www.jmlspecs.org Erik Poll, JML introduction - CHARTER meeting - 2 to make JML easy to use • JML annotations added as special Java comments, between /*@ .. @*/ or after //@ • JML specs can be in .java files, or in separate .jml files • Properties specified using Java syntax, extended with some operators \old( ), \result, \forall, \exists, ==> , .. and some keywords requires, ensures, invariant, .... Erik Poll, JML introduction - CHARTER meeting - 3 JML example public class ePurse{ private int balance; //@ invariant 0 <= balance && balance < 500; //@ requires amount >= 0; //@ ensures balance <= \old(balance); public debit(int amount) { if (amount > balance) { throw (new BankException("No way"));} balance = balance – amount; } Erik Poll, JML introduction - CHARTER meeting - 4 What can you do with this? • documentation/specification – record detailed design decisions & document assumptions (and hence obligations!) – precise, unambiguous documentation • parsed & type checked • use tools for – runtime assertion checking • eg when testing code – compile time (static) analyses • up to full formal program
  • 032133633X Sample.Pdf

    032133633X Sample.Pdf

    Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. Excerpts from the Tcl/Tk reference documentation are used under the terms of the Tcl/Tk license (http://www.tcl.tk/software/tcltk/license.html). The open source icon set used in Figures 22-1, 22-2, and 22-3 are from the Tango Desktop Project (http://tango.freedesktop.org/Tango_Desktop_Project). The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [email protected] For sales outside the United States please contact: International Sales [email protected] Visit us on the Web: informit.com/aw Library of Congress Cataloging-in-Publication Data Ousterhout, John K. Tcl and the Tk toolkit / John Ousterhout, Ken Jones ; with contributions by Eric Foster-Johnson . [et al.]. — 2nd ed.
  • Xotcl - Tutorial 1.6.4

    Xotcl - Tutorial 1.6.4

    XOTcl - Tutorial 1.6.4 Gustaf Neumann and Uwe Zdun XOTcl - Tutorial 1 XOTcl - Tutorial XOTcl - Tutorial - Index Version: 1.6.4 • Introduction ♦ Language Overview ♦ Introductory Overview Example: Stack ◊ Object specific methods ◊ Refining the behavior of objects and classes ◊ Stack of integers ◊ Class specifc methods ♦ Introductory Overview Example: Soccer Club • Object and Class System • Basic Functionalities ♦ Objects ◊ Data on Objects ◊ Methods for Objects ◊ Information about Objects ♦ Classes ◊ Creating Classes and Deriving Instances ◊ Methods Defined in Classes ◊ Information about Classes ◊ Inheritance ◊ Destruction of Classes ◊ Method Chaining ♦ Dynamic Class and Superclass Relationships ♦ Meta-Classes ♦ Create, Destroy, and Recreate Methods ♦ Methods with Non-Positional Arguments • Message Interception Techniques ♦ Filter ♦ Mixin Classes ♦ Precedence Order ♦ Guards for Filters and Mixins ♦ Querying, Setting, Altering Filter and Mixin Lists ♦ Querying Call-stack Information • Slots ♦ System Slots ♦ Attribute Slots ♦ Setter and Getter Methods for Slots ♦ Backward-compatible Short-Hand Notation for Attribute Slots ♦ Experimental Slot Features ◊ Value Checking ◊ Init Commands and Value Commands for Slot Values • Nested Classes and Dynamic Object Aggregations ♦ Nested Classes 2 XOTcl - Tutorial ♦ Dynamic Object Aggregations ♦ Relationship between Class Nesting and Object Aggregation ♦ Simplified Syntax for Creating Nested Object Structures ♦ Copy/Move • Method Forwarding • Assertions • Additional Functionalities ♦ Abstract Classes ♦ Automatic Name Creation ♦ Meta-Data • Integrating XOTcl Programs with C Extensions (such as Tk) • References 3 XOTcl - Tutorial Introduction Language Overview XOTcl [Neumann and Zdun 2000a] is an extension to the object-oriented scripting language OTcl [Wetherall and Lindblad 1995] which itself extends Tcl [Ousterhout 1990] (Tool Command Language) with object-orientation. XOTcl is a value-added replacement for OTcl and does not require OTcl to compile.
  • Implementing Closures in Dafny Research Project Report

    Implementing Closures in Dafny Research Project Report

    Implementing Closures in Dafny Research Project Report • Author: Alexandru Dima 1 • Total number of pages: 22 • Date: Tuesday 28th September, 2010 • Location: Z¨urich, Switzerland 1E-mail: [email protected] Contents 1 Introduction 1 2 Background 1 2.1 Closures . .1 2.2 Dafny . .2 3 General approach 3 4 Procedural Closures 5 4.1 Procedural Closure Type . .5 4.2 Procedural Closure Specifications . .6 4.3 A basic procedural closure example . .6 4.3.1 Discussion . .6 4.3.2 Boogie output . .8 4.4 A counter factory example . 13 4.5 Delegation example . 17 5 Pure Closures 18 5.1 Pure Closure Type . 18 5.2 A recursive while . 19 6 Conclusions 21 6.1 Limitations . 21 6.2 Possible extensions . 21 6.3 Acknowledgments . 21 2 BACKGROUND 1 Introduction Closures represent a particularly useful language feature. They provide a means to keep the functionality linked together with state, providing a source of ex- pressiveness, conciseness and, when used correctly, give programmers a sense of freedom that few other language features do. Smalltalk's standard control structures, including branches (if/then/else) and loops (while and for) are very good examples of using closures, as closures de- lay evaluation; the state they capture may be used as a private communication channel between multiple closures closed over the same environment; closures may be used for handling User Interface events; the possibilities are endless. Although they have been used for decades, static verification has not yet tack- led the problems which appear when trying to reason modularly about closures.
  • Xotcl − Documentation −− ./Doc/Langref.Xotcl ./Doc/Langref.Xotcl

    Xotcl − Documentation −− ./Doc/Langref.Xotcl ./Doc/Langref.Xotcl

    XOTcl − Documentation −− ./doc/langRef.xotcl ./doc/langRef.xotcl Package/File Information No package provided/required Defined Objects/Classes: • Class: __unknown, allinstances, alloc, create, info, instdestroy, instfilter, instfilterguard, instforward, instinvar, instmixin, instparametercmd, instproc, new, parameter, parameterclass, recreate, superclass, unknown, volatile. • Object: abstract, append, array, autoname, check, class, cleanup, configure, copy, destroy, eval, exists, extractConfigureArg, filter, filterguard, filtersearch, forward, getExitHandler, hasclass, incr, info, instvar, invar, isclass, ismetaclass, ismixin, isobject, istype, lappend, mixin, move, noinit, parametercmd, proc, procsearch, requireNamespace, set, setExitHandler, trace, unset, uplevel, upvar, vwait. Filename: ./doc/langRef.xotcl Description: XOTcl language reference. Describes predefined objects and classes. Predefined XOTcl contains three predefined primitives: primitives: self computes callstack related information. It can be used in the following ways: • self − returns the name of the object, which is currently in execution. If it is called from outside of a proc, it returns the error message ``Can't find self''. • self class − the self command with a given argument class returns the name of the class, which holds the currently executing instproc. Note, that this may be different to the class of the current object. If it is called from a proc it returns an empty string. • self proc − the self command with a given argument proc returns the name of the currently executing proc or instproc. • self callingclass: Returns class name of the class that has called the executing method. • self callingobject: Returns object name of the object that has called the executing method. • self callingproc: Returns proc name of the method that has called the executing method. • self calledclass: Returns class name of the class that holds the target proc (in mixins and filters).