Results 1 - 10
of
33
Type systems
- The Computer Science and Engineering Handbook
, 1997
"... This paper presents an overview of the programming language Modula-3, and a more detailed description of its type system. 1 ..."
Abstract
-
Cited by 187 (1 self)
- Add to MetaCart
This paper presents an overview of the programming language Modula-3, and a more detailed description of its type system. 1
Component-Oriented Software Technology
, 1995
"... Modernsoft aresystE0 are increasingly requiredt be open and dist ibut81 Suchsyst08 are opennot only int erms ofnet orkconnectR06 andint0 operabilit support forhet1 ogeneous hardware andsoft are plat orms,but above all, int2 ms of evolving and changingrequirement . Alt169, object,7 ient3 t331,7E8 off ..."
Abstract
-
Cited by 50 (9 self)
- Add to MetaCart
Modernsoft aresystE0 are increasingly requiredt be open and dist ibut81 Suchsyst08 are opennot only int erms ofnet orkconnectR06 andint0 operabilit support forhet1 ogeneous hardware andsoft are plat orms,but above all, int2 ms of evolving and changingrequirement . Alt169, object,7 ient3 t331,7E8 offers some relief,t o a largeext27 t he languages,met2R8 andtd,2 fail t addresstd needs of opensystE3 becausetc y donot escape from tadit192, models of soft are development tpm assume syst, requirement t be closed and st ble.We argue te, open systE8 requirement can only beadequat7E addressed byadopt9, a component,t ient0 as opposedt a purelyobject3E ient2 soft are development approach, byshift7, emphasis away from programming and t wards generalizedsoft arecomposit739 1.1 IntrotrWk5k There has been ac8P8("NP( trend in the development of softwareapplic("NP( away from crom"5 proprietary systems towardsso-c)55( open systems. This trendce be largely attributed to the rapid advancE inc")PPFE hardware tec)F5E"N that have vastlyincy"H5F the cAAF("N)5jjF power available to end-userapplic"P(HHj With new possibilitiescos new needs: in order to survive,c"))AAF" ve businesses must be able to effec) vely exploit newtecP"N)P( as itbecj() available, so existingapplicP)Pjj must be able to work with new, independently developed systems. Wec) see, then, that open systems must be "open" in at least three important ways [49]: 1. Topology: openapplic)E"NE run onc)jEH("NEj networks. 2. PlatF'"A the hardware and software platforms are heterogeneous. 3. EvolutAD' requirements are unstable andc"P(AA)"N ccP(A *In ObjectADL/F/"t Softct CompositL/ , O. Nierstrasz and D. Tsic5A"NE) (Ed.),Prentic Hall, 1995, pp. 3-28. For more information, please see:http://iamw3(0(0(0(0(w157(158(159 4 Componen...
Requirements for a Composition Language
, 1995
"... Abstract The keyrequiwD6( for open systemsi that they be flexi55N or recomposab7 .Thi suggests that they must first of all be composable.Object-oriw2+ techniori help by allowio appli))1wD6 to be vi wed ascomposiD6+ of collaborati ( objects, but areliw2+ i supportiD other kier ofabstracti6+ that ma ..."
Abstract
-
Cited by 47 (6 self)
- Add to MetaCart
Abstract The keyrequiwD6( for open systemsi that they be flexi55N or recomposab7 .Thi suggests that they must first of all be composable.Object-oriw2+ techniori help by allowio appli))1wD6 to be vi wed ascomposiD6+ of collaborati ( objects, but areliw2+ i supportiD other kier ofabstracti6+ that may have finer or coarsergranulari2 than objects. Acomposi676 language supports thetechni21 requi21wD67 of acomponent-orii development approach by shi62+N emphasi from programmiD andiw151+NwD6 of classes tospeci)wD657 andcomposiwD6 of components. Objects are vi wed as processes, and components areabstracti61 over the object space.Anappli(wD61 i vi wed as an expli5+ composiw62 of software components. Bymaki6 softwarearchiew15) expli51 andmani)2+wD62 we expect to better support applitw62+ evolutiN and flexi2(7( . Inthi posi267 paper wewi5 elaborate ourrequi27wD6N andoutli( a strategy for the desi6 andiw2111)wD7)N) of acomposi7)N language for the development of open systems. * In Proceedi+ of the...
On subtyping and matching
- In Proceedings ECOOP '95
, 1995
"... Abstract. A relation between recursive object types, called matching, has been proposed as a generalization of subtyping. Unlike subtyping, matching does not support subsumption, but it does support inheritance of binary methods. We argue that matching is a good idea, but that it should not be regar ..."
Abstract
-
Cited by 45 (3 self)
- Add to MetaCart
Abstract. A relation between recursive object types, called matching, has been proposed as a generalization of subtyping. Unlike subtyping, matching does not support subsumption, but it does support inheritance of binary methods. We argue that matching is a good idea, but that it should not be regarded as a form of F-bounded subtyping (as was originally intended). We show that a new interpretation of matching as higher-order subtyping has better properties. Matching turns out to be a third-order construction, possibly the only one to have been proposed for general use in programming.
The Recursive Record Semantics of Objects Revisited
- Journal of Functional Programming
, 2001
"... In a call-by-value language, representing objects as recursive records requires using an unsafe fixpoint. We design, for a core language including extensible records, a type system which rules out unsafe recursion and still supports the reconstruction of a principal type. We illustrate the expressiv ..."
Abstract
-
Cited by 33 (1 self)
- Add to MetaCart
In a call-by-value language, representing objects as recursive records requires using an unsafe fixpoint. We design, for a core language including extensible records, a type system which rules out unsafe recursion and still supports the reconstruction of a principal type. We illustrate the expressive power of this language with respect to object-oriented programming by introducing a sub-language for "mixin-based" programming.
Notes on Typed Object-Oriented Programming
- In Proceedings of Theoretical Aspects of Computer Software
, 1994
"... . This paper, which is partly tutorial in nature, summarizes some basic research goals in the study and development of typed objectoriented programming languages. These include both immediate repairs to problems with existing languages and the long-term development of more flexible and expressive, y ..."
Abstract
-
Cited by 32 (2 self)
- Add to MetaCart
. This paper, which is partly tutorial in nature, summarizes some basic research goals in the study and development of typed objectoriented programming languages. These include both immediate repairs to problems with existing languages and the long-term development of more flexible and expressive, yet type-safe, approaches to program organization and design. We summarize and compare three object models used in the theoretical literature. We also consider approaches to a few technical problems, including changes in the type of a method (member function) from super (base) class to sub (derived) class and the use of types that give information about the implementations as well as the interfaces of objects. Such implementation types seem essential for adequate typing of binary operations on objects, for example. 1 Introduction A number of largely "theoretical" research efforts over the last five to ten years have developed and analyzed type systems for model object-oriented languages. Thi...
The Development of Type Systems for Object-Oriented Languages
, 1996
"... This paper, which is partly tutorial in nature, summarizes some basic research goals in the study and development of typed object-oriented programming languages. These include both immediate repairs to problems with existing languages and the long-term development of more flexible and expressive, ye ..."
Abstract
-
Cited by 30 (2 self)
- Add to MetaCart
This paper, which is partly tutorial in nature, summarizes some basic research goals in the study and development of typed object-oriented programming languages. These include both immediate repairs to problems with existing languages and the long-term development of more flexible and expressive, yet type-safe, approaches to program organization and design. The technical part of the paper is a summary and comparison of three object models from the literature. We conclude by discussing approaches to selected research problems, including changes in the type of a method from super class to sub class and the use of types that give information about the implementations as well as the interfaces of objects. Such implementation types seem essential for adequate typing of binary operations on objects, for example. 1 Introduction A number of largely "theoretical" research efforts over the last five to ten years have developed and analyzed type systems for model object-oriented languages. This ...
Typing in object-oriented languages: Achieving expressiveness and safety
- Computing Surveys
, 1996
"... While simple static-typing disciplines exist for object-oriented languages like C++, Java, and Object Pascal, they are often so inflexible that programmers are forced to use type casts to get around the restrictions. At the other extreme are languages like Beta and Eiffel, which allow more freedom, ..."
Abstract
-
Cited by 29 (1 self)
- Add to MetaCart
While simple static-typing disciplines exist for object-oriented languages like C++, Java, and Object Pascal, they are often so inflexible that programmers are forced to use type casts to get around the restrictions. At the other extreme are languages like Beta and Eiffel, which allow more freedom, but require run-time or link-time checking to pick up the type errors that their type systems are unable to detect at compile time. This paper presents a collection of sample programs which illustrate problems with existing type systems, and suggests ways of improving the expressiveness of these systems while retaining static type safety. In particular we will discuss the motivations behind introducing "MyType", "matching", and "match-bounded polymorphism" into these type systems. We also suggest a way of simplifying the resulting type system by replacing subtyping by a type system with a new type construct based on matching. Both systems provide for binary methods, which are often difficult...
A Lambda-Calculus for Dynamic Binding
- Theoretical Computer Science
, 1997
"... This paper proposes N , a compact extension of the -calculus to model dynamic binding, where variables are labelled by names, and where arguments are passed to functions along named channels. The resulting formalism preserves familiar properties of the -calculus, has a Curry-style type inference sys ..."
Abstract
-
Cited by 26 (2 self)
- Add to MetaCart
This paper proposes N , a compact extension of the -calculus to model dynamic binding, where variables are labelled by names, and where arguments are passed to functions along named channels. The resulting formalism preserves familiar properties of the -calculus, has a Curry-style type inference system, and has a formal notion of compatibility for reasoning about extensible environments. It can encode record and record extensions, as well as first-class contexts with context-filling operations, and therefore provides a basic framework for expressing a wide range of name-based coordination mechanisms. An experimental functional language based on N illustrates the exploitation of dynamic binding in programming language design. 1 Introduction Computer systems are required to be increasingly "open" --- able to dynamically interact with other, possibly unknown or weakly specified systems, and able to coordinate together a global computation. In order to follow this evolution, computational models pay ever increasing attention to notions such as concurrency and distribution. However, open systems also often depend on another concept, more or less orthogonal to the previous ones, and which seems to have been less investigated in theoretical studies: dynamic binding.

