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

[warlock66613]

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

Если параметр нетипизирован в момент компиляции

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

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

Там ещё и юнионы из таких типов есть, что бы жизнь мёдом не казалась.

Совпадение размеров инта и флоата тут не при чём. Даже несовпадающие по размеру типы можно положить в юнион. Да, использование юнионов ослабляет типизацию, но вы выше их не упоминали.

[arseniiv]

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

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

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

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

Но ведь конкретный алгоритм не указан

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

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

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

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

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

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

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

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

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

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

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

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

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

Reflection использует программист, а компилятору эта штука не нужна, поскольку у него данные о программе уже присутствуют во вполне полноценном виде

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

-- Пт дек 07, 2018 18:01:22 --

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

[alex55555]

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

Давайте подведём черту и перепишем, какие конкретно вопросы или утверждения на данный момент требуют обсуждения

Так я уж пытался всё в оффтоп запихнуть :)

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

[warlock66613]

Возвращаясь к теме Haskell vs. Rust.
Я переписал сейчас кое-какой свой код с Haskell на Rust. С сохраненим поведения и архитектуры, насколько это возможно не нарушая идеоматичность. И 300 строк хаскела превратились в 1300 строк раста. Но несмотря это, код на Rust мне нравится больше.

[arseniiv]

Интересно.