Re: [cme-dev] Composition and Query Language

[Harold Ossher <ossher@xxxxxxxxxx>]

Hi Juri,

Thanks for your comments. Some quick responses below.


> <TANGENT>
...
> The question that is important is:

> "Do we want DSLs (if that means domain specific languages) that cross
> the borders of a development phase / artifact type and how do we handle
> the paradigm shift (chasm)?"
> </TANGENT>
The question of how to derive composition specifications for lower-level
artifacts from those for higher-level ones is is indeed an important,
intersting
and difficult question, I agree. I have not tried to address it yet.

>
> > > and (c) the extraction language.
> > It's a key requirement this language handle extraction too. I can
imagine
> > an "extract" relationship, and some special auxiliary attributes to
control
> > things like reference handling (e.g., declaration completion). The
> approach in the
> > draft essentially allows one to bundle CCC convenient sets of CCC
> functionality,
> > and additional processing provided by plugins, under simple names
> that the user
> > can just use, and to provide various options through similar
> simple names. When
> > we figure out exactly how to accomplish extraction with CCC, it
> should be possible
> > to bundle the necessary controls and options in this way. At
> least, that is my thesis.
> >  If I am wrong, then this approach is deficient and needs to be
> enhanced or abandoned.

> Hmmm... Not certain I understand this... (Oversimplification ahead) When
> I picture extraction, I envision identifying a concern through the query
> language, define how far through the code it extends and then just flip
> a switch to get the parts out. Some declarative-completeness-magic and
> there is it...

> For that, a simple plugin that contains all the operations, options and
> their respective names should be more than sufficient.

> On the other hand, I'd want to consider bit rot by adding too many
> constructs to the language. Unfortunately a set of independent languages
> is not necessarily better as we ould have to face additional problems
> with interoperability of the languages and their constructs.

It seems to me that extraction and composition are closely-enough related
that, if we have a general-purpose composition language, it could and
should handle extraction too, with options to control the declarative-
completeness-magic (or related approach). Certainly, we expect the
composition component to handle extraction too, appropriately driven. If we
go the DSL route, though, then a DSL for extraction (which I think is what
you're suggesting) seems right to me. But Peri has more intuition in this
area
than I do...

>
> > > [from your followup note] Sorry, I missed item (d), the relationship
to a
> > concern model, as well.
> > I mentioned this briefly above: the composition relationships in this
> > approach could go into the concern model, and be interpreted by the
builder.
> > And the items found by the queries would then be concern model
> > elements. But perhaps there is a deeper connection I am missing...

> *see my above note* I do not think that it's that simple because of the
> inherent differences of the artifacts... We would at least be talking
> about multiple builders, cross-artifact consistency checking of
> composition relationships, conflict handling, etc.

Right, I was thinking about multiple builders, but not about the
cross-artifact
issue.

- Harold