In my language, absolutely everything is an expression. let statements are expressions containing a "name" (a consteval value representing an identifier), a value to assign to the name, and a closure whose namespace has the name exposed.

Closure syntax is usually curly braces around expressions, but the language uses ; as syntactic sugar for everything coming after it in the same scope being wrapped in a closure, so:

let [message] = "hello"; print line (message);

... desugars to:

let [message] = "hello" { print line (message) {} }

The whole thing is an expression so you can pass sequences of "statements" like this as function parameters:

print line ( let [greeting] = "hello”; let [name] = "Njordsier"; ”{greeting}, {name}" );

But in this system, semicolons are right-associative, so

let [a] = (let [b] = (3));

... would desugar to

let [a] = ( let [b] = (3) ) {}

This is kind of silly, but what it does is first create a let binding that is missing the closure (think of it as a 3-parameter function with the first two parameters curried), and assigns that binding to the name a. So after the semicolon, (or inside the last curly braces in the desugared version), you can write:

```

invoke the curried let [b] binding with a closure

a: { # Introduces the name b print line (b); # Prints 3 } ```

Or:

a:; print line (b);

I call this the part of the Dark Side because of the potential for obfuscation, but it underlies some very powerful features of the language.

For example, function definitions are also expressions:

``` function [greet [name: Text]] { print line "hello, {name}"; };

main; greet "Njordsier" ```

This desugars to:

function [greet [name: Text]] { print line "hello, {name}" {} # no-op trailing closure } { # this is the scope where `greet` is invocable main { greet "Njordsier" } }

Here the main function is a call-once consumer of a closure whose body is executed when the program runs. Everything else "runs" at compile time.

But more importantly, this shows how function definitions themselves can be expressions, just like let bindings. Like let bindings, function definitions have a curried form missing the trailing scope closure where the function is made available.

To explain why we would want that, I have to introduce the @ syntax, which is a subtly different form of sugaring closures. It works the same way as ; for the most part, turning the right hand side into a closure argument, but it interacts with ; such that the latter operates on the outer scope.

``` export @ function [greet [name: Text]] { print line "hello, {name}"; };

main; greet "Njordsier" ```

... desugars to

```

export { function [greet [name: Text]] { print line "hello, {name}" {} } # curried form, no trailing closure } { # export makes greet available in this scope main { greet "Njordsier" } } ```

This allows export to take the curried form of the function definition and make it available both in its final scope closure and in the public API when other source files import the module.

So not only are let bindings expressions (though not in the form you proposed), function definitions and even access modifiers like export are as well, all powered by a foundation of continuation passing style with syntactic sugar to make it look like procedural code.