Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Воронков Василий, Вы писали:
VD>>>Дело не в линке. Дело в способе вызова функций. ВВ>>А он и так разный. Есть там каррирование, нет там каррирования.
S_>А вобще у каррирования есть полезные применения кроме перестановки аргументов местами? Просто я не в курсе патернов ФП. Вобще частичное применение может и полезно, но в карировании только по-порядку нужно частично применять.
Есть один интересный аспект, который в обсуждениях каррирования пока не упоминался. Это типы функциональных аргументов, получаемых другими функциями. Я на примере OCaml'а дальше. List.map2 — применяет заданную функцию к элементам двух списков и выдает список результатов. Допустим, каррирования нет. Какой тип у нее должен быть? Есть два варианта
('a -> 'b -> 'c) -> 'a list -> 'b list -> 'c list или
(('a, 'b) -> 'c), 'a list, 'b list) -> 'c list
Фокус здесь в том, что первый аргумент этого мапа может иметь принципиально два "разных" типа. Это либо "честная" функция от двух аргументов, либо функция, возвращающая функцию. Второй вариант вполне может возникать, если у нас есть функции, возвращающие лямбду. Никаких частичных применений при этом не нужно (лямбда все же не частичное применение), хотя и вполне возможно. При написании удобно — можно не заботится приведениями типов к "правильным" функциям. Далее парочка примеров применения List.map2
(* identity f где f функция можно применять как (identify(f))(x) *).
let identity x = x;;
(* а это просто применение apply(f,x)).
let apply f x = f x;;
(* применяем обе *)
# List.map2 identity [(+) 1; (-) 1 ] [3;4];;
- : int list = [4; -3]
# List.map2 apply [(+) 1; (-) 1 ] [3;4];;
- : int list = [4; -3]
(* более реалистичный пример, какие-нибудь обработчики и диспетчеризация. Частичных применений нет. *)
let handlers = Hashtbl.create 2;;
let add_1 x = x + 1;;
let sub_1 x = x - 1;;
Hashtbl.add handlers 1 add_1;;
Hashtbl.add handlers 2 sub_1;;
(* Формальный тип функции - int -> (int -> int) *)
let find_handler x = Hashtbl.find handlers x;;
(* Применяем соответствующие обработчики к аргументам *)
#List.map2 find_handler [1; 2; 1; 1] [6; 9; 9; 3];;
- : int list = [7; 8; 10; 4]
(* И в то же время тот же самый List.map2 с функцией типа "(int, int) -> int" *)
let sum x y = x + y;;
# List.map2 sum [1;2;3] [3;2;1];;
- : int list = [4; 4; 4]
Во втором примере еще и лямбды из функций не возвращаются. Без "каррирования" было бы не слишком удобно, пришлось бы где-то вручную преобразования писать. В целом при "осутствии" каррирования либо затруднилось бы написание функций высшего порядка (нужно долго выбирать, какой вариант получать на входе), либо нужно было бы руками много преобразований типов писать.
На всякий случай — по определению функции let f x y = ... это функция, которая возвращает функцию. Можно написать и let f (x,y) = ..., это будет фунцкия от одного аргумента — tuple. Последний вариант не принят и используется только там, где в качестве аргументов идут уже сформированные ранее туплы. Ну и с учетом простого правила "все функции — только от одного аргумента" понятия "каррирование", "декаррирование" и "частичное применение" не нужны.
P.S. На практике все эти каррирования и частичные применения все же возникают в случае наличия в функциях побобчных эффектов. Важен будет момент, когда возникает этот самый эффект, а это зависит от того, как именно описана исходная функция. Но в чистом ФП все остается просто прекрасно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Иначе говоря, получается, что проблема гибридных языков не в том, что в ФП стиле на них писать неудобно, а в том, что на них удобно писать в *гибридном* стиле.
Вот с этим согласен, с оговоркой — это не проблема, а достоинство.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Я описал причины, почему ФП-стиль неудобен. Приходится писать в ленивом стиле и неэффективный код. Я читаю это как не "неудобнее", а как "неудобно".
А ты перестань читать между строк и задай интересующие тебя вопросы автору высказываний.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
ВВ>>Именно что оптимизации. Т.е. разговор переводится уже в другую плоскость. L>Ну так мы о практике.
Мне казалось мы говорим об удобстве
ВВ>>Какие там есть чистые энергичные языки? Что-то навскидку не вспомнил L>Достаточно иметь куски, явно объявленные для компилятора как чистые.
Компиляторы сейчас умные пошли, может, им и не надо кусков явно объявленных как чистые. Сами догадаются что где устранить. Я думаю такие оптимизации и для грязных императивных языков возможны. Но опять же я не понимаю — как это влияет на удобство
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Klikujiskaaan, Вы писали:
VD>>> претензии эти в неизменном виде повторяются одним и тем же человеком с завидной периодичностью.
K>>А воз и ныне там :-D
VD>Какой воз?
Я про недовольство\шапкозакидательство со стороны nemerle-hater vs nemerle addict. Сижу не так давно на рсдне (года 2а), а споры по этому вопросу все те же =)
Здравствуйте, VladD2, Вы писали:
VD>Ага. А если еще вспомнить, что на Скалу можно довольно легко переучить любого хорошего Ява-программиста, а на Немерл любого хорошего шарписта, то вопрос и вовсе начинает выглядеть надумано.
Значит, я — плохой шарпист с 7+ летним стажем и хороший явист с нулевым стажем... Так?
Здравствуйте, Wolverrum, Вы писали:
VD>>Ага. А если еще вспомнить, что на Скалу можно довольно легко переучить любого хорошего Ява-программиста, а на Немерл любого хорошего шарписта, то вопрос и вовсе начинает выглядеть надумано.
W>Значит, я — плохой шарпист с 7+ летним стажем и хороший явист с нулевым стажем... Так?
А какие у тебя проблемы то?
Хотя тебе конечно виднее .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Хотя тебе конечно виднее .
Вот не поверишь — даже дженерик хаскель проще пошел Хотя немерле в поле зрения дай бог памяти где-то с версии 0.8.какой-то.
Здравствуйте, Wolverrum, Вы писали:
W>Вот не поверишь — даже дженерик хаскель проще пошел Хотя немерле в поле зрения дай бог памяти где-то с версии 0.8.какой-то.
Вообще-то такой в природе не было. За 0.3.х сразу появилась 0.9.
Может потому и не пошел, что "в поле зрения" держал, а не пробовал?
Вменяемый C#-щик должен освоить его максимум за месяц.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Wolverrum, Вы писали:
W>>Вот не поверишь — даже дженерик хаскель проще пошел Хотя немерле в поле зрения дай бог памяти где-то с версии 0.8.какой-то.
VD>Вообще-то такой в природе не было. За 0.3.х сразу появилась 0.9.
Ты прав. В общем. с 2005 года — точно
VD>Может потому и не пошел, что "в поле зрения" держал, а не пробовал?
Я его честно пробовал Со своими либами, помнится, проверял работоспособность, с помощью cs2n пытался врубиться, ибо доки были слегка "того" (кстати, положительный прогресс в этом плане — респект!) Потом — баги с интеграцией, а потом забил — все это было где-то в районе 2005й студии еще. Потом — да, "а не пробовал"...
VD>Вменяемый C#-щик должен освоить его максимум за месяц.
Согласен. Хотя лично я щас точу вражескую скалу
— в основном, последняя строка, вроде как обоюдной пользой грозит
Честно говоря меня очень заинтересовали твои слова. Главным образом мне хотелось бы понять, что не понятно. Понимание этого могло бы позволить понять что же нужно менять в документации и описании языка.
Если есть время и желание предлагаю связаться со мной по Скайпу (экаунт VladD2) или Windows Live Messenger (vc@rsdn.ru) и пообщаться тет-а-тет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
ВВ>>Проблема с "ненастоящими" генериками, как я понимаю, прежде всего в упаковке.
N>С версии 2.8 дженерики в Scala не требуют упаковки — компилятор создаёт специализации.
Кстати, а что при этом происходит с размерами кода? В С++, в свое врем, это было серьезной проблемой, пока компиляторы не научились объединять бинарно-совместимый код и выкидывать дубликаты. Ява же джитит все в рантайме и этим точно заниматься не будет. Не увеличивает ли это расход памяти?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
N>>С версии 2.8 дженерики в Scala не требуют упаковки — компилятор создаёт специализации.
VD>Кстати, а что при этом происходит с размерами кода? В С++, в свое врем, это было серьезной проблемой, пока компиляторы не научились объединять бинарно-совместимый код и выкидывать дубликаты. Ява же джитит все в рантайме и этим точно заниматься не будет. Не увеличивает ли это расход памяти?
Да, код раздувается. Но в JVM value-типов: раз, два — и обчёлся (свои собственные определять нельзя). Так что рост ограниченный и предсказуемый.
Здравствуйте, lomeo, Вы писали:
L>Я знаю и меня это огорчает На самом деле это поразительный факт — код с функциями и данными вперемешку понятнее кода с функциями. L>
L>saving = 0
L>for employee in staff
L> if employee.isFired
L> saving += employee.salary
L>return saving
L>
L>понятнее чем L>
L>(sum . map salary . filter isFired) staff
L>
А если развернуть, то, имхо, становится понятнее и приятнее первого варианта...
На самом деле это поразительный факт — код с функциями и данными вперемешку понятнее кода с функциями.