Тут завелся сайт суть которого сравнения разных вещей (например, теплого с мягким).
Там завели тему Nemerle vs. F#:
http://versusit.ru/viewtopic.php?pid=67441

Кто хочет может поражаться за правое дело .

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

VD>Тут завелся сайт суть которого сравнения разных вещей (например, теплого с мягким).
VD>Там завели тему Nemerle vs. F#:
VD>http://versusit.ru/viewtopic.php?pid=67441

VD>Кто хочет может поражаться за правое дело .

Влад, ты лучше скажи, когда добавите параметрический полиморфизм (параметризация генериков) для типа void? В F# это есть Там используется что-то типа FakeVoid, но делается это совершенно прозрачно для программера. Все это нужно для полноценного использования ComputationExpressions.

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

VD>Тут завелся сайт суть которого сравнения разных вещей (например, теплого с мягким).
VD>Там завели тему Nemerle vs. F#:
VD>http://versusit.ru/viewtopic.php?pid=67441
VD>Кто хочет может поражаться за правое дело .

Первое же сообщение темы достаточно бредовое. F# никакой не "чистый функциональный", а такой же гибридный, как и Немерле. Да и вообще они весьма похожи, ибо оба сильно завязаны на дотнетную систему типов. Обо что там в F# можно "разломать мозг"? Меня вообще поражает интертность некоторых товарищей. ML-ный синтаксис в действительности *проще*, чем Си-подобный. Он правда проще Чтобы в нем разобраться, нужен час. И из-за этого люди "ломают мозг"?

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

ВВ> Обо что там в F# можно "разломать мозг"?

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

ВВ> Меня вообще поражает интертность некоторых товарищей. ML-ный синтаксис в действительности *проще*, чем Си-подобный. Он правда проще Чтобы в нем разобраться, нужен час. И из-за этого люди "ломают мозг"?

Большинство людей не мыслит в таких терминах. Для них все сводится к привычно/не привычно. Собственно, большинство людей не мыслит вообще — разум им заменяет дрессировка, и потому вопрос привычности имеет первостепенное значение.

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

ВВ>> Обо что там в F# можно "разломать мозг"?
А> Людям без математической подготовки карринг лучше не показывать, заболеют.

Я как-то слабо вижу здесь связь с математической подготовкой

ВВ>> Меня вообще поражает интертность некоторых товарищей. ML-ный синтаксис в действительности *проще*, чем Си-подобный. Он правда проще Чтобы в нем разобраться, нужен час. И из-за этого люди "ломают мозг"?
А> Большинство людей не мыслит в таких терминах. Для них все сводится к привычно/не привычно. Собственно, большинство людей не мыслит вообще — разум им заменяет дрессировка, и потому вопрос привычности имеет первостепенное значение.

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

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

D>Влад, ты лучше скажи, когда добавите параметрический полиморфизм (параметризация генериков) для типа void?

В смысле чтобы можно было void в качестве параметра типов передавать? Скорее всего никогда (если, конечно, это в дотнете не реализует). Дотнет этого не позволяет, а делать фэйк только себе вредить.

D>В F# это есть

В нем много чего есть. От того его и не могут использовать большая часть дотнетчиков. Одна из исходных предпосылок в дизайне Nemerle — это чтобы Nemerle был родным в дотнете. И так хватает того, что в Nemerle есть вариантные типы и type котрых нет в дотнете. Усугоблять не стоит.

D>Там используется что-то типа FakeVoid, но делается это совершенно прозрачно для программера. Все это нужно для полноценного использования ComputationExpressions.

Использование подобной хрени нужно в очень редких случаях. Я его видел исплючительно в коде работающем с монадами. И наружу он не выставляется (вроде бы). Вот и пускай там сидит. Разве что можно его в стандартную библиотеку перенести (если он еще не там). А в язык интегрировать его не стоит.

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

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

VD>>Тут завелся сайт суть которого сравнения разных вещей (например, теплого с мягким).
VD>>Там завели тему Nemerle vs. F#:
VD>>http://versusit.ru/viewtopic.php?pid=67441
VD>>Кто хочет может поражаться за правое дело .

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

Согласен. Но что ты тут то это пишешь? Это имеет смысл в ту тему писать.

ВВ>Обо что там в F# можно "разломать мозг"?

Да один синтаксис чего стоит? Это ты тренировался ML-щину читать пару лет. А остальным это на фиг не упало. Даже вызов без скобок (которых, правда, там не много) уже мозг взрывает. В F# подобной хрени пруд пруди.

ВВ>Меня вообще поражает интертность некоторых товарищей. ML-ный синтаксис в действительности *проще*, чем Си-подобный.

Для челочека проще то, что привычнее. Одно то, что в школе учат "сишному" синтаксису уже делает ML-ный синтаксис сложнее. Можешь хоть лоб разбить, но ничего не изменится.

ВВ>Он правда проще Чтобы в нем разобраться, нужен час. И из-за этого люди "ломают мозг"?

Я до сих пор теряю нить Хаскелевских программ где-то на десяткой строке. А я хоть какой-то опыт имею. Остальные, кто не ставил себе задачи во что бы то ни стало изучить ML-ный синтаксис, просто видят в нем кракозябры. Селяви.

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

VD>Да один синтаксис чего стоит? Это ты тренировался ML-щину читать пару лет.

Практика показывает, что студентам хватает пары занятий. Правда, они хотя бы отборные, экзамены там всякие сдавали. Думать умеют, и все такое.

VD> Даже вызов без скобок (которых, правда, там не много) уже мозг взрывает.

Это же всего лишь математическая нотация. Кто знает лямбда-исчисление, тот поймет, а кто не знает, тому не стоит программировать.

VD>Для челочека проще то, что привычнее.

Для слабенького человека — да. Для умного проще то, что объективно проще (т.е., имеет более консистентную и компактную модель).

VD> Одно то, что в школе учат "сишному" синтаксису уже делает ML-ный синтаксис сложнее.

В школе вообще Паскалю учат до сих пор в большинстве случаев.

VD>Я до сих пор теряю нить Хаскелевских программ где-то на десяткой строке.

Искренне сочувствую.

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

VD>Кто хочет может поражаться за правое дело .

Там надо регистрироваться — фсат!

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

VD>>Да один синтаксис чего стоит? Это ты тренировался ML-щину читать пару лет.

А> Практика показывает, что студентам хватает пары занятий.

Практика показывает, что 85% студентов программистских специальностей не работает по професси. А те что работают или начинают учиться программированию параллельно обучению в вузах, или начинают делать это уже на работчем месте (за счет работодателя).

Это ваша практика ничего не показывает. Студенты и основную программу осваивают очень плохо, а разные изыски вроде ML просто походят мимо. Есть, конечно, отдельные исключения, но на то они и исключения.

Ну, на 99% программистов на сегодня имеет реальный опыт программирования на С-подобных языках или на Паскале-подобных.

А>Правда, они хотя бы отборные, экзамены там всякие сдавали. Думать умеют, и все такое.

Думать, в определенных объемах, умеет как минимум половина программистов. Но привычки есть привычки. После 5 лет программирвоания на C#/Java/C++ языки с синтаксисом ML даются крайне тяжело.

И вы можете говорить что угодно, но это банально противоречит реальной действительности.

Меж тем в МЛ есть не мало полезных фич (паттерн-матчинг, АлгТД). Куда проще встроить их в язык с привычным синтаксисом и не пытаться переломить привычки людей.

Опыт Немерла и Скалы показывает, что сам по себе ML-ый синтаксис на практике ничего не дает. Все те же возможности можно получить и в языках со скобочной нотацией.

VD>> Даже вызов без скобок (которых, правда, там не много) уже мозг взрывает.

А> Это же всего лишь математическая нотация.

Вранье. Я еще помню как хотил в школу. Там использовали скобки.

А>Кто знает лямбда-исчисление, тот поймет, а кто не знает, тому не стоит программировать.

Лямбда-исчисления? Это речь идет о теории Черча? Зачем она всем программистам? Программистам достаточно того что из этой теории проистекает. Например, появление лямбд в C# 3.0. Для использования C# 3.0 совершенно не нужно знать теорию Черча. Достаточно небольшой статьи и нескольких примеров.


VD>>Для челочека проще то, что привычнее.

А> Для слабенького человека — да. Для умного проще то, что объективно проще (т.е., имеет более консистентную и компактную модель).

Ну вы — возомнившие себя суперменами, когда напишите столько полезного кода как орды этих "слабеньких", тогда и обсудим вашу крутость и их слабость. А пока будем отталкиваться от того, что есть куча не самых тупых людей которые просто не привыкли к синтаксису ML-я и не хотят к нему привыкать.

VD>> Одно то, что в школе учат "сишному" синтаксису уже делает ML-ный синтаксис сложнее.

А> В школе вообще Паскалю учат до сих пор в большинстве случаев.

Я про уроки математике в 1-7 классах, а не про диковинные уроки информатики на которых преподают редкостную ересь.
В прочем, "Паскалевский синтаксис" — это тот же сишный синтаксис, так как там используются все те же скобки для вызова функций. Он не имеет координальных отличий. Простые смертные спокойно переобучаются с Паскаля на С и обратно. И в то же время плюются на ML-ый бесскобочный.

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

VD>>Кто хочет может поражаться за правое дело .

IT>Там надо регистрироваться — фсат!

Согласен. Странное ограничения для ресурса который хочет раскрутиться на флэймовых темах.

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

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

VD>Использование подобной хрени нужно в очень редких случаях. Я его видел исплючительно в коде работающем с монадами. И наружу он не выставляется (вроде бы). Вот и пускай там сидит. Разве что можно его в стандартную библиотеку перенести (если он еще не там). А в язык интегрировать его не стоит.

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

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

VD>Меж тем в МЛ есть не мало полезных фич (паттерн-матчинг, АлгТД). Куда проще встроить их в язык с привычным синтаксисом и не пытаться переломить привычки людей.

Самая полезная фича ML — карринг. А для нее лучше все же безскобочный синтаксис.

Да и ну их всех на фиг, людей, зависимых от привычек. От негибких умов пользы мало.

VD>Опыт Немерла и Скалы показывает, что сам по себе ML-ый синтаксис на практике ничего не дает. Все те же возможности можно получить и в языках со скобочной нотацией.

Карринг!

VD>Вранье. Я еще помню как хотил в школу. Там использовали скобки.

А что, в школе математику учат? Экая новость!

VD>Лямбда-исчисления? Это речь идет о теории Черча? Зачем она всем программистам? Программистам достаточно того что из этой теории проистекает. Например, появление лямбд в C# 3.0. Для использования C# 3.0 совершенно не нужно знать теорию Черча. Достаточно небольшой статьи и нескольких примеров.

Для программирования вообще надо знать значительную часть дискретки. В том числе и самые основы — лямбда-исчисление, комбинаторную логику, Марковские алгорифмы, машину Тьюринга, и т.п.

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

Здравствуйте, <Аноним>, Вы писали:

А> Самая полезная фича ML — карринг. А для нее лучше все же безскобочный синтаксис.
Карринг не нужен.
По сравнению с немерловым подходом он ничего не дает и при этом мешает перегрузке.
Что сразу приводит к невозможности использовать библиотеки .НЕТ.
Ну и нафига козе баян?

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

А> Самая полезная фича ML — карринг.

Это полная чушь. Карринг не более чем одна из возможных реализаций идеи частичного применения функций. Тот факт, что в том же немеле (и похоже в Скале) есть частичное применение функций, но нет карринага уже опровергает твое утверждение.

Далее обсуждать просто не чего.

А> Да и ну их всех на фиг, людей, зависимых от привычек. От негибких умов пользы мало.

Мы поступим проще. Пошлем на фиг тех кого меньше и кто безапелляционно несет полную чушь.

А> А что, в школе математику учат? Экая новость!

А ты в нее не ходил? Или забыл, что ли? Я тебе напомню. В первом классе проходят арифметику. Где-то класса с 4-го функции и т.п. Вот там скобки и вылезают. А привычка с 4-го класса — это очень сильная привычка. Для многих не преодолимая.

А> Для программирования вообще надо знать значительную часть дискретки.

Гы-гы. Расскажи это тем кто пишет сайты и автоматизирует учет на предприятиях. А из где-то 90% у нас в стране.

А>В том числе и самые основы — лямбда-исчисление, комбинаторную логику, Марковские алгорифмы, машину Тьюринга, и т.п.
А> Я не могу себе представить, как можно браться за программирование без этих базовых знаний.

А что тут представлять то? Даже те кто это когда-то знал (а большая часть тупо проспали это в универах) забывает всю эту заумную муру где-то через 5-10 лет работы в областях где она не нужна. А таких областей большинство.

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

А> Большинство людей не мыслит в таких терминах. Для них все сводится к привычно/не привычно. Собственно, большинство людей не мыслит вообще — разум им заменяет дрессировка, и потому вопрос привычности имеет первостепенное значение.
дрессированные немерлисты?

все люди разные [в контексте программирования]. В чём-то у вас лучше, в чём-то у другого, при одном уровне. кто-то известный сказал — "почему же вы так бедны, раз вы так умны". ничего личного, но определённый уровень типа хаскеля требует "определённый" склада ума.
как не все люди рождаются программистам, так и не все хаскелистами и тут нет зависимости от "привычно/не привычно". это конечно обучаемый навык но не всем так просто, как наверное Вам.

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

А>> Самая полезная фича ML — карринг.
VD>Это полная чушь. Карринг не более чем одна из возможных реализаций идеи частичного применения функций. Тот факт, что в том же немеле (и похоже в Скале) есть частичное применение функций, но нет карринага уже опровергает твое утверждение.

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

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

А>> Самая полезная фича ML — карринг. А для нее лучше все же безскобочный синтаксис.
WH>Карринг не нужен.
WH>По сравнению с немерловым подходом он ничего не дает и при этом мешает перегрузке.
WH>Что сразу приводит к невозможности использовать библиотеки .НЕТ.
WH>Ну и нафига козе баян?

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

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

WH>Здравствуйте, <Аноним>, Вы писали:

А>> Самая полезная фича ML — карринг. А для нее лучше все же безскобочный синтаксис.
WH>Карринг не нужен.
WH>По сравнению с немерловым подходом он ничего не дает и при этом мешает перегрузке.
WH>Что сразу приводит к невозможности использовать библиотеки .НЕТ.
WH>Ну и нафига козе баян?

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

    let makeClickable (n: IDiagramNode) (w: IObservable<UIElement option>) =

        w |> Observable.filter Option.isSome 
          |> Observable.map Option.get
          |> Observable.map (fun e -> e.MouseLeftButtonDown :> IObservable<_>)
          |> Observable.concat
          |> Observable.subscribe (fun e -> ...)

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

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

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

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

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

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

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

Еще до того как я узнал про Немерле, мне казалось, что карринг — какой-то динозавр из 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. Все не так просто!

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

WH>Здесь нет ООП.
WH>Здесь использована мегафича "extension method".
WH>Так что это все статические функции просто их вызов выглядит как вызов методов.

Тогда просто расширение ООП.

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

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

Старею, наверное. Есть какое-то разочарование в ООП после долгого, очень долгого использования

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

D>Тогда просто расширение ООП.
Какое ООП? Какое расширение?
Этот код идентичен твоему с точностью до синтаксиса.

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

WH>Этот код идентичен твоему с точностью до синтаксиса.

Да не идентичен он. Похож, но не идентичен.

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

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

WH>>Этот код идентичен твоему с точностью до синтаксиса.

D>Да не идентичен он. Похож, но не идентичен.

и в чем отличия???

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

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

ВВ>>Можем:

ВВ>>

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

ВВ>>sum2 = sum 5 2
ВВ>>

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

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

Не касаясь вопроса, что же это за реальный сценарий такой, я написал бы это так:

f2 x y z = f x 1 y "a" z

И да, хотя в твоей голове это почему-то не укладывается, это тоже было бы частичным применением.

ВВ>>

ВВ>>flip f x y = f y x
ВВ>>div x y = x / y
ВВ>>flip div 2
ВВ>>

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

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

ВВ>>И, кстати, зачем располагать параметры в "неправильном" порядке?
VD>Дык в кавычках оно потому, что это ничего неправильного нет. То что что-то не подходит для вашей теории еще не делает это что-то неправильным.

В рамках "нашего" языка — делает.

ВВ>>

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

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

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

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

Оператор (_) это просто синтаксис такой для поинт-фри объявления функций. Попробуй подумать и сказать, почему ты считаешь, что следующее:

def f = _+_

это частичное применение. (Где здесь применение-то?) А вот такое:

f = \x y -> x + y

Ни фига не частичное применение.
Подумай действительно, чем эти два примера на самом деле отличаются.

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

Я тебе не говорю, что "меня устраивает". Я тебе пытаюсь объяснить, что такое частичное применение. Ибо блин год назад говорили о том же самом, а воз и ныне там

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

Ты точно все целиком прочитал?

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

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

Формулировка данная тобой — бред. Каррированная функция — это функция вида a->b->c вместо (a*b)->c. И соответственно каррированние — это если хочешь *способ* написания лямбд.
И тебе уже сто раз говорилось, что каррированную функцию можно написать на любом языке, где есть замыкания. То, что ты привел выше — это каррированная функция.

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

Посмотри в словаре, выучишь еще одно "вумное" слово. Впрочем, тебе по ходу необзязательно знать смысл термина, чтобы его употреблять.
"Ортогонально" означает, что прямого отношения не имеет.

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

Я очень надеюсь, что ты "повторяешь" это действительно в последний раз. Потому что это — чушь. Изволь все-таки действительно разобраться в том, что такое каррирование и частичное применение. Я повторяю — каррирование используется в некоторых языках, чтобы в первую очередь имитировать функции с несколькими аргументами.
Вот, почитай: http://blogs.msdn.com/b/vorov/archive/2011/04/19/10155122.aspx

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

У Немерла тоже с этим не очень, правда? Об F# хотя бы говорят. Притом что как язык он не просто вторичен по самое не могу, а во многом даже утратил преимущества своего прямого прародителя. А на OCaml кстати вполне себе пишут.

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

Я тебе уже говорил — я не думаю, что аргумент "мы не будем ломать ваши привычки" хорошо подходит для пропаганды Немерле. Если только вы не хотите собирать армию говно-кодеров. Ибо Немерле в реальности ломает привычки и сильно. Особенно его макро-система. Синтаксис же изучается за час.

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

Вульфхаунд говорил в этой теме.

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

ВВ>>Зато превращает их в набор "звездочек". В чем проблема-то?
VD>Потере информации и понятности. Звездочки сразу дают понять где у нас параметры функции, а где мы функцию в качестве параметра передаем. Стрелочки же делают код обфускированным.

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

немного не в тему. А что означает стрикт в описании языка ела

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

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

В F# принято к случаю каррирования относить то, что я привел в виде куска кода выше. Книга Programming F#. Нет ничего хуже, чем спор о терминах.

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

ВВ>я написал бы это так:

ВВ>

ВВ>f2 x y z = f x 1 y "a" z
ВВ>

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

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

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

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

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

ЗЫ

Закрыли тему.

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

ВВ>>каррирование используется в некоторых языках, чтобы в первую очередь имитировать функции с несколькими аргументами.
D>В F# принято к случаю каррирования относить то, что я привел в виде куска кода выше. Книга Programming F#. Нет ничего хуже, чем спор о терминах.

Не мог бы уточнить, о каком примере речь?

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

А>немного не в тему. А что означает стрикт в описании языка ела

Strict or eager evaluation

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

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

Ты это, занеси ветку в мемориз. Сколько там тебе времени потребовалось, чтобы понять "великие" истины вроде "тайпклассы — это не ООП"? Посмотрим, когда ты наконец соблаговолишь и здесь потратить полчасика на прочтение короткой обзорной статейки.

IT>>Там надо регистрироваться — фсат!

VD>Согласен. Странное ограничения для ресурса который хочет раскрутиться на флэймовых темах.

Сами понимаете — регистрация не прихоть, а средство защиты от спама. Так же доступен OpenID.
P.S. теперь региться не нужно.

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

IT>>>Там надо регистрироваться — фсат!

VD>>Согласен. Странное ограничения для ресурса который хочет раскрутиться на флэймовых темах.

L>Сами понимаете — регистрация не прихоть, а средство защиты от спама. Так же доступен OpenID.
L>P.S. теперь региться не нужно.

э-э-э, а капча не катит?

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

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

IT>>>>Там надо регистрироваться — фсат!

VD>>>Согласен. Странное ограничения для ресурса который хочет раскрутиться на флэймовых темах.

L>>Сами понимаете — регистрация не прихоть, а средство защиты от спама. Так же доступен OpenID.
L>>P.S. теперь региться не нужно.

J>э-э-э, а капча не катит?

Сложную капчу я считаю издевательством над пользователем, а простую роботы обходят элементарно. Надо подумать как использование OpenID максимально упростить... пока очевидно его не замечают...

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

L>Надо подумать как использование OpenID максимально упростить... пока очевидно его не замечают...

совместить вход на ресурс с ответом на сообщение?? Ну типа если человек еще НЕ зашел на ресурс, то рядом с полем ответ добавить поле "OpenID" и когда человек ответил в тему — он автоматом зашел. Ну вобщем как тут, на rsdn сделано.

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

ВВ>Не мог бы уточнить, о каком примере речь?

Мое сообщение выше по треду с Observable. В книге Programming F# другой, но похожий пример.

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

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

В том, что читать звездочки проще чем стрелочки, потому что стрелочки правоассоциативны, а звездочки симметричны по ассоциативности.

ВВ>Честно говоря, впервые слышу такое мнение.

Пол Грэхем — известный лиспер, который часто пишет мудрые вещи про программирование, в том числе и про парадокс Блаба. Вот что он пишет про ламбда-функции в контексте своего языка Arc:

In The Periodic Table, Primo Levi tells a story that happened when he was working in a varnish factory. He was a chemist, and he was fascinated by the fact that the varnish recipe included a raw onion. What could it be for? No one knew; it was just part of the recipe. So he investigated, and eventually discovered that they had started throwing the onion in years ago to test the temperature of the varnish: if it was hot enough, the onion would fry.

We're going to try not to include any onions in Arc. Everything is open to question. For example, in Arc, lambda is called fn. This idea appalled me at first, but it seemed like fn would be shorter and at least as expressive. What if I was just used to lambda? So, with a queasy sense of duty, I decided to try it. And after a few days I actually liked fn better. Now it seems clear to me that lambda is an onion: Alonzo Church himself wouldn't have used it if he had to write out the word lambda each time.

http://www.paulgraham.com/arcll1.html

В языке Arc также нету карринга, а есть немерловые "плейсхолдеры". Мне кажется, причины все те же — карринг лишь традиция, и Грэхему это понятно.

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

Функции в .NET не пишутся в расчете на это. Немерле работает с .NET и это много в чем определяет его дизайн.

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

Чтобы понять тип функции. Функция фолд принимает комбинатор, сид и список, и возвращает аккумулятор. Если читать, как я обычно читаю (слева направо), то выйдет, что фолд принимает комбинатор, и возвращает функцию которая принимает сид и возвращает функцию, которая принимает список, и возвращает аккумулятор.

Это может и правильно в мире хаскелла, но в мире .НЕТа все наоборот. Зачем извращатся? Для самой возможности карринга? Нет, спасибо.

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

Именно так. Но библиотеки Немерла написаны так, что такие примерчики в реальном коде попадаются часто.

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

Лично для меня "карринг не нужен" это не провокация. Я откровенно так думаю.

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

ВВ>Ты это, занеси ветку в мемориз. Сколько там тебе времени потребовалось, чтобы понять "великие" истины вроде "тайпклассы — это не ООП"? Посмотрим, когда ты наконец соблаговолишь и здесь потратить полчасика на прочтение короткой обзорной статейки.

Уважаемый, не переводи стрелки. Я прекрасно понимаю что такое классы типов Хаскеля, и обсуждать это не намерен.

В общем, я предупредил.

И вообще, удивительный ты товаришь. Я дал ссылку на другой сайт, а ты вместо идти туда и спорить с теми кто там что-то написал, пришел сюда.

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

L>Сами понимаете — регистрация не прихоть, а средство защиты от спама. Так же доступен OpenID.
L>P.S. теперь региться не нужно.

У нас регистрироваться не надо, а спама особо нет. Спам появляется там где админы не следят за форумами.

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

ВВ>>Не мог бы уточнить, о каком примере речь?
D>Мое сообщение выше по треду с Observable. В книге Programming F# другой, но похожий пример.

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

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

ВВ>>Зато превращает их в набор "звездочек". В чем проблема-то?
C>В том, что читать звездочки проще чем стрелочки, потому что стрелочки правоассоциативны, а звездочки симметричны по ассоциативности.

Тем не менее на вопрос это не отвечает.

C>Пол Грэхем — известный лиспер, который часто пишет мудрые вещи про программирование, в том числе и про парадокс Блаба. Вот что он пишет про ламбда-функции в контексте своего языка Arc:
C>В языке Arc также нету карринга, а есть немерловые "плейсхолдеры". Мне кажется, причины все те же — карринг лишь традиция, и Грэхему это понятно.

Ну и, собственно, что? В Лиспе функции не каррируются автоматически хотя бы потому что использование каррированных функций в лисповом синтаксисе неудобно. Как и в Сишном, впрочем.

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

А причем тут .NET? Говорили мы вроде с тобой про Хаскелл.

ВВ>>Непонятно, зачем вообще расставлять скобки. Можешь объяснить, зачем ты это делаешь?
C>Чтобы понять тип функции. Функция фолд принимает комбинатор, сид и список, и возвращает аккумулятор. Если читать, как я обычно читаю (слева направо), то выйдет, что фолд принимает комбинатор, и возвращает функцию которая принимает сид и возвращает функцию, которая принимает список, и возвращает аккумулятор.
C>Это может и правильно в мире хаскелла, но в мире .НЕТа все наоборот. Зачем извращатся? Для самой возможности карринга? Нет, спасибо.

Любая функция принимает один аргумент и возвращает другую функцию, пока не происходит сатурация. Скобочки не нужны. Что там в мире НЕТа это другой вопрос. Этот самый мир вообще под ФП не рассчитывался. И "неправильный порядок" в функциях тут лишь малая из проблем.

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

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

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

Ради бога. А я считаю, что он способствует выразительности языка.

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

ВВ>>Ты это, занеси ветку в мемориз. Сколько там тебе времени потребовалось, чтобы понять "великие" истины вроде "тайпклассы — это не ООП"? Посмотрим, когда ты наконец соблаговолишь и здесь потратить полчасика на прочтение короткой обзорной статейки.
VD>Уважаемый, не переводи стрелки. Я прекрасно понимаю что такое классы типов Хаскеля, и обсуждать это не намерен.

У меня нет ни малейшего сомнения, что ты понимаешь, что такое тайпклассы. Долгие человекодни лучших умов РСДН были положены на то, чтобы это понимание у тебя сформировалось. Искренне надеюсь, что ты так же поймешь со временем, чем каррирование отличается от частичного применения.

VD>В общем, я предупредил.
VD>И вообще, удивительный ты товаришь. Я дал ссылку на другой сайт, а ты вместо идти туда и спорить с теми кто там что-то написал, пришел сюда.

А зачем идти, когда можно здесь? Не, ты правда веришь, что создавая на РСДН тему "Мелкий холиварчик Х вс. У", ты потом убедишь людей еще куда-то пойти?

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

ВВ>Искренне надеюсь, что ты так же поймешь со временем, чем каррирование отличается от частичного применения.

Я знаю что одно понятие включает другое. Если ты говоришь о конкретной реализации в немерле, то не боись, я прекрасно понимаю чем оно отличается и какие у него ограничения и проблемы.

VD>>В общем, я предупредил.
VD>>И вообще, удивительный ты товаришь. Я дал ссылку на другой сайт, а ты вместо идти туда и спорить с теми кто там что-то написал, пришел сюда.

ВВ>А зачем идти, когда можно здесь?

А зачем разводить флэймы здесь? Может ты не заметил, но это форум конкретного языка. Языка в котором крринга (в то виде как это хочешь ты) не будет никогда. И ты это прекрасно понимаешь. И понимаешь почему это так.

ВВ>Не, ты правда веришь, что создавая на РСДН тему "Мелкий холиварчик Х вс. У", ты потом убедишь людей еще куда-то пойти?

Тут не во что верить. Я дал ссылку и переложил похоливарить именно там.

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

ВВ>>Искренне надеюсь, что ты так же поймешь со временем, чем каррирование отличается от частичного применения.
VD>Я знаю что одно понятие включает другое.

В том-то и проблема, что не включает
Ты можешь писать на F# код, не используя частичное применения. При этом по-прежнему будешь пользоваться каррированными функциями. Ибо функции с несколькими параметрами там эмулируются либо через кортеж, либо через каррирование. Неужели это так сложно понять?

VD>А зачем разводить флэймы здесь? Может ты не заметил, но это форум конкретного языка.

А чего ты добивался размещая ссылку здесь? Что все пойдут поливать грязью F#, потому что у него "странный" синтаксис?

VD>Языка в котором крринга (в то виде как это хочешь ты) не будет никогда. И ты это прекрасно понимаешь. И понимаешь почему это так.

Я отвечал на "фе" про каррирование вообще, а не про его роль в Немерле. В сишном синтаксисе с каррированными функциями "в лоб" работать в любом случае неудобно. Придумывать сахар типа, что "foo(x,y)" равносильно "foo(x)(y)" в том случае, если foo каррирован — тоже не очень идея. Здесь все понятно, и как бы обсуждать нечего.

Обсуждается, к сожалению, то, что частичное применение — это когда есть "применение" и когда оно блин "частичное". И что "_+_" никак не может быть частичным применением, ибо равнозначно F#-вому "(+)", где так же никакого "каррирования" и частичного применения нет.

ВВ>>Не, ты правда веришь, что создавая на РСДН тему "Мелкий холиварчик Х вс. У", ты потом убедишь людей еще куда-то пойти?
VD>Тут не во что верить. Я дал ссылку и переложил похоливарить именно там.

Извините, я где попало не холиварю.

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

ВВ>А причем тут .NET? Говорили мы вроде с тобой про Хаскелл.

А. Тогда извините. Я просто смотрю: форум Немерле. Думаю, тут про Немерле. Оказалось, про Хаскелл. Бывает.

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

VD>Кто хочет может поражаться за правое дело .

Можно было бы, но уровень компетентности участников оставляет желать лучшего. Полистал разные другие флеймы, например, Python vs Ruby уровень участников просто поражает. Вы лучше пробуйте раскрутиться на более весомых ресурсах, типа reddit, hacker news (там я уже создавал топик), lambda the ultimate, habrahabr, etc. Можно было бы делать набеги на лагерь F#'ников, в тех местах, где они больше всего тусуются и попытаться обратить их в Немерлистов

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

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

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

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

flip foldr 5

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

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

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

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

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

А то и

(`foldr` 5)

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

VD>Тут завелся сайт суть которого сравнения разных вещей (например, теплого с мягким).
VD>Там завели тему Nemerle vs. F#:
VD>http://versusit.ru/viewtopic.php?pid=67441

VD>Кто хочет может поражаться за правое дело .

Гм. Примеры написаны в Python-like indent style. А как поживает поддержка у интеграции Nemerle со студией при использовании indent-style сейчас ? Меня в свое время отвратило от перехода с Питона на Немерле именно кривая поддержка этого режима.

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

А>Гм. Примеры написаны в Python-like indent style. А как поживает поддержка у интеграции Nemerle со студией при использовании indent-style сейчас ? Меня в свое время отвратило от перехода с Питона на Немерле именно кривая поддержка этого режима.

Никак. Нет поддержки. Емнип, Влад утверждает, что с питоновским стилем есть проблемы выявления регионов которые надо перепарсить. И опровергнуть его пока никому не удалось.

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

VD>Кто хочет может поражаться за правое дело .

А зачем в первом примере с match'ингом в случае F# применять active pattern? Чтобы более громоздко выглядел?
Там же достаточно обычного матчинга.

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

Д>А зачем в первом примере с match'ингом в случае F# применять active pattern? Чтобы более громоздко выглядел?
Д>Там же достаточно обычного матчинга.

Почему этот вопрос здается здесь, а не там? Там во много код бредовый. Зачем, вот скажем, вместо $"..." использовать Nemerle.IO.sprintf("...")? Но я же не задаю этот вопрос здесь?

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

VD>Почему этот вопрос здается здесь, а не там? Там во много код бредовый. Зачем, вот скажем, вместо $"..." использовать Nemerle.IO.sprintf("...")? Но я же не задаю этот вопрос здесь?

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

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

___> Можно было бы делать набеги на лагерь F#'ников, в тех местах, где они больше всего тусуются и попытаться обратить их в Немерлистов

Там страшный Jon Harrop, он кого угодно затроллит.

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

___>> Можно было бы делать набеги на лагерь F#'ников, в тех местах, где они больше всего тусуются и попытаться обратить их в Немерлистов

А> Там страшный Jon Harrop, он кого угодно затроллит.

Немерлистов там тупо перебанят да и всё.

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

Д>Ну во-первых, я думал, что тамошнее сообщение от кого-то из здешних, а во-вторых, лень региться было там, чтобы оставить сообщение..

Здешние это уже давно прошли и поняли, что это не очень конструктивное занятие. А на счет "региться" — согласен. Борьба со спамом у них убивает желание людей что-то написать.

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

WH>>>Этот код идентичен твоему с точностью до синтаксиса.
D>>Да не идентичен он. Похож, но не идентичен.
J>и в чем отличия???

Нет карринга!

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

Z>Никак. Нет поддержки. Емнип, Влад утверждает, что с питоновским стилем есть проблемы выявления регионов которые надо перепарсить. И опровергнуть его пока никому не удалось.

С indent-style главная проблема заключается в том, что тем кому он интересен не интересно его реализовывать. Найдутся те кто согласится потратить свое время на его поддержку, будет работать.