[Indigo]<CaminoReal>CaminoRealNotes.tioga!1

CaminoRealNotes.tioga

Dennis Arnon, October 13, 1986 12:52:18 pm PDT

CaminoReal Notes

Dennis Arnon

1. Major current open issues 5/22/87

b. Improve repaint speed (incremental update)

c. Improve quality of screen fonts - graceful behavior over scaling

In the integrated environment we have to deal with both. Some math notations correspond to programs, others don't.

d. Algebra servers on Lisp

e. Integration with ESW software

We should offer access to it.

d. Clean up arithmetic - offer both nice structuring and optimized special domains

We should offer access to it.

1. General principles

1. We have our own internal (Tioga) representation of documents, and our own schemes for document manipulation, but when all is said and done, we want to be able to produce TeX (macro) output (except perhaps for graphics). Maybe we'll try to be able to read in TeX docs.

2. We want a single language suitable for encoding math, simple programming (control structures, functions), and formatting directives. We adhere to the "programs are data" rule, i.e. any program is cast into the form of an expression that can be evaluated. Functions can be defined and assigned to environment variables. Functions offer local variables.

3. Every algebraic user action should be expressible as an expression in the universal language, and will be logged into a Tioga document, the AuditTrail. You play it back by evaluating the appropriate expressions.

4. For the foreseeable future, we will use the Tioga artwork mechanism for placing math in Tioga documents. The "semantics" for math that are stored with math artwork characters or nodes in Tioga docs are in the universal language. This decouples us from assuming any particular editor for processing of Tioga documents with math. At the very minimum, there need not be an editor, just somebody who can read in the universal language and paint it. Similarly, there is no particular assumption about evaluators, i.e. the algebra. There is the general environment-maintenance mechanism, i.e. symbol table maintenance, but no necessary assumption about being able to make any nontrivial simplifications of mathematical expressions themselves.

We are able to place expressions of type "sequence" in documents as a equence of their constituents. Concatenating the universal reps of these simpler components must always give us the universal rep of the sequence object.

5. No particular domain structuring is assumed in the algebra system. Note however that the universal language contains the ability to represent certain domains.

6. Whenever we paint an expression, we are always given a sequence of boxes/strips to paint it into, and the particular display we get depends on these, i.e. they are constraints we must satisfy.

7. We have multiDocuments, i.e. multiple levels, Like a constraint network.

7. Applications: proofreading, spreadsheets, computed documents (mathematical form letters).

1. General properties of documents

Their typical characteristics are: multiple things, of multiple flavors (flavor = medium). Documents are not necessarily printable, since paper is an old display medium that is ever less useful. Really a document is a snapshot of state, for some notion of state, at some instant of time.

The canonical situation is: browsing the things of current interest, selecting one or more of them in some definite order, applying an operator to the selections, which typically results in the creation of one or more new things, that are put someplace. "Operators" may be either mathematical operations or editing operations. Typically at any point in time, some of the things of current interest reside in documents, while others reside in desktops, bags, ashtrays, or any other sort of repository there happens to be.

Documents are always assumed to be interactive, in the sense that you are able to select individual constituents, to some level of granularity, and insert new constituents. Furthermore, relationships among the constituents of a document may be imposed. These relationships exist and are edited at some metalevel, i.e. above the display level. In general, a document has multiple levels, the bottommost of which is presumably the one you are ultimately most interested in looking at. The "value" of a level, or the values of components of a level, all of which are assumed to be things that can be seen or heard, can be made to depend on values of things at the next higher level. Each level can be "recomputed in the current environment", i.e. "run off", on demand, where the current environment means the current value of the next higher level. There is also a notion of "recomputing the entire document", which means successively recomputing the levels from top to bottom.

In general, we should save that bottommost layer, which is a bitmap, or IP fragment, and only recompute it upon demand (or if something changes, e.g. all of a sudden we want to display an expression in a different sized box then is current). This raises the question of how Tioga does things, e.g. whether it saves screen images, or recomputes them every time a document is scrolled, especially with respect to artwork nodes.

In general, is it accurate to say that Tsetter "recomputes" a Tioga document in order to print it?

Thus, for example, according to this view, the basic way that math is stuffed into a Tioga doc is to generate an IP fragment and put it in as an ordinary Artwork node. But the semantics (univeral language representation) is also stored with it, and there are easily invokable procs that will recompute the IP fragment or bitmap from the semantics.

Are ordinary Artwork nodes bitmaps or IP fragments?

3. A universal language for representation of mathematical objects and actions

The language should have the following properties:

1. It is sufficiently rich to encode any desired data structure or action. In particular, any domain can be represented as an object in it.
2. It is arbitrarily extensible.
3. A legal input mode to CR is to supply a string of this language. The "keyboard language" consists of a variation, or perhaps a subset, which can be parsed on the fly. There are parsers for the language that produce either editor internal rep, or AlgebraStructures internal rep.
4. It contains some common programming constructs, e.g. loops, conditionals.
5. It consists of TeX, or at least TeX macros. Thus any string in it can have the macro definitions prepended to it and be run through TeX. This completely ignores, however, the issue of linebreaking, i.e. whether an expression can be fit onto a TeX page in the current environment. To get this, you ask the Display routine to format the expr in accordance with certain constraints.
6. It allows for "soft", i.e. formatting constructors, e.g. \Newline {\Linesize ...} Which the parser will throw away when reading in such an expr (unless, perhaps, you ask it to save the information of this sort that it reads). In general, if you read in some UniversalRep to either EditorRep or AlgebraStructuresRep, and then convert back to UniversalRep, there will be either be no, or different, formatting constructors present.

This representation is distinct from the Meddle internal rep. There are conversion routines to/from, which work by table lookup?, i.e. to know whether any particular math construct is Atomic, Compound, or Matrix type of MeddleRep. Since the language is essentially TeX, the EditorRep -> UniversalRep converter amounts to an EditorRep -> TeX converter/

There is a constructor called \File, which basically means: Sequence of Expr's. There can be more specific types of File, e.g. \CadInputFile.

Need for Macsyma-like functional definition of objects, i.e. say you want the 4 x 4 version of aij = gcd(i,j).

2. General display paradigms

We are given either a single box, a single strip, or a finite sequence of boxes, or a finite sequence of boxes plus a template for as many more of those boxes as we need, to try to fit the expression into. The particular display we get for an expression will vary to fit the specifications. The display proc is controlled by a "Rules for expression display" database and constraint solving system.

We have the following methods for fitting expressions into smaller spaces:

1. Linebreaking
2. Ellipses
3. Reveal/unreveal, e.g. Sum(25).
4. Iconification: user-controlled tree closing, or search for common subexprs and replacement of each occurrence by an icon; the general rule is we iconify closed-up subtrees. Fisheye views are a global "automatic" mechanism for achieving the same thing.
5. Scaling.

If the expression we end up fitting into our boxes/strips contains icons, then the default is to include the icon definitions at the end. This can be a multilevel thing, i.e. the definitions of icons can contain icons, whose definitions will then be appended, etc.

Thus display always occurs in some "current environment". Thus we need to distinguish "content", which is what we wish to display, and "form", which is the way it is displayed in the current environment. Content may also be computed in some current environment, but presumably this is a little bit less dynamic than form computations.

Thus note that if we have one set of boxes/strips in effect for a CR viewer (or viewers), and another is imposed by Tioga, then if we hit the ToTioga button, the display we see in the Tioga document may be different from what we see in the CR viewer(s).

Note on selection with respect to multiline exprs in a CR viewer: expression breaking is such that individual lines always consist of one or more selectable expressions. If the mouse points within a line but outside any subExpr, then it selects that entire line, or portion of a line. One CNTL-P then selects the entire Expr. Thus in a CR viewer, a multiline expr is still a single expr (this is achieved with an n-ary $MultiLineExpr type of MATRIX Expr).

When the display routine breaks an expr that is going into a Tioga doc into multiple lines, each line is a separate character and a separate Expr. UniversalRep for the line that begins with "soft" formatting constructors, e.g. \NewLine, \ContinuationLine This enables us to achieve the "concatenation principle", that we should be able to concatenate up the UniversalReps of the individual lines and get a UniversalRep for the whole Expr, and also that individual lines should consist of one or

In general, a "one to many" mapping takes place when we stuff a CaminoReal Object into a Tioga document. The Object is mapped to a sequence of Tioga characters with appropriate artwork. We get from Tioga a description of the boxes/strips into which we are supposed to lay out this sequence of characters, and a sort of negotiation process goes on to do the actual layout. The FromTioga mechanism expects a sequence of characters, and it concatenates their String values and hands the result to the parser to create a single Expr.

In general, we want to think of a DisplayProc as an evaluator, which produces hopefully context-independent bitmaps, or IP fragments.

3. For the future: CaminoReal maintains a Page (layer of a Chameleon doc)

In general, a CR tool maintains an infinite plane (page) of paper, and can have multiple things laid out on it. This will enable it to gracefully become a layer of a Chameleon world. We have a mathematical constructor called Page, whose args are disjoint pairs consisting of (box, Expr). Some of the methods for Page are Scale and Rotate. A Page can be evaluated to produce (box, Bitmap) pairs; each BitMap is obtained by applying Display proc to Expr subject to constraint of supplied box.

Pages are fairly flat, that is only have one level of depth. Selecting the desired Expr on a Page for stuffing to Tioga now becomes trickier. Sibling motion will now be a standard tool for moving around among the different Exprs on a Page. Need the ability to split a CR viewer so that we can have multiple windows on the same page.

This page notion will make it easy to do spreadsheets: you lay out your page into a 2d array of boxes, and then use the levels and environment mechanism to establish relationships among boxes.

4. Interface with Tioga

We assume for the time being that we will continue to use Tioga character artwork.

There is the general question of how Tioga deals with boxes. For example, does Tioga allow for the possibility that the rendering of a single character may span multiple lines, or multiple pages. Let us assume not. So we will do each line of a multiline expression as an individual character (this is consistent with the elsewhere mentioned constraint that individual lines of a multiline expr should be selectable expressions). The design goal is that

Each time we render a particular character, we would like to first ask Tioga where we are in the current line, and what size box or boxes it would like us to fit an expression in. This query can have several flavors: What box the expression MUST be fit into, e.g. it must fit inline, and on the current line only.

Sample properties for an expression in a TiogaDoc: IPFragment, EditorRep, UniversalRep. The UniversalRep is the one that we presume to be newly computed as we evaluate the levels of a document from top to bottom; by converting this to EditorRep and then to IPFragment, we generate what we display.

Perhaps we don't store EditorRep in the document. We assume we're willing to wait for the conversions UniversalRep -> EditorRep, and EditorRep -> UniversalRep -> IPFragment whenever we edit an expr in the document. Also this way we aren't committing ourselves to any particular editor rep or editor: all editors are presumed to be able to transact in UniversalReps.

1. Interface with Viewers

Why can't I drag icons around in blank areas on the display, or scale and rotate them? Presumably ansewer is that Viewers doesn't have an Imager type of view of the screen. Note that Whiteboards, at least, lets me move icons around inside an area that I control.

SIG/CaminoReal to do.

0. Implement polynomials, quotient constructor.

0. The universal mathematics representation language: should offer standard data structuring paradigms, e.g. there should be a standard prescription for the external representation of a mathematical type that consists of a point of other types, in terms of the external representations of those types. Thus we might do general algebraic points of size 2 as (POINT 2 (ALGEBRAICNUMBERFIELDELEMENT ...) (ALGEBRAICNUMBERFIELDELEMENT ...) ), and perhaps have a special constructor for primitive algebraic points of size 2: (PRIMITIVEALGEBRAICPOINT 2 (ALGEBRAICNUMBER ... ) (POLYNOMIAL ...) (POLYNOMIAL ...) ).

Perhaps should be TeX macros as Dan suggested. This would eliminate the need for human readability. General point: all SAC-2 programs should write output in this language. This should be the linear representation attached to Tioga artwork characters.

0. New Meddle constructors needed for algebraic number, points, sequences, records. These will be variations of vector/matrix constructors. We need general n-ary constructors, so e.g. I input a polynomial by specifying variables, and how many terms. Note that I should be able to easily delete variables from the monomial templates that I'll get. This means a general ability to delete components of an n-ary op.

1. Announce SIG in TUG, SIGSAM bulletin

2. Implement definition expression, value expression, environment maintenance, "eval in the current environment"; notion of "computed document". Provides for automated proofreading. perhaps allow attachment of assertions that are checked when "eval in the current environment" is done (presumably first we evaluate the definition expression, assign it to a temporary ("current expression"), and can express assertions in terms of that temporary.

The point is that existing math typesetting systems make you put in all your equations by hand. This is hard labor.

Example of proofreading: checking for spurious variables in an expression, check for unwanted complex numbers in a large matrix (Real Recast should accept a complex number if its real part is negligbly small).

3. after Perlis: design a complete keyboard language. There is the issue of whether you should see what you type, or whether it is parsed on the fly and set. Either mode should be possible. Output dump of expressions should be in this same language. Thus you should always be able to select a string in it and say "parse and convert to internal form". Build the translator in Casaba.

4. CR -> TeX converter in Casaba.

5. Objects should have ToTioga and FromTioga procs (you tell them where to write in what document; somebody else maintains that). For simple types, they just write the object out as a single character with artwork. For a complicated type, e.g. cad, or samplePOint, these do a sequence of writes of their simpler constituents, using their ToTioga ops. This also can provide the logging mechanism: ViewExprImpl maintains a log document, and every time we do an Operate or Eval, we apply the ToTioga op to the result. Note that this has the effect that the aggregate of constituents of such a result may be multiple artwork characters. Thus the FromTioga button needs to know a domain, and applies that domain's FromTioga proc to the entire current selection. Without a domain, we get a sequence of "tokens", each of which is a CR expression in internal form; we then need procs that can crawl such a sequence and build the appropriate item. Or maybe this is precisely what a FromTioga proc does.

6. We need general Sequence and Record constructors, and the ability to define special constructors, e.g. SamplePoint, Cad, constructors that are just renames of the general procedures, but will cause lookup of the appropriate constructor in the MethodDictionary.

7. Operator precedence knowledge needs to be made explicit, and parentheses automatically inserted where necessary. Should the actual CaminoReal editor be driven by this grammar? Cf. Cornell synthesizer. Perhaps yes, and our model is that any other input modes besides typein in the linear language (e.g. menu selection) are automatically translated into the linear form, and then parsed by the same parser that handles keyboard input.

8. The user interface to an existing algebra system. Simplest model is that we only support function calls to the other system, not programming. This is implemented in the particular types, which implement a function (e.g. factor) by RPC to the remote system. The overall usr interface allows you to examine and alter the global state of the remote system (i.e. the environment) that will be used whenever calls to that system are made.

9. References to the type inferencing problem: Mil78 and other refs in Calmet Sigsam Bull, NYU guy's thesis (R. henry).

1. Basic principles

There are two worlds - the editor world and the algebra world. Or alternatively, the world of form (what you see on your screen or in a fully computed, i.e. rendered, document) and content (mathematical meaning). The primary function of the algebra representation is to serve for computation. Thus you cannot object to things being put in canonical, or other desired internal, form in that world, as is indeed what happens when you Eval an editor representation. However, you should not necessarily be forced to see (the editor representations of the) canonical forms of the expressions you input, nor should the editor representations of the expressions you input necessarily be replaced by the editor representations of their canonical forms. However, if you compute something, it is not unreasonable that the editor representation you get for the result is the editor representation for the canonical or whatever form produced by the algebra system.

Another basic principle is that the overall system is able to convert any editor representation into some algebraic object, i.e. come up with some AlgebraStructures structure for which it can convert the editor representation into (the internal representation of) some element of that structure. At present, it is possible that the resulting algebra object may just be the editor representation itself (i.e. an element of the MeddleExprs AS structure). Thus the point is: the Eval function can do something anything; it isn't necessary, though it is perhaps allowed, to tell it what structure the result should be an element of.

Thus we do not require, and indeed, we actually don't allow, the user to specify the domain to which an expression is to belong.

2. Interface to other algebra systems

There are three styles of interactions with other algebra systems. One is to conduct a session entirely with that other system. The only role of CaminoReal here is only to make a CaminoReal-format log of the session, i.e. each command and each output line are displayed both in the window for the session with the other system, and a CaminoReal format version of it in a CaminoReal history log document. The intended purpose here is when you want to do all computation with the other system, and you just want to be able to put the expressions you create into a Tioga document.

Second style is where the only functionality, and hence all algorithms, available are those of the other system, but the user interaction paradigm is that of CaminoReal. Thus you can select subexpressions of prior expressions as operands to future commands. You get a CaminoReal-style session log. The way it is implemented is that menu generators only put up commands from that system, or put up the flavor of the command from that system, or if the user requests a command, it is checked that it is available in that system, and the flavor for that system is used.

Third style is the default, eclectic, CaminoReal style. There is a single, cumulative functionality available that incorporates the functionality available from all sources, e.g. AlgebraStructures, other algebra systems. You get an algebra session log that records the algebra you did, i.e. the command lines and the output lines, and it can be played back.

3. General CaminoReal methodology

Computation in CaminoReal means Eval'ing something. There are two paradigms for doing it:

(1) the user has a Meddle Primary Selection in the editor, he bugs "Eval", if WorkingStructure is active then we go to Eval passing it as sourceStructureForMethod, else we go to Eval with sourceStructureForMethod ← NIL. Result placed where user says.

(2) user selects args either in Tioga doc or CR viewers, then bugs "Operator" button. If WorkingStructure is active, then we offer its Operators, else we Eval the selected firstArg and offer the methods of its Structure. Then we lookup the method, do an AssocList type of replacement of the selected args into the Expr, and pass it to Eval with whatever sourceStructureForMethod is appropriate. Result placed where user says.

In either of the above cases where sourceStructureForMethod is nonNIL, what we log is the CompoundEXPR:

EvalWithSpecifiedStructure(aStructureToExpr(Structure), Quote(Expr) );

to which we can just apply Eval. There is a Structure SpecialMethods, which has as its methods EvalWithSpecifiedStructure, Quote, and SystemListStructureLUB, and SystemListOfListStructureLUB (latter two use the full knowledge base). The Structure Constructors of all other structures are available as methods in them (recall, of course, that these check the StructureRegistry before actually generating a new Structure), so when Eval is asked to evaluate an Expr whose value should be a Structure, its usual lookup will find the necessary Structure Constructors. Thus Eval of the EvalWithSpecifiedStructure method first causes evaluation of its two args, then a call to Eval with sourceStructureForMethod ← Eval(Structure), applied to (unEval'd) Expr.

We can do (2) for the time being by requiring the user to create the expression and Eval it, i.e. path (1).

First logging can just be accomplished by just logging the Expr (with CaminoRealCommand property) and dropping the sourceStructureForMethod if any on the floor.

Arg selection could be offered both for editing and computation. E.g. instead of creating a sum editor Expr by wrapping/replacing and filling in the placeholders, you could select args, bug "Method", and get an editor Expr. You could have a mode that says "I just want to build editor exprs" or "Eval everything I create". Would couple nicely with the idea that if a WorkingStructure is active, you only put Constructor and Operator menus that make sense for that Structure.

[For the future: any Operator invokable a OperatorName(arg1, arg2) type of expression, in which this is a $function (args) type of template with OperatorName as the user-entered function name.]

Thus domain names are Exprs like any other, and the whole process of creating domains takes place in the editor, just as for any other sorts of math expressions.

For the time being at least, we don't store AS objects, or AS structures, with Exprs. Every time you want to do a computation (i.e. an Eval), all (recursively) Exprs have to be Eval'd from scratch.

4. Constructors, Operators, Methods

An Operator or Constructor is the syntax, the method that implements it is the semantics, for some functionality. The Meddle Atom or Operator class name is identical with the AS Method name.

Basic groupings should not be atom, expr, vector, matrix, but rather "Constructor" (integer, real, complex, vector, matrix) and "Operator" menus (there should also be "GroundStructure" and "ConstructedStructure" menus of Structure builders). Thus we do not think of vector and matrix as operators, and it is not possible to wrap with them. It is possible to both replace and wrap with all Operators.

A refinement of this: if a WorkingStructure is active, you only put Constructor and Operator menus that make sense for that Structure.

Ideally there should be a single knowledge base used by both the Editor and the Algebra Routines. The point is that CaminoReal should know about some collection of things, and for each such thing, it should know about both formatting and algebra of it.

Actually there should always be two independent knowledge bases - one for operators, and that for AS Structures. All that really matters is that you should be sure that for every method in every Structure, for which you want some special notation, other than method(args), you should have an entry for it in the operators knowledge base.

5. Eval

5. Relationship of Evaluation and Editing

Given an AlgebraStructures Object, ToExpr followed by Eval should give you the same object back, except it may be represented as an element of a different (presumably simpler) AlgebraStructures Structure. However, given an Expr, Eval followed by ToExpr gives you the (DisplayExpr(ToExpr) of the) AlgebraStructures canonical form of the original DisplayExpr, which may be quite different from the original DisplayExpr.

Eval works as follows. The input can be thought of as of the form MethodName(... args .... ) First, Eval checks to see if Expr is of type Atom. If so, then looks up method (in sourceStructureForMethod first if nonNIL, then in all Structures), applies it, and returns. If not, then calls itself recursively on the args to get a list of Eval'd args. looks to see if the outermost method is special, i.e. comes from a button, e.g. EVAL; if so, it returns the result of the recursive call on arg. Then if not yet returned, looks at structureInWhichToLookForMethod; if nonNIL, tries to get specified method from that structure's method dictionary. If found, then applies it, and if the application succeeds (i.e. args can be recast), then returns. If structureInWhichToLookForMethod is NIL, or if there is no such method in the nonNIL structureInWhichToLookForMethod, or if the method was found in nonNIL structureInWhichToLookForMethod but its application failed, then goes through the Eval'd args in left to right order, and for ech, tries to get the requested method from its structure. Whenever the method is found, applies it, and if the application succeeds, then returns. If we still haven't returned, then returns an element of the AS Structure Exprs, of the form MethodName(... Expr's for Eval'd args ...).

Eval applied to (INT a) a returns an element of the AlgebraStructures structure Ints.

Eval applied to MATRIX( (INT a), (INT b), (INT c), (INT d) ) returns an element of the AlgebraStructures structure M2,2(Ints). The point is that Eval of a "constructor" like "MATRIX" builds an element of some structure, while Eval applied to a method of some structure, e.g. SUM, returns an element of that structure. Thus where appropriate, Meddle constructors should be available in a corresponding AlgebraStructures structure as methods.

Eval has access to a sophisticated facility for "merging" domains, e.g. Z[x] and Q[y] -> Q[x, y], Q[x] and M4(C) -> M4(C[x]).

6. Operating: Argument selection and result destination

Args are selectable anywhere, i.e. in Tioga documents or CR viewers. Selections in their proper order are highlighted with different colors. Result selection mode (in TiogaDoc after current selection, in TiogaDoc at end, in new CR tool, replace first selection, etc.) is menu set.

A CaminoReal viewer has buttons that say: PrimarySelect, CopySelect, MoveSelect the entire DisplayExpr of this viewer.

Need to resolve selection inconsistencies in naming and display between CR and Tioga.

7. Recast procs

A recast proc branches to appropriate code to convert elements of that structure, or if there is no such branch, returns the arg, plus a flag/signal that it couldn't recast it into this structure. Thus a recast proc doesn't necessarily create a new Object.

The recast proc for Exprs as an AS Structure is easy - just applies the ToExpr for input Structure to input. Another note on Exprs as an Algebrastructures Structure: its ToExpr op is a noop.

Explicit recasting can be accomplished by bugging "OperateWorkingStructure", and selecting recast method.

8. Categories

The Scratchpad notion of category translates into a particular sort of class record in CaminoReal. By "particular sort" we mean both the slots that it has, and properties associated with them, e.g. that multiplication is commutative.

Perhaps object flavors could be two-part, so that objects of flavor Class could be further distinguished by a Category subflavor.

8. WorkingStructure

This is an global variable.

Building Structures works just like expression menu, excepts uses special operators, e.g. available atoms are ground domains ("GroundStructure" menu) , available templates are domain structuring ops ("ConstructedStructure" menu).

When built, we bug "SetWorkingStructure". Then we display it in a text viewer via its ToRope method.

10. CaminoReal algebra session logs = history docs

The log is a series of two-part entries of the following form: expression (has Command property), and Eval[expression].

A playback functionality is provided: you select a file, the characters are read through one by one, and each one that has the CaminoRealCommand property is placed into the history log as a CaminoRealCommand, Eval'd afresh, and the result written in to the history log (without CaminoRealCommand property).

Thus ordinary text, e.g. comments, can be added to logs.

11. Interpreter and programming language capabilities for CaminoReal

Currently, command operands must be provided as (Tioga or CaminoReal) selections. This is one consequence of the fact that CaminoReal currently has no "state" or "memory". There is no ability to save the results of previous operations somewhere and pass them as operands to future commands, other than by selecting them in the history document. i.e. there is no "stack". There is no user-level facility for writing "programs" that can be interpreted on the fly.

In general, want to achieve Schelter's Lisp/macsyma style of doing algebra. I.e. interaction with an interpreter, in the context of some current environment. At any time you can load a new function definition into the environment. Question of how this compares with/is achievable with Cedar's "load state" paradigm, plus statement interpreter.

12. Meddle Implementation: Atomic, Compound, and Matrix Expression types

Atomics are a Type and a Value. Compounds have a operator and a fixed number of arguments. Matrices are a type, a 2dimensional specification of number of args, and the args. Matrix type can be used for any n-ary kind of construct, e.g. n-ary sum or product, Record, Sequence, Multiset, etc.

12. Meddle Implementation

We think of a class of Exprs as being defined by an operator, e.g. PLUS. Thus this class of expressions is the set of all sums. Carl says an expression class is an operator; e.g. product, integration.

Note that the data base pertains to Exprs. Roughly speaking, the DisplayExprs are Exprs which also have relativeBox and absoluteBox with them, and have parent pointers.

The question is: when do Exprs live? Seems that in order to render them, we have to convert them to DisplayExprs. Basically seems that they live when we need to look up the nature of an op class in the database; then we immediately convert them to DisplayExprs to be able to render them.

General point: we have a ROPE representation for Exprs, not for DisplayExprs. Thus there seems to be the philosophy - when we represent something externally, we don't try to save formatting information with it.

However, it is DisplayExprs that we convert to ASRopes.

There appear to be two main differences between DisplayExprs and Exprs:

(1) DisplayExprs are mutable, i.e. you can go in and change a substructure of a DisplayExpr. Thus, when you have a pointer to a DisplayExprRep, some recursive part of the expression may change "without you're knowing". This is why you need the parent pointers in DisplayExpr rep.

(2) Only DisplayExprs can be formatted and painted.

However both DisplayExprs and Exprs directly use the Expression classes database, i.e. both Exprs and DisplayObj's have a class: MathExpr.Class field.

MathTypes.FormatClass is: a classification of user-defined operationsinto categories such as binaryOp and matrix, for use by formatting procedures. Currently:

FormatClass: TYPE ~

{atom, paren, binaryOp, unaryOp, op, relation, over, matrix, radical, other};

Apparently a characteristic feature of Compound expression classes is having a fixed number of arguments, and for this reason, vectors and matrices could not be done as Compound expressions.

1. New things 3/11

Why do we get — "meddleexpr.style could not be loaded" message, followed by "style was bad .meddleexpr" when we open CaminoRealDoc?

Mimic Tioga move, delete behavior.

Have formatting rules accessible to the user, so he can change like a user profile (i.e. ideally, don't have to recompile system after a change.) Along with this should be ability to add new notation.

Maybe should be able to read TeX specifications of formatting rules, in general, read in TeX input and do something sensible with it.

There are lots of standard modes for indentation, centering of math expressions (recall that EQN offers some). These should be available as commands or mode settings in the WYSIWYG user interface.

The general question is - what should the user interface for a WYSIWYG typesetting system be? Look at Forms.df for instances of typesetting.

For example, what entities/units should be draggable in a WYSIWYG typesetting system? E.g. perhaps within a block of text which is designated to be "filled lines", dragging should not be permitted.

1. New things 3/23

Need to be able copy matrices, or blocks therof, to be blocks of other matrices. This seems to get to something like Genesereth's circling mechanism (referenced in Foster), i.e. the idea that you should be able to draw a circle around anything and make sense out of it.

1. General Ramblings

High precision typesetting vs. getting your day-to-day work done

Rick's ideas are in MathComposition.DF, /cyan/tioga/top/tabletool.df

Hard questions: Fateman thinks a possible problem with the scheme we propose is - how do you get control over the fine details of how the expression will be displayed in a document, i.e. the Interpress fragment, if you edit it with an EXED -like editor? For example, how would you specify the insertion of a half em space between two characters? Apparently the problem he sees is that if you have such information in an expression, and then you edit it, what are default rules for what happens to it, or perhaps, how can you avoid it being either lost or rendered meaningless?

One facility is the ability to specify expressions as programs, and have expressions dependent on others, This might require invoking an algebra system to evaluate the expressions when a document is to be run off. This raises the general problem of how to know when evaluating an expression may invoke a huge algebra computation - meanwhile the user is wondering why his document isn't coming out. In general, seems that we want to be able to only reeavaluate expressions when necessary, i.e. after changes.

Another thing one can consider is a "document-like" approach to using an algebra system, i.e. automatic history mechanism of a more sophisticated, attractive, and useful kind. A simple version of this would be to have your session with the algebra system automatically logged as a formatted document. Note that the boundary between this paradigm, and the model in which you are writing a document but can invoke an algebra system when you want to, is fuzzy.

Languages for computer algebra and object-oriented programming

Previous domain work in computer algebra (Scratchpad etc.) is not sufficiently inclusive for our situation. For us, a domain means:

1. A collection of mathematical objects, the elements of the domain.

2. One or more internal representations for elements of the domain, in terms of internal representations of existing domains (unless the new domain is primitive). One of these representations may be a "dump" format that will travel with the expr in a document or database.

3. A collection of operations on those objects.

4. Algorithms that implement some or all of the operatios

5. Textual (linear) display rules for elements and operations of the domain.

6. Two-dimensional display rules for elements and operations of the domain

7. Editing "vigilance" when this domain is in effect.

We enforce the domain paradigm whether we're using the resident or a remote algebra system. In other words, a methodology for doing computer algebra is built into our tool, i.e. is part of its semantics.

Our point of view is that all actions take place within some domain, and if that domain is anything other than general expressions, the user must know what it is and specify it.

The default is to do natural conversions, e.g. imbed integer as rat, rat as algebraic.

Macsyma, Reduce are allowable domains. Selecting one of these domains means that the input is assumed to be legal Macsymese or Reducese.

Is it the case that all computer algebra, e.g. anything you can do with Macsyma, takes place in some domain (the domain of "general expressions" seems a copout)? If so, then perhaps reasonable to claim that every simplification algorithm works over some domain. Once things can always be thought of as taking place in some domain, perhaps there really is no difference between evaluation and simplification. Somehow the intuition is that evaluation really does some computation, whereas simplification is just cleanup, bookkeeping.

Does the idea of a standard language for expression of algebraic algorithms make sense in a world where some systems enforce domains and others don't?

Domains, expressions, and the semantics of evaluation

There are two modes of doing operations. One is - I have a fully simplified object(s) in the current domain, a menu of available operations, and I say - apply this op to this (these) object(s). "Fully simplified object" means - All ops have been applied, and the display expression for the object is, as much as possible, a canonical form. Second mode is - I have built up an expression which can be simplified to an object in the current domain, but has not yet been simplified, i.e. it contains "unapplied" operators. Examples - determinant, integral. I then say - eval, or simplify, it. The display expression for the final object is not necessarily different than the expression we start with, for example, if an indefinite integral does not exist in the current domain, or if we try to simplify a polynomial which is already in canonical form.

The second mode encompasses a functionality we want to support, namely input of polynomials in factored or otherwise uncanonical form. Perhaps the point is that an evaluator/simplifier, rather than a direct parser, should be applied whenever we say we want to imbed the current expression in the current domain (SetObject button).

So the point is that the educated user of CaminoReal must be aware of simplification. That is, when you bug the SetObject button, the display expression of the resulting object will be a simplified, as much as possible canonical, form. A simple example of this is monomial reordering for polynomials.

2. CaminoReal: a WYSIWYG system for technical documents

Expression editor improvements

CNTRL-E (CedarAbbreviations) facility from keyboard.

Serve spectrum from technical typist to physicist and mathematician. Very few people want to know about groups, rings, fields, maybe a few more want to know that domain is matrices of polys with complex coeffs. Should provide for secretaries enforcement/templates of subscript types to avoid typos.

Linebreaking (i.e. pretty printing) display option

A good linebreaking paradigm can be used equally well for putting the expression in a document, or as an alternative way to display it in a Camino window for the Camino user.

Perhaps broken exprs in docs can have a PrettyPrinted, or Broken, property.

Ergonomics of large expressions

This is an old research issue in computer algebra, it's now reborn in the era of bit-mapped screens, window systems, mice, WYSIWYG 2D expression editors.

Level clipping, or better, close up levels and show an icon. Run Magnifier over large expression. Fisheye views (George Furnas); one way to do: show a sphere in 3d world, and use ThreeDWorld's ability to map text onto an object to map the expr onto the surface of the sphere, in such a way that one little of the expr is more in focus than the rest. Then give the user the ability to move this focal point around. Alison Lee: space invader icons with the ability to stop at a point of interest for dynamic browsing (a fast forward button). Rick Beach's use of "thumbnails" of ip images in the Interpress samples whiteboard.

One issue is a good interface for entering expressions. May not be the same for all users, e.g. the nonmathematical typist entering a large expression may have a different mental model of it, i.e. may grok it differently, from the scientist who wrote it who sees patterns and structure in it.

LIfe with an expression editor used only by human typists, e.g. as is typical in TeX, is very different from life when you start piping computer algebra system output to the editor's display routine. The editor will have to do something, you hope good, with the potentially enormous expressions that may get generated with the algebra system.

Expression laid out on an infinite plane is not the only way, maybe not even the best. But even assuming that, for all sizes of expression there is the issue of what interface should be provided for browsing it, e.g. to edit it. Something specific to the system's particular tree representation for it may not necessarily be good, since even if the user knows there is a tree representation for it, the particular trees the user may think of may not correspond to the system's tree, so the user will be frustrated trying to move around. A user interface based on a tree-browsing paradigm even seems questionable, since it seems clear that for many expressions, e.g. polynomials, the user is likely to think of them in a linear, left-to-right fashion, so a tree-based interface isn't going to match the user's model.

Offer linear printout, e.g. the AlgebraStructures linear rep, as a display option.

Naming mechanisms

Perhaps only really applies to objects that we want to use as operands to further computations, but one could imagine also ability to give a name to the editor and have it evaluate to an expression that could then become part of some other expression.

User interface for expressions to/from Tioga docs

Revision of Meddle internal rep - should contain, separately, the mathematical content of the expr, domain info, and formatting info. All stored with an expression put in a doc, and recursively, in some sensible way, for subexpressions. This may require revision of AlgebraStructures reps, e.g. the exponent of a variable in a polynomial should be selectable, and should carry full content, domain, and formatting info.

Put Tioga level structure on an expression in a doc. Cf. Peanut.

Anything to be learned/lifted from TiogaImager?

1/22/87 - You should be able to come along in a doc, and say - oh, give that text the look of an equation. This could mean anything from just setting it in italic, to parsing it as a more complex expression.

2/8/87 - Perhaps need a math mode for typing, so that keys automatically give you italic characters and special characters are special keys.

Camino Viewer glitches.

Defaultly scale Camino viewer to be just tall enough to hold expression in it, and automatic legible positioning of expr in new viewer (i.e. home the result of an operation). Fix erroneous persistence of old stuff when viewer repainted.

Dealing with low screen resolution

perhaps really the same issue as large expressions

The problem that equations mixed with text, and at the same point size, are too small to see.

Subhana 2/8/87 - do font tuning, find a best point size to optimize the resolution you get from your screen fonts. Talk to Debra Adams.

Faster repainting

Store interpress fragment with a MeddleExpr node?

Incremental repaint algorithm?

Jules 1/14/87 - have a "Artwork SuggestedOn", by which in Tioga, you suppress painting artwork when scrolling if that's necessary for speed. In any event, when document isn't moving, a background process comes along and repaints all artwork that should be (interrupted if scrolling occurs).

Viewers into docs (Fournier)

Have an interactive viewer tool in the document when it comes up on the screen. Some rule for painting that space when you print the doc. Maybe could be done hacking artwork nodes.

This would enable selection of subexpressions, editing in place in a Tioga document.

Subhana 2/8/87 - something like this is already done with voice annotation of Tioga documents?

Programmable documents

E.g. an expression can be specified as the derivative of some previous expression.

Randy Frank's example: an expression is a self-contained program, e.g. you set A and B to something, then render SQRT(A^2 + B^2 + A + B).

Schelter - when you have such computed expressions, you don't want to recompute them everytime you run off the document, only when necessary. This should perhaps be managed by "version control" among the expressions in a doc, so that if you change an expr that another expr is computed from, that other expr will recompute itself next time you repaint the screen or run off the doc. Or if the computations are long, perhaps you want it to recompute itself in background with a slackprocess.

Section numbering tools

What section numbering tools does one want in WYSIWIG editor? Presumably there should be a property on the node that says - number it.

Same question for Bibliography facilities, enumeration, etc.

Integration with other Document Management tools

Whiteboards?

Illustrators: Scenario - determination of constructibility of regular polygons by factoring primitive polynomial, exact construction where possible. Scenario: Chou's program for drawing the figure corresponding to a geometry assertion.

3D graphics: do the algebra for, display blending surfaces.

Do examples of equations in Gargoyle pictures

EditTool interface

Replace EditTool with popup menus.

Tioga -> TeX conversion

Our general point of view is that WYSIWYG editing is not appropriate for fine tuning of formatting, but very appropriate while the document is evolving. Thus nice to be able to go to TeX.

Do it eventually so e.g. one can transmit a technical doc created with Tioga to another site. Note that having DVI -> IP would enable an emulation of the EXPRES Diamond -> TeX -> Postscript pipeline with a Tioga -> TeX -> Interpress pipeline.

TeX is great for the final beautiful output, but not for the document evolution, daytoday working process.

What we want is an automatic converter Tioga -> TeX; then you can tweak the resulting TeX source to get what you want.

We'd also like to provide TeX -> Tioga conversion, so you can receive a TeX doc from your colleague and work on it in CaminoReal.

Also nice might be TeX nodes in a Tioga document, just like we now have Meddle nodes.

3. Plotting.

Generalities

One goal is : whenever you have an expression that it makes sense to plot, you should be able to do so by just punching a button, maybe setting some plotting parameters.

We deal in abstract, symbolic, exact mathematical objects. Approximations to them, covering set files, pictures of them, are all approximations to the abstract entity.

Thus anything to be plotted must be an abstract object belonging to some mathematical domain. "Plot" is a method which an object may have.

Plotting contexts are objects; come in 2D and 3D flavors. In CaminoReal, a plotting context is instantiated as a Viewer.

4. General algebra access improvements

Distributed computation

Use of the Summoner. This is actually a gateway to distributed computations in multiple environments eg. through Chat interface to Vax.

Issue is what alternatives for use of distributed computing facilities are to be provided? Can a distributed computation, including specification for partitioning, i.e. "parallelization", of an algorithm, be invoked on the fly, or does the client have to sit down and specify a fixed partitioning of the algorithm in advance?

What should it be? The FutureValue construct (Schelter ref to Halstead@MIT). Should mesh with chatting to remote algebra systems.

Sample problem to try: determinant expansion by minors.

User interface re: lightweight and heavyweight computations

When a user forks a remote computation, maybe should specify whether he wants to wait for it. If not, has to specify what it should do. E.g. if I fork a ray tracing, what is it supposed to do?

History mechanism, referring to previous objects/expressions (naming mechanisms)

Scrollable history document?

Need ability to refer to name objects and/or expressions, and refer to them in future objects/expressions by name.

what do "modern" systems like Iris and Views offer?

Programming Language issues, interface to other algebra systems

Fateman says he wants at least ability to enter commands from keyboard. Doable with Cedar interpreter?

Soiffer's idea of Reduce parser inside the interface.

Access to remote computational resources

Managing suites of Vax software from Cedar

Matching directory structures, edit with Tioga, RemoteCompile and SystemBuild commands. Thus we never have to think about what is actually happening on the Vax.

Extension of DF file mechanism to verify that things built successfully on Vax, i.e. that software there is in a good state.

Unix Contributed Software standards for package maintenance?

General issues

What are you to be allowed to do on the remote system? Pass programs? Interrupts?

SAC-2 on Vax

Listing of some supported commands (e.g. DoCad, FactorPolynomial) in SAC-2 and how you access them.

Facility for writing, compiling, running an Aldes/SAC-2 program under CaminoReal.

Standard interchange format for files of cad information

Access to Lisp machines at PARC

Can a single paradigm suffice to access Macsyma both on Vax and on Lisp machines?

RPC interface to Reduce in Interlisp. Running Cedar and Lisp in separate partitions on the same Dorado, communication by files (Bobrow). Common microcode project (Bobrow). Remote procedure call. Examples of useful Interlisp facilities are - Notecards, Argnoter, Cognoter. People who have built connections between Cedar and Interlisp: Swinehart (see Yearend report), Russ, Bobrow.

Foster - RPC (Henry Thompson's) takes 100 ms in InterLisp, 10ms in Cedar. (- that's the RPC from one Cedar machine to another? How long does it take for the dictionary server?) In his COLAB work they have the ability to move mouse across different machines.

Foster - There is a FORMAX? layout program in Interlisp, which can be used as part of Tedit.

5. Access to Vaxc

Chat interface to Vaxc algebra systems

Basic facility - I give the command to invoke on the remote machine, the file of data to pass to it, and a filename where the output is supposed to be stored. Execution of the command on the remote command creates a tempfile on there, which is then pupftp'd over to the specified filename in the Cedar system. I also specify in what way, if at all, I want to wait for that computation to complete.

RPC to Vax? How does Chat do it?

Managing suites of Vax software from Cedar

Matching directory structures, edit with Tioga, RemoteCompile and SystemBuild commands. Thus we never have to think about what is actually happening on the Vax.

Extension of DF file mechanism to verify that things built successfully on Vax, i.e. that software there is in a good state.

Unix Contributed Software standards for package maintenance?

General issues

What are you to be allowed to do on the remote system? Pass programs? Interrupts?

SAC-2 on Vax

Listing of some supported commands (e.g. DoCad, FactorPolynomial) in SAC-2 and how you access them.

Facility for writing, compiling, running an Aldes/SAC-2 program under CaminoReal.

6. Access to Xerox Lisp environments

CommonLisp Macsyma

Issues for interoperability with Lisp software

Can a single paradigm suffice to access Macsyma both on Vax and on Lisp machines?

Foster - There is a FORMAX? layout program in Interlisp, which can be used as part of Tedit.

What distributed computing facilities are available in the PARC Interlisp/CommonLisp world? E.g. even if one could marshall lots of DLions to run list, what is available to make them play together?

Initial hardware: Cedar on a DLIon controlling Lisp on a Dorado.

Note: Kyoto CommonLisp + Mesa C compiler => Lisp -> Mesa translation facility?

Engineering/Scientific Workstation Project

Other Lisp software

1. Chou software, G-basis software

2. Expert systems for geometric reasoning, math problem solving, blending numerical and scientific computation, selecting numerical algorithms in a polyalgorithm environment, assigning a domain to an arbitrary math expression (Scott Morrison), authoring.

3. Hook Notecards to Tioga docs?

4. Glisp algebra system, Glisp as database browser?

CommonLoops algebra system?

7. Meddle Implementation

MathTypes

Defines types common to all modules. In the latest version, only two types are

defined: Style (font info) and FormatClass (a classification of user-defined operations

into categories such as binaryOp and matrix for use by formatting procedures).

MathBox

Data abstraction for a BOX. A BOX is an immutable object.

A BOX is the basic building block for formatting expressions.

(Similar to TeX's concept of boxes and glue.)

Provides BOX constructors and selectors.

Provides operations for determining metrics about a box.

Provides some LIST operations for LIST OF BOX.

MathRules

Defines procedure types for formatting, positioning, painting, and data conversion rules.

Defines types associated with alignment, positioning, and sizing.

Provides primitive procedures to align boxes: AlignHorizontal and AlignVertical.

Provides high-level procedures for automated positioning & composition:

Compose and ComposeMatrix.

Provides procedures for computing relative sizes: ComputeSize and VecFromSize.

MathExpr

Data abstraction for a mathematical expression, EXPR. An EXPR is an immutable

object which contains information about its subexpressions and their classes.

Provides EXPR constructors and selectors.

Provides parse/unparse operations for EXPR.

Provides LIST selector operation for LIST OF EXPR.

Also defines class types for atoms, compound exprs, and matrix exprs.

Classes contain information such as name and rules for formatting, painting, etc.

Provides constructors and selectors for these classes.

MathDisplayExpr

Data abstraction for a displayed mathematical expression, DisplayExpr. A DisplayExpr

is a mutable object which is an EXPR mapped to a viewer. It contains mutable

information about absolute box locations, etc.

Provides DisplayExpr constructors and selectors.

Provides conversion routines between EXPR <=> DisplayExpr.

Provides Copy, Format, Paint, Replace, Selection operations.

Provides an unparse operation to AlgebraStrutures/CaminoReal format.

MathConstructors

Defines and registers classes and rules for many common math operations.

Provides high-level constuctors to combine EXPR's using these operations.

This is the right module to look at if you are defining new operations (notations).

MathCommunication

Interface between MEDDLE and CaminoReal.

Provides high-level operations to create a MEDDLE viewer and set/get its contents.

MathToTioga

Interface between MEDDLE and Tioga.

Defines and registers the Tioga CharacterArtwork class $MeddleExpr.

Registers (Commander) command "MeddleArtwork {on|off}" to enable/disable this feature.

MakeMeddleViewer

Defines and registers (Commander) command "MeddleOpen {name}" to open a

new MEDDLE viewer from the CommandTool.

ViewExpr

This is the core of the MEDDLE user interface.

Defines and registers a new viewer class, $expr.

Parses keyboard and mouse events.

Handles menu events.

Handles copy/move/select events.

Handles all viewer trivia like PaintProc, NotifyProc, bi-scroller stuff, etc.

Provides high-level operations to create a MEDDLE viewer and set/get its contents.

ViewExprOps

Provides procedural abstractions called by ViewExpr to deal with selections and

paint "queue" operations.

8. MEDDLE Ideas for Future Research and Development

1. Specifying New Notation

Problem: Specifying new notation is difficult and tedious.

I believe the major underlying problem is that it is hard to imagine, specify, and verify generic rules which work in all situations. I think that instead of attempting to create bullet-proof all-purpose rules, it may be much better to facilitate the classification and specification of exceptions. I believe a class hierarchy with inheritance is one interesting way to approach this problem.

Each expression class (i.e. operator; e.g. product, integration) would be placed in a hierarchy which contains all expression classes. A subclass should inherit information from its superclass, yet be allowed to differ somewhat from it. (Sound like Smalltalk?) For example, class product may have binaryOp as its superclass. A product is indeed a binary operation, but in some (most) cases the operator is implied. Thus for formatting purposes, a product would behave much like all binaryOps, yet it would exhibit some subclass-specific behavior. The construction of such a class hierarchy in a reasonable way seems to be a non-trivial problem. Once most common notations have been specified, however, it should be relatively painless to subclass expression types which are similar.

Furthermore, each argument in each expression class should be required to have a set of constraints which express sizing and positioning information for every possible expression class that may appear as that argument. For example, in a summation, each argument in (summand lowerlimit upperlimit) must have constraints specifying what happens when the expression type of that argument is each of (sum, product, summand, integration, fraction, etc.). The obvious problem with this scheme is that the number of sets of constraints grows faster than n^2 in the number of expression classes, which is simply ridiculous. However, if you think of the expression class hierarchy as a tree, each argument in (summand lowerlimit upperlimit) only needs enough sets of contraints to "cover" the entire tree. Suppose, for example, that it was necessary for the lowerlimit argument to have special formatting behavior for relations (like =, >, <, etc.) and products. Then only three constraints would need to be specified -- one for the root class "op", one for class "relation", and one for class "product". In fact, if these constraints were mostly similar except for a few details, then inheritance could be used to make specification even easier - the "product" specification could inherit those constraints from "op" which weren't locally overridden by "product"-specific constraints. (I realize my examples here are horrible, but I hope the point is still clear.)

Another problem is that it is not only necessary to know which class of expression appears for each argument, it is also necessary to know quite a few other metrics, such as the size and maybe the "complexity" of the expression. Perhaps these could be handled in a similar hierarchical fashion; I don't know what the best approach would be (seems like a reasonably good research topic).

In the beginning of this section I mentioned that it was also difficult (and tedious) to imagine and verify sets of constraints. I believe that an interactive graphics-oriented constraint specification tool would greatly reduce these difficulties. The tool should allow the user defining a new set of constraints to display sample expressions using his constraints as they evolve. Perhaps a library of both "common" and known "hard to deal with" expressions could be maintained and the tool could allow the user to quickly browse through many sample expressions using these expressions as arguments to the notation being defined. This would certainly make creating and maintaining a library of notation much more enjoyable and reliable than a non-interactive or non-graphical constraint specification system.

Overall, I believe that the problem of specifying notation is one of the most important issues in the design and implementation of a math expression editor. MEDDLE's simplistic approach works adequately in many cases, but as the number of expression classes increased, rules became increasingly difficult to specify correctly. It is also true that the kind of constraint specification system described here is probably beyond the scope of a typical summer project.

2. Expression Classes with Dynamic Numbers of Arguments

Most of the expression classes that MEDDLE handles have a static number of arguments, and those with a dynamic number of arguments are treated as special cases (e.g. matrices and vectors). A more satisfactory method of specifying constraints for expression classes with dynamic numbers of arguments is necessary. For example, a flexible system should allow the specification of n-ary operations (something that is unsupported by MEDDLE) with relative ease. (User interface considerations for entering n-ary ops are yet another consideration).

3. Iconification

A feature which was planned for MEDDLE but never implemented was a facility for "iconifying" large expressions. Iconification would allow the user to abstract away certain subexpressions to enable a better understanding of the overall structure of an expression. For example, an expression with several huge terms would be difficult to get a feel for using only the bi-scrollers and scaling operations which are available in MEDDLE. Iconification should not be very difficult to implement or add to the existing system. One possible implementation would be to simply set a flag in each DisplayExpr subexpression which was to be iconified. Then MathDisplayExpr.Format[] and MathDisplayExpr.Paint[] could be modified to format and paint icons. Perhaps a more interesting question deals with how icons should be presented (e.g. should expressions iconify to expression identifiers like "S1" or "Expr7", or should they convey some sense of the iconified expression, like a tiny integral sign, etc.).

4. Sizing & Style Issues

Due to limited screen resolution, TeX fonts must be magnified to an undesireably large size before they become readable on a Dorado. It should be possible to develop some scheme which would allow the substitution of different, lower-resolution fonts (e.g. Tioga fonts) for the high-quality TeX fonts depending on the resolution of the display device and the desired point size to be used. Doing this is a general way may prove difficult due to the large number of unusual and fancy characters in TeX fonts.

Similarly, supporting styles such as boldface, italics, etc. in a general way would be difficult due to the unusual variety of characters in the TeX fonts.

Maybe the TeX fonts could be hand-tuned as bitmap fonts for a few different small point sizes. The impact of any solution on the goal of WYSIWYG editing must be considered.

5. Instance-Specific Behavior

Even with a wonderful constraint specification system, there will inevitably be times when the user will want to manually "fine-tune" the appearance of a particular expression. This "tweaking" of specific expression instances should be supported.

6. Automatic Parentheses Generation

It is possible to determine when parentheses are required to make an expression such as a + b * c unambiguous. In MEDDLE, since all expression are actually constructed in a syntax-directed prefix manner, there is no ambiguity in the meaning of an expression. However, the displayed form of the internal expressions "a + b * c" and "(a + b) * c" are identical unless the user explicitly adds a set of parentheses. This is clearly undesireable. A scheme which assigned each expression class a precedence and associativity information could be used to effectively solve this problem. I began to implement such a scheme in MEDDLE (fairly successfully) but needed to devote time to other parts of the system which were deemed more critical. The implementation should not be too difficult. If the more powerful constraint specification idea is used (point #1) then perhaps associativity and precedence could also be inherited from superclasses...

7. Misc. Ideas

Other features that would be nice to add to a system such as MEDDLE include incremental repainting (only re-painting what is necessary instead of repainting the entire Imager context) and an interactive way to specify the number of "size levels" (e.g. MEDDLE has four fixed size levels: normal, big, script, and scriptscript) to use, probably with minimum and maximum values.

References

[AND83]
R. A{\small NDERSON}, {\sl EXED: A prototype user interface for algebraic manipulation systems}, Stanford University, MS., October 1983.

[COW78]
R. C{\small OWAN AND} M. G{\small RISS}, {\sl Towards an algebra system based on pattern matching}, Report UCP-67, University of Utah, Oct. 1978.

[FIT82]
J. F{\small ITCH AND} J. P{\small ADGETT}, {\sl A pure and really simple initial functional algebraic language}, Mathematics Unit, University of Bath, December 1982.

[FOS84a]
G. F{\small OSTER}, {\sl User interface considerations for algebraic manipulation systems}, Report No. UCB/CSD 84/192, EECS Dept., U.C. Berkeley, April 1984.

[FOS84b]
G. F{\small OSTER}, {\sl DREAMS: Display REpresentation for Algebraic Manipulation Systems}, Report No. UCB/CSD 84/193, EECS Dept., U.C. Berkeley, June 1984.

[HEA80]
A. H{\small EARN}, {\sl The personal algebra machine}, Proc. IFIP '80, North-Holland, Amsterdam, 1980, pp. 620-628.

[JEN78]
R. J{\small ENKS}, {\sl Towards a language for use and implementation of algebra systems}, Report UCP-64, Symbolic Computation Group, Comp. Sci. Dept., Univ. of Utah, April 1978, 20pp.

[JEN80]
R. J{\small ENKS}, {\sl MODLISP: A preliminary design}, Report RC8073, Math. Science Dept., IBM TJ Watson Research Center, Jan 18, 1980.

[JEN81]
R. J{\small ENKS}, {\sl A language for computational algebra}, Report RC8930, Math. Science Dept., IBM TJ Watson Research Center, July 14, 1981.

[MAR80]
J. M{\small ARTI}, {\sl Compilation techniques for a control-flow LISP system}, Proceedings of the LISP '80 Conference, 203-207.

[MAF82]
J. M{\small ARTI AND} J. F{\small ITCH}, {\sl The Bath Concurrent Lisp Machine}, Mathematics Unit, University of Bath, December 1982; Also Proc. EUROCAL '83?

[MAR82]
J. M{\small ARTI}, {\sl Interprocess comuunication in the Bath Multiple 68000}, Mathematics Unit, University of Bath, December 1982.

[PAD82]
J. P{\small ADGETT AND} J. F{\small ITCH}, {\sl A new model for dynamic access environments}, Mathematics Unit, University of Bath, December 1982.

[SOI??]
N. S{\small OIFFER}, {\sl A perplexed user's guide to Andante}, MS. U.C. Berkeley.

[WAT85]
S. W{\small ATT}, {\sl Parallel algorithms for computer algebra}, Ph.D., University of Waterloo, 1984.