Тогда моя не понимать

Он контрвариантен

Ну вообще списки в Котлин ковариантны, так что нет.

Ну вообще списки в Котлин ковариантны, так что нет.

Да я всегда их путаю, никак не могу запомнить эту терминологию, но это не меняет сути - это не полиморфизм

ну вот есть класс/объект/функция: object Wtf { fun <T> id(obj: T): T = obj } и нельзя просто так взять и Wtf::id, функциональный тип неспособен это выразить. Это функция с другой сигнатурой, у функционального типа 0 тафп-параметров, а тут один.

Да я всегда их путаю, никак не могу запомнить эту терминологию, но это не меняет сути - это не полиморфизм

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

Эт не ковариантность не даёт, а здравый смысл)

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

Я хочу прув такой интерпретации слова полиморфизм

Пока что я могу хотя бы википедией кинутся https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D0%B8%D0%BC%D0%BE%D1%80%D1%84%D0%B8%D0%B7%D0%BC_(%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)

...ковариантность же позволяет List<Nothing> использовать в качестве List<Number> или List<String>.

И там всё довольно однозначно

И там всё довольно однозначно

Да, в рамках теории типов, где всё есть лямбда, аннотированная некоторым типом, полиморфизм оно и есть, так как там значения тоже лямбды (объекты). Так и в Котлин все значения - объекты.

Между лямбдами и объектами есть простой изоморфизм, который я выше писал, так что вполне можно считать, что всё в языке есть лямбда.

Эмммм

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

Как через лямбду выразить мутабельный список?

Какой тут будет изоморфизм?

Иммутабельный список можно выразить через гетерагенный список, а вот что с мутабельным?

Я конечно довольно слаб в теории типов, но что то мне кажется что никак

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

Ну есть же лямбда исчисления и вот это всё

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

Как через лямбду выразить мутабельный список?

Ну состояние в лямбда исчислении можно выразить через продолжения в превом приближении. Более красиво через State монаду, которая следит за тем, как к State применяются операции. Собсна, на State монаде можно выразить изменяемый список, правда работать с ним можно будет только в контесте монады.

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

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

Внутри - да. Для внешнего пользователя это не важно, так как инкапсулировано в монаду.

Так что получится нечто, что ходит как мутабельный список, крякает как мутабельный список => его вполне можно считать мутабельным списком.

Внутри - да. Для внешнего пользователя это не важно, так как инкапсулировано в монаду.

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

Параллелые != асинхронные

Хотя это уже наверное про эффекты и в контексте монад некоректно про это рассуждать ?

Хотя это уже наверное про эффекты и в контексте монад некоректно про это рассуждать ?

Ну почему же. Есть Concurrency Monad, которая как раз занимается организацией параллельных вычислений. В Java что-то подобное реализовано в виде RX Observable

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

Ну и есть Parallel, который вовсе не обязан быть concurent

В контексте State монады не получится в параллельные вычисления, она для этого не предназначена. Ну и в Котлине для подобных операций список небезопасно использовать. Нужен thread safe вариант и плюс куча ограничения на опреации.

Параллелые != асинхронные

я же обозначил

Речь просто про два последовательных обособленных вычисления

Речь просто про два последовательных обособленных вычисления

Так последовательные или параллельные?

Так последовательные или параллельные?

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

Русский язык не справляется с выражением мысли

Нужно рисовать

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

То есть у нас есть точка сериализации обращений к изменяемому списку, в которой выстраивается последовательность "произошло до" между ними?

Ну короч все эти рассуждения все равно не дают права в котлине написать val <A> a :)

Ну короч все эти рассуждения все равно не дают права в котлине написать val <A> a :)

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

Ну почему нет, например вот есть такое выражение: val <A> a: A= ??? Что можно написать вместо ??? кроме throw new Exception

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

Ну почему нет, например вот есть такое выражение: val <A> a: A= ??? Что можно написать вместо ??? кроме throw new Exception

Ничего. Bottom type не населён

Хотя можно ещё в бесконечную рекурсию уйти в поисках значения :)

Ну это уже опять будет функция, которая вызывает саму себя

короч нужна функция :)

короч нужна функция :)

Ну нужен объект в правой стороне.

val <A> a: A = a Как-то так

Хм, а как котлин развернёт вообще val a: Any = a ?

короч нужна функция :)

Ну и функция - тоже. Кто-то же должен объект создавать. Вот как вариант: tailrec fun <A> bottom(): A = bottom() val <A> a: A = bottom()

Хм, а как котлин развернёт вообще val a: Any = a ?

эм, нет

Ну и функция - тоже. Кто-то же должен объект создавать. Вот как вариант: tailrec fun <A> bottom(): A = bottom() val <A> a: A = bottom()

С нормальным котлином функция вызывается с этим тайп-аргументом перед присваиванием. А когда ей вызываться, есть val <A>?

эм, нет

Всмысле компилятор нахер пошлёт?

Всмысле компилятор нахер пошлёт?

ну конечно, до присваивания a переменная a не имеет значения

Хм, а как котлин развернёт вообще val a: Any = a ?

А зачем такое?

чисто теоритические изыскания

А зачем такое?

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

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

Хорошо, а что бы выражало такое определение?

Хорошо, а что бы выражало такое определение?

bottom type значение. Оно же undefined error

bottom type значение. Оно же undefined error

Тогда оно должно же иметь тип Nothing, а не Any

Его не существует. bottom type не населён. Но сам тип должен быть с точки зрения полноты системы типов (он наследник всех типов).

Тогда оно должно же иметь тип Nothing, а не Any

Логично, да. Nothing и есть bottom type в Котлине

И тогда можно сделать val a = TODO()

Ну Nothing - это точно бросок исключения

Ну Nothing - это точно бросок исключения

val a = null имеет тип Nothing?

переменной должно быть присвоено значение, а у Nothing множество значений пустое

ERROR: S client not available

null же в соседней от Nothing иерархии

Ну Nothing - это точно бросок исключения

С точки зрения теории, получение значения bottom type должно либо ронять всё с ошибкой, либо уходить в бесконечную рекурсию.

то есть у него по сути тип Null с единственным значением

Да, все верно и val a = TODO() просто бросит исключение

Ок

null же в соседней от Nothing иерархии

null != Nothing в Котлине. На null можно проверить nullable значение, Nothing проверить обычным способом нельзя, только отлавливая исключения.

Но вообще, есть ли смысл пытаться выразить значения типа, у которого нет значений?

Есть пример языка, который такое может?

Есть пример языка, который такое может?

Котлин. TODO() возвращает полиморфное значение (на самом деле падает в рантайме), но с точки зрения провеки типов проходит.

не полиморфное, просто подтип всего

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

Котлин. TODO() возвращает полиморфное значение (на самом деле падает в рантайме), но с точки зрения провеки типов проходит.

Я про пример val a = a

Ну в скалке - это ок, и будет просто рекурсия

Я про пример val a = a

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

То есть, чтобы узнать чему равно а, сходи в а, где написано, что чтобы узнать, чему равно а, сходи в а, где написано ...

Ну в скалке - это ок, и будет просто рекурсия

А в скалке есть полиморфные значения?

А в скалке есть полиморфные значения?

неа

неа

Хмм... Странно. Я всегда думал, что это Haskell для JVM ?

В scala 3 вроде порывались сделать, не помню точно что решили

Хмм... Странно. Я всегда думал, что это Haskell для JVM ?

У скалки таже ситуация, не всё есть функция

Вот bottom type на Haskell: Prelude> let a = a Prelude> :t a a :: t Если попросить вывести a - уйдёт в рекурсию.

фига себе язык с безопасной системой типов)

У скалки таже ситуация, не всё есть функция

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

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

Да есть

Ну типо никто не мешает тебе написать val a = a

фига себе язык с безопасной системой типов)

Ну с точки зрения системы типов тут всё ок. Он тебе говорить, что тип полиморфный до нельзя. Такой тип однозначно bottom => трогать в рантайме не стоит

фига себе язык с безопасной системой типов)

Ну с точки зрения типов тут всё ок

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

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

Таких - да, а вот значение типа t -> t вполне себе есть. Целое одно. identity лямбда

подскажите. Вот есть у меня класс class TopEntryRowMapper<T> (val valueClass: Class<T>) : RowMapper<TopEntry<T>> { override fun mapRow(res: ResultSet, rowNum: Int): TopEntry<T> { return TopEntry(res.getString("username"), res.getObject("topvalue", valueClass)) } } Я могу его передать туда, где ждут RowMapper<TopEntry<Int>> вот такое - TopEntryRowMapper(Int::class.java) Можно это переделать на функцию типа private inline fun <reified T : Any> mapTopEntry(res: ResultSet, rowNum: Int): TopEntry<T> = TopEntry( res.getString("username"), res.getObject("topvalue", T::class.java) ) и передавать ссылку на неё как-то?

inline функции по сути нет

подскажите. Вот есть у меня класс class TopEntryRowMapper<T> (val valueClass: Class<T>) : RowMapper<TopEntry<T>> { override fun mapRow(res: ResultSet, rowNum: Int): TopEntry<T> { return TopEntry(res.getString("username"), res.getObject("topvalue", valueClass)) } } Я могу его передать туда, где ждут RowMapper<TopEntry<Int>> вот такое - TopEntryRowMapper(Int::class.java) Можно это переделать на функцию типа private inline fun <reified T : Any> mapTopEntry(res: ResultSet, rowNum: Int): TopEntry<T> = TopEntry( res.getString("username"), res.getObject("topvalue", T::class.java) ) и передавать ссылку на неё как-то?

А как должен выглядеть тип передаваемой ссылки?