Template/Generic protocols proposal

[perneto]

I am thinking about a potential Scribble extension for generic/template protocols. For example, instead of having "repeat" as a primitive, libraries could define a template:

protocol repeat(Block) {

     role SrcRole, DstRole;

     rec Loop {

          choice from SrcRole to DstRole {

               iterate():

                    Block;

                    Loop;

               end():

          }

     }

}

// usage example, with new syntax to pass a block as a parameter inspired by Scala

repeat(SrcRole=Alice, DstRole=Bob) {

     String from Alice to Bob;

}

// usage example with predefined protocol as loop body

repeat(SrcRole=Alice, DstRole=Bob) { BuyerSeller(Alice, Bob); }

// or maybe

repeat(SrcRole=Alice, DstRole=Bob) BuyerSeller(Alice, Bob);

// or

repeat(SrcRole=Alice, DstRole=Bob)(BuyerSeller(Alice, Bob))

Such an extension would allow us to keep the core language small while still supporting rich communication constructs, a very useful property while we're still figuring out what constructs are most useful in different contexts.

We have a PhD student at Imperial (Nicholas Ng) who's going to be looking at HPC applications using Scribble. He'll want to support many of MPI's features, and an extension like this one will probably be necessary (MPI has many, many primitives!).

Also, I personally think it's extremely useful to give users a way to extend the language cleanly. This can make it usable in many contexts that haven't been thought of originally.

What do you think?

Olivier

[objectiser]

Its an interesting idea.

Pro is that it could enable flexibility in the way the language is extended, as you have mentioned.

Con is that I am not sure how much benefit this offers over simply composing shared protocols. Where it does make sense, I am not sure whether it really saves much - for example, you could have a 'cancel' macro, but it would need to be supplied with the (1) main normal flow, (2) the condition for cancel (i.e. an interaction) and (3) the cancel flow. However this is not much different from simply using the try/catch block with the related information.

So I think its an idea to be explored, especially if it offers benefits in a particular domain, but we need examples that illustrate the limitations of the current notation and the benefits of the proposed extensions (along with other alternative ways of solving the same problem).

I think that is generally the best way to evolve the language - driven by examples that highlight the limitations, and show the alternatives.