OberonCore

Похоже. что эту статью никто не читал.

Вирт рекомендует функциональный стиль программирования.

On Programming Styles Niklaus Wirth, 24.3.2008 http://www.inf.ethz.ch/personal/wirth/Articles/Miscellaneous/Styles.pdf

Здесь обсуждалось:
viewtopic.php?f=8&t=972&start=0

Обсуждать -- обсуждали.
Непонятно, к какому пришли выводу.

В смысле? Одобрить рекомендацию Вирта или нет?

А потом вызвать Вирта на товарищеский суд. В нашем ЖЭКе.

Просто хочется понять, что именно Вирт имел в виду.
Технически, он предлагает отказаться от использования контекста объемлющей процедуры. Это, похоже, он и называет predominantly functional style.
А я вот помню, как Метцелер (если не ошибаюсь, прямой начальник Александра Ильина) писал об удобстве вложенных процедур. Именно по причине разделяемого ими общего контекста.

Лучшей рекомендации для Метцелера быть не может

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

Иногда внутренние процедуры полезны, но это должно рассматриваться как исключение.

Существуют разные причины вынесения кода в процедуры.
Самая простая (и, вероятно, исторически первая) из них -- избежать повторения одного и того же кода.
Если этот код повторяется в контексте одной (сложной) процедуры, то (IMHO) создание вложенной процедуры -- лучший выход. (Которого, кстати, лишены пишущие на Си.)
Я не думаю, что это такая уж редкая ситуация, чтобы называть ее исключением.

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

Видимо, info21 предлагает этот немалый контекст перетащить в глобальное пространство модуля... :о))

Возможно, я сегодня чересчур мнительный-раздражительный...
Но я думаю, что Евгений прекрасно понимает суть вопроса. И тезис "разделяй и властвуй", который Info21 каждый день поминает, он тоже слышал. Так что "глобальные контексты" - какой-то плод остроумного воображения.


А посему позволю себе ЗАМЕЧАНИЕ ОТ МОДЕРАТОРА, за засорение тематического обсуждения бессмысленными остротами.


Нет, серьёзно - надоело, господа. Кому бирюльки, а кому насущно иметь максимальную пользу от каждой единицы текста в окружающей среде.

Евгений, возможно, и понимает.
А я, увы, не слишком понимаю то, что творится в последнее время.
Какой-то predominantly functional style. В Обероне-07 отказ от очевидно полезных конструкций (таких как цикл LOOP или указатели на массивы).
Вот я и проявляю беспокойство, пытаюсь разобраться в происходящем.

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

Удаление LOOP направлено на то же самое: повышение читабельности и верифицируемости. Это в Драконе на плоскости хорошо рисовать циклы с несколькими выходами, а при линейном чтении я всегда предпочитаю WHILE. Если нужно несколько выходов, то WHILE ~done.

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

Хорошо, хотя бы, что никто не взялся защищать исключение из языка указателей на массивы, возвращающее нас к временам критики Паскаля Керниганом и (IMHO) превращающее Оберон в непригодный для программирования язык.

Что касается исключения LOOP, то оно, по видимому, мотивировано (внезапно вспыхнувшим) желанием Вирта заменить все контекстные зависимости синтаксическими. Это не единственное подобное решение в Обероне-07. Другой пример: привязка (бывшего) оператора RETURN к окончанию функции. (Возможно, в "ту же степь" и predominantly functional style.)
Исключение LOOP Вирт пытался "подкрепить" введением цикла Дейкстры. Но, как говорится, "песок -- неважная замена овсу". Все приведенные примеры цикла Дейкстры не относятся к сфере применения исключенного оператора LOOP.

В спешке не точно выражено.
Не исключение, а second choice.
По умолчанию -- first choice -- подпроцедура вынесена на уровень модуля, инфу получает через параметры.

Мой опыт в том, что это однозначно first choice.

Да, признаю, ситуация second choice случается не так редко.

В лекции №8, которую я вывешивал, моё понимание проблемы полностью суммировано: вкратце: LOOP -- средство 1) моделирования цикла Дейкстры, 2) оптимизации.

Если в 1) нет нужды, то одно 2), возможно, и перестает быть достаточно весомым аргументом, чтобы оставлять LOOP, т.к. здесь это фактически низкоуровневое средство, из разряда SYSTEM.

------
Насчет указателей на массивы: я бы не стал говорить, что нельзя пользоваться языком, но -- да, делать софт с матрицами будем royal pain.

С такой формулировкой согласен.
Встречались, кажется, родственные идеи ("закон Деметера"?).
Просто я немного побаиваюсь, что Вирт (вдруг) возьмет и запретит "вложение" процедур.

И не только с матрицами.
Попытаемся написать на таком "урезанном" Обероне хотя бы аналог сишной функции char *strdup(const char *str), сохраняющей строку (завершающуюся нулем) в куче. (Весьма полезно для создания разных таблиц.)
Конечно, я слишком резко выразился, что языком вообще нельзя будет пользоваться. Но введение неоправданных ограничений -- налицо.

Совсем неочевидно, что цикл Дейкстры (расширение цикла с предусловием) может заменить LOOP...

Думаю, особо бояться нечего: что-то запретить, скажем, в КП уже не вдруг.


Вроде бы из теории Дейкстры именно эта возможность и следует.

А вот насколько можно пренебречь "оптимизированным" вариантом, мне не очевидно: кажется, не так уж редки случаи, когда условия довольно сложные, и там заодно что-то еще вычисляется, и приводить к чистому WHILE будет расточительно. Хотя можно обойти введением каких-то умных оболочек-фасадов...

А как это может выглядеть на практике?
Допустим, у меня есть типичный LOOP:
LOOP

куча кода;
IF что-то там THEN тоже не сижу сложа руки; EXIT END;
еще куча кода

END
Главное здесь то, что "что-то там" проверяется в середине цикла.
Сравним с "типовым" циклом Дейкстры (алгоритм Евклида, как всегда )
WHILE m > n DO m := m – n
ELSIF n > m DO n := n – m
END