Challenge my assumptions!

[Jim Little]

Sorry for the long delay in replying to this.  I have a bunch of new
documents related to this subject to put on the web and I trying to get
those done first.  But that's taking longer than I hoped, so I'll just
wing it... once again, I'm replying to everybody (Tril & iepos) in this
one letter.

Note: This letter ended up being rather long, but don't worry, there's a
lot of quoting, so it's not as long as it seems.  And don't forget to
check out ToonTalk!  It's mentioned near the bottom.


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.

Right on target.  Here's the current meta-metamodel definition from the
new (as yet unpublished) Prism spec:

===
Prism metamodels consist of a set of models and a natural language
definition of what the models represent. The natural language
description is unconstrained. The
set of models is constrained as follows: 

Each model in the set shall consist of one datum. That datum may contain
other data according to its type. Each datum is called an atom. Atoms of
the following
types shall be used:

[Prism atom types explanation]
===

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

Correct.  But I do intend to create a "parser" metamodel for describing
a language and how it relates to a metamodel.  Given this, I could write
a metaprogram which compiled parser models into actual parser
metaprograms.  Assuming the compiler is correct, this is better than
formal verification of human-generated code... it's
automatically-generated code.

(Well, not entirely automatic.  But all accidental difficulties have
been removed, and humans concentrate only on the part that requires
human creativity -- defining the language and figuring out how it
corresponds to the metamodel.)

Oh, one last thing... my intent is that, in Prism, parsers will be
separate from compilers.  Compilers will focus on exactly one
metamodel-to-metamodel transformation.  Not like today's compilers,
which parse, transform from high-level semantics to assembly to object
code, and then link.  I intend Prism's metaprograms to be much more
modular than that.


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

Whoops!  Sorry I didn't give you credit!  I've made sure that you (and
everybody else who's made suggestions) got properly aknowledged in the
new version of the Prism spec.  


> > _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'm not sure how you got that impression... I'm explicitely giving
programmers tools to create their own tools.  However, I do think that
there will be a lot more time spent using tools than creating them.  I'm
also hoping that people will distribute the tools they create, so that
the majority of the time you just pick up a tool created by someone else
rather than making your own.  That's why Prism has a fairly elaborate
GUID and versioning scheme.


> So the GTL includes a macro language, to reuse previous definitions.

Precisely.  Although calling it a "macro language" is giving it more
credit than it deserves... :)  But that's exactly the right
connotation.  

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

Your point is well taken.  I think Prism badly needs a MOP, or at least
some way of relating metamodels to each other and expressing
differences.  I've ordered a copy of AMOP... in the mean time, I'd like
to hear any suggestions that you or others might have on this topic.


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

Yes, Prism compilers have a virtual machine which executes Prism Control
models.  Prism Control programs operate on the models within the Prism
compiler.  Other models, though, will be compiled to machine code and
executed outside of the Prism environment like normal programs.

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

I haven't been trying to avoid discussing the Prism Control metamodel,
it's just that the topic was the Prism meta-metamodel and I didn't want
to confuse the discussion.

I'm definitely interested in hearing your suggestions on Prism Control,
though.  (Yours, too, TMF!  I wasn't trying to ignore you, I just wasn't
sure if you got the point of Prism's models.)  Just keep in mind that
simplicity and completeness are most important.  Simple, because I have
to write a VM for it.  Complete, because I don't want to restrict
Prism's capabilities.

Any other problems with Prism Control can be eliminated by creating new
metamodels whose models can be compiled into Prism Control models, like
the parser example above.

For those of you who aren't familiar with the Prism Control metamodel,
it's basically an assembly language paradigm of standalone opcodes
operating on a heap.  (No registers.)  I'm getting ready to publish an
updated version of the metamodel spec, but in the meantime, you can look
the current version.  The basic concept is identical:

http://www.teleport.com/~sphere/documents/000e/3/transformation_metamodel.html
http://www.teleport.com/~sphere/documents/000e/3/transformation_virtual_machine.html

In particular, look at the opcode list at the bottom of the second URL.


> > 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 guess my point was that, although I'M not trying to create TUNES, I'm
leaving hooks in place so YOU can.  :)  I'm also open to changing the
basic Prism spec, within reason, to accomodate the preferences of this
list.

So, what would you like to see?  :)  But be specific, please.


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

Your reasoning being that constantly creating new metamodels and
metaprograms and maintaining existing ones will take too much effort? 
Hmm... perhaps, but how would you solve it?  Is a MOP enough?  Is
reflection required?  If so, what sort of reflection?  I'm open to
ideas, but I'm also determined to keep things practical so I can
continue to move forward.


> David Manifold <dem@tunes.org>
Thanks for your comments!  You said a lot of good things that I intend
to follow up on.  I was also quite impressed by your insight into the
model/metamodel/meta-metamodel thing.  :)


IEPOS:
iepos@tunes.org wrote:

> I'm afraid you are going to have to be dependent on some syntax, if you're
> going to store any information.

Well, yes, I just don't want to favor any one external syntax (or type
of syntax) over another.  I.e., I want to leave room open for visual or
multimedia languages.

By the way, everyone here should check out ToonTalk (www.toontalk.com). 
The best non-textual language I've ever seen... it's an animated, 3D
language, but unlike other non-textual languages, it doesn't seem
forced.  The language 'syntax' (a lego world with houses and robots,
among other things) fits the semantics of the language perfectly.  It's
also quite an advanced language -- fully concurrent with message
passing, minimal synchronization issues, good scalability when the
process count gets high, simple object-orientation, seamless
debugger(*)... oh, and for kids!  A really cool language, check it out. 
There's a free trial version.  It comes with a 'game' (a set of related
puzzles) which teach you all about the language.  Easily the best
pedagogical tool for programming that I have EVER seen.

(*)The debugger's probably my favorite part.  It's totally transparent. 
When you're in the same house as a robot, the system slows down so you
can see what's going on.  When you leave the house, it speeds up.  It's
a lot of fun to watch your town (processes) grow and shrink and birds
(messages) fly around when you're running a highly concurrent program,
too.

> > I'd also be interested in seeing an example of a metamodel which used
> > binary trees for its atoms.  As a simple example, how about a metamodel
> > for integers?  My solution to the same problem is at
> > http://www.teleport.com/~sphere/documents/002a/2/index.html, and is
> > fairly intuitive, I think.
> 
> all right, this is a good example. Here's one way to do it: you'll have
> two words, a word for zero ('0'), and a word for a successor function
> ('succ'). You'd represent zero using simply one word, '0'. You'd represent
> one as the application of 'succ' to '0' ('succ 0'), two by 'succ (succ 0)',
> and so on. If you want negative numbers, then you add a negation
> function ('neg'). Negative two could then be represented as
> 'neg (succ (succ 0))'.

That definitely works.  But how is it better than my approach?  I would
argue that my approach, a stream of bits, is more intuitive.  Also,
where do the words come from?  Are we just allowed to define whichever
words we want?  (That's fine if we are.)

I don't have anything against binary or non-binary trees, I'm just not
sure why using them is better than using _Bit, _Map, and _Stream. 
Although I'd rather not change my meta-metamodel (I've already written
code to support it), I will if you can convince me your way is better. 
Better to fix the problem now than regret it later!  :)

> - iepos
Thanks for your response!  I'm looking forward to your rebuttal.

Jim