Ослабить ограничения упорядочения в монадических вычислениях

Эта проблема чрезмерной последовательности монадного кода известна как "проблема коммутативных монад".

Коммутативные монады — это монады, для которых порядок действий не имеет значения (они коммутируют), то есть при следующем коде:

do a <- f x
   b <- g y
   m a b

такой же как:

do b <- g y
   a <- f x
   m a b

есть много коммутирующих монад (например, Maybe, Random). Если монада коммутативна, то захваченные в ней операции могут быть вычислены, например, параллельно. Они очень полезны!

Однако у нас нет хорошего синтаксиса для коммутирующих монад, хотя многие люди спрашивали о такой вещи - это все еще открытая исследовательская задача.

Кроме того, аппликативные функторы дают нам такую ​​свободу переупорядочивания вычислений, однако вы должны отказаться от понятия bind (как показывают предложения, например, для liftM2).

Это глубокий грязный хак, но, похоже, он должен помочь мне.

{-# OPTIONS_GHC -fglasgow-exts #-}
{-# LANGUAGE MagicHash #-}
module Unorder where
import GHC.Types

unorder :: IO a -> IO b -> IO (a, b)
unorder (IO f) (IO g) = IO $ \rw# ->
           let (# _, x #) = f rw#
               (# _, y #) = g rw#
           in (# rw# , (x,y) #)

Поскольку это передает недетерминизм в руки компилятора, он должен вести себя "правильно" (т.е. недетерминированно) и в отношении вопросов потока управления (т.е. исключений).

С другой стороны, мы не можем провернуть тот же трюк с большинством стандартных монад, таких как State и Either a, поскольку мы действительно полагаемся на жуткие действия на расстоянии, доступном при воздействии с токеном RealWorld. Чтобы получить правильное поведение, нам понадобилась бы некоторая аннотация, доступная оптимизатору, которая указывала бы, что мы согласны с недетерминированным выбором между двумя неэквивалентными альтернативами.

Семантика C на самом деле не указывает, в каком порядке будут оцениваться вызовы этих двух функций, поэтому компилятор может перемещать вещи по своему усмотрению.

Но что, если doSomething() вызовет побочный эффект, который изменит поведение doSomethingElse()? Вы действительно хотите, чтобы компилятор возился с порядком? (Подсказка: нет) Тот факт, что вы вообще находитесь в монаде, предполагает, что это может быть так. Ваше замечание о том, что «вы теряете обмен результатами», также предполагает это.

Однако обратите внимание, что монадический не всегда означает последовательный. Это не совсем то, что вы описываете, но вас может заинтересовать Par monad, которая позволяет выполнять ваши действия параллельно.

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

Примечание: не путайте return в Haskell с чем-то вроде return в C.