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

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

BZ>поздравляю, ты изобрёл монаду IO

BZ>читай http://haskell.org/haskellwiki/IO_inside

Понял, понял... Уже пошел читать.

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

M>Кстати если где-то есть доступное общечеловеческим языком написанное введение в стрелки — прошу ссылки...

Дак а что там описывать я даж не знаю...
Морфизмы ониж проще пареной репы.
Да и ну функции тебеж объяснять не надо, надеюсь?
А они изоморфны стрелкам

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


К>Морфизмы ониж проще пареной репы.
К>Да и ну функции тебеж объяснять не надо, надеюсь?
К>А они изоморфны стрелкам


Ну то что фунции изоморфны стрелкам допустим. В чем прелесть комбинации мстрелок в отличие от кобинации функций через точку хаскелевую или монадический бинд пояснить смогёшь ?

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

M>Ну то что фунции изоморфны стрелкам допустим. В чем прелесть комбинации мстрелок в отличие от кобинации функций через точку хаскелевую или монадический бинд пояснить смогёшь ?

А я говорил про какую-то прелесть?
Олег, ты чтот не по адресу

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

M>> В чем прелесть комбинации мстрелок в отличие от кобинации функций через точку хаскелевую или монадический бинд пояснить смогёшь ?

К>А я говорил про какую-то прелесть?

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

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

M>Кстати если где-то есть доступное общечеловеческим языком написанное введение в стрелки — прошу ссылки...

тот парень, что написал you could have invented monads, написал и насчёт стрелок. я сам не читал, правда

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

M>Здравствуйте, Курилка, Вы писали:

M>>> В чем прелесть комбинации мстрелок в отличие от кобинации функций через точку хаскелевую или монадический бинд пояснить смогёшь ?

К>>А я говорил про какую-то прелесть?

M>Вопрос к чему. Прелесть не прелесть не суть важно. Имелось ввиду есть ли какое-либо принципиальное различие между стрелками и обычной комбинацией, стоящее того чтобы вводить новую сущность ?

Опять же — эт к любителям стрелок, т.е. снова не особо по адресу

Здравствуйте, Mirrorer, Вы писали:
M>Вопрос к чему. Прелесть не прелесть не суть важно. Имелось ввиду есть ли какое-либо принципиальное различие между стрелками и обычной комбинацией, стоящее того чтобы вводить новую сущность ?

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

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

MC> да нет вроде особо принципиального различия, все суть композиция функций.
Все чудесатей и чудесатей (с).
А если различия нет по каким параметрам оценивать когда использовать одно когда другое?

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

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

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

M>или стрелки и обычная композиция это реализации некоторого интерфейса IComposable,

Как я понял, стрелка это и есть такой интерфейс.

M>но в таком случае у них должно же быть какое-то отличие в реализации..

а реализация композиции функций и стрелок слева направо (когда стрелка — это функция) отличаются только перестановкой аргументов:

instance Arrow (->) where
    -- <...>
    f >>> g = g . f
    -- <...>

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

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

у меня слодилось впечатление, что разница вот в чём:

функции — ты компонуешь последжовательность преобразований данных

монады — компонуешь посл-ть преобразований, помиомо этого у тебя передаётся неявная информация. к примеру, вычлсиление может идти над tuple, а операции описывают манипуляции с первым элементом пары. или вычлсиление идёт над Maybe x, а операции описываются тлько над самим x. ес-но для работы со "скрытой" частью информации используются спец. операции. of course, ты получаешь выигрыш, если тебя главным образом интересует работа с явной частью информации или просто организация посл-ти вычисллений, а обращение к "скрытому состоянию" просиходит лишь в немногих операциях

стрелки — позволяют компоновать вместе операции над несколькими потоками данных. к примеру, стрелка first (*2) >>> second (*3) удваивает второй элемент в tuple и утраивает третий

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

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

Стрелка — это наиболее общий интерфейс, т.к. каждая чистая функция является стрелкой, и функции вида a -> m b, где m — некая монада, — тоже являются стрелками (стрелки Клейсли), а обратное неверно.

Ограниченность чистых функций и стрелок Клейсли заключается в том, что в выражении a >>> b аргументы a и b обязаны быть функциями. Что можно сделать с функцией? Только вызвать, других вариантов — например, паттерн матчинг по значению, — у нас нет.
А стрелка в общем случае может быть каким угодно типом, потому мы можем узнать что-то о стрелке, не "запуская" вычисления в ней.

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

import Control.Arrow

data Stupid a b = Stupid Int (a->b)

numSteps (Stupid n _) = n
apply (Stupid _ f) x = f x

instance Arrow Stupid where
    arr f = Stupid 1 (arr f)
    (Stupid n f) >>> (Stupid m g) = Stupid (m+n) (f >>> g)

test :: Stupid Int String
test = arr (+1) >>> arr show >>> arr (\s -> s ++ s)

main = do print (numSteps test) -- 3
          print (apply test 42) -- "4343"

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

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

Я не очень понял о чем речь, но похоже есть более простой подход... допустить "императившину". Это не так страшно как кажется.

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

M>Хотелось бы донести мысль. Монады можно использовать для реализации императивщины. Для этого они и используются. НО утверждать что они нужны исключительно для этого — неправильно.

А я утверждал? Я не утверждал. Я утверждаю другое. Я утверждаю, что ленивость по умолчанию не стоит того изнасилования головного мозга которое предлагают совершить авторы Хаскеля.

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

M>Кстати еще вариант. Можешь рассматривать монаду IO как аналог unsafe{} блока в c#. То есть у нас везде все managed, но вот в этом конкретном месте к нам проникла опасная грязь.

Не немогу. Если у меня есть unsafe-блок, то меня никто не заставит писать весь вложенный код в опасном режиме. Я могу вызвать из опасного кода безопасный и наоборот. А вот с IO-монадой все не совсем так. К тому же unsafe — это явный хак. Лично я никогда (ну кроме тестов) не применял его. Его с успехом заменяют DllImport и т.п. Вот точно так же (если уж переходить к аналогиям), на мой взгляд более чистям способом будет просто допустить императивность в языке. Ну, а монады если уж они нужны... пусть будут... вот только без того балшита который их обычно сопровождает.