можешь взять non чтобы задать дефолтное значение для b

типа foo . non defaultB . bar

ой, второе не bar не Lens а Prism

т.е. я конструирую значение b

те

s & foo ?~ bar # something

а вообще норм выглядит

а с _Just скомпозить не выйдет?

хм

я не знаю как

https://hackage.haskell.org/package/lens-4.15.3/docs/Control-Lens-Setter.html#v:-63--126- не?

Ну так да, там выше так и есть. Я думал можно длинную призму собрать точками. Чтобы жутко красиво

получится foo . _Just . bar и вот на _Just всё превращается в тыкву

А так то было бы неплохо воссоздавать структуру по длинной призме

Да хоть из empty

выглядит не очень здраво

а не. если всё почистить и запустить заново то ок, кажись проходит. классика

https://www.stackage.org/lts-12.0

LTS Haskell 12.0 (ghc-8.4.3)

праздник у нас!

чокнемся тайпклассами

Подождём в никспкгс

А по Idris нет русскоязычного чата?

есть

https://t.me/joinchat/Ai4h2D9SWO_RDx2jMUbzqw

Спасибо!

Сделайте уже страничку на ruHaskell/wiki со списком подобных чатиков!

Чтобы ссылку давать

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

Может, бота кто зопилит? Типа: /ide /книжки

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

к примеру у Quantified constraints 31 комментарий, ну правильно мало кто понимает что там и как надо/не надо делать еще отличный пример того в чем все разбираются - ORF, там сотня комментариев, но или паттерны его давно обошли, конечно

(правда, если бы линейные типы были одним пропозалом а не двумя - у или было бы второе место только)

линейные типы, кстати, стал обсуждать комитет и там пока более-менее реалистические идеи на этот счет (пока не попробуешь - не узнаешь)

линейные типы, кстати, стал обсуждать комитет и там пока более-менее реалистические идеи на этот счет (пока не попробуешь - не узнаешь)

<troll> Это хаскелевый коммитет начал обсуждать? Это что, в хаскель перфоманс завезут теперь? </troll>

не хаскельный, а гхц-ный

хаскельный комитет это полностью бесполезная организация, вся деятельность которой сводится к ротации комитетчиков и анонсам планов (редким), тут кстати, есть один комитетчик оттуда - @bravit111

+1

а у хачкеля/гхц есть какой-нибудь отлаженый RFC процесс, или ребята просто собираются по определённым датам и говорят по душам?

Я на fpconf полтора года назад рассказывал, чем должен этот комитет заниматься и почему у него ничего не получится

по поводу перформанса, особого импакта на перформанс не будет, все равно основной способ управления памятью в сколько угодно дальней перспективе в гхц будет ГЦ

а у хачкеля/гхц есть какой-нибудь отлаженый RFC процесс, или ребята просто собираются по определённым датам и говорят по душам?

есть

можно как-нибудь в модуле сказать, что все топ-левел функции в нём имеют HasCallStack => ... ?

что, компакты уже можно объявить провалом?

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

по поводу перформанса, особого импакта на перформанс не будет, все равно основной способ управления памятью в сколько угодно дальней перспективе в гхц будет ГЦ

А в JHC вроде вообще сборщика мусора не было, всё на монадических регионах работало

а у хачкеля/гхц есть какой-нибудь отлаженый RFC процесс, или ребята просто собираются по определённым датам и говорят по душам?

предложения субмитятся сюда https://github.com/ghc-proposals/ghc-proposals/ после открытого обсуждения отправляются комитетчикам, которые в рассылочке его пообсуждают и (не) примут

А в JHC вроде вообще сборщика мусора не было, всё на монадических регионах работало

был

регионы-то в фя не работают

потому как и в мл-ките пришлось ГЦ делать

что, компакты уже можно объявить провалом?

почему?

Ну а разве это нельзя назвать "управление памятью"?

считай арена

Ну а разве это нельзя назвать "управление памятью"?

Возможность объявить структуру в памяти монолитной для сборщика мусора сложно назвать средством управления памятью

чот тёплое с мягким, не?

а что вам ещё надо то?

а что вам ещё надо то?

В идеале — чтобы сборщик мусора вообще не требовался

ну ну, удачи

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

видимо вот это, если профитов по перфомансу не будет

/me хочет виртуальную память в юзерспейсе

В идеале — чтобы сборщик мусора вообще не требовался

Та ну зачем, сборщик мусора хорошо подходит для многих задач. Но всё же иногда конечно хочется и вручную памятью порулить и ленивость отрубить.

FFI в руки и вперда

FFI в руки и вперда

а вот об FFI мараться не хочется

ERROR: S client not available

вам шашечки или ехать?

Та ну зачем, сборщик мусора хорошо подходит для многих задач. Но всё же иногда конечно хочется и вручную памятью порулить и ленивость отрубить.

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

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

локально отрубается?

надо {-# BEGIN STRICT #-} {-# END STRICT #-}

ну для модуля меняются умолчания с аннотирования строгости на аннотирование ленивости

Давайте я чуток наброшу — в Rust есть crates.io/crates/im — сборник персистентных иммутабельных структур данных. Отличается тем, что при модификации проверяется, что данными владеет один тред, и в случае, если это так, модиифицирует данные in-place вместо создания изменённой копии

Давайте я чуток наброшу — в Rust есть crates.io/crates/im — сборник персистентных иммутабельных структур данных. Отличается тем, что при модификации проверяется, что данными владеет один тред, и в случае, если это так, модиифицирует данные in-place вместо создания изменённой копии

Т. е. то, что давно обещали для ФП, но вроде так и не сделали

и как там с Box?

и как там с Box?

То есть? Там не Box, там Arc-и

Как там с Rc?

Лучший GC в мире (нет)

Как там с Rc?

Никак, Rc потоконебезопасен

Я начал писать раньше чем ты ответил :(

Рц это управление памятью теперь?

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

Счётчик ссылок -- примитивный GC

Malloc это уже не руками. Вот. Mmap ещё может быть

Счётчик ссылок -- примитивный GC

Не совсем. Подсчёт ссылок даёт предсказуемую деаллокацию, в отличие от

Подсчёт ссылок это рантайм, в отличие от регионов

Давайте я чуток наброшу — в Rust есть crates.io/crates/im — сборник персистентных иммутабельных структур данных. Отличается тем, что при модификации проверяется, что данными владеет один тред, и в случае, если это так, модиифицирует данные in-place вместо создания изменённой копии

Чёт так себе наброс. Вот если бы эта штука аллоцировала для себя какой-то кусок памяти и потом там нормально собирала мусор(не Arc), вот тогда было бы норм, а так чот не.

Самую предсказуемую деаллокацию даёт munmap

Подсчёт ссылок это рантайм, в отличие от регионов

Это да. Но регионами всё не сделаешь

Чёт так себе наброс. Вот если бы эта штука аллоцировала для себя какой-то кусок памяти и потом там нормально собирала мусор(не Arc), вот тогда было бы норм, а так чот не.

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

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

он медленный

Чёт так себе наброс. Вот если бы эта штука аллоцировала для себя какой-то кусок памяти и потом там нормально собирала мусор(не Arc), вот тогда было бы норм, а так чот не.

И да, теоретически можно и переделать таким образом, есть же crossbeam-epoch

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

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

Повторю свой тезис

Повторю свой тезис

Эм, рекурсивные типы это Cons Cons Cons Cons Cons ... a?

Или простой односвязный список?

data List a = Cons a List | Nil

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

а это уже malloc