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

[warlock66613]

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

Только из-за того, что вы не знали, как оптимизировать код, который в остальном нравился?

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

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

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

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

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

А что там ещё общего? Лямбы везде нормальные, алгебраические типы данных с паттерн матчингом тоже. В Rust весьма тяжело обращаться с функциями как с объектами, так что там, где в Haskell не задумываясь пишешь функцию, принимающую функцию, в Rust ещё подумаешь: а нельзя ли заменить параметр-функцию на, скажем, пару булеанов - пусть и не так общно будет, но зато сильно проще.

Монад - в смысле универсальной штуки - в Rust нет. Там, где они нужны, каждый городит свой вариант (на макросах, конечно, пример - опять же библиотека для построения парсеров nom).

И там, и там напрягает отсутствие перегрузки (overloading) методов. В Haskell'е причины понятны, в Rust же особых причин вроде не видно.

[arseniiv]

Спасибо!

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

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

М, да, на этот счёт мне показался интересным подход как в идрисе (но не писал на нём ничего пока, так что неизвестно, насколько удобный), что про ленивость-строгость (Lazy t — сахар для () -> t (возможно, обёрнутого, не помню), но с неявными преобразованиями туда-сюда — хоть где-то они полезны кроме числовых типов!), и про типы коданных подход тоже понравился (тоже сахар, хотя в сложных случаях уже не помогает и надо писать всё явно).

[alex55555]

(Оффтоп)

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

И потом, это же Haskell, в этом вся суть.

Хаскель есть средство отображения алгоритмов на монитор. Завязываться на одно единственное отображение чревато многими неудобствами. Здесь скорее спортивное увлечение в виде "писать исключительно на хаскеле" (только хардкор!).

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

Имхо, если нет нужды в монадах, то что-то было сделано неправильно.

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

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

но на самом деле это должен быть монадный трансформер

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

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

Всё как раз получилось очень просто и естественно, в меру красиво, в меру абстрактно, в меру компромиссно. Одна проблема: адски тормозит, причём явно не по делу.

Значит нет понимания того, что делает программа. Вряд ли всё упирается в специфику компилятора. Скорее вы что-то недопонимаете в самой программе. И тогда заявления про "получилось очень просто" не совсем правильны.

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

Я так и не смог этого побороть, и этим закончилось моё знакомство с Haskell, теперь я всё, написанное на Haskell, переписываю на Rust

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

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

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

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

-- 04.12.2018, 18:51 --

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

Я по крайней мере имел в виду, что полиморфная функция не знает, какой тип a у некоторого из её аргументов, но притом если в коде функции используется метод инстанса C … a …, то мы, конечно, знаем инстанс (если не переборщили с опасными расширениями типа UndecidableInstances), но не знаем тип и потому должны в скомпилированной функции принимать словарь (dictionary) методов C дополнительным параметром

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

[arseniiv]

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

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

Я честно не припомню ни одного языка, где такое бы произошло.

-- Вт дек 04, 2018 20:34:14 --

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

[warlock66613]

(Оффтоп)

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

Значит нет понимания того, что делает программа.

Есть - я ведь её написал.

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

Вряд ли всё упирается в специфику компилятора. Скорее вы что-то недопонимаете в самой программе.

Не компилятора. Рантайма.

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

И тогда заявления про "получилось очень просто" не совсем правильны.

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

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

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

Выделено. К сожаление, выделение времени на понимание не гарантирует достижения этого понимания.

[alex55555]

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

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

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

-- 04.12.2018, 23:50 --

(Оффтоп)

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

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

Значит нет понимания того, что делает программа.

Есть - я ведь её написал.

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

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

Не компилятора. Рантайма.

Во время исполнения хаскель-программы, кроме GC, всё полностью определяется алгоритмами, используемыми компилятором. Скомпилируете на другом - возможны заметные отличия. Хотя, конечно, компиляторы чаще будут выдавать ошибку, мол такая-то фича не поддерживается, но иногда без всяких ошибок можно получить разные результаты, особенно по времени исполнения.

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

На уровне алгоритмов (если развернуть все монады обратно в чистые функции) - всё просто.

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

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

К сожаление, выделение времени на понимание не гарантирует достижения этого понимания.

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

[warlock66613]

(Оффтоп)

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

Вот в таком духе тонкостей в хаскеле хватает

Так я же про это и говорю. Вот все эти тонкости - это реальное препятствие для широкого применения Haskell. Функциональность и непривычность по сравнению с этим - ерунда.

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

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

Вы исходите из представления, что все люди равны. Это совершенно неверно.

[arseniiv]

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

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

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

[alex55555]

(Оффтоп)

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

Вы исходите из представления, что все люди равны. Это совершенно неверно.

Вообще да. Но на мой взгляд докопаться можно. Хотя это уже вряд ли кому-то нужно :)

-- 05.12.2018, 18:33 --

(Оффтоп)

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

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

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

[warlock66613]

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

если не рассматривать понижение строгости типизации языка

Кажется, это тот случай, когда надо очень внимательно различать такие атрибуты типизации как статическая/динамическая и строгая/нестрогая. Динамическая /= нестрогая.

[warlock66613]

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

[alex55555]

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

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

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

При этом нестрогая типизация позволяет просто не интерпретировать некоторые типы, как например типы float и int занимающие 4 байта, могут быть помещены в одно и то же место в памяти и далее использующая это значение функция выполнит с ними операции того типа, который предполагал увидеть программист, и в одном из случаев действительно будет логическая ошибка из-за разницы форматов float и int. То есть здесь нет самой возможности во время исполнения определить тип. В том числе поэтому С и С++ считаются небезопасными.

[warlock66613]

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

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

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

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

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

Это вообще не имеет никакого отношения к системе типов языка. (Можно подумать, что, например, в C# нельзя запихнуть float вместо int или наоборот.)

[arseniiv]

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

словарь функций, перебираемый во время исполнения

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

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

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

Но ей не передаются нетипизированные параметры, пока мы о позднем связывании в статических языках. Для ООП известен класс, пусть и абстрактный, или интерфейс, это ведь нормальные типы, и для языков с типоклассами известны ограничения, ну и вообще о типах отдельных аргументов функции самих по себе говорить не приходится (например, если у функции тип a -> b -> a -> A b -> …, первый и третий аргумент должны иметь один и тот же тип, хоть и не важно какой, а второй и четвёртый должны иметь подходящую пару типов, пример попроще, но требующий MultiParamTypeClasses: C a b c => a -> b -> c -> …), а когда можно (например, для const :: a -> b -> a), каждый имеет вполне корректный замкнутый тип (в примере оба имеют forall t. t, тип любого значения; это тип, а не его отсутствие, потому что система типов его умеет выражать и работает с ним регулярным в сравнении с остальными образом, а не как со специальным типом, добавленным только для интернализации в ней незнания типа (например, ради интероперации с динамическим языком)).

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

Но аналогичность ситуации с присваиванием переменной налицо

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

(UPD: Вот и warlock66613 конкретнее пишет по этому поводу.)

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

То есть здесь нет самой возможности во время исполнения определить тип.

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

[alex55555]

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

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

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

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

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

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

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

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

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

Это вообще не имеет никакого отношения к системе типов языка. (Можно подумать, что, например, в C# нельзя запихнуть float вместо int или наоборот.)

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

-- 07.12.2018, 15:46 --

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

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

словарь функций, перебираемый во время исполнения

Зачем его перебирать, словарь — это ведь просто запись из методов и ссылок на словари суперклассов. Каждому методу в этой структуре соответствует единственный путь.

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

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

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

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

Но ей не передаются нетипизированные параметры, пока мы о позднем связывании в статических языках.

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

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

Ну и нетипизированные функции, а ля JavaScript, это так же один из вариантов, но в нём строгость типизации понижена до общего предка уровня Object. То есть тип вроде есть, но по сути его нет.

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

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

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

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

это тип, а не его отсутствие, потому что система типов его умеет выражать и работает с ним регулярным в сравнении с остальными образом

Да, но в контексте JavaScript тип вроде есть, но по сути его нет. То есть всё опять про контекст.

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

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

То есть здесь нет самой возможности во время исполнения определить тип.

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

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