[Haskell] Альтернативные Prelude с аккур. числовыми классами

[arseniiv]

Для хаскеля есть уже немало альтернатив Prelude, в которых определены более разумные с точки зрения расширяемости и алгебры числовые классы: я хочу написать велосипед с векторами для небольшого расчёта, но хочу при этом пользоваться для сложения векторов обычным +. Но при этом я так и не умудрился разобраться со всем этим разнообразием: что удобно, а что нет, что поддерживается по сей день, а что ушло в прошлое и т. д.. Всё это можно посмотреть на Hackage, но это утомительно, потому, пожалуйста, если кто-то чем-то из этого пользовался, посоветуйте.

Разбор некоторых случаев:

1. numeric-prelude. Вроде весьма проработанный пакет, и последнее обновление было в этом году, вот только одна неприятная деталь: автор (на реддите говорили, переняв привычное для ML) называет все классы C и все типы T, что само по себе не плохо, потому что имена модулей разные, и даже могло бы быть весьма приятным, если бы haddock (по крайней мере, с теми настройками, с которыми используется для этого пакета) не выдавала в результате вот такое — например, class (C a, C v) => C a v — тут все три C из разных модулей, и по показываемым браузером адресам ссылок на первые два можно даже понять, откуда они, но это совершенно неюзабельно. Каким бы замечательным модуль ни был, я что-то не помню чтобы у него была альтернативная документация, которой я мог бы пользоваться, чтобы разобраться с ним.

2. numhask (предпоследняя версия; последняя 0.2.3.0 вообще не билдится, судя по описанию) — кажется, ещё не очень близко к чему-то стабильному. Хотя не знаю, для одного велосипеда могло бы и сойти, видимо.

[Legioner93]

У haddock есть ключ --qual https://haskell-haddock.readthedocs.io/ ... oking.html
Соберите документации локально

[warlock66613]

arseniiv в сообщении #1320639 писал(а):

Всё это можно посмотреть на Hackage

Дополнительным критерием может служить присутствие на Stackage.

[arseniiv]

Legioner93
О! Спасибо, с этим можно будет жить! (Наверно — сейчас проверять не буду.)

А я правильно понимаю, что аргументы к Haddock указываются где-то в установочной информации пакета, и что потому в отсутствии правильной опции --qual можно винить мейнтейнера? (Если да, интересно, пытались ли с ним связаться и если да, как он реагировал…)

warlock66613
Тоже спасибо, действительно резонно.

Кстати хоть на Stackage есть всплывающие хинты, что из какого модуля. Видимо, это заслуга новой темы. (Интересно, почему на Hackage не обновили.)

[warlock66613]

arseniiv в сообщении #1335366 писал(а):

аргументы к Haddock указываются где-то в установочной информации пакета

Я не знаю, как делают другие авторы пакетов - может и есть способ заставить Hackage собирать документацию, но я сначала собираю документацию локально, а потом отправляю на Hackage готовый результат. Если иметь в виду именно этот способ, то 1) нет, никаких аргументов нигде не указывается, 2) да, можно винить мейтейнера.

[alex55555]

arseniiv в сообщении #1320639 писал(а):

Для хаскеля есть уже немало альтернатив Prelude, в которых определены более разумные с точки зрения расширяемости и алгебры числовые классы

А в чём неразумность и нерасширяемость существующих вариантов?

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

[arseniiv]

alex55555 в сообщении #1357717 писал(а):

А в чём неразумность и нерасширяемость существующих вариантов?

В том, что нельзя измельчить грубую иерархию классов — нельзя вставить класс между двумя другими и вообще нельзя добавить суперкласс. Это приводит к дублированию кода и размножению методов (в том числе операций), в которых надо ориентироваться. На пакетах из первого поста можно видеть, как ситуацию можно улучшить, ну и вообще можно почитать любой пост про то, что Num — зло. Или просто даже почитать почти любой пост sigfpe, где он определяет что-нибудь со свойствами полукольца, но не кольца, и вынужден писать псевдоопределения для abs, signum, negate и что там ещё. Это уменьшает пользу от статической типизации, потому что ошибка от неправильного использования будет в рантайме.

alex55555 в сообщении #1357717 писал(а):

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

Ну как сказать. И тут дело не в том, что нет реализации. Если есть реализация, её можно при желании обернуть так, чтобы она уселась в иерархию используемых числовых алгебраических классов. Для простых применений можно вообще пользоваться самописными векторами (взять массивы обычные или из пакета vector и приделать к ним пару операций), иерархию же на коленке хорошую не сваяешь.

[alex55555]

arseniiv в сообщении #1357800 писал(а):

alex55555 в сообщении #1357717 писал(а):

А в чём неразумность и нерасширяемость существующих вариантов?

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

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

Поэтому "вставить" класс можно. Это эквивалентно объявлению некоего типа реализующим заданный интерфейс. И это можно сделать только в вашем модуле, то есть не мешая никому и при этом устраняя помехи от других в вашу сторону. Ну а супер-класс в данном случае понятие условное. Тип реализует просто набор интерфейсов, при этом кто от кого произошёл - неважно. Если нужно "вставить", то просто дополняете набор операций. Операции всё равно остаются неким набором, без взаимосвязей. Взаимосвязаны лишь классы. То есть если вы говорите deriving некоему типу, то он должен реализовать все функции из связываемого класса, но при этом ничто не мешает реализовать так же и функции из любого другого класса.

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

arseniiv в сообщении #1357800 писал(а):

ну и вообще можно почитать любой пост про то, что Num — зло

К сожалению не читал. Но заявления про нечто, являющееся абсолютным злом, рассматриваю скептически.

arseniiv в сообщении #1357800 писал(а):

иерархию же на коленке хорошую не сваяешь.

Почему? Авторы хаскеля же сваяли свою иерархию. Точно так же и любой другой может. Всё, что сделали авторы хаскеля, можно повторить. Поддержка на уровне компилятора есть лишь у очень ограниченного числа классов. И эта поддержка часто легко реализуется дефолтными функциями, то есть без компилятора.

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

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

[warlock66613]

alex55555 в сообщении #1357953 писал(а):

На самом деле хаскель нужно серьёзно учить, что бы было легко на нём писать что угодно.

Более того, не всякий сможет его выучить. Я вот не смог.

alex55555 в сообщении #1357953 писал(а):

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

Да дело вообще не в этом. F# тоже функциональный, но с ним у программистов нет таких больших проблем.

[arseniiv]

alex55555 в сообщении #1357953 писал(а):

Поэтому "вставить" класс можно.

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

Используется синтаксис Haskell

class Semigroup t where
  (<>) :: t -> t -> t

class Semigroup t => Monoid t where
  e :: t

class Monoid t => Group t where
  inv :: t -> t

А вот что у нас вместо этого, допустим, есть:

Используется синтаксис Haskell

class Semigroup t where
  (<>) :: t -> t -> t

class Semigroup t => Group t where
  e :: t
  inv :: t -> t

Вставьте сюда Monoid. (Не получится, если только не определить всё заново и наследовать инстансы, имеющиеся для этих двух, для написанных нами двух, и экспортировать только наши классы, а старые никому не показывать.)

alex55555 в сообщении #1357953 писал(а):

Ну а супер-класс в данном случае понятие условное.

Условное, но в конкретном случае, когда заголовок определения класса — class (C1 t, C2, t, …) => C t, вполне резонно звать C1, C2 и т. д. суперклассами C. Вот когда заголовок хитрее (разные типы, а не один только t), тогда конечно смысла особого (как в ООП) нет, хотя и тогда набор классов перед => можно так звать.

alex55555 в сообщении #1357953 писал(а):

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

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

alex55555 в сообщении #1357953 писал(а):

Но заявления про нечто, являющееся абсолютным злом, рассматриваю скептически.

А кто говорил, что абсолютное? Ну и вообще это было сказано не совсем серьёзно.

alex55555 в сообщении #1357953 писал(а):

Почему? Авторы хаскеля же сваяли свою иерархию. Точно так же и любой другой может. Всё, что сделали авторы хаскеля, можно повторить. Поддержка на уровне компилятора есть лишь у очень ограниченного числа классов. И эта поддержка часто легко реализуется дефолтными функциями, то есть без компилятора.

Да. Но чтобы написать хорошую иерархию, надо сидеть и думать. Чтобы оставить хорошие штуки из дефолтной, надо сидеть и копировать. В общем долго и скучно, если для одного себя, и слишком ответственно, если писать пакет для многих. Потому готовые решения, а они ведь и существуют, предпочтительнее.

[alex55555]

warlock66613 в сообщении #1357956 писал(а):

Более того, не всякий сможет его выучить. Я вот не смог.

Наверное имеет смысл говорить "не захотел". Мочь там много не надо, просто время потратить на повторение для запоминания.

warlock66613 в сообщении #1357956 писал(а):

alex55555 в сообщении #1357953 писал(а):

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

Да дело вообще не в этом. F# тоже функциональный, но с ним у программистов нет таких больших проблем.

Как пишут в википедии - F "мультипарадигмальный" (хотя на мой взгляд нужно "мультипарадигменный"). То есть императив в нём присутствует шире, что помогает переходящим на F с других императивных языков.

[warlock66613]

alex55555 в сообщении #1358125 писал(а):

Наверное имеет смысл говорить "не захотел".

Нет, не имеет.

alex55555 в сообщении #1358125 писал(а):

Мочь там много не надо

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

alex55555 в сообщении #1358125 писал(а):

То есть императив в нём присутствует шире, что помогает переходящим на F с других императивных языков.

Да, но дело всё-таки не в этом. Самое главная разница - в принципиально разных рантаймах (в том числе в ленивости).

[alex55555]

arseniiv в сообщении #1358068 писал(а):

Используется синтаксис Haskell

class Semigroup t where
  (<>) :: t -> t -> t

class Semigroup t => Group t where
  e :: t
  inv :: t -> t

Вставьте сюда Monoid.

Например вот так:

Используется синтаксис Haskell

class Semigroup t => Monoid t where
  identity :: t
class Monoid t => ExtendedGroup t where
  invariant :: t -> t

То есть организуете свою ветвь и с ней живёте, используя в ней свои названия. При этом другим не мешаете использовать стандартные классы. И другие могут использовать ваши, но при этом, естественно, они должны будут использовать ваши названия.

arseniiv в сообщении #1358068 писал(а):

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

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

arseniiv в сообщении #1358068 писал(а):

готовые решения, а они ведь и существуют, предпочтительнее.

Да, конечно. Но иногда в готовых решениях не всё устраивает. И вот тогда начинается поиск компромисса. При этом каждый сам решает, что для него компромисс. Некоторые вообще новые языки придумываю. А другие только готовое используют.

-- 02.12.2018, 15:28 --

warlock66613 в сообщении #1358134 писал(а):

Самое главная разница - в принципиально разных рантаймах (в том числе в ленивости).

Ленивость есть и в F. Правда вроде по умолчанию она выключена (я не изучал серьёзно этот язык).

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

[arseniiv]

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

alex55555 в сообщении #1358139 писал(а):

То есть организуете свою ветвь и с ней живёте, используя в ней свои названия.

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

alex55555 в сообщении #1358139 писал(а):

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

Не нарушает. Или в таком случае сам ad-hoc polymorphism, вводимый механизмом классов, её нарушает — однако так никто не говорит. Ведь и разные числовые типы—экземпляры Num — абелевы группы (по операции $+$), и разные векторные пространства тоже абелевы группы по операции, математиками обозначающейся всё так же $+$ (оно и понятно почему — на координатных пространствах это покомпонентный предыдущий $+$, ну кроме того, что структуру абелевой группы там по-другому и не введёшь, а операции таких групп принято повально обозначать $+$). Ну ладно, то математика, а у нас код, но даже это не мешает: сложить по ошибке число с вектором мы не сможем ровно так же как и сложить числа разных типов. Типизация исполняет свою роль. Она перестанет только в том случае, если мы переусердствуем в абстракции и определим совсем общий class HasPlus a b c | a b -> c where (+) :: a -> b -> c, а потом вдобавок напишем какой-нибудь неподходящий, математически неприемлемый инстанс к нему. Тогда мы себе всё сами сломаем. (Вообще же такой класс может быть полезен, если мы собираемся определить действие абелевой группы на каком-то произвольном типе — такое «сложение» не будет сводиться ни к какому сложению элементов никакой группы самой по себе, так что придётся делать более общий класс. С другой стороны, конкретно этот и для такой цели чересчур общий, можно убрать аргумент c и заменить его на a или b, смотря какие детали. Но это здесь уже совсем оффтоп.)

alex55555 в сообщении #1358139 писал(а):

В целом всё сводится к готовности принять не только решение об использовании знака, но и последствий, которые из него вытекают.

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

-- Вс дек 02, 2018 21:01:52 --

Кстати вот я читал полгода назад где-то, как придумали типоклассы. Удивительно, насколько это вышло чуть ли не случайно, почти везение, хотя казалось бы к этому могли бы прийти как-то логически и десятилетиями двумя раньше. И приятно, что многие языки (типа Rust) их аналоги стали использовать, потому что действительно гибкая вещь — сочетает идеи и наследования ООП, и мультиметодов, убирая минусы того и другого и позволяя к тому же нечто новое (что могли бы позволять и мультиметоды, но они вроде обычно были у динамически типизированных языков) — return type polymorphism. Хотя пользы от последнего, конечно, не сказать чтоб совсем много, но иногда незаменим (как раз в случае всяких классов для алгебр, кстати — всякие нули-единицы получать).

[alex55555]

arseniiv в сообщении #1358215 писал(а):

и нужна возня со скрытием старой Group

Пусть будет открытой, это же ничему не помешает. То есть виды групп разводятся по именам. Если явно используется одно название, значит одна группа, если другое - другая. Всё очевидно любому, кто посмотрит текст такой программы. Увидит привычную стандартную группу - поймёт, что это такое. Увидит вашу - догадается из названия.

arseniiv в сообщении #1358215 писал(а):

Не нарушает.

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

arseniiv в сообщении #1358215 писал(а):

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

Возможно же ещё умножение. Хотя да, читал про некоторые "общепринятые" правила, мол плюс вот здесь, а умножение вот здесь, но ведь при изучении с толку всё равно сбивает. И только потом уже привыкаешь. Вот в вашем примере тоже краткое обозначение $inv$ меня попутало (я потом только вспомнил), сначала дописал его как инвариант (просто всплывшее в голове слово), и только потом связал смыл операции с заданием группы, то есть по разнице операций между классами-предками понял, что это скорее $inversion$ (обратное значение, как и операция - выдающая обратное значение). Как говорят - краткость, конечно же сестра таланта, но в некоторых случаях талантам от этого ничуть не лучше :)

arseniiv в сообщении #1358215 писал(а):

class HasPlus a b c | a b -> c where (+) :: a -> b -> c

Это псевдо-код? А то ведь не хаскель.

arseniiv в сообщении #1358215 писал(а):

Вообще же такой класс может быть полезен, если мы собираемся определить действие абелевой группы на каком-то произвольном типе — такое «сложение» не будет сводиться ни к какому сложению элементов никакой группы самой по себе, так что придётся делать более общий класс

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

arseniiv в сообщении #1358215 писал(а):

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

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

arseniiv в сообщении #1358215 писал(а):

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

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

Это всё есть в A history of Haskell. Тоже, кстати, "paper", в смысле статья, прошедшая как продукт работы "группы товарищей" из ряда университетов.

arseniiv в сообщении #1358215 писал(а):

сочетает идеи и наследования ООП, и мультиметодов

Классы типизированы и проверка аргументов производится на этапе компиляции, а мультиметоды - на этапе выполнения. Разные штуковины. А вот с наследованием - да, по сути одно и то же (если наследование для интерфейсов).