Здравствуйте, Sinclair, Вы писали:

ГВ>>Это определение сферического коня в вакууме. У тебя миелофон за шкафом не завалялся?
S>При чём тут миелофон?

Про другие детекторы стиля мышления мне неизвестно.

ГВ>>К сожалению, почти вся дискуссия показывает, что эти подробности не избыточны.
S>К сожалению, почти вся дискуссия показывает, что люди с заметным усердием занимаются terms misinterpretation. Причем цели этого намеренного непонимания лично мне остаются неясными.

Ой, сколько колкостей по этому поводу вертится у меня на клавиатуре... Ладно, замнём для ясности.

ГВ>>Отлично. Вот этого я и добивался. Теперь объясни ещё пару вещей: что такое техника программирования в данном случае? Это способ декомпозиции, семантика языковых конструкций, какой-то специфический синтаксис, ещё что-то?
S>Геннадий, не нужно включать дурака. Перечитай исходное сообщение, на которое ты столь невежливо ответил:
S>

S>Это способ декомпозиции любого алгоритма на операции модификации, ветвления, и перехода, применяемые к некоторому глобальному состоянию

Не надо выдёргивать цитату из контекста:

Это не должность, а именно стиль мышления. Это способ декомпозиции любого алгоритма на операции модификации, ветвления, и перехода, применяемые к некоторому глобальному состоянию.

Честно говоря, после "стиль мышления" я выпал в настолько плотный осадок, что остальное уже было несущественным. То есть "плавный" переход от субъекта к объекту остался незамеченным. То есть ты называешь способ декомпозиции стилем мышления. Эх, сила слова! Ух, полёт мысли!

Не дела ради, а курьёзу для, попробуем обсудить означенный тобой способ декомпозиции и возможность его существования. И здесь вопросов снова больше, чем ответов. Например, так ли уж любой алгоритм подвергается привязке только к глобальным данным? Кроме того, если набор императивных конструкций ограничен модификацией, переходом и ветвлением (условным переходом), то по логике вещей, и вся программа должна представлять собой сплошной спагетти из if/goto. Если это так, то напрашивается мысль о том, что "императивный программист" — это либо сферический конь в вакууме, либо, в крайнем случае, очень-очень начинающий, поскольку на практике такие программы хоть и бывают, но они либо весьма ограничены в размерах, либо встречаются крайне редко. Оба предполагаемых явления не слишком достойны того, чтобы с ними бороться. Либо я чего-то в твоих рассуждениях не понимаю.

P.S.: Вопрос о мышлении по-прежнему остаётся открытым.

T>>То есть, я прав по всем пунктам.
T>>Ну, а я проектировал системы так и сяк, а ещё поддерживал такие и сякие системы. "Хорошо быть мной!" Сякие, правда, меньше, чем такие, но и нужда в них отпадала быстрей.
LP>Ты спрашиваешь у меня, проектировал ли я системы на Хаскеле, в том время как систем-то этих если и есть, то три штуки на всю планету.

Здесь мы имеем случай так называемого вранья.

Даже на RSDN найдётся десяток-другой товарищей, проектировавших такие системы.

LP>Само собой, можно ткнуть почти в любого, то ответ будет таким же, что же, из этого следует, что никто тебе возразить не сможет? Чушь какая-то, имхо.

С чего бы это? Возражать мне можно, но обоснованно возражать получится после того, как приобретёшь опыт.

Фундамент твоих возражений сейчас строится на основе "когда я работал с этим, я считал, что работаю в функциональном стиле, поэтому я про этот стиль всё знаю".

Слабость состоит в том, что внешней проверки твоего мнения (правильно ли ты считал с точки зрения третьего лица) нет. Твой опыт работы в ФП воображаемый, не настоящий. В действительности всё не так.

Но ты можешь продолжать возражать.

T>>>>Например, ты не можешь получить (по крайней мере, простым путём) окошко для наблюдения за внутренностями другой системы.
LP>>>Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.
T>>К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.

LP>Передергивание было у тебя, когда ты пытался представить модуль написанный на ФЯ чисто функциональным. Где у меня передергивания, в упор не вижу.

"Абсолютно бесполезна".

К сведению. Подавляющее большинство программ может быть написана на не-Тьюринг-полных языках. То есть, на чистом тотальном ФЯ.

LP>К тому никакой я не фанат императивного программирования. Я очень даже за ФП, просто считаю, что оно имеет границы применимости, в отличие от тебя.

ФП Тьюринг-полно. Поэтому границ у него ровно столько же, сколько и у безгранично применявшегося до 1983 года императивного программирования.

T>>>>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.
LP>>>Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.
T>>Контракты ты как описывать будешь? Pre/postconditions? Нет? А как?
LP>Да, пред- и пост-условия, описывающее взаймодействие клиента и модуля. При чем здесь ФП и ООП? Может быть, тебя смущает, что понятие контракта было введено Мейерсом в рамках ООП?

Меня смущает состояние. Императивщина.

T>>>>Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею.
LP>>>Если реализация оказывает влияние, тогда проектирование неправильное.
T>>Чем быстрей ты выяснишь ошибку, связанную с реализацией, тем лучше.
T>>Неужто твой контракт всегда может быть реализован в любой парадигме?
LP>Контракты, они конечно могут быть самыми разными. Например, некоторые предусловия императивного модуля в общем случае функциональнй модуль выполнить не сможет (в отличие от обратного случая). Но если сузить это понятие, скажем, до состояния структур данных, то да, практически при любой. К тому же я уже сказал, что "полностью функциональный модуль" — это сферический конь в вакууме. Для взаймодействия с остальными модулями разумнее использовать императивные интерфейсы и контракты. Это, конечно, мое мнение.

Ну, вот и реализация вылезла.

Ура!

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, gandjustas, Вы писали:


FR>>>Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает.
FR>>>А F# похоже не только функторы по пути растерял
G>>Дык у него вообще ленивости на уровне языка нету.

FR>Ключевое слово lazy тоже отсутствует?
lazy — сахар для Lazy<T>. Причем вы можете свой аналогичный сахар в F# делать в любых количествах.

G>>Я же и говорю что очень удобно было бы в .NET языках задавать ленивость декларативно.

FR>В Ocaml это делается декларативно через Caml4p, например синтаксис потоков
FR>http://shamil.free.fr/comp/ocaml/html/book004.html#htoc62 или даже ленивые списки
FR>в Haskell стиле http://www.y-node.com/blog/2008/aug/04/ocamllazylists/
Круто, может когда-нибудь ркуи дойдут до изучения окамла.

Здравствуйте, gandjustas, Вы писали:

FR>>Ключевое слово lazy тоже отсутствует?
G>lazy — сахар для Lazy<T>.

Так и в окамле lazy сахар для lazy_t

G>Причем вы можете свой аналогичный сахар в F# делать в любых количествах.

Интересно как?

Здравствуйте, EvilChild, Вы писали:
EC>Требование к глобальности состояния обязательное?
Да.
EC>Если да, то почему?
Потому, что контекстов, в которых состояние могло бы быть локально, еще нету. Любая операция в программе может воспользоваться результатами любой другой. См. Машина Тьюринга, Машина Поста.

Для того, чтобы у понятия "локальное состояние" появился смысл, нужно вводить некие контексты. Чем, в частности, занимается процедурное программирование (как развитие императивного).

T>>А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания?
G>Нельзя. В энергичных языках zeros в правой части будет пытаться вычислиться.
G>Но в F# вполне можно написать так: let rec zeros = seq{ yield 0; yield! zeros}. И никакого расхода памяти.
G>На C# так сделать не получится, нету оптимизации хвостовой рекурсии.
G>Хотя для бесконечной последовательности нулей в .NET есть более простые способы.

Это была прелюдия.

А вот основная тема: Generating power of lazy semantics

zeroes — это нулевой бесконечный степенной ряд.

Если нужна ленивость по умолчанию не для списков, то можешь попробовать multivariate higher-order automatic differentiation. Ноотропил стоит в районе 200-250 рублей за упаковку, однако, поэтому это может быть достаточно дорогое удовольствие.

T>>Напишите свои примеры, если угодно. Я их тоже рассмотрю, если они будут того стоить.
T>>Одно условие — надо написать и в ленивом, и в энергичном стиле и хотя бы намекнуть, почему ленивый стиль будет хуже.
T>>Буду признателен.
G>Я не говорил что будет хуже.
G>Я сомневаюсь что с ленивостью по умолчанию для не-списков будет лучше.
G>А учитывая приколы реализацией ленивости в хаскеле (утечки и прочее) может быть и гораздо хуже.

Внимание, вопрос: как бывает наиболее часто? Хуже или лучше? Как изменяется пропорция "хуже-лучше" со временем?

T>>К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.
FR>А еще штангой мозги пудрил, я уже присматриватся начал какую купить, тем более раньше много ТФТ занимался, думал в изучении хаскеля поможет, но теперь ясно грибы рулят

Без грибов с Хаскелем никак. Точнее, либо без штанги, либо без грибов.

Ну, ещё бегать можно.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Про другие детекторы стиля мышления мне неизвестно.
Еще раз: мы говорим об абстрактных вещах. Вопросы детектирования здесь совершенно неуместны.

ГВ>Не надо выдёргивать цитату из контекста:

ГВ>

Это не должность, а именно стиль мышления. Это способ декомпозиции любого алгоритма на операции модификации, ветвления, и перехода, применяемые к некоторому глобальному состоянию.

ГВ>Честно говоря, после "стиль мышления" я выпал в настолько плотный осадок, что остальное уже было несущественным.
Наличие осадка вижу. Причин считать остальное несущественным — не вижу.

ГВ>То есть "плавный" переход от субъекта к объекту остался незамеченным. То есть ты называешь способ декомпозиции стилем мышления.
Хорошо. Речь идет о стиле мышления, для которого типичен именно указанный способ декомпозиции.
Суть беседы пока что сводится к тому, что выражение "У Мэри есть ягненок" тебя не устраивает, а самостоятельно выполнить переход к "гражданка Мария Джонс осуществляет ограниченное право владения объектом животноводства, не достигшим репродуктивного возраста" ты не хочешь.

ГВ>Не дела ради, а курьёзу для, попробуем обсудить означенный тобой способ декомпозиции и возможность его существования.
Отлично. Достаточно подробно вопрос существования такого способа декомпозиции программ освещен в работах Тьюринга, Поста, Чёрча, и многих других.

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

ГВ>Кроме того, если набор императивных конструкций ограничен модификацией, переходом и ветвлением (условным переходом), то по логике вещей, и вся программа должна представлять собой сплошной спагетти из if/goto.
Совершенно верно. См. например алгоритм Евклида. Есть какие-то сомнения в том, что он представляет собой сплошное спагетти из if/goto и присваиваний?

ГВ>Если это так, то напрашивается мысль о том, что "императивный программист" — это либо сферический конь в вакууме,
Ага, похоже начинаются проблески понимания.
ГВ>либо, в крайнем случае, очень-очень начинающий, поскольку на практике такие программы хоть и бывают, но они либо весьма ограничены в размерах, либо встречаются крайне редко.
Совершенно верно. Расширим модель "императивного программиста" до "процедурного программиста".
У него в арсенале появляются новые конструкции, в частности процедуры.
Это даёт ему более богатые возможности декомпозиции алгоритма, но принципиально ничего не меняется — по-прежнему есть разделяемое состояние, с которым идет работа. По-прежнему основным инструментом является if, иногда замаскированный под while/for/until. Даже итерация по массиву/списку выполняется при помощи явной модификации переменной.

ГВ>Оба предполагаемых явления не слишком достойны того, чтобы с ними бороться. Либо я чего-то в твоих рассуждениях не понимаю.
Не вижу ничего особенно редкого в императивном программировании. Вон по соседству Павел Дворкин постоянно съезжает на то, что декларативное программирование мешает ему точно указать, в каком порядке в какие регистры складывать данные.

ГВ>P.S.: Вопрос о мышлении по-прежнему остаётся открытым.
Многие вещи непонятны нам не оттого, что понятия наши слабы, а оттого, что они не входят в круг наших понятий. Это не о тебе, а об "императивных программистах". Влад пытается расширить круг понятий у тех людей, у которых он узкий. Не вижу причин считать это личным оскорблением.

Здравствуйте, thesz, Вы писали:

T>Но ты можешь продолжать возражать.

Если вам угодно, воспользуюсь столь милостивым разрешением и продолжу спор.

T>>>>>Например, ты не можешь получить (по крайней мере, простым путём) окошко для наблюдения за внутренностями другой системы.
LP>>>>Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.
T>>>К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.

LP>>Передергивание было у тебя, когда ты пытался представить модуль написанный на ФЯ чисто функциональным. Где у меня передергивания, в упор не вижу.

T>"Абсолютно бесполезна".

T>К сведению. Подавляющее большинство программ может быть написана на не-Тьюринг-полных языках. То есть, на чистом тотальном ФЯ.

LP>>К тому никакой я не фанат императивного программирования. Я очень даже за ФП, просто считаю, что оно имеет границы применимости, в отличие от тебя.

T>ФП Тьюринг-полно. Поэтому границ у него ровно столько же, сколько и у безгранично применявшегося до 1983 года императивного программирования.

Ты это говоришь, прекрасно зная, что полнота по Тьюрингу тут не при чем. Мол, милое дело развести императивного лошка подменой понятий. Полнота по Тьюрингу в данном случае ровно ничего не значит, поскольку она касается только вычислительного процесса. А программы, знаешь ли, помимо вычислений занимаются многими другими интересными вещами. Например, окошки выводят с кнопочками, пишут на диск (кто бы мог подумать!) и делают еще много чего, что не относится к вычислениям.

T>>>>>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.
LP>>>>Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.
T>>>Контракты ты как описывать будешь? Pre/postconditions? Нет? А как?
LP>>Да, пред- и пост-условия, описывающее взаймодействие клиента и модуля. При чем здесь ФП и ООП? Может быть, тебя смущает, что понятие контракта было введено Мейерсом в рамках ООП?

T>Меня смущает состояние. Императивщина.

Почему? Пусть твои модули, по крайней мере большинство будут функциональными, а их склейка — императивной, что в этом такого?

То есть будет висеть такое состояние:

State a;

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

State cleanFunction(State)

и потом собирать изменения в ограниченном числе императивных функции, тем более хаскель позволяет отделять такие функции по типу.

В результате мы получим почти true-функциональный дизайн внутри модулей и имеративную склейку между модулями. Что плохого в этом?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, EvilChild, Вы писали:
EC>>Требование к глобальности состояния обязательное?
S>Да.
EC>>Если да, то почему?
S>Потому, что контекстов, в которых состояние могло бы быть локально, еще нету. Любая операция в программе может воспользоваться результатами любой другой. См. Машина Тьюринга, Машина Поста.

S>Для того, чтобы у понятия "локальное состояние" появился смысл, нужно вводить некие контексты. Чем, в частности, занимается процедурное программирование (как развитие императивного).
Ты, как-то неожиданно для меня узко трактуешь понятие императивного программирования.
Я правильно понимаю, что процедурное программирование, ты, не рассматриваешь как императивное?

Здравствуйте, EvilChild, Вы писали:
EC>Я правильно понимаю, что процедурное программирование, ты, не рассматриваешь как императивное?
Я рассматриваю процедурное программирование как развитие императивного: то есть мы добавляем в императивное программирование пару конструкций, которые позволяют нам быстрее писать программы. Тем не менее, главное остаётся на месте: у нас по-прежнему есть неявное глобальное (с точки зрения операторов) состояние, которым мы манипулируем.

Здравствуйте, Sinclair, Вы писали:

S>Я рассматриваю процедурное программирование как развитие императивного: то есть мы добавляем в императивное программирование пару конструкций, которые позволяют нам быстрее писать программы. Тем не менее, главное остаётся на месте: у нас по-прежнему есть неявное глобальное (с точки зрения операторов) состояние, которым мы манипулируем.
Нельзя ли конкретизировать эти конструкции? Хотя бы пару ключевых. И указать роль глобального состояния в нём.
А то получается, что оно вроде как тоже императивное, но из твоего определения совершенно неясно в какой степени к нему применимы рассуждения справедливые для императивного.
Мне вот неочевидно почему в нём обязательно должно быть глобальное состояние.

Здравствуйте, Sinclair, Вы писали:

EC>>Я правильно понимаю, что процедурное программирование, ты, не рассматриваешь как императивное?
S>Я рассматриваю процедурное программирование как развитие императивного: то есть мы добавляем в императивное программирование пару конструкций, которые позволяют нам быстрее писать программы. Тем не менее, главное остаётся на месте: у нас по-прежнему есть неявное глобальное (с точки зрения операторов) состояние, которым мы манипулируем.

Получается, что вот здесь у нас есть состояние:

int sum( int[] a ) {
  int r = 0;
  for( int i = 0; i != a.length; ++i )
    r += a[ i ];
  return r;
}

А вот здесь его уже нет?

int sum( int[] a ) {
  int sum_impl( int[] a, int index, int result ) {
    if( index != a.length )
      return sum_impl( a, i + 1, result + a[ index ] );
    else
      return result;
  }
  return sum_impl( a, 0, 0 );
}

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Sinclair, Вы писали:

EC>>>Я правильно понимаю, что процедурное программирование, ты, не рассматриваешь как императивное?
S>>Я рассматриваю процедурное программирование как развитие императивного: то есть мы добавляем в императивное программирование пару конструкций, которые позволяют нам быстрее писать программы. Тем не менее, главное остаётся на месте: у нас по-прежнему есть неявное глобальное (с точки зрения операторов) состояние, которым мы манипулируем.

E>Получается, что вот здесь у нас есть состояние:
E>

E>int sum( int[] a ) {
E>  int r = 0;
E>  for( int i = 0; i != a.length; ++i )
E>    r += a[ i ];
E>  return r;
E>}
E>

E>А вот здесь его уже нет?
E>

E>int sum( int[] a ) {
E>  int sum_impl( int[] a, int index, int result ) {
E>    if( index != a.length )
E>      return sum_impl( a, i + 1, result + a[ index ] );
E>    else
E>      return result;
E>  }
E>  return sum_impl( a, 0, 0 );
E>}
E>

Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.

Здравствуйте, LaPerouse, Вы писали:

LP>Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.

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

Здравствуйте, LaPerouse, Вы писали:

LP>Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.

Кстати стека не будет, там хвостовая рекурсия.

T>>ФП Тьюринг-полно. Поэтому границ у него ровно столько же, сколько и у безгранично применявшегося до 1983 года императивного программирования.
LP>Ты это говоришь, прекрасно зная, что полнота по Тьюрингу тут не при чем. Мол, милое дело развести императивного лошка подменой понятий. Полнота по Тьюрингу в данном случае ровно ничего не значит, поскольку она касается только вычислительного процесса. А программы, знаешь ли, помимо вычислений занимаются многими другими интересными вещами. Например, окошки выводят с кнопочками, пишут на диск (кто бы мог подумать!) и делают еще много чего, что не относится к вычислениям.

Вообще-то, это всё вычисления.

T>>Меня смущает состояние. Императивщина.
LP>Почему? Пусть твои модули, по крайней мере большинство будут функциональными, а их склейка — императивной, что в этом такого?
LP>То есть будет висеть такое состояние:
LP>State a;
LP>И вместо того, чтобы каждая функция изменяла этот a, сделать изменение этого состояния через функции
LP>State cleanFunction(State)
LP>и потом собирать изменения в ограниченном числе императивных функции, тем более хаскель позволяет отделять такие функции по типу.
LP>В результате мы получим почти true-функциональный дизайн внутри модулей и имеративную склейку между модулями. Что плохого в этом?

Таким образом мы не сможем спроектировать дизайн на потоках. Ни на бесконечных списках, ни на потоковых процессорах.

Наличие состояния затрудняет масштабирование решения. В отличии от отсутствия состояния.

Здравствуйте, EvilChild, Вы писали:

EC>Нельзя ли конкретизировать эти конструкции? Хотя бы пару ключевых.
Какой-то повальный отказ от чтения сообщений. Я уже приводил эти конструкции.
Главные, естественно, это выбор, присванивание, и переход.

EC> И указать роль глобального состояния в нём.
Очень просто. Вот у нас простейшая процедурная программа по возведению числа в 5ю степень:

public int Power5(int x)
{
  int power5 = x;
  power5 = power11*x;
  power5 = power11*x;
  power5 = power11*x;
  power5 = power11*x;
  return power5;
}

Обрати внимание, что у нас есть некая переменная power5, состояние которой последовательно меняется. Результат последнего оператора напрямую, но неявно, зависит от того, что положил в эту переменную первый оператор. Это и есть глобальное, с точки зрения отдельных операторов, состояние.
Вся локальность power5 сводится к тому, что мы запрещаем вмешиваться в ее состояние другим процедурам.
Стоит также отметить, что уже здесь мы пользуемся процедурой умножения, которая тоже может быть записана как определенная последовательность ветвлений и присваиваний. То, что в реальных архитектурах такая операция доступна "из коробки", для теории значения не имеет.

EC>А то получается, что оно вроде как тоже императивное, но из твоего определения совершенно неясно в какой степени к нему применимы рассуждения справедливые для императивного.
В полной степени, в полной.
EC>Мне вот неочевидно почему в нём обязательно должно быть глобальное состояние.
А куда же оно денется, это состояние? Вот попробуй переписать Power5 так, чтобы в ней не было состояния.

Здравствуйте, eao197, Вы писали:

E>Получается, что вот здесь у нас есть состояние:
E>

E>int sum( int[] a ) {
E>  int r = 0;
E>  for( int i = 0; i != a.length; ++i )
E>    r += a[ i ];
E>  return r;
E>}
E>

E>А вот здесь его уже нет?
E>

E>int sum( int[] a ) {
E>  int sum_impl( int[] a, int index, int result ) {
E>    if( index != a.length )
E>      return sum_impl( a, i + 1, result + a[ index ] );
E>    else
E>      return result;
E>  }
E>  return sum_impl( a, 0, 0 );
E>}
E>

Совершенно верно. Ну, то есть если мы откажемся от концепции return как таковой, и станем трактовать конструкции как определение смысла функции, тогда получится в чистом виде FP. Никаких присваиваний нет; никакого состояния тоже нет — программа описывает только непреложные факты. Вроде того, что сумма всех чисел в массиве — это сумма одного числа с суммой всех остальных. Этот факт истинен всё время, а не только в момент выхода из подпрограммы.

Здравствуйте, Sinclair, Вы писали:

S>А куда же оно денется, это состояние? Вот попробуй переписать Power5 так, чтобы в ней не было состояния.

let rec power5 x =
    let rec aux acc n = if n=0 then acc else aux (acc * x) (n - 1) in aux 1 5;;