Prism Mechanics: Part 1

[Jim Little]

For those of you just joining my fireside chats, I'm talking about
Prism, a programming technique I'm rabidly passionate about.  Given the
pain of rabies shots, your safest bet is to go on to the next message. 
:)  Otherwise, read on.  More information can be found at the Sphere web
site: http://www.teleport.com/~sphere.


Prism Mechanics, Part I:
It's So Hard To Find A Good Mechanics These Days

This is the second series of Prism essays I intend to write.  In my
first series, I talked about the problems Prism is intended to solve. 
These ideas were all wrapped up in a philosophy called
Paradigm-Independent Software Engineering, or PISE.  The essential
theory behind PISE was that programs deal with many different types of
problems, so our programming languages should too.  To paraphrase PISE's
prime directives :), a programming environment should:

a) Allow you to create your own programming paradigms (or "domain
abstractions") which are optomized for your unique needs.
b) Allow you to use multiple domain abstractions when creating a
program.

Prism is a compiler specification for exactly this type of programming
environment.  These essays will describe how Prism meets these goals.


Unfortunately, it's really hard to describe how Prism works.  I've
already done an okay job on my web site, but part of the reason I'm
doing these essays is to provide a different perspective.  I guess I
should start by describing what Prism is NOT --

Prism is not a programming language.

In fact, Prism is what you get when you take a programming language and
remove the "language" part.  I've been trying to avoid the buzzword, but
(sigh) I'll just have to give in--

Prism is a paradigm-independent semantic meta-metamodel.  (Now you know
what "Prism" stands for, too! :)  )

Of course, now the question is, "What's a paradigm-independent semantic
whatchamacalit?"  So I guess I haven't really gotten anywhere.  But
that's okay.  Let's just leave the whatchamacalit alone for now while I
describe the rest of Prism:

Prism consists of three pieces.  The semantic whatchamacalit, a global
heap, and a domain abstraction called "reflection" (or "the reflection
domain," to mangle terms and simplify typing).

All of the pieces of Prism are important, and they all mix together to
meet the goals above.  In previous descriptions, I've tried to say that
"this piece meets this goal" and "that piece meets that goal" but it's
really not that simple.  They all mix together to meet the requirements,
and I'll describe how later.  But here's a quick description of what
role the different pieces play:

The semantic whatchamacalit is the hardest part to describe, and I'll go
over that in excruciating detail in my next essay.  It enables
programmers to create their own domain abstractions.

The reflection domain is my cheapass lazy way out of writing a real
compiler.  :)  Well, actually, it's a language paradigm specifically
designed to control the Prism compiler.  In a way, it IS the Prism
compiler.  The part I'm implementing in Java is just a shell.  (This
description is less than accurate, but oh well.  I'll go into specifics
after I describe the whatchamacalit.)

The global heap is where good programs go to die.  In a way.  Think of
it as a cosmic waiting room.  :)  Bits and pieces of programs wait here
for the reflection domain to move them around into a complete program.

So, if you were writing a tax evasion program in Prism, here's how you'd
use these three pieces:  (Let's assume your program consists of a
graphical user interface, a SQL database, and of course a tax evasion
business layer.)

1) You'd create domain abstractions for taxes, GUI's, and databases with
the semantic whatchamacalit.  You'd have to make sure the domain
abstractions could interface with each other.

2) In the reflection domain, you'd define translation programs which
converted your brand-spanking-new domains into machine code.

3) You'd define your tax evasion program in some language -- maybe even
one you created yourself.

4) Then you'd run the Prism Compiler.  The compiler would load your
program definition and put the pieces on the global heap.  Then the
reflection domain-based translation programs would convert the pieces to
machine code and stitch them all together.

That's it!  That's how Prism works.

"Sounds like a lot of work."  I can hear it already.  :)

Well, yes, the above steps would be a lot more work than doing it the
old-fashioned way.  But only if you had to create the domains and
translation programs yourself.  If you could reuse some or all of the
domains, translators, and languages, weeeellll.... then things get a
whole lot easier.  And it just so happens that the global heap allows
you to do just that.  You can even create a new domain abstraction by
reusing a pre-existing, lower-level one.

Okay, that's my best shot.  This stuff is hard to describe at a high
level.  Hopefully, my next essay (about the semantic meta-metamodel)
will be more clear.

Jim Little (jiml@inconnect.com)
Prism is at http://www.teleport.com/~sphere