OberonCore

Просматривал статью https://cyberleninka.ru/article/v/protsedury-kak-dannye-i-zadacha-obhoda-spiska и там нашел такую фразу про процедурные константы. Про процедурные переменные я слышал, но про процедурные константы встретилось впервые.
Возможны ли в Оберонах процедурные константы? Поддерживаются ли они компиляторами?

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

или как вариант внутри процедуры завести константую функцию на вышеопределенную процедуру, например так:

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

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

Да нет.

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

Именованную процедуру назвали процедурной константой? Трудности перевода?

Всё равно не то, потому что это автоматический тривиальный вывод типа.

Константа, ссылающаяся на процедуру своего модуля, во-первых, нарушит принцип однопроходности, во-вторых, не имеет смысла.

Константа, ссылающаяся на процедуру другого модуля, невозможна - т.к. адрес процедуры другого модуля не является известным на этапе компиляции. Для этого уже нужна процедурная переменная.

Так что издержки перевода или фразы в узком контексте.

Сообщение о языке не задаёт ни способ трансляции, ни форму процедурного типа.

Числовые константы тоже где-то хранятся.

Логически процедуры -- константы.

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

Надобно различать логические уровни.

Обсуждается имя процедуры в языке.
Его можно присвоить процедурной переменной. Но ему присвоить ничего нельзя.

Адрес входа в процедуру -- это концепт машинного языка. Другой уровень.

Процедурная константа имеет дело с одной фиксированной сущностью( процедурой ), адрес которой, в общем случае, не имеет значения, как и метод обращения к ней. Любая процедур себе постоянна ( опустим самомодифицирующиеся программы ). И не важно, есть раздельная компиляция или нет, при запуске процедура определяется и остается статичной до выгрузки программы.
Процедурная переменная - динамическая сущность, которая, на протяжении жизненного цикла программы, позволяет обращаться к различным процедурам соответствующей сигнатуры. Процедурная переменная обеспечивает лишь статическую точку входа.

Если хочется контанту процедурного типа, навроде const procedure MyProc = Proc;, то, сначала, нужно ответить на вопрос - зачем.
Если предполагается использовать внешними модулями, то процедурную переменную ставят доступ только для чтения и инициализируют при загрузке модуля. Если для внутреннего использования, то таки опять вопрос - зачем.

Вот да.

Ну, правда, мы в ветке Оберон-07.
В стандарте КП указано, что реализация обязана поддерживать динамическую модульность.

Ну а в конкретной реализации КП - в ББ - все константы подставляются на этапе копиляции. Т.е. в рантайме они нигде не хранятся, их нет как сущности. Компилятор взял значение константы из символьного файла одного модуля и подставил в генерируемый машинный код другого непосредственно.
(Ну или для строковых переменных наверняка создал в этом другом модуле однократно хранимую константу).

В кои-то веки я соглашусь с Кеметом (* уж ни заболел ли я?*)
Константные процедуры смысла не имеют. Да, наверное можно реализовать, но зачем? Что мешает процедуру вызывать по имени? Внутри модуля процедура и так доступна, а из другого модуля -- процедурная переменная объявленная на чтение -- таже самая константа.
Усложнить компилятор можно, но не нужно. И да, адрес внешней переменной в О7 известен на этапе компиляции, в ББ -- на этапе загрузки внешней по отношению к модулю средой. Так что тут адрес ничего не решает.

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

а для процедур

Проще реализовать один using для все вариантов сокращения имен.

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

Применение - например, синонимы (алиасы) процедур. Пишем код модуля с использованием такого синонима, а потом можем подставлять разные реализации, редактируя только одно объявление. По сравнению с процедурной переменной имеем:
- очевидность того, что значение задаётся единожды и больше не меняется;
- возможность присвоить значение на этапе компиляции;
- возможность сосредоточить параметры модуля в заголовке вместе с другими константами, а не разрываться между шапкой в начале и секцией инициализации в конце файла.

Синонимы могут быть как локальными, так и импортированными из других модулей. При этом импортированные read-only переменные не дают уверенности, что модуль не подменит реализацию в процессе работы.