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

[warlock66613]

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

А то ведь не хаскель.

Хаскель и есть (с расширением, которое, если не путаю, называется TypeFamilies).

[Xaositect]

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

Хаскель и есть (с расширением, которое, если не путаю, называется TypeFamilies).

{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}. TypeFamilies это сильнее

[arseniiv]

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

Пусть будет открытой, это же ничему не помешает.

Помешает коллизиями имён методов, ну и если не удастся назвать все новые классы не как старые (а вдруг там хорошее имя окажется), то и имён классов.

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

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

Ну, видимо, пороги у всех немного разные, но в среднем наверняка мы все сходимся. Кроме такой экстенсивной перегрузки и добавления суперсуперклассов для большой кучи конкретных классов ещё можно, конечно, делать обёртки у инстансов, например я вполне удовлетворён тем, что делается для Monoid/Semigroup уже из настоящего пакета base (с отдельными именами для операции — вот тут OK) и их инстансов (Min, Max, Any, All, First, Last и какая ещё там куча).

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

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

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

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

Возможно же ещё умножение.

Да, конечно. Потому я отчасти за то, что у настоящих классов моноидов и полугрупп хаскеля операция обозначается <>, а не плюсом или умножением. Числовые и многие другие классы, однако, часто вертятся вокруг структур, подобных кольцу, вот там и сложению, и умножению место. Разных видов колец как раз много надо, чтобы не требовать mod в не евклидовом кольце и т. п..

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

Как говорят - краткость, конечно же сестра таланта, но в некоторых случаях талантам от этого ничуть не лучше :)

Ну, в реальном коде действительно удлинил бы или написал документацию, тут понадеялся. :) Вообще тот пример можно понимать чисто синтаксически, у меня фантазии просто не было.

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

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

(Уже написали, пока я закопался в статью про возникновение типоклассов и пошёл гулять по ссылкам, но пусть уж останется.)

С расширениями MultiParamTypeClasses (это вроде в Haskell2010 входит, но не помню) и FunctionalDependencies компилируется (кстати они ведь в той статье про историю хаскеля тоже упомянуты! ну, без формальных названий). Если смутила часть | a b -> c, то это описание функциональной зависимости, позволяющее проще выводить инстансы (и не позволять определять некоторые). В данном случае оно нужно, чтобы если мы знали a и b, мы могли бы определить однозначно и c. Это запретит, например, написать пару инстансов HasPlus A B C1 и HasPlus A B C2 или, скажем, Show a => HasPlus A B a.

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

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

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

Вообще лично мне помогает вспоминать вещи точечная запись ООП-языков (нажимаешь точку, и IDE тебе выкати весь список), но уж чего тут нет, того нет. И идеальный в этом отношении язык бы имел не просто точечную запись, но и предлагал бы кроме истинных методов того, что слева от точки, всякие функции, берущие его первым аргументом (неравенство, но пользу приносит), так же как и воспринимал бы в общем случае подобную запись a.f(…) как f(a, …), и парочка языков с такой фичей даже есть (Nim и Koka вроде точно да, но могут быть и ещё), но я на них ничего не писал.

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

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

Угу, тоже там читал.

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

а мультиметоды - на этапе выполнения

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

[alex55555]

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

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

А то ведь не хаскель.

Хаскель и есть (с расширением, которое, если не путаю, называется TypeFamilies).

Да, диалекты есть, но так же есть Haskell report 2010. Я придерживаюсь стандарта. А если его не придерживаться, тогда люди плохо понимают друг друга.

[warlock66613]

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

А если его не придерживаться, тогда люди плохо понимают друг друга.

А если его придерживаться, на Haskell писать совершенно невозможно. А проблема понимания явно преувеличена: мы (я, arseniiv, Xaositect) же вот как-то друг друга поняли.

[alex55555]

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

например я вполне удовлетворён тем, что делается для Monoid/Semigroup уже из настоящего пакета base (с отдельными именами для операции — вот тут OK) и их инстансов

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

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

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

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

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

С расширениями MultiParamTypeClasses (это вроде в Haskell2010 входит, но не помню)

В Haskell report 2010 в части определения классов этого нет. И далее нигде не упоминается (искал поиском). Но есть часть 12.3 Language extensions, где как раз есть прагмы в виде:

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

{- LANGUAGE ... -}

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

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

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

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

Вообще лично мне помогает вспоминать вещи точечная запись ООП-языков (нажимаешь точку, и IDE тебе выкати весь список), но уж чего тут нет, того нет.

На самом деле есть. Вопрос только в привычности и, возможно, доработке. Есть разные IDE и есть плагины к IDE. Это вопрос выбора, плюс иногда там не всё так, как хочется, тогда это вопрос доработки (часто не самой большой).

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

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

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

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

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

а мультиметоды - на этапе выполнения

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

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

-- 03.12.2018, 16:52 --

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

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

А если его не придерживаться, тогда люди плохо понимают друг друга.

А если его придерживаться, на Haskell писать совершенно невозможно. А проблема понимания явно преувеличена: мы (я, arseniiv, Xaositect) же вот как-то друг друга поняли.

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

Ну и про "группу понимания". Здесь вообще многие про хаскель даже не слышали, а вы указываете на группу товарищей, как на нечто важное. Широкое использование любого инструмента возможно лишь при вменяемой стандартизации. А если стандарта нет (или его не придерживаются) - ну кто-ж вам постоянно будет гайки М22.5 выпиливать?

В общем, мне кажется, вы здесь лишку "упростили".

[warlock66613]

(Оффтоп)

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

Интересно, а что такого повседневного вам не удаётся написать на стандартном хаскеле?

Парсер бинарного формата.

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

Может какие-то привычки мешают?

Ага. Привычка называется "строгая типизация", и это очень хорошая привычка.

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

Может стоит просто поискать другие пути?

Но зачем?

[arseniiv]

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

Да, диалекты есть, но так же есть Haskell report 2010. Я придерживаюсь стандарта. А если его не придерживаться, тогда люди плохо понимают друг друга.

Среди расширений есть кучка безобидных и часто используемых. В частности, без multiparameter type classes практически никакой каши не сварить вообще. Линзы и пайпы с однопараметрическими не определить. Думаю, в следующую версию языка это расширение будет включено.

Что говорят по этому поводу люди на SO: https://stackoverflow.com/questions/801785/should-i-use-ghc-haskell-extensions-or-not/803130#803130.

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

Там, кстати, группу не нашёл.

Да, группы там действительно нет.

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

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

Да, конечно. Но всё-таки совсем не пользоваться возможностью определять операции из символов было бы зря. А вообще хорошая IDE должна показывать информацию о том, что под курсором, в том числе о непонятной операции — привязанную документацию, место определения, тип… Это сильно помогает даже в каком-нибудь императивном языке с не особо развитой системой типов, а уж тут чуть ли не must have. Ну или когда такого нет, но есть REPL, тоже можно жить.

Так-то я тоже за названия умеренной длины, но в этой теме это немного оффтоп.

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

На самом деле есть. Вопрос только в привычности и, возможно, доработке. Есть разные IDE и есть плагины к IDE.

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

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

После пробела всё может работать точно так же. После первой буквы названия - тоже.

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

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

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

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

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

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

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

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

Широкое использование любого инструмента возможно лишь при вменяемой стандартизации. А если стандарта нет (или его не придерживаются) - ну кто-ж вам постоянно будет гайки М22.5 выпиливать?

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

[alex55555]

(Оффтоп)

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

Парсер бинарного формата.

А в чём там сложность? Хотя я сам вижу проблему с урезанным императивом в хаскеле. Его сторонники признают, что:

Цитата:

An important practical benefit of monadic parser combinators is the fact that Haskell has special syntax (the do-notation) that greatly simplifies writing monadic programms

То есть без императива им бы пришлось совсем туго.

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

[warlock66613]

(Оффтоп)

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

А в чём там сложность?

В строго типизированной обработке ошибок. То есть парсер должен быть монадой Get e a, где e - тип ошибки, a - тип результата. Далее нам необходимо комбинировать парсеры с разными e. Например, комбинатор option должен иметь тип вроде forall e a. Get e a -> Get Void (Maybe a), или - что эквивалентно, но более обще, и потому удобнее - forall e e' a. Get e a -> Get e' (Maybe a) [это эквивалентно варианту с Void, поскольку Void (и только его) можно сконвертить в любой e' функцией absurd]. Для этого я придумал MonadMapError:

class (MonadError e m_e, MonadError e' m_e') => MonadMapError e m_e e' m_e' | m_e -> e, m_e' -> e', m_e e' -> m_e', m_e' e -> m_e where
mapError :: (e -> e') -> m_e a -> m_e' a

Вот как тогда выглядит option:

option'' ::
  ( MonadPlus m_Unit
  , MonadMapError e m_e () m_Unit
  , MonadMapError () m_Unit e' m_e'
  ) => m_e a -> m_e' (Maybe a)
option'' p = mapError (error "Control.Monad.Error.Map.option''") $ mapError (const ()) (Just <$> p) `mplus` return Nothing

Как это всё сделать без обсуждаемых расширений, я не знаю. Думаю, никак.

[alex55555]

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

Среди расширений есть кучка безобидных и часто используемых.

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

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

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

Но всё-таки совсем не пользоваться возможностью определять операции из символов было бы зря.

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

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

А вообще хорошая IDE должна показывать информацию о том, что под курсором, в том числе о непонятной операции — привязанную документацию, место определения, тип…

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

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

Ну или когда такого нет, но есть REPL, тоже можно жить.

Это сильно менее удобно - нужно набивать всё руками вместо наведения курсора на слово. Плюс нажимаем ctrl и кликаем мышкой на слове - переносимся в исходный текст функции. Это давно является стандартом для Java IDE.

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

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

Опять же - сортируем сначала входящие в текущий модуль, затем уже библиотечные названия. По аргументам можно некое переключение добавить - после пробела нажать кнопки alt или ctrl. Способы есть, вопрос только в активном применении (то есть в доработке существующих средств разработки).

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

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

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

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

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

Оно и в целом маленькое. Сравните с любым сообществом писателей сайтов, например. Десятки миллионов против десятков тысяч, ну или как-то близко.

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

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

Здесь ещё одна проблема - технологии требуют много денег. Поэтому всё остальное, кроме GHC, банально загибается. Пейтон Джонс (автор GHC) давно работает в Microsoft, а в вики его характеризуют так - степень PhD так и не получил. То есть кто-то должен оплачивать развитие технологии, но сейчас это всё по сути сваливается на стареющего разработчика c непонятным отношением к этому со стороны Microsoft. Что будет дальше? Хаскель умрёт вместе с автором компилятора? Согласитесь - это ненормально.

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

[arseniiv]

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

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

Ну вы только не подумайте, нововведения же в языки, особенно в сию пору, сверху в основном только формально приходят (потому что кому-то надо это закодить или хотя бы принять чей-нибудь патч или pull request), а необходимость в них идёт снизу, от того же сообщества, чтобы можно было писать код вместо копипасты или ручного описания того, что может генерироваться автоматически. Хаскель в этом отношении весьма консервативен, потому что всяких идей его расширения появилось в разы больше, чем отразилось в расширениях GHC. С некоторыми идеями, правда, проблемы: например, насколько мне известно, пока не придумали единственно верную codo-нотацию для комонад (при том, что существуют и do для монад, и proc…do для стрелок, так что, казалось бы, думать осталось мало) — было два предложения, и оба как-то заглохли.

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

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

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

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

Это уже есть.

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

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

Это давно является стандартом для Java IDE.

Действительно. Пользовался эклипсом с плагином для Ceylon. Да и VS для C#, но VS, понятно, не для джавовых языков.

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

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

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

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

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

Стоп-стоп, погодите. Вон в хаскеле тоже часто (собственно, для любой незаинлайненной полиморфной функции с типом … => t) конкретный инстанс неизвестен во время компиляции, но это не отменяет статичности типизации. Так что такие «статические мультиметоды» сами по себе ничего не портят.

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

Оно и в целом маленькое. Сравните с любым сообществом писателей сайтов, например. Десятки миллионов против десятков тысяч, ну или как-то близко.

Хм, а с какой целью мы начали сравнивать размеры сообществ? Я потерял нить.

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

И мы наглядно видим разницу - миллионы против тысяч. Вот вам и плюсы стандартизации.

Так стандартизация-то тут причём? Это же деньги, это реклама и ещё как частичное следствие размер сообщества, вы сами про это и писали, а не про стандартизацию и расширения. Вот возьмите C# микрософтовский — в нём расширений с первой версии добавилось, наверно, в каком-то смысле больше, чем в хаскеле, и разницы только, что они отдельно не включаются-выключаются. Я не знаю, при чём тут какое-то особенное расползание разработчиков (в каком-то смысле оно есть везде, в другом его тут не больше). Гораздо сильнее влияет уже достигнутая известность и трудности в изучении. О которых мы тут тоже уже говорили. Короче я запутался, куда ведёт беседа.

-- Пн дек 03, 2018 23:07:51 --

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

[alex55555]

(Оффтоп)

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

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

А в чём там сложность?

В строго типизированной обработке ошибок. То есть парсер должен быть...

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

Вообще монады и подход хаскеля на их основе к IO сыграли очень злую шутку с изучающими хаскель - они сделали очень вероятными ситуацию вроде вашей, когда нет нужды ни в монадах, ни в ещё каких-то сложностях. Монады ведь просто скрывают возможность доступа к состоянию путём откладывания его обработки, но надо ли в вашем случае скрывать доступ к состоянию парсера? В функциональном виде парсер получает входное значение и преобразует его в дополнение к дереву и последующий шаг. Это обычная чистая функция, что здесь прятать? Запускаете эту функцию через банальный $map$ на списках входных значений и шагов и получаете список дополнений к дереву, которые потом собираете. Монады здесь вообще ни при чём. А конкретный пример $parsec$ есть лишь именно конкретный пример, а не обязательное к исполнению руководство.

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

-- 03.12.2018, 22:17 --

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

Стоп-стоп, погодите. Вон в хаскеле тоже часто (собственно, для любой незаинлайненной полиморфной функции с типом … => t) конкретный инстанс неизвестен во время компиляции, но это не отменяет статичности типизации. Так что такие «статические мультиметоды» сами по себе ничего не портят.

Конкретный инстанс как раз известен во время компиляции. Вы же где-то используете ту конструкцию, которую изобразили как … => t, вот в том месте и проверяются типы на этапе компиляции.

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

Я потерял нить.
...
Если мы просто сейчас растекаемся мыслию по древу, то это само по себе не плохо, но просто чтоб знать. Нюансы типизации и разработки языков — это интересно, но пока я ничего нового о них всё равно в этой теме не узнал. А начиналась она достаточно специфической.

Да, пожалуй мы рассуждаем обо всём :)

[warlock66613]

(Оффтоп)

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

Но зачем обязательно что-то абстрактное чем-то типизировать?

Ну мне же не один бинарный формат надо разобрать. И потом, это же Haskell, в этом вся суть.

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

нет нужды ни в монадах

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

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

Это обычная чистая функция

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

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

В общем - сложно получается.

На самом деле совсем нет. Всё как раз получилось очень просто и естественно, в меру красиво, в меру абстрактно, в меру компромиссно. Одна проблема: адски тормозит, причём явно не по делу. Я так и не смог этого побороть, и этим закончилось моё знакомство с Haskell, теперь я всё, написанное на Haskell, переписываю на Rust.

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

императив не для него

Ерунда. Для Haskell'а - всё. Если бы все могли на нём писать, другие языки были бы не нужны. Но могут не все. Я, как оказалось, не могу.

[arseniiv]

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

Конкретный инстанс как раз известен во время компиляции. Вы же где-то используете ту конструкцию, которую изобразили как … => t, вот в том месте и проверяются типы на этапе компиляции.

Похоже, мы друг друга не поняли. Я по крайней мере имел в виду, что полиморфная функция не знает, какой тип a у некоторого из её аргументов, но притом если в коде функции используется метод инстанса C … a …, то мы, конечно, знаем инстанс (если не переборщили с опасными расширениями типа UndecidableInstances), но не знаем тип и потому должны в скомпилированной функции принимать словарь (dictionary) методов C дополнительным параметром (вы по идее это знаете, но я не буду ничего опускать, чтобы уж убедиться, где вышло непонимание). Но при этом в рантайме ничего страшного не прозойдёт, если остальной код типировался корректно. Dynamic dispatch, static typing, что в тех же консервативных ООП типа C++. Так что не видно, что должно сломаться, если мы будем рассматривать однометодные классы как «мультиметоды в статическом языке». Если только тот язык не будет позволять тот же минимум корректности, что здесь хаскель.

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

теперь я всё, написанное на Haskell, переписываю на Rust

О! Есть ли у вас какая-нибудь критика насчёт похожих частей того и того?

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

Я, как оказалось, не могу.

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