Изучаю UML и прочие языки/системы метамоделирования. Впечатления самые грустные: те же яйца, вид сбоку.
Те же деления на уровни, куча ограничений и прочее.
Есть ли что-нибудь более гибкое?
А пока, в связи с этим накарябал гипотетические фичи гипотетической системы, к которой я стремлюсь.
Надо бы обработать перед отправлением сюда, но думаю кое-что разобрать можно
Фичи располагаются в случайном порядке, как в голову взбрели.
==============8<===========================
Цель: построить мета-язык описания любых процессов (в частности программирования, ввода-вывода), более сложные функции которого выражаются ТОЛЬКО через набор базовых.
В UML такое отсутствует: сложные конструкции обрабатываются частным образом, а не с помощью базовых, отсюда — слишком много первоначальных определений (в машинном языке). К тому же чётко фиксированы мета-уровни: объект может быть экземпляром класса только соседнего уровня (3M->2M, 2M->Model, Model->Object).
Цель: мета-язык должен быть таким, чтобы результат преобразования L->MeL->L, где L — любой выбранный язык, а MeL — мета-язык, был семантически эквивалентен оригиналу. Т.е. атомарные конструкции должны быть способными описывать ЛЮБУЮ семантику, вплоть до квантовой.
++(Features):
* Время как координата? Лёгкая возможность добавления кода (захвата данных или подобного) в любое место уже написанного.
* Возможность вырождения в императивные, логические или чисто функциональные языки, путём ввода ограничений.
Императивный = "как делать"
Логический = "что нужно получить"
Функциональный = "что делать"
Чисто функциональный = функциональный, но вход-выход без сохранения состояния, т.е. созданные объекты неизменяемы.
* ! Редукция алгоритмов! Пример: primes = filter prime [1..] редукция в решето Эратосфена (т.е. исключение произведений простых чисел из натурального ряда, остаток — искомый ряд), т.к. проверять на делимость числа на все числа подряд — ненужная операция, достаточно проверки на делимость на простые числа меньше квадратного корня из исследуемого. Для такой редукции нужна полная развёртка операции остатка от деления (в атомарные операции).
* Как следствие редукции алгоритмов: реоптимизация машинного кода переведённого в метасистему.
* ! Выделение части реального времени (например верхний предел в %) на тестирование и оптимизацию используемых алгоритмов для текущих данных (в реальном времени, во время параллельной работы).
* родная "компиляция" в ANSI С и ANSI С++, ну и во внутреннее представление (для метасистемы и симуляции)
* Метасистема и язык написаны на самом мета-языке.
* Множественные операции, написанные НЕ через рекурсию. Рекурсивное описание — всего лишь частный случай.
* как можно более компактное (компактнее чем в тексте) и легко-понимаемое представление для человека, но при этом как можно более гибкое и мощное. Кстати, в UML наоборот, более громоздкое описание, по сравнению с текстом.
* достойное представление динамики. В статической графике — опять ограничения и недостатки? В динамике — как это вообще может выглядеть? Источник: UML Action Semantics.
* ввод как графической (формы и объекты) так и текстовой информации. Изменения должны сразу отражаться в остальных.
Ещё лучше: наличие множества (эквивалентных) представлений метаобъектов, в том числе — одно или несколько для пользователя (т.е. для конечного продукта).
* новые метатехнологии могут быть применены к существующим объектам. Пример: распараллеливание на кластерах для скорости, дублирование для надёжности и прочее, применительно к простому объекту, где ничего этого не планировалось. Источник: Oracle.
* отсутствие фиксированного текстового и графического синтаксиса!
1) Текстовый синтаксис определяется задаваемыми внешними правилами (например Extended Bakus-Naur Form), или описываются с помощью самого MeL. Может быть как обычным, так и pattern-matching !
2) Графический синтаксис настраивается с помощью редактора графических форм, или опять с помощью самого MeL.
* Изменяемая семантика. В других языках семантика фиксирована.
NB! Можно ли сделать семантику тоже настраиваемую изнутри???? Получится полностью модифицируемый язык, способный вырождаться в обычные! Более того, получится система моделирования ЧЕГО УГОДНО. 8-)
* Изменяемая строгость: аргументы вычисляются до вызова (Strict) или по мере необходимости (Non-strict). Реализуется легко, т.к. связи являются метаобъектами.
* ? Объекты могут быть множественные, иметь несколько частей, т.е. связи могут образовываться с конкретной частью объекта, а не со всем объектом. Простейший пример: In-Out. В UML для этих целей используется тройка InputPin <- DataFlow -> OutputPin.
* 1 placeholder заменяется на 1 объект; 2 связанных — на 2 объекта, и т.д.
? Возможность подмены цепочки placeholder-ов на другое число объектов. Например, 2 на 3 (дополнительный объект, все 3 объекта выполняют функцию 2-х запланированных), или наоборот, 2 на 1 (один объект выполняет функции обоих)
Нужно ли это вообще??
* свобода направления.
A --<<include>>--> B : "вызов" B из А
A <--<<extend>>-- B : B расширяет A, т.е. возможно В будет вызвано из А.
* возможность запуска исключений (ошибок).
* внутренняя файловая система — фактически объектная система.
* в качестве прикола: возможность писать трекерную музыку в MeL. (следствие изменяемого синтаксиса и семантики)
--(Features)
Цель: Каждый объект может изменять любой другой объект (любого мета-уровня!) или его связи. Как следствие — программа, ведущая себя как самомодифицирующаяся. После компиляции она может стать обычной статической, хотя умный компилятор должен уметь при необходимости делать и модифицирующуюся.
Цель: всё что не требует внешних данных можно выполнить на этапе компиляции. Можно поставить ограничение соотношения <размер результата>/(<время выполнения>*<требуемый для выполнения размер памяти>). Т.е. короткая по времени функция, дающая длинный результат, останется кодом, а не результатом.
Наследование в С++ = безымянное включение члена класса.
Цель: в программировании (в частности) использовать структуры расширяющие, но не ограничивающие возможности дальнейшего использования. Ограничения должны вводится, когда они _НЕОБХОДИМЫ_.
Из физики: непрерывное число измерений — что это может быть? Объединение измерений? Аналогия с уровнями UML (3М, 2М, Модель, Объект) — уровни можно объединить, связи объектов оставить. Объект сможет стать экземпляром не соседнего (в оригинале), а любого уровня (3М -> Объект).
Итого, изменяемые определения: синтаксис, семантика (!), передача управления (!!), строгость (!!!)
==============8<===========================
Вот такие вот запросы, да?
lim