A Modest Proposal: C++ Resyntaxed

In designing the SPECS syntax we have been guided by four design principles: consistency, differentiation, readability, and formal grammatical simplicity.

The specification of types in C++ provides an excellent example of the lack of syntactic consistency that has resulted from the evolutionary development of the language. The following statements all define new types in C++:

    class RXBase { virtual bool match(string) = 0; };
    typedef struct { int x, y; int z; } Vector;
    typedef int (*NumSrc)();
    enum Result { reject, accept, defer };
    union Tokens { int num; char* str; };

In designing the SPECS binding for C++ we have endeavoured to introduce better consistency into all syntactic forms, with particular attention to declaration syntax. In SPECS the above constructs are clearly indicated as creating new types with easily located names:

    type RXBase : class { func match : abstract (string->bool); }
    type Vector : class { [public] obj x, y: int; obj z : int; }
    type NumSrc : ^(void->int);
    type Result : enum { reject, accept, defer }
    type Tokens : union { obj num : int; obj str : ^char; }

Interestingly, C++ also exhibits the opposite syntactic shortcoming – insufficient syntactic differentiation of dissimilar constructs. This is particularly evident in the declaration of functions and objects, where slight variations in component order may completely alter the meaning of a statement:

const Vector& (*vectorA)(int,Vector[]);
const Vector* ( vectorB)(int,Vector[]);
const Vector* (&vectorC)(int,Vector[]);
const Vector* &(vectorD)(int,Vector[]);

In SPECS the differences between these constructs are clearly indicated and their names are (once again) more easily ascertained:

    obj  vectorA : ^((int, [] Vector) -> & const Vector);
    func vectorB :  ((int, [] Vector) -> ^ const Vector);
    obj  vectorC : &((int, [] Vector) -> ^ const Vector);
    func vectorD :  ((int, [] Vector) -> & ^ const Vector);

Both these design goals help support a third – that of maximizing the overall readability of the language. Other notable contributions towards this goal have been:

• reordering declarations to emphasize important features and group together related information
• modification of the template declaration syntax to reduce excess verbosity and better localize relevant information;
• requiring that all iteration or selection statements are followed by brace-enclosed compound statements rather than single unbracketed statements;
• the introduction of the keyword common to specify "static" class members, thereby reducing the semantic overloading of static;
• the replacement of the old-style cast syntax with one that is similar to the new-style casts;
• the introduction of the abstract keyword to replace the "=0" syntax for pure virtual functions;
• the rebinding of the assignment operator to ":=" to better differentiate it from the equality test, which becomes "=";
• the rebinding of the "address of" operator to "@" so as to reduce the overloading of "&";
• the introduction of the defined_cast keyword to make operator conversion declarations more obvious;
• the addition of the keywords inherits and initially .

A final design principle for SPECS was grammatical simplicity. The language was designed to ensure that the new syntax was LALR(1) parsable, grammatically unambiguous and required no semantic feedback from parser to tokenizer. This constraint considerably simplifies the construction of a portable compiler for the language by allowing us to use the widely available parser construction tools yacc and lex. As mentioned above, this has also improved the readability of the language.

The area of greatest difference between SPECS and C++ is declaration syntax. The SPECS binding adopts a number of conventions for consistency across declaration types. Most significantly, all declarations begin with a keyword which identifies the declaration type. This keyword is then followed by the name of the entity being declared, where this is appropriate. Additionally, all declarations either end in a semicolon or a curly-brace enclosed block. This is also the case for C++ function definitions, however C++ type definitions ending in a curly-brace enclosed block require an additional trailing semicolon. SPECS is consistent across the entire syntax in neither requiring nor allowing such a trailing semicolon. Hence, in SPECS, a type ends either in a semicolon or a right brace, but never both.

In SPECS, all type declarations begin with the keyword type, followed by the type name. Four kinds of type declaration are allowed in SPECS: simple, enum, class, and union. The union declaration is analogous to that of the class and is not discussed here.

A simple type declaration in SPECS is equivalent to a C++ typedef. It associates an identifier with a type ID and has the syntax:

    type identifier : typeID;

The following is a typical C++ typedef declaration:

    typedef int* IntPtr;

The equivalent SPECS declarations is:

    type IntPtr : ^ int;

An enum declaration is similar to its C++ equivalent, but in a format consistent with the other type declarations. It has the syntax:

    type optional_enumName : enum { enumContents }

The following is a simple C++ enum declaration:

    enum Colour { red=1, green, blue };

The equivalent SPECS declaration (declared without a trailing semicolon) is:

    type Colour : enum { red:=1, green, blue }

A class declaration in SPECS is semantically equivalent to a C++ class. It takes the place of both the C++ class and struct declarations, since the two constructs are isomorphic. A class definition has the form:

 type className : class { memberDeclarations }

An object declaration creates one or more variables. These variables can be of any type and need not just be instances of classes. All object declarations begin with the keyword obj. The general syntax is:

    obj objName1, objName2, ... objNameN : typeID

We note three main problems with the syntax of standard C++ function declarations:

• Function declarations are very similar in structure to variable declarations. In cases where the type of a variable involves a pointer to a function, the distinction can become very subtle, often involving only slight differences in bracketing.
• The name of a function has no uniform location within the declaration, and in more difficult examples can be embedded within levels of bracketing. Searching for a function declaration within a mass of code can be a challenge.
• The return type is placed before (and some distance away from) the parameter list, or may be entirely implicit. This makes it difficult to quickly ascertain the complete type of a function.

The SPECS syntax for function declaration tackles each of these problems. All function declarations begin with the keyword func, followed by the name of the function. The general syntax is:

    func functionName : opt_specifiers ( parameterList -> returnType );

The parameter list is an optionally-bracketed, comma-separated list of parameters. The syntaxes for a parameter declaration are:

    parameterName : paramType
    parameterName := defaultValue : paramType

If a function takes no parameters, the parameter list must be declared void. The following are C++ function declarations:

    fn1();
    char* fn2(char* param1, int param2);
    const T& fn3(int (*param1)[10]);

The equivalent SPECS declarations are:

    func fn1 : (void -> int);
    func fn2 : ((param1 : ^char, param2 : int) -> ^char);
    func fn3 : ((param1 : ^ [10] int) -> & const T);

A language declaration in a SPECS program specifies a (link to a) non-SPECS code fragment. It has the general structure:

    lang "languageName" { declarationSeq }

where the set of allowed language names is implementation dependent, but contains at least "asm", "C", "C++" and "SPECS". The lang keyword provides a unification of the asm (assembly directive) and extern (external linkage) declarations of C++, whilst eliminating the semantic overloading of the latter.

Within an "asm" language declaration, assembly directives are either newline or semicolon terminated (or both):

    lang "asm"
    {
	mov eax, ebx; xchg ecx, edx
	shl eax, 7; // This semi-colon not required
    }

The equivalent C++ would be:

    asm("mov eax, ebx"); asm("xchg ecx, edx");
    asm("shl eax, 7");

The behavior of the "C" language declaration is identical to the corresponding extern (external linkage) declaration in C++. By extension, standard C++ syntax code is expected within a "C++" language declaration. This is useful when writing SPECS programs that include header files for one or more C++ standard libraries.

A class declaration in SPECS is semantically equivalent to a C++ class. It takes the place of both the class and struct declarations, since the semantics of a struct can be achieved by the addition of a public access specifier at the start of a class type declaration. A class declaration has one of the following formats:

    type className : class;
    type className : class opt_inheritanceList { /* member declarations */ }

where the first form brings a class name into scope, and the second defines an actual class. The inheritance list has the form:

    inherits BaseClass1, BaseClass2, ...etc

where the base class specifications may include one of the access specifiers: public, protected and private, and/or the inheritance specifier virtual, with the same semantics as in C++. Hence, the following SPECS class declaration:

    type ListClass : class inherits public ListBase, private virtual ListImpl
    { /* member declarations */ }

is equivalent to the C++ declaration:

    class ListClass : public ListBase, private virtual ListImpl
    { /* member declarations */ };

A member of a class can be declared public, protected or private (the default). Within a class, only one of these access specifiers will active at any time. To change the current specifier within a class declaration, a directive of the form [accessSpecifier] is used:

    type PublicClass : class
    {
        // members declared here are private
    [public]
        // members declared here are public
    }

In C++ the names of a constructor and destructor of a class are derived from the class name. Because these names will differ from class to class, it can be difficult to identify these members at a first glance. To rectify this problem, in SPECS constructors and destructors are always called ctor and dtor respectively. The general syntax is:

    func ctor : optional_specifiers ( paramList )
        optional_initializer_list
        { /* code */ }

    func dtor : optional_specifiers ( void )
        { /* code */ }

Note that, as in C++, neither constructors nor destructors have a return type.

A constructor initializer list is introduced with the keyword initially:

    func DerivedClass::ctor : (size : int, name : ^char)
        initially BaseClass::ctor(), mySize(size), myName(name)
        { /* code */ }

Although templates are a central feature of C++, the declaration syntax of C++ templates is not always easy to comprehend:

    template class list
    {
    public:
        template T1* match(const T2&);
    };

It is even more cumbersome to define such a member of a template outside the template body :

    template template
    T1 array::match(const T2&) { /* code */ }

The problem stems from the fact that a template declaration has its template parameter list separated from the name that is being parameterized. SPECS alters this syntax so as to eliminate this separation and the excess verbosity of such declarations.

The first change is from simple angle brackets ("<" and ">") to composite brackets ("<[" and "]>"). Replacing single character brackets with two character brackets is not a change that was taken lightly, but it does solve three C++ problems and at the same time clearly delineates the parameterization of a template. The problems solved are:

• There is no longer a need to bracket template arguments containing the "greater than" operator, as in the C++ declaration TemplateClass<( 1>2 )>, since the SPECS version TemplateClass<[ 1>2 ]> is unambiguous.
• It is no longer necessary to put a space between successive closing template brackets, (for example: array<auto_ptr<X> > in C++) . In SPECS, array<[auto_ptr<[X]>]> is unambiguous.
• The template keyword is not needed to disambiguate a member template function call, as in C++:

      x := p-> template alloc<200>();

  The SPECS equivalent is:

      x := p^.alloc<[200]>();

The general form of a template class is:

    type className <[ templateParamList ]> : class opt_derivedList
    {
        // template members...
    }

The following C++ template examples:

    template class Map { /* members */ };
    template template class Outer::Inner { /* members */ };

are written in SPECS as:

    type Map<[type Key, type Value]> : class { /* members */ }
    type Outer<[type T1]>::Inner<[type T2]> : class { /* members */ }

Specializations of these templates in SPECS are similarly readable:

    type Map<[int, ^char]> : class { /* specialized members */ }
    type Outer<[type T1]>::inner<[int]> : class { /* specialized members */ }

The general form of a function template is:

    func funcName <[ templateParamList ]> : opt_specifiers ( paramList -> returnType );

The C++ equality test (val1 == val2) has been changed in SPECS to val1 = val2, as this binding for "=" is more consistent with widespread mathematical usage. The inequality operators ("!=", "<", "<=", ">", ">=") are unchanged.

New-style casts in C++ provide a clear indication that a cast is in progress, and the purpose of that cast. However the ISO/ANSI C++ standard committee has not deprecated the use of old-style casts. Hence, SPECS allows old-style casts, but requires a clearer syntax:

    cast<[typeID]>(Expression)

The while, do-while and for loops retain their C++ syntax in SPECS, except that a single unbracketed statement is no longer permitted as a loop body (that is, the body of a loop must be a block). Likewise, an if statement can only control a brace-enclosed block of zero or more statements, and the statement following an else must either be a (cascaded) if statement or a brace-enclosed block.

The switch statement in SPECS has been considerably altered from its C++ equivalent. It consists of zero or more specified cases and an optional default case, For example:

    switch ( nextValue )
    {
	case 1:       { cout << "Unity" << endl; }
	case 2,4,6,8: { cout << "Even"  << endl; }
	default:      { cout << "Other" << endl; }
    }

Each case consists of a list of one or more (integral) constant expressions, followed by a brace-enclosed block. If the condition matches any of the constant expressions belonging to a case, then the corresponding block of code will be executed. After the block executes control jumps to the end of the switch statement (not to the next case, as in C++). The break statement will also cause control to jump to the end of the switch statement. The continue statement can be used in a case block and causes control to jump immediately to the beginning of the next case block, thereby implementing a more general, but safer form of fall-through than the C++ default behaviour.

By this stage the reader may feel that SPECS has little in common with its parent C++. In fact, the two languages are semantically isomorphic and significant portions of the two languages are syntactically identical. Features common to C++ and SPECS include:

• All inbuilt types are identically named and implemented. All literal values are specified in exactly the same way.
• The same set of operators (with the same precedences) are available for overloading. All binary operators maintain the same associativity in both languages.
• All scoping rules, temporary lifetimes, overloading constraints, function call resolution mechanisms, implicit conversions, access defaults and restrictions, and control structure semantics (except switch statement fall-through) are identical.
• The same preprocessor (cpp) and standard libraries are used for both languages.
• RTTI is identically implemented in both languages, and uses the same syntax.
• The exception handling mechanism and keywords are the same. The specification syntax is also identical except where syntactic differences in type or function specification preclude this.
• Namespaces have identical semantics and syntax in both languages.

In implementing a new text binding for the semantics of C++, we have enjoyed the unparalleled advantage of hindsight and the freedom to step beyond the restrictions of the evolutionary path of C++. Most significantly we have rejected the "failed experiment" of the C declaration notation, in favour of a more Pascal-like approach. We have also taken the opportunity to clean up other error-prone constructs and vestigial unpleasantnesses, such as fallthrough in a switch, the declaration of objects of (subtly) differing types in a single declaration, single statements as control structure bodies, this as a constant pointer (rather than a reference), the overuse of the "&" symbol and static and extern keywords, the "="/"==" confusion, and the cryptic "=0" syntax for pure virtual functions.

The experience of syntactically redesigning a language of the complexity of C++ has been challenging and (at times) frustrating, and has left us with nothing but admiration for the designers of any real-world language, who must not only contend with all the issues and choices we have faced, but must also address the much harder task of simultaneously designing a consistent, powerful, and comprehensible semantics. It is our hope that the example of SPECS will encourage such language designers to recognize that language syntax is the physical interface between programmer and computer and, as such, demands just as much care and design as the language semantics, which is the programmer's logical interface to the machine.

The correct declaration of set_new_handler is:

    void (*set_new_handler(void (*)(void)))(void);

This is so complicated that it is usually declared in two stages:

    typedef void (*new_handler)(void);
    new_handler set_new_handler(new_handler);

The use of a typedef is not, in our opinion, a sufficient improvement.

The equivalent declarations in SPECS are considerably cleaner:

    func set_new_handler : (^(void->void) -> ^(void->void));

and:

    type new_handler : ^(void->void);
    func set_new_handler : (new_handler -> new_handler);