Оберон-клуб «ВЄДАsoft»

Что бы по легче искать было, я тут выкладывал исходник компилятора на Delphi.
Там трэйсер хороший. Можно по шагово просмотреть где и какой код исполняется!

Ой, Серж, боюсь нам это не поможет. Любой Оберон-проект собирается только одним транслятором, хорошо если двумя. Ofront собирается BlackBox'ом и собой же, но это две разные ветки, и два набора исходников соответственно.

В принципе, у BlackBox с отладкой тоже всё обстоит хорошо. Пошаговой нету, но зато какая посмертная! Прелесть. Сам недавно с её помощью очень лихо исправил баг в моей реализации BITS(). С помощью Saferoll.

Ко всем вышеперечисленным проблемам со строками, обнаружил, что сам парсер Ofront (вернее процедура ConstExpression) считает одиночный символ в кавычках значением типа CHAR, т.е. "F", 'F' и 46X это одно и то же. Кстати, по мнению ConstExpression, ""-это строка, а вот 0X - символ.
Значит, мы вообще не можем задать односимвольную строковую константу, можем задавать в тексте программы только константу-символ. Потом может и происходит превращение символа в строку, там где это требуется. Но вот в том и сложность - решить где и что требовать, потому что константных массивов из строк еще нет и это мы сейчас пишем их реализацию.
А решить это совсем непросто!
Поэтому предлагаю пока так. Пусть при задании константного массива внешние скобки () ВСЕГДА означают последовательность элементов (в частности, символов, если мы в данный момент разбираем ARRAY N OF CHAR). Если же мы задаём последовательность символов в виде строковой константы, то эту константу в скобки никогда не заключаем. Т.е. скобки при задании константных массивов означают прежде всего структуру массива, а не часть выражения.
Вообще-то это несколько нелогично, потому что приходится описывать строковую константу, задающую константный массив, как "константное выражение строкового или символьного типа, не начинающееся скобкой ( ". А ведь по существующему синтаксису,например, ((("abcd"))) -правильное константное выражение строкового типа. Другое дело, что здесь скобки излишни. А вот есть ли константное выражение строкового или символьного типа, начинающееся со скобки "(", которая существенна? Т.е. убрать "(" вместе с соответствующей закрывающейся ")" нельзя, потому что получится другое выражение?
Пока я не вижу такого случая. Конкатенация, даже если мы её введём, выполняется слева направо, т.е. необязательно писать ( s1+s2)+s3, это и так подразумевается. Ещё один случай - "(Mуmodule.myfield) ... и что-то там дальше в выражении". Но что может быть дальше в КОНСТАНТНОМ выражении, способное перетянуть myfield у модуля? Видимо, здесь скобки тоже не нужны.
Проблема в перенагрузке скобок разными «смыслами» - это и группировка для выражений и задание массива. Если бы мы использовали для задания массива не (), а [] или {}, то таких бы сложностей избежали. Но как-то неестественно выглядят массивы в других скобках – это ведь не индексы и не множества.
Поэтому пока предлагаю оставить скобки () и считать, что строковые константные выражения задаются без лишних скобок, если они стоят внутри константного массива.

Итак. Что удалось сделать по константным массивам на данный момент-на конец 2014 года.
1)Константные массивы любой вложенности.
2)Тип элемента - целый типов (включая BYTE), BOOLEAN или CHAR; Все эти типы в С-исходнике становятся целыми константами
3)Если массив состоит из CHAR или BYTE, то элементы можно указывать либо как перечень символов в скобках ('f',20X,"7"), либо в виде строки "ab" без лишних скобок. Но строка обязательно подразумевает в конце символ 0Х, для него тоже должно быть место в массиве!
Ставить в кавычках меньше символов можно, недостающие будут приняты за символ 0Х. В частности пустую строку "" можно указывать вместо любого массива ARRAY N CHAR (или ARRAY N BYTE).
Примеры
теперь обрабатываются.
Пока не сделано:возможность опускать размер массива, чтобы Ofront автоматически его рассчитал по количеству элементов и указание $ на фиксированный символьный массив. Чую, что тут опять полезут проблемы с путаницей "символ или строка".

Не могу утверждать, что совсем нет ошибок. Так же есть куда развивать реализацию в смысле эффективности. Но то что сейчас есть уже весьма полезно.
Так что, рекомендую применять в текущих проектах, заодно и протестируем.
2 Zorko Архив с модулями вышлю личкой.

Олежек, ты меня положительно удивляешь. Сначала резвым переходом от теории фористики к результативной практике, ну а теперь — новой качественной модификацией Ofront'а! Думаю, сейчас реализация константных массивов в XDev намного более совершенна, чем в Active Oberon.

Выложил модификацию в реп, буду тестировать — есть на чём. Попробую переписать модуль ресурсов Дурачка с Си на Оберон. Благодаря тебе это стало возможно.

Всем хорошего Рождества!

Обнаружил тут, что в Ofront’е конструкция SYSTEM.ADR("AA") (два символа) разрешена, аллокирует строку и возвращает её адрес, а вот SYSTEM.ADR("A") (один символ) не разрешена и трактуется как ошибка “Illegal use of object”. Опять даёт о себе знать неоднозначность трактования литералов “односимвольная строка” vs “символ”. Конечно было проще сгенерить ошибку трансляции, чем элегантно решить этот вопрос на уровне языка.

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

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

Это не очень смущает, главное чтобы реализация получилась. Моё мнение — хорошая вещь, можно сделать.

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

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

Небольшой патч, призванный устранить вылет по ТРАП при нарушении синтаксиса в описании константных массивов. Это не самая главная проблема, потому что происходит только при перечислении в скобках большего количества констант, чем указано в описании типа для массива.
Тем не менее, лучше внести исправление в процедуру модуля OPP:



К сожалению, главные проблемы с константными массивами (о них мне уже давно сообщил Zorko в частной переписке) до сих пор не решены:
1) Константные массивы не экспортируется, даже если помечены звездочкой. Это означает, что к ним нельзя обращаться из другого модуля, а можно только из того, где они описаны.
2) SDCC неправильно работает со строками константного массива, хотя они и верно генерируются в Си-исходнике. При этом под константный массив выделяется место, с которым и работают все операции. Но сами значения задаются в другом месте, откуда, видимо, какой-то код инициализации должен бы их перекинуть в зарезервированную область. Но этот код отсутствует или не срабатывает.

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