Challenge my assumptions!
Tue, 6 Jul 1999 10:57:24 -0700 (PDT)

> Here's an explanation of the difference between models, metamodels, and
> meta-metamodels:
> A 'model' is a concrete representation of any thing.  A source code file
> is an example of a model.  In Prism, models are formed from 'atoms,'
> which are instances of the _Bit, _Stream, and _Map data types.
Yes.. you're talking about symbols when you say model then... that's
fairly standard usage i think. 

> 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.
Okay, you mean 'language' then when you say "metamodel"... or maybe
you mean the language definition (symbol for the language)...

> A 'meta-metamodel' is a model representing how a particular set of
> metamodels is interpreted.  For most programming languages, the
> meta-metamodel is implicit: (E)BNF and natural language.  In Prism,
> there is one meta-metamodel.  It says that metamodels describe a set of
> models, that the models are formed from _Bit, _Stream, and _Map
> instances, and that the meaning of each model is described with natural
> language.
okay, then you mean a language about languages, or a symbol about
such a language then...

> > may i suggest an alternative structure
> > for representing information: the binary tree ("function application")
> > with a finite set of words for the nodes. Actually, strictly, just one word
> > would suffice (but this might make the interpretion more difficult); if you
> > are willing to have self-referencial trees, then no words are necessary
> > (this would be like Brian's arrow system i suppose).
> Now that I've explained the reasons behind my choice of _Bit, _Map, and
> _Stream more clearly, I hope you'll defend your choice of a binary tree
> as well.  I'm definitely open to using different data types for Prism
> atoms... that's basically what I'm trying to determine if I should
> change.  One thing to consider, though, is that I want the Prism's
> internal representation of programs to be syntax independent.

I'm afraid you are going to have to be dependent on some syntax, if you're
going to store any information. I think what you're saying is that
you want Prism to be able to input and output information in various 
languages, meaning that it's going to have to be able to translate
from its internal syntax... I don't think that's a problem though, for
the binary tree; it should be fairly easy to translate it into other
languages... of course, the binary tree isn't a language itself, but
rather is an approach to languages.

> 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
>, 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))'. there would be other ways to do it using
binary trees.. for instance, if you had '1' and a subtraction function
you could generate all integers. At the risk of making interpretation
difficult, but with the benefit of making the syntax more unified, you
could even use  the same word for subtraction and '1' (subtraction would
always be used on the left (as a "function") while '1' would be used on the 
right (as a "parameter"))... that approach would become problematic if
you ever tried to extend the system with, say, a square root function,
though ... Another interesting approach would be to represent integers
using pure functions (there exist (ordered) sets of functions that
have the properties of integers and operations on them); since all
pure functions can be constructed out of combinators S and K, that
would make quite an interesting system (if you're wondering what
combinators are, you might want to see my web site,

respectfully ...

- iepos