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.

I would suggest another option: for protocols defined in the scope of another protocol, allow capture/closure on role names already in scope.

This would turn the above example into the much more concise:

protocol RunInlineProtocol {
     role Buyer, Seller;
     run protocol {
          Order from Buyer to Seller;
     }
     Confirm from Seller to Buyer;
}

I also commented in the other thread about getting rid of "run" to unify it with recursion labels. In this context, an inline subprotocol could just be a block:

protocol RunInlineProtocol {
     role Buyer, Seller;
     {
          Order from Buyer to Seller;
     }
     Confirm from Seller to Buyer;
}

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?

I support using the positional approach only for now. Ultimately if we do want named parameters back the parser will need to have two separate cases, but I also prefer the conciseness of positional parameters in most cases.

Regarding inline protocols, I think you're basically suggesting the same thing I made explicit above: closure on role names in scope. Clearly I don't think that's a problem, it's more of a feature for me.

Olivier