Results 1 -
6 of
6
Beyond Static and Dynamic Scope
"... Traditional treatment of scoping in programming languages considers two opposite semantics: static scoping, where the scope of a binding is a block of program text, and dynamic scoping, where a binding is in effect during the whole reduction of an expression to a value. Static scoping and dynamic sc ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
Traditional treatment of scoping in programming languages considers two opposite semantics: static scoping, where the scope of a binding is a block of program text, and dynamic scoping, where a binding is in effect during the whole reduction of an expression to a value. Static scoping and dynamic scoping are however but two points in the design space of scoping mechanisms. As a result, most proposed language mechanisms that rely on some notion of scoping, such as variable bindings of course, but also more exotic ones like aspects and mixin layers, adopt either one or the other semantics. As it turns out, these two semantics are sometimes too extreme, and a mixture of both is needed. To achieve this, language designers and/or programmers have to resort to ad hoc solutions. We present a general scoping model that simply expresses static and dynamic scoping, and that goes further by allowing fine-grained exploration of the design space of scoping. The model, called scoping strategies, gives precise control over propagation and activation of language mechanisms. While we have already studied it for aspects, we hereby show that the model is not restricted to aspects, by treating in depth its application to the most standard kind of adaptation: variable bindings. We also briefly discuss its application to mixin layers, and program monitoring. We believe that research in programming language constructs can benefit from a more flexible notion of scoping that goes beyond the static/dynamic dichotomy.
The essence of static and dynamic bindings
- In ICTCS’09
, 2009
"... Static binding is the standard binding discipline in programming languages. However, the demands of developing distributed, highly dynamic applications have led to an increasing interest in dynamic programming languages and mechanisms. Typically, this needs are satisfied by hoc mechanisms that lack ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
Static binding is the standard binding discipline in programming languages. However, the demands of developing distributed, highly dynamic applications have led to an increasing interest in dynamic programming languages and mechanisms. Typically, this needs are satisfied by hoc mechanisms that lack clean semantics. In this paper, we adopt a foundational approach, developing a core dynamic
Composing New Abstractions From Object Fragments Adrian Kuhn and Oscar Nierstrasz Software Composition Group
"... As object-oriented languages are extended with novel modularization mechanisms, better underlying models are required to implement these high-level features. This paper describes CELL, a language model that builds on delegationbased chains of object fragments. Composition of groups of cells is used: ..."
Abstract
- Add to MetaCart
As object-oriented languages are extended with novel modularization mechanisms, better underlying models are required to implement these high-level features. This paper describes CELL, a language model that builds on delegationbased chains of object fragments. Composition of groups of cells is used: 1) to represent objects, 2) to realize various forms of method lookup, and 3) to keep track of method references. A running prototype of CELL is provided and used to realize the basic kernel of a Smalltalk system. The paper shows, using several examples, how higher-level features such as traits can be supported by the lower-level model. 1.
Lessons in Software Evolution Learned by Listening to Smalltalk ⋆
"... Abstract. The biggest challenge facing software developers today is how to gracefully evolve complex software systems in the face of changing requirements. We clearly need software systems to be more dynamic, compositional and model-centric, but instead we continue to build systems that are static, ..."
Abstract
- Add to MetaCart
Abstract. The biggest challenge facing software developers today is how to gracefully evolve complex software systems in the face of changing requirements. We clearly need software systems to be more dynamic, compositional and model-centric, but instead we continue to build systems that are static, baroque and inflexible. How can we better build change-enabled systems in the future? To answer this question, we propose to look back to one of the most successful systems to support change, namely Smalltalk. We briefly introduce Smalltalk with a few simple examples, and draw some lessons for software evolution. Smalltalk’s simplicity, its reflective design, and its highly dynamic nature all go a long way towards enabling change in Smalltalk applications. We then illustrate how these lessons work in practice by reviewing a number of research projects that support software evolution by exploiting Smalltalk’s design. We conclude by summarizing open issues and challenges for change-enabled systems of the future. 1
Intersection types for unbind and rebind (Extended Abstract) ∗
"... We define a type system with intersection types for an extension of lambda-calculus with unbind and rebind operators. In this calculus, a term t with free variables x1,...,xn, representing open code, can be packed into an unbound term 〈 x1,...,xn | t 〉, and passed around as a value. In order to exec ..."
Abstract
- Add to MetaCart
We define a type system with intersection types for an extension of lambda-calculus with unbind and rebind operators. In this calculus, a term t with free variables x1,...,xn, representing open code, can be packed into an unbound term 〈 x1,...,xn | t 〉, and passed around as a value. In order to execute inside code, an unbound term should be explicitly rebound at the point where it is used. Unbinding and rebinding are hierarchical, that is, the term t can contain arbitrarily nested unbound terms, whose inside code can only be executed after a sequence of rebinds has been applied. Correspondingly, types are decorated with levels, and a term has type τ k if it needs k rebinds in order to reduce to a value of type τ. With intersection types we model the fact that a term can be used differently in contexts providing a different numbers of unbinds. In particular, top-level terms, that is, terms not requiring unbinds to reduce to values, should have a value type, that is, an intersection type where at least one element has level 0. With the proposed intersection type system we get soundness under the call-by-value strategy, an issue which was not resolved by previous type systems.
Theoretical Informatics and Applications Informatique Théorique et Applications Will be set by the publisher EXTENDING LAMBDA-CALCULUS WITH UNBIND AND REBIND
"... Abstract. We extend the simply typed λ-calculus with unbind and rebind primitive constructs. That is, a value can be a fragment of open code, which in order to be used should be explicitly rebound. This mechanism nicely coexists with standard static binding. The motivation is to provide an unifying ..."
Abstract
- Add to MetaCart
Abstract. We extend the simply typed λ-calculus with unbind and rebind primitive constructs. That is, a value can be a fragment of open code, which in order to be used should be explicitly rebound. This mechanism nicely coexists with standard static binding. The motivation is to provide an unifying foundation for mechanisms of dynamic scoping, where the meaning of a name is determined at runtime, rebinding, such as dynamic updating of resources and exchange of mobile code, and delegation, where an alternative action is taken if a binding is missing. Depending on the application scenario, we consider two extensions which differ in the way type safety is guaranteed. The former relies on a combination of static and dynamic type checking. That is, rebind raises a dynamic error if for some variable there is no replacing term or it has the wrong type. In the latter, this error is prevented by a purely static type system, at the price of more sophisticated types. 1991 Mathematics Subject Classification. 68N15, 68N18.

