Здравствуйте, BulatZiganshin, Вы писали:
BZ>cps, монады, type classes я бы посчитал продвинутым материалом, которому там не место. но тут конечно надо знать, что там читать, а что скипать :)) я в своё время бросил изучать хаскел из-за того, что в gentle глава о монадах была написана с особым цинизмом :))
Чёрт, а я наоборот, по GentleIntro учился, а YAHT бросил :)
Здравствуйте, Mirrorer, Вы писали:
L>>Значит тебя ещё ждут приключения с комонадами и стрелками :-)
M>А вот такой вопросец. Комонады и стрелки изучать лучше после прокачки в ТК или и без ТК нормально пойдет?
Я ТК, к сожалению, не знаю. Поэтому сравнить не могу.
Здравствуйте, palm mute, Вы писали:
PM>Спасибо . Для меня большая честь получить такой отзыв от автора PM>библиотек, попавших в репозиторий darcs.haskell.org.
Ужас! В декларативном — тишина, а в Философии Монады обсуждають
M>>Теория Категорий. A>А эта ТК имеет отношение к Хаскелю или речь о мат. базисе для изучения?
монады — это объект из теории категорий. для того, чтобы понять *теоретичсекие* основы, которые отцы Хаскела под императвиность подвели, это нужно изучать. есть даже несколько попыток введения в ТК для программистов
я лично не читал, и не собираюсь. как и комонады — практическая польза от них? а вот стрелки используются для более удобной композиции функций, это для *практического* программирования олехно будет прочесть. опять же, ТК я думаю для этого не понадобится
Здравствуйте, BulatZiganshin, Вы писали:
BZ>монады — это объект из теории категорий. для того, чтобы понять *теоретичсекие* основы, которые отцы Хаскела под императвиность подвели, это нужно изучать. есть даже несколько попыток введения в ТК для программистов :)
Моё мнение такое — я смотрю, какие изящные решения были придуманы людьми, и понимаю, что мне пришлось бы долго думать, чтобы до такого додуматься. А люди эти вещи взяли из ТК. Это мой единственный стимул изучения ТК. Брать самому, а не смотреть на то, что дали.
BZ>я лично не читал, и не собираюсь. как и комонады — практическая польза от них? а вот стрелки используются для более удобной композиции функций, это для *практического* программирования олехно будет прочесть. опять же, ТК я думаю для этого не понадобится
Вооооот! А я как раз сейчас балуюсь с комонадами, и многие вещи, для которых используют стрелки (например, сигнальные типы из FRP), прекрасно решаются с помощью комонад. Сейчас у меня к сожалению мало времени, а так я ещё хочу побаловаться с комонадами для написания бэктрекинга. "На бумаге" получается как минимум ничуть нихуже, чем в монадах.
BZ>>монады — это объект из теории категорий. для того, чтобы понять *теоретичсекие* основы, которые отцы Хаскела под императвиность подвели, это нужно изучать. есть даже несколько попыток введения в ТК для программистов
L>Моё мнение такое — я смотрю, какие изящные решения были придуманы людьми, и понимаю, что мне пришлось бы долго думать, чтобы до такого додуматься. А люди эти вещи взяли из ТК. Это мой единственный стимул изучения ТК. Брать самому, а не смотреть на то, что дали.
может быть. мне лично кажется, что для придумывания монад лезть в математику ни к чему. многие монады — это просто невидимая передача состояния. в целом же монады — это нечто вроде "страгегии вычислений". тебе дают отдельные операции, савязанные >>=, и ты можешь определить это >>= как душе угодно. хочешь — можешь порпускать каждую вторую операцию. хочешь — повтори 10 раз и затем сделай "ку!". хочешь — запиши историю всех внутренних значений для отладки. вот и вся премудрость
BZ>>я лично не читал, и не собираюсь. как и комонады — практическая польза от них? а вот стрелки используются для более удобной композиции функций, это для *практического* программирования олехно будет прочесть. опять же, ТК я думаю для этого не понадобится
L>Вооооот! А я как раз сейчас балуюсь с комонадами, и многие вещи, для которых используют стрелки (например, сигнальные типы из FRP), прекрасно решаются с помощью комонад. Сейчас у меня к сожалению мало времени, а так я ещё хочу побаловаться с комонадами для написания бэктрекинга. "На бумаге" получается как минимум ничуть нихуже, чем в монадах.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>может быть. мне лично кажется, что для придумывания монад лезть в математику ни к чему.
Это то да! Но то монады — их уже вытащили из ТК и дали нам разжёванное, а сколько там ещё непопробованного лежит? ;-)
BZ>печально сознавать, что есть люди поумнее меня :))
BZ>>может быть. мне лично кажется, что для придумывания монад лезть в математику ни к чему.
L>Это то да! Но то монады — их уже вытащили из ТК и дали нам разжёванное, а сколько там ещё непопробованного лежит?
а мне кажется, что монады просто вытащили на свет для того, чтобы дать математическое объяснение тому, как это устроен в/в в lazy языках. вот представь — идёшь ты по двору, ловишь кошку, жаришь её, а потом заглядываешь в словарь и найдя там подходящую картинку, объясняешь окружающим — я поймал кошку. а они потом всё лезут и лезут словарь, надеясь нарыть там что-нибудь съедобное
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а мне кажется, что монады просто вытащили на свет для того, чтобы дать математическое объяснение тому, как это устроен в/в в lazy языках. вот представь — идёшь ты по двору, ловишь кошку, жаришь её, а потом заглядываешь в словарь и найдя там подходящую картинку, объясняешь окружающим — я поймал кошку. а они потом всё лезут и лезут словарь, надеясь нарыть там что-нибудь съедобное :))
:) Ну, я попытался объяснить свою позицию в одном из постов. Смысл такой — если я потом залез в словарь и определил кошку, формализовал охоту на неё и т.д. это одно, т.к. дальнейшие мои кошкодомогательства будут более эффективны (производительны) в силу выработанных приёмов, абстракций и т.д. Я зафиксировал паттерн. А вот если я в словарь не полезу, то я потом со второй кошкой и облажаться, т.к. не пойму, что эта животина точно такая же, как и первая. И как её ловить буду придумывать заново.
добрался наконец до ответа на это письмо
M>Монада — это класс реализующий интерфейс IMonad, с >>=, return и т.д. а также удовлетворяющий монадическим законам. С этим понятно.
M>Есть монада State. С ней тоже вроде все понятно состояние и состояние. Его можно передавать по цепочке в неизменном виде, а можно и изменить.
это верно
M>Как только у нас появилась монада State мы можем делать IO. IO тот же State, только в состоянии хранится вся информация необходимая для ввода-вывода. Хендлы открытых файлов, этц. Естественно все это спрятано внутри монады и снаружи все выглядит как обычный интерфейс IMonad(в ООП-шном смысле).
упаси боже. IO и ST — это всего лишь способы упорядочить операции. они нужны потому, что при взаимосдействии с внешним миром нужно вполнять операции строго в заданном порядке, хотя между ними незаметно никакой связи по данным. ну какая например разница, сначала ClrScr сделать, а потом строку вывести, или наоборот?
эти монады через свой фиктивный аргумент RealWorld, который аналогичнсо state путешествует от операции к операции, гаранируют, что операции будут выполнены строго в заданном порядке. в конечном счёте всё упирается в вызовы Сишных функций, которые имеют тип "... -> IO a", т.е. после раскрытия этого type synonym IO, они получают и возвращают некий объект типа RealWorld. а поскольку внутрь этих сишных прцедур не заглянешь, то компилятору остаётся только согласиться с тем, что их действительно надо вызывать в том самом порядке, что описан, поскольку фиг его знает, как там эта процедура "вычисляет" сой выходной RealWorld на основани входных аргументов. вот такой вот обман компилятора
и вся программа таким образом просто-напросто описывает последовательность вызовов этих внешних Сишных процедур и передаваемые им параметры — и ничего больше! с другой стороны, это логично — ведь такие вызовы и есть единственный способ как-то повлиять на внешний мир, верно?
опять-таки, подробней смотрите в моём "IO Inside". ST — это тот же IO, только позволяющий работать лишь с переменными и массивами, специально переименованными, чтобы операции из ST нельзя было использовать в IO и наоборот. это, и плюс ещё трюк с forall типами, гарантирует что переменные/массивы, созданные внутри одного ST блока, не могут быть использованы в другом, и таким образом произведённые в нём вычисления являются чистыми, зависящими только от входных данных. я уже приводил этот пример:
f x = runST (do a <- newSTRef x
modifySTRef a (*2)
readSTRef a)
это вычисление, хоть и описано в императивном стиле, тем не менее не зависит от каких-либо обстоятельств выполнения, и всегда возвращает x*2. можно сравнить это с Сишной функцией, которой разрешено пользоваться только локальными переменными — тогда она тоже будет referential transparent, поскольку ей просто негде сохранять состояние в промежутке между вызовами
ещё одно важное отличие монады State от IO — вычисления, описанные в первой, вовсе не обязательно выполнять последовательно. это описание просто задаёт связи между данными. т.е. если State изменили в calc2 и затем использовали в calc3, то используемое в ней значение будет именно то, которое было присвоено в calc2. однако это просто связка по данным, и порядок вычислений она совсем не обязана гаранитировать. и на самом деле может быть сначала выичслено значение их calc3, а затем из calc1. ну например если в моём примере написсать "return (b++a)" вместо "return (a++b)"
монады могут быть реализоаны как ленивые и строгие. строгие выполняют операции в том порядлке, как это записано в монаде, ленивые — втом, в каком это нужно для получения ответа. технически это делается форсированием операций для строгих монад так что результат выполнения очередной операции оказывается якобы зависящим от выполнения предыдущей (используется операция seq). монада IO, понятное дело, всегда только строгая, а остальные можно реализовать и так, и эдак. скажем, здесь:
f x = runST (do a <- newSTRef x
modifySTRef a (*2)
b <- newSTRef x
readSTRef a)
в случае строгой монады всё будет выполнено последовательно (в тот момент, когда будет затребован результат "f x"), а в случае ленивой — запрос на результат приведёт к вполнению readIORef, результат которого, как выяснится, зависит от modifySTRef, а её резщультат — от первого newSTRef. второй же newSTRef так и не будет исполнен, поскольку его в цепочке зависимостей нет
впрочем, на практике, ленивые монады, как и вообще всё ленивое — это чаще всего медлительность и жуткий расход памяти (представьте себе набор зависимостей, воозникающий при записи, скажем, алгоритма умножения матриц )
M>С List-ом тоже вроде понятно. Это реализация интерфейса IMonad только List-специфичная. Вот чего не могу понять что в этом особенного?
M>Ну есть допустим в .NET интерфейс IEnumerable, который позволяет представлять все что угодно в Enumer-абельном виде. Ну здорово кто же спорит. Но ведь подобных интерфейсов вагон и маленькая тележка....
самое интересное в монадах — то, что они позволяют разделить логику работы приложения на отдлельные слои. лучше всего упоминавшуюся статью. Вадлера посмотреть, где в интерпретатор добавляют возможности, не трогая самого интерпретирующего кода
BZ>>может быть. мне лично кажется, что для придумывания монад лезть в математику ни к чему.
L>Это то да! Но то монады — их уже вытащили из ТК и дали нам разжёванное, а сколько там ещё непопробованного лежит?
в конечном счёте всё имхо определяется тем, что вы с математикой на ты, а я просто программист
palm mute,
PM>... skipped ... PM>Надеюсь, хоть чуть-чуть понятнее стало .
Спасибо, в целом хорошо. (только стиль хромает немного).
И ещё хочется какую-нибудь картинку. Какую-нибудь вот такую:
вот к этому PM> ...то действие (u >>= h >>= g >>= f) в общем случае является деревом конвейеров...
u — это начальное монадическое значение, скажем возвращённое функцией return.
Прямоугольники означают функции h, g и f :: a -> m b.
Внутри них сидит ядро, которое и выполняет полезную работу: печатает на экран, гадит в файл, достаёт пользователя и т. п.
Аргументы передаются по чёрным стрелкам;
Состояние — по пунктирным.
Каждая функция выдаёт монадическое значение (жырная синяя или фиолетовая стрелка), которая попадает в bind (жырная чёрная точка с границей соответствующего цвета-типа). Далее bind внутри себя расковыривает монадическое значение и передаёт функциям дальше.
Есть два момента:
1. bind принимает не только монадическое значение, но так же и функцию. Например, самый верхний bind должен принимать функцию h в качестве параметра. Чтобы не перегружать рисунок, придётся оговорить этот момент на словах, что я и делаю.
ps: Знаю, знаю, картинка за туториал не канает. Может быть позже выдумаю свой уникальный вариант.
Вот список прочитанных мной туториалов по монадам в хронологическом порядке
1. сообщение Редуктора.
2. глава в "истории Хаскеля" (давным давно в декларативном пролетала ссыла)
3. астронавты
3. их вторая инкарнация про ядерные отходы
4. эта (вы могли изобрести монады, но почему то не изобрели)
5. don't panic — пожалуй самая конкретная, но почти непрошибаемая. Я месяц (один месяц) буксовал на естественных трансформациях, пока не наткнулся на п. 6.
6. monadic crash course — пролил свет на многие моменты в 5. ускользнувшие почему-то.
7. YAHT
8. твои сообщения.
9. сообщение Глеба (palm_mute).
После такого списка я тоже могу сказать, "Да мужики, вы чо! Монады — это легко. Всем читать you-could-have-invented-monads!!!".
Но на самом деле you-could-have-invented-monads _недостаточно_. С одной стороны — это самый безболезненный старт, но с другой — по-прежнему непонятно, как же писать императивные программы на Хаскеле. Вот после YAHT — понятно, но не факт, что я бы врубился в него, если бы он был выше в списке.
Короче, минимального по объёму и максимального по естественности восприятия материала по-прежнему нет.
. Для меня большая честь получить такой отзыв от автора 
(только стиль хромает немного).
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
