OberonCore
https://forum.oberoncore.ru/

... the recommended style becomes predominantly functional.
https://forum.oberoncore.ru/viewtopic.php?f=26&t=1004
Страница 1 из 3

Автор:  GeoVit [ Вторник, 27 Май, 2008 15:16 ]
Заголовок сообщения:  ... the recommended style becomes predominantly functional.

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

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

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

Автор:  Илья Ермаков [ Вторник, 27 Май, 2008 15:22 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

Автор:  AVC [ Четверг, 29 Май, 2008 19:51 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

Илья Ермаков писал(а):
Здесь обсуждалось:
viewtopic.php?f=8&t=972&start=0
Обсуждать -- обсуждали.
Непонятно, к какому пришли выводу.

Автор:  Info21 [ Четверг, 29 Май, 2008 22:46 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

AVC писал(а):
Непонятно, к какому пришли выводу.


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

Автор:  AVC [ Пятница, 30 Май, 2008 00:12 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

Info21 писал(а):
AVC писал(а):
Непонятно, к какому пришли выводу.


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

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

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

Автор:  Info21 [ Пятница, 30 Май, 2008 09:09 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

AVC писал(а):
... Метцелер (если не ошибаюсь, прямой начальник Александра Ильина) писал ...

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

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

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

Автор:  AVC [ Пятница, 30 Май, 2008 21:01 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

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

Автор:  Geniepro [ Пятница, 30 Май, 2008 23:52 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

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

Автор:  Илья Ермаков [ Суббота, 31 Май, 2008 00:34 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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


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


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

Автор:  AVC [ Суббота, 31 Май, 2008 01:09 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

Автор:  Александр Ильин [ Суббота, 31 Май, 2008 07:12 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

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

Автор:  Wlad [ Суббота, 31 Май, 2008 09:54 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

Автор:  AVC [ Суббота, 31 Май, 2008 11:46 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

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

Автор:  Info21 [ Суббота, 31 Май, 2008 12:32 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

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

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

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

Автор:  Info21 [ Суббота, 31 Май, 2008 12:39 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

AVC писал(а):
Что касается исключения LOOP ...

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

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

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

Автор:  AVC [ Суббота, 31 Май, 2008 12:48 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

Info21 писал(а):
По умолчанию -- first choice -- подпроцедура вынесена на уровень модуля, инфу получает через параметры.

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

Автор:  AVC [ Суббота, 31 Май, 2008 12:57 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

Автор:  AVC [ Суббота, 31 Май, 2008 14:00 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

Info21 писал(а):
AVC писал(а):
Что касается исключения LOOP ...

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

Автор:  Info21 [ Суббота, 31 Май, 2008 14:07 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

AVC писал(а):
Просто я немного побаиваюсь, что Вирт (вдруг) возьмет и запретит ... :)

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

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

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

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

Автор:  AVC [ Суббота, 31 Май, 2008 21:19 ]
Заголовок сообщения:  Re: ... the recommended style becomes predominantly functional.

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

Вроде бы из теории Дейкстры именно эта возможность и следует.
А как это может выглядеть на практике?
Допустим, у меня есть типичный LOOP:
LOOP
    куча кода;
    IF что-то там THEN тоже не сижу сложа руки; EXIT END;
    еще куча кода
END

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

Страница 1 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/