Polymorphic Data Types, Objects, Modules and Functors: Is It Too.Much.? Sylvain Boulmé, Thérèse Hardin, Renaud Rioboo
Total Page:16
File Type:pdf, Size:1020Kb
Polymorphic Data Types, Objects, Modules and Functors: is it too.much.? Sylvain Boulmé, Thérèse Hardin, Renaud Rioboo To cite this version: Sylvain Boulmé, Thérèse Hardin, Renaud Rioboo. Polymorphic Data Types, Objects, Modules and Functors: is it too.much.?. [Research Report] lip6.2000.014, LIP6. 2000. hal-02548309 HAL Id: hal-02548309 https://hal.archives-ouvertes.fr/hal-02548309 Submitted on 20 Apr 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Polymorphic Data Types Ob jects Mo dules and Functors is it to o much S Boulme T Hardin R Riob o o March Abstract Abstraction is a p owerful to ol for developers and it is oered by numerous features such as p olymorphism classes mo dules and functors A working programmer may b e confused with this abundance We develop a computer algebra library which is b eing certied Rep orting this exp erience made with a language Ocaml oering all these features we argue that they are all needed together We compare several ways of using classes to represent algebraic concepts trying to follow as close as p ossible mathematical sp ecication Then we show how to combine classes and mo dules to pro duce co de having very strong typing prop erties Currently this library is made of one hundred units of functional co de and b ehaves faster than analogous ones such as Axiom Introduction Any software engineer is aware of the imp ortance of abstraction in the pro cess development This concept corresp onds in fact to several dierent metho ds The rst abstraction metho d is binding binding an identier in a type expression ie dening parametric p olymorphism binding an identier in a value expression ie dening a function binding a signature ie building a functor The second metho d is to give a naming mechanism for collections of entities ie to oer ob jects classes orand mo dules etc The third one is a kind of hiding hiding denitions of types abstract data types abstractmanifest types hiding denitions of functions interfacessignatures hiding names private elds etc These three asp ects of abstraction are provided by most mo dern languages Some ones as Ocaml go a step further by oering p olymorphic data types with records and unions classes with multiple inheritance mo dules and functors Is it not to o much Faced with such a wealth of abstraction metho ds which do not seem so far from each other the programmer may b e puzzled when designing the implementation of a somewhat intricate sp ecication In this pap er we relate our exp erience in the Foc pro ject and we would like to explain why all these dierent handlings of abstraction are all needed together to satisfy the Foc requirements In the following we present briey the motivations of Foc Then we give a short acquaintance to its requirements in order to justify the choices made in its conception 1 The Foc pro ject started at the fall is aimed to build a development environ ment for certied algebra that is to say a framework for programming algorithms proving their mathematical prop erties and the correctness of their implementations This aim may b e a little surprising as by denition Computer Algebra Systems in short CAS work on mathematical entities represented by terms of a formal language whose rules describ e exact computations and algorithms system or userimplemented rely up on mathematical pro ofs So little place seems to remain for bugs as usually implementations are carefully done Despite of this care bugs are not rare algorithmic errors hasty simplications no verication of required assumptions etc bugs during co ding incorrect typing bad man agement of inheritance bad deallo cation etc As CAS tend to b e more and more used in critical systems rob otics cryptography physics etc safety prop erties are required on their outputs But usual metho ds to guaranty a high level of safety are here rather dicult to use for the two following reasons First computer algebra programs tend to b e large and complicated and hence dicult to maintain Then testing symbolic manipulations may b e dicult due to the size of the data for instance p olynomial co ecients with several thou sands of digits or the time needed for verication several hours of CPU time computations is common Furthermore the ouput may b e nonconstructive for instance the result that a given p olynomial has no ro ot The Foc environment is based on a library of algebraic structures which is providing not only the implementation of the classical to ols to manipulate algebraic structures but also their semantics given by explicit veried statements The user of Foc should have the p ossibility to sp ecify a given algorithm by using together elements of this library prove prop erties of this algorithm dene an implementation and prove its correctness This needs a strong interaction b etween programming and proving through user interface which has b een considered from the b eginning of the pro ject To increase safety the gap b etween mathematical description of an algorithm and its enco ding in the programming language has to b e reduced This requires a syntax p ower ful enough to reect mathematical prop erties as well as a rm semantics asso ciated with this syntax That was already p ointed out several years ago by Davenport and as no programming language was meeting these requirements the Computer Algebra community was led to develop its sp ecic programming languages giving birth to p owerful systems eg Axiom which is p erharps the most achieved But this eort is not yet sucient to get rid of bugs or ambiguities for example on solving multiple inheritance conicts Indeed the syntax of Axiom encourages the user to follow a certain programming discipline but there is no eective semantic control We tried to prove some prop erties of Axiom programs by interfacing it with the pro of assistant Co q The conclusion was that such a task needs a programming language whose semantics is fully understo o d and p ossibly formalized To decrease the distance b etween mathematics and co de to help carrying pro ofs we made emerging the following requirements R The overall organization of the library should reect its mathematical counterpart eg groups should b e dened up on monoids 1 F for Formel ie symbolic in French O for Ocaml C for Co q R Several levels of abstraction must b e available for a given notion the type of the op eration of a group can b e accessed b efore any implementation of it R Some notions may b e dened by default so that they can b e shared by a whole family of structures and still p ossibly b e lo cally redened for a sp ecic inhabitant of the family For example isdifferent should b e dened by default as the negation of isequal in any structure built up on sets with equality but may b e redened within sp ecic structures R Implementations of a given algebraic structure may b e progressively rened from an abstract view of ZZ one may go to an implementation ZI representing the inhab itants by integers and to another one ZB using b o oleans Some constructions have to b e shared b etween ZI and ZB R Dierent implementations of an abstract algebraic structure such that ZI and ZB must b e distinguished by typing in order to avoid confusions or misuses R The corresp ondance b etween the co ding of the structures in the programming language and the prover should b e as natural as p ossible R To have a true prototype the library should contain a signicant amount of basic no tions in Computer Algebra big integers mo dular integers and several representations of p olynomials at least the distributed and the recursive ones Indeed the problems arising at the level of certication can b e visible only after a certain amount of com plexity b oth in the organization of the algebraic structures and in implementation issues has b een reached These requirements are not all sp ecic to Computer Algebra they corresp ond to well known paradigms in programming languages The language must have a strong expressive p ower to meet R and also to ease R R together with R asks for abstract data types on one hand and concrete or manifest types on the other hand leading to mo dules R R R together call for ob jectoriented features classes inheritance late binding A functional programming style free from assignments but with exception handling helps for R R needs also an ecient language with recursive types and garbage collection Considering all these p oints the language Ocaml was chosen It has a very strong disci pline of types with parametric p olymorphism and type inference it provides b oth mo dules and ob jects which are p owerful enough to dene our library Moreover the interaction b e tween classing and sub classing mechanism and the typing algorithm is fully describ ed and semantically understo o d This choice b eing done the development is not yet ready to start In fact our require ments are in a certain sense contradictory Indeed R asks to dierentiate ZI and ZB by typing mo duleoriented asp ect and at the same time R asks to share some constructions b etween these two rings ob jectoriented asp ect Thus a design discipline