[Fwd: Re: Prism Rationale, Part 1]

Jim Little jiml@inconnect.com
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 <jeske@home.chat.net>
To: Jim Little <jiml@inconnect.com>
References: <369196EA.4C3A0F6A@inconnect.com>
<19990104223226.A15764@home.chat.net> <3691D66B.CA402265@inconnect.com>
<19990105110844.D15764@home.chat.net> <369317A9.47EA191@inconnect.com>

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

I'm glad.

> 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
for. :)

> 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
> 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...  :)

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

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/ + jeske@chat.net