This page exists as a place to post proposed ideas. It is a bit more formal that the forums, but not so formal as to require a true spec. In the future, this should probably become a web form or a wiki.
Inline Assembly
The approach to inline assembly I created was to treat the assembly as a sort of inline function. The compiler adds no entry/exit code to an assembly function. This allows the code to be directly inserted into a function by "calling" the assembly function, or it allows the function to be used as an interrupt handler, or in a similar role where the entry/exit code is slightly different.
One possible option is to allow the grammar to support a new form of function declaration:
asm spin_lock : void(ptr : void*) {
mov t0,0;
swap t0,[ptr];
bne t0,0,.l1;
...
}
The disadvantage is that this approach requires substantial grammar reworking. Another approach can be to simply treat asm as a type qualifier, and to allow access to certain special functions, types, and declarations in an asm function.
spin_lock : void asm (ptr : void*) {
val : register = 0;
addr : register = ptr;
swap(val, *addr);
if (0 == val) {
...
}
Personally, I favor this approach, as it is more idiomatic with the language, and it is a bit more abstract and usable, while maintaining every bit of the power of other approaches. The ability to declare registers helps avoid register allocation conflicts. Presumably, all registers would be treated as a predeclared variable. The function could be written as follows:
spin_lock : void asm (ptr : void*) {
mov(t1, ptr);
swap(t0, *t1);
if (0 == val) {
...
}
Furthermore, this approach does not change the grammar at all.
Strict Pointers
The strict keyword when applied to pointers means that the pointer points to a single object. Pointer arithmetic is not allowed.
An alternate use of this keyword could be to introduce a managed pointer type, which throws an exception if NULL is dereferenced, or if pointer arithmetic is done on NULL. The argument against this is that this approach will not catch all possible pointer errors.
The current purpose of strict with pointers could be fulfilled by another keyword, possibly pure.
Functions and Lexical Closure
As mentioned in the design decisions document, I am presently deciding whether or not to allow a form of lexical closures. A possible scheme could work as follows:
type counter = int();
make_counter : counter const ();
type frame = make_counter.frame_type;
scope : frame;
make_counter : counter () {
count : int = 0;
func : int() {
return count++;
}
// save the current function's frame
scope = *(this.frame);
// set the returned function's backlink
func.slink = &scope;
return func;
}
Functions become a sort of "artificial structure", with a frame type, a code pointer, a static link, and a frame pointer.
Complex, Rational and Fixed Point Numbers
Complex numbers are numbers involving the mathematical value i (the square root of -1). Fixed point numbers are numbers with an implicit denominator. Rational numbers are classic fractions.
These could be implemented as primitives or derived types easily. I am open to any arguments for or against or suggestions concerning syntax or semantics.
