Polylith(ID:7205/pol019)Multiple language algebraic worsktationAlgebraic system that permits multiple languages via MIL Featured a software bus Related languages
References: in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details 1. Introduction. The task of building environments and assistants that are to serve problem solvers haa consistently been a long and expensive ordeal: many staff years and dollars are invested, only to find that our understanding of underlying data objects (and relations between them) is subject to change as our expectations and theory evolve; that new hardware, on which we would like to implement our environments, has so far outstripped software?s capacity to take advantage of the new architectures; that environments built using older software interconnection technologies are typically inflexible in the face of change or extension; and that, in spite of these problems, demand for our area?s product - problem solving environments - is growing in both size and diversity. These types of problems are not unique to our area, and they are not manifest aa a result of any decision made by those who pioneered the implementation of the mathematicians? scratch pads. Instead, these problems reflect more general difficulties extant in the theory of software design. The challenge of constructing a mathematician?s assistant in particular is representative of a wide array of implementation difficulties. The project called Polylith studies environment construction by first addressing those problems embedded in the underlying software interconnection technology. A new model of interconnection has been proposed, and a run-time system consistent with that model is implemented. Th e result is a software design system that facilitates rapid prototyping and reuse of existing tools. In that our project applies these techniques to instantiating environments for mathematical problem solvers, we view Polylith as an environment design system. In this paper we discuss how Polylith can directly aid both environment builders and users alike. Section 2 of this paper gives a review of our underlying software system. Section 3 reviews fundamental considerations in environment construction, and then describes new functionality that is available in experimental environments built using our type of ?tool bus.? Extract: A simple model for interconnection 2.1. A Simple Model for Interconnection. Consider a simple graph model for module interconnection: let each node in a process graph abstractly represent any identifiable module or object of interest (we will refer to these interchangeably a3 services), and let the (directed) arcs entering or leaving this node be labeled to correspond to that service?s visible interfaces. Modules are not necessarily complete programs, and interfaces are not analogous to IO ports (interfaces can instead be viewed as the entry points available to a calling routine.) We will let binding be defined as any directed arc that connects the interfaces of two services. In general, our process graph will be attributed - for instance, services? interfaces will bc characterized by an interface pattern to capture the structure and type of any data that is involved in a transaction across that interface. Any application system is completely defined by two separate but very related parts. The first part is a minimum specification that is written in our Polylith language. This specification concisely describes the essential structure of some application system: services are described generically, class structure of necessary data objects is built, and bindings between instantiated services are enumerated. In short, a process graph is described with the minimum detail necessary to allow Polylith to directly execute (or simulate, as needed) that specification. The second part necessary to complete an application system is an implementation part: each service schema may simply contain a reference to some object file or binary that can, when executed, effect the described specification. It is important to note the ?minimum? part of our term ?minimum specification?: we do not require formal (algebraic) specification of any one service?s intended functionality; we instead require only design or structural information so that our run-time support may correctly manage boundaries between services and objects, as well a3 control composition of services into some larger graph. Implementation part3 may be accomplished using any language supported by the host operating system, with the consistency between implementation and specification parts either guaranteed (when formal specifications are available), checked (when semantic analysis tools are available on a language domain by domain basis), or, in the weak case, lightheartedly hoped for by the tool designer. The model that so dominates in current interconnection techniques is that of ?nesting? in construction of monoliths: generally, an implementor?s goal is a single process, with all modules and data objects managed within that address space. Binding is passive in these cases, that is, all calls manage argument structure (size, location and so forth) according to either static agreement or dynamic conventions fixed a priori. Of course, in such a situation the implementor must understand these low level calling conventions and data representations for all tools each time they are united. This is especially dangerous in cases where the application spans several source languages, requiring not only that the user have intimate understanding of more than one language?3 low level conventions, but that the run-time systems supporting each language may all co-exist in the same process space compatibly. Further, by using this nesting paradigm for control of names (under any of the possible conventions attached to those nested objects, e.g. lexical scoping rules), only limited mechanisms are available to control possible explosive growth of the name space. In cases where some form of package arrangement is established to allow name hiding (that would reduce complexity of analyzing the monolith?3 total structure to some extent), then it is usual that the connectivity properties (i.e. what function entry point may be utilized where) are severely impaired. Even in multiprogramming applications, the current technotogy can only provide limited interprocess communication primitives that are really intended to facilitate orchestration of monoliths. The complexity of managing even a small process graph rapidly becomes untenable. Especially in multilanguage environments, transactions are usually limited in content to some ad hoc collection of atomic types that the programmer hopes is common to all monoliths concerned. Usually, these difficulties in multiprogramming efforts foster a return to implementation in a single monolith. Thus, current interconnection technology fails to handle the complexity inherent in large environments. Worse, it fails to allow swift design alterations, where changes can reliably propagate to low level implementation considerations. The central problem is this: all structural (or design) information, semantic behavior (functionality of modules), and composition (interconnection) assertions are heavily intertwined in one user'source. Being so diffused, it is costly (if possible at all) to isolate only one of these views. Finally, alterations made to the view can not be easily or reliably mapped back into the integrated structure. Polylith models have exactly the opposite of this situation: design information is explicitly isolated from the implementation perspective of each component service, and differs from other systems that deal with specification in how it provides for a full range of minimum specifications to be used in design. An environment designer may manipulate the high level specification of desired tools, free of any low level implementation considerations. Our system handles refinement of the data types and patterns that comprise transactions between tools. And since our run-time support system connects services? implementation parts using an active agreement (that is, one allowing dynamic reconfiguration of calling convention3 and coercion at call-time) application modules will, in effect, need only understand the Polylith interfacing protocol in order to access any other service available in the cluster (either locally, or remotely.) Extract: Polylith Overview 2. Polylith Overview. Currently accepted models for program interconnection have proven to be inadequate as a medium where researchers can develop realistic solutions for such issues as rapid prototyping, software reuse, configuration management, or programming in very large scale software efforts. Existing software practices for exploiting machine organization are the most critical impediment common to these cited issues. State-of-theart ?smart editors,? knowledge-based schema managers, engineering databases and other expert assistants are very good at helping us create individual modules, and yet we still lack efficient and reliable ways to combine these individual modules. It is likely that these large-system design difliculties account for much of the cost that tool builders paid in creating early-generation computer algebra systems; it is certain that these difficulties would exact a high cost should a researcher seek to unite such assistants with other tools, newer tools not necessarily developed on the same architecture under the same paradigm. This high cost associated with environment design motivated the project called Polylitk in order to better amplify the effect of problem solving endeavors, the leverage of a software tool bus haa been developed to meet the increasing demands of flexibility in software design. This project has proposed new models for program interconnection, and has implemented a prototype (of a language and associated run-time support) that is consistent with one of these models. The Polylith grammar has features derived from both module interconnection and specification languages, and our run-time system allows for direct execution of a process graph (or cluster) once specified in our language. This system transcends linguocentric boundaries, allowing tools written in any language supported by the host OS to participate in a cluster. Further, expert tools are provided to assist users in analyzing properties of clusters; in maintaining consistency between implementation versus specification assertions concerning application modules; and in managing the binding information for very large clusters. in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details |