DOCSLIB.ORG

Object-Oriented Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Object-Oriented Programming MATLAB® Object-Oriented Programming R2020a How to Contact MathWorks Latest news: www.mathworks.com Sales and services: www.mathworks.com/sales_and_services User community: www.mathworks.com/matlabcentral Technical support: www.mathworks.com/support/contact_us Phone: 508-647-7000 The MathWorks, Inc. 1 Apple Hill Drive Natick, MA 01760-2098 Object-Oriented Programming © COPYRIGHT 1984–2020 by The MathWorks, Inc. The software described in this document is furnished under a license agreement. The software may be used or copied only under the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written consent from The MathWorks, Inc. FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees that this software or documentation qualifies as commercial computer software or commercial computer software documentation as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification, reproduction, release, performance, display, and disclosure of the Program and Documentation by the federal government (or other entity acquiring for or through the federal government) and shall supersede any conflicting contractual terms or conditions. If this License fails to meet the government's needs or is inconsistent in any respect with federal procurement law, the government agrees to return the Program and Documentation, unused, to The MathWorks, Inc. Trademarks MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders. Patents MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents for more information. Revision History March 2008 Online only New for MATLAB 7.6 (Release 2008a) October 2008 Online only Revised for MATLAB 7.7 (Release 2008b) March 2009 Online only Revised for MATLAB 7.8 (Release 2009a) September 2009 Online only Revised for MATLAB 7.9 (Release 2009b) March 2010 Online only Revised for MATLAB 7.10 (Release 2010a) September 2010 Online only Revised for Version 7.11 (Release 2010b) April 2011 Online only Revised for Version 7.12 (Release 2011a) September 2011 Online only Revised for Version 7.13 (Release 2011b) March 2012 Online only Revised for Version 7.14 (Release 2012a) September 2012 Online only Revised for Version 8.0 (Release 2012b) March 2013 Online only Revised for Version 8.1 (Release 2013a) September 2013 Online only Revised for Version 8.2 (Release 2013b) March 2014 Online only Revised for Version 8.3 (Release 2014a) October 2014 Online only Revised for Version 8.4 (Release 2014b) March 2015 Online only Revised for Version 8.5 (Release 2015a) September 2015 Online only Revised for Version 8.6 (Release 2015b) March 2016 Online only Revised for Version 9.0 (Release 2016a) September 2016 Online only Revised for Version 9.1 (Release 2016b) March 2017 Online only Revised for Version 9.2 (Release 2017a) September 2017 Online only Revised for Version 9.3 (Release 2017b) March 2018 Online only Revised for MATLAB 9.4 (Release 2018a) September 2018 Online only Revised for Version 9.5 (Release 2018b) March 2019 Online only Revised for MATLAB 9.6 (Release 2019a) September 2019 Online only Revised for MATLAB 9.7 (Release 2019b) March 2020 Online only Revised for MATLAB 9.8 (Release 2020a) Contents Using Object-Oriented Design in MATLAB 1 Why Use Object-Oriented Design ................................. 1-2 Approaches to Writing MATLAB Programs ........................ 1-2 When Should You Create Object-Oriented Programs ................. 1-2 Handle Object Behavior ........................................ 1-7 What Is a Handle? .......................................... 1-7 Copies of Handles ........................................... 1-7 Handle Objects Modified in Functions ............................ 1-8 Determine If an Object Is a Handle .............................. 1-9 Deleted Handle Objects ...................................... 1-9 Basic Example 2 Create a Simple Class .......................................... 2-2 Design Class ............................................... 2-2 Create Object .............................................. 2-3 Access Properties ........................................... 2-3 Call Methods .............................................. 2-3 Add Constructor ............................................ 2-4 Vectorize Methods .......................................... 2-4 Overload Functions ......................................... 2-5 BasicClass Code Listing ...................................... 2-6 MATLAB Classes Overview 3 Role of Classes in MATLAB ...................................... 3-2 Classes ................................................... 3-2 Some Basic Relationships ..................................... 3-3 Developing Classes — Typical Workflow ............................ 3-6 Formulating a Class ......................................... 3-6 Specifying Class Components .................................. 3-7 BankAccount Class Implementation ............................. 3-7 Formulating the AccountManager Class ......................... 3-10 Implementing the AccountManager Class ........................ 3-11 AccountManager Class Synopsis ............................... 3-11 v Using BankAccount Objects .................................. 3-12 Representing Structured Data with Classes ....................... 3-14 Objects as Data Structures ................................... 3-14 Structure of the Data ....................................... 3-14 The TensileData Class ....................................... 3-15 Create an Instance and Assign Data ............................ 3-15 Restrict Properties to Specific Values ........................... 3-16 Simplifying the Interface with a Constructor ...................... 3-16 Calculate Data on Demand ................................... 3-17 Displaying TensileData Objects ................................ 3-18 Method to Plot Stress vs. Strain ............................... 3-18 TensileData Class Synopsis ................................... 3-19 Implementing Linked Lists with Classes .......................... 3-23 Class Definition Code ....................................... 3-23 dlnode Class Design ........................................ 3-23 Create Doubly Linked List ................................... 3-24 Why a Handle Class for Linked Lists? ........................... 3-25 dlnode Class Synopsis ...................................... 3-25 Specialize the dlnode Class ................................... 3-34 Static Data 4 Static Data ................................................... 4-2 What Is Static Data .......................................... 4-2 Static Variable ............................................. 4-2 Static Data Object .......................................... 4-3 Constant Data .............................................. 4-4 Class Definition—Syntax Reference 5 Class Files and Folders ......................................... 5-2 Class Definition Files ........................................ 5-2 Options for Class Folders ..................................... 5-2 Options for Class Files ....................................... 5-2 Group Classes with Package Folders ............................. 5-3 Class Components ............................................. 5-4 Class Building Blocks ........................................ 5-4 Class Definition Block ........................................ 5-4 Properties Block ............................................ 5-5 Methods Block ............................................. 5-5 Events Block ............................................... 5-5 A Complete Class ........................................... 5-6 Enumeration Classes ........................................ 5-6 Related Information ......................................... 5-7 vi Contents Classdef Block ................................................ 5-8 How to Specify Attributes and Superclasses ....................... 5-8 Class Attribute Syntax ....................................... 5-8 Superclass Syntax .......................................... 5-8 Local Functions in Class File .................................. 5-9 Class Properties .............................................. 5-10 The Properties Block ....................................... 5-10 Access to Property Values .................................... 5-11 Methods and Functions ........................................ 5-13 The Methods Block ......................................... 5-13 Method Calling Syntax ...................................... 5-13 Private Methods ........................................... 5-14 More Detailed Information on Methods .......................... 5-14 Class-Related Functions ..................................... 5-14 How to Overload Functions and Operators ....................... 5-15 Rules for Defining Methods in Separate Files ..................... 5-15 Events and Listeners .......................................... 5-17 Define and Trigger Events ..................................
Load more

Recommended publications
  • Arithmetic Equivalence and Isospectrality
    ARITHMETIC EQUIVALENCE AND ISOSPECTRALITY ANDREW V.SUTHERLAND ABSTRACT. In these lecture notes we give an introduction to the theory of arithmetic equivalence, a notion originally introduced in a number theoretic setting to refer to number fields with the same zeta function. Gassmann established a direct relationship between arithmetic equivalence and a purely group theoretic notion of equivalence that has since been exploited in several other areas of mathematics, most notably in the spectral theory of Riemannian manifolds by Sunada. We will explicate these results and discuss some applications and generalizations. 1. AN INTRODUCTION TO ARITHMETIC EQUIVALENCE AND ISOSPECTRALITY Let K be a number field (a finite extension of Q), and let OK be its ring of integers (the integral closure of Z in K). The Dedekind zeta function of K is defined by the Dirichlet series X s Y s 1 ζK (s) := N(I)− = (1 N(p)− )− I OK p − ⊆ where the sum ranges over nonzero OK -ideals, the product ranges over nonzero prime ideals, and N(I) := [OK : I] is the absolute norm. For K = Q the Dedekind zeta function ζQ(s) is simply the : P s Riemann zeta function ζ(s) = n 1 n− . As with the Riemann zeta function, the Dirichlet series (and corresponding Euler product) defining≥ the Dedekind zeta function converges absolutely and uniformly to a nonzero holomorphic function on Re(s) > 1, and ζK (s) extends to a meromorphic function on C and satisfies a functional equation, as shown by Hecke [25]. The Dedekind zeta function encodes many features of the number field K: it has a simple pole at s = 1 whose residue is intimately related to several invariants of K, including its class number, and as with the Riemann zeta function, the zeros of ζK (s) are intimately related to the distribution of prime ideals in OK .
    [Show full text]
  • NOTES on FINITE GROUP REPRESENTATIONS in Fall 2020, I
    NOTES ON FINITE GROUP REPRESENTATIONS CHARLES REZK In Fall 2020, I taught an undergraduate course on abstract algebra. I chose to spend two weeks on the theory of complex representations of finite groups. I covered the basic concepts, leading to the classification of representations by characters. I also briefly addressed a few more advanced topics, notably induced representations and Frobenius divisibility. I'm making the lectures and these associated notes for this material publicly available. The material here is standard, and is mainly based on Steinberg, Representation theory of finite groups, Ch 2-4, whose notation I will mostly follow. I also used Serre, Linear representations of finite groups, Ch 1-3.1 1. Group representations Given a vector space V over a field F , we write GL(V ) for the group of bijective linear maps T : V ! V . n n When V = F we can write GLn(F ) = GL(F ), and identify the group with the group of invertible n × n matrices. A representation of a group G is a homomorphism of groups φ: G ! GL(V ) for some representation choice of vector space V . I'll usually write φg 2 GL(V ) for the value of φ on g 2 G. n When V = F , so we have a homomorphism φ: G ! GLn(F ), we call it a matrix representation. matrix representation The choice of field F matters. For now, we will look exclusively at the case of F = C, i.e., representations in complex vector spaces. Remark. Since R ⊆ C is a subfield, GLn(R) is a subgroup of GLn(C).
    [Show full text]
  • Operator Overloading ______
    Chapter 10: Operator Overloading _________________________________________________________________________________________________________ Consider the following C++ code snippet: vector<string> myVector(kNumStrings); for(vector<string>::iterator itr = myVector.begin(); itr != myVector.end(); ++itr) *itr += "Now longer!"; Here, we create a vector<string> of a certain size, then iterate over it concatenating “Now longer!” to each of the strings. Code like this is ubiquitous in C++, and initially does not appear all that exciting. However, let's take a closer look at how this code is structured. First, let's look at exactly what operations we're performing on the iterator: vector<string> myVector(kNumStrings); for(vector<string>::iterator itr = myVector.begin(); itr != myVector.end(); ++itr) *itr += "Now longer!"; In this simple piece of code, we're comparing the iterator against myVector.end() using the != operator, incrementing the iterator with the ++ operator, and dereferencing the iterator with the * operator. At a high level, this doesn't seem all that out of the ordinary, since STL iterators are designed to look like regular pointers and these operators are all well-defined on pointers. But the key thing to notice is that STL iterators aren't pointers, they're objects, and !=, *, and ++ aren't normally defined on objects. We can't write code like ++myVector or *myMap = 137, so why can these operations be applied to vector<string>::iterator? Similarly, notice how we're concatenating the string “Now longer!” onto the end of the string: vector<string> myVector(kNumStrings); for(vector<string>::iterator itr = myVector.begin(); itr != myVector.end(); ++itr) *itr += "Now longer!"; Despite the fact that string is an object, somehow C++ “knows” what it means to apply += to strings.
    [Show full text]
  • Class Numbers of Totally Real Number Fields
    CLASS NUMBERS OF TOTALLY REAL NUMBER FIELDS BY JOHN C. MILLER A dissertation submitted to the Graduate School|New Brunswick Rutgers, The State University of New Jersey in partial fulfillment of the requirements for the degree of Doctor of Philosophy Graduate Program in Mathematics Written under the direction of Henryk Iwaniec and approved by New Brunswick, New Jersey May, 2015 ABSTRACT OF THE DISSERTATION Class numbers of totally real number fields by John C. Miller Dissertation Director: Henryk Iwaniec The determination of the class number of totally real fields of large discriminant is known to be a difficult problem. The Minkowski bound is too large to be useful, and the root discriminant of the field can be too large to be treated by Odlyzko's discriminant bounds. This thesis describes a new approach. By finding nontrivial lower bounds for sums over prime ideals of the Hilbert class field, we establish upper bounds for class numbers of fields of larger discriminant. This analytic upper bound, together with algebraic arguments concerning the divisibility properties of class numbers, allows us to determine the class numbers of many number fields that have previously been untreatable by any known method. For example, we consider the cyclotomic fields and their real subfields. Surprisingly, the class numbers of cyclotomic fields have only been determined for fields of small conductor, e.g. for prime conductors up to 67, due to the problem of finding the class number of its maximal real subfield, a problem first considered by Kummer. Our results have significantly improved the situation. We also study the cyclotomic Zp-extensions of the rationals.
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • REPRESENTATION THEORY WEEK 7 1. Characters of GL Kand Sn A
    REPRESENTATION THEORY WEEK 7 1. Characters of GLk and Sn A character of an irreducible representation of GLk is a polynomial function con- stant on every conjugacy class. Since the set of diagonalizable matrices is dense in GLk, a character is defined by its values on the subgroup of diagonal matrices in GLk. Thus, one can consider a character as a polynomial function of x1,...,xk. Moreover, a character is a symmetric polynomial of x1,...,xk as the matrices diag (x1,...,xk) and diag xs(1),...,xs(k) are conjugate for any s ∈ Sk. For example, the character of the standard representation in E is equal to x1 + ⊗n n ··· + xk and the character of E is equal to (x1 + ··· + xk) . Let λ = (λ1,...,λk) be such that λ1 ≥ λ2 ≥ ···≥ λk ≥ 0. Let Dλ denote the λj determinant of the k × k-matrix whose i, j entry equals xi . It is clear that Dλ is a skew-symmetric polynomial of x1,...,xk. If ρ = (k − 1,..., 1, 0) then Dρ = i≤j (xi − xj) is the well known Vandermonde determinant. Let Q Dλ+ρ Sλ = . Dρ It is easy to see that Sλ is a symmetric polynomial of x1,...,xk. It is called a Schur λ1 λk polynomial. The leading monomial of Sλ is the x ...xk (if one orders monomials lexicographically) and therefore it is not hard to show that Sλ form a basis in the ring of symmetric polynomials of x1,...,xk. Theorem 1.1. The character of Wλ equals to Sλ. I do not include a proof of this Theorem since it uses beautiful but hard combina- toric.
    [Show full text]
  • Property Mapping: a Simple Technique for Mobile Robot Programming
    Property Mapping: a simple technique for mobile robot programming Illah R. Nourbakhsh The Robotics Institute, Carnegie Mellon University Pittsburgh, PA 15213 [email protected] Abstract In this paper we present robot observability as a The mobile robot programming problem is a software predictor for diagnostic transparency. Then, we present a engineering challenge that is not easily conquered using language-independent technique called property mapping contemporary software engineering best practices. We for constructing robot programs that are diagnostically propose robot observability as a measure of the diagnostic transparent and thereby achieve high degrees of transparency of a situated robot program, then describe reliability. property mapping as a simple, language-independent approach to implementing reliable robot programs by maximizing robot observability. Examples from real- The Robot Programming Problem world, working robots are given in Lisp and Java. A mobile robot is a situated automata, or a module that comprises one part of a closed system together with the Introduction environment. Fig. 1 shows the standard depiction of a robot, with its outputs labeled as actions and the outputs The recent availability of inexpensive, reliable robot of the environment in turn labeled as percepts. chassis (e.g. ActivMedia Pioneer, IS-Robotics Magellan, Nomad Scout) has broadened the accessibility of mobile robotics research. Because these robots consist of fixed E hardware out-of-the-box, this technology is shifting the actions A P percepts emphasis of mobile robot research from a joint hardware and software design process toward hardware-unaware R mobile robot programming. This is a software design problem, and yet software Figure 1: The standard view of an embedded robot engineering best practices are not very helpful.
    [Show full text]
  • Problem 1 Show That If Π Is an Irreducible Representation of a Compact Lie Group G Then Π∨ Is Also Irreducible
    Problem 1 Show that if π is an irreducible representation of a compact lie group G then π_ is also irreducible. Give an example of a G and π such that π =∼ π_, and another for which π π_. Is this true for general groups? R 2 Since G is a compact Lie group, we can apply Schur orthogonality to see that G jχπ_ (g)j dg = R 2 R 2 _ G jχπ(g)j dg = G jχπ(g)j dg = 1, so π is irreducible. For any G, the trivial representation π _ i i satisfies π ' π . For G the cyclic group of order 3 generated by g, the representation π : g 7! ζ3 _ i −i is not isomorphic to π : g 7! ζ3 . This is true for finite dimensional irreducible representations. This follows as if W ⊆ V a proper, non-zero G-invariant representation for a group G, then W ? = fφ 2 V ∗jφ(W ) = 0g is a proper, non-zero G-invariant subspace and applying this to V ∗ as V ∗∗ =∼ V we get V is irreducible if and only if V ∗ is irreducible. This is false for general representations and general groups. Take G = S1 to be the symmetric group on countably infinitely many letters, and let G act on a vector space V over C with basis e1; e2; ··· by sending σ : ei 7! eσ(i). Let W be the sub-representation given by the kernel of the map P P V ! C sending λiei 7! λi. Then W is irreducible because given any λ1e1 + ··· + λnen 2 V −1 where λn 6= 0, and we see that λn [(n n + 1) − 1] 2 C[G] sends this to en+1 − en, and elements like ∗ ∗ this span W .
    [Show full text]
  • C++ Properties -- a Library Solution
    Document Number: SC22/WG21/N1615=04-0055 Date: 2004-04-09 Author: Lois Goldthwaite Email: [email protected] C++ Properties -- a Library Solution N1600 is a summary of the "property" language extension that is proposed for C++/CLI. I can't help feeling that this is an effort to impose an alien idiom on C++. There is too much of "the compiler will perform black magic behind your back" in it. There are too many ways in which the programmer must be aware that some [pseudo-]data members must be handled in different ways from [real] data members. The C++/CLI draft spec (N1608)says in 8.8.4 and 18.4 that "A property is a member that behaves as if it were a field." I think "behaves" is absolutely the wrong word to use here. A property is behavior that pretends to be state. From an OO design point of view, I think this is A Bad Idea. Behaviour should be visible; state should not. Further on, the document continues, "the X and Y properties can be read and written as though they were fields. In the example above, the properties are used to implement data hiding within the class itself." The subtle advantage of "hiding" a private data member by treating it as a public data member escapes me. Properties are just syntactic saccharine for getter and setter member functions for individual fields. C++ experts have spent years trying to educate people NOT to use public data, to use member functions instead, and now we propose to introduce something that looks just like public data? Do we really want to try to teach people that public fields are still bad, but properties are good, even though they look just the same from outside the class? Moreover, these public fields have side effects! There is a danger that too many novice programmers will prototype their designs using public fields, with the intent of changing them to properties later, if and when it proves necessary, and the general quality of code will suffer because of it.
    [Show full text]
  • Introductory Programming in C# Release 1.0
    Introductory Programming in C# Release 1.0 Andrew N. Harrington and George K. Thiruvathukal May 29, 2012 CONTENTS 1 Context 1 1.1 Introduction to the Notes.........................................1 1.2 Comments on Miles Chapter 1......................................1 2 C# Data and Operations 3 2.1 Development Tools............................................3 2.2 Lab Exercise: Editing, Compiling, and Running............................5 2.3 Comments on Miles Simple Data....................................9 2.4 Division and Remainders.........................................9 2.5 Substitutions in Console.WriteLine................................... 10 2.6 Learning to Solve Problems....................................... 12 2.7 Lab: Division Sentences......................................... 15 2.8 Homework: Grade Calculation...................................... 18 3 Defining Functions of your Own 23 3.1 Syntax Template Typography...................................... 23 3.2 A First Function Definition....................................... 23 3.3 Multiple Function Definitions...................................... 25 3.4 Function Parameters........................................... 26 3.5 Multiple Function Parameters...................................... 29 3.6 Returned Function Values........................................ 30 3.7 Two Roles: Writer and Consumer of Functions............................. 32 3.8 Local Scope............................................... 33 3.9 Static Variables.............................................
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • Property Conveyances As a Programming Language
    Property Conveyances as a Programming Language Shrutarshi Basu∗ Nate Foster James Grimmelmann Harvard University Cornell University Cornell Law School & Cornell Tech Cambridge, MA, USA Ithaca, NY, USA New York, NY, USA [email protected] [email protected] [email protected] Abstract 1 Introduction Anglo-American law enables property owners to split up Many legal issues depend on vague, open-ended standards. rights among multiple entities by breaking their ownership For example, nuisance law prohibits “unreasonable” interfer- apart into future interests that may evolve over time. The con- ence with neighbors’ use of land. What counts as “unreason- veyances that owners use to transfer and subdivide property able” depends on an eight-factor balancing test, and many of rights follow rigid syntactic conventions and are governed the individual factors are themselves vague and open-ended, by an intricate body of interlocking doctrines that determine including “the social value that the law attaches to the pri- their legal eect. These doctrines have been codied, but mary purpose of the conduct;” and “the suitability of the only in informal and potentially ambiguous ways. particular use or enjoyment invaded to the character of the This paper presents preliminary work in developing a locality.” [American Law Institute 1979] A lawyer who wants formal model for expressing and analyzing property con- to know whether a client’s cement plant will be considered veyances. We develop a domain-specic language capable a nuisance will have to research numerous previous cases, of expressing a wide range of conveyances in a syntax ap- gather extensive facts about the plant and its neighbors, and proximating natural language.
    [Show full text]