Здравствуйте, Воронков Василий, Вы писали:

ВВ>Каррирование дает удобную форму для поинт-фри и для построения комбинаторов. Собственно, поинт-фри естественным образом проистекает из факта каррированности функций. Да и перегрузке по типу он не особо-то и мешает.

Частичное применение в стиле Немерле может все то же, что и карринг. При этом оно не превращает типы функций в набор стрелочек.

Еще до того как я узнал про Немерле, мне казалось, что карринг — какой-то динозавр из 60-х, от которого не избавляются лишь в дань традиции (аналогично называнию локальных функций лямбдами).

Если у меня есть каррированная функция Int -> Int -> String -> Double, почему я имею право указать лишь первый аргумент? Как это ограничение помогает для поинт-фри (скорее пойнтлес) программирования?

Вот тип фолда в хаскелле: (a -> b -> b) -> b -> [a] -> b. Вот тип фолда в Немерле: list[A] * B * (A * B -> B) -> B. Это наверное вопрос вкуса, но для меня последний понятней: не приходится в голове расставлять скобки в соответствии с правой ассоциативностью.

В немерле я могу без ламбды описать комбинатор, который начинает всегда с пяти:

def foldFromFive = _.Fold(5, _);
// или
def fold2FromFive = NList.Fold(_, 5, _);

Как это сделать в Хаскелле, мне до сих пор неизвестно.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Каррирование можно сделать на любом языке с замыканиями. А в Скале кстати можно сразу объявлять функции как каррированные. Это делается с помощью нотации def sum(x)(y) { ... }

Можно. И что из этого следует? Да, ничего!

Здравствуйте, catbert, Вы писали:

C>Частичное применение в стиле Немерле может все то же, что и карринг. При этом оно не превращает типы функций в набор стрелочек.

Это не так. Частичное применение может значительно больше нежели карринг.

Здравствуйте, dsorokin, Вы писали:

D>Наоборот, карринг чертовски полезен в F#.

Ключевое слово здесь "F#". В F# — полезен. Полезен потому что других средств нет. Но в других языках есть другие средства. И эти средства делают карринг ненужным.

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

Кроме того такой подход к частичному применению препятствует использованию перегрузки. В F#, например, это делит свет на два мира. Одни — это "функциональный" мир где функции автоматически кррируются. Второй — это мир дотнета где все функции получают в качестве параметра один кортеж и где вообще нет частичного применения! И это в дотнетном языке!

Не спорю, подход F# имеет право на существование. Но тут нужно задаться вопросом — каковы предпосылки в дизайне языка? Если мы хотим портировать имеющийся ФЯ на враждебную платформу или хотим создать классический ФЯ работающий на враждебной платформе, то подход F# возможно и не плох. Но пользователями этого языка будут только те кто уже плотно подсел на язык с ML-синтаксисом.

Если же создатели языка хотят чтобы на нем было просто работать людям с "С-прошлым", то этот подход не приемлем. Так же этот подход будет ошибкой, если мы хотим создать язык который будет выглядеть родным мирах дотнета или явы (которые не мыслимы без перегрузки).

Собственно это и определяет выбор дизайнеров языков. F# выбрал путь совместимости с догмами ML-ного синтаксиса, а Nemerle с догмами ООП.

Разные цели, разные решения.

Но утверждать, что вот карринг руль, а частичное применение сакс (или наоборот) — это глупо. Вы, тем самым, подменяете свои предпочтения разговорами о какой-то эфемерной правильности. Меж тем правильно и то, и другое. Это не ошибка дизайна, а всего лишь выбор дизайнеров.

Здравствуйте, WolfHound, Вы писали:

D>>Наоборот, карринг чертовски полезен в F#. С помощью него легко строить потоковую обработку. Многие функции специально имеют такой порядок аргументов, чтобы удобнее было пользоваться каррингом. Одна из моих любимых фич F#. Получается очень функционально.
WH>Аналог не немерле:
WH>

WH>    def makeClickable (n: IDiagramNode, w: IObservable[UIElement, option])
WH>    {
WH>        w .Filter(Option.isSome)
WH>          .Map(Option.get)
WH>          .Map(e => e.MouseLeftButtonDown :> IObservable[_])
WH>          .Concat()
WH>          .Subscribe(e => ...)
WH>    }
WH>

WH>Как видишь, получилось даже короче.
WH>Карринг не нужен.

Тут ты тоже не прав. " :> IObservable[_]" — это костыль нужный для доисторического Хиндли-Милнера. Если приведение есть, оно будет использовано автоматически. Так что код будет еще короче .

def makeClickable(n : IDiagramNode, w : IObservable[UIElement, option])
{
  w.Filter(_ is Some)
   .Map(_.Value)
   .Map(_.MouseLeftButtonDown)
   .Concat()
   .Subscribe(e => ...)
}

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

Здравствуйте, dsorokin, Вы писали:

D>Ну, вот. Такой облом. Это нужно не только для монад. Для полиморфных функций тоже.

Да не особо. На то есть перегрузка. Конечно удобно создавать только одну реализацию функции. Но результат получается медленнее по сравнению с использованием перегрузки.

D>Фишка в том, что программисты на Немерле разницы большой не заметят. Просто void будет незаметно подменяться классом FakeVoid. Будет более логически законченная вещь — тип void будет приравнен к остальным типам. А C#-перы пусть мучаются

Ну, как же не заметят? Скорость будет иной. Функции для которых бывает полезна передача void в качестве параметра типов обычно являются библиотечными. А там не грех и лишнюю перегрузку написать. Ну, а если что не сложно и FakeVoid использовать (если ты дорос до уровня понимания ФП когда ты понимаешь что делаешь и это тебе реально нужно). Результат то будет тем же самым.

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

Здравствуйте, catbert, Вы писали:

ВВ>>Каррирование дает удобную форму для поинт-фри и для построения комбинаторов. Собственно, поинт-фри естественным образом проистекает из факта каррированности функций. Да и перегрузке по типу он не особо-то и мешает.
C>Частичное применение в стиле Немерле может все то же, что и карринг.

Формально — да. Это разве отрицалось?

C>При этом оно не превращает типы функций в набор стрелочек.

Зато превращает их в набор "звездочек". В чем проблема-то?

C>Еще до того как я узнал про Немерле, мне казалось, что карринг — какой-то динозавр из 60-х, от которого не избавляются лишь в дань традиции (аналогично называнию локальных функций лямбдами).

Честно говоря, впервые слышу такое мнение. Описание функций через оператор (_) в стиле Немерле/Скалы я узнал раньше знакомства с ML-языками. И чисто формально разницы между ними нет. Однако на практике мне кажется, что построение комбинаторов на основе каррированных функций выглядит выразительнее. Фактически мы просто вытряхаем из кода излишние операторы и "знаки препинания".

C>Если у меня есть каррированная функция Int -> Int -> String -> Double, почему я имею право указать лишь первый аргумент? Как это ограничение помогает для поинт-фри (скорее пойнтлес) программирования?

Обычно функция пишется в расчете на то, что будет фиксировать именно первый аргумент. Ну в конце концов можешь флипнуть ее. Хотя в реальности flip нужен не так уж и часто.

C>Вот тип фолда в хаскелле: (a -> b -> b) -> b -> [a] -> b. Вот тип фолда в Немерле: list[A] * B * (A * B -> B) -> B. Это наверное вопрос вкуса, но для меня последний понятней: не приходится в голове расставлять скобки в соответствии с правой ассоциативностью.

Непонятно, зачем вообще расставлять скобки. Можешь объяснить, зачем ты это делаешь?

C>В немерле я могу без ламбды описать комбинатор, который начинает всегда с пяти:
C>

C>def foldFromFive = _.Fold(5, _);
C>// или
C>def fold2FromFive = NList.Fold(_, 5, _);
C>

C>Как это сделать в Хаскелле, мне до сих пор неизвестно.

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

foldFromFive f = foldl f 5

Лямбд, как видишь, нет. Да, да, поинт-фри тут не получилось, косяк Можно сделать поинт-фри, если предположить, что у нас есть такой флип:

flip3 f x y z = f y x z

foldFromFive = flip3 foldl 5

И заметь, я ничего плохого об операторе (_) не говорил. А лишь поддался на очередную провокацию от Немерлианцев в стиле "ХХХ не нужен".

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, dsorokin, Вы писали:
D>>Наоборот, карринг чертовски полезен в F#.
VD>Ключевое слово здесь "F#". В F# — полезен. Полезен потому что других средств нет. Но в других языках есть другие средства. И эти средства делают карринг ненужным.
VD>Почти любой выбор дизайнеров языка является компромиссом. Мы выигрываем в одном, и проигрываем в другом. Не является исключением и карранг получая возможность красиво строить комбинаторы мы теряем сразу множество возможностей.
VD>Так мы не можем производить частичное применение более чем для одного параметра

Можем:

sum x y z = x+y+z

sum2 = sum 5 2

VD>и не можем применять частичко фунции если их параметры расположены в "неправильном" порядке.

Можем:

flip f x y = f y x

div x y = x / y

flip div 2

Не говоря уж о:

(/2)

(`div` 2)

И, кстати, зачем располагать параметры в "неправильном" порядке?

VD>Кроме того такой подход к частичному применению препятствует использованию перегрузки. В F#, например, это делит свет на два мира. Одни — это "функциональный" мир где функции автоматически кррируются. Второй — это мир дотнета где все функции получают в качестве параметра один кортеж и где вообще нет частичного применения! И это в дотнетном языке!

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

int sum(int x, int y) {
  return x + y;
}

int sum5(int x) {
  return sum(5, x);
}

Это — частичное применение. Аналогично и:

Func<int,int,int> sum = (x,y) => x + y;

Func<int,int> sum = x => sum(5, x);

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

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

VD>Не спорю, подход F# имеет право на существование.

Смешно, ей богу. Сколько лет тут были ML-и, появился Немерле (ну да, Скала в начале), и теперь ML-ный подход "имеет право на существование".

VD>Но утверждать, что вот карринг руль, а частичное применение сакс (или наоборот) — это глупо. Вы, тем самым, подменяете свои предпочтения разговорами о какой-то эфемерной правильности. Меж тем правильно и то, и другое. Это не ошибка дизайна, а всего лишь выбор дизайнеров.

Однако вы именно это и утверждаете. Заметь, все высказывания вашего лагеря сводятся к "ХХХ не нужен, ведь этого нет в Немерле".

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Однако вы именно это и утверждаете. Заметь, все высказывания вашего лагеря сводятся к "ХХХ не нужен, ведь этого нет в Немерле".
Не так. Этого нет в немерле по тому что это не нужно.
И заметь у нас всегда есть четкое обоснование почему та или иная хрень не нужна.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, dsorokin, Вы писали:

D>>Наоборот, карринг чертовски полезен в F#. С помощью него легко строить потоковую обработку. Многие функции специально имеют такой порядок аргументов, чтобы удобнее было пользоваться каррингом. Одна из моих любимых фич F#. Получается очень функционально.
WH>Аналог не немерле:
WH>

WH>    def makeClickable (n: IDiagramNode, w: IObservable[UIElement, option])
WH>    {
WH>        w .Filter(Option.isSome)
WH>          .Map(Option.get)
WH>          .Map(e => e.MouseLeftButtonDown :> IObservable[_])
WH>          .Concat()
WH>          .Subscribe(e => ...)
WH>    }
WH>

WH>Как видишь, получилось даже короче.
WH>Карринг не нужен.

На мой вкус слишком много ООП Впрочем, в scala похожая байда.

Здравствуйте, dsorokin, Вы писали:

D>Здравствуйте, WolfHound, Вы писали:

WH>>Здравствуйте, dsorokin, Вы писали:

D>>>Наоборот, карринг чертовски полезен в F#. С помощью него легко строить потоковую обработку. Многие функции специально имеют такой порядок аргументов, чтобы удобнее было пользоваться каррингом. Одна из моих любимых фич F#. Получается очень функционально.
WH>>Аналог не немерле:
WH>>

WH>>    def makeClickable (n: IDiagramNode, w: IObservable[UIElement, option])
WH>>    {
WH>>        w .Filter(Option.isSome)
WH>>          .Map(Option.get)
WH>>          .Map(e => e.MouseLeftButtonDown :> IObservable[_])
WH>>          .Concat()
WH>>          .Subscribe(e => ...)
WH>>    }
WH>>

WH>>Как видишь, получилось даже короче.
WH>>Карринг не нужен.

D>На мой вкус слишком много ООП Впрочем, в scala похожая байда.

где в этом коде ООП ???

Здравствуйте, Jack128, Вы писали:

D>>На мой вкус слишком много ООП Впрочем, в scala похожая байда.
J>где в этом коде ООП ???

Что такое IDiagramNode, IObservable? Словари функций, прибитые к объектам? Вот это и есть ООП.

Здравствуйте, dsorokin, Вы писали:

D>На мой вкус слишком много ООП Впрочем, в scala похожая байда.
Здесь нет ООП.
Здесь использована мегафича "extension method".
Так что это все статические функции просто их вызов выглядит как вызов методов.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Что такое IDiagramNode, IObservable? Словари функций, прибитые к объектам? Вот это и есть ООП.
А теперь посмотри в код

Автор: dsorokin
Дата: 21.05.11

на F#...

Здравствуйте, WolfHound, Вы писали:

ВВ>>Что такое IDiagramNode, IObservable? Словари функций, прибитые к объектам? Вот это и есть ООП.
WH>А теперь посмотри в код

Автор: dsorokin
Дата: 21.05.11

на F#...

здесь

Автор: Воронков Василий
Дата: 20.05.11

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Можем:

ВВ>

ВВ>sum x y z = x+y+z

ВВ>sum2 = sum 5 2
ВВ>

Ты вот это повтори:

f(_, 1, _, "a", _)

VD>>и не можем применять частичко фунции если их параметры расположены в "неправильном" порядке.

ВВ>Можем:

ВВ>

ВВ>flip f x y = f y x

ВВ>div x y = x / y

ВВ>flip div 2
ВВ>

flip только переворачивает параметры. А что будешь делать если параметров много и все он "неправильно" расположены?

ВВ>И, кстати, зачем располагать параметры в "неправильном" порядке?

Дык в кавычках оно потому, что это ничего неправильного нет. То что что-то не подходит для вашей теории еще не делает это что-то неправильным.

VD>>Кроме того такой подход к частичному применению препятствует использованию перегрузки. В F#, например, это делит свет на два мира. Одни — это "функциональный" мир где функции автоматически кррируются. Второй — это мир дотнета где все функции получают в качестве параметра один кортеж и где вообще нет частичного применения! И это в дотнетном языке!

ВВ>Это глупость. Частичное применение есть во всех языках, где есть функции.

ВВ>

ВВ>int sum(int x, int y) {
ВВ>  return x + y;
ВВ>}

ВВ>int sum5(int x) {
ВВ>  return sum(5, x);
ВВ>}
ВВ>

ВВ>Это — частичное применение. Аналогично и:

Это не частичное применение. Это обявление новой функции. А твои слова действительно глупость.

Если же тебя устраивает такое "частичное применение", то не фига вести разговоры о каких-то высших материях. То что тебя устраивает было в C. А стало быть карринг вообще никому не нужен.


ВВ>

ВВ>Func<int,int,int> sum = (x,y) => x + y;

ВВ>Func<int,int> sum = x => sum(5, x);
ВВ>

ВВ>Оператор _ вообще ортогонален частичному применению — так же, как и лямбды. Он представляет собой всего лишь сокращенную запись для лямбды и, конечно же, так же, как и лямбды, может использоваться для частичного применения.

Супер! Рекурсивное отрицание! Такого я еще не видел. Ну, это ладно...

Ну давай действовать также как ты. Карринг ортогонален частичному применению. Он представляет собой всего лишь сокращенную запись для лямбд.

Func<int,int> sum = x => y => sum(x, y);

Ну, чё? Как будель со своей же демагогией бороться?

ВВ>Каррирование так же ортогонально частичному применению.

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

Я повторяю последний раз. Карринг является разновидностью частичного применения. Но не наоборот. Потрудись опровергнуть это утверждение, или согласись с ним и перестань постоянно повторять ту ересь что ты несешь с завидной регулярность. Достал уже.

ВВ>Сколько лет тут были ML-и, появился Немерле (ну да, Скала в начале), и теперь ML-ный подход "имеет право на существование".

Дык если ML удовлетворял бы людей, то Скала и Немерл не появились бы вовсе. А они вот появились и как не странно набирают все больше и больше сторонников. А вот ML которому в этом году 40 лет исполняется (если не ошибаюсь) даже с протекцией МС не может завоевать предпочтение программистов.

В общем, я не хочу спорить на негативные темы. Я уже говорил, что подход ML имеет право на существование. Но это дизайнерский выбор, а не единственный true way. Со своими преимуществами и недостатками. Жить без него можно не испытывая никаких проблем. Те же задачи решаются другими способами. Зато отказ от этого решения дает главный бенефит — возможность не ломать привычки тем кто использовал скобочную нотацию для описания и применения функций с четвертого класса школы.

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

VD>>Но утверждать, что вот карринг руль, а частичное применение сакс (или наоборот) — это глупо. Вы, тем самым, подменяете свои предпочтения разговорами о какой-то эфемерной правильности. Меж тем правильно и то, и другое. Это не ошибка дизайна, а всего лишь выбор дизайнеров.

ВВ>Однако вы именно это и утверждаете. Заметь, все высказывания вашего лагеря сводятся к "ХХХ не нужен, ведь этого нет в Немерле".

Что? Можно процитировать где я утверждал что-то подобное? Не говоря уже об "этом".

Здравствуйте, Воронков Василий, Вы писали:

C>>При этом оно не превращает типы функций в набор стрелочек.

ВВ>Зато превращает их в набор "звездочек". В чем проблема-то?

Потере информации и понятности. Звездочки сразу дают понять где у нас параметры функции, а где мы функцию в качестве параметра передаем. Стрелочки же делают код обфускированным.

Здравствуйте, Воронков Василий, Вы писали:

C>>Если у меня есть каррированная функция Int -> Int -> String -> Double, почему я имею право указать лишь первый аргумент? Как это ограничение помогает для поинт-фри (скорее пойнтлес) программирования?

ВВ>Обычно функция пишется в расчете на то, что будет фиксировать именно первый аргумент. Ну в конце концов можешь флипнуть ее. Хотя в реальности flip нужен не так уж и часто.

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

Потом фипни как нам фунции из linq-а! Зачем для них обертки то пишутся?

ВВ>Непонятно, зачем вообще расставлять скобки. Можешь объяснить, зачем ты это делаешь?

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

ВВ>И заметь, я ничего плохого об операторе (_) не говорил. А лишь поддался на очередную провокацию от Немерлианцев в стиле "ХХХ не нужен".

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

Меж тем преимущества можно перечислить куда проще, так как оно одно — краткость формирования кобинаторов. Ну, да оно есть, только вот на практике те кто пишет на Немерле редко пользуются комбинированием функций. Им проще локальную функцию описать. Зато не страдают другие аспкты. Функции с перегрузкой для Немерла родные. Синтаксис частичного применения мощнее...

Здравствуйте, dsorokin, Вы писали:

WH>>Аналог не немерле:
WH>>

WH>>    def makeClickable (n: IDiagramNode, w: IObservable[UIElement, option])
WH>>    {
WH>>        w .Filter(Option.isSome)
WH>>          .Map(Option.get)
WH>>          .Map(e => e.MouseLeftButtonDown :> IObservable[_])
WH>>          .Concat()
WH>>          .Subscribe(e => ...)
WH>>    }
WH>>

WH>>Как видишь, получилось даже короче.
WH>>Карринг не нужен.

D>На мой вкус слишком много ООП Впрочем, в scala похожая байда.

1. С каких пор ООП стал плох? Если он дает результат лучше чем ФП, то не фига совать ФП куда попало. А ООП тут не причем.
2. Тут может не быть ни грамма ООП. Все эти вызовы могут быть методами расширениями которые по факту прост статическая функция.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Что такое IDiagramNode, IObservable? Словари функций, прибитые к объектам? Вот это и есть ООП.

Обрати внимание на функцию IObsvervable.concat: IObservable<IObservable<'a>> -> IObservable<'a>. Фактически это — монадический join. Все не так просто!