DOCSLIB.ORG

Java for Scientific Computing, Pros and Cons

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Java for Scientific Computing, Pros and Cons Journal of Universal Computer Science, vol. 4, no. 1 (1998), 11-15 submitted: 25/9/97, accepted: 1/11/97, appeared: 28/1/98 Springer Pub. Co. Java for Scienti c Computing, Pros and Cons Jurgen Wol v. Gudenb erg Institut fur Informatik, Universitat Wurzburg wol @informatik.uni-wuerzburg.de Abstract: In this article we brie y discuss the advantages and disadvantages of the language Java for scienti c computing. We concentrate on Java's typ e system, investi- gate its supp ort for hierarchical and generic programming and then discuss the features of its oating-p oint arithmetic. Having found the weak p oints of the language we pro- p ose workarounds using Java itself as long as p ossible. 1 Typ e System Java distinguishes b etween primitive and reference typ es. Whereas this distinc- tion seems to b e very natural and helpful { so the primitives which comprise all standard numerical data typ es have the usual value semantics and expression concept, and the reference semantics of the others allows to avoid p ointers at all{ it also causes some problems. For the reference typ es, i.e. arrays, classes and interfaces no op erators are available or may b e de ned and expressions can only b e built by metho d calls. Several variables may simultaneously denote the same ob ject. This is certainly strange in a numerical setting, but not to avoid, since classes have to b e used to intro duce higher data typ es. On the other hand, the simple hierarchy of classes with the ro ot Object clearly b elongs to the advantages of the language. It is also used to intro duce further concepts like exception handling, which thus is fully integrated in the ob ject oriented avor of the language and as extendeble as all other classes. Multidimensional arrays in Javahave to b e handled as arrays of arrays. This means that there is no guarantee that a matrix is allo cated in contiguous space. Certainly most numerical algorithms will su er from that fact. In a p olymorphic environment it often is helpful to get information ab out the current sp eci c typ e of an ob ject at runtime. This can b e achieved by the metho d getClass which returns the typ e as a constant ob ject of the class Class. In that class metho ds to get more information ab out the interface or name of the typ e are provided. 1.1 Workaround: Op erator Overloading Esp ecially the lack of op erator overloading is annoying. It can b e overcome by a precompiler which maps the op erator to metho d calls. Since metho ds may return arbitrary classes this precompiler only has to change the notation of each expression lo cally. So the corresp ondence between the original source and the generated Java program is quite obvious. Using such a precompiler we can also allow for the de nition of user de ned op erator names or symb ols including the determination of its precedence. 12 v. Gudenberg J.W.: Java for Scientific Computing, Pros and Cons 2 Hierarchical Programming The paradigm of hierarchical programming means the classi cation of the data using inheritance. Base class comp osition or programming abstract data typ es are alternate names. We recommend to separate b etween interfaces and imple- mentations of classes as well as to collect common b ehavior in general abstract sup erclasses which then can b e extended for the sp eci c application. This design leads to reusable, easily extendable classes. The separation of interfaces and classes and the use of packages in Java provide a go o d supp ort for clearly structured programs. Since there is only one hierarchy of classes, we always can cast or convert an ob ject of a typ e to its sup ertyp e. This is the usual \is-a" relation in ob ject ori- ented inheritance structures. A conversion in the other direction from sup ertyp e to subtyp e is also p ossible. Hence, if we know the sp eci c typ e of an ob ject, we can make use of its particular features. These downcasts are obtained by writing the name of the destination class in front of the ob ject. In a similar wayupward and downward casting of primitive typ es is p ossible, where we now have the following subtyp e relation. int long float double Note that this relation only indicates the upward direction for casts and do es not mean that there is no information lost, when you convert an int or long to a float. Metho ds are b ound dynamically by default. The mo di er final,however, which can be attached either to a metho d meaning that this metho d can not b e rede ned, or to a whole class which then prohibits the inheritance from this class, op ens p ossibilities for optimization. 3 Generic Programming The paradigm of generic programming in general deals with homogeneous con- tainers, i.e. data structures comp osed of elements of the same typ e. These con- tainers de ne one or several iterators to access all or some of their elements in a sp eci ed order. These iterators then link generally de ned algorithms to the container. In the package java.util a simple iterator interface is provided which can easily b e extended to the user's needs. This style of programming yields a high degree of reuse, since the same structure is preserved. The data structures generally are parameterised by the elementtyp es. The algorithms are further generic with resp ect to the iterators. This kind of parametrization is usually provided by templates, a feature which unfortunatedly is lacking in Java. 3.1 Workaround: Templates In the language manuals it is suggested to use containers of the typ e Object instead and p erform appropriate typ e casts. This do es not work well, since prim- itive typ es are no ob jects, so we can not ll a container with primitive typ es. To cop e with this situation wrapp er classes are included in the language, which simply wrap a constantvalue of the corresp onding primitivetyp e. Since they are ob jects, no op erations are available for wrapp er classes, not even an assignment v. Gudenberg J.W.: Java for Scientific Computing, Pros and Cons 13 of a new value is p ossible. Hence, if wewant to write generic co de for primitive data, wehave to explicitly check the currenttyp e and cast. This kind of co de { a large conditional satement dep ending on typ e of the current ob ject{ has not much to do with ob ject orientation, even if it is encapsulated in a help er class, like NumberHelper [8]. This class provides metho ds for arithmetic op erations for the wrapp er classes which use the prede ned primitive op erations. So this approach only helps for the limited numb er of wrapp er classes. We can provide a similar help er class for higher arithmetic data typ es. The main disadvantage of this approach is that it is not extendable. If we add a new typ e with the same interface, wehave to edit the help er class and to add a new branch in the conditional statement. We might try to overcome the diculty by using the runtime information to get the name of the class of the elements and then cast to it. This, however, can not be compiled, since the syntax requires an identi er and not a string as a typ ename. Therefore, we write a factory class which pro duces a help er class for each elementtyp e. The name of this help er class contains the name of the element class. All help er classes implement one generic interface whichnow replaces the template. The application program calls the makeHelper metho d of the factory class with an ob ject of elementtyp e as parameter. This lo oks for the corresp onding help er class and loads it, if available. If not, it writes the source to a le inserting the ob ject's typ e name where appropriate, compiles this le on the y and then loads the corresp onding class. Since all help ers have identical structure this pro cess of writing and compiling can b e made automaticly. 4 Arithmetic Java is one of very few languages which completely sp ecify the semantics of their oating-p ointtyp es. The IEEE 754 formats sing l e and doubl e have to b e used for the float and double data typ e, resp ectively. All 4 basic arithmetic op era- tions are to b e p erformed with full precision using the rounding to the nearest neighb or. Expression evaluation has to use these basic op erations to compute eachintermediate result, i.e. round after each op eration. This rule ignores the facilities which some hardware units supply, like fused multiply and add or ex- tended temp oraries, and therefore has lead to some discussion [4]. In our opinion this feature of strict expression evaluation is mandatory for a language which claims to get identical results on all computers. And, indeed, this goal is achieved by that rule. So even programs using oating p oint op erations are completely p ortable. An interesting Java extension where expression evaluation may b e switched between this strict mo de and a so-called natural mo de which makes use of ex- tended hardware features and hence pro duces results which are at least as go o d, is discussed in [3].
Load more

Recommended publications
  • The Pros of Cons: Programming with Pairs and Lists
    The Pros of cons: Programming with Pairs and Lists CS251 Programming Languages Spring 2016, Lyn Turbak Department of Computer Science Wellesley College Racket Values • booleans: #t, #f • numbers: – integers: 42, 0, -273 – raonals: 2/3, -251/17 – floang point (including scien3fic notaon): 98.6, -6.125, 3.141592653589793, 6.023e23 – complex: 3+2i, 17-23i, 4.5-1.4142i Note: some are exact, the rest are inexact. See docs. • strings: "cat", "CS251", "αβγ", "To be\nor not\nto be" • characters: #\a, #\A, #\5, #\space, #\tab, #\newline • anonymous func3ons: (lambda (a b) (+ a (* b c))) What about compound data? 5-2 cons Glues Two Values into a Pair A new kind of value: • pairs (a.k.a. cons cells): (cons v1 v2) e.g., In Racket, - (cons 17 42) type Command-\ to get λ char - (cons 3.14159 #t) - (cons "CS251" (λ (x) (* 2 x)) - (cons (cons 3 4.5) (cons #f #\a)) Can glue any number of values into a cons tree! 5-3 Box-and-pointer diagrams for cons trees (cons v1 v2) v1 v2 Conven3on: put “small” values (numbers, booleans, characters) inside a box, and draw a pointers to “large” values (func3ons, strings, pairs) outside a box. (cons (cons 17 (cons "cat" #\a)) (cons #t (λ (x) (* 2 x)))) 17 #t #\a (λ (x) (* 2 x)) "cat" 5-4 Evaluaon Rules for cons Big step seman3cs: e1 ↓ v1 e2 ↓ v2 (cons) (cons e1 e2) ↓ (cons v1 v2) Small-step seman3cs: (cons e1 e2) ⇒* (cons v1 e2); first evaluate e1 to v1 step-by-step ⇒* (cons v1 v2); then evaluate e2 to v2 step-by-step 5-5 cons evaluaon example (cons (cons (+ 1 2) (< 3 4)) (cons (> 5 6) (* 7 8))) ⇒ (cons (cons 3 (< 3 4))
    [Show full text]
  • The Use of UML for Software Requirements Expression and Management
    The Use of UML for Software Requirements Expression and Management Alex Murray Ken Clark Jet Propulsion Laboratory Jet Propulsion Laboratory California Institute of Technology California Institute of Technology Pasadena, CA 91109 Pasadena, CA 91109 818-354-0111 818-393-6258 [email protected] [email protected] Abstract— It is common practice to write English-language 1. INTRODUCTION ”shall” statements to embody detailed software requirements in aerospace software applications. This paper explores the This work is being performed as part of the engineering of use of the UML language as a replacement for the English the flight software for the Laser Ranging Interferometer (LRI) language for this purpose. Among the advantages offered by the of the Gravity Recovery and Climate Experiment (GRACE) Unified Modeling Language (UML) is a high degree of clarity Follow-On (F-O) mission. However, rather than use the real and precision in the expression of domain concepts as well as project’s model to illustrate our approach in this paper, we architecture and design. Can this quality of UML be exploited have developed a separate, ”toy” model for use here, because for the definition of software requirements? this makes it easier to avoid getting bogged down in project details, and instead to focus on the technical approach to While expressing logical behavior, interface characteristics, requirements expression and management that is the subject timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achiev- of this paper. ing the additional aspects of the expression and management of software requirements that stakeholders expect, especially There is one exception to this choice: we will describe our traceability, is far less so.
    [Show full text]
  • Generic Programming
    Generic Programming July 21, 1998 A Dagstuhl Seminar on the topic of Generic Programming was held April 27– May 1, 1998, with forty seven participants from ten countries. During the meeting there were thirty seven lectures, a panel session, and several problem sessions. The outcomes of the meeting include • A collection of abstracts of the lectures, made publicly available via this booklet and a web site at http://www-ca.informatik.uni-tuebingen.de/dagstuhl/gpdag.html. • Plans for a proceedings volume of papers submitted after the seminar that present (possibly extended) discussions of the topics covered in the lectures, problem sessions, and the panel session. • A list of generic programming projects and open problems, which will be maintained publicly on the World Wide Web at http://www-ca.informatik.uni-tuebingen.de/people/musser/gp/pop/index.html http://www.cs.rpi.edu/˜musser/gp/pop/index.html. 1 Contents 1 Motivation 3 2 Standards Panel 4 3 Lectures 4 3.1 Foundations and Methodology Comparisons ........ 4 Fundamentals of Generic Programming.................. 4 Jim Dehnert and Alex Stepanov Automatic Program Specialization by Partial Evaluation........ 4 Robert Gl¨uck Evaluating Generic Programming in Practice............... 6 Mehdi Jazayeri Polytypic Programming........................... 6 Johan Jeuring Recasting Algorithms As Objects: AnAlternativetoIterators . 7 Murali Sitaraman Using Genericity to Improve OO Designs................. 8 Karsten Weihe Inheritance, Genericity, and Class Hierarchies.............. 8 Wolf Zimmermann 3.2 Programming Methodology ................... 9 Hierarchical Iterators and Algorithms................... 9 Matt Austern Generic Programming in C++: Matrix Case Study........... 9 Krzysztof Czarnecki Generative Programming: Beyond Generic Programming........ 10 Ulrich Eisenecker Generic Programming Using Adaptive and Aspect-Oriented Programming .
    [Show full text]
  • A Metaobject Protocol for Fault-Tolerant CORBA Applications
    A Metaobject Protocol for Fault-Tolerant CORBA Applications Marc-Olivier Killijian*, Jean-Charles Fabre*, Juan-Carlos Ruiz-Garcia*, Shigeru Chiba** *LAAS-CNRS, 7 Avenue du Colonel Roche **Institute of Information Science and 31077 Toulouse cedex, France Electronics, University of Tsukuba, Tennodai, Tsukuba, Ibaraki 305-8573, Japan Abstract The corner stone of a fault-tolerant reflective The use of metalevel architectures for the architecture is the MOP. We thus propose a special implementation of fault-tolerant systems is today very purpose MOP to address the problems of general-purpose appealing. Nevertheless, all such fault-tolerant systems ones. We show that compile-time reflection is a good have used a general-purpose metaobject protocol (MOP) approach for developing a specialized runtime MOP. or are based on restricted reflective features of some The definition and the implementation of an object-oriented language. According to our past appropriate runtime metaobject protocol for implementing experience, we define in this paper a suitable metaobject fault tolerance into CORBA applications is the main protocol, called FT-MOP for building fault-tolerant contribution of the work reported in this paper. This systems. We explain how to realize a specialized runtime MOP, called FT-MOP (Fault Tolerance - MetaObject MOP using compile-time reflection. This MOP is CORBA Protocol), is sufficiently general to be used for other aims compliant: it enables the execution and the state evolution (mobility, adaptability, migration, security). FT-MOP of CORBA objects to be controlled and enables the fault provides a mean to attach dynamically fault tolerance tolerance metalevel to be developed as CORBA software. strategies to CORBA objects as CORBA metaobjects, enabling thus these strategies to be implemented as 1 .
    [Show full text]
  • Chapter 15 Functional Programming
    Topics Chapter 15 Numbers n Natural numbers n Haskell numbers Functional Programming Lists n List notation n Lists as a data type n List operations Chapter 15: Functional Programming 2 Numbers Natural Numbers The natural numbers are the numbers 0, 1, Haskell provides a sophisticated 2, and so on, used for counting. hierarchy of type classes for describing various kinds of numbers. Introduced by the declaration data Nat = Zero | Succ Nat Although (some) numbers are provided n The constructor Succ (short for ‘successor’) as primitives data types, it is has type Nat à Nat. theoretically possible to introduce them n Example: as an element of Nat the number 7 through suitable data type declarations. would be represented by Succ(Succ(Succ(Succ(Succ(Succ(Succ Zero)))))) Chapter 15: Functional Programming 3 Chapter 15: Functional Programming 4 Natural Numbers Natural Numbers Every natural number is represented by a Multiplication ca be defined by unique value of Nat. (x) :: Nat à Nat à Nat m x Zero = Zero On the other hand, not every value of Nat m x Succ n = (m x n) + m represents a well-defined natural number. n Example: ^, Succ ^, Succ(Succ ^) Nat can be a member of the type class Eq Addition ca be defined by instance Eq Nat where Zero == Zero = True (+) :: Nat à Nat à Nat Zero == Succ n = False m + Zero = m Succ m == Zero = False m + Succ n = Succ(m + n) Succ m == Succ n = (m == n) Chapter 15: Functional Programming 5 Chapter 15: Functional Programming 6 1 Natural Numbers Haskell Numbers Nat can be a member of the type class Ord instance
    [Show full text]
  • Subtyping on Nested Polymorphic Session Types 3 Types [38]
    Subtyping on Nested Polymorphic Session Types Ankush Das1, Henry DeYoung1, Andreia Mordido2, and Frank Pfenning1 1 Carnegie Mellon University, USA 2 LASIGE, Faculdade de Ciˆencias, Universidade de Lisboa, Portugal Abstract. The importance of subtyping to enable a wider range of well- typed programs is undeniable. However, the interaction between subtyp- ing, recursion, and polymorphism is not completely understood yet. In this work, we explore subtyping in a system of nested, recursive, and polymorphic types with a coinductive interpretation, and we prove that this problem is undecidable. Our results will be broadly applicable, but to keep our study grounded in a concrete setting, we work with an extension of session types with explicit polymorphism, parametric type construc- tors, and nested types. We prove that subtyping is undecidable even for the fragment with only internal choices and nested unary recursive type constructors. Despite this negative result, we present a subtyping algo- rithm for our system and prove its soundness. We minimize the impact of the inescapable incompleteness by enabling the programmer to seed the algorithm with subtyping declarations (that are validated by the al- gorithm). We have implemented the proposed algorithm in Rast and it showed to be efficient in various example programs. 1 Introduction Subtyping is a standard feature in modern programming languages, whether functional, imperative, or object-oriented. The two principal approaches to un- derstanding the meaning of subtyping is via coercions or as subsets. Either way, subtyping allows more programs as well-typed, programs can be more concise, and types can express more informative properties of programs. When it comes to the interaction between advanced features of type systems, specifically recursive and polymorphic types, there are still some gaps in our arXiv:2103.15193v1 [cs.PL] 28 Mar 2021 understanding of subtyping.
    [Show full text]
  • Programming Paradigms
    PROGRAMMING PARADIGMS SNS COLLEGE OF TECHNOLOGY (An Autonomous Institution) COIMBATORE – 35 DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING (UG & PG) Third Year Computer Science and Engineering, 4th Semester QUESTION BANK UNIVERSITY QUESTIONS Subject Code & Name: 16CS206 PROGRAMMING PARADIGMS UNIT-IV PART – A 1. What is an exception? .(DEC 2011-2m) An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions. 2. What is error? .(DEC 2011-2m) An Error indicates that a non-recoverable condition has occurred that should not be caught. Error, a subclass of Throwable, is intended for drastic problems, such as OutOfMemoryError, which would be reported by the JVM itself. 3. Which is superclass of Exception? .(DEC 2011-2m) "Throwable", the parent class of all exception related classes. 4. What are the advantages of using exception handling? .(DEC 2012-2m) Exception handling provides the following advantages over "traditional" error management techniques: Separating Error Handling Code from "Regular" Code. Propagating Errors Up the Call Stack. Grouping Error Types and Error Differentiation. 5. What are the types of Exceptions in Java .(DEC 2012-2m) There are two types of exceptions in Java, unchecked exceptions and checked exceptions. Checked exceptions: A checked exception is some subclass of Exception (or Exception itself), excluding class RuntimeException and its subclasses. Each method must either SNSCT – Department of Compute Science and Engineering Page 1 PROGRAMMING PARADIGMS handle all checked exceptions by supplying a catch clause or list each unhandled checked exception as a thrown exception. Unchecked exceptions: All Exceptions that extend the RuntimeException class are unchecked exceptions.
    [Show full text]
  • Estacada City Council Estacada City Hall, Council Chambers 475 Se Main Street, Estacada, Oregon Monday, January 25, 2016 - 7:00 Pm
    CITY OF ESTACADA AGENDA MAYOR BRENT DODRILL COUNCILOR SEAN DRINKWINE COUNCILOR LANELLE KING COUNCILOR AARON GANT COUNCILOR PAULINA MENCHACA COUNCILOR JUSTIN GATES COUNCILOR DAN NEUJAHR ESTACADA CITY COUNCIL ESTACADA CITY HALL, COUNCIL CHAMBERS 475 SE MAIN STREET, ESTACADA, OREGON MONDAY, JANUARY 25, 2016 - 7:00 PM 1. CALL TO ORDER BY PRESIDING OFFICER (An invocation will be offered prior to call to order) . Pledge of Allegiance . Roll Call 2. CITIZEN AND COMMUNITY GROUP COMMENTS Instructions for providing testimony are located above the information table and the back of this agenda 3. CONSENT AGENDA Council members have the opportunity to move items from the Consent Agenda to Council Business. Council actions are taken in one motion on Consent Agenda Items. a. Approve January 11, 2016 Council minutes b. Approve January 16, 2016 Council Retreat minutes c. System Development Charge Annual Report 2015 Estacada Urban Renewal District Annual Report 2014-15 d. OLCC Annual Renewals 4. DEPARTMENT & COMMITTEE REPORTS a. Committee, Commission and Liaison b. City Manager Report c. Mayor Report 5. COUNCIL BUSINESS Items may be added from the Consent Agenda upon request of the Mayor or Councilor. a. SECOND CONSIDERATION – Ordinance Series of 2016 – 001 – An ordinance amending Section 5.04.020 D. of the Estacada Municipal Code regarding business and occupation licenses. b. 2016 Council Goals 6. CITIZEN AND COMMUNITY GROUP COMMENTS Instructions for providing testimony are located above the information table and the back of this agenda 7. COUNCIL REPORTS & COMMENTS 8. ADJOURNMENT OF MEETING Estacada City Council Meeting January 11, 2016 – Page | 1 ESTACADA CITY COUNCIL MEETING MINUTES ESTACADA CITY HALL, COUNCIL CHAMBERS 475 SE MAIN STREET, ESTACADA, OREGON MONDAY, JANUARY 11, 2016 - 7:00 PM CALL TO ORDER BY PRESIDING OFFICER The meeting was called to order at 7:00pm.
    [Show full text]
  • Static Reflection
    N3996- Static reflection Document number: N3996 Date: 2014-05-26 Project: Programming Language C++, SG7, Reflection Reply-to: Mat´uˇsChochl´ık([email protected]) Static reflection How to read this document The first two sections are devoted to the introduction to reflection and reflective programming, they contain some motivational examples and some experiences with usage of a library-based reflection utility. These can be skipped if you are knowledgeable about reflection. Section3 contains the rationale for the design decisions. The most important part is the technical specification in section4, the impact on the standard is discussed in section5, the issues that need to be resolved are listed in section7, and section6 mentions some implementation hints. Contents 1. Introduction4 2. Motivation and Scope6 2.1. Usefullness of reflection............................6 2.2. Motivational examples.............................7 2.2.1. Factory generator............................7 3. Design Decisions 11 3.1. Desired features................................. 11 3.2. Layered approach and extensibility...................... 11 3.2.1. Basic metaobjects........................... 12 3.2.2. Mirror.................................. 12 3.2.3. Puddle.................................. 12 3.2.4. Rubber................................. 13 3.2.5. Lagoon................................. 13 3.3. Class generators................................ 14 3.4. Compile-time vs. Run-time reflection..................... 16 4. Technical Specifications 16 4.1. Metaobject Concepts.............................
    [Show full text]
  • Libraries for Generic Programming in Haskell
    Libraries for Generic Programming in Haskell Johan Jeuring, Sean Leather, Jos´ePedroMagalh˜aes, and Alexey Rodriguez Yakushev Universiteit Utrecht, The Netherlands Abstract. These lecture notes introduce libraries for datatype-generic program- ming in Haskell. We introduce three characteristic generic programming libraries: lightweight implementation of generics and dynamics, extensible and modular generics for the masses, and scrap your boilerplate. We show how to use them to use and write generic programs. In the case studies for the different libraries we introduce generic components of a medium-sized application which assists a student in solving mathematical exercises. 1 Introduction In the development of software, structuring data plays an important role. Many pro- gramming methods and software development tools center around creating a datatype (or XML schema, UML model, class, grammar, etc.). Once the structure of the data has been designed, a software developer adds functionality to the datatypes. There is always some functionality that is specific for a datatype, and part of the reason why the datatype has been designed in the first place. Other functionality is similar or even the same on many datatypes, following common programming patterns. Examples of such patterns are: – in a possibly large value of a complicated datatype (for example for representing the structure of a company), applying a given action at all occurrences of a par- ticular constructor (e.g., adding or updating zip codes at all occurrences of street addresses) while leaving the rest of the value unchanged; – serializing a value of a datatype, or comparing two values of a datatype for equality, functionality that depends only on the structure of the datatype; – adapting data access functions after a datatype has changed, something that often involves modifying large amounts of existing code.
    [Show full text]
  • CONS Should Not CONS Its Arguments, Or, a Lazy Alloc Is a Smart Alloc Henry G
    CONS Should not CONS its Arguments, or, a Lazy Alloc is a Smart Alloc Henry G. Baker Nimble Computer Corporation, 16231 Meadow Ridge Way, Encino, CA 91436, (818) 501-4956 (818) 986-1360 (FAX) November, 1988; revised April and December, 1990, November, 1991. This work was supported in part by the U.S. Department of Energy Contract No. DE-AC03-88ER80663 Abstract semantics, and could profitably utilize stack allocation. One would Lazy allocation is a model for allocating objects on the execution therefore like to provide stack allocation for these objects, while stack of a high-level language which does not create dangling reserving the more expensive heap allocation for those objects that references. Our model provides safe transportation into the heap for require it. In other words, one would like an implementation which objects that may survive the deallocation of the surrounding stack retains the efficiency of stack allocation for most objects, and frame. Space for objects that do not survive the deallocation of the therefore does not saddle every program with the cost for the surrounding stack frame is reclaimed without additional effort when increased flexibility--whether the program uses that flexibility or the stack is popped. Lazy allocation thus performs a first-level not. garbage collection, and if the language supports garbage collection The problem in providing such an implementation is in determining of the heap, then our model can reduce the amortized cost of which objects obey LIFO allocation semantics and which do not. allocation in such a heap by filtering out the short-lived objects that Much research has been done on determining these objects at can be more efficiently managed in LIFO order.
    [Show full text]
  • First-Class Functions and Patterns
    First-class Functions and Patterns Corky Cartwright Stephen Wong Department of Computer Science Rice University 1 Encoding First-class Functions in Java • Java methods are not data values; they cannot be used as values. • But java classes include methods so we can implicitly pass methods (functions) by passing class instances containing the desired method code. • Moreover, Java includes a mechanism that closes over the free variables in the method definition! • Hence, first-class functions (closures) are available implicitly, but the syntax is wordy. • Example: Scheme map 2 Interfaces for Representing Functions For accurate typing, we need different interfaces for different arities. With generics, we can define parameterized interfaces for each arity. In the absence of generics, we will have to define separate interfaces for each desired typing. map example: /** The type of unary functions in Object -> Object. */ interface Lambda { Object apply(Object arg); } abstract class ObjectList { ObjectList cons(Object n) { return new ConsObjectList(n, this); } abstract ObjectList map(Lambda f); } ... 3 Representing Specific Functions • For each function that we want to use a value, we must define a class, preferably a singleton. Since the class has no fields, all instances are effectively identical. • Defining a class seems unduly heavyweight, but it works in principle. • In OO parlance, an instance of such a class is called a strategy. • Java provides a lightweight notation for singleton classes called anonymous classes. Moreover these classes can refer to fields and final method variables that are in scope. In DrJava language levels, all variables are final. final fields and variables cannot be rebound to new values after they are initially defined (immutable).
    [Show full text]