не конкретно Number -> Number -> Number

Обоснуй

Обоснуй

любое "складываемое"

Опа, уже обобщения пошли)

Num a => a -> a -> a

вот ж

Ты сложил два числа и получил результат a?

вместо a ты подставляешь тип, если это простые int, то получил int

если это float, то float

если complex, то complex

все зависит от природы чисел

Иррациональные забыл

Я говорю про конкретные 2 и 3

Забудь про свои классы, я о другом)

Ух! Спасибо! Странно что примеров такого использования нигде не встречается )

Даже в тестах?

Ты можешь говорить, что результат будет числом, потому что система типов статически тебе вывела это

да, окей

хотя "статически вывела" что значит?

Compile time

окей, а система типов это компилятор?

Это математическое понятие

как это математическое понятие живет в compile time?

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

Оно в спеке языка живёт)

Оно в спеке языка живёт)

мы про какой язык кстати?

Любой

лол

Кроме клингонского, тот живёт в сенарии

Любой

function f(a, b) { return a+b; } что скажет тебе спека языка про типы в compile-time?

То что жс — динамически компилируемый

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

а про типы?)

окей, что значит "доказывать утверждения о своих объектах"?

что такое "статическая система типов" знаю немного, вроде)

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

В хаскелле перед этим идёт статическая система, про которую я сейчас и говорю)

не, она как раз после идет)

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

У всех объектов есть единый интерфейс для взаимодействия. Любые два числа сложатся функцией a -> a -> a, любые два других типа — тоже, причём это будет выводиться для любых твоих объектов так же, как и в примере с числами до этого

Если у тебя есть объект, то ты знаешь, что его .map вернёт именно его же

Если у тебя есть объект, то ты знаешь, что его .map вернёт именно его же

что значит его .map?

не у всех объектов есть map

или ты про fmap функторов?

не у всех объектов есть map

Да, это категория Functor

ага, окей

У числа есть .map, и n.map( a -> a) даст тебе число при любом исходе, без исключений, потому что это выводится из самого подхода

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

"чем обычно" - это как?

У числа есть .map, и n.map( a -> a) даст тебе число при любом исходе, без исключений, потому что это выводится из самого подхода

имея функтор f, операция f.map(a -> b) даст мне в результате функтор f b, а не f a. И это тоже вполне безопасно, без исключений, выводится из самого подхода и т.д.

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

имея функтор f, операция f.map(a -> b) даст мне в результате функтор f b, а не f a. И это тоже вполне безопасно, без исключений, выводится из самого подхода и т.д.

Да, ты можешь об этом говорить обобщено, потому что кроме сигнатуры функции тебе ничего не нужно

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

напомню изначальный вопрос

очевидно f a и f b это разные типы, но если хочется совсем разного, то можно опять же взять a -> f a

Вот

или да боже, apply :: (a -> b) -> a -> b

Так же очевидно, что а -> a вернёт один тип

а a -> b вернет любой

и?)

Не любой, а любой тот же

Гарантированно

Не любой, а любой тот же

какой тот же?

Если у тебя такие правила применяются повсеместно, без исключений , то неоткуда взяться исключениям из правил

какой тот же?

а

Считай это дженериком

а a -> b вернет любой

b же

я знаю, что это такое)

Ну ты на какую то свою линию отклоняешься вечно) Я не говорю тебе про функцию a -> b

А тупо про function<a>(_a: a): a

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

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

Мы можем сделать tree обобщённо так же как array и у него изначально будет тот же способ для взаимодействия с ним

я говорю, что a -> a и a -> b одинаково типобезопасны

Да

и не понимаю, зачем и как к функции a -> a приплетается типобезопасность

Но вне контекста a -> b не значит ничего, мы берём что-то и возвращаем что-то ещё

она приплетается к любой функции, которая типизируется

Но вне контекста a -> b не значит ничего, мы берём что-то и возвращаем что-то ещё

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

хотим конкретнее - описываем конкретнее

Неет

В этом вся фишка

У тебя это утверждение выполняется в любом случае

нет

У меня вообще создается впечатление что ramda частично состоит из методов, которые не просто редко кем используются, а которые вообще практически никогда ни кем не применялись в деле )

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

Ну это у тебя нет, у меня нет, ты спросил - я отвечаю, почему))

У тебя есть единый интерфейс чтобы применить любую функцию a -> a к любому объекту

взять тот же compose: compose :: (a -> b) -> (b -> c) -> (a -> c)

нам абсолютно пофигу что принимают функции

важна связь типов

Забудь про них, попробую сразу дальше объяснить)

У тебя есть единый интерфейс чтобы применить любую функцию a -> a к любому объекту

Попробуй это представить

Просто теоретически, что будет если это правда

думаю справлюсь)

А разве нет конкретно определения у функций, которые принимаю значение и возвращают значение одного типа?

К промису и к комплексному числу - один и тот же способ

один и тот же способ чего?)

Применить любую функцию типа a -> a к объекту

есть языки где нет единого способа применить функцию к объекту?

в том числе и a -> a?