# Edge Language

> A domain specific language for the Ethereum Virtual Machine

## Docs

- [Introduction](/intro): Edge is a domain-specific language for the Ethereum Virtual Machine (EVM):
high-level, strongly statically typed, and designed to make smart contract
development more expressive without giving up control over execution.
- [Tooling overview](/tools/overview): Edge's tooling is centered around the compiler CLI, the installer, and the
language server.
- [Built-in](/specs/builtins): Built-in functionality refers to features available during compilation that
are otherwise inaccessible through the language's regular syntax.
- [Inline assembly](/specs/inline): Edge supports inline EVM assembly for low-level control when the high-level
language abstractions are insufficient.
- [Specifications](/specs/overview): This document defines Edge, a domain-specific language for the Ethereum Virtual
Machine (EVM).
- [Comments](/specs/syntax/comments): The `<line_comment>` is a single-line comment, ignored by the parser.
- [Expressions](/specs/syntax/expressions): An `<expression>` is any construct that produces a value.
- [Identifiers](/specs/syntax/identifiers): Dependencies:
- [Data locations](/specs/syntax/locations): The `<data_location>` is a pointer annotation indicating which EVM data region
a value resides in. Edge defines seven distinct location annotations. This is a
divergence from general-purpose programming languages to more accurately represent
the EVM execution environment.
- [Modules](/specs/syntax/modules): Dependencies:
- [Operators](/specs/syntax/operators): Operators are syntax sugar over built-in functions. Operator overloading is disallowed.
- [Syntax](/specs/syntax/overview): Conceptually, all EVM contracts are single-entry point executables and at compile time,
Edge programs are no different.
- [Statements](/specs/syntax/statements): A `<statement>` is a language construct that does not itself produce a value
(unlike an expression). The top-level parse loop collects statements until EOF.
- [Variables](/specs/syntax/variables): Dependencies:
- [ABI](/specs/syntax/types/abi): The application binary interface is both a construct to generate a JSON ABI
by the compiler and a subtyping construct for contract objects.
- [Array types](/specs/syntax/types/arrays): The array type is a fixed-length list of elements of a single type.
- [Type assignment](/specs/syntax/types/assignment): Dependencies:
- [Contract objects](/specs/syntax/types/contracts): Contract objects serve as an object-like interface to contract constructs.
- [Event types](/specs/syntax/types/events): The event type is a custom type to be logged via EVM log opcodes.
- [External Calls](/specs/syntax/types/external-calls): External calls enable cross-contract interaction through ABI-typed
addresses. The `Impl` type wraps an address with compile-time ABI
information, enabling type-safe method dispatch that compiles to
EVM CALL, STATICCALL, or DELEGATECALL instructions.
- [Function types](/specs/syntax/types/function): The function type is a type composed of input and output types.
- [Generics](/specs/syntax/types/generics): Generics are polymorphic types enabling function and type reuse across different types.
- [Implementation](/specs/syntax/types/implementation): Implementation blocks enable method-call syntax and trait satisfaction.
- [Type system](/specs/syntax/types/overview): The type system builds on core primitive types inherent
to the EVM with abstract data types for parametric polymorphism,
nominative subtyping, and compile-time monomorphization.
- [Primitive types](/specs/syntax/types/primitives): The `<primitive_data_type>` covers signed and unsigned integers, booleans,
address, fixed bytes, and the single-bit type. Each maps directly to
`TypeSig::Primitive(PrimitiveType)` in the AST.
- [Product types](/specs/syntax/types/products): The product type is a compound type composed of zero or more internal types.
- [Sum types](/specs/syntax/types/sum): The sum type is a union of multiple types where the value represents
exactly one of the inner variants.
- [Trait constraints](/specs/syntax/types/traits): Traits are interface-like declarations that constrain generic types to
implement specific methods or contain specific properties.
- [Branching](/specs/syntax/control/branching): Branching refers to blocks of code that may be executed based on a condition.
- [Code blocks](/specs/syntax/control/code): A code block is a sequence of items with its own scope. It may appear
standalone or as the body of a function, loop, or branch.
- [Loops](/specs/syntax/control/loops): Loops are blocks of code that may be executed repeatedly based on conditions.
- [Control flow](/specs/syntax/control/overview): Control flow is composed of code blocks, loops, branches, and pattern matching.
- [Compile-time branching](/specs/syntax/compile/branching): Dependencies:
- [Constants](/specs/syntax/compile/constants): Dependencies:
- [Compile-time functions](/specs/syntax/compile/functions): Dependencies:
- [Literals](/specs/syntax/compile/literals): Numeric literals are composed of decimal or hexadecimal digits. Each literal
may contain underscores for readability. Hexadecimal literals are prefixed
with `0x`.
- [Compile time](/specs/syntax/compile/overview): Compile time, also referred to as comptime, covers expressions, functions,
and branches that are resolved during compilation. Comptime expressions and
functions resolve to constant values at compile time, while comptime branches
provide conditional compilation.
- [Basics](/specs/showcase/basics): This page walks through the fundamental building blocks of Edge: contracts, storage, functions, types, expressions, and transient storage. All code snippets are exact copies from files in [`examples/`](https://github.com/refcell/edge-rs/tree/main/examples).
- [ERC20](/specs/showcase/erc20): A complete ERC-20 fungible token in Edge. This page covers two implementations:
- [Syntax showcase](/specs/showcase/overview): The following are Edge language source code examples, organized by category.
Full source files are in the [`examples/`](https://github.com/refcell/edge-rs/tree/main/examples) directory, with standard library modules in [`std/`](https://github.com/refcell/edge-rs/tree/main/std).
- [Codesize & optimization](/specs/semantics/codesize): This document details Edge's optimization pipeline. The compiler transforms
source programs through a multi-stage IR optimization pipeline before generating
EVM bytecode.
- [Namespaces](/specs/semantics/namespaces): A namespace contains valid identifiers for items that may be used.
Edge uses a hierarchical module-based namespace system.
- [Semantics](/specs/semantics/overview): The semantics section covers language features that are not tied to specific
syntax constructs — general compiler behaviors, name resolution, and access
control.
- [Scoping](/specs/semantics/scoping): Items are brought into scope by import or declaration.
- [Visibility](/specs/semantics/visibility): Visibility controls which items are accessible from outside their declaring
scope. Edge has four visibility levels:
- [Contributing](/contributing/contributing): This document covers contribution guidelines for [edge-rs](https://github.com/refcell/edge-rs).
- [Contact](/contact/contact): If none of the below methods work, reach out to [refcell](https://github.com/refcell)
on [x.com @ andreaslbigger](https://x.com/andreaslbigger).
- [Compiler architecture](/compiler/overview): Edge compiles `.edge` source files into EVM bytecode through a multi-stage pipeline. The compiler uses **egglog** (equality saturation) as its core optimization framework at two distinct stages: once on the high-level IR and once on the emitted bytecode.
- [Quickstart](/compiler/quickstart): This page gives you the fastest path from a fresh checkout to compiling an
`.edge` contract. For a deeper walkthrough of the internals, see
[Compiler Architecture](/compiler/overview).