OberonCore

В интерфейсных модулях сторонних библиотек (большей частью, написанных на C) я считаю верных подходом отделять определение базовых типов в специальные модули. Такие модули, как правило, аппаратно- и компиляторо-зависимы.
Вместо такого описания (как в примере кода) я бы создал отдельный модуль, в котором определил такие типы, как UInt8, Pointer, Integer, Cardinal, PChar и прочие. Затем импортировал бы их в интерфейсном модуле. Так мы добиваемся универсальности при переносе на другие платформы и компиляторы, даже в пределах совместимости между различными компиляторами Оберонов.

Резонно.

Пож., уточните формулировку (чего этого?) или измените.

Уточнил.

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



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

1) Для ББ (про прочие компилеры не знаю) введением особого модуля для типов Вы не избавитесь от SYSTEM, т.к. его сразу тянет MODULE Aaa ["os-lib.file"].
2) На базе опыта и ощущений: не стал бы я гоняться за универсальностью реализации в интерфейсных модулях (поминая макросы, воркэраунды и проч.). Основная цель, по-моему, сделать интерфейс как можно ближе к [задокументированному] оригинальному. А из-за разницы в языках (напр. Си-Оберон) это не всегда делается одинаково. Например, unsigned int можно как INTEGER перевести, а можно как SET...
3) я придерживаюсь такой схемы: в документации пишу соответствие типов

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

Особые ситуации, по-моему, бывают довольно часто. Если есть общие соглашения --- в случае исключения им можно не следовать. Если есть набор модулей, претендующий на универсальность, придётся часто и сильно ломать голову над тем, как эту универсальность (отсутсвтвие особых ситуаций) обеспечить.

1. Желательно минимизировать присутствие модуля SYSTEM где бы то ни было.
2. Никаких отличий я не предлагаю. Лишь alias для базовых типов, определённых в отдельном модуле. Сегодня INTEGER занимает 32 бита, завтра - 128. Именно поэтому нужно иметь независимое от компилятора представление типа. Ведь не спроста во многих библиотеках определяются типы UInt32, gchar и тому подобные. Они позволят избежать перелопачивания кода при изменении среды, в которой будет работать ПО.

1. Присутствие в смысле "импорт" или "зависимость"? (для ББ) введение модуля с "alias для базовых типов" зависимость от SYSTEM не убирает. Вообще --- желательно, согласен.
2. Конкретный нюанс, с которым сталкивался на практике. Можете записать, как будет выглядеть решение с использованием модуля алиасов?

Моё текущее мнение (навязывать не собираюсь): точный прогноз что и как будет "завтра", чтобы найти 100% решение сегодня --- дать не возможно. А тратить силы на полурешение не охота.

"Утро вечера мудренее": надо --- перепишем (если эта библиотека ещё будет существовать, если в ней ещё будет потребность, если .......)

1. Избегать присутствия при импорте, конечно.
2. Можно так:

В КП INTEGER зафиксирован в 32 бита. 128 -- это HUGEINT.

Если завтра выйдет новая версия сообщения об языке КП с указанием размера нового размера INTEGER, то что делать с ПО, написанным под предыдущие версии? Возможен вариант, что ПО придётся адаптировать под новые версии компилятора.
С другой стороны, тип INTEGER имеет различный размер среди разных версий компиляторов Оберонов. Как тогда можно гарантировать компиляцию программы?

Чтобы не перелопачивать весь код, я могу лишь заменить alias базового типа в одном модуле, а затем скомпилировать проект заново. Разве так не выгоднее?

Смотря для чего. Если ПО уже было написано для 32, то значит, что оно сможет корректно работать и на машине с 128 (правда, возможно, медленнее при прочих равных).

А если делается обновление программы для работы со 128 (допустим, эти 128 открывают новые возможности), то перелопачивание кода будет долгим.

А с какого бодуна это может произойти?

Этак от определения любого языка можно ожидать, что оно в любой момент поменяется так, что мама не горюй.
Так и жить нельзя будет

Соответствие между типами данных удобно собрать в одной таблице, как сделано, например, на http://www.zel.org/oberon/osci.htm