Доклад, прочитанный мной в декабре 2021 года на Открытой конференции ИСП РАН им. В.П. Иванникова:
Разработка типовой системы языка программирования приложений
7 комментариев
Добавить комментарий для AN Отменить ответ
Следующая запись: Статья Д. Соломенникова «Импортозамещай это»
Постоянная ссылка
Алексей, привет. Мне кажется, из рассмотрения незаслуженно выпали весьма примечательные конструкторы ограниченных строк из TypeScript. И с моей точки зрения это частный случай более общей группы — конструкторы-через-ограничение.
Возможно, это будет чем-то пересекаться с навороченными системами зависимых типов как в Idris, мне это не вполне ясно пока.
Но кажется, что это может быть самостоятельным (ортогональным) и весьма мощным механизмом, если в рамках некоторого базового типа (который сам по себе может быть сложным как struct) мы можем дополнительно задать инвариант, определяющий подмножество значений, и это подмножество будет соответствовать некоторому новому типу.
Возможно, это скорее к runtime-проверкам, и может/должно реализовываться на других конструкторах (например, struct + функции-конструкторы и неявные функции приведения), и тогда это может и не будет ортогональным механизмом, но мне казалось, что в TypeScript смогли что-то полезное для типов шаблонных строк вытащить на уровень статической компилияции.
Постоянная ссылка
Спасибо за идею.
В моем понимании, надо сначала определить базовую систему типов, которая является общей основой для семейства языков, а потом думать про частные добавления, например, зависимые типы, которые могут быть только в одном языке семейства.
Постоянная ссылка
Нечего не скажу про Котлин и Свифт (не знаю, а про Го вполне определённо могу сказать, что интерфейсы разрешает встраивание (причём множественное), и на текущий момент — дженерики подвезли. Увы, но поверку оказалось, что работают они медленнее, задачу map не решают, сложность отладки растёт. Что касается структур, то общий подход, если мне память не отшибло: множественное наследование нужно избегать в пользу композиции. Собственно, удовлетворение требованиям абстракций в Го архитектурно именно эту проблему и решает.
Постоянная ссылка
про компонентный асемблер и остальные Ваши статьи — чувствую мышление, прокомпостированное Java и жёстко-типизованными языками
Попишите на Elixir (под платформу Erlang/BEAM/OTP) — может что-то поменяется в установках, особенно про необходимость применения машинного вместо байткода (с потерей контроля над выполнением программ), и про построение системы из множества независимых процессов, с асинхронным обменом сообщениями, и динамической связкой между компонентами в рантайме
Постоянная ссылка
Это хороший наезд. На него стоит ответить. Читайте http://алексейнедоря.рф/?p=412
Постоянная ссылка
«Жёсткая типизация» — нет такого термина. Машинный код — далеко не всегда потеря контроля. По крайней мере, все массовые процессоры поддерживают защиту памяти. Го способен на моей домашней машине поддерживать в рамках одного процесса 1 миллион потоков и всё вполне работает. Любая система, активно работающая с памятью по определению является динамической.
Постоянная ссылка