Type-Safe linking with recursive DLLs and shared libraries

Duggan, Dominic

doi:10.1145/586088.586093

Cited by 21 publications

(10 citation statements)

References 39 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…By focusing primarily on this property here, this paper extends our past studies, from different perspectives, of component dependency and linking [42,27,28]. Linkingespecially its theoretical foundations and type properties -has been extensively studied and well-understood [6,19,20,14,13]. However, previous studies do not adequately take into account the when and where of linking: Does it happen at build time, installation time, or run time?…”

Section: This Workmentioning

confidence: 93%

See 1 more Smart Citation

A formal framework for component deployment

Liu

Smith

2006

Proceedings of the 21st Annual ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications

View full text Add to dashboard Cite

Software deployment is a complex process, and industrial-strength frameworks such as .NET, Java, and CORBA all provide explicit support for component deployment. However, these frameworks are not built around fundamental principles as much as they are engineering efforts closely tied to particulars of the respective systems. Here we aim to elucidate the fundamental principles of software deployment, in a platform-independent manner. Issues that need to be addressed include deployment unit design, when, where and how to wire components together, versioning, version dependencies, and hot-deployment of components. We define the application buildbox as the place where software is developed and deployed, and define a formal Labeled Transition System (LTS) on the buildbox with transitions for deployment operations that include build, install, ship, and update. We establish formal properties of the LTS, including the fact that if a component is shipped with a certain version dependency, then at run time that dependency must be satisfied with a compatible version. Our treatment of deployment is both platform-and vendor-independent, and we show how it models the core mechanisms of the industrial-strength deployment frameworks.

show abstract

Section: This Workmentioning

confidence: 93%

“…No formal property was proved, and the framework does not address application evolution in the deployment lifecycle. The linking of DLLs was formalized in [14], where the focus was on type safety.…”

Section: Deployment-related Formalismsmentioning

confidence: 99%

A formal framework for component deployment

Liu

Smith

2006

Proceedings of the 21st Annual ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications

View full text Add to dashboard Cite

show abstract

“…Each variable attribute in this template program makes a reference to a DLL. Module interconnection languages are recognized as an essential tool in managing the complexity of increasingly huge software systems (Duggan, 2002). Furthermore, the dynamic linking is an important requirement for module interconnection languages, as exemplified by DLL and class loaders in operating systems and Java, respectively.…”

Section: Artifacts For Providing System Flexibilitymentioning

confidence: 99%

A systematic design for coping with model risk

Yang

Tsaih

Hsieh

2011

Expert Systems with Applications

View full text Add to dashboard Cite

“…Be that as it may, for the remainder of this paper we will use the term mixin composition to mean Bracha's merge operator. Following mixin-based languages like Flatt et al's units [14,30] and Duggan's recursive DLLs [12], our MixML language does not attempt to support any form of overriding.…”

Section: Imports(m) = Imports(m1)∪imports(m2)−exports(m)mentioning

confidence: 99%

“…One major limitation of Bracha/CMS-style modules, however, is that they contain only term components, not type components, which means that they cannot express ML-style abstract data types, let alone translucent signatures. This has led a number of researchers to consider ways of combining the support for type abstraction found in ML modules with the support for separate compilation and recursive linking found in mixin modules [14,12,29,30]. …”

Section: Imports(m) = Imports(m1)∪imports(m2)−exports(m)mentioning

confidence: 99%

Mixin' up the ML module system

Dreyer

Rossberg

2008

SIGPLAN Not.

View full text Add to dashboard Cite

ML modules provide hierarchical namespace management, as well as fine-grained control over the propagation of type information, but they do not allow modules to be broken up into mutually recursive, separately compilable components. Mixin modules facilitate recursive linking of separately compiled components, but they are not hierarchically composable and typically do not support type abstraction. We synthesize the complementary advantages of these two mechanisms in a novel module system design we call MixML.A MixML module is like an ML structure in which some of the components are specified but not defined. In other words, it unifies the ML structure and signature languages into one. MixML seamlessly integrates hierarchical composition, translucent MLstyle data abstraction, and mixin-style recursive linking. Moreover, the design of MixML is clean and minimalist; it emphasizes how all the salient, semantically interesting features of the ML module system (as well as several proposed extensions to it) can be understood simply as stylized uses of a small set of orthogonal underlying constructs, with mixin composition playing a central role.

show abstract

Type-Safe linking with recursive DLLs and shared libraries

Cited by 21 publications

References 39 publications

A formal framework for component deployment

A formal framework for component deployment

A systematic design for coping with model risk

Mixin' up the ML module system

Contact Info

Product

Resources

About