Prism Rationale, Part 1
Jim Little
jiml@inconnect.com
Wed, 06 Jan 1999 02:42:50 -0700
David Jeske wrote:
> [Jim Little wrote:]
> > Create a bag of XXX and call it Foo.
> > ...Other stuff...
> > Take element #1 out of Foo so YYY can use it.
> >
> > There would be exactly one way of saying "I want element #1."
>
> Sure, but what happens when I want to reuse a huge body of code which
> is written for this domain abstraction, but I want to change the
> nature of how 'taking element #1 out of foo' is implemented?
Hmmm... think of it like this. You don't write FOR the domain
abstraction, you define semantics IN the domain abstraction. The
semantics you define ARE your system, or at least a complete and exact
model of it.
The way those semantics are translated into machine code is irrelevant
at the time you define the program. But -- say, for performance reasons
-- you decide that you need to translate your system differently, then
you just change the way the domain is translated, without touching the
definition of the system itself.
I think you're asking me, "What if I decide I want to change the
semantics of my system? Will domain abstraction give me an easy way to
do that wholesale?"
In that case, the answer is "no." But it's also 'yes,' in a way,
because if you abstract out the implementation details (like whether
you're using a linked list or an array) and focus solely on the
functional requirements, then you can make changes to way the program is
implemented by changing the way your domain is translated.
I hope that made sense. :)
> > But when you compiled your program, you would choose how the abstract
> > data structure domain would be translated. So you could choose a linked
> > list, or an array, or whatever.
>
> Okay... I think you're implying that the domain abstraction is just a
> syntax definition, and not an implementation.
Hmm... I'm not sure where you're coming from, here. I'm tempted to say
'no,' but in a way you're correct. I'll be publishing part 2 of my
Prism Mechanics series soon, and it will go into metamodels in some
detail. Metamodels are how we define domain abstractions, so maybe
you'll be able to resolve my confusion by responding to that essay.
> > Brian's Arrow system could be expressed in the Prism meta-metamodel as
> > follows:
> >
> > _pMap (Arrow Space)
> > +---+----------------------------+
> > | * | _pMap (Arrow) |
> > | | +------+-----------------+ |
> > | | | 0..n | _pBits32 (Slot) | |
> > | | +------+-----------------+ |
> > +---+----------------------------+
> > (Slot references an Arrow in Arrow Space -- in a full description, there
> > would be a complete description of the semantics following the above
> > metamodel.)
>
> You already understand more about his Arrow ideas than I... :)
Maybe not. :) I think Brian's Arrow language is fundamentally pretty
simple. That's part of its beauty. What's difficult is the
RAMIFICATIONS of the Arrow language... that, I don't understand. I
think, because the Arrow language is so simple, Brian confused a lot of
folks by saying, "Here it is, very simple, now here's three pages of
what it means." People saw the three pages and thought it was all
trying to define the language.
On the other hand, I could be dead wrong. A lot of Brian's posts go
over my head. :)
> Where exactly is the Prism compiler? What kind of questions are yet
> unanswered for the initial implementation?
None, really. It's just a matter of getting it done. The compiler
specification (under "Prism Specification" on the web site) has got a
few holes, but they're minor things that I just haven't taken the time
to fill in yet. (Stuff like, "what's the exact algorithm for this
reflection instruction?")
If you or anybody else want to help me finish implementing the Prism
compiler, that would be great. It's about half done right now. I'm not
sure how you could have missed it :) -- it's under "Prism Compiler" on
the front page of the web site. Here's the exact address, though:
http://www.teleport.com/~sphere/documents/0009/1/index.html
The document behind that link describes the compiler architecture before
giving the links to the source code -- maybe that's what confused you.
I recommend that you read the document -- at least up to "Architecture"
-- but here's the exact link to the source code:
http://www.teleport.com/~sphere/documents/0009/1/PrismCompiler_1.zip
You'll need JDK1.1 and to know how to compile and run Java source code.
If you need help, drop me a personal email and I'll get you set up.
Jim Little (jiml@inconnect.com)
Prism is at http://www.teleport.com/~sphere