OMG, another programming language? Whyyy?? Are you serious with this??

• Do you unapologetically enjoy low-level systems programming in C, are actually quite productive with it, but just wish it had a few modern "creature comforts" and safety checks?
• Do you like the Rust and Ada brochures, but when you get down to writing programs in them, feel an unwarranted level of friction? Do you find they inhibit exploratory or creative programming?
• Do you find the modern model of package management that is a growing tower of fractal abstractions that try to reach up to heaven to be problematic? Want to easily create, use, modify, and extend modules (packages)?

Highlights

Examples

Basic Main Function

Here’s just a bit more than just printing “Hello, World!”

const pl_name str = "Crescent";
var verbose bool = false;

fn main(args str[]) i32 {
    println("Hello, World!");
    println("Programming language: ", pl_name);
    println("Number of arguments: ", args.length);

    foreach (arg in args) {
        println("Argument: ", arg);
        if (arg == "-v") {
            verbose = true;
        }
    }

    return 0;
}

Data Structures

Data structures in Crescent are essentially C-like structs.

@packed
struct Packet {
    opcode u8;
    payload_length u16;
}

@packed is an annotation. All annotations start with @ and are free-form. There are a limited number of annotations handled by the compiler but @packed is one of them. It tells the compiler to use 1-byte alignment (no padding between fields or at struct boundaries).

Enumerated Types (Enums)

Enums are explicitly of a type.

enum Color unit {
    Black;
    VeryVeryDarkGray;
}

enum OpCode u8 {
    NOP = 0;
    ADD = 1;
    SUB = 2;
    OMG = 3;
    HCF = 4;
}

fn handle_op_code(op OpCode) unit {
    if (op == OpCode.NOP) { }
    else if (op == OpCode.HCF) { while (true) { } }
}

fn batman_to_webcolor(color Color) str {
    if (color == Color.VeryVeryDarkGray) { return "#121212"; }
    return "#000000";
}

Type Aliases

Crescent has strict type aliases (which sounds like an oxymoron so maybe this should be called something else). You can alias a type and use it to differentiate different properties or units of variables and function parameters. Primarily this is used to solve the “sea of ints” function parameter problem in C and C++ where anything that could be interpreted as an int is quietly converted to an int.

type PressurePSI f32;
type TemperatureDegC f32;
type SalinityGramsPerLiter f32;

fn speed_of_sound_in_water(pressure PressureMPa,
                           temperature TemperatureDegC,
                           salinity SalinityGramsPerLiter) MetersPerSecond {
    // Do all that math and return the value
}

//   ---  8<  ---

var pressure PressurePSI;
var temperature TemperatureDegC;
var salinity SalinityGramsPerLiter;

//   ---  8<  ---

// Later...

var transmission_speed = speed_of_sound_in_water(temperature, pressure, salinity);

// ^ The above fails to compile with a type mismatch error.

These type alias names are quite verbose, but just for example purposes.

Easy Option and Try types

Use unions to create variants. These kinds of constructs are easy enough to create and use that Crescent is not opinionated about them and only includes them as part of a standard library and does not introduce try and option as intrinsic language types.

struct Result {
    value any;
}

struct Error {
    code i32;
    message str;
}

union Try {
    Result;
    Error;
}

fn do_process(uri str) unit {
    var response = request_the_stuff(uri);
    if (response is Error) {
        println("Error: Couldn't get the stuff:", response.message);
    }

    handle_response(response.value);
}

struct Some {
    value any;
}


struct None {
}


union Option {
    Some;
    None;
}

fn process() unit {
    var maybe Option = returns_an_option();
    if (maybe is Some) {
        // use maybe.value
    }
}

* There is a little run-time magic that makes this possible (e.g. during assignment).

Variadic Functions

Crescent leverages its run-time type information and safe arrays to support variadic functions without an unholy union of pre-processor and compiler glue. The special function parameter type ... collects the rest of the function arguments and passes them in as an any[]. You can then use the is operator to type-check the array elements.

fn println(args ...) unit {
    foreach (arg in args) {
        if (arg is str) {
            //  8< for brevity
        }
        else if (arg is bool) {
            //  8< for brevity
        }
    }
}

* Something like a “spread” unary operator that expands an array to an argument list is being considered. This is a natural inverse-like operation to the ... function parameter “collect” type. This gets immediately abused in most programming languages that have it (e.g. JavaScript and Python) but that’s not disqualifying by itself.

About The Language

Uniform Syntax

Defining types, functions, variables in your program follow a similar ordering convention: what it is, its name, its definition.

Once a type has been defined, its intrinsic construct-type (type of aggregate) no longer needs to be used in the syntax. E.g. if you define struct Thing {}, “Thing” is the type name and and it does not need to be prefixed with the construct type (struct) like in C (the compiler knows what it is and so should you).

Value literals match the enclosing symbol in their definition (e.g. array literals are enclosed in []). This looks better and makes type inference of arrays possible as it does not look like an anonymous structure literal.

Some hold-overs from C syntax are kept. Some punctuation-based syntax in newer languages is rejected. For instance, parentheses around flow-control conditions are kept. Some languages drop these in an aesthetic attempt to make programming seem more natural-language-like, but this has the flaw that it decreases quick scanability / parseability by humans. In the extent, if the entire program consisted of english words, its scanability actually decreases. Some newer languages introduce a lot of punctuation-based syntax for their differentiating features, ? as try type qualifier, :: delimiting type information, etc etc. In contrast to the flow-control punctuation, Crescent attempts to limit punctuation syntax where there is already a delimiter of some sort e.g. function parameters (first f32, second i32) is unambiguous and not improved by adding : between parameter and type. The shift key is already used enough in programming.

struct StructName { }
enum EnumName type { }
union UnionName { }

const pi f32 = 3.1415926535897932;
const first_four_primes u8[] = [1, 2, 3, 5];
var number_of_high_fives u32 = 27;

fn function_name(arg1 StructName) unit { }

(I have come to prefer snake case except for user-define type names being CamelCase but you do as you see fit.)

Conscientious Trade-Offs

• Explicit memory management. No garbage collection.
• Not removing punctuation-based syntax from flow-control conditions.
• Not adding punctuation-based syntax like ? and ::

Sins to be Avoided

• Classes and other forms of object-oriented fixed encapsulation and data/code associations.
• Operator overloading. Yeah, I know, but the, like, seven really good vec3f and mat4x4f-type use cases don’t cut it. Maaaybe binary operators excluding comparisons and assignment would be ok. Or maybe arrays-of-ints and arrays-of-floats get vector programming operators.
• “Move” and “forward” semantics.
• UB soup and sequence point stew

More details

unit
any
bool
u8
u16
i16
u32
i32
u64
i64
f32
f64
str

var greeting_tokens str[] = ["Hello", " ", "world!", "\n"];

fn say_hello() unit {

    foreach (token in greeting_tokens) {
        // token is a string value,
        // copied out of greeting_tokens
        print(token);
    }

    foreach (token* in greeting_tokens) {
        // token is a string pointer,
        // pointing into greeting_tokens
        print(token);
        // ^ Might look questionable except print(args ...)
        // checks for pointer-to-string (str*).
    }

}

var greeting_tokens str[] = ["Hello", " ", "world!", "\n"];

fn say_hello() unit {

    for (i u32 = 0, n u32 = greeting_tokens.length; i < n; i++) {
        print(greeting_tokens[i]);
    }

}

fn main(args str[]) i32 {
    var exit_requested = false;

    while (!exit_requested) {
        process_data();
        read_inputs();
        display_outputs();
        exit_requested = check_exit_requested();
    }
}

enum Fruit u8 {
    Apple = 0;
    Orange = 1;
    Banana = 2;
}

@packed
struct Packet {
    fruit Fruit;
    sender u32;
}

fn handle_packet(packet Packet) unit {
    if (packet.fruit == Fruit.Apple) {
        // ...
    }
    else if (packet.fruit == Fruit.Orange) {
        // ...
    }
    else if (packet.fruit == Fruit.Banana) {
        // ...
    }
    else {
        // Unknown fruit!
    }
}

Compiler

Compiler Status

There is a compiler in works that uses the LLVM backend. The first-pass compiler is named C-Prime (c-prime) which is mostly being used to develop and test language features. It is therefore not yet focused on the user interface (which is to say compiler warnings and errors). It is a “no mistakes allowed!” type compiler where the goal is only to explore combinations of language ideas and be feature-complete enough to compile a self-hosted compiler (crescent).

Mechanism

The compiler has a lot of standard stages like a resolution pass, a type-sizing pass, an inferrence pass (or more), a type-checking pass, a pass for checking basic errors like alloc-free mismatches / use-after-free, intermediate representation code generation.

Will like completely rip off the JAI compiler message loop idea. At least as it pertains to main stages so custom checkers and constraints can be added per code base.

Miscellany

To-Answer

“Why don’t you just use…?”

• Odin
• Zig
• C3
• Fil-C
• Verse / VerseLang

How is it different? Why is it different?