Телеграмм чат группы haskellru страница 15334

Ну, уж про аллоки векторов я знаю...
Персистентность это изменение размера?

персистентность — это сохранение ссылочной прозрачности при "мутации"

13:31пожаловаться #1

AA

Ну, уж про аллоки векторов я знаю...
Персистентность это изменение размера?

это когда операции по добавлению/изменению элемента создают новую версию коллекции а старая версия остается для всех кто на нее ссылался

13:32пожаловаться #2

[

Кстати, а в хаскеле есть компайл-тайм вычисляения? Просто раз подразумевается, что это чисто функциональный яп, то логично было бы посяитать вообще всё, что не зависит от юзер-инпута

13:33пожаловаться #3

IR

Jerzy Syrowiecki

списки — нормально, если их функционально "мутировать" близко к голове. вектор придётся копировать целиком или отказаться от персистентности, а для списка расход памяти мизерный

Короче, список как стек - норм, как вектор - уг.

13:34пожаловаться #4

IR

Впрочем говорят, что vector тоже уг

13:35пожаловаться #5

[

A64m AL256m qn I0

это когда операции по добавлению/изменению элемента создают новую версию коллекции а старая версия остается для всех кто на нее ссылался

А, я кажется понял, в чём проблема.
Это как в плюсах создать ссылку на элемент вектора, потом изменить его размер с аллокацией и ссылка вдруг резко начинает указывать куда-то не туда, куда нужно.

13:35пожаловаться #6

AA

Кстати, а в хаскеле есть компайл-тайм вычисляения? Просто раз подразумевается, что это чисто функциональный яп, то логично было бы посяитать вообще всё, что не зависит от юзер-инпута

есть двумя способами, причем каждый из двух способов - два способа

13:36пожаловаться #7

JS

Jerzy Syrowiecki in Haskell

Кстати, а в хаскеле есть компайл-тайм вычисляения? Просто раз подразумевается, что это чисто функциональный яп, то логично было бы посяитать вообще всё, что не зависит от юзер-инпута

1. да, это просто оптимизация.
2. не логично, если вычисление очень тяжёлое, например, миллион знаков пи.
3. оптимизация не гарантирована, но есть ещё Template Haskell, который гарантирован, но надо явно его выделять

13:36пожаловаться #8

JS

Jerzy Syrowiecki in Haskell

А, я кажется понял, в чём проблема.
Это как в плюсах создать ссылку на элемент вектора, потом изменить его размер с аллокацией и ссылка вдруг резко начинает указывать куда-то не туда, куда нужно.

есть пример проще. если в плюсах взять ссылку на int, а потом изменить этот int, то по ссылке можно будет прочитать новое значение. в Хаскеле — старое

13:37пожаловаться #9

AA

А, я кажется понял, в чём проблема.
Это как в плюсах создать ссылку на элемент вектора, потом изменить его размер с аллокацией и ссылка вдруг резко начинает указывать куда-то не туда, куда нужно.

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

13:38пожаловаться #10

[

IC Rainbow

Впрочем говорят, что vector тоже уг

Вектор уг, если тебе надо добавлять 100500 элементов к нему, потому что тот постоянно аллочится, а это минус память и минус производительность. Добавление элемента в вектор занимает O(n) времени.
Список же этих проблем не имеет, но 1 - обращение к произвольному элементу занимает O(n), 2 - кэш проца умирает, если накосячить.

13:39пожаловаться #11

IR

У vector ещё императивная реализация под капотом довольно стрёмная похоже. Регулярно вижу его кишочки в профиле.

13:41пожаловаться #12

AA

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

13:41пожаловаться #13

IR

A64m AL256m qn I0

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

А сторабл?

13:41пожаловаться #14

AA

большинство хаскельных типов не сторабл

13:42пожаловаться #15

AA

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

13:47пожаловаться #16

[

В общем, надо смотреть на алгоритмическую полезность колки, а не на то, как она там работает под капотом

13:49пожаловаться #17

AA

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

13:49пожаловаться #18

IR

A64m AL256m qn I0

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

Эх, если бы у нас был язык, который может из типа знать безопасный диапазон....

13:50пожаловаться #19

IR

В общем, надо смотреть на алгоритмическую полезность колки, а не на то, как она там работает под капотом

Если её капот выпирает из моего, то как тут на него не смотреть...