Firstly, some assumptions about the platforms the language targets, just to get a few things out of the way. An implementation will not be able to support all the language features if some of these assumptions are not met. Note that these do not imply hardware support, merely compiler support; the difference is most relevant for floating-point and 64-bit integer types. <stdint.h> is available or can be implemented, with [u]int{8,16,32,64}_t and [u]intptr_t types present.

Note: Imported names/paths are made up, and are intentionally made more complicated for the sake of showing off features. For example, std@io.file is likely to just sit in either std@io or std@file directly. The syntax for imports is not finalized, but most of the semantics are. The most likely option is heavily inspired by D. // TODO: Not happy with this syntax. I like `std:io.file` visually the most, but that's ambiguious.

Note: Feature is as of yet TBD. Syntax isn’t finalized, but there are a few main options. The first is to have the lexer handle it, in a syntax (but not semantics) similar to the C preprocessor. Note that this is not a preprocessor, and especially not a C one. For example, conditional compilation is based on actual variables, and is not an arbitrary text/token replacement system. Likewise, function macros will not be supported, allowing a single pass over the entire source.

Perhaps rather unique among scripting languages, Coyote has a pass-by-value record type: the struct. It also provides a pass-by-reference type via class. struct SomeStruct { string foo; int bar; // implemented as an anonymous trait (see `Traits` below) string toString() { return format("%s %d", foo, bar); } } class SomeClass { string foo; int bar; } var s1 = SomeStruct(); s1.foo = "hello"; var s2 = s1; s2.foo = "world"; // does not affect s1 assert(s1.

Traits are designed as a mechanism for extending existing types with functionality. Both explicit and implicit traits exist; explicit traits (trait Foo) must be explicitly implemented for a given type. They implement nominal subtyping. Implicit traits (implicit trait Foo) apply to all types that match the “pattern” (structure) described within, thus implementing structural subtyping. Note: The example specifies what seems like operator overloading. While the D approach seems fine, I don’t fully know yet how it will work.

Some of this is as of yet TBD, but the following basic types are planned: // Miscellaneous void noreturn // encodes __attribute__((noreturn)) and similar bool null_t // the type of `null`; TBD: what to name this keyword? (again, I dislike ones ending with _t) // TODO: Actual name of type? dynamic // top type, essentially a boxed/variant type with some magic attached to it // Character Types char // equivalent to uint8_t in representation, but a separate type for clarity wchar // reserved; uint16_t-based dchar // reserved; uint32_t-based // note that strings are simply immutable `char[]` // TODO: Should strings be a separate type in their own right?

Structs & classes are covered above. Literals are also provided, as examples. Ones marked as “feature TBD” might not necessarily make the cut. // simple arrays int[] a = [1, 2, 3]; // array of integers (similar to int* in C) int[][] b = [[1, 2], [3]]; // jagged array (similar to int** in C) int[,] c = [1, 2; 3, 4]; // (feature & literal syntax TBD) multidimensional array (similar to int[2][2] in C) int[!

Note that the exact syntax is as of set TBD. The general syntactic idea will remain the same, but there may be some differences in the details. Furthermore, (D-like) templates may be provided instead. Generics are available: Types parameterized by other types. Support for value parameters is unlikely, but it is a possibility. Exact details are unknown, but they will likely by design be kept *non-*turing-complete. // LinkedListNode#T is shorthand for LinkedListNode#(T), as multiple parameters are supported class LinkedListNode#T { T item; LinkedListNode#T?

To keep this concise, only exceptions from other C-like languages are listed. Operator precedence is different from C in some places, but will not be included here at the moment. Note that many of these operators also support the <op>= form, such as ~= for appending. Note that in all cases, each operand is only evaluated once, regardless of how many times it appears within “equivalent to”. // ternary shorthands a ?

Note: It is TBD whether this will be a core language feature, or a library one. Also TBD on whether there’s a way to represent all this via arrays above. Since so many programs implement their own “Point” type, I’ve decided to add builtin vector types (at least in stdlib). Matrix & quaternion types are also likely to be present for completeness. Syntax is as of yet TBD. A generics-like syntax would be ideal for vectors (is presented here), but may cause ambiguities, and it is conceptually ugly (as it overloads the base types).