Dear Peter,I fully agree with the importance of the definition of a common algebraic specification language. The initiative being important a question is whether I have a role to play. In my view that is not the case because I am a theoretician. This may sound silly but I am afraid that it will get entangled in very problematic matters. The situation becomes difficult as soon as new theory has to be developed in order to get the design moving. I have seen that situation too often and I simply have to avoid it because it notoriously leads to inferior theoretical work (at least if I am involved). Then another problem may result if groups disagree on which theory to use. That is extremely likely to happen in the case at hand. If a disagreement of that kind appears we get into the worksop decision style where mysterious commitee decisions run the show and all one sees is the social power structure reflected in the results. Again I am not the kind of person to participate in such procedures. What I can imagine is that people send me documents which I can comment. Such comments would be personal and the language defining team would be entirely free to ignore them. That of course is always possible and need not be formalised in advance. It is my firm opinion that standardization projects of the intended kind often lead to languages which are too large. It is an enormous challenge to manufacture a language with wide approval that allows to write algebraic specifications that are not modularized, then to add imports and so on. As soon as there are too many features the language willhave no meaning to any outsider (and to some insiders who cannot afford to express their view without being stigmatized.) I think that the least one may say about a standardization effort for algebraic specification languages is that it is difficult bcause it would have been done already otherwise. One more remark is that we could strenhten the appearance of our field in very simple ways by listing a number of languages as 'accepted' and ask every author to mention these languages in his/her papers. The incoherence of the subject might then become less dramatic. By agreeing on a number of standard references and a mutual agreement of the pros and cons of the languages put forward in these standard references we may obtain a common metatheory about the subject. Having that common metatheory may help a great deal in making the further developments in each site in some sense compatible. I expect that Paul Klint will be available for some kind of participation in your plan.
Best regards Jan Bergstra
To: janb@fwi.uva.nl
Date: Thu, 12 Oct 95 18:09:37 +0100
From: pdm
Dear Jan,Thanks for your clear reply. A few immediate reposnses:
I fully agree with the importance of the definition of a common algebraic specification language. The initiative being important a question is whether I have a role to play. In my view that is not the case because I am a theoretician. This may sound silly but I am afraid that it will get entangled in very problematic matters. The situation becomes difficult as soon as new theory has to be developed in order to get the design moving. I have seen that situation too often and I simply have to avoid it because it notoriously leads to inferior theoretical work (at least if I am involved).We see that danger, and we are going to try very hard to avoid including constructs whose theory has not already been investigated.There remains the problem that new combinations of constructs may give rise to new theoretical questions, but that is (hopefully) more manageable.
Then another problem may result if groups disagree on which theory to use. That is extremely likely to happen in the case at hand. If a disagreement of that kind appears we get into the worksop decision style where mysterious commitee decisions run the show and all one sees is the social power structure reflected in the results. Again I am not the kind of person to participate in such procedures.So far, no-one involved in the CFI has taken a particularly defensive stance; on the contrary, people have been willing to leave their pet advanced constructs out of the intermediate-level common language (probably hoping that these can later be included in an extended language).Somewhat surprisingly, there already seems to be a general consensus to adopt partial algebras, with existential equalities - although no definite decisions are being taken at this early stage, of course.
So I'm quite optimistic on this point.
What I can imagine is that people send me documents which I can comment. Such comments would be personal and the language defining team would be entirely free to ignore them. That of course is always possible and need not be formalised in advance.Thank you, that will certainly be very useful.It is my firm opinion that standardization projects of the intended kind often lead to languages which are too large. It is an enormous challenge to manufacture a language with wide approval that allows to write algebraic specifications that are not modularized, then to add imports and so on. As soon as there are too many features the language willhave no meaning to any outsider (and to some insiders who cannot afford to express their view without being stigmatized.) I think that the least one may say about a standardization effort for algebraic specification languages is that it is difficult bcause it would have been done already otherwise.We are hoping that the idea of having a family of languages, with clear relations between them, will help. As indicated in the little diagram included in the report, we want an intermediate common language together with various sub-languages and extensions; but we'll have to hit just the right level for the intermediate common language, and that certainly won't be easy.One more remark is that we could strenhten the appearance of our field in very simple ways by listing a number of languages as 'accepted' and ask every author to mention these languages in his/her papers. The incoherence of the subject might then become less dramatic. By agreeing on a number of standard references and a mutual agreement of the pros and cons of the languages put forward in these standard references we may obtain a common metatheory about the subject. Having that common metatheory may help a great deal in making the further developments in each site in some sense compatible.That might be an appropriate way of terminating the CFI if we run into too many conflicts and problems to agree on a common language... And it corresponds somewhat to the situation with programming languages.[...]
Best regards
Peter
From: janb@fwi.uva.nl (Jan Bergstra)
Subject: CFI
To: pdmosses@daimi.aau.dk
Date: Wed, 18 Oct 1995 18:53:12 +0100 (MET)
Dear Peter[...] Further: if partial algebras have a current preference, what is the fate of total algebras. It would be very useful if such matters are clarified. The problematic outcome is the all too common view that total algebras are outdated. In fact groups are total and fields are partial, similarly in computing both coexist. Most process algebras are total and most algebras describing an evaluator for complex expressions are partial. So my question is: how are the simplest options dealt with. I have no answer but I take it for granted that many people will consider the proposal to start with a kernel language having total functions only boring whereas I consider that to be the best option
Best regards
Jan Bergstra
To: janb@fwi.uva.nl
Date: Thu, 19 Oct 95 08:59:07 +0100
From: pdm
Dear Jan,Further: if partial algebras have a current preference, what is the fate of total algebras. It would be very useful if such matters are clarified. The problematic outcome is the all too common view that total algebras are outdated. In fact groups are total and fields are partial, similarly in computing both coexist. Most process algebras are total and most algebras describing an evaluator for complex expressions are partial. So my question is: how are the simplest options dealt with. I have no answer but I take it for granted that many people will consider the proposal to start with a kernel language having total functions only boring whereas I consider that to be the best optionIf the common intermediate-level language is to allow partial functions, it is likely also to allow specification of the fact that particular functions are in fact total (e.g., by use of OBJ3-like attributes, or Z-like arrows). One can then define a sub-language by insisting that all functions have to be specified as total - perhaps this could also be abbreviated by a single keyword at the beginning of the spec. Of course the model classes need cutting down too (for loose semantics anyway).Thus both total and partial functions coexist in the common intermediate language, and you get your "kernel" total language as a sub-language. The point is that there may well be other kernel sub-languages, e.g., partial unsorted algebras, total equational algebras, and we aren't wanting to highlight just one of them.
Please don't focus on the details above, this is just meant as a quick indication of the intended overall strategy. Please tell me at once if you see some major drawback with that, as it's quite central to the organization of the design.
Thanks for your reactions.
Best regards
Peter
From: janb@fwi.uva.nl (Jan Bergstra)
Subject: Re: CFI
To: pdmosses@daimi.aau.dk
Date: Thu, 19 Oct 1995 16:14:16 +0100 (MET)
Dear Peter,If the common intermediate-level language is to allow partial functions, it is likely also to allow specification of the fact that particular functions are in fact total (e.g., by use of OBJ3-like attributes, or Z-like arrows). One can then define a sub-language by insisting that all functions have to be specified as total - perhaps this could also be abbreviated by a single keyword at the beginning of the spec. Of course the model classes need cutting down too (for loose semantics anyway).What you suggest seems obvious. But the possible drawback that I fear is that one has to add keyword after keyword in order to get into the 'classical' mode, i.e. the one that is used in LOTOS, SDL and many such languages of more academic status. What I think is that a stereotype BNF syntax that takes care of all possible mechanisms is not feasible. Rather one needs an environment that allows for a number of dialects each of whose are not burdened with keywords that serve no intrinsic purpose. What I mean is that if you have decided that all your functions will be total in the next three months, it becomes an unbelievable overhead if this very fact must be stated once more in every single case. So what I think is that these dialects have certain mechanisms in common: signatures , equations, equality sign, a notation for reduction, imports, exports, parameters and that we would make progress if a common toolkit were available to deal with these mechanisms. The least of all problems however is parsing and even type checking is a task that we may well leave to the local user. What I consider the main difficulty is how to handle large structured specifications, how to make progress in providing an international datatype library, how to make specifications as exchangeable as programs in C.Thus both total and partial functions coexist in the common intermediate language, and you get your "kernel" total language as a sub-language. The point is that there may well be other kernel sub-languages, e.g., partial unsorted algebras, total equational algebras, and we aren't wanting to highlight just one of them.
What I would propose is to have the small sublanguages first and to get them attractive and then to standardise them. Thereafter a common underlying mechanism is needed. In my view such spcifications may be rather like LATEX code. That means that
\begin{spec} XXX \end{spec}can be printed by all users in their favourite way. Using a dialect indication oe may then indicate how the specification is to be presented to its user community. e.g.:\begin{spec} dialect{TFCESS}...where this abbreviates total functions, conditional equations and finitely many sorts. The major task is: how to handle modularisation, and all the time how to enable different user communities a tailored and optimised representation.Best regards
Jan Bergstra