Является ли оператор && строгим в Haskell?

Функция (&&) является строгой по второму аргументу, только если ее первый аргумент равен True. Он всегда строг в своем первом аргументе. Вот эта строгость/лень и гарантирует порядок оценивания.

Так что он ведет себя точно так же, как C. Разница в том, что в Haskell (&&) — это обычная функция. В C это было бы невозможно.

Но Haskell ленив, и, как правило, нет гарантии, какая операция выполнится первой, пока мы не используем seq, $! или что-то еще, чтобы сделать наш код строгим.

Это неправильно. Истина глубже.

Ускоренный курс строгости:

Мы знаем, что (&&) является строгим в своем первом параметре, потому что:

⊥ && x = ⊥

Здесь ⊥ — это что-то вроде undefined или бесконечного цикла (⊥ произносится как «нижний»). Мы также знаем, что (False &&) не является строгим во втором аргументе:

False && ⊥ = False

Он не может оценить свой второй аргумент, потому что его второй аргумент равен ⊥, который не может быть оценен. Однако функция (True &&) является строгой по второму аргументу, потому что:

True && ⊥ = ⊥

Итак, мы говорим, что (&&) всегда является строгим по первому аргументу и строгим по второму аргументу только тогда, когда первый аргумент равен True.

Порядок оценки:

Для (&&) свойств строгости достаточно, чтобы гарантировать порядок выполнения. Это не всегда так. Например, (+) :: Int -> Int -> Int всегда является строгим в обоих аргументах, поэтому любой аргумент может быть оценен первым. Однако вы можете заметить разницу, только перехватывая исключения в монаде IO или используя функцию unsafe.

Как отмечали другие, естественно, (&&) является строгим в одном из своих аргументов. По стандартному определению он строг в своем первом аргументе. Вы можете использовать flip, чтобы перевернуть семантику.

В качестве дополнительного примечания: обратите внимание, что аргументы (&&) не могут иметь побочных эффектов, поэтому есть только две причины, по которым вам нужно заботиться о том, является ли x && y строгим в y:

• Производительность: если y вычисление занимает много времени.
• Семантика: Если вы ожидаете, что y может быть внизу.

Haskell ленив, и, как правило, нет гарантии, какая операция будет выполнена первой.

Не совсем. Haskell чист (за исключением unsafePerformIO и реализации IO), и нет возможности наблюдать, какая операция будет выполняться первой (кроме unsafePerformIO и реализации IO). . Порядок выполнения просто не имеет значения для результата.

&& имеет таблицу истинности с 9 значениями, включая случаи, когда один или оба аргумента равны undefined, и точно определяет операцию:

a           b           a && b
True        True        True
True        False       False
True        undefined   undefined
False       True        False
False       False       False
False       undefined   False
undefined   True        undefined
undefined   False       undefined
undefined   undefined   undefined

Пока реализация следует за этой таблицей, ей разрешено выполнять действия в любом порядке.

(Если вы изучите таблицу, то заметите, что последовательная реализация не может следовать ей, если она не выполняет сначала a, а затем b, если a равно True. Но реализации Haskell не обязательно должны быть последовательно! Реализации всегда разрешено запускать выполнение b, когда она захочет; ваша единственная гарантия заключается в том, что, согласно таблице, результат выполнения b может повлиять на вашу программу только тогда, когда a имеет значение True. )

(Обратите внимание, что «лень» — это единственный способ написать функцию с таблицей истинности, подобной приведенной выше; в таких языках, как C или ML, все пять строк с undefined в любом аргументе будут быть принудительно иметь undefined в качестве результата, тогда как в Haskell (и в C, поскольку && встроено в язык C) одна из строк может вместо этого иметь False в качестве результата.)

Я считаю, что это работает так, как вы ожидаете; оценить RHS, если LHS оценивается как True. Однако, если предположить, что RHS не имеет побочных эффектов, как бы вы узнали (или позаботились)?

Редактировать: я думаю, что RHS может быть undefined, и тогда вам будет все равно...