Apr. 18th, 2011

MapM

Apr. 18th, 2011 11:20 am
Abstract:
В данной статье я расскажу вам про отображающие функции вида map, включающие в себя сайд-эффекты. Тем, кому известен хаскель, эти функции известны как mapM и подобные.
Далее, будет показано, что хаскель, будучи самым распространённым языком из тех, где используются монады (ну, кроме C#/linq и Scala), является непрактичным из-за отсутствия сайд-эффектов. Раньше мне без сайд-эффектов было всего лишь просто неудобно использовать хаскель (требовалось городить лишний код), теперь же я понимаю, что есть некоторые вещи, где с чистотой не получится клёво использовать монады в одном из их применений.
Также будет показано, что тайпклассы -- это не гибко, потому что у одного тайпкласса и у одной функции (например, "функция sequence в монаде IO") может быть только одна реализация, и будет показано, где именно это не гибко.

Read more... )

Кроме того, видел сегодня клёвую статью Modules Matter Most. Она тут упомянута потому, что в ней тоже необоснованно гонят на хаскель, но сама статья хорошая и правильная.
Предупреждение: вопрос глупый. Слабонервным не читать.

Мы с коллегой проектируем протокол общения двух программ. Общение состоит в том, что одна программа пишет в stdin/пайп/сокет для другой программы сообщение, являющееся валидным json (в строгом смысле слова -- либо массив, либо объект, то есть, self-delimited), другая программа читает, обрабатывает и отсылает ответ обратно, тоже json.
Запросов и ответов может быть много в одном потоке, они идут последовательно, на каждый запрос один ответ. И есть варианты, как это всё писать в один сплошной поток байтов.

1. Писать как есть, а парсер json'а разберётся, где заканчивается массив-объект (тупым подсчётом скобочек, исключая содержимое строк, например; либо средствами json-парсера),
2. Генерировать json так, чтобы он не содержал пустых строк (последовательности байтов 0x0A 0x0A), писать его в поток и разделять разные сообщения пустой строкой,
3. Писать сначала длину сообщения в байтах в десятичном представлении, затем перевод строки, затем само сообщение, содержащее ровно указанное количество байт.
4. Взять протокол наподобие http, имеющий возможность как слать сообщения с указанной длиной, так и сообщения в чанках, так и сообщения "до закрытия канала".

(соответственно, конец общения различать в соответствующих случаях так: 1. просто закрытый на отсылку поток (eof), 2. eof либо пустая строка вместо json, 3. eof либо сообщение длиной 0, 4. закрытие канала по канонам rfc2616.)

У нас возникли разногласия о том, как же это сделать, и я решил узнать общественное мнение.
Какой бы формат выбрали вы?

За какой вариант я и за какой вариант коллега -- не скажу пока. В качестве бонуса можете попробовать это угадать, а я через пару дней расколюсь.

Profile

gdsfh

August 2013

S M T W T F S
    123
45678910
111213 14151617
18192021222324
25262728293031

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Mar. 24th, 2017 12:01 pm
Powered by Dreamwidth Studios