Re: [cme-dev] Composition and Query Language

[Juri Memmert <memmert@xxxxxxxxxxxx>]

Hi,

I finally found the time to look at the proposal some more:

Perhaps I am dense, but I could not get more information on "arity" from
what you suggested in 6.4.1:

> For more on the comment “Perhaps dependent on arity”, see 6.4.7
> (compose).



> 6.4.9 advise (was “bracket”)
> 
> advise (C1:S1.m*(), before#C2:S2.b(), after#C2.S2.a())
> 
>       * ‘#’ is used here, because the more natural ‘:’ is already used
>         for spaces
>         
>       * Or: advise C1:S1.m*() with before#C2:S2.b(), after#C2.S2.a();
>         
>         
>       * In general, more flexible, distributed way to write
>         correspondences?

I think so.
I understand the ease of parsing "keyword piece_of_information keyword"
(if you consider a ',' a keyword) but it always bugged me nonetheless.

Would

advise C2:S2.b(), C1:S1.m*(), C2.S2.a();
advise none, C1:S1.m*(), C2.S2.a();
advise C2:S2.b(), C1:S1.m*(), none;

be much harder?

"none" (or empty or nil or whatever_the_doctor_prescribed) is a
placeholder and the sequence of the concerns defines whether it's a full
bracket or only a partial one.


>       * Parameter passing, including pseudo-variables

could be handled easily, too.
I see two main cases for this:
- Pass parameters to m() to a() or b() or both
- Pass return values from b() as a parameter to m() and / or to a() [or
any permutation of that pattern].

This is a general problem that is ugly enough that most developers will
strive to avoid it, but if they can't I would do the following:

advise 
	<3>=C2:S2.b(<1>),
	<4>=C1:S1.m*(<1>,<2>,<3>),
	C2.S2.a(<2>,<3>,<4>)
;

This states that b takes the first argument to m and returns a value
that is to be passed to m as its 3rd argument. a takes m's second, the
return value of b (or if it's an object that is changed in m whatever is
in there now) and the return value of m.

I realize that this is not very pretty, but it is easy to handle. Arrays
are, of course, not easy to handle thus, but I believe that glue-code is
needed in such a case anyway.

As for summary functions (6.4.10), I am not certain that I would only
want to summarize merge operations. Advise would be a good candidate,
too.


Some more general questions, too:
What is the target of any composition operation? A valid input to
another operation? In that case, either the composition operation or the
result needed to be named at all times.
You specified that all operations [can/must] have a name. While I really
want that, I am not sure whether it's something that fits into the
examples so far.

Some work quite nicely:
> merge concern (C1, C2) as C;
> rename class C:S as C1:S1;

While others do not immediately do that:
> extend [ … ] concern C1 with C2;
> override concern (C1, C2);
> instrument concern (C1, C2);

Will we address the result as C1?


> advise (C1:S1.m*(), before#C2:S2.b(), after#C2.S2.a())

And what's the name of this beast?


Also, overriding is done for the input space of the output space? If
it's for the input, what's the name of the original C1? If it's in the
output space, we need to name the operation, not the concern...

And yes, I generally would prefer naming the operations not the
artifacts the operations work on / result in, just in case you remember
my rant about how unstable names are. ;-)


There's a lot more to discuss in this paper, but that should be enough
for a Sunday.


	Juri


-----
As the Americans learned so painfully in Earth's final century, free
flow of information is the only safeguard against tyranny. The
once-chained people whose leaders at last lose their grip on information
flow will soon burst with freedom and vitality, but the free nation
gradually constricting its grip on public discourse has begun its rapid
slide into despotism. Beware of he who would deny you access to
information, for in his heart he dreams himself your master.
 -- Commissioner Pravin Lal, "U.N. Declaration of Rights"