Quorlin
Docs
Documentation Index
7 min read•Chapter 3

3. Language Philosophy & Design

Smart contract development on blockchain platforms has historically suffered from high barriers to entry, ambiguous syntax, and opaque compilation pipelines that obscure security risks. The Quorlin Smart Contract Language was designed for the Kortana Virtual Machine (KVM) to fundamentally change this dynamic.

Quorlin's design philosophy rests on a single core assertion: smart contract code should look like modern structured code (such as Java or C#) and read like plain English. By eliminating cryptically named types and ambiguous state mutation semantics, Quorlin makes contract logic intuitive for developers, easily auditable by security researchers, and seamlessly interoperable with established EVM toolchains.

3.1 Core Principles: Readability, Safety, and Familiarity

Many traditional smart contract languages sacrifice clarity for low-level expressiveness, introducing subtle bug vectors. Quorlin prioritizes semantic intent. Every construct in Quorlin is explicit, reducing cognitive load and avoiding implicit behavior.

High-Level Language Characteristics

  • Familiar Syntax: Quorlin inherits structural syntax from Java, C#, and JavaScript (using curly braces {}, standard operator precedent, and explicit type declarations).
  • English-like Keywords: Rather than raw protocol abbreviations, Quorlin uses self-explanatory English terminology:
    • number instead of uint256
    • truth instead of bool
    • text instead of string
    • nothing instead of void
    • yes / no instead of true / false
    • reads and writes instead of complex, multi-token specifiers (view, pure, or default mutability).

Consider this complete Quorlin implementation of a basic token balance system:

contract TokenVault {

    number totalVaultSupply;
    map<address, number> vaultBalances;

    event VaultDeposit(address indexed user, number amount);
    event VaultWithdrawal(address indexed user, number amount);

    constructor {
        totalVaultSupply = 0;
    }

    reads number getBalance(address account) {
        return vaultBalances[account];
    }

    writes truth deposit(number amount) {
        require amount > 0, "deposit amount must be positive";

        vaultBalances[caller] = vaultBalances[caller] + amount;
        totalVaultSupply = totalVaultSupply + amount;

        emit VaultDeposit(caller, amount);
        return yes;
    }

    writes truth withdraw(number amount) {
        number userBalance = vaultBalances[caller];
        require userBalance >= amount, "insufficient balance";

        vaultBalances[caller] = userBalance - amount;
        totalVaultSupply = totalVaultSupply - amount;

        emit VaultWithdrawal(caller, amount);
        return yes;
    }
}

Anyone with basic programming literacy can audit this contract and immediately understand its exact runtime logic, storage structures, and security checks.

3.2 Human-Centric Type System vs. EVM Binary Compatibility

A defining architectural aspect of Quorlin is the clear separation between its internal source type representation and its external ABI/EVM mapping.

In Quorlin’s design, developer ergonomics and network wire compatibility are treated as distinct concerns:

  1. Developer View (Internal Representation): Diagnostics, compiler errors, and syntax trees use human-readable terms (number, truth, text, nothing).
  2. Wire View (EVM ABI Representation): Functions, selectors, signatures, and event topics use standard Ethereum ABI type strings (uint256, bool, string, void).

The internal compiler mapping functions demonstrate this explicit translation layer:

Quorlin Keyword (type_name)EVM / ABI Equivalent (abi_type_name)Underlying KVM Storage / Representation
numberuint256256-bit unsigned big-endian integer
truthbool256-bit word (0x00...00 = no, 0x00...01 = yes)
addressaddress160-bit (20-byte) address
textstringDynamic byte sequence bound by kMaxTextBytes
nothingvoidVoid / No return value

Why This Dual Representation Matters

If a language uses non-standard ABI names internally (for instance, hashing a function identifier as transfer(address,number) instead of transfer(address,uint256)), the resulting 4-byte selector will hash to a completely different value using keccak256.

Quorlin solves this by preserving English syntax for the developer while computing function selectors and event topics strictly against standard Ethereum ABI typings (uint256, bool, etc.). Consequently, Quorlin contracts interact seamlessly with existing Ethereum infrastructure, web3 frontends, hardware wallets, and Solidity contracts.

3.3 Explicit State Mutability & Intent

Smart contract security bugs often stem from unintended state mutations. Quorlin forces developers to explicitly declare the mutability intent of every function signature using mandatory access modifiers: reads or writes.

Read-Only Functions (reads)

Functions marked with reads guarantee state immutability. They can inspect storage variables, execute calculations, and read context primitives (such as caller), but they are prohibited from modifying state or emitting events.

reads number calculateFee(number amount, number rate) {
    return (amount * rate) / 10000;
}

State-Modifying Functions (writes)

Functions marked with writes declare explicit permission to mutate state variables, update maps, execute low-level transfers, and dispatch contract events.

writes truth updateFee(number newRate) {
    require newRate <= 500, "fee rate exceeds maximum cap";
    feeRate = newRate;
    return yes;
}

Built-in Execution Context Primitives

Rather than using obscure global objects (like EVM's msg.sender), Quorlin exposes execution context through clear built-in identifiers:

  • caller: The immediate address executing the invocation (maps to msg.sender).
  • yes / no: Native literals representing boolean truth conditions.

3.4 Strict Analysis Gatekeeping & Compiler Architecture

The Quorlin toolchain operates via a linear 4-stage execution pipeline designed for predictable compilation and early safety verification:

+------------------+     +------------------+     +------------------+     +--------------------+
|    1. Lexer      | --> |    2. Parser     | --> |   3. Analyzer    | --> |   4. CodeGenerator |
| (quorlin/lexer)  |     | (quorlin/parser) |     |  (quorlin/sema)  |     | (quorlin/codegen)  |
+------------------+     +------------------+     +------------------+     +--------------------+
                                                           |
                                                  [ THE GATEKEEPER ]
                                                           |
                                                           v
                                                Validates types, scope,
                                                and register allocation

The Analyzer as the Security Gatekeeper

The third stage—the Semantic Analyzer (Analyzer)—acts as an unyielding gatekeeper.

As designed in the backend architecture (quorlin/compiler.cpp), the CodeGenerator performs no dynamic type safety checks or symbol lookups of its own. It operates on total trust that every symbol resolves and every type constraint is strictly satisfied. If the Semantic Analyzer encounters a single type mismatch, missing identifier, or invalid binary operation:

  1. Diagnostics are appended to the DiagnosticBag.
  2. Pipeline execution halts immediately.
  3. Zero bytecode modules are emitted.

This guarantees that invalid code is caught strictly at compile time before reaching the code generator or KVM interpreter.

Developer-Friendly Diagnostics

Quorlin avoids vague error messages. When semantic checks fail—such as referencing a non-existent field inside a record type—the semantic analyzer evaluates the context and lists the available options directly in the diagnostic output:

record Offer {
    address seller;
    number price;
    truth active;
}

If a developer attempts to access offer.cost, Quorlin generates an error explicitly stating:

Error: record 'Offer' has no field 'cost'. Available fields are 'seller', 'price' and 'active'.

3.5 Native EVM Interoperability via the Unified State Trie

Quorlin was designed specifically for the Kortana Virtual Machine (KVM), which operates on a unified state trie.

Rather than running in an isolated environment, KVM contracts share storage layout paradigms, keccak hashing schemes, and world state access with standard Ethereum contracts.

                  +-----------------------------------+
                  |         World State Trie          |
                  +-----------------------------------+
                                   |
                +------------------+------------------+
                |                                     |
                v                                     v
   +-------------------------+           +-------------------------+
   |  KVM Interpreter (KVM)  |           | KEVM Interpreter (EVM)  |
   | (Quorlin Bytecode Ops)  |           |   (Solidity Bytecode)   |
   +-------------------------+           +-------------------------+

Cross-VM Communication

Through StateHost and unified interface bindings, a Quorlin contract can call a Solidity contract, and a Solidity contract can call a Quorlin contract without custom translation bridges:

interface IERC20 {
    reads number totalSupply();
    reads number balanceOf(address account);
    writes truth transfer(address recipient, number amount);
}

contract InteropExample {
    
    address tokenAddress;

    constructor(address targetToken) {
        tokenAddress = targetToken;
    }

    reads number checkExternalBalance(address user) {
        IERC20 token = IERC20(tokenAddress);
        return token.balanceOf(user);
    }
}

Because Quorlin emits standard Ethereum ABI metadata and standard function selectors behind the scenes, standard ERC-20 interfaces (such as totalSupply(), balanceOf(address), and transfer(address,uint256)) resolve seamlessly regardless of which virtual machine executes the target contract.

3.6 Summary of Language Benefits

FeatureLegacy Smart Contract LanguagesQuorlin Design Standard
Type NamesCryptic (uint256, bytes32, bool)Readable (number, text, truth)
LiteralsLow-level (true, false)English (yes, no)
State MutabilityImplicit / Confusing keywords (pure, view)Explicit access intent (reads, writes)
EVM CompatibilityNativeNative (transpiles ABI specs automatically)
Compiler ArchitectureOften multi-pass, permissive codegenStrict semantic gating before bytecode generation

By pairing English-like syntax with a strict, security-focused compiler gatekeeper, Quorlin enables developers to write robust smart contracts rapidly without sacrificing low-level performance or cross-chain standards compatibility.

Previous Chapter
2. The Kortana Virtual Machine (KVM)
Next Chapter
4. Primitive Data Types
View Quorlin KVM Implementation on GitLab