OberonCore

Собственно, причиной открытия этой ветки стало вот это:

http://www.jg.inf.ethz.ch/wiki/ComponentLanguage/Front



Прошу любить и жаловать. :):)

SYSTEM убрали. Означает ли это, что системно-зависимые компоненты нужно писать на языке несовместимом с COMPOSITA или же его высокоуровневые возможности будут позже добавлены в прочие языки Oberon-семейства? Хотя бы предположительно.

Если SYSTEM не описан в Language Report, это не значит, что его нет...
Надо бы глянуть, на чем написан "поверхжелезный" рантайм Композиты - на ней самой, или на Активном Обероне?

Не заметил по описанию языка, но это- очередной эксперимент и из языка на этот раз выкинули указатели. (со страницы http://www.jg.inf.ethz.ch/wiki/Group/Research ).

Отлично, давно пора! : )

Да, там какая-то концепция хранилищ - толком по первому чтению не разобрался.

Впечатление - декларатив для "композиции компонентов" действительно сильный, но в целом язык несбалансирован - его бы как "верхний уровень" взять для организации взаимодействия подсистем, а не для полного программирования.
+ такая особенность бросилась в глаза: в ОО-языках есть только объекты, которые хорошо годятся для абстрагирования проблемной области, но плохо - для архитектуры.
А тут есть только компоненты, заточенные под выстраивание архитектуры, а абстракции данных придется эмулировать через них... Т.е. тот же перекос, что и у ОО, только в обратную сторону, получился.
В отличие от Обероновской классики, где есть разделение компетенций между объектами и модулями.

А не нужны вам "абстракции ДАННЫХ"! Вы теперь получате средство формализации ОТНОШЕНИЙ в системах (соблюдение деклараций интерфейсов + поддержка протокола по обмену). - Какая разница что и как внутри компонент это поддерживает? :о) Это ж как раз и есть конечная идеальная точка компонентного ПО! :о)

Да вот, средство формализации отношений между компонентами отличное!
Но для написания самих компонент слишком высокоуровневое, по-моему.

Такое предположение, что модель контроля за взаимодействием компонент, обкатанная на COMPOSITA будет внедряться в язык, служащий непосредственныи приемником Active Oberon. Хотя, возможно, что предположение да и только . Фактов таких нет. Косвенное свидетельство - экспериментальный характер COMPOSITA и открытость Оберонов для расширения.

Возможно, Ваше предположение вполне реалистичное.
Active Oberon был промежуточным экспериментальным решением.
Zonnon в чистом виде заточен под .NET и из-за обязательств по микрософтовским грантам вряд ли будет open-source.
Логично, что лаборатория Гуткнехта ведет "разведку боем" в третьем направлении, развивающим два предыдущих.

Эх, поспешил обрадовать, а ребята, похоже, имели ввиду совсем другое - коллекции лежат в динамической памяти, компоненты вероятно, тоже "Initially, the storage location of a normal variable with a component type is empty until a component has
been assigned to it." (хотя чего им было в статическую не кинуть ). Еще как-то не нашел наследования - похоже его заменяет наличие нужного интерфейса.
Штука получилась интересная, но 2 примера из 3-х выглядят переусложненными. Как работает "решето" до сих пор не пойму. Третий пример (SimCity ) - то, для чего этот язык создавался.
В силу того, что массив-это коллекция и хранится в динам. памяти, а также того, что взаимодействие по протоколу- не самая дешевая операция, для ядра он может оказаться не очень.

Припомнил что швейцарцы меняли:
Паскаль: +структурность, -сложность, -адресная арифметика
Модула: +модули,-неоднозначности Паскаля
Оберон: +наследование, -typebound процедуры, -множ.наследование, - модель (2 файла на модуль)
ActiveOberon: +активные объекты
Zonnon: +протокол для активных объектов.
Composita: +компоненты,протоколы взаимодействия, интерфейсы, -наследование (быстро же у них наследование износилось
OneronNext: +??, - ?? (что дальше они выкинут на свалку истории???

Вроде писал, а не вижу...

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

Не стоит сильно париться.

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

Это да. Однако некоторые идеи извлечь оттуда можно. Чем и занимаемся.

На странице исследовательской группы проф. Гуткнехта (Programming Languages and Runtime Systems Group, ETH Zurich) выложена реализация языка Composita с исходными текстами (включая исходники ран-тайма), а также с набором тестов производительности и парой примеров приложений. См. http://www.jg.inf.ethz.ch/wiki/ComponentLanguage/Front

В минувший четверг на странице исследовательской группы проф. Гуткнехта (Programming Languages and Runtime Systems Group, ETH Zurich) выложена новая версия реализации языка Composita с исходными текстами (включая исходники ран-тайма), а также с набором тестов производительности и парой примеров приложений. См. http://www.jg.inf.ethz.ch/wiki/ComponentLanguage/Front

Изменения по сравнению с вариантом двухмесячной давности затронули Component System (на уровне ядра и компилятора языка), а также Traffic Simulation Package и Benchmark Package.

Это весьма нешаблонный взгляд на компонентное программирование и его поддержку на уровне языковых конструкций, включая интерфейсы-контракты с поддержкой спецификаций протоколов взаимодействия. Подход Composita -- предмет пристального изучения в свете поддержки параллельного и компонентного программирования в рамках проекта новой ОС "Роса".

Почитал описание языка и сразу возникло много вопросов.

Концепция процедуры есть, но библиотеки процедур создавать нельзя (процедуры существуют только внутри компонента и недоступны за его пределами). А что делать, если мне нужно использовать одну и ту же процедуру сортировки в разных компонентах?

Взаимодействие между компонентами на основе протоколов выглядит на первый взгляд привлекательно. Но что, если в протоколе есть ошибка, как ее найти, как отладить такую программу? А если компонент нужно заменить его новой версией, в которой протокол усовершенствовали (что-то добавили, что-то исключили)?

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

Это некий прототип архитектурного языка... Которому место на верхнем уровне системы. В сочетании с обычным языком на нижнем.
В текущем ("чистом") виде получился язык далеко не универсального применения...

поддерживаю))

((ужас чего наворочали. и снова грамматики как в зонноне...
подумаю лучше на тему конечных автоматов и ммх...