repository·master·Indexed 24 days ago
https://github.com/valelang/valeA high-performance, memory-safe, statically-typed programming language compiled to LLVM. Vale utilizes generational references instead of a garbage collector or borrow checker to achieve memory safety. The documentation covers language features, compiler architecture (Frontend, Backend, and Coordinator), build instructions for Ubuntu, macOS, and Windows, and detailed memory layouts for Sparse Arrays, Sparse Lists, and Sparse Stable Lists.
Vale is a fast, memory-safe, and easy-to-use programming language. It is AOT (Ahead-of-Time) compiled to LLVM and is statically-typed.
Key features include:
A territory change occurs when a final owning reference inside a varying inline object is changed (e.g., replacing one Spaceship with another). While the type remains stable, the indirectly owned memory area changes.
To detect this, you can use the First Final Owned Pointer (FFOP). By remembering the FFOP of an inline object, you can check if it has changed. If the FFOP differs, it indicates that the underlying hierarchy (the 'territory') has been replaced.
Every function in Vale receives a mutable region, often referred to as the default region.
Every 'denizen' (function or struct) in Vale has an implicit self-region. While you can omit region annotations, they are conceptually present to track ownership and lifetime.
For a function, the default region acts as the ambient region for its local variables. For a struct, the default region identifies the region in which the struct's own fields reside.
Example: Implicit Function Regions
// Explicit version of a standard function
func main<m' rw>(args m'[]str) m' {
list = m'List<int>(0);
println(list.len());
}Example: Implicit Struct Regions
// Explicit version of a struct
struct HashMap<K, V, x'> x' {
size x'int;
arr x'[]HashMapNode<K, V>;
}// Standard function with implicit regions
func main(args []str) {
list = List<int>(0);
println(list.len());
}
// Standard struct with implicit regions
struct HashMap<K, V> {
size int;
arr []HashMapNode<K, V>;
}In Vale, generics use instantiation bounds to ensure that types passed to generic functions or structs satisfy specific requirements (e.g., implementing a certain function like drop).
Key behaviors regarding bounds:
FunctionT, the instantiationBoundParams (of type InstantiationBoundArgumentsT) must match the runes used at the call site. This ensures that the arguments provided during a call align with the requirements defined in the function's signature.moo(P, Q), and there are two different overloads of moo that could match the provided types, the resolution may be ambiguous. The system aims to perform checks at the call site to mitigate this.HGM v13 introduces the concept of a "span" for arrays, where a generation is shared every $N$ bytes.
Implementation Details:
(index / 2^11). Read the generation at that location, move 16 bytes past it, and then add (index % 2^11) to locate the specific element.weakable object is dead. To track the lifecycle of weakable objects in this version, you must use an LGT.When reading structs from a linear buffer that uses offsets instead of pointers (e.g., when writing to a file), Vale does not immediately translate these offsets into pointers using a Serialized Address Adjuster upon loading.
Instead, Vale follows a 'lazy translation' approach: when a reference is read from the serialized buffer, it may remain as an offset. The translation from an offset to a valid pointer occurs only when the program eventually attempts to load from the specific struct or array containing that reference. This avoids the complexity of recursively translating entire hierarchies of fat pointers, interfaces, or enums immediately upon loading.
Vale primarily uses regions for memory safety, which has largely obviated the need for HGM. However, HGM is considered for scenarios where more precise control is needed within a region to eliminate generation checks (gen checks).
A common problem occurs when passing a non-owning reference to a function (like push in a collection) where the compiler cannot guarantee the reference remains alive, potentially triggering a generation check.
Proposed strategies to handle this include:
live keyword on parameters to monomorphize functions (creating one version for when the value is known to be alive and one for when it isn't).trackable to include metadata (like a boolean bit) within the type or its padding to facilitate live references.The HGM architecture provides two key benefits for runtime execution:
When accessing a member of a generic struct using dot notation (e.g., self.table), Vale performs a substitution to rephrase the accessed type in terms of the current denizen's placeholders. This ensures that nested generic types are correctly mapped to the local generic context.
#!DeriveStructDrop
struct HashMapNode<X Ref imm> {
key X;
}
#!DeriveStructDrop
struct HashMap<T Ref imm> {
table! Array<mut, HashMapNode<T>>;
}
func keys<K Ref imm>(self &HashMap<K>) {
// Accessing self.table substitutes the internal HashMapNode<T>
// with HashMapNode<keys$K> to match the current context.
self.table.len();
}Vale uses an incremental approach to resolving generic placeholders. Instead of populating all placeholders at once, the compiler populates them one at a time and performs a 'solve' step in between each new placeholder. This prevents conflicts where multiple placeholders might otherwise violate constraints (e.g., when two placeholders are required to be equal).
Example of a function that requires incremental solving to avoid conflicts:
func bork<T, Y>(a T) Y where T = Y { return a; }If T and Y were populated simultaneously, they would be treated as distinct placeholders, causing the T = Y constraint to fail. By populating them incrementally, the solver can unify them.