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 писал(а): Непонятно, к какому пришли выводу. В смысле? Одобрить рекомендацию Вирта или нет? ![]() |
Автор: | AVC [ Пятница, 30 Май, 2008 00:12 ] |
Заголовок сообщения: | Re: ... the recommended style becomes predominantly functional. |
Info21 писал(а): AVC писал(а): Непонятно, к какому пришли выводу. В смысле? Одобрить рекомендацию Вирта или нет? ![]() А потом вызвать Вирта на товарищеский суд. В нашем ЖЭКе. ![]() Просто хочется понять, что именно Вирт имел в виду. Технически, он предлагает отказаться от использования контекста объемлющей процедуры. Это, похоже, он и называет 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) оптимизации. |
Автор: | 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 тоже не сижу сложа руки; еще куча кода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/ |