[Fwd: Re: Prism Rationale, Part 1]
Wed, 06 Jan 1999 19:47:15 -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, 6 Jan 1999 00:11:59 -0800
From: David Jeske <email@example.com>
To: Jim Little <firstname.lastname@example.org>
On Wed, Jan 06, 1999 at 12:58:33AM -0700, Jim Little wrote:
> 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
> 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?
> 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. Furthermore, it sounds
like you're implying that binding a domain abstraction to a particular
implemenation will be a standard operation. That's all I was asking
> I think we're basically saying the same thing here. I'm not completely
> sure, but it seems like it.
Sounds 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.
I understand. It's just much harder to come up with those examples.
It's hard enough to come up with these examples. :)
> 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
You already understand more about his Arrow ideas than I... :)
> 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.
I agree that would be great. In pure academics they rely on formal
language concept descriptions to communicate ideas, but out here
perhaps we are better off with implemention driven descriptions.
> 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
I agree.. but it's really hard to experiment or even describe ideas
without an example substrate to do it on/in.
Where exactly is the Prism compiler? What kind of questions are yet
unanswered for the initial implementation?
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + email@example.com