OberonCore

В документации написано, как создавать массив, но я не нашёл, как "вручную" добавить значения в массив.
Сегодня у меня получилось добавить (см.код внизу), но возможно, кто-то сможет подсказать, как правильно можно это сделать?

Мой модуль:


Вывод:

Правильно будет вот так:

Спасибо, но я думал, что можно, как-то проще, в одну строку.

С другой стороны, я планирую вводить массив из формы или файла, а это уже совсем другая история.

Чтобы два раза не вставать, а как правильно (минимально по коду) задать МНОЖЕСТВО:
{0,1,2,3,4,5,6,7,8,9} и вывести его?

StdLog.Set( {0 .. 9} )

qrkx, в одну строку тоже можно, но это сомнительный вариант. Надо написать отдельный парсер. А потом как-то так:
Такой способ я видел в каком-то из компиляторов Оберона-07, там так задавались машинные команды в шестнадцатеричном коде. Но, понятно, дополнительные накладные расходы на парсинг.

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

Вы, видимо, имели опыт интерпретируемых-скриптовых языков?

Смотрите.
Для языка со статической системой типов.
Если можно задавать массив как-то конструкцией, как целое - это будет, во-первых, литералы массивового типа. Во-вторых, появляются константы массивового типа. Вопросы, что это ещё влечёт в языке.
По сути, для ARRAY OF CHAR так и сделано: строка как литерал, возможность объявить константу этого типа.
Для массивов остальных типов...
А что дальше? Вводить конструкцию, которая будет уже собирать значение не просто из литералов, а из переменных?
Проследите цепь нагромождений.

Но автор говорит не о литералах/константных массивах, а об инициализации массива одной строкой.
Впрочем, и константные массивы и инициализаторы есть во всех языках, авторы которых заботятся об эффективности и удобстве разработки, а не о том, как придумать такой язык, компилятор которого студиозус мог бы реализовать за обозримое время.
Вот как понадобилось, так для Активного Оберона и математическое расширение сделали и инициализацию массивов, ибо без него это и не расширение получается.
Правильный подход, это когда компилятор берет на себя работу, которая, в общем-то к программированию и не относится.

Расширение Активного Оберона -- это эксперимент + тема для кандидатской. Надо же придумывать темы аспирантам.

Эти расширения для массивов проверялись на моей реальной системке еще при разработке. Там пяток строк сократилось из порядка тысячи. Овчинка выделки не стоила.

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

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

(Коллеги, кто был на Дне Оберона, видели).

День Оберона пишется с большой буквы.

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

Это же по заказу было сделано и используется в коммерческой системе, поэтому синтаксис был заимствован из матлаба.
Сокращение на пяток строк говорит о том, что что-то пошло не так, видимо это сокращение происходило через не могу/не хочу/не буду/это не по оберонвски/это нарушает мои представления о мире и тп. Потому что у других таки сокращение получается значительным. Впрочем, мат расширение Активного Оберона это не столько про сокращение записи, сколько про упрощение и понятность записи, и производительность, так как время вычислений может снижаться на пару порядков.
Ну, для академических вычислений, конечно, можно и пару дней результат вычислений подождать, не велика беда.
Но ведь задачи и другие бывают.

В Ofront+ для BlackBox Олег Комлев реализовал константные массивы. Идея взята из Оберона для Амиги (Amiga-Oberon v3.11, F. Siebert / A+L AG). Работа с ними выглядит так:

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

Илья прав, появились дополнительные сложности. Так что, наверное, в подчёркнуто простом языке программирования, каким является, например, Оберон-07, они не нужны просто из стремления к простоте транслятора, языка и концепта в целом. Это вопрос философии минимализма. Во что выливается стремление удобно задавать массивы скопом? В такое же желание иметь возможность задавать константные записи, тогда их элементы тоже будут считаться константами, и понеслось. Понимаете, qrkx? Простота утекает, накапливается сложность, и потом мы в ней тонем. А какой язык использовать - каждый решает для себя.

Можно подумать, что коммерсанты понимают, что они программерам заказывают.

По моему опыту -- что первые, что вторые в подавляющем большинстве изрядные долбо*бы, несмотря на всю свою, нередко нерядовую смекалистость. Одно другому ведь не мешает.

А чем ещё можно проинициализировать массив?

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

Прошу прощения, это остатки более длинного сообщения, после неудачного редактирования.

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

Kemet, а я не знаю из серьёзных участников форума никого, кто не имел бы многолетнего различного опыта в "других языках программирования и ide".
Всё это сто раз обсуждалось. Разумеется, есть общеличностные (общекогнитивные в том числе, хотя и не только) установки тоже, которые приводят к тому, что кому-то чего-то не хватает (а хочется взять и пользовать), а кого-то наоборот раздражает избыток, наваленный без понимания (а хочется выкинуть большую часть и продумать с чистого листа).

Безусловно, если отбросить часть, что кто-то чего-то не понимает, а говорить только о понимающей части, то есть и ролевая матрица: кто-то должен, действительно, решать те задачи, где надо прямо сегодня, сейчас и быстро. И психологически ему эти задачи подходят. А кто-то должен сидеть и втыкать, как всё перебрать и сделать не через одно место. И психологически ему это подходит.
Беда бывает, когда первые забывают, что накапливается инженерный долг (всё, что сделано через одно место, надо при первой возможности переделывать через нормальное).
Также беда бывает, когда задача, требующая "прямо сейчас", падает на человека второго типа.
Да что говорить, там наверняка даже на уровне гормональном отличия у этих типов (А - адреналин - хватай-атакуй-беги, Б - кортизол - затаись-понаблюдай-подумай). Info21 поправит, как знаток этой темы.