именно!

между прочим у меня там нету сплошного unlifted ^_^

у DMap пока вставка круче :/

но видимо бенчмарки плохие

и там удачный случай

ещё круто бы было все с liquid haskell пройтись

@int_index кстати мне не нравится то, что у вас 2 fingerprint массива

ты пробовал в одном все хранить друг за другом? и умножать на 2 индекс для сдвига

Именно так и пробовали сначала, вышло медленнее

должно быть более cache friendly (но это не точно)

Это изначальная идея была, но unboxed vectors оказались быстрее, и я подсмотрел как там сделано — разбиение на два

страннота

ещё на самом деле, но это не точно, можно хранить только половинку слова и сравнивать, как в hashmap

блин слово в смысле

а дальше хранить smallarray## второе слово+ значение

но в принципе и так все хорошо уже

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

Может, будет полезно: https://akuklev.livejournal.com/1279998.html

@chshersh чот у вас слишком простые ревью, я повеселее подкинул

Ну, мне не особо нравится не соблюдение нашего стайл-гайда, но не очень удобно говорить про такое, особенно когда человек потратил много времени и сил и забесплатно поделал клевые штуки в твоих библиотеках. Форматирование я потом и сам могу поправить, когда буду с этим кодом работать, и вообще, не столько важны отступы, сколько именно смысл. А если в остальном замечаний к PR не хватает — извините, под конец дня не особо сил остается ? Там просто очень много делается, и на это надо больше времени, чтобы отвревьювить. Тем более, я не особо ожидал, что во время Hacktoberfest столько людей будет что-то делать и будут открывать PR, поэтому наши силы касательно ревью PR потихоньку истекают...

Подглядел в решениях самое красивое: Count $ fix S

А как посчитать количество обитателей (->) c, что-то понять не могу. Я думал, это count @c, ну с поправкой на то, что если отображение в Void, то нет обитателей вообще.

a -> b ~ b^a разве нет?

А как посчитать количество обитателей (->) c, что-то понять не могу. Я думал, это count @c, ну с поправкой на то, что если отображение в Void, то нет обитателей вообще.

Откуда обитатели у высших кайндов?

Ну, мне не особо нравится не соблюдение нашего стайл-гайда, но не очень удобно говорить про такое, особенно когда человек потратил много времени и сил и забесплатно поделал клевые штуки в твоих библиотеках. Форматирование я потом и сам могу поправить, когда буду с этим кодом работать, и вообще, не столько важны отступы, сколько именно смысл. А если в остальном замечаний к PR не хватает — извините, под конец дня не особо сил остается ? Там просто очень много делается, и на это надо больше времени, чтобы отвревьювить. Тем более, я не особо ожидал, что во время Hacktoberfest столько людей будет что-то делать и будут открывать PR, поэтому наши силы касательно ревью PR потихоньку истекают...

блин, я забыл, что не у всех наш стиль

a -> b ~ b^a разве нет?

А, точно!

> мне не особо нравится не соблюдение нашего стайл-гайда Зато в других проектах нравится применять stylish-haskell, когда этого никто не просил

> мне не особо нравится не соблюдение нашего стайл-гайда Зато в других проектах нравится применять stylish-haskell, когда этого никто не просил

Во-первых, это было давно, и я так больше не делаю. Во-вторых, я научился отключать stylish-haskell, когда работаю над проектом (правда, это неудобно). В-третьих, поскольку это больно, то мотивации работать над проектами, которые не используют stylish-haskell, у меня намного меньше, чем над теми, которые используют. Слишком много сил тратится на переключение контекста. В-четвертых, если даже проект и использует stylish-haskell, то я считаю, что настройки должны лежать в корне этого проекта (а так делают не все люди, к сожалению). В-пятых, проблема часто еще и в том, что у людей не просто stylish-haskell не настроен, но и какой-нибудь whitespace cleaner тоже не настроен, и ты коммитишь с удалением trailing пробелов. А потом люди жалуются, что коммит содержит лишние изменения пробелов (и не очень понятно, почему нельзя использовать GitHub фичу для игнорирования пробельных изменений в ревью). Это, кстати, была одна из причин для меня перестать контрибьютить в cabal. Я не нашел способа отключить у себя whitespace cleaner, а мне лично самому не особо и нужно. Сам же я спокойно отношусь к спонтанным форматированиям и выравниваям в PR, если они в рамках настроек и стайл-гайда и здравого смысла.

> удалением лидирующих пробелов Это как?

> удалением лидирующих пробелов Это как?

Опечатка. Имелось в виду хвостовых пробелов (или висящих, хз как по-русски)

Такую зависимость от стиля надо бороть, я вот с GHC исходниками работаю и со странным выравниванием, и с их do {a; b}

И не бросаюсь все переписывать

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

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

Такую зависимость от стиля надо бороть, я вот с GHC исходниками работаю и со странным выравниванием, и с их do {a; b}

Одно дело, когда ты вручную поддерживаешь стиль. С этим у меня проблем нет. Я могу работать с любым файлом и придерживаться стиля этого файла вообще без особых усилий. Даже с GHC с их интересным форматированием `do`-блоков. Проблема начинаются тогда, когда надо прилагать дополнительные усилия, чтобы отключать автоматические тулы форматирования. Если бы они автоматически могли понимать, что не надо на этих файлах запускаться, тогда вообще никаких проблем.

Так говно тулы, если нельзя их научить

люди коммитящие с висящими пробелами должны гореть в аду

Там же где люди удаляющие их без нужды

У них там один котёл

люди коммитящие с висящими пробелами должны гореть в аду

я!

мне лень вим таки настроить

У них там один котёл

котел обмена опытом ? ?

Это типа до сих пор не выработался единый стиль форматирования?

я!

это всё тлетворное влияние физматшколы

а нельзя сделать просто один коммит на весь ghc/cabal/еще что, который удалит все висящие пробелы (локализует катастрофу)

люди коммитящие с висящими пробелами должны гореть в аду

Висячий пробел должен быть ошибкой компиляции!

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

котел обмена опытом ? ?

Одни топят, другий варятся. Потом меняются

типа го и раста

Висячий пробел должен быть ошибкой компиляции!

Да! Сделали же с табами ворнинги

больше ни у кого общего стиля нету

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

больше ни у кого общего стиля нету

Ну хорошо, ослабим требование: не общий, а общепринятый.

Даёшь 8 пробелов отступы.

В питоне пеп8 есть к примеру

вообще тут сложно договориться красивенько против поддерживаеменько

Хорошо, если ослабить требование прям совсем: хотя бы несколько популярных стилей форматирования есть или каждый как хочет так и форматирует?

по моему нет даже общепринятых

это плохо

Ну вроде стиль Йохана Тиббела ±широко распространён(с вариациями)

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

Ну вроде стиль Йохана Тиббела ±широко распространён(с вариациями)

Вот от вариаций и горит в итоге у всех

Вот от вариаций и горит в итоге у всех

Так хоть в своём коде не горит

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

Бессмысленная ерунда? Серьёзно? Вот опять проблема практики vs академики вылезла.

Но откровенно наркоманские стили — редкость всё же

Бессмысленная ерунда? Серьёзно? Вот опять проблема практики vs академики вылезла.

точно, я практик, ерундой не страдаю

точно, я практик, ерундой не страдаю

Ага, конечно.

В языках с нормальным синтаксисом плохо отформатировать - надо сильно постараться, никто, кроме крисдона не старается, так что все читабельно

В языках с нормальным синтаксисом плохо отформатировать - надо сильно постараться, никто, кроме крисдона не старается, так что все читабельно

Ага, конечно. (2)

чет теоретик разбушевался

А маршировать строем практики любят? eine Sprache, ein Stil, ein Editor!

пора заводить haskell_drama канал

чет теоретик разбушевался

Некоторые хаскелисты любят писать data Record = Record { field1 :: Int , field2 :: String } После такого любой здравомыслящий человек разбушуется

Да, это из более наркоманских стилей

Некоторые хаскелисты любят писать data Record = Record { field1 :: Int , field2 :: String } После такого любой здравомыслящий человек разбушуется

Я бы тут писал так: ``` data Record = Record { field1 :: Int , field2 :: String } ```

Я бы тут писал так: ``` data Record = Record { field1 :: Int , field2 :: String } ```

тут не в отступах проблема

тут не в отступах проблема

А конкретно?

Просто мне тут только отступа в 8 пробелов не хватало.

А конкретно?

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

Вот так ещё можно. data Record = Record { field1 :: Int , field2 :: String }

Вот так ещё можно. data Record = Record { field1 :: Int , field2 :: String }

ещё лучше

В Хаскеле типы - это самое важное. data Record = Record { field1 :: Int, field2 :: String }

В Хаскеле типы - это самое важное. data Record = Record { field1 :: Int, field2 :: String }

Топ

В Хаскеле типы - это самое важное. data Record = Record { field1 :: Int, field2 :: String }

Но не так важно как сэкономить место data Record = Record{field1::Int,field2::String}

Но не так важно как сэкономить место data Record = Record{field1::Int,field2::String}

вокруг знака равенства лишние пробелы

а точно, простите

Я бы тут писал так: ``` data Record = Record { field1 :: Int , field2 :: String } ```

data Record = Record { field1 :: A , field2 :: B } The best!

Такой вопрос. Какой грязный извращенец придумал переносить запятую на новую строчку и что он перед этим употреблял?

data Record = Record { field1 :: A , field2 :: B } The best!

и deriving вот так data Record = Record { field1 :: A , field2 :: B } deriving(Show, Eq, Ord)

Такой вопрос. Какой грязный извращенец придумал переносить запятую на новую строчку и что он перед этим употреблял?

Мне нравится, теперь везде так делаю

data Record = Record { field1 :: A , field2 :: B } The best!

data Record = Record { field1 :: A , field2 :: B }

Такой вопрос. Какой грязный извращенец придумал переносить запятую на новую строчку и что он перед этим употреблял?

полагаю, у каждого извращенца были свои мотивы. Мне так удобнее комментрировать ненужные поля

Считайте это частью общепринятого стиля

устойчиво к диффам и рефакторингу и добавлением ещё конструкторов

вот запятая впереди - точно общий стиль

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

Такой вопрос. Какой грязный извращенец придумал переносить запятую на новую строчку и что он перед этим употреблял?

С запятыми удобно. Комментировать и т.д.

и выравнивается удобно

Такой вопрос. Какой грязный извращенец придумал переносить запятую на новую строчку и что он перед этим употреблял?

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

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