We have a single fixed class record for all instances of structures in that class. That is, all instances of structures in the class will contain a pointer to exactly the same record in memory.

A class record contains only procedures. Property lists provide a primitive subclassing mechanism. That is, for each given type of class record (group, ring field, etc.), we can instantiate variations of it with different property lists. The procedure-only principle extends to property lists - they contain only procedures.

We seek to enforce the paradigm that data (e.g. matrix size, variable list, minimal polynomial) pertains to particular instances of structures, and that it goes in the instance record of each particular structure.

Certain familiar structures, e.g. integers, reals, bigrats, are automatically created by the package.

For some differences between algebraic structures it is clear that we need different built in kinds (classes) of structures (e.g. group, ring). Having established our builtin kinds of structures, it is clear that there can be small differences among structures of a given kind; these distinctions we make via the property list (e.g. ordered rings). Properties possessed by all structures of a given kind (e.g. identity, characteristic for rings) are in the class record for that kind, provided that (1) their values can be obtained by invoking procedures, (2) it is reasonable that the parameters of such procedures be REF ANY, or a particular structure kind, which is all we have available in the AlgebraClasses interface. Properties not meeting these requirements, and clear interface data, have to go in later interfaces.

For some "properties" it is less clear where they should go; generally we put them on property list (e.g. Euclidean domain). The value of a property may be a record of operations that are available because a structure has a given property (e.g. comparison ops made possible by order property).

Our view is that an algebraic structure consists of two things - a class record of operations (some are defined for all rings, and others, on the propList, are defined only for some subclass of rings), and instance data.

The ring class record contains procedures for the class, where a "class" of rings is all those rings builts up using a particular constructor. We can take the definition of what proc definitions belong in the constructor interface as: those which are the same for all rings in the class.

Something that allows us to get polymorphism out of our structuring interfaces, e.g. polynomials, matrices. Each particular flavor of polynomial or matrix is defined to be a just a generic polynomial or matrix, e.g.

One way that this pays benefits is that the ring instantiation procedures can be in the constructor interface, because when the class procs do their NARROWs, they get generic polynomials.

The interface for a new structured ring can get a handle to its ground ring in one of two ways: either the ground ring has already been instantiated in some other interface, or we instantiate it in this interface. In either the case, the direct procs just call appropriate constructor procs, passing them the ground ring.

The place where type checking really happens is when we get down to operations on the ground ring, i.e. the class procs for the ground ring will do NARROWs which will fail if the wrong ground ring is present at the bottom.

The interface for a structured ring contains two things.
(1) the instantiation of the ring.
(2) direct procedures for operating on elements of the ring.

The direct procs have inputs and outputs of the particular structured ring type. They utilize the structuring operations to do their computation. They don't have to NARROW their inputs, but they do have to NARROW the outputs they get back from structuring operations.

To instantiate the ring, you define class procs which narrow their arguments and call the direct procs. Obviously there is no need to "widen" the outputs that come back from the direct procs. You might say that the NARROW done by the direct proc is wasted effort, but this is the price one pays for the convenience of having the direct procs, which anyone who is a direct client of this ring will use.

The standard naming convention is that the direct procs have names which mimic the fields of a ring class, e.g. "Multiply", and the class procs simply put the word "Class" before this.

If you get an op for a ring via its class record (as is done e.g. by structuring operations), you have to NARROW the result, since by definition, AlgebraClasses.UnaryOp, BinaryOp, etc. return a REF.

A finished, structured ring knows what its ground ring is, and even though that information is not in its elementType declaration (e.g. we define RatPolynomial: TYPE = Polynomials.Polynomial), it will be used in ring's direct procs, and indeed, the ground ring should be clearly stated somewhere at the beginning of the interface. Thus, in order to build up a structured ring you have in mind, all the "lower order" rings have to exist, i.e. have been instantiated, and you have to know what at least the outermost of the interfaces containing those instantiations is to get your hands on the outermost ground ring you need.

We expect that, in general, one will want additional operations on a ring than those provided by its class record or property list. These will be implemented by a separate sequence of interfaces. Thus, if one wanted an integer polynomial factorization algorithm that did complete factorization of the integer content, it would be necessary to have an integer factorization routine. To us it is appropriate that you do not, and do not expect to, find such a procedure in the class record or property list for the integer ring.

There seems little uniformity in how much genericity will be possible in such modules. Thus it seems clear that one can have generic polynomial division and real root isolation modules. Gcd seems clearly to admit genericity for prs algorithms (since pseudodivision does), perhaps for Chinese remainder lifting of variables, for multivariate polynomials over a field (use prs algorithm at univariate base), and not at all for Chinese remainder lifting of integer coefficients. There appear to be two kinds of polynomials we want to factor, rational and algebraic, possibility of genericity unclear.

This point of view has an algebraic interpretation - we are saying that the only kinds of "finer grain" ring operations we are willing to build into the class structure are ordered rings and fields. Operations pertaining to euclidean domains, or unique factorization domains, have to be implemented outside the ring structure. Thus the ring structure makes it easy to get I/O and basic ring operations for algebraic polynomials, giving you a platform from which to separately do the additional work to e.g. get factorization.

We try to follow the rule that there is one class record for more than one domain. However the sequence constructor violates this; every time you make a new sequence structure you make a new class record. The problem here is not that we have a class that has only one domain in it, but the "lack of uniqueness" aspect: we unfailingly create the new class record every time, regardless of whether we might already have made this kind of sequences.

This can be dealt with by having unique hashcodes for structures, and a registry of all created structures, and then every structure constructor checks the registry to see if a requested structure is already there. This could be handy if someone tries to recreate the basic structures, or e.g. to prevent algebraic number routines from multiply recreating the same algebraic number field. Hashcodes should probably be ropes.

There is a tension between having e.g. a PolynomialOpsRec that goes on the property list, and simply having procs in the interface; currently we do both (i.e. we're redundant). The general problem is that we have a single kind of StructureClassRec defined in AlgebraClasses, that has to be made to serve all algebraic structures. A better mechanism would be to simply put REF PROC's on the property list, plus build up a list of the available ops. Only the things which absolutely every structure has, e.g. a printNameProc, would be hard fields of the class record. Algebraclasses would export a "dispatcher", which would take in the name of a desired proc and know whether to get it out of a record field or off the proplist.

The general issue is - how to make all knowledge about what procs are available in a structure exported to clients by the run-time structure (ideally even including documentation, perhaps a la pop-up buttons). Then the CaminoReal user interface could be just like any other client, and would contain no hardwired knowledge of the underlying algebra system, except for knowledge of the generic mechanism by which the specifications of a structure are encoded.

We then have a field in class records in which is stored a list of triples: property name, whether in class record or a proc on property list or a property value on the property list, and a documentation rope. Class record then offers procs to tell you whether a property exists at all, or to get its value on the assumption that that value is a proc, or to get its value on the assumption that that value is a bool, or to get its value on the assumption that that value is a rope, etc. Also there is a proc to do a full printout of the triple list - names, nature of values, and documentation ropes. Some other proc returns a list of (standardly modified, e.g. remove "$") names of proc-valued properties; this can then become part of the pop-up menu of ops for that structure.

AlgebraClasses offers a proc that takes five args (a StructureClass variable, a PropName, a Ref that is the prop value, a specification of the nature of the value, and a documentation rope), and does two things: puts the prop on the StructureClass's proplist with the specified value, and adds the (PropName, specification of the nature of the value, documentation rope) triple to the list of triples stored in that StructureClass). The Impl module for a class then has as part of its start code a call to this proc for each op associated with the class.

A basic convention is that the procs implementing structure ops should all have types defined in AlgebraClasses.

Thus we insist that our structures are "run-time self-documenting". The run-time user can find out in a standard way what's available in a structure. The client is expected to look at the interfaces, or perhaps there is a manual that tries to stay up to date (one way it might stay up to date is to regenerate itself on the fly, i.e. whenever you want to display it, it goes off and actually calls the same sort of procs we have been talking about, in all the interfaces, to produce a list of what ops are available).

MethodApplier: PROC [methodSelector: ATOM, argList: LIST OF Object, structure: Object ← NIL] RETURNS[value: Object];

A basic rule: every method must return exactly one object.

AC.CheckMethod, AC.DesiredArgStructures, AC.PerformMethod, etc. look in the method dictionaries of their structure arguments, and if need be, the method dictionaries of their superclasses.

6/20/87 - Consider a Structure S whose class (i.e. the value of field S.class) is C (C is an Object of flavor Class). There are two possible flavors of superclasses (i.e. flavors for C.class) in this situation: Class or Structure. The first sort is obvious - consists of methods, corresponds to inclusion of categories. The second sort is only appropriate in case S is the only Structure in its class. Then if S is a substructure of a Structure T, we can set C.class to T. The obvious example is Integers are a substructure of Rationals are a substructure of Reals. The effect is that if we are searching for methods and don't find them in C, and we see that C.class is a Structure T, then we will continue our search in T.class. It is assumed that if C.class = T, then T's recast proc can handle elements of S.

At the moment only single inheritance is supported. Can fake by having superClass methods in Class.

General note on inheritance: the Smalltalk paradigm seems to assume that a class has one model: a subclass is a subset of that model consisting of all elements that have some further property. Thus the (unique) model of a subclass is a subset of the (unique) model of the class. The situation we have with algebraic structures is rather multiple models. I.e. we have a category, e.g. the real closed fields. All models in this category may have an add op, but you can't give a single particular add proc that will work for all models.

How do Views, Scratchpad, etc. deal with this issue?

Combiner uses CaminoReal.

Separate BigRats for CedarChest like BigCardinals, not AlgebraStructures?

How should users specify new operators, or new domains? Need to specify things like canonical forms, formatting rules for legal expressions.

Automatic conversion where appropriate, or tell user to modify domain if he want that op?

How hard is automatic domain inference for an arbitrary expression (Scott Morrison)?

What are the correct specifications of a general substitution facility?

For any polynomial, we need to keep track of 'what variables it's a polynomial in'. This is accomplished by associating a variable sequence with the polynomial. This is a sequence of Ropes (the variables). In order for scanning to work, variables should be Cedar identifiers. A variable sequence should be written as comma-separated variables enclosed in parentheses (whitespace ok anywhere except within a variable). For example, "(x,y,z)".

When you have a variable sequence into the ScratchPad, and some coefficient domain, you can apply the polynomial constructor.

Algebra-format Rope: (-38368.0 + 22976.0 i )

Display Expression:

At present, CaminoReal insists that anything that is to be considered a complex number must be created with the complex template from the menu, and hence be displayed in the form X. Thus for example, complex zero must be dealt with as X (or X; the presence or absence of decimal points doesn't matter) and complex one as X. Also, complex numbers with negative imaginary part will appear as in this example: X. Given this rigidity, one can perhaps live with the fact that complex numbers are not enclosed in parenthesis, e.g. here's an example of how CaminoReal currently prints a polynomial in x with complex coefficients: X

A polynomial is written as a sequence of terms in the variables of that list. Order of terms doesn't matter. Multiplication is implicit (whitespace between coefficients and variables). Exponentiation is indicated by either "^" or "**". Order of occurrence of variables in a term doesn't matter (no duplicate monomials allowed, however). Error if a variable not in the variable sequence occurs, but not all variables in the list need occur in any given polynomial. Case matters in variables. Order of occurrence of variables in a term doesn't matter.

No simplification currently supported in input, e.g. (x + y)^2 is illegal.

For example, suppose Domain is Polynomials in (x, y, z) over the Rationals.

Algebra-format Rope: x z^33 - 92837498279872983749734 / 33 y**23 + x y z - 1

Display Expression: i

Domain is 2 x 2 Matrices over Polynomials in (x) over the Complexes.

Algebra-format Rope: [ [ x , (1.0 + 1.0 i ) x^12 + (0.0 - 1.0 i ) ] , [ x^3 , x ] ]

Display Expression: X

Suppose the domain is extension of Rationals by the unique real root of X between -2 and -1.

Algebra-format Rope: [ x^3 + 647364/19 x^2 - 3 x + 1/8 ]

Display Expression: X