Я работаю с множеством карриных функций, принимая аналогичные аргументы, но не совсем. По этой причине мне было бы очень полезно иметь способ выполнить транспозицию, приложение и состав n-го аргумента, а также «окончательный» результат. Пример:Операции по n-му аргументу в кардинальных функциях в scala
val f :X=>Y=>W=>Z
def compose1[A](w :A=>Y) :X=>A=>W=>Z
def transpose1 :X=>W=>Y=>Z
def apply1(y :Y) :X=>W=>Z
Это может быть легко достигнуто при фиксированном значении п с чем-то вроде этого:
implicit class Apply2[X, Y, Z](private val f :X=>Y=>Z) extends AnyVal {
def transpose :Y=>X=>Z = { y :Y => x :X => f(x)(y) }
def provide(y :Y) :X=>Z ={ x :X => f(x)(y) }
def compose[A](y :A=>Y) : X=>A=>Z = { x :X => a :A => f(x)(y(a)) }
def apply[A, B]()(implicit ev :Z <:< (A=>B)) :Apply3[X, Y, A, B] = new Apply3[X, Y, A, B]((x :X) => (y :Y) => ev(f(x)(y)))
}
Но, конечно, я не приветствую идею авторских & -pasting 22 версии этого класса. Я также могу довольно легко сделать это для последнего аргумента с классом типа, , но решение, которое было бы похоже на succint для обозначения подчеркивания scala для частичного применения не-кардной функции, ускользает от меня. Я чувствую, что это должно быть возможно достигнуть следующих:
val f :A=>B=>C=>D=>E=>F
val c = f()().compose((x :X) => new C(x)) :A=>B=>X=>D=>E=>F
val t = f()().transpose :A=>B=>D=>C=>E=>F
val s = f()().set(new C()) :A=>B=>D=>E=>F
через неявное преобразование к некоторому Apply
, который обеспечивает рекурсивную apply()
метод, возвращающий вложенную Apply
экземпляр.
Когда все типы известны, грубое решение конвертирования в HList и обратно работает, но бесхарактерная зависимость - это немного обоюдоострый меч.
Можете ли вы объяснить, что вы подразумеваете под «устанавливает ловушки в общий код»? По моему опыту, я всегда чувствую себя более «захваченным» неявными преобразованиями, чем решениями типа класса. –
В первую очередь, зависимые от пути типы; столь же мощные, как и они, они также являются самым большим источником моего разочарования (и недоумением о ошибках компилятора в прошлом). Во-вторых, IntelliJ не очень хорошо понимает бесформенность. В-третьих, я тоже ... Не недостаток библиотеки, и я очень часто использую HLists, но я немного неохотно занимаюсь магией вокруг кода производственного цикла. – Turin
Отредактировано замечание о бесформенном, поскольку я не понимал, что это стало неконструктивной критикой, пока проблема между стулом и клавиатурой ... – Turin