Prism criticism

[Maneesh Yadav]

You're goals seem clearer to me now, and I agree with them for the most
part.  However I really don't see what you are trying to sya here.  Is the
meaning part just a part of the code?  How is this different than writing
out a c struct and a comment beside it?

Jim give me a clear example on how using Prism's methods provides more
elegance/usefullness whatever, than doing it in C++....that's all that you
need to prove your case.

On Wed, 2 Jun 1999, Jim Little wrote:

> 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
>