Results 1 - 10
of
41
An Efficient Implementation of Self, a Dynamically-Typed Object-Oriented Language Based on Prototypes
, 1991
"... . We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF's lack of classes and explicit variables. To compensate for the absence of class ..."
Abstract
-
Cited by 150 (24 self)
- Add to MetaCart
. We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF's lack of classes and explicit variables. To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information and eliminating the apparent space overhead for prototype-based systems. To compensate for dynamic typing, user-defined control structures, and the lack of explicit variables, our system dynamically compiles multiple versions of a source method, each customized according to its receiver's map. Within each version the type of the receiver is fixed, and thus the compiler can statically bind and inline all messages sent to self. Message splitting and type prediction extract and preserve even more static type information, allowing the compiler to inline ma...
The Design and Implementation of the SELF Compiler, an Optimizing Compiler for Object-Oriented Programming Languages
, 1992
"... Object-oriented programming languages promise to improve programmer productivity by supporting abstract data types, inheritance, and message passing directly within the language. Unfortunately, traditional implementations of object-oriented language features, particularly message passing, have been ..."
Abstract
-
Cited by 120 (15 self)
- Add to MetaCart
Object-oriented programming languages promise to improve programmer productivity by supporting abstract data types, inheritance, and message passing directly within the language. Unfortunately, traditional implementations of object-oriented language features, particularly message passing, have been much slower than traditional implementations of their non-object-oriented counterparts: the fastest existing implementation of Smalltalk-80 runs at only a tenth the speed of an optimizing C implementation. The dearth of suitable implementation technology has forced most object-oriented languages to be designed as hybrids with traditional non-object-oriented languages, complicating the languages and making programs harder to extend and reuse. This dissertation describes a collection of implementation techniques that can improve the run-time performance of object-oriented languages, in hopes of reducing the need for hybrid languages and encouraging wider spread of purely object-oriented langu...
Making Pure Object-Oriented Languages Practical
- In OOPSLA '91 Conference Proceedings
, 1991
"... In the past, object-oriented language designers and programmers have been forced to choose between pure message passing and performance. Last year, our SELF system achieved close to half the speed of optimized C but suffered from impractically long compile times. Two new optimization techniques, def ..."
Abstract
-
Cited by 117 (20 self)
- Add to MetaCart
In the past, object-oriented language designers and programmers have been forced to choose between pure message passing and performance. Last year, our SELF system achieved close to half the speed of optimized C but suffered from impractically long compile times. Two new optimization techniques, deferred compilation of uncommon cases and non-backtracking splitting using path objects, have improved compilation speed by more than an order of magnitude. SELF now compiles about as fast as an optimizing C compiler and runs at over half the speed of optimized C. This new level of performance may make pure object-oriented languages practical. 1 Introduction In the past, object-oriented language designers and programmers have been forced to choose between purity and performance. In a pure object-oriented language, all computation, even low-level operations like variable accessing, arithmetic, and array indexing, is performed by sending messages to objects. Although a message send may cost o...
The Cecil Language, Specification and Rationale
, 1993
"... Cecil is a new purely object-oriented language intended to support rapid construction of highquality, extensible software. Cecil combines multi-methods with a classless object model, object-based encapsulation, and optional static type checking. Cecil's static type system distinguishes between subty ..."
Abstract
-
Cited by 109 (20 self)
- Add to MetaCart
Cecil is a new purely object-oriented language intended to support rapid construction of highquality, extensible software. Cecil combines multi-methods with a classless object model, object-based encapsulation, and optional static type checking. Cecil's static type system distinguishes between subtyping and code inheritance, but Cecil enables these two graphs to be described with a single set of declarations, optimizing the common case where the two graphs are parallel. Cecil includes a fairly flexible form of parameterization, including both explicitly parameterized objects, types, and methods and implicitly parameterized methods related to the polymorphic functions commonly found in functional languages. By making type declarations optional, Cecil aims to support mixed exploratory and production programming styles. This document describes the design of the Cecil language as of March, 1993. It mixes the specification of the language with discussions of design issues and explanations of...
A Proposal for Making Eiffel Type-Safe
- The Computer Journal
, 1989
"... Statically type-correct Ei#el programs may produce run-time errors because (1) attributes may be redeclared during inheritance, invalidating assignments in the superclass, (2) a formal method argument type may be restricted in violation of the contravariance of function types, and (3) two applic ..."
Abstract
-
Cited by 108 (1 self)
- Add to MetaCart
Statically type-correct Ei#el programs may produce run-time errors because (1) attributes may be redeclared during inheritance, invalidating assignments in the superclass, (2) a formal method argument type may be restricted in violation of the contravariance of function types, and (3) two applications of a generic class are assumed to conform if the actual arguments conform. The third problem is solved by case analysis on the variance of generic parameters. Declaration by association provides a solution to the first two problems, but it suffers from additional di#culties. Type attributes, or generic parameters with default values, are suggested as a replacement for most cases of declaration by association. The special association type used to express type recursion cannot be explained using type attributes, and it appears to be a truly novel construct for typing object-oriented programs.
Optimizing dynamically-typed object-oriented languages with polymorphic inline caches
, 1991
"... Abstract. We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF’s lack of classes and explicit variables. To compensate for the absence ..."
Abstract
-
Cited by 105 (9 self)
- Add to MetaCart
Abstract. We have developed and implemented techniques that double the performance of dynamically-typed object-oriented languages. Our SELF implementation runs twice as fast as the fastest Smalltalk implementation, despite SELF’s lack of classes and explicit variables. To compensate for the absence of classes, our system uses implementation-level maps to transparently group objects cloned from the same prototype, providing data type information and eliminating the apparent space overhead for prototype-based systems. To compensate for dynamic typing, user-defined control structures, and the lack of explicit variables, our system dynamically compiles multiple versions of a source method, each customized according to its receiver’s map. Within each version the type of the receiver is fixed, and thus the compiler can statically bind and inline all messages sent to self. Message splitting and type prediction extract and preserve even more static type information, allowing the compiler to inline many other messages. Inlining dramatically improves performance and eliminates the need to hard-wire low-level methods such as +, ==, and ifTrue:. Despite inlining and other optimizations, our system still supports interactive programming environments. The system traverses internal dependency lists to invalidate all compiled methods
Subtypes vs. Where Clauses: Constraining Parametric Polymorphism
- In Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA
, 1995
"... All object-oriented languages provide support for subtype polymorphism, which allows the writing of generic code that works for families of related types. There is also a need, however, to write code that is generic across types that have no real family relationship. To satisfy this need a programmi ..."
Abstract
-
Cited by 75 (12 self)
- Add to MetaCart
All object-oriented languages provide support for subtype polymorphism, which allows the writing of generic code that works for families of related types. There is also a need, however, to write code that is generic across types that have no real family relationship. To satisfy this need a programming language must provide a mechanism for parametric polymorphism, allowing for types as parameters to routines and types. We show that to support modular programming and separate compilation there must be a mechanism for constraining the actual parameters of the routine or type. We describe a simple and powerful constraint mechanism and compare it with constraint mechanisms in other languages in terms of both ease of use and semantic expressiveness. We also discuss the interaction between subtype and parametric polymorphism: we discuss the subtype relations that can exist between instantiations of parameterized types, and which of those relations are useful and can be implemented efficiently...
The Design of the E Programming Language
- ACM Transactions on Programming Languages and Systems
, 1993
"... E is an extension of C++ designed for writing software systems to support persistent applications. Originally designed as a language for implementing database systems, E has evolved into a general persistent programming language E was the first C++ extension to support transparent persistence, the f ..."
Abstract
-
Cited by 57 (3 self)
- Add to MetaCart
E is an extension of C++ designed for writing software systems to support persistent applications. Originally designed as a language for implementing database systems, E has evolved into a general persistent programming language E was the first C++ extension to support transparent persistence, the first C++ implementation to support generic classes, and remains the only C++ extension to provide general-purpose lterators, In addition to its contributions to the C + + programming domain, work on E has made several contributions to the field of persmtent languages in general, including several distinct implementations of persistence. Thm paper describes the main features of E and shows through examples how E addresses many of the problems that arise in building persistent systems.
The Cecil language -- specification and rationale: Version 3.2
, 2004
"... Cecil is a purely object-oriented language intended to support rapid construction of high-quality, extensible software. Cecil combines multi-methods with a simple classless object model, a kind of dynamic inheritance, modules, and optional static type checking. Instance variables in Cecil are access ..."
Abstract
-
Cited by 49 (4 self)
- Add to MetaCart
Cecil is a purely object-oriented language intended to support rapid construction of high-quality, extensible software. Cecil combines multi-methods with a simple classless object model, a kind of dynamic inheritance, modules, and optional static type checking. Instance variables in Cecil are accessed solely through messages, allowing instance variables to be replaced or overridden by methods and vice versa. Cecil’s predicate objects mechanism allows an object to be classified automatically based on its run-time (mutable) state. Cecil’s static type system distinguishes between subtyping and code inheritance, but Cecil enables these two graphs to be described with a single set of declarations, streamlining the common case where the two graphs are parallel. Cecil includes a fairly flexible form of parameterization, including explicitly parameterized objects, types, and methods, as well as implicitly parameterized methods related to the polymorphic functions commonly found in functional languages. By making type declarations optional, Cecil aims to allow mixing of and migration between exploratory and production programming styles. Cecil supports a module mechanism that enables independently-developed subsystems to be encapsulated, allowing them to be type-checked and reasoned about in isolation despite the presence of multi-methods and subclassing. Objects can be extended externally with additional
A Survey of Object-Oriented Concepts
- OBJECT-ORIENTED CONCEPTS, DATABASES AND APPLICATIONS
, 1989
"... The object-oriented paradigm has gained popularity in various guises not only in programming languages, but in user interfaces, operating systems, databases, and other areas. We argue that the fundamental object-oriented concept is encapsulation, and that all object-oriented mechanisms and approac ..."
Abstract
-
Cited by 44 (5 self)
- Add to MetaCart
The object-oriented paradigm has gained popularity in various guises not only in programming languages, but in user interfaces, operating systems, databases, and other areas. We argue that the fundamental object-oriented concept is encapsulation, and that all object-oriented mechanisms and approaches exploit this idea to various ends. We introduce the most important of these mechanisms as they are manifested in existing object-oriented systems, and we discuss their relevance in the context of modern application development.

