Развитие Own/L встало на стабильные рельсы. Каждый элемент цепочки (компилятор, кодогенератор, рантайм) сейчас позволяют в рабочем режиме добавить новую фичу языка без проблем.
Появилось время подумать, куда двигаться дальше. Наибольшие опасения вызывает этап выбора системы типов. Про системы типов написано много умных слов, чем дальше, тем сильнее все эти слова сводятся к описанию имплементации системы типов в языке haskell, как будто ничего лучше человечество не придумало.
Если не брать от безысходности готовую систему типов Оберона, а немного подумать, то ситуация ещё больше ухудшается. Во-первых, есть определённый провал между простым определением типа и его математическим развитием, все эти декартовы произведения, мощности и прочее.
Отдельная проблема это обратный переход, так как математику развили хорошо, уже непонятно, как спуститься на землю, к числам, спискам и объектам.
Взять, например, дескрипционную логику, которая является формальной основой для систем онтологий.
Да, концепции, роли, индивиды, это похоже на типы, свойства и объекты. Но как именно перейти к тому, что будет понятно говнокодеру - не сказано.
Опять же, Вирт в AD предлагает простые понятия, но он это всё предлагает с послезнанием, он уже знает всё это и говорит сразу правду, что не оставляет шанса дойти до всего самому.
Надо думать.
Пока что принимаем за отправную точку определение: тип данных — допустимое множество значений объекта.
Данное определение сразу предъявляет ряд требований ко всей системе - наличие объектов и значений, возможность определить множество этих значений.
Допустим, объекты это переменные и параметры процедур. Значения - это литералы и результат вычисления выражений, а так же константы (пока отсутствуют в языке).
Первый вывод - могут быть объекты, которые принимают любое значение, точнее, значение любого типа. То есть, формально это будет объект с нулевым типом, без типа, но в языке со строгой типизацией это будет объект с типом ANY. При этом, предполагается, что значение так же может быть не установлено, чему соответствует значение NONE.
Конечно же, новый язычок не мог обойтись без гибкой концепции процедурных блоков.
BLOCK Add
VAR x, y, res INTEGER
PAR x, y, res* FUNC res(x, y)
BEGIN
a + b -> res
END Add
Add[1, 2, fx]
Add[x: 1, y: 2, res::fx]
Add(1, 2) -> fx
Add(x: 1, y: 2) -> fx
1 \Add 2 -> fx
Тут тебе и процедура, и процедура с переменным числом параметров, и функция, и наличие именованных параметров, и даже, не может быть, инфиксный вызов (надо ограничить его только для одного и двух операндов)!
За пару дней, с большой осторожностью, накидал прототип own2js-компилятора по мотивам lomo/leaf тут.
Конечно, он пока больше завязан на nodejs, нежели на electron в целом, но получается, что electron, как устройство вывода должен появиться чуть позже.
Язык own пока ничего из себя не представляет, концепцию я пока не придумал, но модуль описать/транспилировать/загрузить динамически уже можно. Ура!
Если позиционировать этот продукт, как собственный вариант BlackBox, то нужно глубже погружаться в систему типов КП, так как управляющих инструкций в КП не так много, и они не самые важные (ну, кроме эффективного WITH). С другой стороны, кому нужен будет Оберон, всегда смогут взять oberonjs, тут почти ничего делать не потребуется, own же в целом должен быть в чём-то концептуальным, так что надо изучить системы типов народов мира :D
Лет пять назад уже всем было понятно, что развитие отобразительных средств браузера идёт, а развитие отобразительных средств десктопного гуя остановилось. Не спасло даже Windows Modern UI. А теперь вот, совсем хорошо, гуй десктопного приложения строится в браузерном движке с помощью html/css/js. Такой мир. Этим мог стать BlackBox. Но не стал.
Пришло время вспомнить про концепцию жизненного цикла программы. Вот его этапы:
В ситуации недостаточных ресурсов для полноценной проработки этих этапов на уровне хорошей годной бинарной кроссплатформенности ничего не остаётся кроме как загнать всё это дело в эмулятор, виртуальную машину, которую можно реализовать для любой подходящей по возможностям экосистемы. А потом уже раскрутиться до полноценного продукта.
В ожидании релиза webassebmbly можно выработать набор собственных примитивов, сводимых к wasm-примитивам, благо не нужно работать для бизнеса, на надёжность и окупаемость.
Возможно ли минимальными выразительными средствами обеспечить приемлимую реализацию всего этого великолепия, пока не ясно.
Плюс ко всему остался нерешённым вопрос совмещения декларативного и императивного подхода, многопоточного и однопоточного кода, возможности выполнения кода на разных вычислительных платформах (гетерогенные вычисления) и так далее.
Короче, надо обозначить ближайшую цель: получить виртуализированную программную платформу, в которой возможна реализация и исполнение программных модулей, отвечающих концепции жизненного цикла программы.
