𝛈µ
Если мы про статью, то это константная функция, вычисляющая значение функтора. Я думал, что достаточно понятно - есть интерфейс Functor<A>, есть его реализации.
Нет, непонятно
Size: a a a
2020 August 02
SA
Нет, непонятно
так тебе и не надо, ты и так всё понял давно
𝛈µ
Если мы про статью, то это константная функция, вычисляющая значение функтора. Я думал, что достаточно понятно - есть интерфейс Functor<A>, есть его реализации.
Покажи мне пример "передачи данных по сети" тогда плес
𝛈µ
Functor<A> = peredachadannikhovernetwork?
SA
Ещё раз мап сделать -- все, что я могу
Интерфейс - это альтернативный вариант сделать функтор. Можно запилить тайпкласс с методом map, можно заимплеменить интерфейс с методом map
SA
Ну сделал я foo.map(f), получил Functor<B>, что дальше мне делать?
Вот это странный вопрос). У нас есть код, которому для работы достаточно map, он будет абстрактный и всё такое. А вызывающая сторона может знать больше об этом типе.
ΛВ
Интерфейс - это альтернативный вариант сделать функтор. Можно запилить тайпкласс с методом map, можно заимплеменить интерфейс с методом map
Да пусть так, только интерфейс должен быть с тайп-параметром с дыркой, хосподи.
interface Functor<F<_>, A>{
fun <B> map(f: A -> B): F<B>
}
У вас в статье не так.
interface Functor<F<_>, A>{
fun <B> map(f: A -> B): F<B>
}
У вас в статье не так.
SA
Я, кажется, понял проблему. Подгорает у тех, кто уже давно в ФП. Кто ожидает увидеть законы, кто при виде
Functor триггерится "тайпкласс неправильно объявлен" и т.п.𝛈µ
Я, кажется, понял проблему. Подгорает у тех, кто уже давно в ФП. Кто ожидает увидеть законы, кто при виде
Functor триггерится "тайпкласс неправильно объявлен" и т.п.Да у тебя просто херня написана, которая только еще больше запутает
𝛈µ
Да пусть так, только интерфейс должен быть с тайп-параметром с дыркой, хосподи.
interface Functor<F<_>, A>{
fun <B> map(f: A -> B): F<B>
}
У вас в статье не так.
interface Functor<F<_>, A>{
fun <B> map(f: A -> B): F<B>
}
У вас в статье не так.
Разве котлин умеет в хкт?
SA
Да пусть так, только интерфейс должен быть с тайп-параметром с дыркой, хосподи.
interface Functor<F<_>, A>{
fun <B> map(f: A -> B): F<B>
}
У вас в статье не так.
interface Functor<F<_>, A>{
fun <B> map(f: A -> B): F<B>
}
У вас в статье не так.
Как раз нет, это не так. Правильный вариант - как в статье. Представь себе IO, который имплементит этот интерфейс. сигнатура же совпадет? за вычетом косяка, что map вернет Functor, а не IO
𝛈µ
Как раз нет, это не так. Правильный вариант - как в статье. Представь себе IO, который имплементит этот интерфейс. сигнатура же совпадет? за вычетом косяка, что map вернет Functor, а не IO
Давай ты еще таким же способом интерфейс для монады сделаешь
SA
Разве котлин умеет в хкт?
Не умеет. есть kotlin arrow-kt, но там костыли
𝛈µ
А то ты там обещал монаду в прелюдии, а потом про жалкий функтор пердел
𝛈µ
Народу нада манада
SA
Народу нада манада
Есть там манада. И абзац по теме есть:
В качестве примера реализуем функтор, который возвращает значение A, содержащее в себе некоторое количество случайных бит. Наш интерфейс в Котлине так просто использовать не получится (но при желании можно), поэтому напишем extension method:
SA
Я вижу, ты до него не дочитал)
𝛈µ
Щас дочитаю
𝛈µ
Даешь енотов-полоскунов
𝛈µ
interface Monad<A> {
// монада является функтором, но map реализовывать отдельно не нужно -
// он выражается через flatMap и lift
fun <B> map(f: (A) -> B): Monad<B> = flatMap { a -> lift(f(a)) }
fun <B> flatMap(f: (A) -> Monad<B>): Monad<B>
}
fun <A> lift(value: A): Monad<A> = TODO()