CoCoA:CoCoA5Client Overview

Design Overview

The client consists of several pieces:

• lexer (prototype done)
• parser (some code exists, needs work to set up a node tree that can be fed to the interpreter)
• interpreter (prototype done - works by employing RTTI)

The current goal is to get the parser in a shape that we can hook all three pieces together. For a more detailed description have a look at the following topics.

Parser: How many passes?

We are certain that a one pass parser is not sufficient. Hence the question remains: how many passes should we do? One suggestion:

• first pass: determine whether we run in CoCoA4 compability mode or CoCoA5 mode.
• second pass: determine the names and numbers of indeterminates, build listing of all functions and variables
• third pass: build node tree and call the interpreter

Parser: CoCoA 4 compability mode vs. CoCoA 5 mode

The interpreter won't need to differenciate between those two modes since it is the parser's job to create a node tree.

One feature that we strongly desire is the possibility to type variables when we instanciate them. This cannot be done in CoCoA 4 compability mode. Hence the parser would turn a definition of a function like

Define F(A,B)

into

Any Define F(Any A, Any B)

internally. The Any-type is the old CoCoA 4 type. Using the Any-type has certain drawbacks, for example the need to check type compability during runtime.

Parser: CoCoA4 compability mode - a closer look

While we attempt to be 100% compatible with CoCoA 4.X, we might have to weigh this desire against cleanliness of the code. Bending over backwards to implement obscure and/or little used features in the CoCoA4Language is not the highest priority at he moment.

Typing of variables

CoCoA 4 currently implements 20 different types. While we strive to implement all of those for the first CoCoA 5 release we will probably mark some of those types as depreceated and clearly warn people that some of those type will be abandoned in future releases.

New Datastructures

One might miss certain datastructures in the current CoCoA 4 when implementing algorithms. Here are a couple of suggestions from us:

• Mapping: should function like a hash with key-value pairs, implemented using c++ mappings
• homogeneous list: since currently lists in CoCoA 4 are composed of Any-types, sorting lists is very expensive (roughly cubic or worse). Having homogenous lists gives us the opportunity to implement very efficient sorting algorithms with n*log(n) average case cost.
• double linked lists vs. arrays: lists are currently implemented as vectors of pointers. As a result, inserting or deleting elements from a list is rather expensive. So we would like to offer two different kind of lists: One uses a vector approach so that elements can be accessed in constant time with the downside that inserting or deleting elements is expensive. The other one would be a double linked list, making inserting and deleting elements very cheap with the downside that access to random elements would be expensive. Depening on the need of the algorithm, i.e. if we need to partition a list depending on a condition, one would choose one approach over the other.

To reference count or not to reference count?

There is still an ongoing discussion whether we should reference count objects or not. While one can easily construct a case where reference counting would be of tremendous advantage the question remains whether this is worth the hassle since it complicates code. One possible way out of the mess is the ability to pass variables/objects to subroutines by reference. Being able to make an object/variable const may be an added bonus.