Prism criticism

[Jim Little]

Maneesh Yadav wrote:
> 
> Jim, I think you need to provide clearer examples.
> I really don't see much here except that if you use the word class for
> metamodel and write all data out in binary it's no different than any
> traditional structure representation (C++, smalltalk etc.) which 
> isn't particularly different.  For example you "universal" text 
> import export model example is just the binary representation of Hello
> World...I really don't see how writing a string down in binary makes 
> it possible to mix languages and do visual programming.

Perhaps a quick introduction to Prism is in order.  For the theoretical
background, please see my "The Will and the Word" essay -- it's the best
explanation of what I'm trying to do. 
http://www.teleport.com/~sphere/documents/0006/4/index.html

Prism is an attempt to realize the theories presented in my essay. 
Here's how it works:

The fundamental concept behind Prism, presented in "The Will and the
Word," is that programs are ethereal constructs.  The only things we
humans ever deal with are representations of programs -- models.  Source
code, object code, executable files -- these are all different ways of
modeling programs.  Some of them can even be run by a computer.  But the
fundamental concept is unchanged: they are all models.


THE META-METAMODEL

What Prism does is provide a standard format for modeling programs...
or, as it turns out, any other concept.  (In this way, it's very similar
to Arrow.)  Prism's standard format is called its "meta-metamodel," for
reasons almost explained below.  The format defines three data types,
which I call "atoms:"

_Bit:    Prism's fundamental unit of information
_Stream: An ordered collection of atoms
_Map:    An indexed collection of atoms

(The underscore serves to distinguish Prism's atoms from normal bits,
streams, and maps; it serves no other purpose.)

The most important part of Prism's meta-metamodel is that it only
defines a format for models.  It implies absolutely no meaning.  So if I
say (using the Prism/GTL language):

_Stream
+-----------+
| _Bit: FOO |
| _Bit: FOO |
| _Bit: FOO |
| _Bit: BAR |
| _Bit: BAR |
| _Bit: BAR |
| _Bit: FOO |
| _Bit: FOO |
| _Bit: FOO |
+-----------+

You know that I have a model consisting of a _Stream which contains nine
_Bits in the order given.  But you don't know what it represents.  To
save space, I might have described the same model this way (still using
Prism/GTL):

_Bit[]: 111000111

But you still couldn't assume anything about what the model represented.

This is where metamodels come in.  Prism's meta-metamodel defines a
standard format for modeling any concept.  But it doesn't say anything
about which concept a particular model represents!  We use metamodels to
determine that.


METAMODELS

As I've mentioned, every program -- indeed, every concept -- can be
modeled in the format defined by Prism's meta-metamodel.  But if you
don't know how to interpret a model, it's meaningless.  That concept --
the knowledge of how to interpret a model -- is represented by a
metamodel.  A metamodel is a description of a set of models and a
description of the concept each model represents.

(Astute readers will have noticed that, since metamodels represent a
concept, they could theoretically be described with Prism's
meta-metamodel.  We're seeing the first glimpse of how reflection could
possibly play a role, which is what makes this relavent to TUNES.)

In Prism, I use a language called Prism/GTL to describe sets of models. 
(You've seen the basic "model syntax" of Prism/GTL above.  It describes
a single model.  There's a variant called the "metamodel syntax" which
describes sets of models.)  Then I use plain English to present rules
which an intelligent human could use to understand how to interpret all
of the models described by a metamodel.  Here's an example:

FORM: _Bit[0+]: * (Morse Code)

MEANING: All Morse Code models represent a message in Morse code.  Each
_Bit in the model corresponds to a dot or a dash in the message.  _Bits
in the FOO state represent a dot.  _Bits in the BAR state represent a
dash.

Basically, what this metamodel is saying is that there's a set of models
called "Morse Code" models which represent messages in Morse code.  The
form of the model is zero or more _Bit atoms in a _Stream.  Each _Bit
can either be FOO or BAR; FOO corresponds to a dot, and BAR corresponds
to a dash.

Armed with this information, we're ready to interpret the model I gave
above:

_Stream
+-----------+
| _Bit: FOO |
| _Bit: FOO |
| _Bit: FOO |
| _Bit: BAR |
| _Bit: BAR |
| _Bit: BAR |
| _Bit: FOO |
| _Bit: FOO |
| _Bit: FOO |
+-----------+

Assuming the above model is a Morse Code model, then it represents the
message:

. . . - - - . . .

...or, "SOS."

(Astute readers will have noticed that the levels of meaning here are
rather astounding -- the Prism model, which represents the morse code
message, which represents the word "SOS," which represents the phrase
"Save Our Ship," which has connotations of extreme need.  Extremely
astute readers will have realized that each one of these levels of
meaning -- each being a slightly different concept -- could be
represented by Prism models.  Now if only a computer could perform the
interpretation...)


TRANSFORMING MODELS

Models only make sense in context.  You can only interpret a model if
you know which metamodel you should use to interpret it.  Above, I
interpreted the example model as meaning "...---..." because I assumed
it was a Morse Code model.  The same model interpreted with a different
metamodel could mean something entirely different!

More importantly, the same concept can be represented with different
models if they are interpreted by using different metamodels -- that is,
if their context is different.

So how does all of this relate to programs and programming?  Well,
consider this.  If source code is a model of a program, and executable
code is a model of a program, then what is a compiler?

Answer: It's a mechanism for automatically transforming models from one
context to another.  The source code and executable code are both models
of the same program -- they're just interpreted differently.  The
context is different.  One context is recognized by humans; the other,
recognized by CPU's.  The program represented is the same.


THE POINT

It's getting late and I'm losing my lucidity.  But the point of all this
is that a compiler isomorphically transforms models.  It changes the
representation, but doesn't change what is being represented.  Now,
suppose we had a common format for representing all models.  And further
suppose that format was so well-suited to modeling concepts that
metamodels for that format clearly mapped concepts to syntactic
structures.  What would that give us?  

It would give us the ability to write a single program which could
manipulate any model.  If we made the program itself programmable, the
simple metamodels would give us the ability to easily write programs to
transform models from one context to another.  And since all the models
would have a common form, we could even write programs which transformed
multiple models into one.

And that, Maneesh, is what the Prism Compiler is.  That's why "writing a
String down in binary" is so important.  I'm not writing a string down
in binary; I'm defining a metamodel for representing strings, so that
henceforth, any person using Prism can look at a String model and know
what it means and how to transform it, so that any future metamodel he
wishes to create can incorporate strings, and any existing programs that
transform or manipulate strings can be re-used.

What I'm providing are the basic building blocks required to create
interoperable, high-level, useful metamodels.  You can't define a
metamodel for 3D text adventures if you're constantly having to explain
how a string is represented.

Anyway, that's what Prism is about.  I'm sorry I couldn't make it
shorter, but to understand Prism, you really have to understand the
theoretical underpinnings.  Otherwise all this stuff looks like a bunch
of C structs tacked on to a sort of programmable yacc.  But once you
look past the surface, I think you'll see a whole lot more.

Jim


PS: Maneesh, I do appreciate your criticism.  It's easy, especially on a
project like this one, for me to lose sight of reality.  So please,
continue to pick holes in my arguments!

Thanks,
Jim


Prism is at http://www.teleport.com/~sphere