Re: [cme-dev] Composition and Query Language

[Juri Memmert <memmert@xxxxxxxxxxxx>]

Hi,


just a few comments on where to start in the development process...

Peri wrote: 
> > Third, where are you
> > assuming the developers are starting (code? design? anywhere?)?

Harold responded: 
> I wasn't making particular assumptions about this. It should work on
> anything that CCC can handle. However, the examples I worked through
> concretely so far are all derived from Hyper/J.

These comments led me off on a tangent which I'll include here for your
information. None of this is new to you, but could become useful when
the above question has been discussed some more:

<TANGENT>
If I look at a typical Cosmos model (which is my model-of-choice to
describe concerns throughout the development process), there is no
fundamental difference during which phase I decide to merge two concerns
in that phase.
Once the merge is supposed to take place in a different phase than the
definition was created (or the merge is supposed to effect other
phases), the problems start.

Let us assume two concerns identified during analysis called C(a)1 and
C(a)2. It was decided to merge these concerns. The relationship to merge
them is called R.

The result of this merge is (given the right compositor) pretty straight
forward and easy because the complete definition of what to do resides
within the three components of the equation.

Let us assume that we then more on to the design of the application and
create / identify the concerns C(d)1 to C(d)3 which logically implement
C(a)1 and the concern C(d)4 which logically implements C(a)2.
With our knowledge that there is an R in the analysis phase, we need to
create a new set of Relationships that logically implement R and make
the general intent to merge C(a)1 and C(a)2 match the current concerns
C(d)1 to C(d)4 (different types of artifacts merge differently and need
different glue).

Of course, this stepwise refinement continues in the development phase,
so that, in the end, we have a large number of concerns and
relationships that all (logically or physically) implement C(a)1, C(a)2
and R.

What is needed to actually merge the code is code-level concerns and
relationships and the fact that they implement higher-level
relationships and concerns is, from the point of view of the composition
language, mere coincidence.
>From the position of the user, though, the ability to write "merge C(a)1
and C(a)2 like this" and mean "merge all concerns that implement either
of these concerns and all relationships that are derived from the above
statement" is a great boon.

The ability to say this implicitly is absolutely necessary and very
useful, but within a single phase, with a single compositor, there is no
difference in the composition language to create the merge.
So from the point of view of a concern model similar to the one I use,
the question is moot.

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>


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


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


	Juri


-----
Boy, am I glad it's only 1971...