Ответ на »сообщение 2590« (Иван Горячев)
___________________________

У меня вот вопрос - как быть с зоопарком типов? C вещественными типами, например.

Не такой уж это зоопарк. :o) Разве что есть небольшие расхождения, но они вполне разумно могут быть снивелированы. Кстати говоря, неплохо было бы иметь на руках для обсуждения сравнительные таблицы расхождений для трех языков, а также для соотв. IDE. Что-то такого документа я нигде не встречал...

Далее, касательно строк вообще и юникода в частности (потому как они мне сейчас ближе всего) - в XDS и ETH двубайтового символьного типа нет, насколько я помню.

Насчет Unicode: а что хотелось бы поддерживать -- UTF-8, UTF-16, UTF-32 и почему?


По поводу процедурных типов. Возможность их применения зависит от того, собирается ли OM дальше работать над Блэкбоксом, ибо в документации они грозились процедурные типы убрать...

Процедурные типы закреплены в языке. Они решили поменять язык? И назвать его по-другому? Вот Вам и налицо произвол компании-монополиста :o) А мы тут планируем сделать на них ставку...

Кстати, а пробовал ли кто-нибудь переносить в обе стороны модули одного и того же языка Component Pascal в двух реализациях BlackBox и GPCP? Тут случаем зоопарка не наблюдается?


1. К списку модулей я бы добавил OberonCoroutines или что-то подобное.

В отношении его необходимости на базовом уровне библиотеки есть большие сомнения.

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

2. Модули OberonConsole, OberonFiles и OberonInOut естественным образом сводятся к одному головному модулю OberonIO и нескольким модулям-плагинам (с возможностью добавления своих, естественно).

Здесь можно поспорить. У каждого из этих подходов есть свои плюсы и минусы.

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

Ответ на »сообщение 2587« (Руслан Богатырев)
___________________________
У меня вот вопрос - как быть с зоопарком типов? C вещественными типами, например.

Далее, касательно строк вообще и юникода в частности (потому как они мне сейчас ближе всего) - в XDS и ETH двубайтового символьного типа нет, насколько я помню.
Или вот ситуация - в модуле OberonStrings имеют место быть процедуры перекодировки символов, и соответственно таблицы перекодировки (что в принципе логично):

TYPE
  CharTable = POINTER TO ABSTRACT RECORD
    (t : CharTable) FromUnicode(ch : CHAR) : CHAR, NEW, ABSTRACT;
    (t : CharTable) ToUnicode(ch : CHAR) : CHAR, NEW, ABSTRACT;
  END;

PROCEDURE FromUnicode(t : CharTable; VAR s : ARRAY OF CHAR);
PROCEDURE ToUnicode(t : CharTable; VAR s : ARRAY OF CHAR);

Преобразование ToUnicode можно оформить массивом из 256 позиций, а вот обратное - нет, ибо в юникоде символы одной кодовой таблицы разбросаны будь здоров. Можно было бы сделать на основе процедурных переменных, но тоже ненадёжно (об этом ниже). Никакого приемлемого переносимого решения в голову не приходит.

По поводу процедурных типов. Возможность их применения зависит от того, собирается ли OM дальше работать над Блэкбоксом, ибо в документации они грозились процедурные типы убрать...

-------------
Теперь по существу :)

1. К списку модулей я бы добавил OberonCoroutines или что-то подобное.

2. Модули OberonConsole, OberonFiles и OberonInOut естественным образом сводятся к одному головному модулю OberonIO и нескольким модулям-плагинам (с возможностью добавления своих, естественно).

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

Ответ на »сообщение 2587« (Руслан Богатырев)
___________________________

При этом не должно быть дискриминации в отношении выбора пользователем парадигмы программирования (не затаскивать его принудительно в component-oriented programming). Иными словами, поддерживать три основных подхода:
1. Структурное программирование (Oberon) c поддержкой расширяемости ПО.
2. Объектно-ориентированное программирование (Oberon-2).
3. Компонентное программирование (Component Pascal).


В смысле, одновременно писать три разных (но в чем-то похожих) framework-ов?

Оберон и экспериментальное программирование

Интересно, а кому-нибудь доводилось изучать созданный на базе Oberon-2 язык O2M (Д.А.Швец, А.И.Легалов, Красноярский ГТУ), а также соответствующую систему программирования?

http://www.softcraft.ru/index.shtml
http://www.softcraft.ru/ppp/o2m/cmd/index.shtml
http://www.softcraft.ru/ppp/download.shtml#src

Каковы впечатления?

Размышления в продолжение темы единой эталонной библиотеки для Oberon, Oberon-2 и Component Pascal.

Если следовать лаконичному стилю Оберона, в базовом уровне должен быть заложен минимум средств, который понадобится большинству программ (не завязанных на GUI, DB, Communication и т.п.).

При этом не должно быть дискриминации в отношении выбора пользователем парадигмы программирования (не затаскивать его принудительно в component-oriented programming). Иными словами, поддерживать три основных подхода:

1. Структурное программирование (Oberon) c поддержкой расширяемости ПО.
2. Объектно-ориентированное программирование (Oberon-2).
3. Компонентное программирование (Component Pascal).

Для каждого из указанной тройки языков в отношении операционной платформы Win32 на сегодня есть соответствующая некоммерческая система программирования:

1. ETH (Plug-In ETH Oberon for Windows)
2. XDS (Excelsior Native XDS)
3. BlackBox, GPCP

В качестве объединяющей идеи предлагается выбрать концепцию ADT (abstract data type), опирающуюся на понятие модуля, и за счет нее на базовом уровне эталонной библиотеки исключить использование методов и классов (где языки начинают отличаться).

Если взглянуть на библиотеки ISO Modula-2 и Oakwood Oberon-2, а также вспомнить истоки самого Оберона (статья Вирта "Проектирование системы с нуля"), то видятся такие библиотечные модули.

0. OberonSystem (системно- и языково-зависимые средства, операции над битами, а также возможно exceptions)
1. OberonString (работа со строками, включая Unicode)
2. OberonConsole (ввод-вывод для консольных приложений, аналог Log-окон с поддержкой клавиатурного ввода)
3. OberonFile (файловый ввод-вывод)
4. OberonInOut (обобщение Console и File в понятие потока ввода-вывода, stream)
5. OberonMath32 (математические функции, SHORTREAL для CP)
6. OberonMath64 (математические функции, REAL для CP)
7. Oberon2D (примитивы 2D-графики)

В качестве ADT-модулей могут быть выполнены OberonConsole, OberonFile, OberonInOut, Oberon2D. При необходимости и OberonString.

Поскольку в Обероне по сравнению с Modula-2 произошел отказ от неквалифицирующего импорта (т.е. убрано FROM… IMPORT), то в ADT-модулях удобно фиксировать имя главного абстрактного типа -- T, т.е. использовать "объекты" типа OberonFile.T (как это активно применялось в Modula-3).

Что касается контроля использования избыточных языковых средств (возможность миграции внутри тройки Oberon/Oberon-2/CP), то можно сделать для BlackBox (как объединяющей IDE) два верификатора (language validator) -- т.е. вырожденные front-end компиляторов Oberon и Oberon-2 без генерации кода.

Таким образом, BlackBox может использоваться для сборки разнородных блоков (Oberon, Oberon-2, Component Pascal) и включения на максимум потенциала ООП и КОП.

Компилятор XDS — как оптимизатор кода и как инструмент для создания real-time systems.

ETH -- как учебная система для computer science, где возможностей языка Oberon более чем достаточно.

Ну а семейтсво GPCP -- для тех, кто хотел бы шагать в ногу с модой и не отставать от новаций мира Java и .NET.

Ответ на »сообщение 2583« (Trurl)
___________________________

Рассматривать Компонентный Паскаль как надмножество Оберона-2 не получится. Разве что в простейших случаях. Да и без привязки к базовым библиотекам и даже к компилятору очень трудно обойтись.
Вот, казалось бы, численные методы - область, где зависимость от среды минимальна. Но даже здесь придется иметь дело с такими частностями, как exp и Exp. Что уж говорить о строках и файлах.

Унификация библиотек для Оберонов более чем желательна. На мой взгляд, если этого не сделать, то придется замыкаться на конкретной реализации (BlackBox) со всеми вытекающими отсюда проблемами.

Еще в языке Modula-2 Вирт применил хороший подход, позволяющий отделить переносимые (высокоуровневые) модули от непереносимых (низкоуровневых). Достаточно было осуществлять импорт псевдомодуля SYSTEM.

Даже в тех случаях, когда можно было напрямую использовать типы и процедуры из этого модуля (импортирование осуществлялось неявно, благо это прямая связь с компилятором и RTS), все равно для подчеркивания низкоуровневого характера модуля желательно было импортировать SYSTEM. В языке Modula-3 эта идея нашла еще большее развитие.

Унификация библиотек -- развитие этой идеи: все, что использует только эталонную библиотеку, переносимо, остальное -- намертво завязано на конкретную среду программирования.

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

Считайте, что любые прямые вызовы штатной библиотеки системы программирования равносильны системным вызовам. При изменении системного API в случае прямой завязки на него придется переписывать исходные тексты. Библиотечная прослойка (реализация ее вырожденная, в простейшем случае примитивная) позволяет получить дополнительное средство реконфигурации системы.

Что касается языковых средств, то, вообще говоря, языки Oberon, Oberon-2 и Component Pascal различаются между собой куда меньше разных версий Turbo Pascal, Borland Pascal и Delphi.

Ответ на »сообщение 2583« (Trurl)
___________________________


Рассматривать Компонентный Паскаль как надмножество Оберона-2 не получится. Разве что в простейших случаях. Да и без привязки к базовым библиотекам и даже к компилятору очень трудно обойтись.
Я, собственно, к этому и веду. Хотя бы минимальный набор библиотек стандартизировать...

Ответ на »сообщение 2574« (RBV)
___________________________
>>>Да и прямого смысла нет привязываться к компилятору. Речь идет о привязке к языку... вот только к какому? Можно ориентироваться на Оберон-2 и рассматривать Компонентный Паскаль (грубо), как его надмножество.

Рассматривать Компонентный Паскаль как надмножество Оберона-2 не получится. Разве что в простейших случаях. Да и без привязки к базовым библиотекам и даже к компилятору очень трудно обойтись.
Вот, казалось бы, численные методы - область, где зависимость от среды минимальна. Но даже здесь придется иметь дело с такими частностями, как exp и Exp. Что уж говорить о строках и файлах.

К вопросу о компиляции - добавил в подсистему Rad тулзовину, позволяющую просто скомпилировать модуль на Oberon-2.
Правда при стыковке с модулями на Компонентном Паскале имеются нюансы (что-то про области видимости и расширения типов, сейчас не помню)