Results 1 
6 of
6
A Calculus for Dynamic Reconfiguration with Low Priority Linking
 Electonical Notes in Theoretical Computer Science, 2004. In WOOD’04: Workshop on ObjectOriented Developments
, 2004
"... Building on our previous work, we present a simple module calculus where execution steps of a module component can be interleaved with reconfiguration steps (that is, reductions at the module level), and where execution can partly control precedence between these reconfiguration steps. This is achie ..."
Abstract

Cited by 6 (4 self)
 Add to MetaCart
Building on our previous work, we present a simple module calculus where execution steps of a module component can be interleaved with reconfiguration steps (that is, reductions at the module level), and where execution can partly control precedence between these reconfiguration steps. This is achieved by means of a low priority link operator which is only performed when a certain component, which has not been linked yet, is both available and really needed for execution to proceed, otherwise precedence is given to the outer operators. We illustrate the expressive power of this mechanism by a number of examples.
A calculus of components with dynamic typechecking
 Electronic Notes in Theoretical Computer Science, 2006. Formal Aspects of Component Software
, 2006
"... We present a simple module calculus modeling software composition in an open environment, where some components can be provided from the outside after execution has started. Operators for combining software components are as in previous module calculi; here, we focus on the new problems posed by the ..."
Abstract

Cited by 5 (2 self)
 Add to MetaCart
We present a simple module calculus modeling software composition in an open environment, where some components can be provided from the outside after execution has started. Operators for combining software components are as in previous module calculi; here, we focus on the new problems posed by the fact that components are not all available at compile time. In particular, we want to be able to statically check internal consistency of local code, by only specifying a required type for missing components, and then to perform dynamic checks which ensure that code received from the outside, which is assumed to travel with its type, can be successfully accepted, without requiring to typecheck the whole code again. We consider two alternative solutions. The former uses simple dynamic checks based on standard subtyping, that is, a component can be safely combined with local code if it provides the expected features, and all additional features are hidden, thus avoiding conflict problems. The latter preserves the semantics we would get having all components statically available, but requires a more involved type system based on constraints, where dynamic checks prevent conflicts.
A calculus of open modules: callbyneed
"... We present a simple module calculus where selection and execution of a component is possible on open modules, that is, modules which still have to import some definitions from the outside. Hence, it provides a kernel model for a computational paradigm in which standard execution (that is, execution ..."
Abstract
 Add to MetaCart
We present a simple module calculus where selection and execution of a component is possible on open modules, that is, modules which still have to import some definitions from the outside. Hence, it provides a kernel model for a computational paradigm in which standard execution (that is, execution of a single computation described by a fragment of code) can be interleaved with operations at the metalevel which can manipulate in various ways the context in which this computation takes place. Formally, this is achieved by introducing as basic terms configurations, which are, roughly speaking, pairs consisting of an (open, mutually recursive) collection of named components and a term representing a program running in the context of these components. Configurations can be manipulated by classical module/fragment operators, hence reduction steps can be either execution steps of the program or steps which perform module operators (called reconfiguration steps). Since configurations combine the features of lambda abstractions (firstclass functions), records, environments with mutually recursive definitions, and modules, the calculus extends and integrates both traditional module calculi and recursive lambda calculi. We state confluence of the calculus, and propose different ways to prevent errors due to lack of some needed component, either by a purely static type system or by a combination of static and runtime checks. Moreover, we define a callbyneed strategy which performs module simplification only when needed and only once, leading to a generalization, including module features, of callbyneed lambda calculi. We prove soundness and completeness of this strategy using an approach based on information content which also allows to preserve confluence even in case local substitution rules are added to the calculus.
A Module Calculus with Dynamic TypeChecking
"... We present a simple module calculus modeling reconfiguration of code in an open environment, where some software fragments can be provided from the outside and combined with others after execution has started. Software fragments and their composition are modeled as in previous module calculi; her ..."
Abstract
 Add to MetaCart
We present a simple module calculus modeling reconfiguration of code in an open environment, where some software fragments can be provided from the outside and combined with others after execution has started. Software fragments and their composition are modeled as in previous module calculi; here, we focus on the new problems posed by the fact that code fragments are not all available at compile time. In particular, we want to be able to statically check internal consistency of local code, by only specifying a required type for missing code, and then to perform dynamic checks which ensure that code received from the outside, which is assumed to travel with its type, can be successfully accepted, without requiring to typecheck the whole code again. We consider
Celestijnenlaan 200A – B3001 Heverlee (Belgium) Different implementations in Java of a nested loop and their proofs
, 2001
"... In this technical report, we prove the correctness of different implementations of a given specification. This way, we show that using internal iterators dramatically shortens the length of a proof of correctness, and thus the complexity of the code. A remarkable outcome is that introducing a helper ..."
Abstract
 Add to MetaCart
In this technical report, we prove the correctness of different implementations of a given specification. This way, we show that using internal iterators dramatically shortens the length of a proof of correctness, and thus the complexity of the code. A remarkable outcome is that introducing a helper method no longer shortens the proof when internal iterators are used, but makes it longer.