Multiple language algebraic worsktation 

Algebraic system that permits multiple languages via MIL

Featured a software bus

Related languages
Polylith => MINION   Evolution of

  • Purtilo, James. "Computing Runge-Kutta Starters Symbolically", University of Illinois Dept of Computer Science, Report UIUCDCS-R-83-1120, Urbana, 1983 view details
  • Purtilo, James "Polylith and Environments for Mathematical Computation", University of Illinois Dept of Computer Science, Report UIUCDCS-R-84-1135, Urbana, May 1984 view details
  • Purtilo, James "On Specifying an Environment", Proceedings of the IEEE Computer Society's Ninth International Computer Sof~voare and Applications Conference, Chicago, October 1985. pp 456-46.3. view details
  • Purtilo, James "Polylith: An Environment to Support Management of Tool Interfaces" pp12-18 view details
          in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details
  • Purtilo, James "Polylith: the early goals", University of Illinois, Department of Computer Science, Urbana, IL, 1985 view details
          in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details
  • Purtilo, J. "Applications of a software interconnection system in mathematical problem solving environments" Proceedings of the Fifth ACM Symposium on Symbolic and Algebraic Manipulation Waterloo, Ontario, Canada 1986 pp16-23 view details DOI Extract: Introduction
    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
  • Purtilo, J., D. Reed, D. Grunwald. "Environments for Prototyping Parallel Algorithms", University of Illinois Dept of Computer Science, Report UIUCDCS-R-86- 1249. view details
          in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details
  • Purtilo, James "Polylith architecture" University of Illinois, Department of Computer Science, Urbana, IL, 1986 view details
          in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details
  • Purtilo, James Marvin "A software interconnection technology to support specification of computational environments" 1986 view details
          in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details
  • Purtilo, James M. "The POLYLITH software bus" ACM Transactions on Programming Languages and Systems (TOPLAS) 16(1) January 1994 pp151-174 view details Abstract: We describe a system called POLYLITH that helps programmers prepare and interconnect mixed-language software components for execution in heterogeneous environments. POLYLITH's principal benefit is that programmers are free to implement functional requirements separately from their treatment of interfacing requirements; this means that once an application has been developed for use in one execution environment (such as a distributed network) it can be adapted for reuse in other environments (such as a shared-memory multiprocessor) by automatic techniques. This flexibility is provided without loss of performance. We accomplish this by creating a new run-time organization for software. An abstract decoupling agent, called the software bus, is introduced between the system components. Heterogeneity in language and architecture is accommodated since program units are prepared to interface directly to the bus and not to other program units. Programmers specify application structure in terms of a module interconnection language (MIL); POLYLITH uses this specification to guide packaging (static interfacing activities such as stub generation, source program adaptation, compilation, and linking). At run time, an implementation of the bus abstraction may assist in message delivery, name service, or system reconfiguration. DOI
          in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details