Alexander
СС дискуссия про хугл
Alexander
haskell.academic-university.edu
Anonymous
Alexander
а почему он ведет на старье, вроде последние версии показывает
Alexander
@deni_ok объяснитесь пожалуйста
Alexander
на hoogle.haskell.org само приложение новее, но база вроде та же?
Denis
Можно поискать <>, например
Artyom
@cblp_su
> import Control.Lens
> import Data.Functor.Product
> import Data.Monoid
> let withFlag f x =
Pair (Const (Any True))
(Identity (f x))
> [1,2,3] & each (withFlag negate)
Pair (Const (Any {getAny = True}))
(Identity [-1,-2,-3])
> [] & each (withFlag negate)
Pair (Const (Any {getAny = False}))
(Identity [])
A64m
новый хугл же все еще по типам нормально не ищет?
A64m
ладно, нормально он никогда не искал, имеется в виду не хуже чем раньше
A64m
да и "новый" он уже несколько лет
Denis
Там старый движок нормальный, но настроен, как я понимаю, на поиск в каких-то непонятных местах.
Alexander
да, ему там явно либы прописывать надо
Denis
А "новый" недоделанный, но с настраиваемым местом, откуда брать документацию (stackage, platform, included-with-ghc).
Alexander
и то что он по умолчанию на latest натравливает не совсем помогает
Зигохистоморфный
https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated-guide-to-haskell-in-2018/
Mikhail
Пишу парсинг сериализованных данных Data.Aeson ругается что у него нет instance FromJSON ByteString и я совершенно не могу покять как его написать, может кто знает?
Artyom
не надо его писать
Artyom
как ты хочешь сериализовать байтстринги? как hex, как base64, еще как-то?
Artyom
или тебе неважно?
Artyom
если неважно, то пакет base64-bytestring тебе поможет
Alexander
все верно @lightgreen говорит
Ignat
Как бы сериализовать последовательность байт в последовательность байт 🤔🤔🤔
Artyom
JSON-с
Alexander
о, в json появился тип для последовательности байт?
Alexander
это какое расширение стандарта?
кана
Массив чисел)
Alexander
base64 string логичнее
Alexander
xml наше все, json для лохов
Alexander
с xml тоже не все чтобы очевидно
Alexander
или через CDATA или ещё как
Евгений
2к18 и не протобуф?
Andrew
На pgconf 2018 развели холивар тоже json vs xml.
Andrew
По мне так, xml не удобный из за несовместимости с js
Anatolii
Там парсер написать не могут?
Andrew
а с xml надо повозиться, распарсить
Alexander
ну есть и другая сторона вопроса, формат json задается в лучшем случае через flow (и то чисто за счет его совмстимости с js), а для задания формата xml придумали кучу крутых штук
Alexander
причем flow достаточно молод, чтобы автодоки с ним лучше было писать самому
Alexander
На pgconf 2018 развели холивар тоже json vs xml.
там это еще интереснее, поскольку xml в psotgre принципиально типизированный, а json нет
Andrew
там это еще интереснее, поскольку xml в psotgre принципиально типизированный, а json нет
Вот этого я не знал, что pg xml тип поддерживает. А каковы издержки этого типа? Можно ли строить индекс по внутренним нодам?
Alexander
индексы только функциональные и полнотекстовые
Alexander
обычно функциональных хватает
Alexander
так, я наврал, postgresql не умеет в валидацию по схеме
Alexander
парсер не нужен, парсер крайне желателен
Alexander
любое выражение json является валидным выражением js, проблема только в том чтобы не делать eval с user inputом
Cheese
почему крайне? если хочешь, чтобы твоя программа падала, то не пользуйся парсером
Cheese
любое выражение json является валидным выражением js, проблема только в том чтобы не делать eval с user inputом
не является. то есть не любое
Alexander
мне кажется, с xml не будет проблем. если на клиенте типизированный язык
Anatolii
Ну это значит что парсер написали уже
Alexander
это не особо важно, v8 справится с задачей превратить парсе в байткод
Andrew
С xml там сложнее. Это как раз плюсик в пользу JSON формата.
Anatolii
Я просто не понял как формат данных может быть не совместим с языком
Cheese
Я просто не понял как формат данных может быть не совместим с языком
формат может не быть частью языка
Alexander
> {"JSON":"ro cks!"}
разве это валидный json?
Alexander
мне кажется что это UTF-8 расширение
Alexander
глянул спеки json, да, там полная поддержка utf-8 :(
Cheese
Ну это же не "не совместимость"
да, скорее "поддержка на уровне синтаксиса"
Anatolii
Конечно на фронте приятно на 1 зависимость меньше тащить
Alexander
проблема в том, что на фронте становится непонятно что делать с xml
Cheese
глянул спеки json, да, там полная поддержка utf-8 :(
кстати, есть 2 слегка противоречащих друг другу спеки JSON, врочем, это ерунда
Alexander
то есть по идее ты хочешь пройтись по нему xpathами, а не десериализовать в объект, потому что непонятно как описать десериализатор
Cheese
делайте клиентскую часть фронтенда попроще, XML уберите в серверную часть
Alexander
это вопрос инструментария. Если фронт на js то понятно что xml не нужен
Alexander
проще уж изъебнуться с flow
Andrew
Можно вообще взять edn :) и на фронте и на сервере
Aleksei (astynax)
Кложуристы, вон, гоняют на фронт EDN свой. И радуются. И им не жмёт особо