Type-System: Components and interfaces

[emil14]

Размышляя над тем, какие требуются доработки компилятору (рантайм кажется готовым), анализатору и синтезатору, я пришёл к выводу, что главные затруднения вызывают такие сущности как компоненты и интерфейсы.

Пакет, как контейнер с сущностями, имеет 4 их вида: Сообщения, Интерфейсы, Типы и Компоненты. С сообщениями проще всего, они являются тем, чем в обычных языках являются константы. То есть отображённые прямо в исходном коде значения. Будучи статическими данными, они не могут быть обобщёнными. Остальные 3 вида сущностей отличаются параметрическим полиморфизмом (джерениками) и, стало быть, нуждаются в механизме разрешения (resolving).

Разрешённый тип, согласно моему разумению, это тип, который а) ссылается на базовый тип и б) аргументы его параметров являются разрешёнными типами. Компоненты и интерфейсы в данной концепции не являются типами данных, т.е не могут быть значениями сообщений (нельзя отправить компонент или интерфейсное значение по сети) и потому непонятно, каким образом они могут быть разрешены.

Workaround может заключаться в том, чтобы ввести понятие "Resolvable" как чего-то, что способно разрещаться. Тогда компонент и интерфейс будут входить, наряду с типами данных, в это понятие. Разрешённые компоненты и интерфейсы можно определить как таковые, в которых аргументы типов разрешены.

Возможно, это сработает, однако же, элегантные системы неизбежно не только мощны, но и просты. Простота лиспа (где нет, однако, статической типизации) говорит, что концепцию можно упростить. передаваСделать это можно путём унификации всех трёх понятий до одного единого понятия типа. То есть сказать, что "компонент" и "интерфейс" это просто такие типы данных и, следовательно, их можно передавать в сообщениях.

Эта мысль сперва вызвала у меня восторг, ведь она, на первый взгляд, решает проблему, упрощая концепцию системы. К тому же, именно так работают популярные языки - Go, Python, JS, В них функции и объекты, удовлетворяющие интерфейсам являются объектами первого порядка, т.е свободно передаются и возвращаются из функций. Но это упрощение открыло целую кроличью нору...

Во-первых, как эти типы данных будут использованы? Компоненты и интерфейсы объединяет то, что и то и другое используется как вычислительная единица. Интерфейс, по сути, представляет абстрактный компонент. Эти две сущности представляют неявную и явную зависимости. В обычных языках внедрение зависимостей происходит как часть обычного вычислительного процесса - программа просто написана таким образом, что где-то в её начале происходит (единожды) это внедрение, создаются нужные объекты и наполняются нужными данными (клиенты баз данных, моки, etc).

Как здорово было бы иметь возможность в FBP сделать всё то, что можно сделать в обычных языках, ещё и упростив тем самым концепцию! Не правда ли? К сожалению, всё не так просто. Например:

1. Как компонент/интерфейсное значение, будучи переданным как сообщение, попав в сеть компонента встанет на своё место в сети? Тут есть над чем поразмыслить, но навскидку кажется, что выйдет что-то очень сложное
2. Компоненты/интерфейсы можно будет паковать в сообщения. Хорошо это или плохо, ясно одно - сообщения будут не просто данными, а ещё и кодом (если будет найден ответ на п.1)
3. Как создать экземпляр компонента? В обычных ЯП есть выражения и операторы, как нечто похожее но отдельное от функций, в FBP же есть только компоненты. Получается, что нужен специальный компонент (оператор) для создания экземпляров компонентов? У оператора "создать стурктуру" в Go есть операнд "ссылка на структуру". Как сослаться на компонент в FBP? Компонент должен быть чем-то, что находится в памяти и на что можно сослаться по идентификатору. Рантайм нуждается в усложнении и введении понятия компонентов (тогда как сейчас он примитивен и не знает о них).

Это только часть вопросов, которая всплыла в моей голове, при попытке разрешить этот мучительный вопрос.

[emil14]

At this point I decided to keep components and interfaces as "special" entities and not making them specific cases of data/messages. The "dynamic" problem could be solved with #155