9.3 Paul Klint

Dear Peter,

Your mail regarding the Common Framework Initiative has triggered quite some debate here.

On the one hand, we are in favor of any initiative that strengthens the field of algebraic specifications and promotes their application in industry.

On the other hand, there are several objections as well. Some of the assumptions made in the rationale of the initiative are at least incompatible with our own experience. In addition, work on this initiative will be a serious investment that conflicts with other activities. I will briefly explain each of these point below. This message ends with a proposal.

Rationale of CFI

The rationale behind this initiative is that the lack of such a framework greatly hinders the dissemination and application of research results. In particular, the proliferation of specification languages, some differing in only quite minor ways from each other, is a considerable obstacle for the use of algebraic methods in industrial contexts, making it difficult to exploit standard examples, case studies and training material. A common framework with widespread support throughout the research community is urgently needed.

I disagree. In our experience, the major stumbling block is to make the point that *any* formal technique might solve a problem in practice. Once this point has been made, the precise details of the technique are less important as long as it fulfills its promise. Clearly, everyone uses the techniques he/she is most familiar with and we are quite happy with the results of using ASF+SDF in industry. Several companies are now using it in various projects.

The current aim is to base the common framework as much as possible on a critical selection of features that have already been explored in various contexts.

That is reasonable. However, there are several points of concern:

• (1) The language should be as simple as possible, otherwise industrial users will not understand (and hence: not use) it.
• (2) Point (1) is incompatible with the tendency in many design projects in which increasingly complex logics and features are invented in order to desgn the "ultimate" specification language. Well-known examples like Ada and Common Lisp (as well as many other standardization efforts) do not make me very optimistic about "design by committee".
• (3) I fear the political consequences of the previous two points. It is likely that various research groups will start pushing their techniques in order to be included in the CFI. One seldomly sees that research groups give up their own line of work in favor of another direction invented elsewhere.
• (4) I wonder at what level you want to standardize. Will we see endless battles over concrete syntax, or will there be only a standardization at the level of abstract syntax? The latter will make it easier to provide tools for conversion to various concrete forms. It would be nice to have a very general exchange format for specifications that is liberated from most ideological bias.

Investment of time

At a global level, you know the research activities we are involved in. In addition to this we are starting a major project in the area of reverse engineering, again using our ASF+SDF technology. Clearly, it is for us crucial to optimally allocate our limited resources to these various projects.

Since it is obvious that full participation in the CFI will require a serious investment in time, CFI is competing with our other projects. My current estimate is that I have to put CFI on a relative low priority (but see below).

Proposal

I hope that you forgive me my, admittedly pessimistic, remarks. However, there are a few things we could offer.

First and foremost, we can offer to do some tooling for the CF once it has been designed. Clearly, the precise scope of these tools has to be negotiated, but we are certainly willing to make some positive contribution here.

Second, we are of course available to answer specific questions (or to prepare technical notes regarding technical issues that directly fall in our scope (e.g., ASF+SDF, user-definable syntax, compilation, tool generation, tool integration, etc.)

Finally, it may be a good idea to stay connected to the CFI as observers. Jan Heering (Jan.Heering@cwi.nl) is willing to act as our liaison person.

All the best,

Paul Klint

To: Paul.Klint@cwi.nl
Date: Fri, 20 Oct 95 16:51:03 +0100
From: pdm

Dear Paul,

Your mail regarding the Common Framework Initiative has triggered quite some debate here.

On the one hand, we are in favor of any initiative that strengthens the field of algebraic specifications and promotes their application in industry.

On the other hand, there are several objections as well. Some of the assumptions made in the rationale of the initiative are at least incompatible with our own experience. In addition, work on this initiative will be a serious investment that conflicts with other activities. I will briefly explain each of these point below. This message ends with a proposal.

Rationale of CFI

The rationale behind this initiative is that the lack of such a framework greatly hinders the dissemination and application of research results. In particular, the proliferation of specification languages, some differing in only quite minor ways from each other, is a considerable obstacle for the use of algebraic methods in industrial contexts, making it difficult to exploit standard examples, case studies and training material. A common framework with widespread support throughout the research community is urgently needed.

I disagree. In our experience, the major stumbling block is to make the point that *any* formal technique might solve a problem in practice. Once this point has been made, the precise details of the technique are less important as long as it fulfills its promise. Clearly, everyone uses the techniques he/she is most familiar with

I hope you are thinking of "algebraic specification and development", rather than some particular specification language, as a "technique".

But basically, we can agree that establishing a Common Framework, however well-designed it might be, is not going to magically ensure industrial use. Our initial aim is therefore to focus research and development within academia. We definitely do not want stop people getting industry interested in existing frameworks during the next years! Rather, we hope that the future development of many frameworks may converge towards the Common Framework in the long term, bringing their industrial contacts with them, and gaining from synergy.

and we are quite happy with the results of using ASF+SDF in industry. Several companies are now using it in various projects.

We are very much aware of that, which is one of our reasons for inviting ASF+SDF participation in the CFI...

The current aim is to base the common framework as much as possible on a critical selection of features that have already been explored in various contexts.

That is reasonable. However, there are several points of concern:

• (1) The language should be as simple as possible, otherwise industrial users will not understand (and hence: not use) it.

Let me emphasize that we are aiming at a family of languages: some very simple, some probably quite `sophisticated'. However, we intend this family to be centred on a single intermediate-level language, with the others being either sublanguages or extensions of it. Although this intermediate language will definitely not be "as simple as possible", it will at least not be burdened by the extra features that people will want to have in the extension languages.

• (2) Point (1) is incompatible with the tendency in many design projects in which increasingly complex logics and features are invented in order to desgn the "ultimate" specification language. Well-known examples like Ada and Common Lisp (as well as many other standardization efforts) do not make me very optimistic about "design by committee".

We will try to leave such complexities to the extension languages. The intermediate language is intended to be quite moderate in ambition.

• (3) I fear the political consequences of the previous two points. It is likely that various research groups will start pushing their techniques in order to be included in the CFI. One seldomly sees that research groups give up their own line of work in favor of another direction invented elsewhere.

The indications at the meeting in Norway were that the participants were indeed prepared to compromise on the details of the intermediate specification language. If they want restrictions, they can define a sub-language incorporating them; for extensions, a super-language. Rather than "giving up their own line of work", they will try to continue it within, or transfer it to, the Common Framework.

It would be very interesting for us to learn just which features of ASF+SDF you and your colleagues feel are absolutely vital to your work, but which wouldn't fit in with the Common Framework at any level.

• (4) I wonder at what level you want to standardize. Will we see endless battles over concrete syntax, or will there be only a standardization at the level of abstract syntax? The latter will make it easier to provide tools for conversion to various concrete forms. It would be nice to have a very general exchange format for specifications that is liberated from most ideological bias.

Certainly the initial emphasis is on design of abstract syntax, and different applications may well need different concrete syntaxes. However, as someone once said, the nice thing about standards is that one can have so many of them... perhaps each proposal for a concrete syntax would have to be approved by the CFI, to avoid irritating minor differences creeping in - and to keep the number of alternatives low. We haven't thought so much about that, although we realize that concrete syntax is an important issue. It's also an advantage when a framework is easily recognizable by its appearance, cf. Z.

Your work on exchange formats could be very useful to us.

Investment of time

At a global level, you know the research activities we are involved in. In addition to this we are starting a major project in the area of reverse engineering, again using our ASF+SDF technology. Clearly, it is for us crucial to optimally allocate our limited resources to these various projects.

One thing that all the current participants seem to have in common is lack of time... This is why we are trying to keep working meetings adjacent to other events which the majority of participants will be attending anyway: FME, AMAST, WADT. None of us (especially not me) is intending to spend any large proportion of their time on CFI-specific work - although we hope that a lot of their time goes on things which contribute less directly.

Since it is obvious that full participation in the CFI will require a serious investment in time, CFI is competing with our other projects. My current estimate is that I have to put CFI on a relative low priority (but see below).

That's not a problem for us. Any contribution at all is welcome. And I'm trying to make it possible for people not attending meetings to keep up with the development of the CFI, using WWW and mailing lists.

Proposal

I hope that you forgive me my, admittedly pessimistic, remarks. However, there are a few things we could offer.

First and foremost, we can offer to do some tooling for the CF once it has been designed. Clearly, the precise scope of these tools has to be negotiated, but we are certainly willing to make some positive contribution here.

Excellent! I see a large potential for using ASF+SDF tools in connection with the CFI.

Second, we are of course available to answer specific questions (or to prepare technical notes regarding technical issues that directly fall in our scope (e.g., ASF+SDF, user-definable syntax, compilation, tool generation, tool integration, etc.)

One of the first things we are doing is to make a catalogue of existing (major) specification languages, analyzing them according to a check-list that is just being finalized now. It will be very helpful if one of you would do the analysis for ASF+SDF.

Finally, it may be a good idea to stay connected to the CFI as observers. Jan Heering (Jan.Heering@cwi.nl) is willing to act as our liaison person.

Thanks, Jan. May we list you as a `Participant', perhaps without putting you in any sub-groups to start with? Please take a look at the WWW pages on the CFI, URL below.

All the best,

Paul Klint

Thanks for the time and care you took to state your position. I hope you'll consider some of my responses above, but let's not spend all our time writing e-mail on these topics!

[...]

Best regards

Peter