Мотивация
Модульный Рефал имеет встроенный механизм инкапсуляции данных — так называемые «абстрактные типы данных», АТД. Модуль может определить несколько «тегов типа» — имён АТД, которыми может помечать некоторые скобочные термы (собственно, АТД-термы). Непосредственный доступ к содержимому АДТ-термов возможен только в функциях модуля, в котором определены метки. Другие модули могут манипулировать с АТД-термами, либо импортируя модуль, где они определены и вызывая его entry-функции, либо вызывая функции-callback’и того модуля.
Механизм АТД решает свою задачу: предотвращает доступ извне к содержимому, но при этом налагает жёсткое ограничение: либо нужно импортировать модуль, либо передавать callback, либо доступа вообще нет. Таким образом, возникают затруднения при написании некоторых универсальных служб (служб, которые могут работать с любыми объектными выражениями): сортировка, преобразование к строке, сериализация.
Другое ограничение АТД (в широком смысле) в модульных языках (Модульный Рефал, Модула-2) — необходимость прямого или косвенного импорта модуля, реализующего тип данных в модулях, использующих экземпляры этого типа. В результате возникает слишком жёсткая связь между отдельными компонентами (например, в синтаксическом анализаторе захардкожена ссылка на лексический анализатор).
Решение обеих проблем хорошо известно: разделение типа и интерфейса. Первая проблема решается тем, что универсальные службы предлагают интерфейс (например, ToString), который должны реализовать все типы, совместимые со службой. Вторая проблема решается тем, что клиенты зависят только от описания интерфейса, экземпляр типа, реализующий требуемый интерфейс, передаётся в клиенты методами верхнего уровня.
Предлагаемое решение
Концепция
В Модульном Рефале единица инкапсуляции — модуль. Это свойство разумно сохранить. Модульный Рефал — функциональный язык, поэтому интерфейс опишем как набор переопределяемых функций. Как-то так.
Некоторые модули предоставляют виртуальные функции, набор этих функций формирует некоторый интерфейс. Другие модули импортируют модули с виртуальными функциями и расширяют последние дополнительными предложениями, обрабатывающими АТД, реализованные в данном модуле. После чего можно вызывать виртуальные функции, передавая в них экземпляры АТД, для которых эти функции расширены. Виртуальные функции (они всегда экспортируются, пишем $VIRTUAL, подразумеваем $ENTRY) могут вызываться как из модулей, где они определены, так и из модулей, которые импортируют модули с виртуальными функциями. При этом последние ничего не знают о модулях, которые расширяют виртуальные функции.
Синтаксис
Виртуальная функция помечается ключевым словом $VIRTUAL и имеет одно и только одно виртуальное предложение. Виртуальное предложение состоит из одного образца (для краткости далее виртуального образца), который (а) может быть только жёстким образцом (без повторных переменных и открытых e-переменных), (б) должен содержать хотя бы один терм вида $DATA — признак виртуального предложения. Перед и после виртуального предложения могут располагаться обычные предложения с обычной семантикой.
Расширение виртуальной функции может располагаться только в модуле, который импортирует модуль, определяющий виртуальную функцию. Расширение виртуальной функции записывается как функция, помеченная ключевым словом $EXTENDS и имеющая имя ИмяМодуля.ИмяВиртуальнойФункции, где ИмяМодуля — имя модуля, где виртуальная функция определена. При этом в модуле не может дважды переопределяться одна и та же виртуальная функция. Каждое предложения расширения должно уточнять виртуальный образец, при этом на месте терма $DATA должен располагаться АТД-терм. Соответствие образцовых частей расширения виртуальному образцу должно контролироваться на стадии компиляции.
Расширение виртуальной функции самостоятельной функцией не является, предложения, перечисленные в теле функции, можно вызвать только вызывав виртуальную функцию. Соответственно, ключевое слово $ENTRY к расширению не применимо ибо бессмысленно.
Семантика
Примечание. Здесь описывается идеализированная модель, реализация может (и будет) отличаться, но её поведение должно совпадать с идеализированной моделью.
После компиляции и компоновки формируется единая программа, в которой каждая виртуальная функция превращается в обычную функцию, в которой на месте виртуального предложения располагаются предложения всех расширений этой виртуальной функции. При этом относительный порядок предложений, описанных в расширении сохраняется, но относительный порядок предложений различных расширений не определён, ибо не важен (см. ниже).
Следовательно, исполнение виртуальной функции идёт в следующем порядке:
- Сопоставления с образцами предложений, расположенных до виртуального предложения. Если одно из них оказалось успешным, выполняется соответствующее предложение, виртуальная функция на этом завершается.
- Сопоставление аргумента с каждым из образцов расширений функции. Все эти образцы, уточняя виртуальный образец, различаются тегами АТД в позициях термов
$DATA. В модуле, расширяющем виртуальную функцию, могут использоваться только теги данных, которые в нём определены, поэтому образцы предложений различных модулей не конфликтуют между собой. Если одно из сопоставлений завершилось успешно, выполняется соответствующее предложение расширения и виртуальная функция завершается.
- Сопоставление с образцами предложений, расположенных после виртуального предложения. Тут всё аналогично п. 1.
- Если не было успешного сопоставления, функция падает с ошибкой.
Пара слов о синтаксисе
- Ключевые слова
$VIRTUAL и $EXTENDS избыточны: виртуальную функцию можно узнать по наличию виртуального предложения, расширение — по квалифицированному имени. Однако, добавление этих ключевых слов повышает ясность и читабельность программы.
- Возможное расширение синтаксиса:
[$ENTRY] ИмяФункции $EXTENDS Модуль.ВиртуальнаяФункция — создаёт как обычную функцию (с именем ИмяФункции), так и расширение Модуль.ВиртуальнаяФункция с идентичным набором предложений.
Реализация
Back-end C++/SR
Непосредственная реализация семантики затруднена: модули транслируются независимо в исходные файлы на C++, которые затем уже транслируются компилятором C++. Поэтому будем действовать иначе.
Допустим, выполнение виртуальной функции дошло до виртуального предложения. Сопоставим аргумент с виртуальным образцом — допустим, оно прошло успешно, каждый из символов $DATA наложился на АТД-терм. Возьмём, к примеру, первое вхождение символа $DATA — зная тип АТД, мы можем узнать модуль, в котором он переопределён, и попытаться в этом модуле найти расширение виртуальной функции. Расширение нашли — можем попробовать сопоставить аргумент с каждой из левых частей предложений расширения. Если одно из предложений расширения выполнилось, то виртуальная функция на этом завершается, иначе происходит переход на предложения, следующие за виртуальным. Заметим, что другие расширения виртуальной функции проверять не нужно — они не могут содержать на месте $DATA чужой АТД.
Очевидно, что путь поиска расширения избыточен: из цепочки тег АТД → модуль → расширение можно выкинуть модуль, храня в теге непосредственно расширения для разных АТД, причём только те предложения из расширений, которые относятся к данному типу.
На данный момент тег типа для АТД представляет собой пустую функцию, поскольку его роль — только отличать друг от друга разные АТД. Поэтому его можно пополнить новой информацией, новым поведением без конфликтов с имеющимся кодом.
Виртуальная функция при компиляции представляется в виде пары: префикс — функция, состоящая из предложений по виртуальное включительно и суффикс — функция, состоящая из предложений, которые следуют за виртуальным. Суффикс может быть и пустой функцией. Для примера, пусть у нас компилируется функция Модуль.Гладить — имя префикса будет совпадать с именем функции, имя суффикса будет иметь вид Модуль.Гладить%суф. (Реализация может давать любое имя, как угодно декорированное, такое, что пользователь не сможет его перекрыть). Модуль:
$MODULE Модуль;
$VIRTUAL Гладить {
Обычное = Предложение;
Виртуальное $DATA;
Предложение = Суффикса;
}
$END Модуль.
будет компилироваться во что-то вроде:
$MODULE Модуль;
$ENTRY Гладить {
Обычное = Предложение;
Виртуальное [s.Tag e.Info] = <s.Tag &Гладить%суф Виртуальное [s.Tag e.Info]>;
}
$ENTRY Гладить%суф {
Предложение = Суффикса;
}
$END Модуль.
Здесь используется синтаксически невозможная [s.Tag e.Info], которая позволяет извлечь тег типа из АТД для осуществления косвенного вызова. Тег АТД является функцией, которая принимает указатель на суффикс и исходный аргумент, причём указатель на суффикс играет две роли: во-первых, служит тегом виртуальной функции, во-вторых, на него передаётся управление в случае невозможности сопоставления. На примере модуля-клиента всё будет понятно.
$MODULE Клиент;
$IMPORT Модуль;
$IMPORT Format;
$DATA Кот, Утюг, НеКласс;
$EXTENDS Модуль.Гладить {
Виртуальное [Кот e.Кот] = Гладим кота;
Виртуальное [Утюг e.Утюг] = Гладим бельё;
}
$EXTENDS Format.ToString {
[Кот e.Кот] = 'Кота зовут ' e.Кот;
[Утюг e.Утюг] = 'Утюг марки ' e.Утюг;
}
$END Клиент.
компилируется в
$MODULE Клиент;
$IMPORT Модуль;
$IMPORT Format;
Кот {
& Модуль.Гладить%суф Виртуальное [Кот e.Кот] = Гладим кота;
& Format.ToString%суф [Кот e.Кот] = 'Кота зовут ' e.Кот;
s.Suf e.Arg = <s.Suf e.Arg>;
}
Утюг {
& Модуль.Гладить%суф Виртуальное [Утюг e.Утюг] = Гладим бельё;
& Format.ToString%суф [Утюг e.Утюг] = 'Утюг марки ' e.Утюг;
s.Suf e.Arg = <s.Suf e.Arg>;
}
НеКласс {
s.Suf e.Arg = <s.Suf e.Arg>;
}
$END Клиент.
Теги типов становятся уже таблицами виртуальных функций. Последнее предложение каждой виртуальной функции служит для передачи управления на суффикс, АТД, для которых расширения не определены, состоят только из одного такого предложения.
Back-end Простого Рефала
Реализуется аналогично back-end’у C++/SR с той лишь разницей, что конструкция [s.Tag e.Info] синтаксически недопустима, а значит, нужно идти в обход.
АТД, не участвующие в каком-либо расширении виртуальных функций, описываются как и раньше — пустая функция для тега и [Tag e.Info] для АТД-термов. Для типов, участвующих в расширении виртуальных функций тег описывается также, как и для предыдущего back-end’а, а терм — [Class Tag [Tag e.Info]] — таким образом, (а) по-прежнему обеспечивается инкапсуляция, но при этом есть доступ к тегу типа. Тег Class глобален на всю программу, объявляется в файле .main.sref как $EENUM.
Виртуальные предложения ожидают, что типы данных имеют вид [Class Tag [Tag e.Info]], поэтому при передаче в них АТД, не участвующих в расширениях виртуальных функций, выполнение сразу передаётся на суффикс. Пример выше может быть откомпилирован так:
$EXTERN Class;
$ENTRY МодульP_Гладить {
#Обычное = #Предложение;
#Виртуальное [Class s.Tag [s.Tag e.Info]] =
<s.Tag МодульP_ГладитьX_суф #Виртуальное [Class s.Tag [s.Tag e.Info]]>;
#Предложение = #Суффикса;
}
$ENTRY МодульP_ГладитьX_суф {
#Предложение = #Суффикса;
}
$EXTERN Class;
$EXTERN МодульP_ГладитьX_суф;
$EXTERN FormatP_ToStringX_суф;
КлиентP_Кот {
МодульP_ГладитьX_суф #Виртуальное [Class Кот [Кот e.Кот]] = Гладим кота;
FormatP_ToStringX_суф [Class Кот [Кот e.Кот]] = 'Кота зовут ' e.Кот;
s.Suf e.Arg = <s.Suf e.Arg>;
}
КлиентP_Утюг {
МодульP_ГладитьX_суф #Виртуальное [Class Утюг [Утюг e.Утюг]] = Гладим бельё;
FormatP_ToStringX_суф [Class Утюг [Утюг e.Утюг]] = 'Утюг марки ' e.Утюг;
s.Suf e.Arg = <s.Suf e.Arg>;
}
$EMPTY КлиентP_НеКласс;
Back-end Рефала-5
Поскольку стадия компоновки является частью Модульного Рефала, здесь можно непосредственно реализовать семантику.
Заключение
Описанный механизм позволяет внедрить механизм полиморфизма в Модульный Рефал, причём минимальными синтаксическими расширениями. Механизм расширяет и дополняет имеющийся в языке механизм инкапсуляции. Если в дальнейшем в языке появится статическая типизация, то описанные синтаксис и семантика могут быть легко интегрированы в систему типов (в отличие от ООП на основе вложенных функций).
Как внедрить наследование реализации, а главное, стоит ли его внедрять — вопрос открытый.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent