Prism Conclusion: Applicability to TUNES

[Jim Little]

This is the conclusion to my Prism series of essays.  I hope you've
found them interesting -- if not, well then at least they're over.  :)
Fare', I'm sending you a copy of this directly because I spend a lot of
time discussing your recent essay. :)


Prism Conclusion:
So What's Your Point?


* Recap *

For those of you who have been ignoring my essays (up to now, anyway),
Prism, in brief, is a programming technique intended to reduce the
complexity of software development through the use of "domain
abstraction."  Simply put, domain abstraction is the act of programming
in a high-level language rather than a low-level language.

Prism allows the programmer to perform domain abstraction by creating
"semantic metamodels."  (Semantic metamodels are similar to programming
languages, but without syntax.)  Then the programmer uses one or more
metamodels to define his program.  The program is compiled by the use of
translation programs which are written in Prism's "Reflection
metamodel."

If you'd like more information about Prism, please read the essays I've
already posted.  There's six of them -- "Prism Rationale," parts one and
two; "Prism Mechanics," parts one through three, and "Prism Glossary." 
You can also visit the Sphere web site (http://www.teleport.com/~sphere)
which has a compiler specification and a half-completed compiler.

In the rest of this essay, I'm going to talk about how Prism can be used
to help TUNES development.  At the end, I'll discuss Fare's recent paper
(http://www.tunes.org/~fare/articles/ll99/index.en.html), which does a
pretty good job of justifying Prism.  :)


* Applicability to TUNES *

I haven't noticed an astounding level of interest in Prism thus far. 
:)  However, I think Prism could be extremely useful to the TUNES
community.  There's two ways in which it may be used -- as a
specification tool, and as a development platform.


. Prism as Specification Tool .

The TUNES project has a very gifted talent pool from which to draw. 
However, although I see a lot of ideas and goals being thrown around, I
don't see much in the way of formal specifications or definitions.  Part
of the reason for this may be that the TUNES project is dealing with new
concepts that are difficult to describe other than in natural language.

Prism's meta-metamodel might be able to help in this regard.  It's a
tool for specifying semantic metamodels -- i.e., the semantics of
programming languages.  As Fare' says in his recent article, TUNES
"lacks what would no doubt constitute the heart of the system: a
programming language adapted to a reflective style of development." 
Prism's meta-metamodel can help you specify this language without
getting bogged down in syntax.

Prism's meta-metamodel is not a formal specification language.  However,
there's a fine line between formality and convenience, and I think the
meta-metamodel strikes close to this line.  I describe the theory of the
meta-metamodel in "Prism Mechanics, Part 2," but it's changed somewhat
since then.  I'd be happy to provide an updated, practice-oriented
description if you like.


. Prism as Development Platform .

Prism defines more than just a semantic meta-metamodel.  It also defines
a means for models to be translated -- i.e., compiled.  If TUNES uses
Prism's meta-metamodel to specify its languages, then it can use the
Prism compiler to try out these languages.  (The Prism compiler isn't
done yet, but it's fully specified, designed, and half implemented. 
There's not much left to do.)

For example, Brian Rice has been discussing his Arrow language lately. 
This language may be specified as a Prism metamodel.  (And doing so
could lead to greater understanding of the language by others. :) )  If
it were, then specific Arrow systems could be modeled with the Arrow
metamodel.  From there they could be compiled.  Alternatively, since
Arrow seems fairly close to Prism in many respects, the Prism compiler
could be modified to use the Arrow meta-metamodel and virtual machine
rather than Prism's.


* Prism and Metaprogramming *

Fare' recently published an article entitled "Metaprogramming and the
Free Availability of Sources"
(http://www.tunes.org/~fare/articles/ll99/index.en.html).  I skimmed
over the Open Source sections, I admit, but the metaprogramming part
certainly caught my eye.  It seems that Fare' and I have independently
been working on very similar projects.  Here's a brief contrast/compare
of his work and mine.

+++ Fare' describes metaprogramming -- the manipulation of programs by a
program -- as a way of easing the task of the programmer, of relieving
her "from all repetitive and conceptually redundant operations."

--- I use metaprogramming to enable domain abstraction -- a way of
easing the task of the programmer by reducing complexity.

=== We both see metaprogramming as a way of easing programming, but
Fare' sees it as a way of automating programming, whereas I see it as a
way of simplifying programming by allowing the programmer to focus on
high-level concepts.  Perhaps we have the same idea but are expressing
it differently.


+++ Fare' discusses "metalanguages" and "metaprograms."  A metalanguage
is a programming language which describes a semantic-equivalence mapping
between two programming languages.  A metaprogram is a term of the
metalanguage.

--- I discuss "metamodels" and Prism's "Reflection metamodel."  A
metamodel is like a programming language -- its terms (if I'm using the
word properly) are models of programs.  Prism's Reflection metamodel is
a simple imperative metamodel which can be used within the Prism
environment to translate a model from one metamodel to another whilst
preserving the model's semantics.

=== Fare's declarative approach to translating models is undoubtably
superior to my spaghetti-codish imperative approach.  But my approach
doesn't involve the tricky aspect of formalizing semantics.


+++ Fare' allows new metamodels to be defined when "a metaprogramming
framework ... is able to represent itself."  At this point, a new
metalanguage does not have to be introduced for each metamodel.

--- I allow new metamodels to be defined as terms of a "meta-metamodel,"
which defines three orthogonal groupings of information which can be
given particular meaning by a metamodel.  One "metalanguage" -- the
Reflection metamodel -- is sufficient to translate any models which were
defined in the context of the meta-metamodel.

=== I don't know what Fare' means by "metaprogramming framework," so I
can't comment here.


+++ Fare' thinks of program models in terms of languages, but he says,
"In fact, any non-trivial metaprogram must be able to manipulate
programs no[t] simply according to their superficial shape, their
syntax, but also to their fundamental meaning, their semantics."

--- I allow models to be defined in terms of semantics.  Metamodels are
defined by giving associating meaning with particular groupings of
information.  Models are defined by giving specific values to the
groupings.  Thus, the semantics of a model are more easily determined. 
In fact, since the metaprogram must manipulate the semantics in some
form or another, the data structure defined by the model might as well
be used as a direct representation of the model's semantics.


Well, I hope I've piqued somebody's interest.  I've received very few
responses to my Prism essays -- in fact, I could count the respondents
on the thumbs of my hands. :)  I'm not sure if this is because of I'm
explaining things poorly, or you're not interested, or some other
factor.

At any rate, this is it unless somebody cares to respond.  For those of
you who have responded, thank you.  Good luck to all of you with TUNES.

Jim Little  (jiml@inconnect.com)
Prism is at http://www.teleport.com/~sphere