Евгений
Практически у всех этих функций есть стандартные safe аналоги, либо их можно одним case'ом заменить
саша
этим всем можно не пользоваться :)
Да оно понятно, что стандартной библиотекой с самыми что ни на есть стандартными функциями можно не пользоваться, а взять вместо этого что-то стороннее. Но меня беспокоит то, что оно unsafe by default
Ilya
второй момент, как тут сказали уже, что рекурсивные типы в хаскеле -- коиндуктивные, но иногда хочется про это забыть и считать их индуктивными (конечными).
Евгений
в Хаскелле всегда можно говорить про тотальность только с оговорками, иначе у нас тотальными только id, const и подобные будут, из-за боттомов в каждом типе
id от нетотального аргумента будет нетотальна :)
Евгений
Да оно понятно, что стандартной библиотекой с самыми что ни на есть стандартными функциями можно не пользоваться, а взять вместо этого что-то стороннее. Но меня беспокоит то, что оно unsafe by default
Ну, экспешоны это типичная практика в сабже, без них никуда же
Ilya
Название safe вводит в заблуждение, как будто с помощью этих headMaybe можно писать безопасные программы, пф
Ilya
length тотальная, если забыть про боттомы и бесконечные списки
Aleksei (astynax)
Евгений
саша
Исторически сложилось
ну вот да, я когда это увидел тоже подумал, что это связано в первую очередь с возрастом
Aleksei (astynax)
Название safe вводит в заблуждение, как будто с помощью этих headMaybe можно писать безопасные программы, пф
те части, которые построены сугубо из содержимого safe, вполне себе безопасны - насколько это возможно :)
саша
А то я вообще как-бы из раста, а там паники ловить нельзя, поэтому всё стараются делать сейф. После этого Haskell немного конфьюзит
Ilya
те части, которые построены сугубо из содержимого safe, вполне себе безопасны - насколько это возможно :)
Ну они безопасны только пока ими правильно пользуются
Ilya
для бесконечных списков имеет смысл говорить о продуктивности. length не продуктивна, из-за того, что возвращаемый тип Int не коиндуктивен, можно написать продуктивный length', возвращающуй Nat, например
Aleksei (astynax)
Так в хаскеле тоже в основном стараются всё делать safe :)
Ilya
Хотя ладно, fromJust то не сейф тоже
Ilya
А матчить руками (\(Just x) -> ..) мы не будем ок
Ilya
Тогда норм
Aleksei (astynax)
Code review для такого есть :)
саша
А матчить руками (\(Just x) -> ..) мы не будем ок
можно компилятор попросить громко ругаться на non exhaustive patterns
Ilya
можно компилятор попросить громко ругаться на non exhaustive patterns
Ну попроси :) Он же лямбды не смотрит, по-моему
Aleksei (astynax)
так и делаем - -Werror на CI
Ilya
Это вам не идрис
Aleksei (astynax)
Смотрит вроде
Ilya
id от нетотального аргумента будет нетотальна :)
ну, id undefined не взорвется же, но если хочется убить боттом, давайте оставим только const
Евгений
Ага, только боттомы друг другу не равны. id $ head [] взорвётся
Ilya
можно компилятор попросить громко ругаться на non exhaustive patterns
Компилятор не всегда может проверить, рассмотрены ли все случаи в гардах
Евгений
Если хочется убить боттом, то нужно пруф-асистентент в язык встраивать #ленивый_идрис
Ilya
так же как и id undefined
саша
Компилятор не всегда может проверить, рассмотрены ли все случаи в гардах
можно попросить ругаться на все гарды без otherwise или что-то типа того
Ilya
иногда удобно писать гарды без otherwise
Aleksei (astynax)
можно попросить ругаться на все гарды без otherwise или что-то типа того
f x | x > 0 = "foo"
f 0 = "bar"
f _ = "qux"
Ilya
хотя в таком случае обычно есть catchall clause
Aleksei (astynax)
проверка на pattern match exhaustiveness - штука сложная
Aleksei (astynax)
view patterns всякие оную ломают
саша
f x | x > 0 = "foo"
f 0 = "bar"
f _ = "qux"
ну как по мне лучше где-то явно написать аналог рустовского unreachable!(), чем писать сложные матчи, которые компилятор не может определить как exhaustive
Ilya
идрис вот отловит такое, да
Ilya
ну и наверное всякие расширения хаскеля
Ilya
ну как по мне лучше где-то явно написать аналог рустовского unreachable!(), чем писать сложные матчи, которые компилятор не может определить как exhaustive
ещё не хватало из руста что-то в хаскель тащить 😤
Dmitry
А подскажите, есть ли готовые библиотеки для расширяемых массивов, типа std::deck из C++ (состоит из списка массивов). Так, чтобы можно было с одного из концов добавлять, но не переаллоцировать каждый раз, ну и чтобы оверхеда, как в стандартных одноэлементных списках, не было?
Dmitry
И самому можно написать, но зачем, если готовое есть
саша
ещё не хватало из руста что-то в хаскель тащить 😤
Кек.
unreachable = error "Unreachable"
Ilya
Dmitry
Они на списках
Dmitry
А мне нужно поплотнее элементы располагать
Ilya
Data.Sequence на finger tree
Dmitry
Data.Sequence на finger tree
Но не на массивах. Там тоже ссылочная структура, почти на каждый элемент
Dmitry
data FingerTree a
= EmptyT
| Single a
| Deep {-# UNPACK #-} !Int !(Digit a) (FingerTree (Node a)) !(Digit a)
Aleksei (astynax)
какой ключик нужен ещё?
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using-warnings.html#ghc-flag--Wincomplete-uni-patterns
Dmitry
А мне бы 20 млрд элементов в памяти удержать
Ilya
Aleksei (astynax)
там же стоит глянуть на -Wall - в описании этого флага описано, какие ворнинги в него не включены
Dmitry
Ну, видимо, так и придётся.
Dmitry
Просто не охота было баги плодить.
Alexander
но это просто Sequence Vector
Dmitry
Поясни, я не понял :)
Alexander
Seq (Vector a) возьми за основу
Alexander
добавление и удаление чанков будет быстрым
Alexander
если по одному то тогда да, не прокатит
Dmitry
Ну вот мне по одному, т.е. надо будет код писать для добавления в последний чанк и проверку на переполнение этого последнего чанка
Dmitry
Ну, в принципе, багов не должно быть слишком много, напишу уже.
Cheese
Alexander
препенд будет не очень
Alexander
если чанк не мувать
Dmitry
Да мне только с одного конца
Dmitry
Т.е. только append
Alexander
а, если с одного то все проще
кана
Ведь она не определена на possible argument [1..]
по идее она определена для всех значений: для [] и для (x:xs), и аргумент структурно уменьшается
Aleksei (astynax)
я на это и давил :)
кана