я чот совсем тупой, да?

какие тут нахер завтипы

Нихуя неясно type FromValue<'out>() = class end let example(from: FromValue<'out>): 'out = failwith "" let one = new FromValue<int>() let oneInt: int = example(one) let two = new FromValue<string>() let twoString: string = example(two)

Ну ты типы руками указываешь, обрати на это внимание

Ну ты типы руками указываешь, обрати на это внимание

где???

ну ты тоже указывал их руками!

если ты про let oneInt: int = ... то ясен хер это писать не надо

Чото что мапает значение в контейнере

let f a b c = a + b + c // int -> int -> int -> int let a, b, c = Some 1, Some 2, Some 3 // f a b c // не компилится let af = Some f // Some (int -> int -> int -> int) let bf = Option.apply af a //Some( int -> int -> int) let cf = Option.apply bf b // Some (int -> int) let df = Option.apply cf c //Some int

let f a b c = a + b + c // int -> int -> int -> int let a, b, c = Some 1, Some 2, Some 3 // f a b c // не компилится let af = Some f // Some (int -> int -> int -> int) let bf = Option.apply af a //Some( int -> int -> int) let cf = Option.apply bf b // Some (int -> int) let df = Option.apply cf c //Some int

аппликативный фтор

Мне сложно

функтор это для чего есть Select, монада / TakeWhile, а аппликатив это Aggregate

аппликативный фтор

а фтор это в зубной пасте )

а фтор это в зубной пасте )

и она апплицирует на зубы

фуу

ну ты тоже указывал их руками!

В методе example никаких дженерик параметров у меня нет. И компилятор это разруливает сам. Но ладно, чуть другой пример: trait Parent { type Child } trait DependentPair { val x: Parent val dependsOnX: x.Child }

Это самый настоящий сигма тип

В методе example никаких дженерик параметров у меня нет. И компилятор это разруливает сам. Но ладно, чуть другой пример: trait Parent { type Child } trait DependentPair { val x: Parent val dependsOnX: x.Child }

смысл ни на каплю не поменялся. Вообще ни на грам

Он там расжовывает на простых примерах

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

Для настоящих зависимых типов ещё надо уметь выражать пи тип (а вот тут нам имплиситы помогут): trait Pi[T] { type U } def dependent[T](t: T)(implicit pi: Pi[T]): pi.U = ???

смысл ни на каплю не поменялся. Вообще ни на грам

Я просто что-то плохо обьясняю.

let f a b c = a + b + c // int -> int -> int -> int let a, b, c = Some 1, Some 2, Some 3 // f a b c // не компилится let af = Some f // Some (int -> int -> int -> int) let bf = Option.apply af a //Some( int -> int -> int) let cf = Option.apply bf b // Some (int -> int) let df = Option.apply cf c //Some int

Понял

смысл ни на каплю не поменялся. Вообще ни на грам

Ок, чуть другой пример, который через дженерики не получить: val one: Parent = ??? val two: Parent = ??? val three: Parent = ??? // скопилится, т.к. у этого инстанса точно один и тот же тип: implicitly[one.Child =:= one.Child] // не скомпилится, т.к. эти типы для компилятора разные implicitly[two.Child =:= three.Child] implicitly[one.Child =:= two.Child]

Ок, чуть другой пример, который через дженерики не получить: val one: Parent = ??? val two: Parent = ??? val three: Parent = ??? // скопилится, т.к. у этого инстанса точно один и тот же тип: implicitly[one.Child =:= one.Child] // не скомпилится, т.к. эти типы для компилятора разные implicitly[two.Child =:= three.Child] implicitly[one.Child =:= two.Child]

круто, но где это использовать?

я не очень понял

круто, но где это использовать?

хз type Parent<'child>() = class end type DependentPair<'a> = abstract member x: Parent<'a> abstract member dependsOn: 'a

так и не понял нихуя я

хз type Parent<'child>() = class end type DependentPair<'a> = abstract member x: Parent<'a> abstract member dependsOn: 'a

Разница в том, что тебе приходится тут явно пропихивать дженерик параметр.

Разница в том, что тебе приходится тут явно пропихивать дженерик параметр.

тайп инфиренс спрячет

и слово приходится тут неуместо. ты пишешь x.Child

я пишу <'a>

тайп инфиренс спрячет

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

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

ещё раз. не придётся

в скале - да

ещё раз. не придётся

В определения методов

Не в коде вызывающем, а в определении самих методов

В структурах, которые будут использовать эту структуру и т.д.

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

Ещё раз, напиши код, который сломается на языке с дженериками

или будет выглядеть вырвиглазно

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

но на языке с дженериками надо писать дженерик тип, а на языке без дженериков надо писать type.Type

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

Я выше писал пример про неравенство внутренних типов

Вот он ломается.

Я выше писал пример про неравенство внутренних типов

я честно сказать не совсем понял что там написано. Я даже не в курсе что делает оператор =:=

то есть я примерно нихуя не понял

я честно сказать не совсем понял что там написано. Я даже не в курсе что делает оператор =:=

Он на этапе компиляции проверяет равны ли данные типы

Ещё раз, напиши код, который сломается на языке с дженериками

Я просто пытаюсь минимальный пример найти, но оно не так просто выходит.

Я выше писал пример про неравенство внутренних типов

https://t.me/fsharp_flood/120235

https://t.me/fsharp_flood/120235

Оно вместе с имплиситами в основе шейплесса лежит.

Господа, а можете объяснить что такое аппликативный функтор? А то в книге прочитал и нихуя не понял

Есть видос Влашина,тоже вполне годный (тайминг 54:27) https://youtu.be/Nrp_LZ-XGsY

я честно сказать не совсем понял что там написано. Я даже не в курсе что делает оператор =:=

Не смог найти минимального и простого примера, иду по хардкору: Ну да, тут основная разница в том, что у тебя у инстансов одного типа (Parent) оказываются разные внутренние типы (instanceOne.Child) и (instanceTwo.Child). Если этот факт и type projection не использовать, то да, можно всегда заменить дженериками (пусть и вербознее будет в дженерик методах, структурах и т.д.) Если добавить при этом type projection, то тут открываются приколы повеселее: trait Nat { type Add[A <: Nat] <: Nat type Mult[A <: Nat] <: Nat } class _0 extends Nat { type Add[A <: Nat] = A type Mult[A <: Nat] = _0 } class S[N <: Nat] extends Nat { type Add[A <: Nat] = S[N#Add[A]] type Mult[A <: Nat] = A#Add[A#Mult[N]] } type +[A <: Nat, B <: Nat] = A#Add[B] type *[A <: Nat, B <: Nat] = A#Mult[B] type _1 = S[_0] type _2 = S[_1] type _3 = S[_2] type _4 = S[_3] type _5 = S[_4] type _6 = S[_5] type _7 = S[_6] type _8 = S[_7] type _9 = S[_8] type _10 = S[_9] type _11 = S[_10] implicitly[_3 =:= _1 + _2] implicitly[_4 =:= _2 * _2]

Увы, не нашел на своем компе более минимального примера логики на type projection, так что пришлось стащить стандратную пеановскую арифметику

Такое просто на дженериках уже никак не сделать

Такое просто на дженериках уже никак не сделать

На дженериках с хкт сделать же

но конкретно в фшарпе нет хкт

так что дело тут не в дженериках

На дженериках с хкт сделать же

Тебе тогда руками придется их протаскивать

Тебе тогда руками придется их протаскивать

разок объявить, да.

но опять же, дальше тайп инфиренс выводить эту срань должен

но хкт нет, поэтому первый же трейт на фшарпе невыразим type Nat<'add<'a>, mult<'a>> = ...

но хкт нет, поэтому первый же трейт на фшарпе невыразим type Nat<'add<'a>, mult<'a>> = ...

Можно попробовать на скале так записать только на хкт

Можно попробовать на скале так записать только на хкт

лучше на хачкеле

лучше на хачкеле

Не уверен, что без сабтайпинга оно сработает как надо

Надо чуть подумать.

а, чорт

проклятый хачкель

В хаскеле такое на тайпклассах делают

+ fundeps или type families

Скаловские type projection - это как раз некий аналог type families

Насколько я понимаю.

а, чорт

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

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

По сути это изоморфно должно быть. Ты таскаешь типы в инстансе типа, но генерики это то же самое. Просто объявление в другом месте, но типы все равно таскаются с инстансом

По сути это изоморфно должно быть. Ты таскаешь типы в инстансе типа, но генерики это то же самое. Просто объявление в другом месте, но типы все равно таскаются с инстансом

Если говорить просто про abstract types - то да. Если к этому добавить path dependent (то, что не равны внутренние типы для разных инстансов внешнего) - то нет. (Но это относительно бессмысленно в твоем энкодинге) Если к этому добавить type projection - то по идее тоже нет. Вопрос - если взять хкт + скаловский/F# саб тайпинг, можно будет получить выразительную силу type projection?

Если говорить просто про abstract types - то да. Если к этому добавить path dependent (то, что не равны внутренние типы для разных инстансов внешнего) - то нет. (Но это относительно бессмысленно в твоем энкодинге) Если к этому добавить type projection - то по идее тоже нет. Вопрос - если взять хкт + скаловский/F# саб тайпинг, можно будет получить выразительную силу type projection?

Если вопрос ко мне, то я не знаю :)

Если вопрос ко мне, то я не знаю :)

Это вопрос скорее риторический. Я как-нибудь на досуге попробую

Тут, конечно, извиняюсь, из меня плохой рассказчик с самого начала был. Надо было сразу явно разделить и рассказать про abstract types, path dependent types и type projection. А я всё в кучу смешал

И само собой ничего не понятно было.

Но тут и скала все усложнила, потому что в расте и хаскеле, они себя скорее как type projection введут, а не как скаловские abstract types

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

можно тоже попробую жести вкинуть ))

Пример из туториала по миксинам Есть трейт итератор abstract class AbsIterator { type T def hasNext: Boolean def next: T } Нам нужен foreach, это не ключевое слово, просто функция. Можно расширить трейт без явного знания, что такое Т, но с использованием T, hasNext и next trait ForEachIterator extends AbsIterator { def foreach(f: T => Unit) { while (hasNext) f(next) } } а можно нашлепать еще кучу расширений, например итерацию по каждому второму Каждый раз указывать тип T неудобно, особенно если он там не нужен, или их там больше одного trait EverySecondIterator extends AbsIterator { def everySecond(f: T => Unit) { while (hasNext) { next if (hasNext) f(next) } } } Можно взять тип и определить трейт для типа Т, например String, независимо есть там foreach или нет. Тут пока как обычно побуквенно class CharsIterator(s: String) extends AbsIterator { type T = Char private var i = 0 def hasNext = i < s.length() def next = { val ch = s charAt i; i += 1; ch } } или по-словно class WordsIterator(s: String) extends AbsIterator { type T = Char private var i = 0 val words = s.split(' ') def hasNext = i < words.length() def next = { val word = words elemAt i; i += 1; word } } а теперь их можно комбинировать, хотя везде уже есть реализация с кодом - кейк паттерн так называемый class WordsIter extends WordsIterator(args(0)) with ForEachIterator with EverySecondIterator val words = new WordsIter words foreach println class CharsIter extends CharsIterator(args(0)) with ForEachIterator val chars = new CharsIter chars foreach println такая петрушка используется в скалатесте, там можно указать "матчеры" (у здорового человека "ассерты") по вкусу - expect, shouldbe, property итп или структурой и наименованием тесткейсов управлять - плоско или вложенно

Хм, столкнулся с ситуацией, где None -- это happy path, а Some нежелателен. Это ж нормально? А то непривычно как-то.