OberonCore

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

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

Я в затруднении ответить, нужны ли константы-массивы, но "плодить сущности" - это именно то, к чему Вы и призываете. В случае с массивом новых видов сущностей не добавляется.

Я не призываю ни к чему Просто жалуюсь на отсутствие такой возможности в Обероне, несмотря на наглядность. Честно говоря я не вижу серьёзных усложнений. Просто получается что массив инициализируется не нулевым значением, а некоторым другим.

Каким, например? Просто получится лишь в случае простых-же выражений...

Вы декларируете от балды, а я -- на основе наблюдений за студентами и школьниками.

Внятного ответа не последовало, поэтому попробую сам ответить на этот вопрос.
Рискну предположить, что веских оснований не включать конструкторы массивов в язык у создателей языка (Оберон, КП и тд) не было. Может Никлаус Вирт & Co руководствовались второстепенными доводами. Например, тупо не хватило "свободных" скобок. А что!, круглые скобки и так перегружены значениями, особенно после введения охраны типа и методов (принимающий параметр); фигурные скобки нельзя (SET); квадратные тоже нельзя (селектор элемента массива). В конце концов, видимо, было принято волевое решение, просто на правах автора языка, может и не без сомнений.
Может сыграл свою роль и тот факт, что конструкция получается не универсальной: в случае больших и (или) многомерных массивов код превращается в кошмар. Мол, начнут злоупотреблять.

Наоборот. Нужны веские доводы, чтобы *включать* что-то в язык. Пока таких не предъявлено, по умолчанию -- не включать.

Похоже, это точка в разговоре о конструкторах массива.

ха ха ха
оказывается есть!!!!

К сожалению, Ваш пример у меня не компилируется, ругается на синтаксис (BlackBox v1.5 Rus). Я бы удивился, если было бы иначе. В спецификации на КП таких конструкций нет (поправьте меня, если я ошибаюсь).

Естественно - речь про Актив Оберон и А2.

Игорь! Обратите внимание, что ветка называется Active Oberon & Bluebottle (A2)

Мой пример работает в A2 (aka BlueBottle, aka Aos)
Это операционная система, которая работает на голом железе, но может работать и под Виндовсом (WinAos) - в результате получается нечто похожее (за исключением графического интерфейса) на BlackBox, так же може работать и поверх Linux.

Язык программирования: ActiveOberon - очень похож на компонентный паскаль, но есть и некоторые различия. Например объекты описываются несколько по другому, как то компактнее (что мне особенно нравится).

Попробуйте, может Вам будет интересно

Если Вам нужна дополнительная информация можете поискать здесь (рус.) http://a2os.org.ua/forums/ и здесь (англ.) http://www.ocp.inf.ethz.ch/forum/ и http://www.ocp.inf.ethz.ch/wiki/

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

Sorry А я тут всё со своей КП-шной колокольни
Спасибо за ссылочки, но думаю, что пока мне рано переходить на AO. Не потому, что AO чем-то плох, просто нет достаточных оснований для таких метаний. По большому счёту нет большой разницы на каком из Оберонов писать, важно правильно мыслить, по обероновски

Очень даже можно Если вы не с "нуля" пишете компилятор, то просто забыв удалить фичу вы ее вводите в новый компилятор

На самом деле, мне кажется, что не это причина появления "недокументированных" возможностей. Так как язык продолжает разширятся.
Вы также не найдете таких возможностей:
- векторные расширения компилятора(операции с матрицами);
- перегрузка операторов;
- ООП расширений (абстрактные методы и возможно другие)
- рефлекшин;

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

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

А то ведь действительно, можно завести константный массив (строку) типа CHAR:
Но — нельзя типа INTEGER. Несимметрично как-то.

Мне за много лет использования Оберонов наверно наибольше не хватает в них константных массивов. Поэлементное присваивание в некоторых случаях неэффективно. И чтобы включить в модуль маленький массив приходится извращаться с кодовыми процедурами:
что, разумеется, непереносимо между диалектами Оберона. Здесь как с параметрами процедур (IN в КП, CONST в Oberon-07, READONLY в Modula-3) Или с нетрассируемыми указателями ({UNTRACED}, [untagged], [NOTAG] в разных реализациях и т.п.). Позволю себе предположить, что возможности эти на практике — крайне полезны. Но не будучи своевременно включенными в стандарт языка "расползлись" на разные варианты в разных реализациях. Вот вам недостатки минималистических стандартов.

Вобщем, я — за включение в новые редакции КП, если таковые будут, константных типизированных массивов.

P.S. В своё время для компьютера Амига много писали на модульных языках. Так вот в Amiga-Oberon v3.11 (F. Siebert / A+L AG) применяется интересное расширение Оберона-2:
Почему бы не взять синтаксис отсюда, ведь есть же потребность, как видим. Хочу попробовать протолкнуть эту идею авторам GPCP, которые вводят экспериментальные расширения языка охотнее, чем OMinc.

Я думаю, что при проектировании Оберонов был расчёт на разделение кода от данных. Что, в общем-то, является неплохой идеей, но, в то же время, перфекционистской попыткой приучить к "правильному" подходу в программировании ...