Gamma Language Specification

The Scala of C

Documents

These PDF documents collectively form the specification of Gamma, detailing what must be made available to programmers. Keep in mind that they were written on extremely short notice, and thus gaps, repetitions and even contradictions may be present.

Background

Even though I came up with the language as described in these documents only in November of 2019, the concepts in this language had been rolling around in my mind for the past year or so.

The reason why I decided to work at C's level, instead of at a higher level or at the level of assembly, is because I feel that C occupies a niche that simply won't go away. The simple fact is that Linux is written in C; Windows is written in C at the core; Redox even has to offer a C standard library implementation; C++ still keeps backwards compatibility; Python, PHP, Java and other dynamic languages use implementations written in C; and even IoT is often done in C. The message is clear: C may not behave like a portable assembler, but it sure as hell is used like one.

The problem is, it has dangers which are not relevant to its applications. Operator precedence was chosen for backwards compatibility with B; null-terminated strings came from the personal experience of Dennis Ritchie and Ken Thompson; integer conversions and promotions only made sense back in the 80s; the increment and decrement operators only really promote unreadability while introducing moronic possbilities for undefined behavior; and the lexer hack doesn't make me think that the language is easy to parse. Then again, C got to where it is because of Unix and Linux, and we all know how Unix and Linux got to where they are.

This language may remind people of Ada - and indeed, I will not deny I have taken a look at it. That said, while the specification here should be at least usable, it shouldn't be considered complete; I am not ruling out adding (or perhaps removing) features in the future, but I will not do so without taking a wide look at all of the prior art in the industry.

Summary

To put it briefly, the points I took (almost) wholesale from C were:

• Type system: except for a few modifications, arrays, pointers and function pointers have practically exact equivalents in Gamma, and constancy works in the same way;
• Statements: except for minor aesthetic differences, most C statements have direct equivalents;

• Type system: function (but not operator) overloading is supported, and a result qualifier was added which makes reading from the datum forbidden. This would have use in, say, routines cooperating in cryptographic applications, where the code must not be able to read confidential output;
• Nested subprograms: a subprogram (function or procedure) can be nested, and obeys the same rules as other local datums (including not returning its address, since it would be tantamount to returning the address of a local - which, newsflash, is undefined behavior in C);
• Array values: array parameters and arguments in subprogram calls now conserve their length (i.e. #arr actually returns the length of the array), obviating the need for things like strlen;
• Namespaces: this is not just out of a matter of convenience, but also required by the standard library, which would otherwise be much more difficult to structure and implement;

• Type system: the basic types were rationalized and made consistent (e.g. n1,n2,n4,n8 and so on for unsigned types, and d1,d2,d4 and so on for floating-point types, where the number refers to the size of the type - this allows still supporting non-standard arches and byte sizes with considerably less byzantine type names);
• Integer promotions: an unsigned integer, if promoted, will be promoted to signed integer type of greater size, in all circumstances;
• Operator precedence: the bitwise operators are finally put in their proper precedence, ending the (a & b) == c infelicity;
• Syntax: operators are spelt differently, notably casting and pointer dereference, to eliminate the need for the lexer hack, and initializations employ type inference (with functions available in case one needs a short rather than a byte);
• Behavior: some forms of undefined behavior are eliminated, while others are introduced, for reasons which will be explained;

• File inclusion: this is made redundant with the linkage process described, and is also explained in the implementation notes;
• Null pointers: again, unions and overloads will provide a solution that will be illustrated in some examples;
• Integer conversions: a signed integer will never be converted implicitly to an unsigned integer type, period;
• Casts: as it turns out, they are redundant at best and invalid at worst (e.g. casting float to int is an attempt at ignoring rounding), so there's no real loss here;
• Arithmetic conversions: arithmetic operations should be interpreted as operating in infinite precision, regardless of the size of the operands, so the operands don't need to be of the same type as in C;
• Uninitialized variable reads: a variable should be written to before any read, so it makes no sense for the language to allow otherwise;
• Other conversions: in fact, some, like *((float *)&i), are undefined behavior (due to differing alignments) even in C, and that pointer conversion is better handled by unions, so there's arguably no loss here;
• Static locals: if strtok doesn't disturb you, then I guess this won't make much sense :-)

Discussion