CoCoA:CoCoA5Client Overview

Design Overview

Caution: Ongoing Work

This document is the result of ongoing discussion between John, Franceso and Michael. It is a collection of thoughts about where we want to go with the new CoCoA 5 client.

Modular design

The CoCoA 4 client is neither properly documented nor is it obvious where i.e. all parts of the interpreter is implemented. It is for example possible to add built-in commands on different levels. For example the Print function is defined in the grammar as well as reintroduced in the parser.

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: 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.

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.

General Design

Technical stuff:

• Have 2 equally important modes: CoCoA 4 and CoCoA 5
• Support the CoCoA 4 Language in CoCoA 4 mode close to 100% (whatever is humanly possible) - certain features are marked as depreceated
• seperate lexers and parsers for each mode, share as much code as possible
• common interpreter

CoCoA4

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

Namespace

1. functions
2. identifiers
3. rings
4. aliases

Variables

Name of variable contains alhpanumeric characters plus underscore. Has to start with either underscore or capital letter

Panel

Keep supporting it.

Catch

Keep supporting it.

Features that might be depreceated

• Block ... EndBlock If Condition

CoCoA5

Parser: How many passes?

We are confident that we only need to do one pass in CoCoA 5 mode.

Namespace

one flat namespace, i.e. x cannot be variable and indeterminate at the same time

Variables

• Maximum length of variables defined in header file at compilation, suggested length 250 characters
• two options for overlength variables: truncate and warn or throw error.

Needs more discussion

Datatypes

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.
• Since we will interface will many different external numerical libraries (think BLAS, Lapack) it could be benefical to add a datatype double (with all its know limitations) to CoCoA5 in order to make the life of plugin-writers easier. We obviously would also need functions to convert to and from double to arbitray precision types.

Panels

We have four keywords manipulating Panels: Set, Unset, Option & Panel.

Let each package have a panel. Values can be of any available type. Example:

Package Foo;

Panel
  SUGAR:=False;
  Name="lkjshg;
EndPanel

To access a panel value use $Foo.SUGAR; to assign use $Foo.SUGAR:=False; and to reset value use reset $Foo.SUGAR, to reset the whole panel do reset $Foo.

We store setting for the interpreter and internal function (like timestamp format) in the CocoA5 panel.

errors and warnings

Parser should omit warnings and errors, warning could be surpressed via an option.

Catch and Uncatch

A good idea, similar to the concept of exceptions.

TIME

Keep TIME for compability, but introduce native type TimeStamp, i.e.

TimeStamp T1,T2;
T1:=Now();
DoSomething();
T2:=Now();
Print T2-T1;

Precision should be 1/100 of the second, just like in CoCoA4, or better depending on the platform. Linux under x86-64 for example provides higher resolution.

Format of time is set via CoCoA5 Panel. Write a timer package that would handle starting, stopping and pausing timers.

Packages

In order to keep the parser slim and the number of keywords down offer the ability to define Functions as "buildin" and provide some way to map those to Nodes. Also offer a similar way to register functions from plugins.

To be discussed later:

• how to export namespaces, what is visible from outside, i.e. functions starting with underscore are not publically available

Input and Output

Kill the internal Device interfaces and properly use filehandles. Also make stdin & stdout easily available to CoCoA5.

PlugIns

Each plugin requires a package which defines the function it provides by declaring them External. The CoCoA 5 client provides a well defined api to create, manipulate and delete datastructures from within CoCoA 5.

Anonymous functions

useful in certain circumstances like a user-defined sort-operator:

SortBy(L,(x,y)->(Deg(x),Deg(y)));