[Fwd: Re: Prism Rationale, Part 1]

[Jim Little]

The following message is one of several that was accidently sent
directly between myself and David Jeske instead of to the mailing list. 
I don't know if you'll find it useful, but here it is:


-------- Original Message --------
Subject: Re: Prism Rationale, Part 1
Date: Wed, 06 Jan 1999 00:58:33 -0700
From: Jim Little <jiml@inconnect.com>
To: David Jeske <jeske@home.chat.net>
References: <369196EA.4C3A0F6A@inconnect.com>
<19990104223226.A15764@home.chat.net> <3691D66B.CA402265@inconnect.com>
<19990105110844.D15764@home.chat.net>

David Jeske wrote:

> I believe that just as you've identified the importance of being able
> to define new domain abstractions which are specific to a problem,
> it's important to be able to remap between different pieces of a
> domain abstraction with little or no cost.
> 
> In other words, we want to be able to define compact syntax, as I
> demonstrate in (1) above, but we also want to be able to rebind what
> that compact syntax is doing within a given block of code, so that we
> can 'weave' in an improvement to the whole block of code by changing
> the domain abstraction instead of changing the code itself.

I think I see what you're saying here.  The example you gave above (the
part I deleted :) ) about C data structure accesses cleared things up
immensely.

However, I think in a PISE-style system which supported multiple domain
abstractions, the issue wouldn't even come up.  Instead of using a
programming domain which provided many different ways to describe the
same action, you'd use lots of fine-grained, extremely-focused domains
which were 100% orthogonal.

So instead of saying a[1] or *(a+1) or get_element(a,1), you'd say (with
whatever syntax)

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

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.

I think we're basically saying the same thing here.  I'm not completely
sure, but it seems like it.

> Good, I'm glad that made sense to someone else. I find that at work we
> end up wacking domain abstraction ontop of our C code. Every 'function
> declaration' is actually done with a macro. We have a few different
> things which occur because of a function declaration, and they are all
> explained in the macro definition. As a result, our code no longer
> repeats this pattern.

I do want to make a point on this -- in our discussion, we've been
talking about pretty detailed code-level abstractions.  I see domain
abstraction being useful for this, but actually I see it more as a tool
for software engineering: big abstractions which drastically simplify
solving a problem.  Not so much for algorithmic optomizations.

But of course, we do have to solve the small problems before we solve
the big problems.  :)  I just wanted to point out the general direction
I see domain abstraction going.

One last issue:

One of the things I'm hoping Prism will do is to allow some of the Tunes
theorists a more formal medium for expressing their ideas.  For example,
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.)

We all benefit by having clear descriptions of the paradigms people are
proposing, and the Prism meta-metamodel is sufficiently generalized that
I think it could do the job.  In particular, I want to see more wild
discussion of domain abstractions.  I think the current focus on
text-based languages (not necessarily here, but in the computing
community) and a meta-metamodel based on syntax trees is constraining
people's imaginations.

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