О дизайне языков

dmzlj — 12.06.2010 Немного разбора полетов, очередной дамп мыслей для их лучшей сохранности и возможности последующего восстановления, и, можно сказать, программный пост.

Если бы я разрабатывал язык сейчас, то

Синтаксис

Не стал бы заниматься разработкой синтаксиса. Синтаксис --- это синтаксический сахар, его введение сразу ко многому обязывает и фиксирует ряд предположений, уменьшая гибкость.

Плюсы:

• Отсутствие парсера. Меньше кода в компиляторе. Можно взять любой готовый разборщик s-выражений. Несмотря на простоту реализаций парсеров на парсер-генераторах, практически сразу встает проблема конфликтов и неоднозначностей, которые присутствуют в большинстве языков с синтаксисом. А потом, в случае измения и уточнения синтаксиса, решать эти неоднозначности еще много раз. В общем, наличие синтаксиса создает проблемы, решать которые приятнее намного позже, когда все остальное уже хорошо работает.
• Немного выше скорость компиляции
• Возможность естественного метапрограммирования

Минусы:

Некоторые не выносят языки со скобочками.

Несвоевременное введение синтаксиса --- было явной ошибкой целеполагания при разработке Бипа. Синтаксис не стоил потраченного на него времени, кроме того, принятые при разработке синтаксиса решения внесли некоторые неконсистентности в язык после его обкатки, исправлять которые уже не было ресурсов. Исправлять синтаксис --- дорого (лексер, парсер, типы AST, обработка AST).

Типизация

Все равно делал бы статическую типизацию, так как она необходима для генерации эффективного кода. Теперь ясно, что динамическая типизация может быть реализована достаточно дешево в плане затрат оперативной памяти, и может быть вполне приемлема (примеры есть) в случае embedded, но по-прежнему непонятно, что делать с ошибками типов на удаленном устройстве. Грамотно реализованная динамическая типизация неизбежно усложняет рантайм и повышает потенциальное количество ошибок в нем. А писать его придется все равно на Си. Ну и не улучшает производительность тоже.

Замыкания

Оправдания отсутствию замыканий --- нет. Функции высшего порядка без замыканий практически бесполезны, если нет замыканий, то и на ФВП тратить времени не стоило, можно было остановиться на унылом C-like.

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

Отсутствие замыканий --- это FAIL. Касается не только Бипа.

Continuations

Continuations необходимы. Continuations --- это возможность простой реализации обработки исключений, простой реализации конкурентности, реализации различных управляющих конструкций, возможность разработки чистого языка при желании (continuation-based IO).

Отсутствие continuations --- FAIL. Касается не только Бипа.

Рантайм: стековый или регистровый

Регистровый без вариантов:

Упрощение рантайма. Меньше манипуляций с указателями. Отсутствует понятие переполнения стека. Меньше кода, меньше работы с памятью --- меньше места для критических ошибок.

Увеличивается сложность компиляции: появляется фаза выделения регистров. В случе исполнения на виртуальной машине нам не важно количество регистров, можем сделать их достаточное количество для того, что бы вообще не делать аллокацию, а просто маппить все параметры и переменные функции на регистры (см. Lua). Если количество параметров будет превышать количество регистров, то можно выделять часть activation record в хипе, но проще сделать так, что бы компилятор предлагал автору такого кода лечить голову.

В любом случае, если стоит вопрос упрощения рантайма ценой усложнения компилятора, так и следует поступать.

Возможность оптимизации: маппинг N регистров виртуальной машины на регистры процессора. На стековой машине это сделать значительно сложнее.

Плотность кода. На первый взгляд плотность кода стековой машины выше, но этот параметр не является врожденным свойством машины. Плотность не появляется сама по себе, а получается в результате анализа и оптимизации.

Минусы

Невозможность дешевого выделения памяти, ограниченная возможность unboxed представления структур на стеке. Вероятно, лечится программными стеками. Все равно для организации многозадачности требуется много стеков.

Сборщик мусора: точный vs консервативный

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

NB:Компромиссные решения в виде размещения тэгов в словах VM, боксинг всех значений --- это FAIL (привет Эрлангу и Окамлу).

Многозадачность

Многозадачность имеет смысл, даже если у нас есть всего один медленный CPU. Это мощный способ структурирования кода, упрощения и уменьшения кода, уменьшения латентности кода (наверное, надо примеры?)

Предыдущий абзац верен для случая Erlang-style многозадачности. В случае традиционного подхода с неограниченной мутабельностью и примитивами синхронизации --- это ад.

Отсутствие многозадачности --- FAIL, тем более, что она легко реализуется в случае наличия continuations.

Прочее

Мутабельность

К сожалению, от нее не никуда не деться, но запрятать ее нужно как можно глубже и реализовать не раньше, чем действительно понадобится

Возможно, есть более простые пути ее обособления, чем монады

Мутабельность усложняет статический анализ, затрудняет разработку инкрементального GC, тормозит этот GC

Основные примитивы

Closure

Continuation

Tagged record

На них реализуется практически всё.

Abstraction/application

Ну, это почти без комментариев.

Вводить лишние абстракции для операций, например, арифметических --- смысла нет. Вопрос эффективного инлайнинга маленьких функций решается системно. Кроме того, при таком подходе мы сразу получаем эти операции как обычные первоклассные функции, что правильно. Кстати, тут я расхожусь с A. Appel, который упорно эти примитивы вводит

Пока не рассматривалось

но следует об этом подумать

• Нативная компиляция
• Оптимизирующий компилятор
• Семантика работы с raw memory (думать: ограниченный compile-time DSL, порождающий эффективные read/show функции маппинга данных на память c учетом архитектуры)
• Семантика работы с периферией (думать: compile-time маппинг на ADT)
• Статическое управление памятью (Думать: выделение всего, что возможно, на программных стеках, удаляемых с выходом из контекста. Думать: если эта возможность очевидна на этапе компиляции, то не стеков, а фиксированных областей памяти. Думать: преаллокация этих областей)
• Гарантии (возможность применений для задач реального времени) (думать: компиляция в FSM, преаллокация, запрещение GC)
• Метрики

Резюме

Структура языка:

(синтаксисы [опционально])
      => (типизированная лямбда)
      => (метапрограммы)
      => (нормализованная типизированная лямбда) 
      => (кодогенераторы)

Совсем короткое резюме: статически-типизированный scheme-like язык. Думаю, применение описанного подхода сдует размер кода рантайма и компилятора раза в два --- два с половиной по отношению к текущей реализации Бипа, при этом сильно увеличив возможности.

Оставить комментарий

Популярные посты:

• Ранее
• Архив