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 for the denition

of our library has to b e elab orated through the understanding of the balance b etween the

use of mo duleoriented and ob jectoriented features Doing that we have also to describ e

the dierent dep endency links b etween the library units in a rather uniform way to ease

forthcoming pro ofs

To have an account of the actual diculties arising from dierent design choices and of

their p ossible solutions we have written several versions of the basic library describ ed by

R These versions have b een analyzed according to three criteria whether they t RR

whether they are easy to handle b oth from the developers and from the users p oint of view

and whether they give rise to ecient algorithms This last p oint is imp ortant b ecause there

is no use to pay for the pro of of a program if it will b e rejected due to ineciency reasons

In this pap er we rst describ e the conception of Foc in section we then explain

briey in section why a rst try based only on mo dules was rejected and in section we

comment several ways of using the ob jectoriented features fo cusing on their drawbacks

The retained solution is given in section in a rather detailed way The current state of the

library is given in section and some eciency comparisons are done in section Along the

pap er we provide examples written in Ocaml trying to remain understandable to p eople

not acquainted with this language

Analysis of the FOCs conception

In the following sections we are commenting several ways for implementing the Foc library

These comments are done according to the sp ecication of this development which is de

tailed in this section

Engineers scientists etc use daytoday CAS like Mathematica and Maple for solving

symbolic problems such as integration or equation solving in much the same way that

they would use a p o cket calculator for numerical calculations However some domains

rob otics cryptography require very more involved computations with CAS need

ing wellengineered and robust libraries Foc is not intended to b e an interactive computer

algebra system like Maple but only to oer a library which can b e used by engineers to build

their own unit However a toplevel system may b e built up on it in the future

The job of computer algebra engineers is to implement mathematics more precisely to

implement to ols which compute with mathematical data Their aim is not to prove theorems

with some verication to ols but to pro duce data with algorithms built up on some theorems

The p oint where the approachs of engineers and mathematicians depart from each other is

the notion of representation in mathematics there exists a unique set of integers dened

by some caracteristic prop erties in computer algebra there are several implementations of

integers BigNums GMP etc sometimes needing explicit conversions b etween them There

are several ways to link mathematical data and their representations In the following we

give our approach and we compare it with Axiom one

Our vue

A CAS manipulates entities such as integers p olynomials etc These entities have a rep

resentation which must explicitely b e stated as part of their denition In our opinion it is

imp ortant to distinguish mathematical op erations p erformed on an entity from those p er

formed on the representation This give b etter control over the data b eing manipulated

These entities are characterized by prop erties of their op erations which rely on math

ematical prop erties together with representation prop erties We also want to have a clear

distinction b etween mathematical dep encies and data representation dep encies

Thus our choice is to have a neat separation b etween data manipulation and mathemat

ical prop erties handling Data manipulation is a concern of programming languages which

is not at all in the scop e of computer algebra For instance lists with their to ols and their

prop erties are assumed to b e available

Categories and domains of Axiom

In Axiom entities b elong to some domain which is presented as their type Domains

themselves b elong to structures called categories Categories are also presented as types of

domains

The membership of a domain to a category is asserted by a declaration and a domain

may b elong to dierent categories Categories may b e combined to build new categories by

adding some comp onents and by a join op eration So categories and domains are akin to

classes and ob jects with an inheritancelike mechanism The symbol is used to denote

the domain b eing describ ed or implemented It thus app ears as the classical self of ob ject

oriented languages But it denotes also the abstract type of its entities Categories exp ort

signatures containing names of available op erations with their prototypes written with

These op erations are not implemented at category level but inside each of the domains of

the category using the representation for entities chosen in the domain The representation

of entities is always hidden outside their domain denition and can b e manipulated only

by the signatures of the categories the domain b elongs to Thus with these signatures a

domain is like an abstract data type

In Axiomxl recent versions of Axiom the two faces abstractconcrete of entities is

explicited using two sp ecial functions rep Rep which gives access to the repre

sentation of the entity and per Rep which hides this representation Rep is a

conventional name to denote the representation of the entities rep and per can b e seen as

conversions b etween abstract and manifest types

Sp ecies and collections of Foc

Mathematical structures are here describ ed by species which are dened by a set of com

ponents describing mathematical op erations and prop erties available for an entity of this

sp ecie So sp ecies are roughly Axioms categories We detail carefully in the following the

atomic steps of the introduction a new sp ecie as each of these steps corresp onds to an atomic

stage of pro of correctness so needs to b e easily identiable in the source program

The representation of its entities is the rst comp onent of a sp ecie it is called the carrier

of the sp ecie Working in a p olymorphic typed framework the simplest carrier is a type

variable T T may progressively b e instanciated by a type expression still containing other

type variables or by an explicit data type This is a rst way of creating a new sp ecie which

is called carrier instanciation

The comp onents called primitive of a sp ecie are named and describ ed by their prototype

written as a type expression p ossibly dep ending on T or by a logical statement dep ending

on T for comp onents recording prop erties A given sp ecie can also have derived comp onents

which receive b eside a name and a prototype an implementation build up on the primitive

comp onents and functionalities supp osed available over T

A second way to create new sp ecies is to extend a given sp ecie by adding primitive or

derived comp onents For instance an additive group is an extension of an additive monoid by

a primitive op eration nding the opp osite of an entity and another primitive one that checks

an element to From these op erations one can describ e a derived binary subtraction and

implement equality which was a primitive op eration in the sp ecie of monoids in terms of

subtraction and zero check Sometimes an extension adds only new prop erties an ab elian

group has the same op erations than a group but has new prop erties

Now a primitive comp onent of a sp ecie can receive an implementation dening a new

sp ecie by a way usually called a renement so no extension of the sp ecication only a step

to approach a full implementation The co de has only to meet the declared prop erties of

the comp onent Thus the renements of a sp ecie share names prototypes some prop erties

and some denitions

A derived comp onent say c of a given sp ecie S may b e redened leading to a new

1

sp ecie S As in the previous case the new co de has to meet the declared prop erties of the

2

comp onent in S Moreover as redenitions of a sp ecie share also names prototypes and

1

some prop erties if some of these prop erties in S rely up on the co de of c they have to b e

1

reproved Redenition of primitive comp onents is considered as well

Whenever every primitive comp onent of a sp ecie has a denition this sp ecie can only b e

extended by derived comp onents We will call collection such a sp ecie if we dont want to

extend it anymore A collection thus app ears as a terminal element of the sp ecies creation

pro cess

Sp ecies can receive parameters as long as those are collections or entities Thus a

parametrized specie is a kind of function taking collections or entities and returning a

sp ecie For instance ZnZ the sp ecie of mo dular integers is parametrized by the integer n

and there exists a sp ecie of univariate p olynomials parametrized by the ring R of co ecients

All previous op erations on sp ecies apply to parametrized sp ecies Rening a parametrized

sp ecie may b e also done by instanciating some parameters For instance instantiating n by

builds the sp ecie ZZ and R may b e instantiated by ZZ

A sp ecie S can b e converted into a sp ecie S by etasblihing a corresp ondance b etween

1 2

the primitive comp onents of S and some comp onents of S ensuring the same prop erties

2 1

A sp ecie can always b e restricted to another sp ecie of which it is an extension Namely a

eld can always b e provided where a ring is wanted

Some op erations of a sp ecie can b e renamed to create a new sp ecie For instance in an

additive monoid we should b e able to rename the plus op eration into a mult op eration

and the zero constant into a one constant

Summarizing new sp ecies can b e dened by representation instantiation extension re

nement and parameter instanciation redenition Moreover conversion and explicit re

naming are needed These dierent links b etween sp ecies dene a sort of hierarchy b etween

them

The introduction has describ ed seven general requirements for Foc Having an easy

implementation for all these op erations on sp ecies is also a ma jor requirement As already

seen for RR these op erations on sp ecies corresp ond to mo duleoriented or ob jectoriented

features Thus we turn now to the description and the comparison of several attempts of

designing the discipline co ding of Foc

Data encapsulation

The requirement R of the introduction concerns safety collections must b e dierentiated

by typing in order to avoid misuses and inconstencies We fo cus rst on this p oint

As wellknown a simple way to increase safety is to exp ort only abstract types for the

representations Indeed data representation often uses implicit invariants Abstract types

forbid the user to misuse the representation by ignoring some of these invariants Further

more the representation can b e changed without disturbing users On the other hand devel

op ers of the units of the library need to know the exact implementation of the representation

So we t in the very usual discussion on abstract versus manifest types and encapsulation

of data representation It rmly corresp onds to a mo duleoriented programming style Our

rst try was to use mo dules only and we comment it briey

We recall that Ocamls mo dules system is a simply typed lambdacalculus language

with a subtyping relation and constraint expressions Structures allow to package together

denitions sharing a common environment which can b e referred to outside the structure

using the dot notation Signatures are interfaces for structures A signature sp ecies the

name and the type of the comp onents of a structure which are available from the outside

It can b e used to hide some comp onents of a structure or to exp ort some comp onents

with a restricted type Functors are higherorder functions from structures to structures

So abstract data types corresp ond to signatures and their implementations to structures

Sp ecies such as ring b elow are co ded by mo dule signatures and collections such that ZZ

by mo dule implementations

module type Ring

sig

type t

val equal tt bool

val plus tt t

val mult tt t

val opp t t

val one t

end

module Zz Ring

struct

type tbool

let equal xy xy

let plus xy x y not x y

let mult xy x y

let opp x x

let onetrue

end

The type abstraction mechanism is reinforced by the use of functors that allow to obtain

the desired level of type abstraction within parameterized collections For instance the

sp ecie of univariate p olynomials and the parameterized collection of sparse p olynomials can

b e describ ed as follows

module type FormalPoly

sig

module Base Ring

type t

val equal tt bool

val multextern Basettt

end

module SparsePoly ARing

FormalPoly with module Base A

struct

module Base A

type t At int list

let equal

end

The following declaration builds the collection of sparse p olynomials with co ecients in

ZZ

Zz Sp Poly Zz module Pol

Zzt and Zztint list are incompatible types the structures imp orting the Pol

sparse p olynomials do not have access to their representation

let id y

val id Pol Zzt Pol Zzt fun

id Zzone

This expression has type Zzt int list

Zzt Sp PolyZzt but is here used with type Pol

ZzBaset and Zzt are equal types This testies the correctness of the But Pol

co ding with resp ect to the sp ecication

So Ocamls mo dules system allows for an exact description of the sp ecication and its

p owerful typing algorithm helps a lot to avoid inconsistencies But as stated by R some

inheritance mechanism is needed There is no such p ossibility in the current version of

Ocaml We tried to micmic it by hand but it turns out to b e unrealistic when it comes to

realsize attempts Declaring inherited mo dules as comp onents of heirs leads to a notation

with a painful sequence of dots Putting by cut and paste the comp onents of the inherited

mo dule inside the heir is denitively to o hard to maintain Such a mechanism may p erharps

b e automatized but not so simply as extending it to mo dule structures and functors would

require a semantical analysis of co de Furthermore mo dules are designed to minimize the

propagation of mo dications during co de generation allowing separate compilation such a

use of them would not resp ect their purp ose

First runs with classes

Having a true inheritance seems to b e a necessity we are thus led to consider working with

Ocaml classes As stated by requirement R redenition of certain op erations is crucial

typically for optimization purp oses For instance the function multextern which com

putes the pro duct of a p olynomial with a scalar number may take advantage of the sp ecic

representation of sparse p olynomials Late binding allows to mo dify only those elds that

need to b e redened and these mo dications have not to b e rep orted in the metho ds using

these elds So we rmly want late binding

Entities as ob jects

We rst try to use ob jectoriented features as usually done in textb o oks on ob jectoriented

languages Sp ecies are describ ed by virtual classes collections by concrete classes and

entities by ob jects indeed by instance variables of ob jects But this simple design do es not

meet our requirements this can b e seen on the following example where the ring sp ecie is

describ ed by

class virtual ring

object selfa

method virtual equala bool

method virtual plusa a

method virtual mult a a

method virtual opp a

method virtual one a

end

The unity entity one and the opposite op erator opp have the same type Actually

types of comp onents do not reect their arities b ecause they are implicitly applied to the

underlying ob ject For instance binary op erations b ecome within this approach unary meth

o ds which introduces a gap b etween the syntax and mathematical notation Moreover opp

applies to the underlying entity whereas one is given by the underlying collection these

semantic dierences are not reected

Now instance variables such as myrep are private in Ocaml insuring data encapsula

tion However when co ding the binary op erations one needs to know the actual represen

tation given here by myrep of the explicit argument Therefore the value of the instance

variable has to b e made public by a sp ecic metho d called b elow rep This way the integer

collection may b e given by

class integers

object

inherit ring

val myrep

method plus x myrep myrep xrep

method rep myrep

method one myrep

end

We then face a new problem coming from the fact that rep is shared by all the subclasses

having the same carrier For instance the entities of ZZ may b e canonically co ded by or

by using an implicit invariant

class zz

object

inherit ring

val myrep

method rep myrep

method plus x let tmpmyrepxrep in

if tmp

then myrep

else myrep tmp

method print stringofint myrep

end

It is now p ossible to mix integers and mo dular integers as follows

let onezz new zzone

val onezz zz obj

let one new integersone

val one integers obj

let three oneplus oneplus one

val three integers obj

onezzplus threeprint

string

The implicit invariant has b een broken b ecause the metho ds of zz and integers have the

same name and the same type and thus are considered by Ocamls typing system to b e

compatible which should not happ en

In conclusion this ob ject oriented solution do es not t our requirements There is

no neat corresp ondance b etween the implementation of sp ecies and collections and their

mathematical semantics For instance the collection of integers is implemented by the class

integers of this mo del an ob ject of this class is the co ding of an entity of the collection but

carries within himself the unity and all the op erations of this collection and of the sp ecies of

rings The relation ob jectclass do es actually not t to the relation entitycollection This is

exemplied by the loss of arity mentioned ab ove which makes dicult to express prop erties

like asso ciativity or commutativity of op erations At last such a use of ob jects and classes

is rather inecient due to the continuous use of rep at running time Remember that

data encapsulation within mo dules is guaranteed by a typing mechanism without additional

cost at runtime

Classes as Abstract Data Types

We now want to restore the corresp ondence b etween type and arity of op erations by rending

explicit the implicit argument self We give here to the type a of the ob ject the same

status as in Axiom So binary op erations corresp ond to binary metho ds and constants

app ear as true constants In other words the representation of a sp ecie or a collection is an

abstract data type enco ded by a class

class virtual ring

object self a

method virtual equalaabool

method virtual plusaaa

method virtual multaaa

method virtual oppaa

method virtual onea

end

class integers

object

inherit ring

val myrep

method repints myrep

method equal xy xrepintsyrepints

method plus xy myrepxrepintsyrepints

end

This concrete class integers may b e viewed as a sp ecie if we want still to rene it It

will b e considered as a collection if the renement pro cess is frozen But how to interpret

int and zero the values my

int new integers let my

int integers obj val my

let zero

my intplusmy intonemy intopp my intone

val zero integers obj

my intequal my intzero

bool true

They have the same type they may b e compared But zero is clearly an entity wheras

my int may b e intended as a collection Distinguishing b etween these two p ossible uses of

ob jects may b e dicult at the pro of level

This mo del has b een developed up to the implementation of distributed p olynomials We

however rejected it as furthermore entities are still encapsulated in ob jects still paying the

cost of the calls to the rep metho ds

Encapsulating classes within mo dules

To dierentiate sp ecies collections and entities by static typing we develop a new mo del

which also gets rid of the instance variable myrep The information on the carrier is now

given as a type parameter a and has the same status than Axioms Rep Metho ds have

types dep ending on the carrier and not on an abstracted view of the representation For

instance the ring integers and zz classes of the preceding mo dels b ecome

class virtual a ring

object

method virtual equalaabool

method virtual plusaaa

end

class integers

object

inherit int ring

method equal xy x y

method plus xy x y

end

class zz

object

inherit int ring

method equal xy xy

method plus xy

let tmpxy in if tmp then else tmp

method mult xy xy

method opp x x

method one

method print x

stringofint x

end

The integers class implements the mathematical integers This class is concrete but

can still b e rened using inheritance We consider it rmly as the specie of the integers

More generally classes are considered only as implementations of sp ecies Collections are

always created only by using the keyword new So they are Ocaml ob jects Entities are

simply elements of the carrier of the sp ecie sp ecifying the collection Applying op erations to

entities is sending a message to the ob ject collection

Whit this choice we have a onetoone corresp ondance b etween mathematical notions

and semantics of typing But the problem of carrier abstraction describ ed ab ove remains

It is due to the p owerful mechnism of sub classing and cannot b e solved within the ob ject

oriented framework To handle this problem we prop ose the following solution

As dened ab ove the collection of integers provides access to its op erations but also to

its carrier This is ne for for example to pass them as actual parameters to parameterized

sp ecies But common uses of the library do not need full access to the carrier So it is safe

to add an encapsulation mechanism building structures called Ecollections

An Ecollection is obtained as follows

collection sig module type E

type abstract

collection abstract type class val a

end

module my E collection E collection

struct

type abstract some type

collection new a class let a

end

For instance we dene the Ecollection Zz by

module type Ring sig

type abstract

val a ring abstract ring

end

module Integers Ring

struct

type abstractint

let a ring new integers

end

module Zz Ring

struct

type abstractint

ring new zz let a

end

Calculations are p erformed using a ring and the sp ecication is type safe A user may

now declare an ob ject still called integers which allows him to use the integer collection

in a simple way

ring let integers Integersa

val integers Integersabstract ring

let one integersone

val one Integersabstract

ring let zz Zza

val zz Zzabstract ring obj

let onezz zzone

val onezz Zzabstract abstr

zzplus onezzone

This expression has type Zzabstract Integersabstract

but is here used with type Zzabstract Zzabstract

As shown by the previous examples an Ecollection A is represented via a mo dule as a

pair abstract some where abstract is the type of its entities and some is the ob ject

that contains the metho ds of the collection The representation of abstract should b e

known only by the sp ecies underlying A and the collections extending it while b eing hidden

to all users of the corresp onding Ecollection This mechanism can b e easily extended to

handle parameterized collections like p olynomials

In this mo del unlike the traditional way of programming in ob jectoriented style an

ob ject do es not have an internal state that is there is no instance variable The main p oint

here is that the class is completely describ ed by the functionalities of the sp ecies or the

collection in the same spirit as algebraic abstract datatypes Note however that in this

mo del the whole functional expressiveness provided by Ocaml is exploited

Description of the library

In its current state the Foc library is made of ab out Ocaml class for ab out lines of

Ocaml co de comprising

parameterized sp ecies by base integers which encapsulate small and big integers Cur

rently small integers are used to build degrees of p olynomials and small mo dular arith

metics Big integers are used as co ecients rings of those p olynomials Supp ort is

2

provided using two dierent big integer packages BigNum and GMP

Base sp ecies to provide monomials and ordering over those monomials Current imple

mentation supp orts several variables with lexicographical ordering providing degree

arithmetic The usual case of one variable is then seen as a sp ecial degenerated case

of this

Distributed p olynomial arithmetics is then provided up to exact division

This co de achieves most of the functionalities of Axioms p olynomials but with increased

reusability since in Axiom univariate and distributed p olynomials have dierent though

similar implementations

We then provide supp ort for recursive p olynomials with strictly higher generality than

those of Axiom In Axiom recursive p olynomials are an iteration of the univariate case

viewing a p olynomial in X and Y as a p olynomial in X which co ecients are p olynomials

in Y The carrier is a recursive type the base case is given by the co ecient ring and the

inductive case uses the distributed p olynomials sp ecie Supp ose given a a ring collection R

with carrier or a and a degree collection D with carrier or b then the carrier for

recursive p olynomials is

type ab recstruct

Base of a

Composed of stringabrecstruct b list

The type of recursive p olynomials is denoted by for short Here the parameter of type

r

string is used to represent the set of variable names of the multivariate p olynomial and to

dene the level ordering

Building the sp ecie of recursive p olynomials we have to express that the collection R or

r is a ring and that D or d is a degree collection Here R and D are Ocaml ob ject values

with types or r and or d resp ectively We achieve this by writing type constraints

constraint ring and

ordering constraint monomial

Now recursive p olynomial op erations usually pro ceed by calling univariate op erations

We depart from that by calling distributed op erations

We thus need a sp ecie D or distr p for distributed p olynomials not detailled here

p

Let us name by R or rec p the ob ject b eing dened in the class recursive pols Its

r

type is or rec p We dene it as a collection obtained from an instantiation of the

r

sp ecie D giving R as the actual co ecient parameter collection and D as the actual degree

p r

collection We thus need R to b e a ring with carrier

r r

2

other packages are b eing included

inherit ring

r

dp and we can now hold the collection D R D by dening a metho d the

p r

method the dp new D R D

p r

We thus have

class radb recursivepols rdrd

objectrecprecp

constraint r aring

constraint d bmonomialordering

inherit abrecstructring

method thedp let dp new distrprecpd in dp

end

dp can now b e used inside other metho d b o dies to encapsulate dis The metho d the

tributed op ertions For instance the co de for recursive p olynomial multiplication uses the

construction

let p q recpthedpmultpq in

Note that late binding and op en recursion is essential to this pro cess Current Foc

implementation uses further abstraction by manipulating a function F R ; D R D

p r p r

and uses an eective collection constructor and further type parameters which abstract the

eective D implementation of ditributed p olynomials

p

Benchmarking

Co ding with the Foc library uses functional style programming Most of Focs co de do es

not overwrite derivated comp onents and many op erations use their default implementation

which induces an extra cost Representations used in Foc are close to those of Axiom though

they are strictly more general It thus make sense to compare Foc with Axiom wheras it

would not with other computer algebra systems

The b enchmark consists in resultant computations they are determinant of matrices

that are computed using p olynomial arithmetics Op erations involved in the co ecient

ring are addition multiplication and exact division The same algorithm has b een co ded

using Foc and Ob jective caml and Axiom The two univariate p olynomials involved

30 20 10 25 15 5

are P x ax ax a and Q x bx bx with a varying and b a

The results are obtained on a p entium Mhz machine running redhat linux Timings

are computed by the Ocaml Systime function In Axiom time statistics are unreliable

in the presence of garbage collections and we designed our own timing function from the

basic timer of the underlying Lisp system Both timimgs take GC activity into account

3

The rst b ench in gure mesures big integers capabilities and a is an integer in the

100 700

range to The result is also an integer with to digits in base

3

dashed lines represent theoretical complexity for Karatsuba multiplication which app ears not to b e

implemented in either big integer packages

Figure subresultant calculation of P and Q

Subresultant calculations of P and Q

3

Axiom secs

3

158

x

Output Digits

Foc secs

2

3

158

x

3

3

3

2

2

3

2

2

2

3

2

2

number of input digits of a

Ob jective Caml has the ability to pro duce byte or native co de in the previous computa

tion b oth timings cannot b e distinguished since most of the time is sp ent inside big integer

calculations We thus can see that Axioms big integers are less ecient than Ocaml

P

i=k

i

In gure we change the co ecient ring and a will b e a p olynomial of the form A

i=0

The result is a p olynomial in A of degrees varying from to We measure this degree

the maximum size of the results co ecients which are integers together with times Here

the size of co ecients varies from to digits in base

Here numbers are relatively small and time sp ent inside big integer arithmetic is negligible

with resp ect to the time sp end inside p olynomial arithmetics p olynomials in A We can

see that timings compare for the byte co de version of Foc and are much b etter for the native

co de version of Foc

Conclusion

The title of this pap er expresses well our questioning at the start of the Foc pro ject Carrying

out several sizeable prototypes we have b een able to elab orate an answer which shows that

all the abstract metho ds oered by our programming idiom are needed Some other languages

oer a mechanism inheritance within mo dules For instance mixins are mo dules in which

some comp onents are deferred ie their denition has to b e provided by another mo dule

They can b e mutually dep endent and their comp osition supp orts redenition of comp onents

But this is not enough as late binding not only overidding is also crucial

What we have done in fact is to design a framework welladapted to the sp ecication of a

given trade the one of the computer algebra engineer And we think that this exp erience can

b e redone with another trades chemistry physics etc leadind p erharps to very dierent

Figure subresultant calculation of P and Q

Subresultant calculations of P and Q

Axiom secs

3

max output digits

3

degree

FocByte secs

FocNat secs

2

3

3

3

2

2

3

2

2

3

2

3

2

2

P

i=k

i

a A

i=0

uses of abstract metho ds So as a rst conclusion this is indeed imp ortant to disp ose of a

programming language with rich features but only if they are semantically wellunderstoo d

so if they can serve to express without ambiguity the sp ecications of a given area

As a second conclusion we may say that to obtain a full certication the compiler of

the programming language should itself b e certied No such compiler exists for the time

b eing even if some kernels of functional languages have b een formally studied Nevertheless

it would have b een completely irrealistic to try to create our own programming language

As it is a semantically well founded language Ocamlis a go o d compromise Using only a

functional style certainly will help the pro ofs to b e done Also the richness of the syntax

allows to co de algorithms very closely to their mathematical formulation This will help also

proving stages

The third conclusion may b e on eciency We have noted that the encapsulation of data

inside ob jects is really costly But there is no need to use it On the opp osite me may claim

that functional style is ecient more ecient in this case than traditional implementations

making ne tuning of p ointers

As shown by the number of classes and the b enches the library has now reached the

state of a full development Our design conception has b een tested by students which have

added some units following it without diculties On the side pro of the ma jor dicult

p oint is to dene the representation of sp ecies collections and of the dierent op erations on

them A solution based on dep endent lab elled records co ded in Co q is under submission

The next step of the pro ject is to dene the user interface that is a syntax for programs

and statements welladapted to computer algebra engineers and to extract Ocaml co de and

Co q co de from it

Acknowledgments

We would like to acknowledge the Co q and Cristal teams at INRIA for the languages Ocaml

and Co q This work has b eneted of numerous discussions with V MenissierMorain D

Hirschko D Doligez M Moreno V Viguie the members of SPI and CALFOR teams at

LIP the members of the CFC action at INRIA

References

G Alexandre DAxiom a Zermelo These de luniversite Paris February

D Ancona and E Zucca An algebraic approach to mixins and modularity In M Hanus

and M Ro drigez Artalejo editors ALP LNCS Springer Verlag

Co q pro ject The Coq Proof Assistant Reference Manual version

Judicael Courant MC un calcul de modules pour les systemes de types purs These de

do ctorat Ecole normale superieure de Lyon February

J Davenport and Y Siret and E Tournier and D Lazard Computer Algebra Masson

Richard D Jenks and Rob ert S Stutor AXIOM The Scientic Computation System

SpringerVerlag

Xavier Leroy The Objective Caml system release Software and do cumentation

available httpcamlinriafroc aml

Didier Remy Des enregistrements aux objets Memoire dhabilitation a diriger des

recherches en informatique Universite Paris september

Didier Remy et Jerome Vouillon Ob jective ML An eective ob jectoriented extension

to ML Theory And Practice of Object Systems to app ear

David R Stoutemyer Crimes and Misdemeanors in the Computer Algebra Trade No

tices of the AMS pp September Vol Number

Jerome Vouillon Using mo dules as classes In Informal proceedings of the FOOL work

shop available at httppauillacinriaf rr emy fool

S Watt P Broadb ery S Do oley P Iglio S Morrison J Steinbach et R Sutor

AXIOM Library Compiler User Guide NAG Ltd March