Skip to content

Key Ideas

U design has not been tied to legacy language syntax or semantics. All aspects of language design have been rethought from the ground up.

Most language paradigms have their roots in need for either:

  • A new theory: lambda calculus, ...
  • A better machine code abstraction: Assembly, C, ...
  • A better X language: better C (C++, Rust), better Perl (Python, Ruby), better ML (OCaml, Haskell)...

But instead of having one language for all domains, we often end up with many DSLs:

  • C/C++ preprocessor and template engine are DSLs.
  • Web stacks are the combination of HTML/CSS/JS/WASM.
  • Configuration formats (JSON, YAML, XML) are DSLs for others languages.

U's design approach programming from a completely different perspective by providing flexibility to adjust every step of the compilation process: Tokenization, parsing, type checking, optimizations, instruction generation, and binary output should be accessible and augmentable.

U vs Other Languages

Unlike other languages, U design has roots in defining heterogeneous environments found in almost all domains. But instead of gathering features needed, map them in grammars with keywords, U focuses on the minimal syntax required to clearly express features. Freed from any implementation choice, you can easily describe current and future solutions.

Programming languages designers cannot predict every possible need developers will face in the future. Instead, U provides a small set of features that let you naturally add new constructs and expressions as user defined function, or syntax.

U lets you grow its syntax: write less pretty code, extend, support or optimize it.

U returns to the root of language design by answering the following questions:

1. Lexical level: Why most languages have reserved keywords?

Most programming languages are iterations of previous ones. They reuse common patterns, including keywords. Although it might seem easier to read plain English words, keywords restrict the expression of your logic and make it difficult and slow to parse.

Instead, U has no reserved keywords like 'var', 'if', 'int'. It allows you to use any identifier you want.

In U:

  • no semicolon required: U is line based with optional semi-colons like in Python or Ruby.
  • hyphens are allowed in names for good reasons. You can write login_screen.
  • delimiters '(', '[', '{' are mapped to Values.

See Syntax for more details.

2. Syntax level: What could be the minimal rule set to define a clear syntax?

To define a minimal correct syntax, U introduces Apertures – a group of few special characters like ':', or '\' – that allow you to express almost all programming patterns. Each time an aperture is found in your code, the compiler check for a directive. Simple but powerful.

For example, the main entry point – '\/', the V of U – is guarded by the escape aperture '\' followed by '/'. With Apertures, almost all characters are allowed, even most common language keywords like if, or while.

U minimal syntax means empowering developers' mental models without restriction, with an easy learning curve.

# ':' prefix is used to create symbols (interned string) and variables
# ' : ' with spaces, ':' is the bind operator
:text : 'Hello, World!'

# A function returning 3 in one line
:fn : :> 3

# A function with braces returning the sum of 2 numbers
:block_function {: a, b
 a + b
}

3. Semantic level: What could be the minimal logic to fastly and safely generate machine code?

Many programming theories, paradigms exist, and it's challenging to pick one for all domains: OOP, functional, asynchronous, reactive, ...U lets developers choose the right one for the right job by just stating that:

  • Everything is a value: see Value
  • There are only two Value kinds: Primitive and Derived.
  • There are only two expression kinds: Binding and Applying

U's design is inspired by powerful functional programming aspects (Ocaml/Scala) to ensure proper implementation.

4. Openness: What is the best strategy to have a future-proof language?

Popular language designers struggle to keep the pace of technological changes because they are concerned about backward compatibility and making sure new features are implemented correctly. A complex syntax makes it worse.

U cares more about expressiveness, productivity, maintainability. The basic idea is that you should be able to extend the language to:

  • Avoid bad legacy in the future,
  • Keep a flexible syntax to integrate multiple DSLs,
  • Easily integrated future paradigms and hardware architectures.