Здравствуйте, Геннадий Васильев, Вы писали:

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

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

C++ несёт слишком много уточняющей информации, которая к программированию не относится, а относится к оптимизации. Я понимаю, можно конечно использовать сплошь и рядом огромные (и гибкие) объекты с метаструктурой на виртуальных функциях, но где взять компилятор, который всё это редуцирует? К тому же атомами там являются int-ы, char-ы и прочее, но не объекты. Я же хочу, чтобы МЕТАобъект был минимальной структурой, а int, char и прочая шалупонь являлись структурами построенными на основе атомов (включая свойства и операции).

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

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

Деление на уровни можно оставить, но не делать его фиксированным и навязанным. Т.е. "хочешь — используй, хочешь — нет, а хочешь наваяй свои".
А насчёт "фиксированной" семантики окружающего мира я очень сомневаюсь. Мы слишком мало знаем (а точнее хотим знать).

L>>Т.е. атомарные конструкции должны быть способными описывать ЛЮБУЮ семантику, вплоть до квантовой.

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

Гы? И что же в этом предложении такого? Про глобальность или про кванты?

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

L>>++(Features):

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

ГВ>Нет ничего проще! Текстовый редактор + шаловливые ручонки.

Текстовый редактор?! Ну добавил ты сохранение объекта в середину кода, чтобы использовать это значение потом. Затем изменил программу и использование значения стало не нужно. Появился неиспользуемый мусор, который нужно убирать вручную. Мне же нужнен "линк" в середину кода (и временной шкалы), который сам отваливается, когда больше не нужен.

Замечу, что я визуалист. Дальше объяснять?

L>>* Возможность вырождения в императивные, логические или чисто функциональные языки, путём ввода ограничений.

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

Зачем ассемблер? Мне такое вырождение может и не пригодится, но люди не умеют пользоваться всем сразу, и обычно большие возможности становятся основным источником ошибок. Кстати, другого объяснения рождению новых, всё более убогих языков я не нахожу. Поэтому для ограждения программы от посягательств человека такие вырождения просто необходимы.

Простейший пример: чисто функциональный язык. Если разрешить изменение объектов после их создания, то весь замысел летит к чёрту.

К тому же такие ограничения могут вводиться в зависимости от поставленной задачи.

L>>* ! Редукция алгоритмов! Пример: primes = filter prime [1..] редукция в решето Эратосфена.

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

Перебор — ну его к богу. Анализировать надо, а не перебирать. И анализировать не результат, а сам алгоритм. Не думаю, что это так уж невозможно, как принято считать.

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

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

Это как раз не преждевременная. Реоптимизация готовых программ, не тобой написанных. Фактически: дизассемблирование -> анализ -> оптимизация -> компиляция. А вот любая программа на С++ — пример преждевременной (и неверной) оптимизации, т.к. чтобы вообще что-то написать, приходится описывать детали. Функциональные языки (в частности Haskell) мне тем и нравятся, что изначально описывается действие, а не его детали. Частично, конечно, но уже неплохо.

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

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

Я же сказал: компиляция! Не писать же компилятор для каждой системы отдельно? А так в С++ скомпилировал, а там пусть GCC мучается.

А не хочешь статически компилировать — есть внутреннее представление (или байт-код, если угодно), который используется интерпретатором/симулятором.

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

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

Угу. Вот и хочу, чтобы было легко "писать". Т.е. стоит подумать над интерфейсом вообще.

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

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

Источник мысли. В UAS пока всё выглядит довольно убого. Интересно было бы взглянуть на будущий UML 2.0.

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

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

Новые не для нас, а для программы. Т.е. те, которые в данной программе/объекте не использовались и не подразумевались.

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

ГВ>Которая никак абсолютно не будет работать.

Почему нет? С точки зрения семантики это будет выглядеть как цепочка семантик от версии №1 до N-ной, где каждая следующая использует предыдущую. Понятно, что на самом деле можно оставить всего одну базовую, но для внутреннего представления. Внешняя же будет изменяемой.

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

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

Неважно. Я просто думал, с какой стороны ещё можно "превратить бетон в резину".

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

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

А бог его знает. Объектная наверное. Для большей гибкости. Мне очень многого не хватает в сегодняшних файловых системах. Например: не древовидная, а графовидная структура каталогов;

L>>--(Features)

ГВ>А почему "--" ?

Это закрывающая скобка к ++()

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

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

Ну исходный код сам по себе ничего не может. Он кем-то должен компилироваться или интерпретироваться.

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

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

Т.е.? Просто пытался свести к минимуму различия между наследованием и включением, т.к. деление там не нужно. Предок в С++ — фактически член класса, только безымянный.

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

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

Угу. Но можно ведь подумать и над другими принципами? Развлекаюсь...
Эта мыслЯ у меня вытекла из идеи "программирование ограничениями". Т.е. описываешь что тебе нужно, а остальное — дело компа. Например сортировка состоит из одного постусловия: множество элементов такое же, но элементы распологаются в неубывающем порядке. Какой алгоритм применять, и применять ли вообще — пусть метасистема кумекает.

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

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

Именно. Я уже рассказал про необязательное деление.

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

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

Не забывай, что это не исследование, а случайные идеи.

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

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

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

Сеньки.