OberonCore

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

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

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

А.А. Берс (ИСИ СО РАН) в одной из своих лекций даже подвёл некую общую классификацию для этих... контекстов всяких.
viewtopic.php?f=62&t=3031

Для разнообразия немного сомнений. А стоит ли овчинка выделки?

1. Синтаксис с ограниченностью применения , а по сути директива компилятору.

2. В том виде как изложено для рекурсивных вызовов не пригодна.Будет зацикливание даже и без оптимизации. Вызов концевой процедуры в рекурсивных вариантах должен быть условным в составе IF,ELSE ... или в CASE . И вообще рекурсивные вызовы в моей практике всё больше внутри циклов. Да и без передачи параметров как-то о рекурсии говорить тяжело.

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

Пока на сегодня всё.

Когда меня толкают на компромисс, я хочу знать, а ради чего? Что взамен? И вижу, что ничего. И зачем тогда эти побочные эффекты плюс усложнение синтаксиса (не забудьте!)?

Что касается ООП, то это ГИГАНТСКИЙ КОМПРОМИСС ради такой маленькой вещи, как повторное использование кода. И я теперь должен благоговеть перед ООП? Не стоит его приводить в качестве положительного примера, хотя я не принципиальный противник ООП.

Конечно же!!
Концевой - не значит синтаксически в конце!!
Если говорить об обычном вызове, то он считается концевым, если после возврата из него текущая процедура тоже закончит свою работу. Функциональные компиляторы это распознают и оптимизируют. В частности, ту же рекурсию - до цикла.
Я же просто предложил, чтобы не полагаться на такую несколько эфемерную вещь, как "понимание" компилятора, явную конструкцию. Она всегда "концевая", в каком бы месте не встретилась. Т.е. это как будто вызов функции, а потом сразу RETURN стоит. Разумеется, правила стиля те же, что и для RETURN - ставить на действительно концевом месте.


У вас переменные объемлющей процедуры - делайте рекурсию над ними! Концевая рекурсия реализуется в фиксированном объёме памяти. Фактически, такая рекурсия - сложный цикл. Логично, что есть вместо параметров просто переменные цикла.


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

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

А для цикла обработки событий с автоматной логикой не вижу причин роста стека.
Для этого достаточно выделить в процедуру логику работы одного автоматного такта и кормить её событиями (кивок в сторону Шалыто А.А. как пример)
Это я к тому, что бороться можно разными способами, иногда лучше пересмотреть подход к решению задачи.

Это когда концевая. Углубились - всплыли.
А если как челнок ( типа по дереву ползать) - то сразу встанет проблема восстановления контекста.
Если уж и ограничиваться переменными объемлющей процедуры, то тогда надо и от рекурсии избавляться, сводить к автоматному циклу(например)

Так неконцевая-то как относится к обсуждаемому вопросу? Никак.

Речь в данной теме исключительно о концевой.

Поскольку ни одного куска кода ещё приведено не было, то приведу примитивный пример.
Вместо CONTINUE использовано NEXT.



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

Мне кажется, что в приведённом примере (возможно, я просто не вижу более общей картины) решение о продолжении работы должно приниматься не процедурой Stage1, а вызывающей стороной:Как вам такой вариант? Я что-то упускаю из виду в данном обсуждении?

Согласен, оставим вообще рекурсию в покое. Тогда тем более большого смысла нет.Один только геморрой.
Хотя бы из-за необходимости в описании синтаксиса формализовать применимость этой конструкции.
Повторюсь: пусть эту оптимизацию делает компилятор(опционально). Если его научить, то и с параметрами концевой процедуры разберётся.

P.S.
Это сообщение уже лишнее. Не заметил "stop"

Александр, так я начал с этого: с того, что есть декомпозиция древовидная, а есть списочная - viewtopic.php?p=59493#p59493
Вы предлагаете решение в рамках древовидной, а всё обсуждение предлагаю подумать над списочной

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

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

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

Код Александра понятен и нагляден. В этой связи: а нужен ли специальный языковый конструкт ?

Мой код не будет работать в Oberon/CP: локальные процедуры не могут быть присвоены процедурным переменным, так как в языке нет замыканий. Этот метод сработает только если в качестве контекста (группы локальных переменных) использовать RECORD или глобальные переменные модуля.

Ну да, а в ТМТ-Паскаль будет. Так в этом и вопрос, что лучше вводить новые конструкты, или универсализировать существующие. Лично я предпочитаю второе. Если ввели процедурные переменные, значит они должны работать с любыми процедурами.

Предлагаете добавить замыкания? Или запретить присваивать локальные процедуры нелокальным переменным?

Скорее второе, либо исключить процедурные переменные (как предлагал Омник)