Further discussion on run/protocol notation changes
In the previous thread, I mentioned that we were looking to change the way parameters (roles initially) are bound between a calling and called protocol.
4) Running a protocol
The way in which parameters (roles initially) are passed (or bound) when running a protocol has been changed. Instead of binding to roles defined within the protocol being run, the roles (and in future other state) are defined as parameters of the protocol. For example,
protocol BuyerSeller(role Buyer, role Seller)
The way in which the protocol parameters are passed can be in two ways:
run BuyerSeller(BuyerRole, SellerRole); -- so positional parameters
run BuyerSeller(Seller=SellerRole, Buyer=BuyerRole); -- keyword parameter assignment, as used in the current version
However while implementing this change I realised there are some issues.
1) How should inline run commands deal with this change?
For example, previously we had:
protocol RunInlineProtocol {
role Buyer, Seller;
run protocol (SubBuyer := Buyer, SubSeller := Seller) {
role SubBuyer, SubSeller;
Order from SubBuyer to SubSeller;
}
Confirm from Seller to Buyer;
}
So the binding between the roles in the outer and inline protocol are specified as parameters to the run command. However in the new changed mechanism, the roles bound to a protocol are defined as parameters themselves.
So possibly this could be handled in two ways:
a) Use the same binding notation as above, where renaming is necessary, allowing the outer and inner role names to be different
b) As the inline protocol cannot be reused, the list of parameters defined by the inline run are just indicating which roles in the parent should be in-scope for the inline protocol - but the names must be the same.
Both approaches could be supported depending upon the outcome of the second point below.
2) Should both positional and key based parameter binding be supported?
From a parsing perspective, supporting both using the current notation is slightly ackward. For example, we could have:
protocol RunSubProtocol {
role Buyer, Seller;
run Sub(SubBuyer := Buyer, SubSeller := Seller);
Confirm from Seller to Buyer;
protocol Sub(role SubBuyer, role SubSeller) {
Order from SubBuyer to SubSeller;
}
}
So this uses the key binding approach, or
protocol RunSubProtocol {
role Buyer, Seller;
run Sub(Buyer, Seller);
Confirm from Seller to Buyer;
protocol Sub(role SubBuyer, role SubSeller) {
Order from SubBuyer to SubSeller;
}
}
this uses the positional approach.
When parsing into the object model, the <subRole> := <parentRole> is converted into a DeclarationBinding object with two role names. However in the positional case, the first (and only name) is the parent role, but in the key based approach it is the sub-role.
The conversion mechanism is generic, using configuration information to guide the process. So it would not be easy to cater for the difference - unless a 'hard coded' rule is defined specifically for this situation.
Just wondering whether the key based approach should be supported, as the positional approach is far more concise?
If keybased is not supported, then the inline discussion above is affected - it may mean that the inline protocol has to use the same role (and later variable) names as the parent, but is this really a problem?
Thoughts?
