Здравствуйте, lomeo, Вы писали:
L>>>Я что сказать хочу. Чистота функций (отсутствие сайд эффекта), ФВП, рекурсия — это особенности ФП.
VD>>Особености?
L>Э-э-э, да... Что смущает?
1. Неопределнность термина.
2. Как особенностью стиля программирования может выступать использование фич конкретного языка?
Ееще раз повторюсь. Главной отличительной чертой ФП и соотвествнно ФЯ является программирование в выржениях. А уж все остальное от побочных эффетов, до постоянного применения ФВП — это следствия использоания стиля.
L>>>От того, что они есть в ИЯ не делает их не ФП-шными фичами.
VD>>Делает, делае.
L>ФВП — не ФП фича?
Нет конечно. Она же с успехом применяется в императивном коде. Примеры колбэков имзеняющих переменные и т.п. тому свидетельство.
L>Не думаю, что могу согласится с этим. Это же два способа делать одно и то же — состояния в ИЯ и ФВП в ФП.
Какая тут связь? Вот тебе приколнейший код:
using System.Console;
mutable var = 0;
def getCerrentState() { var }
def setCerrentState(newVal) { var = newVal }
def printIt(f) { WriteLine(f()); }
printIt(getCerrentState);
setCerrentState(getCerrentState() + 1);
printIt(getCerrentState);
Он выводит на консоль:
0
1
Он использует замыкания и ФВП. Причем делает это "во все дыры", что называется. Он он императивен по сути, так как использует побочные эффекты. А это явное противоречие если исходить из ваших позиций.
L>Использование ФВП, кстати, вытекает из того, что программа есть выражение, а не набор стейтментов.
Есть огромноая разница между тем, что в программе есть выражения и тем, что вся программа состоит из одних только выражений.
И использованием ФВП ничего само по себе не говорит. Конечно любое варажение в крограмме можно рассматривать как использования функционального стиля программирования. Но насколько разумен такой взгляд?
L>ФЯ — это язык, "облегчающий писать в ФП стиле", а не "позволяющий писать в ФП стиле".
С этим можно согласиться. Я бы даже сказал "имеющий достаточный набор средств для программирования в ФС".
VD>>Скажем так — любой ФЯ (в отличии от ИЯ) имеет синтаксис для создания неизменяемых переменных и обеспечивает возможность программировать вообще не используя изменяемые переменные.
L>На С++ всё это, как ты уже заметил, тоже есть.
А я что спорю? А в С и C# нет. Ну, и что?
L>Ты вот постоянно аппелируешь к логике, но сам ей пользуешься нечасто. Берем твое утверждение о том, что ФП — это когда программа записана в виде выражений. Записываем так на С++. Опа! С++ — ФЯ! Так что ли?
А зачем ты все время смешиваешь понятия ФЯ и ФП. Жонглирование ими и приводит к путаннице.
Исходно я был против утверждения "ленивость и отсуствие побочных эффектов есть отличительные особености ФЯ".
В С++ несомненно есть ФВП, рекурсия и выражения. Этого более чем достаточно для того чтобы писать на С++ в ФС. Но С++ не ФЯ. И единственное что его по большому счету отличает от ОКамла в этом плане — это неудобность программирования в выражениях. Большинство его конструкций являются стэйтментами. Программируя на С++ в ФС ты вунужден будешь ограничиться оперотором ?:, вызовом функций и пожалй что теми самыми ФВП. А этого явно мало для полноценного программирования.
VD>>Читайте Красного дракона Аха. L>Читали
Тогда должне был обратить внимание н раздел посвященный передаче аргументов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Можно ли это считать аналогом typeclasses, или я упускаю какую-то существенно важную вещь ?
В качестве продолжения извращений..
Допустим вот монада
// (a -> m b) public delegate IMonad<B> BindDelegate<A,B>(A a);
public interface IMonad<A>
{
// return :: a -> m a
IMonad<A> ret(A val);
// bind, >>= :: m a -> (a -> m b) -> m b
IMonad<B> bind<B>(IMonad<A> ma,BindDelegate<A,B> binder);
}
А вот это Maybe
public class Maybe<A> : IMonad<A>
{
#region IMonad<A> Members
public IMonad<A> ret(A val)
{
return new Just<A>(val);
}
public IMonad<B> bind<B>(IMonad<A> ma, BindDelegate<A,B> binder)
{
if (ma is Just<A>)
return binder((A)(ma as Just<A>).Val);
return new Nothing<B>();
}
#endregion
}
public class Nothing<A> : Maybe<A>
{
public Nothing()
{
}
}
public class Just<A> : Maybe<A>
{
public readonly object Val;
public Just(A val)
{
Val = val;
}
}
По аналогии с
firstElement :: [a] -> Maybe a
firstElement [] = Nothing
firstElement (x:xs) = Just x
Метод возвращающий Maybe
static Maybe<A> firstElement<A>(List<A> list)
{
if (list.Count == 0)
return new Nothing<A>();
return new Just<A>(list[0]);
}
Здравствуйте, VladD2, Вы писали:
VD>1. Неопределнность термина. VD>2. Как особенностью стиля программирования может выступать использование фич конкретного языка?
VD>Ееще раз повторюсь. Главной отличительной чертой ФП и соотвествнно ФЯ является программирование в выржениях. А уж все остальное от побочных эффетов, до постоянного применения ФВП — это следствия использоания стиля.
Опять спор будет о терминах, что такое следствие, да что такое фича. Не хочу.
L>>ФВП — не ФП фича?
VD>Нет конечно. Она же с успехом применяется в императивном коде. Примеры колбэков имзеняющих переменные и т.п. тому свидетельство.
Ну так выражения тоже с успехом применяются в императивном коде. Тогда что — программирование в выражениях — не ФП?
Хорошо, допустим, что ФП — это когда используются только выражения. Ну так можно сказать и про ФВП. Используй его, не используй императивные фичи, и будет у тебя функциональный код
Твой код (в приведенном примере с состоянием) императивен не потому, что он использует сайд-эффекты, а потому что ты определяешь последовательность действий. Перепиши его только на ФВП, не используй последовательность и у тебя будет функциональный код. То, что программа записана только в выражениях не делает ее функиональной. Декларативной, может быть. Возьми усеченный пролог — где есть только факты и правила. Написанная на нем программа не будет функциональной. Просто потому что там нет функций. Наличие функций (в математическом смысле слова) очень важно для функционального программирования, а работа с ними без ФВП в реальной работе практически невозможна. ФВП — это отличительный инструмент (фича, следствие, подставь нужный термин) ФП. Это симптом, один он, может и не говорит о том, что код функционален, однако вкупе с другими симптомами верно определяет диагноз.
Так что, на мой взгляд, ФВП — это фича ФП.
Остальное вертится вокруг этого, поэтому поскипаю.
Здравствуйте, VladD2, Вы писали:
L>>Влад вот тоже часто путает ФЯ и ФП.
VD>Примеры такой путанницы, плиз, приведи.
Ой, Влад, да это происходит практически постоянно. Вот из последнего только:
Так что разумно говорить, что ФП — это программирование в выражениях которое стимулирует программирование без побочных эффектов. Причем именно ФП, а не ФЯ!
Хотя до этого ты говорил,
Есть одно четкое свойство выделяющее ФЯ — запись программы в виде выражений (expressions), а не statements.
А вот ещё:
L>Это я к твоей фразе о том, что "ФП — это отсутствие побочных эффетов — ахинея". ФП, конечно, это не отсутсвие сайд эффектов, но отсутствие сайд эффектов — отличительная черта ФП.
Конечно же отличительной чертой это не является, так как большая часть ФЯ позволяют менять переменные, и немало ИЯ имеют синтаксис для создания неизменяемых переменных. Если сказать, что это отилчительная черта, то С++ — это ФЯ.
Хотя, как мне показалось, ты понимаешь условность названия ФЯ.
Если же поднять наш тред из ООП vs ФП, то там это происходит постоянно. Просто лень копаться.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
L>Ой, Влад, да это происходит практически постоянно. Вот из последнего только: L>
Так что разумно говорить, что ФП — это программирование в выражениях которое стимулирует программирование без побочных эффектов. Причем именно ФП, а не ФЯ!
L>Хотя до этого ты говорил, L>
Есть одно четкое свойство выделяющее ФЯ — запись программы в виде выражений (expressions), а не statements.
И в чем тут путанница?
L>А вот ещё: L>
L>>Это я к твоей фразе о том, что "ФП — это отсутствие побочных эффетов — ахинея". ФП, конечно, это не отсутсвие сайд эффектов, но отсутствие сайд эффектов — отличительная черта ФП.
L>Конечно же отличительной чертой это не является, так как большая часть ФЯ позволяют менять переменные, и немало ИЯ имеют синтаксис для создания неизменяемых переменных. Если сказать, что это отилчительная черта, то С++ — это ФЯ.
Насколько я помню ты влез по середине разговра в котором говрилось приемущественно о ФЯ. Так что не мудренно, что я еще продолжаю говорить именно о ФЯ.
L>Хотя, как мне показалось, ты понимаешь условность названия ФЯ.
Мне тоже так кажется. Я даже почти уверен.
L>Если же поднять наш тред из ООП vs ФП, то там это происходит постоянно. Просто лень копаться.
А. Ну, ну.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Т.е. вы подтверждаете в общем мою мысль, что ФЯ и приемы описанные в статье только делают удобными некоторые ОБЩЕПРИНЯТЫЕ приемы программирования которые в других языках возможны но используются не так широко.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, minorlogic, Вы писали:
M>>Это моя беглая точка зрения , после первого прочтения. Комментированные минусы за мою ткпость велкам !
VD>По просбам трудящийся поставил минус.
VD>И что немало важно от души.
VD>Аргументирую так. Ты не знаешь о чем говоришь. Поробуй, а потом еще раз выскажись. Уверен, что твое мнение сильно изменится.
Я ожидал ответ на свой пост комментарий по существу , а не бред обиженного ребенка. Но Влад от тебя что еще можно ожидать ?
VD>ЗЫ
VD>Думаю самую плохую услугу ФП оказывают его популяризаторы. Они перегибают палку часто доводя рекламу ФП до уровня рекламы гебалайфа.
VD>В принципе ФП и родившиеся в нем технологии вроде функций высшего порядка (в широком понимании этого слова, т.е. замыкания, лямбды), алгеброические типы и паттерн-матчинг — это весма полезные вещи сильно упрощающие решение многих задач.
VD>Продолжения это вообще мега-фича только вот к ФП в общем-то не относящаяся. В прочем ФП вообще илюзорен. Это набор паттернов кторый можно без проблем применять в ИЯ. Основное достоинство ФЯ заключается в том, что они резко упрощают использование этого стиля.
Именно это я и сказал в предыдущем посте, ты его вообще прочел, или как всегда ... ?
Здравствуйте, minorlogic, Вы писали:
M>Т.е. вы подтверждаете в общем мою мысль, что ФЯ и приемы описанные в статье только делают удобными некоторые ОБЩЕПРИНЯТЫЕ приемы программирования которые в других языках возможны но используются не так широко.
Скорее вообще не используются по незнанию или неудобству.
Кроме того это самое удобство дает куммулятивный эффект, начинаешь не только писать (в смысле кодирования, или конструрования по Макконелу) но и делать декомпозицию и проектирование по другому.
Здравствуйте, VladD2, Вы писали:
VD>Вообще-то строго говоря нет языков недопускающих побочные эффекты. В той или иной форме они обязаны быть в любом зяыке, так как без этго программы не смогли бы общаться с внешим миром.
Нет. С точки зрения чистого ФП — программа это функция y = f(x). Дал ей x, она выдала y.
Вот этот y и есть ее результат для внешнего мира.
VD>По-моему — это все пуританство. Разумно было бы ввести в язык некую аннотацию функций гарантирующую отсуствие в них побочных эффетов.
Что и сделано в C++
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Нет. С точки зрения чистого ФП — программа это функция y = f(x). Дал ей x, она выдала y. АХ>Вот этот y и есть ее результат для внешнего мира.
Такая программа называется сфероконь вакуумный. Ведь даже вшивый калькулятор обязан выводить результаты пользователю. А это тот самый побочный эффект.
VD>>По-моему — это все пуританство. Разумно было бы ввести в язык некую аннотацию функций гарантирующую отсуствие в них побочных эффетов. АХ>Что и сделано в C++
Отнюдь. В С++ вообще ничего не гарантируется по причине наличия указателей и ассемблерных вставок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Нет. С точки зрения чистого ФП — программа это функция y = f(x). Дал ей x, она выдала y. АХ>>Вот этот y и есть ее результат для внешнего мира.
VD>Такая программа называется сфероконь вакуумный. Ведь даже вшивый калькулятор обязан выводить результаты пользователю. А это тот самый побочный эффект.
Ну хорошо, давай калькулятор.
Что такое пользователь? Это на самом деле функция AskUser( results ) которой даешь результаты, а она возвращает то что он ввел.
Вот как он приблизительно работает (императивно)
Results Calculator( )
{
Results results = null;
while( true )
{
Input input = AskUser( results );
if( input == null )
break;
else
results = DoMath( input, results ); // или DoMath(input) если программа не использует предыдущие вычисления
}
return results;
}
Теперь перепишем это же в функциональном стиле на Nemerle
Calculator() : Results
{
def AskFunc(results)
{
( AskUser( results ), results )
}
def Calc(input,results)
{
if(input == null)
results
else
Calc( AskFunc( DoMath( input, results ) ) ) // или DoMath(input) если программа не использует предыдущие вычисления
}
Calc( AskFunc(null) )
}
P.S. При попытке проверить на практике компилятор Nemerle выдал ice . Будем разбираться.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Ну хорошо, давай калькулятор.
АХ>Что такое пользователь? Это на самом деле функция AskUser( results ) которой даешь результаты, а она возвращает то что он ввел.
Любой вывод информации пользователю — это побочный эффект. Точка!
Фунициональное программирование — это аксиморон. Оно невозможно в принципе.
Можно писать 99.9% кода в фукнциональном стиле, но программы не будет если не будет побочных эффектов. Так что вопрос только в их количестве и в том, что они дают.
Отсюда и все внеполовые изврещения вроде монад в Хаскеле. Все это попытка спрятать банальную правду императивности компьютера за розовыми очками математических абстракций.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Что такое пользователь? Это на самом деле функция AskUser( results ) которой даешь результаты, а она возвращает то что он ввел.
Стоп стоп! А эта функция чистая? Пользователь при одинаковых параметрах будет под угрозой удара током что ли вводить одинаковые значения?
VoidEx,
АХ>>Что такое пользователь? Это на самом деле функция AskUser( results ) которой даешь результаты, а она возвращает то что он ввел.
VE>Стоп стоп! А эта функция чистая? Пользователь при одинаковых параметрах будет под угрозой удара током что ли вводить одинаковые значения?
Конечно чистая.
user(Timestamp) -> ...
И вообще, _весь_ ввод-вывод можно представить в виде функции
NewWorld = io_fun(OldWorld).
Единственым препятствием для была трудность практической реализации такого подхода. Однако прогресс на месте не стоит, и создатели Clean сделали это, причём весьма эффективно.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Что такое пользователь? Это на самом деле функция AskUser( results ) которой даешь результаты, а она возвращает то что он ввел.
VE>Стоп стоп! А эта функция чистая? Пользователь при одинаковых параметрах будет под угрозой удара током что ли вводить одинаковые значения?
Хорошо, уточню. Если мы считаем, что пользователь мыслит рационально и его дальнейшие действия основываются только на результатах — то да. Если не только на результатах но и на исходных мыслях, то тогда скажем, заменим results на (results,user_thoughts) и в начале будем передавать не null,
а (null,some_thoughts).
Если же пользователь мыслит нерационально, тогда уже более сложный вопрос.
И тут уже мы упираемся в математические теории детерминированных и недетерминированных функций и философию.
Но вообще говоря со случайными функциями тоже можно работать.
Только результат тоже будет случайной функцией.
Даже такие языки программирования есть (например Java2K ).
А для квантовых языков программирования это вообще естественная ситуация, т.к. кубиты, которыми они манипулируют вообще говоря — случайные величины.
Но с другой стороны, если почитать в Wikipedia про Pure Functional
Purely functional is a term in computing used to describe algorithms, data structures or programming languages that exclude destructive modifications (updates).
In computer science, a function is said to produce a side effect if it modifies some state other than its return value.
Как видишь про детерминированность ничего не говорится.
А как на практике скажем в Haskell, работают с недетерминированными функциями было бы интересно услышать от его знатоков
(я не являюсь таковым к сожалению).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Единственым препятствием для была трудность практической реализации такого подхода. Однако прогресс на месте не стоит, и создатели Clean сделали это, причём весьма эффективно.
Очень интересно, а можно на пальцах или ссылку, где это объясняется просто и на пальцах?
VoidEx,
LCR>>Единственым препятствием для была трудность практической реализации такого подхода. Однако прогресс на месте не стоит, и создатели Clean сделали это, причём весьма эффективно.
VE>Очень интересно, а можно на пальцах или ссылку, где это объясняется просто и на пальцах?
Uniqueness typing.
На пальцах:
Представим, что у нас есть функция
%%% язык типа эрланг, но аннотации типов из хаскеля.
append_char :: (File, Char) -> File.
append_char (File, Char) ->
(use io api...).
main :: File -> (File, File).
main (file) ->
{append_char(file, 'a'), append_char(file, 'b')}.
Если мы будем добавлять в файл символ и возвращать тот же файл, то функция append_char перестаёт быть собственно функцией и результат main зависит от того, левый или правый элемент тупла вычисляется первым. Это можно победить, если возвращать копию файла. Тогда main будет гарантированно всегда возвращать тот же самый результат. Создание новых файлов — это конечно слишком неэффективно и разумеется отметается как вариант. Но что тогда?
К счастью, побочные эффекты допустимы при некоторых ограничениях. Если можно гарантировать, что некий объект не расшарен между функциями, то изменение можно сделать прямо на месте не копируя объект. Было бы неплохо, если бы на этапе компиляции можно было бы определять уникальность аргументов и результатов функций. Но к сожалению, это неразрешимая задача (см. Теорема Райса, проблема останова и т.п.). Поэтому система типов расширяется дополнительным атрибутом UNQ, этот атрибут вставляется программером в нужных местах (где компилятор не может определить уникальность сам), а система типов отвечает за верификацию. Естественно, вывод типов также должен учитывать этот момент.
то система типов отметёт этот код как некорректный. Если же
main :: UNQ File -> (File, File).
то всё нормально.
Как гарантировать порядок вычислений? Нужно просто передать world в качестве параметра, и тип этого world должен быть помечен атрибутом UNQ. Просто и эффективно, не так ли? (хотя куча людей придерживаются мнения, что монады помощнее будут).
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>Единственым препятствием для была трудность практической реализации такого подхода. Однако прогресс на месте не стоит, и создатели Clean сделали это, причём весьма эффективно.
VE>Очень интересно, а можно на пальцах или ссылку, где это объясняется просто и на пальцах?
Вот хорошая статья про монаду IO в Haskell. Собственно идея та же — в функциях, взаимодействующих с внешним миром, добавляется еще один парметр RealWorld, также возвращаемое значение дополняется тем же значением RealWorld. Эти значения нужны только для компилятора,- чтобы обеспечить правильный порядок вызовов и не дать ему соптимизировать вызовы одной функции с одинаковыми парметрами. В статье показано как это можно сделать без всяких монад, монады же просто скрывают от программиста этот механизм и упрощают его использование.
AskUser( results ) которой даешь результаты, а она возвращает то что он ввел.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
