тогда хватает боксинга

Деструктор переделывать надо. Если наивно реализовать — будет вылетать с переполнением стека

тогда хватает боксинга

Ну, человек это тьюринговский оракул. По крайней мере пока он работает так и нет причин полагать обратное

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

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

*серебрянной

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

а так-же что раст не нужен в 90% програм

Нельзя написать алгоритм, который расставляет маллоки за тебя

*серебрянной

да. я сегодня без кофе.

а так-же что раст не нужен в 90% програм

Haskell не нужен в 90% программ

Нельзя написать алгоритм, который расставляет маллоки за тебя

И free, free не забудь!

Haskell не нужен в 90% программ

В 10%

Haskell не нужен в 90% программ

хаскелем комфортно писать 90% программ. Растом нет.

В 10%

Аргументируйте, пожалуйста

В тех самых, в которых нужен раст :)

Вообще развели тут блах

да.

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

Очевидно когда найдут что-то удобнее для некоторых своих задач

ой да ладно, там у людей травма от си и плюсов

на расте эти 90% программ, где он не нужен могут быть удобнее, чем плюсы

но раст не настолько лучше плюсов

мне он проще, я плюсы не осилил, например

айда в blah

+

на расте эти 90% программ, где он не нужен могут быть удобнее, чем плюсы

У меня травма больше от динамически типизированных языков

И от TypeScript

И от Go ещё

У меня травма больше от динамически типизированных языков

в @haskell_blah пожалуйста

сообщения я туда форварднул

я думал blah это для обсуждения троцкизма, а тут уже и ЯП обсуждать нельзя? вот это поворот

раст всегда был онтопом, как и плюсы

рулевой комитет, кстати, ищет комитетчика, причем "консервативного", видно по два года пропозалы обсуждать им показалось мало

А снойман комитетчик?

нет

да тут началось странное

рулевой комитет это * Chris Allen (@bitemyapp) * Joachim Breitner (@nomeata) * Manuel M T Chakravarty (@mchakravarty) * Iavor Diatchki (@yav) * Atze Dijkstra (@atzedijkstra) (через месяц заменили на Романа Лещинского) * Richard Eisenberg (@goldfirere) * Ben Gamari (@bgamari) * Simon Marlow (@simonmar) * Ryan Newton (@rrnewton) (сейчас ищут замену для него) * Simon Peyton-Jones (@simonpj)

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

сложно...

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

избегай успеха и вот это вот все

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

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

спасибо

есть и другие комитеты, один из них тот, с которым снойман воюет все время

но к фичам языка они и вовсе уже никакого отношения не имеют

ого сколько бюрократов

библиотечный комитет это Edward Kmett (chair) Eric Mertens (Term ending June 2017) Dan Doel Michael Snoyman Luite Stegeman (Term ending June 2017) Joachim Breitner Neil Mitchell Ryan Scott не знаю, кого на кого там заменили и заменили ли

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

но к фичам языка они и вовсе уже никакого отношения не имеют

Я думал где-то в недрах кабалистов разрабатывают нормальные модули

Это разве не фича языка?

бекпак проходил предобсуждение когда оно еще в экспериментальном режиме работало, но рулевым комитетом не рассматривалось, закрыли его как аут оф скоуп у него мутный статус при нынешнем процессе, к примеру абстракция для не боксед типов ни через какие комитеты не проводилась. но и кабалистический комитет с которым снойман воюет тут не участвует, он только сайтом и ГСоКом занимается

Я думал где-то в недрах кабалистов разрабатывают нормальные модули

Какие там фичи у модулей будут?

Какие там фичи у модулей будут?

Почему будут, давно есть же http://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/

(но не в стаке)

Какие там фичи у модулей будут?

да там вроде ничего нового не планируется пока, основная часть для 8.2 и для 8.4 всякие фиксы и минифича

а можно как-то в stack.yaml прописать чтобы для определенного пакета собирался haddock?

а можно как-то в stack.yaml прописать чтобы для определенного пакета собирался haddock?

можно просто запустить stack haddock. не уверен насчёт модуля, но компонентом ограничить можно

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

О, хорошо

Как раз 64 воткнул

Будет, на чем хелловорлд собрать

Попробуй telegram api с помощью 8.2 собрать

The highlights, since the 8.4.1 release, are: Many, many bug fixes.

я так понимаю в 8.4 и 8.6 ничего интересного касательно самого языка

в 8.4 ничего, в 8.6 есть

вообще спросить хотел я в стек ямл указал ссылку на форк репа. как теперь убедится что подключен форк а не то что в снапшоте?

ERROR: S client not available

да и вообще может оно никак не сработает, ведь версии одинаковые

а, да, ну и конечно фича 8.6 в которой самое загадочное - почему это не фича 5.00 Prelude> :doc map 'map' @f xs@ is the list obtained by applying @f@ to each element of @xs@, i.e., > map f [x1, x2, ..., xn] == [f x1, f x2, ..., f xn] > map f [x1, x2, ...] == [f x1, f x2, ...]

ох нашёл. супер

вообще спросить хотел я в стек ямл указал ссылку на форк репа. как теперь убедится что подключен форк а не то что в снапшоте?

если указан репозиторий, то он всегда оверрайдит снапшотовый пакет. Даже версия не учитывается по сути, т.к. ревизия явно указывается

можно просто запустить stack haddock. не уверен насчёт модуля, но компонентом ограничить можно

Ну а когда я запущу build без haddock, он мне доки не снесёт?

вообще спросить хотел я в стек ямл указал ссылку на форк репа. как теперь убедится что подключен форк а не то что в снапшоте?

поверить стэку. или проверить наличие именно той фичи, ради которой ты подключил именно эту версию

Ну а когда я запущу build без haddock, он мне доки не снесёт?

не должен. лучше проверь

поверить стэку. или проверить наличие именно той фичи, ради которой ты подключил именно эту версию

проверил - не работает, решил спросить в чате) ну скорей всего чел который форкнул не довёл дело до конца

Ну ладно, рулевой комитет принял поправку, так что теперь 8.6 все пакеты с дженериками (включая аэсон ) не поломает, поломает некоторые другие, ну это как обыяно

на самом деле давно уже было понятно что так сделают и даже альфу выпустили в таком виде, но официально - только сейчас

#announcement New project: typerep-map — very efficient dependent map from type representations to values of these types. Blog posts describes how to implement such data structure step by step. https://kowainik.github.io/posts/2018-07-11-typerep-map-step-by-step.html

Всем привет! Делюсь ссылкой на typerep-map проект, над которым наша организация плотно трудилась в последнее время вместе с @int_index . Библиотека содержит эффективную реализацию отображения из типов в значения с соответствующим типом. А блог пост довольно хорошо описывает, как эта структура разрабатывалась шаг за шагом. Соддержит полезную информацию про RTTI в Haskell и прочие ништяки!

где она?)

ссылка

Над текстом же

какой профит от этого?

Всем привет! Делюсь ссылкой на typerep-map проект, над которым наша организация плотно трудилась в последнее время вместе с @int_index . Библиотека содержит эффективную реализацию отображения из типов в значения с соответствующим типом. А блог пост довольно хорошо описывает, как эта структура разрабатывалась шаг за шагом. Соддержит полезную информацию про RTTI в Haskell и прочие ништяки!

Привет, мы используем в проде dependent-sum и dependent-map, из доков пока не понял, можно ли заменить юзкейсы на реализацию с typerep-map. Типичный юзкейс, это параметризация единиц измерения Symbol тэгом, а потом складывание их в мапу по таким тегам.

Привет, мы используем в проде dependent-sum и dependent-map, из доков пока не понял, можно ли заменить юзкейсы на реализацию с typerep-map. Типичный юзкейс, это параметризация единиц измерения Symbol тэгом, а потом складывание их в мапу по таким тегам.

На Hackage в документации есть пример использования того, как можно использовать параметризацию Symbol - тэгом (если я правильно понял use-case). По сути, если есть DMap TypeRep и insert-ы не так часто происходят, то можно смело менять на TypeRepMap. http://hackage.haskell.org/package/typerep-map-0.1.0/docs/Data-TypeRepMap.html

На Hackage в документации есть пример использования того, как можно использовать параметризацию Symbol - тэгом (если я правильно понял use-case). По сути, если есть DMap TypeRep и insert-ы не так часто происходят, то можно смело менять на TypeRepMap. http://hackage.haskell.org/package/typerep-map-0.1.0/docs/Data-TypeRepMap.html

Похоже, что может подойти, не хватает только операций для аппликативного traverse и конвертации в/из список (для серилазиации в aeson, например)

Спасибо за рекомендацию! Этот пейпер не видел. Но из абстракта вижу, что они рекомендуют для больших n использовать Eytzinger layout, типа это самый быстрый вариант. Это как раз именно то, что и реализовано сейчас в typerep-map.

ну там можно посмотреть как его бранч-фри версию реализовывать, и как использовать префетчи и т.д.

не уверен правда, что в гхц префетчи без ллвм бекенда будут работать

ну там можно посмотреть как его бранч-фри версию реализовывать, и как использовать префетчи и т.д.

Интересно. Branch-free версию можно будет попробовать и посмотреть, насколько лучше становится

прямо скажем, сильного улучшения я бы не ждал

А вот как бы мне достать тип-аргумент из экзистенциального констуктора?

Похоже, что может подойти, не хватает только операций для аппликативного traverse и конвертации в/из список (для серилазиации в aeson, например)

Можете открыть issue на Github, и мы подумаем, как это сделать! Насчет аппликативного traverse не уверен, но конвертацию в/из список можно будет добавить

Можете открыть issue на Github, и мы подумаем, как это сделать! Насчет аппликативного traverse не уверен, но конвертацию в/из список можно будет добавить

Открыть тикет это запросто, открывать тикеты я умею

@chshersh а какая разница была между "наивным" кодом и ручным анбоксом? Или с самого начала так и писали?

@chshersh а какая разница была между "наивным" кодом и ручным анбоксом? Или с самого начала так и писали?

Сначала писали наивный код. А потом анбоксили вручную, чтобы убедиться, что GHC все хорошо инлайнит. Иногда разницы не было. А иногда перформанс значительно увеличивался, а сгенерированный core становится намного более хорошим