Здравствуйте, Mirrorer, Вы писали: LCR>>Например, верни мне указатель на LCR>>1. функцию Medved(_, 22, _) получающуюся после частичного применения числа 22 к среднему аргументу функции Medved(x, y, z). M>Мммммм.. Тут какой интресный вопрос возникает.. Считать ли partial application необходимым условием для ФВП?
А что тогда ВП?
Вроде как это возможность
а) принять функцию как аргумент
б) вернуть функцию как результат
в) уметь возвращать разные функции как результат выполнения.
г) уметь возвращать ранее не существовавшие функции как результат выполнения
Для partial application требуется именно г). Если его нету, то какие-то у нас ФВП получаются убогие: не позволяют конструировать функции. В С++ ФВП можно эмулировать при помощи функторов, и то я не вполне уверен, что этого реально достаточно.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Насколько оно валидно —
Если есть ссылки на более авторитетные источники чем Wikipedia — Welcome!
S>Вроде как это возможность S>г) уметь возвращать ранее не существовавшие функции как результат выполнения S>Для partial application требуется именно г). Если его нету, то какие-то у нас ФВП получаются убогие: не позволяют конструировать функции.
Если ФВП = а И б И в И г , то таки да.
А если ФВП = а ИЛИ б ИЛИ в ИЛИ г, то вопрос остается открытым.
Здравствуйте, Mirrorer, Вы писали:
M>А можно тыксзть озвучить разницу понятным языком? А то я что-то до сих пор разницы не прочувствовал
Ну... Как здесь уже говорили в Pascal или в C можно с помощью ссылок на функцию организовать higher-order function, или в C# с помощью делегатов. Но функции первоклассными объектами в этих языках все равно не являются. Или я ошибаюсь?
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Mirrorer, Вы писали:
M>Но это в том случае если принять, что указатель на функцию == функции.
M>Но опять же в таком случае в ассемблере ФВП тоже имеются... в M>общем. Но хотелось бы разобраться.
Реализовать можно всё, особенно если делать допущения. Но... то что можно реализовать — это хорошо, для языка. А "напрямую" оперировать понятиями — это уже другое. С теми же функциями... собственно мы в C можем их только вызывать, и на этом возможности заканчиваются. Речь ведь об этом?
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, Mirrorer, Вы писали:
M>>Но это в том случае если принять, что указатель на функцию == функции.
K>Так в том и дело, что указатель на функцию != функции. K>Собственно, в той же Википедии и об этом написано здесь
А. Вроде разобрался. Просто у меня была путаница между ФВП и First-Class Function.
Итого. Получается что ФВП действительно то, что написано в википедии
In mathematics and computer science, higher-order functions or functionals are functions which do at least one of the following:
* take one or more functions as an input
* output a function
А First-Class Function это
In computer science, a programming language is said to support first-class functions if it treats functions as first-class objects. Specifically, this means that functions can be created during the execution of a program, stored in data structures, passed as arguments to other functions, and returned as the values of other functions.
Причем
The modern, natively compiled programming languages support functions defined statically at compile time. Most of them, e.g. C and Pascal, additionally support function pointers, which can be stored in data structures and passed as arguments to other functions. Nevertheless, they are not considered to support first class functions, since, in general, functions cannot be created dynamically during the execution of a program. The closest analog would be a dynamically compiled function created by a just-in-time compiler, which is compiled as an array of machine language instructions in memory and then cast to a function pointer. However, this technique is specific to the underlying hardware architecture and is, therefore, neither general nor portable.
Здравствуйте, VladGalkin, Вы писали:
VG>Здравствуйте, LaPerouse, Вы писали:
LP>>[...skipped]
VG>А Вы не кащенит ли случаем? А то Ваш ответ практически по "Кащенезису" построен.
По этой ссылке — это что, шутка? Если нет, то это общество моральных уродов. Очень жаль, но у вас сложилось неверное впечатление
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>По этой ссылке — это что, шутка? Если нет, то это общество моральных уродов.
Шутка, затянувшаяся. Хотя, каждый воспринимает кащенитов по своему. Этот конкретный документ — пародия на масонские документы (уставы?).
LP>Очень жаль, но у вас сложилось неверное впечатление
Просто я бы сказал, что Вашим высказываниям в данной теме присущи черезмерный максимализм, псевдо-философия (?) (не поймите меня неправильно), углубленность а также не совсем адекватное понимание термина "функциональное программирование". Их просто сложно читать. Также рекомендую ознакомиться с определением из Википедии, и, для примера, форумом.
LP>Все-таки основным критерием функционального подхода является то, о чем я говорил выше – отношение к хранению состояния. Вот он, постамент, на котором зиждется вся теория и практика функционального программирования, тот самый “пятый элемент”, придающий особый колорит этому стилю. Стоит только разрешить изменение переменных в любом “функциональном языке”
Зачем?
LP>и внешние ссылки на эти переменные (которое не нужно даже специальным образом вводить),
Зачем? И потерять такую важную вещь, как удобство в распараллеливании программ?
LP>и этот язык неуловимо для глаз превратится в стандартный процедурный язык.
Зачем?
LP>Все остальное – синтаксические конструкции, помогающие объявлять вложенные конструкции функций, встроенные в сам язык возможности для обработки списков и т п — все это для дураков, чтобы дать им почувствовать всю “революционность” и крутизну “новейшего” подхода.
Предположим, не революционность, а эволюционность.
За возможность написать map(Fun, List) я бы продал Страуструпа с Виртом в рабство. Обоих
LP>Да! Я утверждаю, что за роскошной вывеской прячется тухлятина, которой уже как минимум 50 лет. И готов это доказать любому, пусть и придется пожертвовать частью личного времени на восполнение пробелов в чужом образовании.
Ну, не 50, а больше. Если я не ошибаюсь, все началось в далеких 1930-х годах, когда Черч и Клин начали разрабатывать лямбда-исчисление. Правда, поняли это только в 1960-х. Хорошая цитата оттуда:
Most programming languages are rooted in the lambda calculus, which provides the basic mechanisms for procedural abstraction and procedure (subprogram) application.
The most prominent counterparts to lambda calculus in programming are functional programming languages, which essentially implement the calculus augmented with some constants and datatypes.
То есть функциональные языки являются наиболее полной реализацией лямбда-исчисления на практике. И прочие языки меееедленно подбираются к этому. Зачем им подбираться к тухлятине? Быть может, не такая уж это и тухлятина?
Здравствуйте, LaPerouse, Вы писали:
LP>Все-таки основным критерием функционального подхода является то, о чем я говорил выше – отношение к хранению состояния.
Ты забыл прставить ИМХО.
LP>Вот он, постамент, на котором зиждется вся теория и практика функционального программирования, тот самый “пятый элемент”, придающий особый колорит этому стилю.
А эти сопливые сантименты как к делу относятся?
LP>Стоит только разрешить изменение переменных в любом “функциональном языке” и внешние ссылки на эти переменные (которое не нужно даже специальным образом вводить), и этот язык неуловимо для глаз превратится в стандартный процедурный язык.
Именно так лисп в виде CL перестал быть "чистым" ФЯ. Но "стандартным" я бы его не назвал
LP>Все остальное – синтаксические конструкции, помогающие объявлять вложенные конструкции функций, встроенные в сам язык возможности для обработки списков и т п — все это для дураков,...
"От такого и слышу!" Это новый метод доказательства?
LP>...чтобы дать им почувствовать всю “революционность” и крутизну “новейшего” подхода.
"Откуда дровишки?" Это я про "новейший" подход? С какого забора ты читал этот маркетологический бред?
LP>Да! Я утверждаю, что за роскошной вывеской прячется тухлятина, которой уже как минимум 50 лет.
Про возраст — прав. Про оценку качества — "сам дурак"
LP>И готов это доказать любому, пусть и придется пожертвовать частью личного времени на восполнение пробелов в чужом образовании.
Что именно из этого крутого замеса полуправды, полулжи, стенаний девственницы и бреда маркетологов ты собираешься доказывать?
Долго думал, встрявать или нет.
Встряну!
LP>Все-таки основным критерием функционального подхода является то, о чем я говорил выше – отношение к хранению состояния. Вот он, постамент, на котором зиждется вся теория и практика функционального программирования, тот самый “пятый элемент”, придающий особый колорит этому стилю. Стоит только разрешить изменение переменных в любом “функциональном языке” и внешние ссылки на эти переменные (которое не нужно даже специальным образом вводить), и этот язык неуловимо для глаз превратится в стандартный процедурный язык.
Стоит в литр воды насыпать щепотку соли, и она станет непригодной для питья.
По делу: неизменяемые состояния — следствие. Основа — чистота функций. Если любая функция при одних и тех же входных параметрах возвращает одно и то же, то это настоящий (чистый) функциональный язык. Это требование — необходимая и достаточная гарантия для большинства техник, составляющих функциональное программирование. А изменяемые состояния, если они нужны, можно при этом эмулировать, скажем в Хаскелле с помощью монады State.
Я не очень хочу флеймить по этому поводу, отсылаю жаждущих подробностей или драк к книжке Филд, Харрисон Функциональное программирование, М., Мир, 1993 г. Там во введении всё написано довольно подробно. У Мошкова версия битая (была, по крайней мере, полгода назад), но где-то в сети была и хорошая (google поможет).
LaPerouse wrote: > C>Функциональное программирование — это совершенно другой стиль. > C>Ортональный ООП и противоположный императивному. > Видите ли, те языки, о которых вы говорите (C++, Pascal) в представлении > многих являются классическими процедурными языками, что нет ничего > недопустимого в усилении этого термина, которое более предпочтительно по > сравнению с введением нового термина – “функциональный язык”.
Это РАЗНЫЕ термины.
> Исходя из > того, что сказано мной выше, едва ли справедливо выделять из процедурных > группу функциональных языков, тут, скорее, нужно говорить о > “функциональном подходе” и о языках, наиболее эффективно поддерживающих > этот подход.
Так я могу сказать, что ВСЕ стили программирования — это процедурный стиль.
На Паскале и чистом С можно писать объектно-ориентировано (см. GTK,
GNOME). Делает ли это язык C ООП-языком? Нет, не делает.
На чистом С можно писать с использованием точного grabage collector'а
(см. внутреннее устройство GCC). Делает ли это язык С языком с GC? Нет,
не делает.
На чистом С я могу писать для многопроцессорных машин. Но это не делает
язык С языком с встроным параллелизмом.
И так далее.
> Все-таки основным критерием функционального подхода является то, о чем я > говорил выше – отношение к хранению состояния.
Да ничего оно не является. Куча функциональных языков имеют неявное
глобальное состояние. Даже в Haskell'е оно есть в виде монад.
Размещу ответ на том же уровне, т к обращаюсь ко всем ответившим на последний вопрос.
На основании ваших ответов можно заключить, что никто из вас не отвергает приближения ФЯ->Проц. язык. Таким образом, загвоздка заключается только в употребляемых терминах. Под функциональным языком вы имеете ввиду процедурный язык с явными ограничениями ввиде запрещений внешних ссылок, изменяемых переменных и т п. Прекрасно. В таком случае и доказывать-то мне ничего не остается — разве что недопустимость использования устаревшей парадигмы.в сегодняшних задачах. Но я хочу говорить не об этом.
Мне часто приходится слышать слова о том, что императивное программирование далека от человеческого мышления, т к якобы предполагает указание явной последовательности действий. Однако это совершенно не соответсвует действительности. Если императивность ограничить с помощью грамотно спроектированного ООП-дизайна (т е по сути применить декларативный подход), можно получить модель, удивительно отражающую реальность, которую она представляет. Давайте рассмотрим конкретный пример. Функциональщики, например, любят говорить возникающих в императивных программах сайд-эффектах. Рассмотрим двух людей и один единственный стул. Каждый из них на нем время от времени сидит. Данная ситуация очень ээфективно представляется с помощью соответсвующих классов (стул, человек) и объектах (два человека, стул). Рассмотрим среду, относительно которой сущществование этих объектов является гобальным (частный случай — эти объекты объявлены глобальными). В один момент один из людей проявляет желание сесть на этот стул. В этот момент другой опрокидывает его. Сайд-эффект? Безусловно (мы предполагаем, что это опрокидывание произошло случайно, непреднамеренно). Тогда, если первый человек не приоверит состояние стула, то грохнется (то соответсвует началу неправильного течения программы.) Но на то и даны глаза человеку, чтобы смотреть, на что садишься. На то и даны программисту исключения, чтобы в нужный момент осуществлять проверки и вызывать exception. Я хочу сказать таким образом, что САЙД-ЭЭФЕКТЫ, ВОЗНИКАЮЩИЕ ПРИ ОБЪЕКТНО-ОРИЕНТИРОВАННОМ ПРОГРАММИРОВАНИИ, ГЛУБОКО ЕСТЕСТВЕННЫ, ОНИ ХАРАКТЕРНЫ ДЛЯ ТОЙ РЕАЛЬНОСТИ, КОТОРУЮ ОПИСЫВАЕТ ОБЪЕКТНАЯ МОДЕЛЬ. Функциональный подход, такой "человечный и естественный", в данном случае совершенно не будет отражать естественного поведения вещей. При моделировании данной ситуации на ФЯ мы не сможем иметь глобальные объекты ввиде стула и людей. Мало того, что при изменении состояния объекта объект как бы пересоздается (что совершенно неестественно), так еще повторение данной ошибки невозможно из-за того, что первый человек уже ОЖИДАЕТ стул, находящийся в перевернутом состоянии.
Мне хотелось бы пна ваши комментарии по этому поводу.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Размещу ответ на том же уровне, т к обращаюсь ко всем ответившим на последний вопрос.
LP> Рассмотрим двух людей и один единственный стул. Каждый из них на нем время от времени сидит. Данная ситуация очень ээфективно представляется с помощью соответсвующих классов (стул, человек) и объектах (два человека, стул). Рассмотрим среду, относительно которой сущществование этих объектов является гобальным (частный случай — эти объекты объявлены глобальными). В один момент один из людей проявляет желание сесть на этот стул. В этот момент другой опрокидывает его. Сайд-эффект? Безусловно (мы предполагаем, что это опрокидывание произошло случайно, непреднамеренно). Тогда, если первый человек не приоверит состояние стула, то грохнется (то соответсвует началу неправильного течения программы.) Но на то и даны глаза человеку, чтобы смотреть, на что садишься. На то и даны программисту исключения, чтобы в нужный момент осуществлять проверки и вызывать exception. Я хочу сказать таким образом, что САЙД-ЭЭФЕКТЫ, ВОЗНИКАЮЩИЕ ПРИ ОБЪЕКТНО-ОРИЕНТИРОВАННОМ ПРОГРАММИРОВАНИИ, ГЛУБОКО ЕСТЕСТВЕННЫ, ОНИ ХАРАКТЕРНЫ ДЛЯ ТОЙ РЕАЛЬНОСТИ, КОТОРУЮ ОПИСЫВАЕТ ОБЪЕКТНАЯ МОДЕЛЬ. Функциональный подход, такой "человечный и естественный", в данном случае совершенно не будет отражать естественного поведения вещей. При моделировании данной ситуации на ФЯ мы не сможем иметь глобальные объекты ввиде стула и людей. Мало того, что при изменении состояния объекта объект как бы пересоздается (что совершенно неестественно), так еще повторение данной ошибки невозможно из-за того, что первый человек уже ОЖИДАЕТ стул, находящийся в перевернутом состоянии.
LP>Мне хотелось бы пна ваши комментарии по этому поводу.
Вы привели какой-то совершенно левый пример, который можно легко решить даже на самом заскорузлом процедурном языке. Вводим функцию сесть над парой структур — человек и стул, вот и все дела.
Функциональное программирование не против состояний, но эти состояния не глобальны, а локальны. В этом главное отличие ФП от ПП и оно совершенно все меняет. Что вам дает state centric подход? То, что вы можете сидеть за клавиатурой и медитировать на тему того, что стул упал? Не хватает соображения работать не с глобальным состоянием, которое меняется рывками в строгой последовательности, а во многих местах помаленьку? Поэтому в рамка функционального подхода ваш вопрос бессмысленен, функционального программиста не интересует лежит стул или нет, его интересует, что с этим стулом будет происходить дальше. Ваша же картина полностью статична, поэтому можно просто объявить переменную человек два раза и опрокинутый стул один раз, этого достаточно.
Q>Ну да, конечно. Поразительный факт состоит только в том, что функциональное программирование начало развиваться только в конце 70-х. Именно тогда появились ML и первый функциональный диалект Lisp — Scheme. Если вы не понимаете фундаментальной разницы между императивным и функциональным подходом к написанию программ, лучше не позорьтесь, промолчите.
Императивное программирование начало развиваться в 30-х годах 20-го века. Только тогда появилась мшина Тьюринга — императивный аналог лямбда-исчисления.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, LaPerouse, Вы писали:
LP>Мне часто приходится слышать слова о том, что императивное программирование далека от человеческого мышления, т к якобы предполагает указание явной последовательности действий.
Да нет, на самом деле обывателю понятнее имератинвый стиль. А вот математики (которые, кстати, благодаря своей способности формализовать что угодно решают задачи, просто фантастические для обывателя) привыкли думать статично и метафизически. Им должен быть ближе функциональный стиль. Но здесь я не побоюсь высказать своё ИМХО: чтобы решать сложные задачи, прораммист должен быть немножко математиком.
LP>Однако это совершенно не соответсвует действительности. Если императивность ограничить с помощью грамотно спроектированного ООП-дизайна (т е по сути применить декларативный подход), можно получить модель, удивительно отражающую реальность, которую она представляет.
Открвываем любой вузвоский учебник по математике или физике и читаем. Что же мы там можем увидеть? А то, что в начале вводятся несколько фундаментальных законов. В принципе, они очень красиво описывают модель реальности. Но из этого на практике не следует ровным счётом ничего. Потому оставшиеся 90% книжки описывают частные приближения. Так же и с программированием. В пределах какой-то модели мы всё можем описать красиво. Но вот когда дело доходит до практики, общие методы отдыхают. Приходится выбирать наиболее рациональное частное решение. И будет оно в рамках имеративного, функционального или ещё какого-либо ещё программирования, должно зависеть исключительно от решаемой задачи, а не от личных предпочтений программиста или от догматики.
Здравствуйте, Sinclair, Вы писали:
S>А что тогда ВП? S>Вроде как это возможность S>а) принять функцию как аргумент S>б) вернуть функцию как результат
...
Не "уметь", а фукнция принимающая или возрващающая другую функцию. Все! Если язык это позволяет, то он поддерживает ФВП. Так что С их однозначно поддерживает.
А вот большинство те кто использует этот термин путают его с трактованием функций как первоклассных значений. Что конечно включает поддержку ФВП, но не ограничивается ею.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Klapaucius, Вы писали:
K>Ну... Как здесь уже говорили в Pascal или в C можно с помощью ссылок на функцию организовать higher-order function, или в C# с помощью делегатов. Но функции первоклассными объектами в этих языках все равно не являются. Или я ошибаюсь?
В C# 2.0 практически функция являектся первокласным объктом. Картину малось портят проблемы с делегатами, но по сути тех же характеристик добиться можно. Хотя конечно в языках исходно поддерживающих ФП все выглядит значительно чище.
От того лично я склоняюсь к определению: ФЯ это язык целенаправленно поддерживающий программирование в функциональном стиле и имеющий широкий спктр встроенны фич упрощающих программирование в этом стиле.
C# балансирует на грани. Он уже имеет довольно важные фукнции, но пока недотягивает до действительно фунциональных языков.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
1.2.0 alpha rev. 655
Но... то что можно реализовать — это хорошо, для языка. А "напрямую" оперировать понятиями — это уже другое. С теми же функциями... собственно мы в C можем их только вызывать, и на этом возможности заканчиваются. Речь ведь об этом? 
