OberonCore

И всё-таки мы ушли от темы.
Вот сейчас мне нужно иметь матрицы преобразований (поворота) типа

и что же их тоже хранить в отдельном файле ?

Возврат каретки, перевод строки, символ табуляции и смена регистра букв я не считаю форматированием, а курсив, bold, смена шрифта по среди текста и такое прочее -- это форматирование. А кому сейчас легко? Если серьёзно, то задача не особенно трудна, если Вы умеете строить распознающие автоматы.

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

Ведь все они образуются на базе единичной матрицы. Следовательно, в модуле объявляется единичная матрица, в секции BEGIN она инициализируется. А далее определяются процедуры-конструкторы которые создают нужную матрицу беря за основу единичную, и подставляя изменяемые параметры. Чем не устраивает такой вариант?

Я бы назвал это языком описания меню. И его не обязательно знать чтобы получить работоспособную программу. Этот язык надо знать, если Вы хотите настроить меню ББ.
Если Вы работаете в ББ, то текстовая модель -- это (хотите Вы этого или нет ):

Не забывайте, что Вы работаете в компонентной среде!
- есть текст -- текстовая модель. Она может хранить "....". Ей глубоко до балды, что это за текст: документация, исходный, описание меню и т.д. и т.п. Есть текстовое отображение, которое позволяет смотреть и редактировать содержимое текстовой модели. Это не специализированный редактор кода/ресурсов/меню. Это просто редактор (текстовой модели).
- есть построитель меню. Он использует текст, чтобы извлечь из него описание меню. Форматирование для него роли не играет.
- есть компилятор. Он использует текст, чтобы считать из него текст модуля. Форматирование для него роли не играет.
....
Это независимые друг от друга компоненты. Чтобы пользоваться какой-то из них, Вам нужно знать именно её. Знание других не требуется.

В подсистеме Ogl, например, так и делают.

Кстати можно завести единичную матрицу:

Я конечно рад за другие системы, но хотелось бы иметь статические матрицы поворота (по 5 градусов на каждую ось), а приходится делать так:

А какая для Вас разница между константами и переменными, экспортированными только для чтения, которые при загрузке модуля будут инициализированы нужными значениями?

Разница в наглядности.

Да ну...
Вынесите в отдельный модуль группу таких "констант" - и всего-то делов.

Почему нельзя сделать так?
Как иначе Вы предпологаете, что-бы компилятор вычислил значения Math.cos(5 * Math.pi / 180) и Math.sin(5 * Math.pi / 180)? Ведь для этого нужно импортировать модуль Math, выполнить чтение константы pi и вызов функций sin и cos. Или напишете заранее вычисленные значения? Что будет с наглядностью в таком случае?

Евгений, Вы попали в самую точку. Истинная глубинная причина нашего спора не в том, что мы как-то по разному представляем себе назначение ресурсов и т. д., а в том, что некоторые идеи, реализованные в Блэбокс, вступили в противоречие с моими собственными идеями. Компонентную среду можно реализовать по-разному, сохранив основные принципы. И Блэкбокс мне тем и нравится, что если что-то не устраивает, то садись и делай как тебе нравится (с учётом лицензионных ограничений ). После Delphi от такой свободы просто дух захватывает

Без строк тоже можно было бы обойтись.

Верно подмечено .
Главный вопрос "Чем так плохи конструкторы массивов?" пока повис в воздухе. Хотелось бы услышать внятные неоспоримые доводы, как про GOTO

Повторюсь ещё раз для всех.
Разница в наглядности!

Для примера Borland Pascal (Delphi):


Тоже на Active Oberon

Вариант с Active Oberon выигрывает только в том, что позволяет легко адаптировать алгоритм для единичной матрицы любой разумной размерности.
В случае же маленькой размерности, как в приведённом примере, то вариант Delphi намного лучше, особенно если вспомнить, что программы пишутся не только для компиляторов, но и для людей.

В случае Оберона даже если-бы компилятор и допускал инициализацию массивов, их можно было-бы инициализировать только чем-то легко вычислимым без обращения к библиотекам... Поскольку, не знает компилятор, что такое sin и cos.
Для инициализации одной лишь единичной матрицы этого пожалуй хватило-бы Стоит ли необходимость усложнения компилятора такой возможности?
Избавлениё от библиотечных функций в компиляторе не только его упростило, а ещё и уменьшило зависимость от платформы. И кроме того насколько возросла гибкость... нужна математика с одинарной точностью импортируем Math, нужна с двойной импортируем Math := MathL.
А человек, читающий текст программы должен понимать в теории "что такое единичная матрица, и счём её едят"

PS. Можно привести вид единичной матрицы и в коментарии:
так даже нагляднее, нет мусора из скобок и запятых

Если циклы в одну кучу не сваливать, то наглядности вполне достаточно:

Строго говоря, не полностью избавился. DevCPC486 вызывает процедуры NewRec и NewArr из Kernel.
Хотя, модуль Kernel в некотором смысле можно рассматривать как продолжение (или начало?) компилятора, слишком уж он специфичен.