[Fwd: Re: Prism Rationale, Part 1]
Wed, 06 Jan 1999 19:46:59 -0700
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 <email@example.com>
To: David Jeske <firstname.lastname@example.org>
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
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 or *(a+1) or get_element(a,1), you'd say (with
Create a bag of XXX and call it Foo.
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
_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
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
Jim Little (email@example.com)
Prism is at http://www.teleport.com/~sphere