Hi Mira: We want to connect APPCs and call the connected thing again an APPC. This is similar to hardware description. In my hardware description language Zeus which has been absorbed into VHDL (I am told), a component body consists of: hardware declarations: where you name the building blocks by instantiating component types connection specifications: where you connect the instantiated components So we would have: Type : CompoundAPPC | TraversalAPPC | ... CompoundAPPC = "APPC" Name Parameters "APPCinstances" List(Ap) "connections" // example mode Summing:Composite:after -> LimitCheckingDelta:Composite:actual {Car, Engine}:capacity() -> LimitCheckingDelta:Composite:limit; {Car, Engine}:capacity() -> LimitCheckingDelta:Composite:limit // end example mode "end". Ap = List(InstanceName) ":" Type. TraversalAPPC = "Traversal" "APPC" APPCName Parameters ["modifies" APPCName] InterfaceClassGraph Classes. Does this structure look right? -- Karl PS. Miriam from ECE is taking David and me on a hardware/software codesign adventure. That is why we bring in some hardware terminology. >From mira@informatik.uni-siegen.de Thu Nov 5 11:43:05 1998 >Subject: Re: merging APPCs >To: lieber@ccs.neu.edu (Karl Lieberherr) >> >> I guess we need to extend the syntax so that we can specify a mapping: >> >> Z{ >> int f() via A to B (SummingAPPC with ... , CountingAPPC with ... ); >> } >> >> We need to typecheck that the two APPCs are compatible. >> We need to agree on which APPC will return a value. The first one? >> >> How do we want to handle this? >> >> An alternative would be to define merge-composition of >> traversal-style APPCs >> and only give one APPC to a traversal, always. >> >> We would define >> >> MyAPPC = merge( components (SummingAPPC with ... , CountingAPPC ... ) >> output from SummingAPPC >> ) >> >> Z{ >> int f() via A to B MyAPPC with ... ; >> } >> >> -- Karl > > >Yes, we would need additional syntax and semantics - something like you >merge-compose operation or you can call it mapping if you want, in >order not to add terminology. In the absence of a visual interface >we would have something like: > > >Summing-LimitCheckingAPPC = { > Summing:Composite:after -> LimitCheckingDelta:Composite:actual;} > >We connect the single output of Summing to one of the inputs of >LimitChacjingDelta. This can happen before this is used. At this stage >we make sure that the connected input and output are compatible by >comparing the return type of Summing:Composite:after with the declared type >of the expected input "actual" in LimitCheckingDelta's ICG (both are floats >in this case). They must have either the same type or the output is >a subtype of the input. > >Now the created Summing-LimitCheckingAPPC has two remaining inputs and >one output. Well, for illustration purposes let assume that summing >also returns the total sum at the end. >Thus, we have two inputs and two outputs. > >int f() Summing-LimitCheckingAPPC with { > > {Car, Engine}:capacity() -> LimitCheckingDelta:Composite:limit; > //again, type checking happens here > > {CarParts:getWeight(), EnginePartsweight()} -> Summing:Simple:summableValue; > // both CarParts:getWeight() and EnginePartsweight() > // return floats and Summing:Simple:summableValue is > // declared to be a float - so that's OK > return Summing:return(); > } > >This is supposed to do summing and capacity checking, and return the >total sum calculated by the summing APPC. > >The syntax of mappings used above is ugly - is the first thing that came >to my mind. But, I think in general will be difficult to get an elegant >syntax for the mappings. That's why the optimal case is to get the visual >builder work for us and have the mappings be done by drawing lines. > >The CCG I have used above is the one I had once drawn in one of the very >first versions of writting the functionalities performed over the >composite pattern when I was in Boston. > >Hope you can get any idea from what I have written above. Don't expect >much more from me today -- after a lecture with 250 students! > >- Mira > > > > >