Зависимые типы позволяют создавать более точные типы, которые могут зависеть от значений, но их обработка компиляторами различается. В отличие от обычных типов, которые полностью стираются во время компиляции, зависимые типы могут частично сохраняться в исполняемом коде. Это влияет на производительность и возможности оптимизации.

Исследования показывают, что некоторые языки с зависимыми типами, такие как Idris, сохраняют часть информации о типах во время выполнения. Это позволяет выполнять проверки типов во время выполнения, открывая новые возможности для метапрограммирования и рефлексии. Однако такая сохранение типов увеличивает размер исполняемых файлов и может снижать производительность.

• Обсуждение показало, что зависимые типы (dependent types) — это не только академическая концепция, но и практически применимы в языках вроде Zig и TypeScript, хотя с ограничениями.
• Участники обсуждали, что в TypeScript условные типы и в Zig comptime демонстрируют схожие с зависимыми типами идеи, но не покрывают полный спектр возможностей зависимых типов.
• Были подняты вопросы о том, что такое "зависимые типы" и как они отличаются от обычных обобщённых типов, с упором на то, что в большинстве языков нет полной поддержки зависимых типов.
• Обсуждались примеры, где тип возвращаемого значения может зависеть от входного значения, и как это может быть реализовано в разных языках.
• Также обсуждались границы между статическим и динамическим анализом типов, и как они влияют на возможность компилятора вычислять и оптимизировать код.

Lua_u_

Lua_u_ (строчная u, /ˈlu.aʊ/) — это быстрый, компактный, безопасный, постепенно типизированный встраиваемый язык сценариев, основанный на Lua.

Мотивация

Примерно в 2006 году Roblox начал использовать Lua 5.1 в качестве языка сценариев для игр. Со временем мы значительно развили реализацию и язык: для поддержки растущей сложности игр на платформе Roblox, увеличения размеров команд и написания большого объёма кода (более 1 млн строк к 2020 году) нам пришлось инвестировать в производительность, удобство использования, инструменты языка и ввести постепенную систему типов. Подробнее…

Песочница

Luau ограничивает набор стандартных библиотек, доступных пользователям, и реализует дополнительные функции песочницы для возможности запуска непривилегированного кода (написанного разработчиками игр) вместе с привилегированным кодом (нашим). Это создаёт среду выполнения, отличающуюся от традиционной для Lua. Подробнее…

Совместимость

По возможности Luau стремится быть обратно совместимым с Lua 5.1 и одновременно включает функции из более поздних версий Lua. Однако Luau не является полным надмножеством более поздних версий Lua — мы не всегда согласны с решениями Lua и имеем другие варианты использования и ограничения. Все функции Lua после 5.1, а также их статус поддержки в Luau, документированы здесь.

Синтаксис

Luau синтаксически обратно совместим с Lua 5.1 (код, действительный для Lua 5.1, также действителен для Luau); однако мы расширили язык набором синтаксических функций, делающих его более привычным и эргономичным. Синтаксис описан здесь.

Анализ

Для упрощения написания корректного кода Luau включает набор инструментов анализа, которые могут выявлять распространённые ошибки. Они состоят из линтера и проверки типов, интегрированных в исполняемый файл командной строки luau-analyze. Проверки линтера описаны здесь, а руководство по проверке типов можно найти здесь.

Производительность

В дополнение к полностью кастомному фронтенду, реализующему парсинг, линтинг и проверку типов, среда выполнения Luau включает новый байткод, интерпретатор и компилятор, сильно оптимизированные для производительности. Интерпретатор Luau может конкурировать с интерпретатором LuaJIT в зависимости от программы. Также доступен опциональный компонент для ручной JIT-компиляции на платформах x64 и arm64, который может значительно ускорить определённые программы. Мы продолжаем оптимизировать среду выполнения и переписывать её части для ещё большей эффективности. Хотя наша общая цель — минимизировать время, которое программисты тратят на настройку производительности, некоторые детали о характеристиках производительности предоставлены для любознательных.

Библиотеки

Как язык Luau является полным надмножеством Lua 5.1. Что касается стандартной библиотеки, некоторые функции пришлось удалить из встроенных библиотек, а некоторые — добавить; обратитесь к полной документации для подробностей. Когда Luau встраивается в приложение, сценарии обычно получают доступ к дополнительным функциям библиотек, специфичным для приложения.

© 2025 Roblox.

• Переход на Luau обусловлен системой типов, но язык имеет шероховатости и слабую документацию, а сообщество практически отсутствует.
• Luau значительно сложнее и объёмнее стандартного Lua, что связано с реализацией системы типов и дополнительных возможностей.
• Существуют альтернативные реализации и среды выполнения Luau, такие как Lune, предназначенные для использования вне Roblox.
• Сообщество отмечает проблемы обратной совместимости между различными форками Lua (LuaJIT, Luau, PUC Lua), что создаёт фрагментацию.
• Luau сравнивают с Teal, но они fundamentally разные: Teal — это транспилятор, а Luau — полноценный форк Lua с собственной средой выполнения.
• Разработчики Roblox работают над улучшением поддержки Luau вне своей платформы, включая создание standalone-рантаймов.
• Несмотря на критику, инженерные решения в Luau, особенно в области производительности, оцениваются как впечатляющие.

Типы — это небеса

В CL тип — это множество, и каждый объект принадлежит хотя бы одному.
(type-of 37) → (INTEGER 0 …)
(type-of "漣") → (SIMPLE-ARRAY CHARACTER (1))

(typep 37 'integer) → T, аналогично 'real, 'number, t.
Типы не образуют строгую иерархию: строка всегда string, но не обязательно simple-array.

Типы для корректности

(defun f (n) (+ n "漣")) — компилятор жалуется: "漣" не NUMBER.
(defstruct sky (molecules 0 :type integer))
(make-sky :molecules 1.1) — ошибка типа.
То же для длины массива: (simple-array character (17)) отвергнет строку из 18 символов.

Типы для оптимизации

Подсказки помогают компилятору.
(defun add (n) (+ n 37)) без аннотаций → общий код.
Добавим (declare (type fixnum n)) — генерируется короткая машинная инструкция LEA.

Классы — это земля

Классы реальны: (defclass point () ((x :initarg :x) (y :initarg :y))).
Наследование и множественный диспатч generic-функций работают как в CLOS.

Сердце машины

• «Абстрактные» классы — просто не создают экземпляров.
• fixnum — самый быстрый целый, в SBCL 61 бит (63 на 64-битных).
  (type-of 4611686018427387904) → (INTEGER 4611686018427387904) — уже bignum.

Итог

CL даёт строгие типы без потери гибкости: проверки на этапе компиляции и выполнения, оптимизация, но возможность менять код в REPL.

• Участники согласились, что статья преувеличивает гарантии статической проверки типов в Common Lisp: SBCL даёт лишь «вежливые» предупреждения, а стандарт вообще не требует обязательной проверки.
• Обсуждали «квирки» иерархии типов: отношения между string, simple-array и vector уточняли через subtypep и typep; выяснилось, что они связаны отношениями подтипов.
• Отметили особенность «апгрейда» типов элементов массивов: итоговый тип всегда супертип заявленного, причём сохраняются отношения подтипов.
• Вспомнили специальную форму the, которая служит как для оптимизации, так и для runtime-assert’ов, но не даёт жёстких гарантий.
• Пошутили о том, что массив с элементами типа NIL формально считается строкой, поскольку NIL — подтип любого типа, включая CHARACTER.

Python 3.10 добавил сопоставление с образцом, которое использует isinstance.
ABC с __subclasshook__ могут подменять проверку типа, поэтому:

class NotIterable(ABC):
    @classmethod
    def __subclasshook__(cls, C):
        return not hasattr(C, "__iter__")

match x:
    case NotIterable(): ...

работает — 10 считается NotIterable, строки и списки — нет.

Аналогично можно «матчить» по наличию атрибутов:

class DistanceMetric(ABC):
    @classmethod
    def __subclasshook__(cls, C):
        return hasattr(C, "distance")

и деструктурировать:

match x:
    case DistanceMetric(distance=d): ...

Динамически создаём комбинаторы:

def Not(cls):
    class _Not(ABC):
        @classmethod
        def __subclasshook__(_, C):
            return not issubclass(C, cls)
    return _Not

n = Not(DistanceMetric)
match x:
    case n(): ...

Синтаксис не позволяет писать Not(DistanceMetric)() прямо в case, но сохранив сгенерированный ABC в переменную, обходим ограничение.

• btown показал «трюк» с rrshift, позволяющий делать цепочки вида x >> f >> g без изменения левой части.
• Большинство участников критикуют реализацию pattern matching: неочевидное поведение имен-констант, лишняя сложность, отсутствие общих константных паттернов.
• Некоторые считают match-case полезным для структурной проверки типов, но просят линтеры/semgrep-правила, чтобы запретить его в кодовой базе.
• Обсуждаются и другие «преступления»: предложение {/} для пустого множества, метаклассы, меняющие isinstance, и «goto-подобная» неявность.

Кратко:
PHP-фонд предлагает реализовать только компиляторные обобщения (generics) для интерфейсов и абстрактных классов.
Синтаксис:

interface Repository<Item> {
    public function find(int $id): Item;
}

class UserRepo implements Repository<User> { … }

• Все проверки типов происходят на этапе компиляции.
• Ошибки ловятся до запуска кода.
• new Repository<User>() по-прежнему невозможно, но и не усложняется.

Почему не полные обобщения?
Полноценные runtime-generics требуют сложного вывода типов и резко замедляют работу, особенно при объединённых типах и массивах.

Откуда идея?

• 2023-2024: эксперименты Arnaud Le Blanc показали, что 80 % пользы можно получить без 80 % сложностей.
• 2025: Gina Banyard разрабатывала «ассоциированные типы» и поняла, что их легко переформулировать как ограниченные обобщения.

Вопрос сообществу:
Поддержите ли вы такой вариант и проголосуете ли «за»?

• В обсуждении разбираются плюсы и минусы добавления дженериков в PHP.
• Участники спорят, не приведёт ли это к «размагничиванию» типов, и объясняют разницу между reified (типы сохраняются в рантайме, как в C#) и erased (типы стираются, как в Java) дженериками.
• Поднимается вопрос: почему class Repo<T> {} труднее реализовать, чем class BlogPostRepo extends BaseRepo<BlogPost> {}.
• Многие разработчики просят хотя бы строго типизированные массивы, считая их более полезными, чем полноценные дженерики.
• Часть команды уже использует PHPStan и strict_types, считая этого достаточным без изменений ядра языка.