Challenge my assumptions!

[Tril]

Let me see if I got this straight:  A model represents an individual
concept.  A metamodel is a set of models.  To define a metamodel you use
the Prism meta-metamodel which supposedly can express the set of sets of
models.

A model is an instance of a metamodel.  The metamodel defines the
structure of a set of models; the actual models are just the permutation
of values in each slot in the structure.  So an individual model has the
same structure as the other models in the same metamodel, but maybe
different values at different places in the structure.  (I realize the
structure can include things such as "repeat this element X times", or any
number of times)

Metamodels are defined using the GTL, which associates structures of _Bit,
_Map, and _Stream to textual descriptions of what each one is for.
As far as I know, metamodels aren't expressible in Prism, and they are
included in the documentation.  It is the job of a particular Prism
mini-language compiler to ensure that it parses the language into that
metamodel properly- i.e. there is no way to verify that it does so,
formally, within the system.

The meta-metamodel is the set of all sets of organizations of bits,
streams, and maps.  This is also not part of the programmable system but
is implied because the output of every prism mini-compiler must be in this
format.

On Tue, 6 Jul 1999, Jim Little wrote:
> _Bag, an unordered collection of other atoms.  Suited to representing
> any concurrent concept, such as declarative programs, concurrent
> algorithms, and spatial arrangement of furniture.

Thanks for considering my suggestion!

> A 'metamodel' is a model representing how a particular set of models is
> interpreted.  The metamodel tells you what the set of models mean.  A
> language definition such as the C standard is an example of a
> metamodel.  In Prism, metamodels are formed from a natural language such
> as English.

In addition to defining the meaning of each model in a set of models, it
seems that your metamodels also specify what set they are defining, by the
structure.  It seems like these concepts should be separated, so that you
define the syntax (set of structures) separately from the semantics
(meaning).  Perhaps this separation already happens because the metamodel
syntax is stored in an internal format, where the semantics are only
human-readable.

> BRIAN:
> > I can't think of anyone who would like to deal with
> > programs as streams of bits as a concept, unless they really had to think
> > that way at some point.
> 
> _Bit, _Stream, and _Map are Prism's INTERNAL representation of
> programs.  The programmer doesn't need to deal with them unless he is
> defining a new metamodel, or creating a metaprogram which manipulates
> models.  Most of the time, the programmer won't be doing that.  He'll be
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> defining programs with source code, and simply using other people's
> metaprograms.

Here is a main difference between PRISM and TUNES.  You expect programmers
to make do with the tools they are given.  I thought you agreed that the
best way was to have one metamodel for each conceptual domain?  You
underestimate the number of metamodels needed.  New ones will be required
every day.  This is why systems that don't include reflection die from
exorbitant maintenance costs.

> One point that I haven't made clear in the past is that, once a
> metamodel (such as the "Integer" metamodel) is defined, it may be
> referenced in the definition of other metamodels.  That saves quite a
> bit of frustration, not to mention time.

So the GTL includes a macro language, to reuse previous definitions.  That
may be useful to some extent, but if you don't allow orthogonalization of
aspects of a metamodel, you'll still have the problem where old metamodels
are ALMOST what are needed for the current situation, but not quite.  If
all you can do is plug in the name of an old metamodel to reuse them,
people will end up editing the GTL spec of a metamodel to adjust it
slightly.  Oh, wait, you can't do that, because then the manually-written
mini-compiler for that language won't work anymore.  Do you see the
problem?

A meta-object protocol properly allows the definition of a family of
similar metamodels, allows a particular metamodel to be selected by
choosing the properties required, and AUTOMATICALLY allows metamodels in
that family to interoperate.  (yes there's an overhead due to dynamic
lookup at run-time)  A MOP would solve the reuse of metamodels problem,
but adding one to Prism would require some substantial, careful thinking.

> THOMAS:
> > > 1) The basic Prism data types (_Bit, _Stream, _Map) are SUFFICIENT to
> > > represent any concept, particularly programs.
> > 
> > In order to comment on this, one needs to know what ways can _Bit,
> > _Stream and _Map can be manipulated. 
> 
> Well, manipulation is the province of metaprogramming, and not what I'm
> discussing here.  
>
> > Data in itself without any ways to
> > interpret it is effectively useless. Like Billy says, programs = data +
> > algorithms.
> 
> Except that, in this case, the data is REPRESENTING a program, not being
> used by it.

The above statements seem to contradict each other.
I think we're missing something.  What data do Prism *programs* operate
on?  Are there NO prism programs that operate on models?  Obviously your
Prism Control (formerly Reflection Domain) must operate on models.  That
is the language that Prism mini-compilers are written in, isn't it?  I
don't see how you are going to avoid keeping that out of this
conversation.  You told me that you didn't like the prism control as it
is.  Sounds like an excellent opportunity to rewrite it.  It seems like
it's an important part of prism, if it's what the mini-language compilers
are written in.

> > Dependent on your goals. Personally, I think relflection is a point, and
> > I don't see how that is provided in your model.
> 
> Reflection is a noble goal, but not what I am personally striving for. 
> Reflection can "easily" be added to Prism without changing Prism itself,
> though.  You just have to define a subset of the Prism meta-metamodel
> which formalizes the definition of metamodels so that they no longer use
> natural language.  Then Prism's scripting language (a metamodel itself)
> could be used to write programs which achieve reflection.  Anybody care
> to try?  ;)

Truly, we're not sure why you ask this to the TUNES forum.  You should
have already known that we'll just tell you Prism won't be very useful as
long as it doesn't have reflection, and that leaving it out so as to get
Prism done sooner will only make Prism the same as every other special
purpose system.  I have no choice but to try to persuade you to slow down
development and do the appropriate redesign to make Prism succeed.

> I do plan on experimenting along these lines after I finish my other
> Prism goals.  One thing I want to do, for example, is to write a Prism
> compiler in a Prism language which supports dynamic recompilation.  Then
> new Prism scripts can be compiled into the compiler itself.  :)  I also
> want to formalize some subset of metamodels so that some degree of
> automatic metaprogramming is possible.  But I've still got a lot basic
> things to worry about, first.

Why not consider these things at the beginning, if it is the ultimate
goal?  How are the "basic things to worry about" going to help you get
there?  I recommend that since you have done so much work, that you finish
it up quickly and move on to the interesting stuff.  The answer to your
question of whether _Bit, _Stream, and _Map are suitable, is "No", and the
reason is for human maintainability not for Turing completeness.

David Manifold <dem@tunes.org>
This message is placed in the public domain.