Дизайн-документ YaoXiang

Дао рождает единое, единое рождает двойственное, двойственное рождает тройственное, тройственное рождает все сущее.

Данный каталог содержит дизайн-решения, предложения и обсуждения языка программирования YaoXiang.

Основные дизайн-концепции

Концепция	Описание
Всё есть тип	Значения, функции, модули — всё это типы; типы — полноправные граждане первого класса
Естественный синтаксис	Читаемость как у Python, близость к естественному языку
Модель ownership	Абстракции с нулевой стоимостью, без GC, высокая производительность
Модель spawn	Синхронный синтаксис, асинхронная сущность, автоматический параллелизм
AI-дружественность	Строгая структурированность, чёткий AST

Структура дизайн-документов

design/
├── index.md              # Данный индекс
├── deprecated/           # Устарело (заменено новым дизайном)
│   └── *.md
├── rejected/             # Отклонено
│   └── *.md
├── rfc/
│   ├── draft/            # Черновики (работа в процессе)
│   ├── review/           # На рассмотрении (открытое обсуждение)
│   ├── accepted/         # Принято (дизайн одобрен)
│   ├── deprecated/       # Устарело (заменено)
│   └── rejected/         # Отклонено (не одобрено)
└── discussion/           # Зона дизайн-обсуждений (открытое обсуждение)
    └── *.md

Принятые дизайн-предложения

Документ	Статус	Описание
RFC-010 Унифицированный синтаксис типов	✅ Принято	Унификация синтаксиса определения типов
RFC-011 Система generics	✅ Принято	Дизайн системы generics
RFC-009 Модель ownership	✅ Принято	Дизайн системы ownership и заимствования
RFC-024 Модель concurrency	✅ Принято	Семантика spawn-примитивов
RFC-027 Compile-time утверждения	✅ Принято	Compile-time предикаты и статическая верификация

Смотрите каталог rfc/accepted/ для полного списка (всего 16), а также rfc/index.md для актуального состояния.

Предложения RFC

RFC (Request for Comments) — это процесс предложения новых возможностей и крупных изменений.

Активные предложения

Номер	Название	Статус
RFC-019	Типизированная гомоиконичность	Черновик
RFC-028	JIT-компилятор	Черновик
RFC-029	Система семантики модулей	Черновик
RFC-031	Уровни оптимизации	Черновик
RFC-033	Оператор рефлексии ^^	Черновик
RFC-034	Инструменты отладки	Черновик
RFC-035	MCP Server	Черновик
RFC-002	Кроссплатформенный IO (libuv)	Черновик
RFC-026b	yx-bindgen	Черновик
RFC-011a	Реализация интерфейсов и динамическая диспетчеризация	На рассмотрении
RFC-014a	Протокол Registry	На рассмотрении
RFC-014b	Система сборки	На рассмотрении
RFC-014c	Рабочее пространство	На рассмотрении
RFC-026a	Расширяемый FFI	На рассмотрении
RFC-032	Унифицированное выражение spawn	На рассмотрении

Принятые предложения

Номер	Название	Статус
RFC-004	Каррированное многопозиционное связывание	Принято
RFC-006	Оптимизация сайта документации	Принято
RFC-007	Унификация синтаксиса функций	Принято
RFC-008	Модель runtime concurrency	Принято
RFC-009	Модель ownership	Принято
RFC-009a	Анализ времени жизни токенов	Принято
RFC-010	Унифицированный синтаксис типов	Принято
RFC-011	Система generics	Принято
RFC-012	f-string	Принято
RFC-013	Спецификация кодов ошибок	Принято
RFC-014	Менеджер пакетов	Принято
RFC-015	Система конфигурации	Принято
RFC-017	Поддержка LSP	Принято
RFC-018	AOT-компилятор на LLVM	Принято
RFC-024	Модель concurrency	Принято
RFC-026	Базовый механизм FFI	Принято
RFC-027	Compile-time утверждения	Принято
RFC-030	Механизм assert-утверждений	Принято

Отклонённые предложения

Номер	Название	Статус
RFC-003	Планирование версий	Отклонено
RFC-005	Сканирование CVE	Отклонено
RFC-016	Нативная поддержка квантовых вычислений	Отклонено
RFC-025	Расширение примитивных типов	Отклонено

Шаблоны RFC

Перед подачей нового предложения обратитесь к:

• RFC_TEMPLATE.md
• Полный пример

Участие в дизайн-обсуждениях

Жизненный цикл RFC

Предложения RFC имеют 5 состояний:

Статус	Значение
Черновик	Работа в процессе
На рассмотрении	Открытое обсуждение
Принято	Дизайн одобрен
Устарело	Было принято, заменено новым дизайном
Отклонено	Не одобрено

Полный жизненный цикл:

Черновик → На рассмотрении → Принято → Устарело (заменено)
                                  ↓
                              Отклонено (не одобрено)

Процесс предложения

1. Составление предложения (используя шаблон RFC)
   → Помещается в rfc/draft/

2. Отправка на рассмотрение
   → Перемещается в rfc/review/, открытое обсуждение сообщества

3. Рассмотрение основной командой
   → Принято → Перемещается в rfc/accepted/
   → Отклонено → Перемещается в rfc/rejected/

4. Последующее сопровождение
   → Заменено → Перемещается в rfc/deprecated/

Принципы дизайна

• Чёткие границы: каждое дизайн-решение должно иметь чёткую область применения
• Практичность прежде всего: решать реальные проблемы, а не воображаемые угрозы
• Поведение, наблюдаемое пользователем, не меняется: Never break userspace

Примеры кода

// Определение типа
Point: Type = { x: Float, y: Float }
Result: (T: Type, E: Type) -> Type = { ok: (T) -> Result(T, E), err: (E) -> Result(T, E) }

// Определение функции
add: (a: Int, b: Int) -> Int = a + b

// Главная функция
main: () -> Void = {
    print("Hello, YaoXiang!")
}

Ключевые дизайн-решения

1. Система типов

• Унифицированный синтаксис типов: упразднение enum, struct, union, единообразное использование Name: Type = {...}
• Конструктор — это тип: устранение разрыва между «типом» и «значением»
• Поддержка generics: мономорфизация на этапе компиляции, нулевые накладные расходы в runtime

2. Модель spawn

// Модель spawn: по умолчанию последовательное выполнение, spawn вводит параллелизм потоков данных

// Последовательное выполнение по умолчанию
compute: (Int) -> Int = (n) => {
    a = heavy_calc(1)
    b = heavy_calc(2)  // Последовательно, ожидает завершения a
    c = heavy_calc(3)  // Последовательно, ожидает завершения b
    a + b + c
}

// spawn-блок вводит параллелизм потоков данных
process: () -> Void = () => {
    spawn {
        users = fetch_users()   // параллельно
        posts = fetch_posts()   // параллельно
    }
    // Вызывающая сторона синхронно блокируется в ожидании результата
    render(users, posts)
}

3. Обработка ошибок

Result: (T: Type, E: Type) -> Type = { ok: (T) -> Result(T, E), err: (E) -> Result(T, E) }

process: () -> Result(Data, Error) = {
    data = fetch_data()?      // Оператор ? обеспечивает прозрачное распространение
    transformed = transform(data)?
    save(transformed)?
}

Связанные ресурсы

• Учебные материалы — изучение YaoXiang
• Справочная документация — API и стандартная библиотека
• Спецификация языка — полная спецификация языка
• GitHub Discussions
• Руководство по участию

Исторический архив

Исторические документы из процесса проектирования перенесены в каталог docs/old/, включая:

• Ранние архитектурные дизайны
• Устаревшие предложения
• Нерелевантные планы реализации