Выход из цикла или смерть Кощея

[Geniepro]

Кто Вам такое сказал? о_О

Мне такое сказали авторы книги Real World Haskell http://book.realworldhaskell.org/read/monads.html

Note, though, that the chain is not completely short-circuited. Each (>>=) or (>>) in the chain will still match a Nothing on its left, and produce a Nothing on its right, all the way to the end. It's easy to forget this point: when a computation in the chain fails, the subsequent production, chaining, and consumption of Nothing values is cheap at runtime, but it's not free.

И обманули, гады 

Какой-то странный абзац, и не удивительно, что он вызвал там кучу удивлённых комментов.
Вот простейший тест:

Код: [Выделить]

mbDiv :: Integer -> Integer -> Maybe Integer
x `mbDiv` 0 = Nothing
x `mbDiv` y = Just $ x `div` y

resultOk = do
    x <- 10 `mbDiv` 5
    y <- 10 `mbDiv` 0               -- тут возвращается Nothing
    z <- return $ Just $ 10 `div` 0 -- и до сюда вычисление не доходит
    return z

resultBad = do
    x <- 10 `mbDiv` 5
    y <- 10 `mbDiv` 1               -- тут возвращается Just 10
    z <- return $ Just $ 10 `div` 0 -- и здесь падаем по делению на ноль
    return z

Код: [Выделить]

*Main> resultOk
Nothing
*Main> resultBad
Just (Just *** Exception: divide by zeroВсё нормально, монада Maybe работает правильно, как и должна.

[Geniepro]

Как-то я переусложнил тестовый пример, так проще:

Код: [Выделить]

result = do
    x <- Just 'x'
    y <- Nothing
    z <- Just 'z'
    return z

Код: [Выделить]

Main> result
Nothing

[ilovb]

Ведь и в самом первом варианте Алмазова достаточно вместо внутреннего if игла # NIL then break вынести & (игла = NIL) в условие цикла.

Чет я пропустил. Оказывается уже упоминалось до меня 

[DddIzer]

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

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

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

Все остальные предложенные "разновидности" - не знаю для чего могут понадобиться.

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

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

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

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

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

Кроме того, что функция может быть чистой и грязной (с побочными эффектами), она ещё может быть тотальной (гарантированно успешно завершится) и не тотальной (может выдать ошибку или никогда не завершиться).
Например, f(x)=5/x может выдать деление на ноль, и хоть она и является чистой, тотальной она не является.

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

Если параметр-переменная "заяц" здесь ссылочная, то присвоение "результата" функции переменной заяц^, это само по себе глобальный эффект.

1. Я не считаю конкретно это изменение ПОБОЧНЫМ эффектом - хотя конечно это изменяет глобальное окружение
2. Вы черезчур сильно обобщаете свои рассуждения - следуя этому пути можно всегда предположить, что в одной из этих процедур есть и традиционный побочный эффект (прямое изменение значения глобальной  переменной не передающейся через интерфейс подпрограммы).. а раз так то и задача не имеет смысла...

1. А я считаю, по этой же причине. Такая "функция" является тривиально чистой, она тождественная, потому что "результат" здесь это само ссылочное значение "заяц" (а не "заяц^") равное ссылочному аргументу "заяц" (если конечно "функция" не меняет его значение).
2. Изменение значения глобальной переменной даже передающейся через интерфейс подпрограммы (как параметр-переменная) тоже является побочным эффектом. У функции без побочного эффекта не должно быть VAR/OUT-параметров.
Почему задача не имеет смысла? Не обязательно использовать функции. Требования использовать функции без побочного эффекта тоже нет в условии задачи. Только минимизация числа извлечений и сохранение промежуточных результатов.

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

Если так рассуждать - то Хаскели и проч. "чистые" ФЯВУ  - не только таковыми не являются - но потенциально гораздо более опасны чем императивные ЯП.

"Чистые" ФЯВУ по сути это одни выражения, и никаких операторов.
Если мы хотим изменить "глобальное окружение" в "чистом" ФЯВУ (например, записать в лог), мы должны влючить значение этого "глобального окружения" в параметр функции, а затем вывести новое значение этого "глобального окружения" как компоненту результата.

1. По всей видимости разница. в восприятии.. вы трактуете данную ситуацию как использование чистой функции вообще... я  как использование функции  без побочного эффекта в данной задаче... скорее всего неправ я...
2. С чего бы это (точнее  не всегда) - если речь идет о классическом (пошаговом, детерменированном) алгоритме  в однозадачной системе то по возвращаемое функцией в ссылочном значении эквивалентно  чистому присваиванию (а возможные переприсваивания внутри функции не влекут изменения в глобальном окружении) - можно  конечно более точно  привести необходимые и достаточные условия для этого.. но - см. п1.
3.  Я воспринял задачу так - как необходимость использовать функцию не содержащую побочный эффект - причем эффект вынужденный (следующий из паттерна решения  основной задачи но не родственный природе самой функции).
4.Я имел ввиду другое.. реально программа в функциональном яп транслируется в си.. и далее... который вполне императивен.. -  вы можете сказать когда создаются  фактические динамические переменные , а когда нет?.. между тем согласно вашей же фразе (если я правильно ее понял) любое создание динамической переменной есть побочный эффект... отсюда вывод фяву- в общем случае языки с неконтролируемым побочным эффектом ...

[Peter Almazov]

Ведь и в самом первом варианте Алмазова достаточно вместо внутреннего if игла # NIL then break вынести & (игла = NIL) в условие цикла.

Чет я пропустил. Оказывается уже упоминалось до меня 

Илье не помогло гадание на драконной гуще и он вляпался в новое ...

[Илья Ермаков]

А что, собственно, не так?

trurl увидел сразу этот вариант, который я бы тоже написал с нуля, если бы столкнулся с такой задачей - и мозги не были бы забиты начальной вашей постановкой

[Илья Ермаков]

Пётр, у меня к Вам вопрос, как к человеку, знания которого я уважаю.

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

Вы считаете криминальным использование графовой формы, например, в теории схем программ (схем не в визуальном смысле, а в смысле моделей, на которых оптимизирующие компиляторы строятся и проч.)? В новосибирских работах типа В. Е. Котов, В. К. Сабельфельд Теория схем программ М.: Наука, 1991. Или работы Касьянова и Евстигнеева. Это же классика теории программирования. Почему применение "каких-нибудь" схем Янова для анализа свойств программ - не криминал, а применение ДРАКОНа - да? Или Вы считаете, что "всё это хрень"?

[Илья Ермаков]

Вот что интересует в ДРАКОНе - возможности в этом плане:

[Peter Almazov]

А что, собственно, не так?

trurl увидел сразу этот вариант, который я бы тоже написал с нуля, если бы столкнулся с такой задачей - и мозги не были бы забиты начальной вашей постановкой

"Не так"?!
Ну, мля, как дворниками пообщался.
Сказано же, тело цикла выполняется лишний раз. Здесь это "i=i+1".
Но тело цикла может быть несколько другим.
Н-р, "Достать очередной сундук со дна Марианской впадины".
Или "Уничтожить протоколы разборки сундука, как не оправдавшего надежд, на то что там окажется игла".
Но нашим пейсателям все равно.
-А, давайте ткнем проверку игла <> null в заголовок цикла?
-Давайте! Не изврата ради, а токмо "правильного постусловия" для.

После общения с такими гражданами хочется вымыть руки.

[Peter Almazov]

Вы считаете криминальным использование графовой формы, например, в теории схем программ (схем не в визуальном смысле, а в смысле моделей, на которых оптимизирующие компиляторы строятся и проч.)? В новосибирских работах типа В. Е. Котов, В. К. Сабельфельд Теория схем программ М.: Наука, 1991. Или работы Касьянова и Евстигнеева. Это же классика теории программирования. Почему применение "каких-нибудь" схем Янова для анализа свойств программ - не криминал, а применение ДРАКОНа - да? Или Вы считаете, что "всё это хрень"?

Не надо смешивать уважаемых людей с запредельно безграмотной околодраконной публикой.

[Kemet]

Для полноты картины ещё добавлю Р-схему модифицированного варианта моего решения. Модификация в плане сокращения записи.

Код: [Выделить]

$==========================================================================$
!                                                                          !
!НЕ Нашли И                                                                !
!ЕСТЬ(сундуки)     ПУСТО(заяц)                                             !
!------------->$---------------------------------------------------------->!
 ВЗЯТЬ(сундук) !                                                           !
 ЗАЯЦ(сундук)  !           ПУСТО(утка)                                     !
               !--------->$----------------------------------------------->!
                УТКА(заяц)!                                                !
                          !           ПУСТО(яйцо)                          !
                          !--------->$------------------------------------>!
                           ЯЙЦО(утка)!                                     !
                                     !            ПУСТО(игла)              !
                                     !--------->$------------------------->!
                                      ИГЛА(яйцо)!                          !
                                                !             ПУСТО(смерть)!
                                                !----------->$------------>!
                                                 СМЕРТЬ(игла)!             !
                                                             !             !
                                                             !------------>!
                                                              Нашли := ДА



[albobin]

А что, собственно, не так?

"Не так"?!  ... Но нашим пейсателям все равно.

Могу тоже сказать:  А что, собственно, не так?   
Идея  размазать while по телу цикла (while+andwhile) не состоятельна по выводу самого автора (Петра) из-за засад.
(Мне она тоже никакого доверия не вызывает.)
Без exit из циклов while можно вполне обходиться.
А придумать можно что  угодно усугубляющее.  Но тогда и решения должны быть соответствующими.
 

[DddIzer]

А придумать можно что  угодно усугубляющее.  Но тогда и решения должны быть соответствующими.

Лично для себя я решил этот вопрос давно..ЕСЛИ ЭТО ВОЗМОЖНО -Я ОРИЕНТИРУЮСЬ НА КОНКРЕТНУЮ ЗАДАЧУ

[Илья Ермаков]

"Не так"?!
Ну, мля, как дворниками пообщался.
Сказано же, тело цикла выполняется лишний раз. Здесь это "i=i+1".
Но тело цикла может быть несколько другим.

Вот пусть оно сначала будет несколько другим, чтобы были веские причины уходить от варианта, который наиболее "прописан" для применения в неотягощённом "марианскими впадинами" случае.

Раскатывать условия из общего условия цикла куда-то в его внутренности - это нужны очень серьёзные агрументы.
Вы в исходном сообщении привели один: операции получения уток-иголок дорогие. Вам и дали решение для этого случая.
Про дороговизну i := i + 1 речи не было.

[Илья Ермаков]

Не надо смешивать уважаемых людей с запредельно безграмотной околодраконной публикой.

При чём тут публика? Это проблемы публики, что ей там "по барабану" логические свойства схемы. Мне - нет и меня именно этот аспект интересует.
Если есть просто конкретная нотация (конкретная топология графов). И конкретные примеры выражения на ней.
Если Вы не можете обсуждать вопрос "по существу", без своей личной идиосинкразии, то это Ваша проблема.