πͺ QAIL β The Horizontal Query Language
Stop writing strings. Hook your data.
The Manifesto
SQL is vertical, verbose, and clunky inside modern codebases.
QAIL is horizontal, dense, and composable. It treats database queries like a pipeline, using symbols to hook data and pull it into your application.
-- The Old Way (SQL)
SELECT id, email, role FROM users WHERE active = true LIMIT 1;
# The QAIL Way
get::usersβ’@id@email@role[active=true][lim=1]
One line. Zero ceremony. Maximum velocity.
The Philosophy
- Constraint: Vertical space is precious. SQL blocks interrupt the flow of code reading. QAIL flows with your logic.
- Density: Symbols (
@,β’,[]) convey more information per pixel than keywords (SELECT,FROM,WHERE). - The Star Rule: If you need 50 columns, fetch the struct (
@*). If you need 3, list them. Listing 20 columns manually is an anti-pattern. QAIL encourages "all or nothing" density.
Is it still Horizontal? Yes. The language itself is horizontal because it uses symbols instead of keywords. But we give you the Vertical Escape Hatch (tabs/newlines) so you can organize complex logic however you see fit, without fighting the parser. Horizontal is the identity; Vertical is the layout.
π Quick Reference
| Symbol | Name | Function | SQL Equivalent |
|---|---|---|---|
:: |
The Gate | Defines the action | SELECT, INSERT, UPDATE |
β’ |
The Pivot | Connects action to table | FROM table |
@ |
The Hook | Selects specific columns | col1, col2 |
[] |
The Cage | Constraints & Filters | WHERE, LIMIT, SET |
~ |
The Fuse | Fuzzy / Partial Match | ILIKE '%val%' |
| |
The Split | Logical OR | OR |
& |
The Bind | Logical AND | AND |
^! |
The Peak | Sort Descending | ORDER BY ... DESC |
^ |
The Rise | Sort Ascending | ORDER BY ... ASC |
* |
The Star | All / Wildcard | * |
[*] |
The Deep | Array Unnest | UNNEST(arr) |
$ |
The Var | Parameter Injection | $1, $2 |
π Installation
CLI (Recommended)
As a Library
# Cargo.toml
[]
= "0.1"
π‘ Usage
CLI β The qail Command
# Fetch all users
# Get specific columns with filter
# Update a record
# Delete with condition
# Transpile only (don't execute)
As a Library
use *;
async
π Syntax Deep Dive
A. Simple Fetch (get::)
-- SQL
SELECT id, email, role FROM users WHERE active = true LIMIT 1;
# QAIL
get::usersβ’@id@email@role[active=true][lim=1]
B. Mutation (set::)
-- SQL
UPDATE user_verifications SET consumed_at = now WHERE id = $1;
# QAIL
set::user_verificationsβ’[consumed_at=now][id=]
Note: In
set::mode, the first[]is the payload (SET), the second[]is the filter (WHERE).
C. Deletion (del::)
-- SQL
DELETE FROM sessions WHERE expired_at < now;
# QAIL
D. Complex Search with Fuzzy Match
-- SQL
SELECT * FROM ai_knowledge_base
WHERE active = true
AND (topic ILIKE $1 OR question ILIKE $1 OR EXISTS (SELECT 1 FROM unnest(keywords) k WHERE k ILIKE $1))
ORDER BY created_at DESC
LIMIT 5;
# QAIL
get::ai_knowledge_baseβ’@*[active=true][topic~|question~|keywords[*]~$1][^!created_at][lim=5]
# Or multi-line for readability:
[active=true]
| |
[lim=5]
E. Joins (Coming Soon)
# Inner join
get::ordersβ’@*>>users.id=orders.user_idβ’@users.email[status=paid]
# Left join
get::productsβ’@*>|categories.id=products.cat_idβ’@categories.name
βοΈ Configuration
Create a .qailrc or qail.toml in your project root:
[]
= "postgres" # postgres | mysql | sqlite
= "postgres://localhost/mydb"
[]
= "table" # table | json | csv
= true
[]
= true # Prompt before UPDATE/DELETE
= false
ποΈ Architecture
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β QAIL Pipeline β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
β "get::usersβ’@*[active=true]" β
β β β
β βΌ β
β βββββββββββββββββββββββ β
β β Parser (nom) β β Tokenize symbols β
β βββββββββββ¬ββββββββββββ β
β β β
β βΌ β
β βββββββββββββββββββββββ β
β β AST (QailCmd) β β Structured representation β
β βββββββββββ¬ββββββββββββ β
β β β
β βΌ β
β βββββββββββββββββββββββ β
β β Transpiler (SQL) β β Generate valid SQL β
β βββββββββββ¬ββββββββββββ β
β β β
β βΌ β
β βββββββββββββββββββββββ β
β β Engine (sqlx) β β Execute against DB β
β βββββββββββββββββββββββ β
β β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Core Structs
πΊοΈ Roadmap
Phase 1: Parser β
- Lexer for QAIL symbols
-
nomparser combinators - AST generation
Phase 2: Transpiler π§
- PostgreSQL codegen
- MySQL codegen
- SQLite codegen
- Query optimization hints
Phase 3: Engine π
- Async execution (sqlx)
- Connection pooling
- Transaction support
- Prepared statement caching
Phase 4: Ecosystem π
- VS Code extension (syntax highlighting)
- Language server (LSP)
- REPL mode
- Schema introspection
E. The Flagship Comparison (Complex Joins)
Scenario: Find verified users who joined after 2024 and booked under the 'SUMMER' campaign.
-- SQL (7 lines, cognitive load high)
SELECT u.*
FROM users u
JOIN bookings b ON b.user_id = u.id
WHERE u.created_at >= '2024-01-01'
AND u.email_verified = true
AND b.campaign_code ILIKE '%SUMMER%'
ORDER BY u.created_at DESC
LIMIT 50;
# QAIL (1 line, cognitive load low)
get::users->bookingsβ’@*[created_at>='2024-01-01'][email_verified=true][bookings.campaign_code'SUMMER'][^!created_at][lim=50]
π€ Contributing
We welcome contributions! Please see CONTRIBUTING.md for guidelines.
# Clone the repo
# Run tests
# Run with example
π License
MIT Β© 2025 QAIL Contributors