Language models with functional flavor such as Lisp, FORTH or PostScript are more promising since the number of syntactic constructs (operators) is a priori unlimited and organization of libraries, a poorly defined and often poorly implemented task in procedural languages, is put here under more rigorous control of the language design process. We see FORTH or PostScript like syntax as particularly attractive since the stack model allows for a natural implementation of a N objects -> M objects transfer functions (i.e. operators), as opposed to expression evaluating procedural languages which favor N ->1 transfers (i.e. function calls) or object-oriented languages which favor 1->1 transfers (i.e. method invocations which typically transform object into (modified) itself).
We illustrate these concepts on a comparative diagram above which presents basic computational primitives in selected languages. Enumeration complexity of library design (i.e. selecting, encapsulating and naming chunks of reusable software) is color-encoded, with the darker color indicating more complex (less useful) model. For example, we consider C as more complex than PostScript since the C language itself doesn't offer a method to organize software libraries and to maintain such infobase. Natural input/output configurations for the transfer functions are indicated by incoming/outgoing arrows. Method arguments (as in C++) or module parameters (as in AVS) are indicated by vertical wavy arrows.
The most suitable generic primitive to handle complex computing tasks is a parametrized N->M transfer function, such as presented above for AVS module and MovieScript operator. The difference between these two is that AVS modules are coarse grain and the AVS dataflow model doesn't offer any reusable submodular primitives, whereas MovieScript offers conceptually similar "objectflow" paradigm at all levels of a self-similar design.
For a reader susceptible to a statistical physics or quantum field theory jargon, a useful analogy of what we do in MovieScript can be given in terms of Lagrangians and Green's functions of the corresponding statistical systems. Here solid input/output lines correspond to particles, wavy lines to external fields, blobs to interaction vertices and color to "symmetries" or other measures to control complexity and keep the count of interaction terms manageable. A language like C could be compared to a theory with a simple bare Lagrangian (with a small finite number of vertices/syntactic rules) which unfortunately turns out to be non-renormalizable, i.e. generates infinite number of arbitrarily complex and hence non-manageable interaction blobs (library functions for "real world" applications). AVS is like a purely phenomenological Lagrangian with infinite number of effective vertices. Our effort in MovieScript design can be compared to building a renormalizable theory with has large but finite (memorizable) number of interaction terms which are self-similar, i.e. applicable to an open, growing and a priori infinite family of particles (objects).
Another analogy can be given in terms of natural languages. Here, syntactic constructs play the role of "Common English" which everyone knows and understands, whereas methods for complex objects are like terms in "Expert English", understandable only to domain experts. Still, due to self-similarity of the design, even non-experts can talk about and deal with complex objects. For example, an installation manual for a smart set-top box will be written in common English even if the smart set-top box concept/object didn't exist in our vocabulary a few years ago. The problem with natural languages is that the only family of servers that can interpret them as of today are human brains, whereas we want our servers to run on computers. But the requirements for televirtuality software is similar as in the set-top box example: we need a programming framework in which complex software entities could be developed, customized and used by non-experts.
In designing MovieScript, we try to enforce the self-similarity features, present in natural languages or in renormalizable quatum field theories. A subtle balance between functional and object-oriented components of the design is crucial here. Some aspects of our design are similar to CLOS (Common Lisp Object. System). However, CLOS enjoys only limited success rate when compared with C++, which is partially due to overexpanded functional content of Lisp, making the "Common English" part of CLOS (i.e. just Lisp) in fact accessible only to AI experts. Another extreme design, this time in the object-oriented domain, is provided by Smalltalk which comes with an extensive image of built-in classes and again it doesn't offer a scalable "Common English" component. Finally, languages like C or Fortran offer only "Common English" which is however so simplistic that expressing non-trivial computation in these languages is inherently complex.
MovieScript design starts from a maximally polymorphic subset of PostScript which is implemented as the base MOVIE server/interpreter, written in C and associated with C--shell/Perl based CASE-tools for the server protocol extension. Graphics part of PostScript is absent in such a kernel -- it is supported later on by an extension shell which links to a suitable PostScript server on a given machine such as NeWS or DPS. The initial set of useful generic PostScript types such as array, file or dictionary is extended by a family of other operational primitives such as tasks, threads, ports or channels, a family of computational primitives such as field (n-dimensional array) or record (formatted and indexed data structure), or a family of GUI primitives such as widget, image or a set of graphics objects. One special new type called "type" plays the role of Smalltalk metaclass and implements the (C++/CLOS-like) object-oriented model with multiple inheritance. Another special type called "shell" provides an extension model for system dictionaries, and hence for the language itself. MovieScript types and shells are in a dual relationship, with the respective focus on structure and function aspects of the language design. Depending on a particular programmer's point of view, the resulting design can be seen as either purely functional or purely object-oriented or hybrid with a modifiable weight of both components. A new computational domain is typically interfaced by creating a set of new classes and optionally some extension shells with new 'calculus' rules. MovieScript system dictionary, extensible via shells, plays the role of "Common English" and here the design effort is on maximal polymorphism in terms of a large but finite (memorizable) and slowly growing collection of generic operators. Complexity of large objects is encapsulated and hidden in terms of specialized methods, playing the role of "Expert English". Shells plays also a useful role in rapid prototyping and facilitate quick-and-dirty trial-and-error based langauge extensions, to be cast later on to more organized formats of polymorphic operators and new object classes.
- Ref.1
- Ref.2
- Ref.3