Привет тебе, брат по разуму limax, Вы писали:

L>Изучаю UML и прочие языки/системы метамоделирования. Впечатления самые грустные: те же яйца, вид сбоку.

L>Те же деления на уровни, куча ограничений и прочее.

Иначе обычные человеческие мозги просто не управятся с любой, даже простейшей задачей. UML — это способ документирования твоих мыслей, и он на себя функций берёт не более, чем... ну, скажем, язык символов принципиальных электрических схем — транзисторы, резисторы, микросхемы и прочее. Когда-то я тоже думал, что на UML можно адекватно описывать семантики (в т.ч. — динамические) разных уровней. Оказалось, что можно, конечно... в Notes, очень удобно.

L>Есть ли что-нибудь более гибкое?

Есть. Точно знаю. Мозг. Более гибкого инструмента в распоряжении человека пока нет. Ещё — язык квадратиков, кружочков и стрелочек с пометками.

L>А пока, в связи с этим накарябал гипотетические фичи гипотетической системы, к которой я стремлюсь.
L>Надо бы обработать перед отправлением сюда, но думаю кое-что разобрать можно
L>Фичи располагаются в случайном порядке, как в голову взбрели.

Угу, мечты всегда беспорядочны.

L>==============8<===========================
L>Цель: построить мета-язык описания любых процессов (в частности программирования, ввода-вывода), более сложные функции которого выражаются ТОЛЬКО через набор базовых.

Язык программирования C++. Минимальная базовая семантика — даже операции ввода-вывода отсутствуют. Богатые средства комбинирования объектных семантик. Все сложные функции выражаются (кстати, не "выражаются", а создаются!) через набор базовых.

L>В UML такое отсутствует: сложные конструкции обрабатываются частным образом, а не с помощью базовых, отсюда — слишком много первоначальных определений (в машинном языке). К тому же чётко фиксированы мета-уровни: объект может быть экземпляром класса только соседнего уровня (3M->2M, 2M->Model, Model->Object).

Дык! Потому-то и появляются разные "уровни", поскольку людям проще оперировать сложными семантиками, разбивая их на "уровни" или "срезы" или "схемы" и прочее. Реальные объекты вообще состоят из атомов и молекул с (обращаю твоё внимание) фиксированной семантикой. Кроме того, набор базовых символов UML — ИМХО, весьма перегруженная вещь и ты правильно заметил, что вместо цельных символов логично использовать именованные композиции. Ну так поди докажи это оболваненному COM-ом и прочей дребеденью миру?

L>Цель: мета-язык должен быть таким, чтобы результат преобразования L->MeL->L, где L — любой выбранный язык, а MeL — мета-язык, был семантически эквивалентен оригиналу. Т.е. атомарные конструкции должны быть способными описывать ЛЮБУЮ семантику, вплоть до квантовой.

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

А вот теперь прокомментирую твои мечтания. Мне они показались очень-очень интересными. И начну сразу с того, что ты ставишь исходную задачу весьма обобщённо, а посылки формулируешь в частных семантиках. Это — следствия.

L>++(Features):

L>* Время как координата? Лёгкая возможность добавления кода (захвата данных или подобного) в любое место уже написанного.

Нет ничего проще! Текстовый редактор + шаловливые ручонки. Вопрос на самом деле не в добавлении кода как такового (это — достаточно тривиальная задача), а в сохранении системы в состоянии, удовлетворяющем требованиям, ради удовлетворения которых она создана. Таким образом, имеем необходимости: а) описания требований к системе, б) глубокой интроспекции изменяемого кода, для верификации соответствия изменённых структур предъявляемым требованиям.

А ещё в связи с этим одно наблюдение. Есть такой продукт Rational RequisittePro, знакОм, наверное? Когда я его только начинал осваивать, я всё искал возможности отобразить семантику требований на создаваемую программу. Недолго искал — дня два. Пока не понял, что во фразе "управление требованиями", которыми характеризуется Requsitte главное — это "управление" (которое выражается в сопоставлении флажков требованиям и некоторой структуре перепинываний требований от пользователя к пользователю на их "утверждение", "одобрение", "верификацию" и т.п.), а "требование" это вовсе не семантическая структура, а так... клочок бумаги, пометка на полях и не более того. Просто я её прочёл неправильно — RequsittePro — это удобная, но ни к чему не обязывающая записная книжка. Примерно та же история и с UML.

L>* Возможность вырождения в императивные, логические или чисто функциональные языки, путём ввода ограничений.
L> Императивный = "как делать"
L> Логический = "что нужно получить"
L> Функциональный = "что делать"
L> Чисто функциональный = функциональный, но вход-выход без сохранения состояния, т.е. созданные объекты неизменяемы.

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

L>* ! Редукция алгоритмов! Пример: primes = filter prime [1..] редукция в решето Эратосфена (т.е. исключение произведений простых чисел из натурального ряда, остаток — искомый ряд), т.к. проверять на делимость числа на все числа подряд — ненужная операция, достаточно проверки на делимость на простые числа меньше квадратного корня из исследуемого. Для такой редукции нужна полная развёртка операции остатка от деления (в атомарные операции).

Угу, но прикинь себе нагруженность базовой системы базовыми же математическими аксиомами. А методы поиска по ним? Нет, в принципе можно перебирать всё-всё-всё в поисках наиболее подходящего, но критерии завершённости... с этим проблема...

L>* Как следствие редукции алгоритмов: реоптимизация машинного кода переведённого в метасистему.

Как там у Кнута — "Преждевременная оптимизация — источник..."

L>* ! Выделение части реального времени (например верхний предел в %) на тестирование и оптимизацию используемых алгоритмов для текущих данных (в реальном времени, во время параллельной работы).

Очень интересная мысль.

L>* родная "компиляция" в ANSI С и ANSI С++, ну и во внутреннее представление (для метасистемы и симуляции)

ИМХО, это — игрушки, поскольку C и C++ — инструментальные языки и никакой необходимости в генерации исходного кода на них — нет.

L>* Метасистема и язык написаны на самом мета-языке.

Браво.

L>* Множественные операции, написанные НЕ через рекурсию. Рекурсивное описание — всего лишь частный случай.

Соображаешь.

L>* как можно более компактное (компактнее чем в тексте) и легко-понимаемое представление для человека, но при этом как можно более гибкое и мощное. Кстати, в UML наоборот, более громоздкое описание, по сравнению с текстом.

Кстати, его более трудно сотоавлять, хотя и порой проще читать.

L>* достойное представление динамики. В статической графике — опять ограничения и недостатки? В динамике — как это вообще может выглядеть? Источник: UML Action Semantics.

UAS — это источник проблемы или чего?

L>* ввод как графической (формы и объекты) так и текстовой информации. Изменения должны сразу отражаться в остальных.
L>Ещё лучше: наличие множества (эквивалентных) представлений метаобъектов, в том числе — одно или несколько для пользователя (т.е. для конечного продукта).

Здраво. C++ — это всего лишь один из способов представления внутренней структуры программы — не более того.

L>* новые метатехнологии могут быть применены к существующим объектам. Пример: распараллеливание на кластерах для скорости, дублирование для надёжности и прочее, применительно к простому объекту, где ничего этого не планировалось. Источник: Oracle.

Так, одна просьба убери слово "новые", оно уже у всем оскомину набило. Просто "новое" при нынешнем состоянии IT-отрасли часто ассоциируется с: "для идиотов, идидотичнее старых".

L>* отсутствие фиксированного текстового и графического синтаксиса!
L>1) Текстовый синтаксис определяется задаваемыми внешними правилами (например Extended Bakus-Naur Form), или описываются с помощью самого MeL. Может быть как обычным, так и pattern-matching !

Эх, раззудись рука. См. моё примечание в конце поста. Обращаю твоё внимание, что pattern-ы сами по себе наследники той парадигмы, для которой они сформулированы.

L>2) Графический синтаксис настраивается с помощью редактора графических форм, или опять с помощью самого MeL.

Rational пытается делать шаги в этом направлении, но пока...

L>* Изменяемая семантика. В других языках семантика фиксирована.
L>NB! Можно ли сделать семантику тоже настраиваемую изнутри???? Получится полностью модифицируемый язык, способный вырождаться в обычные! Более того, получится система моделирования ЧЕГО УГОДНО. 8-)

Которая никак абсолютно не будет работать. Ты забываешь о главном — у базовой системы (компьютера, то бишь) все семантики фиксированы до предела. Если это регистр, то это регистр, если это адресная шина, то адресная шина. Вся гибкость компьютеров следует из простого постулата о том, что система S может быть описана в терминах системы G, если S выразима в символах G. А прикол в том, что благодарая системе команд центрального процессора компьютера (это и есть базовый язык описания моделируемой системы), а также наличию оперативной памяти компьютеры могут моделировать системы с очень сложной семантикой. Прикинь себе сложность системы, которую можно описать 256 командами в 1M памяти. Собственно, я имею ввиду, что от необходимости базовой элементарной семантики ты никуда не денешься. Приятно складывать кубики то в башню, то в автомобиль, но должны быть кубики.

L>* Изменяемая строгость: аргументы вычисляются до вызова (Strict) или по мере необходимости (Non-strict). Реализуется легко, т.к. связи являются метаобъектами.

И ни на что реально не влияет (в глобальном масштабе), поскольку если включающая система требует строгого определения типа, то его по-любому придётся выполнять. Короче, ИМХО, в таком виде — рюшечки.

L>* ? Объекты могут быть множественные, иметь несколько частей, т.е. связи могут образовываться с конкретной частью объекта, а не со всем объектом. Простейший пример: In-Out. В UML для этих целей используется тройка InputPin <- DataFlow -> OutputPin.

Роковая ошибка. Я понимаю, хочется всего и сразу. Если объект имеет несколько частей, то зачем всё усложнять? Это же очень просто — объект состоит из нескольких объектов же. Вот и всё. Далее — см. агрегация, ассоциация и т.п.

L>* возможность запуска исключений (ошибок).

Ну... за образец семантики можно принять C++... или CLU.

L>* внутренняя файловая система — фактически объектная система.

Так файловая или объектная? Термин "объект" может быть определён в рамках определения термина "файловая система", но вот наоборот...

L>* в качестве прикола: возможность писать трекерную музыку в MeL. (следствие изменяемого синтаксиса и семантики)

Мда... какофония — тоже музыка своего рода. Симфонии здесь не получится... по крайней мере — сразу...

L>--(Features)

А почему "--" ?

L>Цель: Каждый объект может изменять любой другой объект (любого мета-уровня!) или его связи. Как следствие — программа, ведущая себя как самомодифицирующаяся. После компиляции она может стать обычной статической, хотя умный компилятор должен уметь при необходимости делать и модифицирующуюся.

Тогда этот компилятор практически ничего не должен делать, всё необходимое сделает сама программа.

L>Цель: всё что не требует внешних данных можно выполнить на этапе компиляции. Можно поставить ограничение соотношения <размер результата>/(<время выполнения>*<требуемый для выполнения размер памяти>). Т.е. короткая по времени функция, дающая длинный результат, останется кодом, а не результатом.

Нужно внести ещё понятие времени, ну ты правильно подметил это ранее.

L>Наследование в С++ = безымянное включение члена класса.

Обобщи эту посылку.

L>Цель: в программировании (в частности) использовать структуры расширяющие, но не ограничивающие возможности дальнейшего использования. Ограничения должны вводится, когда они _НЕОБХОДИМЫ_.

То есть, ограничение — это часть семантики структуры. А вернее — семантика структуры всегда автоматически обладает теми или иными ограничениями.

L>Из физики: непрерывное число измерений — что это может быть? Объединение измерений? Аналогия с уровнями UML (3М, 2М, Модель, Объект) — уровни можно объединить, связи объектов оставить. Объект сможет стать экземпляром не соседнего (в оригинале), а любого уровня (3М -> Объект).

А вот гонять с уровня на уровень, ИМХО, не стоит. Тогда уж проще вообще не вводить уровней абстракции как обязательной части системы. Не зацикливайся ты так на UML-ных структурах. На них свет клином не сошёлся. Пусть себе предлагает деления тем или иным способом.

L>Итого, изменяемые определения: синтаксис, семантика (!), передача управления (!!), строгость (!!!)

Выглядит заманчиво, хотя на самом деле не всё так уж "золото на голубом".

L>==============8<===========================

L>Вот такие вот запросы, да?

Нормальные запросы неиспорченного "индустриальым подходом" человека. Постарайся их логичнее изложить. Найдёшь и свои собственные противоречия и кучу бардака вокруг. И вообще — дерзай.