Visual X# is an experimental native programming language and compiler project. This repository contains the compiler, project DSL, runtime components, language examples, tests, and supporting developer tools.
The repository is under an architectural transition. The production .vxs route now uses the Haskell lexer-through-Core
frontend and hands a verified VXCR Core artifact to the C++20 CorePrep-to-Xpp-to-Xmm-to-LLVM pipeline. The previous C
lexer/parser, semantic tree, macro, HIR/MIR duplicate, Rust FFI session bridge, and DIMCLI dependency have been removed.
The remaining Rust tree is transitional reference material, not a production dependency or a second supported compiler.
.vxs source
→ Haskell Lexer
→ Haskell Parser
→ Parsed AST
→ Renamer
→ Name Resolution
→ Resolved AST
→ Type Checker
→ Typed AST
→ Desugarer
→ Core
→ Core optimizations
→ CorePrep
→ C++20 Xpp
→ Xpp optimizations
→ C++20 Xmm
→ Xmm optimizations
→ LLVM bitcode
→ native object and .vxse executable
Core, CorePrep, Xpp, and Xmm are target-independent. Their public artifact extensions are .core, .xpp, and .xmm;
normal compilation keeps intermediate data in memory unless explicit emission is requested.
The official native development hosts are Windows 10/11, macOS 15 Sequoia, and macOS 26 Tahoe. Both host families use:
- Bazelisk for the production C++20 graph;
- an LLVM development package containing headers, libraries, and
llvm-config; - GHC 9.10 and Cabal for the Haskell frontend;
- JDK 25 and the Kotlin runner for the project DSL.
Windows uses standalone ClangCL/LLD plus Windows SDK and MSVC CRT/STL development files. macOS uses Clang/LLD plus the Apple SDK supplied by the Xcode Command Line Tools. Visual Studio and Xcode IDEs are not required.
Repository configuration does not contain a machine-specific LLVM installation path. Set LLVM_ROOT or put
llvm-config on PATH.
On a new supported machine, the Go bootstrap can report or install the host toolchain:
go run scripts/prebuild.go check
go run scripts/prebuild.go installWindows installation uses exact winget package identities, including Temurin JDK 25, plus the official GHCup bootstrap. macOS uses Homebrew and the
Xcode Command Line Tools installer. The Windows SDK/CRT workload supplies link resources only; Visual X# still selects
ClangCL and LLD. Open a new terminal after installation, then run go run scripts/develop.go doctor.
Initialize the recursive submodules first:
git submodule update --init --recursiveThe portable developer command detects the host, checks its toolchain, and keeps Bazel's private configuration names out of the normal workflow:
go run scripts/develop.go doctor
go run scripts/develop.go version 0.3.7
go run scripts/develop.go build
go run scripts/develop.go test
go run scripts/develop.go bundleThe same commands run from Terminal on macOS. Direct bazelisk build //Compiler/... remains supported and selects the host
configuration automatically; ordinary builds never need --config. The Bazel graph discovers LLVM from LLVM_ROOT or
llvm-config and does not store a machine-specific installation path.
bundle is the reproducible local path from a checkout to a usable compiler layout. It builds the C++20 vxs driver with
Bazel, builds its private Haskell vxs-frontend companion with Cabal, stages both programs under
dist/visual-xsharp-<version>-<platform>-<arch>/, and verifies that the staged pair can compile and run a real .vxs
program as a .vxse. The ignored dist/ tree also contains LICENSE.txt, PATENTS, the current Progmasoft exception and
patent-grant texts, and SHA256SUMS. See Building for the layout and
verification contract.
The compiler executable is vxs. Its C++20 command parser uses one typed schema for command scope, option arity, duplicate
rejection, defaults, and value conversion; it has no third-party CLI dependency. For .vxs, check runs the Haskell
frontend and the complete in-memory Core/CorePrep/Xpp/Xmm/LLVM validation route. build produces a native .vxse by
default; -Emit core|object|assembly|llvmll|llvmbc selects another supported artifact. run builds and executes the
native binary. Public bounded Xpp/Xmm v3 readers and writers support verified forward pipeline resumption.
CorePrep wire bytes are never accepted under the public .core extension.
vxs-frontend is an implementation companion, not a second user-facing compiler command. Current packaged layouts contain
two physical executables because the Haskell frontend is still a private process boundary. vxs locates that companion
relative to itself and remains the command users invoke.
The reliable single-file validation form is:
.\bazel-bin\Compiler\Cli\vxs.exe check -File .\path\to\Main.vxsFrom a directory containing Visual.XSharp.kts, project validation uses the configured source roots and namespace-qualified
entry directly:
.\path\to\vxs.exe check
.\path\to\vxs.exe build -Emit core
.\path\to\vxs.exe format
.\path\to\vxs.exe lintThe compiler recursively discovers case-sensitive .vxs files, applies project-relative exclusions, merges files by
declared namespace, validates every namespace, and selects the configured entry class. It does not require namespace and
directory layouts to match.
Project-wide format and lint reuse that compiler-owned source discovery. They require the separately installed Visual
Formatter and Visual Linter packages, respectively; the compiler does not embed either tool.
See CLI for the exact accepted surface and implementation status.
A Visual X# project uses one Visual.XSharp.kts file. sources.main.entry names a namespace-qualified class; its final
segment is a class name and need not be Main or Program. The selected class must provide a parameterless
public static void Main() method; a top-level runtime function is not an entry point.
The entry is resolved from namespace and type identity. It does not name a source file, and source file names or directory
layout do not have to mirror the namespace. The Kotlin runtime passes source roots and exclusions to the compiler without
walking the project for .vxs files. The Haskell frontend now owns that discovery, strict UTF-8 decoding, deterministic
ordering, exclusion matching, namespace merge, and entry validation.
project {
name = "Example"
version = "0.1.0"
stability = Stability.DEV
}
sources {
main {
srcDir = "Sources"
entry = "Example.Main"
}
}See Project files for the current Kotlin DSL.
The binary project lockfile can be inspected without changing the normal project-evaluation output. The separate vxdc
tool evaluates Visual.XSharp.kts and writes deterministic, replayable SQL to the requested output path. VXDC does not
require a particular output filename extension.
The Spec directory contains 24 topic-oriented .vxs example suites. They record current language design
intent, including valid and invalid fragments, but they are not concatenated applications and must not be treated as a claim
that every rule is already implemented by vxs.
The Visual X# EBNF summarizes the concrete syntax, while the
TextMate grammar provides matching editor token scopes for .vxs files. Semantic
restrictions remain defined by Spec/, not by syntax highlighting.
The comparative programs provide ten complete examples side by side in Visual X#, C# 13, C++20, and Java 21. The C# and Java variants are educational comparisons and do not add compiler-development prerequisites.
- Documentation index
- Architecture
- Compiler pipeline
- Implementation status
- Building
- Testing
- CLI
- Project files
- Diagnostics
- Ecosystem tools
- Specification guide
- Repository layout
- Contributing
Project-owned source files use MPL-2.0 WITH AdditionRef-Progmasoft-Exception-1.1. The exception permits static and
dynamic linking with independent components under licenses of their choice, including proprietary licenses, without
removing MPL-2.0 obligations from covered files or modifications to those files. See LICENSE.txt,
LICENSES/AdditionRef-Progmasoft-Exception-1.1.txt, PATENTS,
LICENSES/AdditionRef-Progmasoft-Patent-Grant-1.1.txt, and NOTICE.txt.