ох господи, это HDBC, все в машину времени!

fromRow (SqlInt64 eid, [d -> Just nm, d -> Just pwd, d -> Just vn]) = Just $ User eid nm pwd vn where d (SqlByteString nm) = either (const Nothing) Just $ decodeUtf8' nm d _ = Nothing fromRow _ = Nothing

мне кажется, без view patterns как-то проще: fromRow [SqlInt64 eid, nm, pwd, nv] = User (toInteger eid) <$> d nm <*> d pwd <*> d vn

да, так норм

А что не так с HDBC?

он старый и стрёмный

а какие есть альтернативы? Я видел только *-simple, которые сделаны каждый под свою БД

а разве нужен кому-то 1 клиент под разные БД?

ну, когда я смотрел что есть для БД, то увидел небогатый выбор

и "Вау, да тут можно один клиент под разные БД использовать"

Кстати, а как узнать о View Patterns, если ни разу до этого их не трогал?

в GHC-ном мануале, там же ссылки будут для углубленного изучения

http://ghc.readthedocs.io/en/latest/glasgow_exts.html#view-patterns

у Касперского или на Касперского, но не в нём

Ехехе

Я прост сидел в гиттере

Помню аватар

fromRow (SqlInt64 eid, [d -> Just nm, d -> Just pwd, d -> Just vn]) = Just $ User eid nm pwd vn where d (SqlByteString nm) = either (const Nothing) Just $ decodeUtf8' nm d _ = Nothing fromRow _ = Nothing

Спасибо. Как-же не хватает туториалов :(

а тут неясно что туториалить

да вообще что-нибудь простое

взять тот-же андроид с котлином или явой. Полон гитхаб ToDo-list'ов с тысяча и одной иллюстрацией каждого чиха

с Tutorial конечно была интересная задумка и со school of haskell

но как-то никто её не форснул

А то книжку со слоником я прочёл, а как с этим жить в суровой реальности не понятно

ну книжка со слоником - она "для общего развития"

Таки да, это утверждение совпадает с действительностью :)

@nepherpitou есть ещё толстая книжка за деньги, там туториалов порядком

@nepherpitou есть ещё толстая книжка за деньги, там туториалов порядком

так и со слоником была за деньги

Но она онлайн же доступна

В отличие от

от...?

Haskellbook

а туториал по чему именно требуется-то в данном случае?

По основным шагам в написании веб-сервиса, например.

что-куда-к чему использовать и почему не использовать

это уже гайд какой-то

просто туториал, например, у серванта есть

от перемены терминов суть меняется не сильно. Я вот при попытке найти таковой гайд нашел кучу разношерстой шляпы по scotty

там емнип туториал будет именно по серванту же, а не по всему набору библиотек который понадобится

т.е. тут нужна, видимо, книга типа RWH но новее, например какая-нибудь такая http://www.apress.com/gp/book/9781430262503

но такие книги за год устаревают

ха! Я когда искал что-куда считал за благо советы или статьи из 2012

в основном было 2008-2010

а ты "за год устаревают"

Господи, дай мне сил intermediatehaskell.com дописать

Пойду, пожалуй, этим и займусь.

ха! Я когда искал что-куда считал за благо советы или статьи из 2012

да, в материале по хаскелю надо в первую очередь год смотреть

от перемены терминов суть меняется не сильно. Я вот при попытке найти таковой гайд нашел кучу разношерстой шляпы по scotty

А что кстати не так со scotty?

А что кстати не так со scotty?

со scotty, в целом, всё в полном порядке, насколько я могу судить. Беда с описанием того, как с его помощью пилить полноценный сервис. Нет, силой мысли можно рано или поздно дойти до удовлетворяющего состояния проекта, но у "конкурентов", той-же скалы, к примеру, разных гайдов с подробным разжевыванием до неприличия больше

Есть по скотти хорошие статьи, и не одна

http://seanhess.github.io/2015/08/19/practical-haskell-json-api.html например

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

я слышал тут мнение, что servant уже стандарт де-факто, но мне с моим weekend haskell например scotty намного понятнее

Есть по скотти хорошие статьи, и не одна

ага, я и говорю, со скотти всё хорошо. Как заставить его выплюнуть json или текст вполне понятно. А вот как сделать так, чтобы при полсотни роутов поддержка не превратилась в ад - не понятно.

> Haskell users are satisfied with library performance > Haskell users are extremely unsatisfied with their ability to reason about the performance of their programs

интересное сочетание

это просто неверная интерпретация графиков

я слышал тут мнение, что servant уже стандарт де-факто, но мне с моим weekend haskell например scotty намного понятнее

стандарт де факто, это WAI (и то некоторые не согласны), а всё что поверх - пока вкусовщина :)

ха! Я когда искал что-куда считал за благо советы или статьи из 2012

Я до сих пор их читаю 😂

а на что можно заменить вот такое? mapM_ (\x -> f1 x >> f2 x) xs где f1 :: String -> IO () и f2 :: String -> IO () просто применить последовательно f1 и f2 к x

гершом такой гершом...

Prelude Control.Monad Control.Applicative> :t mapM_ (liftA2 (>>) f1 f2) mapM_ (liftA2 (>>) f1 f2) :: Foldable t => t String -> IO ()

@vasyayorkin так например ^

mapM_ ((>>) <$> f1 <*> f2)

отлично, спасибо!

mapM_ $ uncurry (>>) . (f1 &&& f2) &&& из Control.Arrow

у меня проще :P

А мне так больше нравиться)

А есть в стандартной библиотеке что-нибудь типа dup x = (x, x)?

вроде нету

зачем если можно join (,)

Я так и знал что какой-то такой прикол есть!

яб императивненько forM_ фигакнул

питонистей

ну тут mapM норм заходит, поинтфришненько

зачем если можно join (,)

Это не просто так) в комбинаторах это есть комбинатор-дубликатор с названием W

W fn

ну тут mapM норм заходит, поинтфришненько

Лучше traverse тогда) рестрикшн на монадку пропадет)

+

ну да, я обратил внимание в доке As of base 4.8.0.0, mapM_ is just traverse_, specialized to Monad.

У диля есть классное наставление

ачтогдекак?