2016-04-07 3 views
3

Так, чтобы мой код выглядел похожим при использовании монад, когда я использую аппликаторы и функторы, я использовал =<< вместо >>=. Я также использовал <* вместо *>/>>. Однако я заметил, что <* НЕ *>, что =<< - >>=.Обратный оператор >> в haskell

Например:

print 5 <* print 6 

дает мне:

5 
6 

Когда я ожидал их на печать наоборот, с print 6 называют, печать 6, а затем результат () получения выбрасывается, а затем вызывает print 5.

После продолжения игры вокруг это кажется <* и *> отличаются только возвращаемыми значениями, а не такими, как функции объединены/упорядочены. В то время как =<< является правильным переворотом >>=, включая переключатель в фиксации слева направо.

мне было интересно, почему это было так (похоже >>= это назад, но это как-то лучше подходит с, а не назад, <*><**> комбинации, даже если подписи типового >>= и <*> перевернуты). Мне также было интересно, есть ли оператор стиля <<, который я мог/должен использовать.

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

+0

Возможный дубликат: http://stackoverflow.com/questions/14176667/why-is-there-no-in-the-haskell-standard-library –

ответ

2

Aye, *> и <* отличаются только своим возвратным значением.

это как-то лучше подходит с, а не назад, <*><**> комбинация, даже если подписи типовым >>= и <*> перевернуты

Я бы не сказал, что подписи >>= и <*> являются переворачивается. Скорее, <*> просто специализирован, чтобы содержать функцию в своем левом аргументе, а затем applied до значения в правом аргументе. Вы можете сделать это с >>= тоже считаете

fs<*>xs ≡ fs >>= \f -> f<$>xs 

Я не думаю, что есть много необходимости аппликативного-эквивалент <<, как нет необходимости в перевернутую версию ++: просто заказать аргументы *> или <* в порядке, который вам нужен для вашей желательной семантики!

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

Er, это не правильно. Версия с parens справа не совсем хорошо написана. Возможно, вы пробовали пример с лямбдами и не принимали их во внимание с вашими парнерами?

+0

«просто закажите аргументы' *> 'или' <* 'в порядке, который вам нужен для вашей желаемой семантики!". Нельзя ли так же сказать о необходимости «= <<' and '>> ='? Также для ассоциативности я имел в виду «(чистый = << чистый) = << чистый 5' против« чистый = << (чистый = << чистый 5) ». – semicolon

+0

Для инфиксных комбинаторов с аргументами функции вам нужно учитывать, что они часто используются с лямбдами (которые дают естественное направление слева направо) или целями без точек (справа налево), поэтому здесь может быть любое направление явная польза. Но это не относится к '*>', как это не для '++'. - Rg. ассоциативность, осторожность: выражение в правом скобках возможно только потому, что существует экземпляр monad функции. «Чистые живут в разных монадах! – leftaroundabout

+0

Если какое-либо направление работает, почему бы не иметь операторов для обоих? Кроме того, Haskell, как правило, не переходит налево, поскольку он является функциональным языком и всеми, и с '$' '.' И просто ''. Мне просто кажется странным, как монада переворачивает все вокруг, и, похоже, он также частично выполняет аппликативный характер: 'print = << (++) <$> getLine <*> getLine' сначала оценивает первую getLine, тогда как серия' = << 'будет оценена справа налево. – semicolon

Смежные вопросы