Ответ на »сообщение 2598« (Сергей Губанов)
___________________________

Позиция понятна. Не особо конструктивно, зато прямо.

Ответ на »сообщение 2599« (Сергей Губанов)
___________________________

Речь идет о возможности ослабления контроля языка на уровне передачи параметров. Есть ли средства-заменители ARRAY OF BYTE в Component Pascal?

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

...совместимость всех типов с ARRAY OF BYTE на уровне формальных параметров?

Это невозможно из-за различного порядка следования байтов в представлении чисел на машинах с разными архитектурами little-endian и big-endian.

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

И вообще, чаво остальные молчат?

А потому что:
1) Единый фреймворк для Оберона, Оберона-2 и Компонентного Паскаля невозможен.
2) Математические библиотеки пишут/переписывают только те кому они самим нужны.

Короче, ерунда это всё...

Информации о предпочтениях пользователей, имеющих возможность выбирать разные Оберон-языки и IDE, маловато.

Но кое-что появляется. Вот полезный срез (на лето 2005 г.) по Вологодскому педагогическому университету от С.Свердлова: http://www.inr.ac.ru/~info21/texts/2005-06-27-MGU/welcome.html

Вопрос несоответствия типов решается таким модулем:

MODULE OberonBase;
TYPE
  Boolean* = BOOLEAN;
  Set* = SET;
  Byte* = BYTE или SYSTEM.BYTE;
  Shortint* = 2 байта;
  Integer* = 4 байта;
  Longint* = 8 байт; (*если компилятор не поддерживает = Integer*)
  Hugeint* = 16 байт; (*а вот хочу я на своём Athlon-64 иметь 128-битные целые! но пока нет = Integer*)
  Shortreal* = 4 байта;
  Real* = 8 байт;
  Longreal* = 10 байт; (*не понимаю, зачем упорно игнорировать Интеловский Extended. но пока = Real*)
  Shortchar* = 1 байт; (* в КП = SHORTCHAR, в остальных = CHAR*)
  Char* = 2 байта; (* в КП = CHAR, в остальных = Shortint*)
  Longchar* = Integer; (*UCS-4*);
END OberonBase.

и тотальным использованием в переносимой части программы этих типов. Из минусов такого подхода - тяжело работать со встроенными процедурами. Правда их переносимые аналоги можно поместить в этот же модуль.

А по поводу переносимости - ну это очевидно, что базой будет служить простой Оберон(-1), потому как основные расхождения всех языков как раз в области ООП.

Но мы несколько с разных позиций подходим к задаче. Я хочу, чтобы модуль, реализующий некоторый алгоритм, без переделок работал на всех трёх (а лучше и большем числе) платформах. И модуль Threads я толкаю потому, что множество чисто вычислительных алгоритмов прекрасно работают в многозадачном режиме, и я хочу переносимости этих алгоритмов.

Кстати, XDS отнюдь не является хорошим выбором. Пусть меня поправят старшие товарищи, но у него кажись вообще нет 8-байтного целого и двубайтовое целое реализуется только через SYSTEM.

И вообще, чаво остальные молчат?

PS. А Блэкбокс ARRAY OF BYTE не пропускает :(

Несколько уточнений к вопросу о переносимости внутри Оберонов.

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

На мой взгляд, имеет смысл преимущественно поддерживать переносимость "снизу вверх" (т.е. от Oberon к Oberon-2 к Component Pascal). Это связано не только с тем, что языки построены по принципу расширения предшественника (что заведомо осложняет обратную совместимость), но и сами ориентированы на несколько разные сферы программирования.

Если требуется реализовать/отладить алгоритм из области численных методов, работы с динамическими структурами (списками, деревьями, графами), нет большого смысла сразу окунаться в Component Pascal. Для большинства задач computer science достаточен Oberon и соответственно реализация ETH, где удобно писать и экспериментировать как раз-таки без отладчика.

Если нужно обобщение алгоритмов (задействование ООП), написание автономных несложных программ, устойчивая работа с ОС на уровне системных вызовов, использование внешних библиотек на других языках, перенос на другие платформы через C/C++, эффективная реализация (оптимальный объектный код), то подходит Oberon-2 в исполнении XDS.

Если требуется строить расширяемую систему с использованием компонентно-ориентированного программирования, подходов программной инженерии, иметь прямой выход на современные наработки для Win32, .NET и Java Platform, то нужен Component Pascal в реализациях BlackBox и GPCP. Иными словами, имеет смысл задействовать новые возможности Component Pascal, когда требуется опустить мысль/алгоритм с небес на грешную землю -- в основном для компоновки и обвязки наработанных алгоритмов (насаживание их на каркас и вращивание в единую компонентную среду).

В своей работе "Научные основы доказательного программирования" А.П. Ершов выделял три вида программирования:

1) синтезирующее (автоматическое, автоматизированное или ручное манипулирование знанием о задаче с синтезом соответствующей программы);
2) сборочное (построение программы из уже существующих и корректных фрагментов);
3) конкретизирующее (построение специализированных программ из универсальных заготовок).

Oberon (на уровне АТД) и Oberon-2 (на уровне ООП) больше подходят для синтезирующего программирования и в определенной мере для конкретизирующего, а вот Component Pascal –- преимущественно для сборочного и конкретизирующего программирования.

Не вижу большого смысла выстраивать сложную библиотеку там, где нужны будут преимущественно средства консольного ввода-вывода.

Тем, кто выбирает Oberon-2 для реализации своих программ масштаба shareware унификация вряд ли нужна. Унифицированную поддержку современного UI (а тем паче поддержку threads) выстраивать там смысла тоже нет. Кому требуется, поэксплуатирует внешние библиотеки поддержки UI (и другие средства).

Окончательную привязку средних и больших развивающихся проектов к программной архитектуре и "агрессивному" внешнему миру надо делать все же в Component Pascal, сохраняя возможность плавной миграции между BlackBox и GPCP.

Стоит упомянуть еще две области (специализации языков), которые Component Pascal затронуть не может (по крайней мере, в нынешней реализации), а вот Oberon и Oberon-2 –- вполне. Это клиентские интернет-приложения (изощренный тонкий клиент, Juice-Oberon) и приложения для мобильных устройств (сфера Java 2 Micro Edition) –- "карманный" компилятор JOB Сергея Свердлова (Oberon-2) с оптимизатором JVM-кода.

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

К вопросу о базовых типах для Oberon, Oberon-2 и Component Pascal.

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

Для изучения брал эталонные спецификации:

1. Oberon (Niklaus Wirth). "Oberon Language Report" (October1990)
2. Oberon-2 (Hanspeter Moessenboeck). "The Programming Language Oberon-2" (March 1995)
3. Component Pascal (Cuno Pfister). "Component Pascal Language Report" (March 2001)

А также уточняющие документы:

1. "Differences between Oberon and Oberon-2". H.Moessenboeck (July 1993)
2. "The Oakwood Guidelines for Oberon-2 Compiler Developers" (October 1995)
3. "What's New in Component Pascal". C.Pfister (March 2001)

Что в результате имеем: в спецификациях языков Oberon и Oberon-2 размеры базовых типов не регламентируются (для CP это указано). Это означает, что смотреть надо на конкретные реализации -– ETH (для Oberon) и XDS (для Oberon-2). XDS, что радует, опирается на конкретный регламентирующий документ Oakwood Guidelines, из которого некоторые детали проясняются.

Базовые типы для Oberon и Oberon-2 различий не имеют (не уверен в отношении SET для Oberon, ибо нет под рукой ETH-компилятора, но думаю, что все-таки 4 байта, как и в Oberon-2). Таким образом, можно сравнивать в этом аспекте Oakwood с CP Report.

1. SET и BOOLEAN расхождений не имеют.

2. Тип BYTE есть во всех трех языках (в Oberon и Oberon-2 размещен в псевдомодуле SYSTEM). Кстати, а поддерживает ли Component Pascal (как Oberon и Oberon-2) совместимость всех типов с ARRAY OF BYTE на уровне формальных параметров?

3. CHAR. Разница в названиях типов. Простое переименование CHAR (для Oberon/Oberon-2) в SHORTCHAR (для CP) частично решает проблему. Использование UTF-16 для CHAR в CP -- отдельная проблема.

4. INTEGER. Разница в названиях типов. При переходе к CP решается аналогичным переименованием INTEGER в SHORTINT. Но это требуется только в случае специфических вычислений, когда строго нужен диапазон -32768..+32767, а не -2147483648..+2147483647. Вывод: по возможности надо работать только в INTEGER во всех языках, не привязываясь к внутреннему представлению.

5. REAL. Аналогично пункту 4. REAL --> SHORTREAL. В основе надо использовать преимущественно REAL.

Совместимость, преобразование типов, операции над ними (включая предопределенные процедуры) -- предмет отдельного исследования.

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

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

Для XDS сейчас не дам, а так размеры основных типов:

            Bluebottle  BlackBox
BOOLEAN        1          1
SHORTCHAR      -          1
CHAR            1          2
SET            4          4
BYTE            -          1
SHORTINT        1          2
INTEGER        2          4
LONGINT        4          8
HUGEINT        8          -
SHORTREAL      -          4
REAL            4          8
LONGREAL        8          -

В ETH Oberon типы как в Bluebottle, только HUGEINT нет. Вот и зоопарк - всего два совпадающих типа (BOOLEAN и SET)!

Насчет Unicode: а что хотелось бы поддерживать -- UTF-8, UTF-16, UTF-32 и почему?
Так как в Блэкбоксе CHAR двухбайтовый, то за основу хотелось бы взять UTF-16. Причём для скорости и простоты отрезать все символы, не влезающие в диапазон CHAR. Но конечно оставить и полную поддержку (Хотя иероглифический кусок под названием Hangul желания реализовывать нет - там одни таблицы в зипе больше 6 Мб). Кстати: в один модуль реализацию юникода укладывать неразумно: лучше несколько специализированных.


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

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

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

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

Ну как мне видится.

Библиотека должна обеспечивать относительно лёгкую (а в идеале - полную) переносимость в нескольких областях:

1. "Расчётная" часть - алгоритмы, не взаимодействующие с внешним миром и составляющие суть программы.
    - математические процедуры
    - строковые процедуры (без работы с файлами)
    - поддержка многозадачности
    - работа с типами, памятью, битами и пр.
    - элементарные структуры данных
2. Коммуникационная часть - обеспечивает поступление данных "расчётной" части. Работа с файлами, сокетами, консольный ввод/вывод
    - ввод/вывод в файлы, консоль, куда-нибудь ещё
3. Интерфейсная часть - всё, что относится непосредственно к работе с пользователем.
    - двумерная графика
    - OpenGL
    - сообщения и события

Из первой части следуют модули
  OberonMath
  OberonMathL  - стандартные "дубовые" процедуры, может ещё какие дополнительные
  OberonComplex - дабы каждый не занимался изобретательством велосипеда
  OberonThreads - поддержка параллельных вычислений
  OberonStrings - работа со строками. Можно разбить на несколько модулей со своей специализацией (даже нужно, потому как юникод - штука большая, на каждую задачу свои немаленькие таблицы)
  OberonTypes - работа с метаинформацией, биты, etc.
  OberonADT - списки, деревья
  И прочие модули. Добавляются, если реализация каких-либо алгоритмов постоянно воспроизводится в разных сторонних библиотеках.

Из второй части -
  OberonIO - абстрактный интерфейс ввода-вывода. К нему прилагаются модули реализации для консоли, файлов, сетевого доступа, доступа к архивам, etc.
  OberonFormatIO - интерфейс структурированного ввода-вывода средствами OberonIO

Из третьей -
  Oberon2D
  Oberon3D
  На счёт возможности реализации третьей части библиотеки вообще и её состава в частности у меня большие сомнения

Ответ на »сообщение 2591« (Руслан Богатырев)
___________________________
>>> Кстати, а пробовал ли кто-нибудь переносить в обе стороны модули одного и того же языка Component Pascal в двух реализациях BlackBox и GPCP? Тут случаем зоопарка не наблюдается?

Наблюдается. Некоторые расширения языка можно просто игнорировать, но вот модуль OberonString в GPCP будет называться Oberon_String.