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

"Цель этой статьи максимально просто объяснить императивному программисту основы функционального программирования (далее ФП)."

"Я понимаю, что это очень непривычно и непонятно (на первый взгляд), но поверьте, что есть целая теория обосновывающая это (теория «лямбда-исчислений» Чёрча)."

"Разворот списка очень часто используется в ФЯ, но это, скорее, вызвано не тем, что такая операция действительно так уж часто встречается в работе, а тем, что для представления последовательности в ФЯ обычно применяют однонаправленный связанный список (см. выше и ниже)."

"Приводить их реализации я не буду, так как они нетривиальны (уйдет много времени на их reverse engineering), да и занимают довольно много место. Для нас важен сам факт понимания их работы."

"Кстати, используя расширение синтаксиса, в конце запроса обязательно нужно писать ключевое слово select. Как говорилось в одном анекдоте – «Объясныт это нэлза! Это можьно толко запомныт!!!»."

{-# LANGUAGE PostfixOperators, NewQualifiedOperators #-}

import Prelude hiding ((++), init, (<=))
import qualified Prelude as P

import Data.IORef (IORef, newIORef, readIORef, writeIORef)
import Control.Monad (when)
import qualified Text.Printf as Pf (printf)

printf s r = readIORef r >>= Pf.printf s

newInt = newIORef 0

infixr 1 =:
(=:) = writeIORef

rx <= y = do
    x <- readIORef rx
    return (P.(<=) x y)

(++) :: IORef Int -> IO ()
(++) = \r -> do
    i <- readIORef r
    r =: i + 1
    
for (init, cond, post) act = do
        init
        loop
    where
        loop = do
            b <- cond
            when b $ act >> post >> loop

main = do
    i <- newInt
    for (i =: 1, i <= 5, (i++)) $
        printf "%i\n" i

var ary = new int[]{ 1, 2, 3, 4, 5 };

int sum = 0;
Array.ForEach(ary, delegate(int elem) { sum += elem; });

foreach (var elem in ary)
  Console.WriteLine(elem);

Функциональное вычисление – функция (или если быть точнее – «чистая функция», pure function) – должна принимать некоторые аргументы (входящие данные) на входе, производить вычисление и возвращать некоторый результат. При этом функция не должна создавать никаких побочных эффектов. Под побочными эффектами понимается:

> import qualified Data.Map as M

> type Node = Int

> data Element = Element { isLinear :: Bool, leftNode :: Node, rightNode :: Node }

> type Scheme = M.Map Node [Element]

> otherNode :: Element -> Node -> Node
> otherNode (Element _ l r) n
>     | l == n    = r
>     | otherwise = l

> mergeElement :: Element -> Element -> Node -> Element
> mergeElement e1 e2 n = Element True (otherNode e1 n) (otherNode e2 n)

> removeNode :: Node -> Scheme -> Scheme
> removeNode = M.delete

> attachElement :: Element -> (Node, Node) -> Scheme -> Scheme
> attachElement el (ln, rn) = go ln . go rn
>     where
>         go = M.adjust (el:)

> isEntrantPoint :: Node -> Scheme -> Bool
> isEntrantPoint _ _ = False

> transformWithNode :: Node -> Scheme -> Scheme
> transformWithNode node s
>     | length els /= 2 || isEntrantPoint node s = s
>     | isLinear el1 && isLinear el2 =
>         let el@(Element _ ln rn) = mergeElement el1 el2 node
>          in attachElement el (ln, rn) s
>     where
>         els@(~[el1, el2]) = s M.! node

> transform :: Scheme -> Scheme
> transform s = foldr transformWithNode s nodes
>     where
>         nodes = M.keys s

S>>Да! Если это серьёзная статья, постарайтесь обойтись без ехидства и левых наездов на быдлопрограммистов или на разработчиков типа "никто не знает почему". Научитесь уважать чужую работу. Особенно смешно выглядит, если читаешь блоги самих товарищей, где они подробно описывают дизайн языка и говорят что да, решение было не лучшим, но оно было оптимальным на тот момент. Вы ж не жёлтая пресса, чтобы стонать "ооо, как они неправы"

Зачем их было называть методами, и почему им сделали столь неуклюжий синтаксис, остается загадкой.
...
Откровенно говоря, лямбда-выражения – это просто доведенные до ума анонимные методы.
...
очень часто можно было услышать, как анонимные методы называют «анонимными делегатами», хотя это в корне неверно

При этом в Microsoft не придумали ровным счетом ничего нового. Примерно так выглядят лямбды почти во всех ФЯ. Так что совершенно непонятно, зачем было лепить в C# 2.0 этот безобразный, длинный и сбивающий с толку синтаксис. Понятно, что вывод типов был сделан только в C# 3.0, но, по крайней мере, все остальное-то точно можно было бы сделать сразу как в лямбда-выражениях!

Однако при проектировании .NET-делегатов был сделан ряд ошибок, которые сказались при развитии C# в сторону ФП.
...
Данное решение не создает особых проблем на практике, за исключением того, что вызов делегата медленнее, чем мог бы быть.

For those performance oriented among you, please note that if you have a MulticastDelegate that hasn’t been combined with any other delegates the CLR can optimizes for this case during dispatch and in how the JIT compiles the callsite….

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

In the .NET Framework, callback functions are just as useful and as pervasive as they are in unmanaged programming for Windows®. However, the .NET Framework has the added bonus of providing a type-safe mechanism called delegates.

Именно так обычно пишет код 90% императивных программистов. Причем чем больше нужно выполнить действий над элементами списка, тем больше и сложнее становится тело цикла (а так же его пролог и эпилог). Не мудрено, что в большинстве случаев такой код превращается в кашу.

Причём к остальной части статьи, где описывается собсно linq глазами ФП я придраться могу только совсем по мелочам. Оставили бы только её — вообщзе конфетка была бы. Продолжайте

string Function(int x, string y);

Можно описать как:

int * string -> string

или как:

int -> string -> string

По ходу чтения сильно напрягает стиль изложения "от первого лица" с наездами на "императивных программистов".

S>Вообще-то — из определения "императивного программиста".
S>Как только программист перестаёт думать императивными конструкциями, он перестает быть императивным программистом.

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

var bars = foos.Select(foo => map[foo.Name]);

return x*x*x*x*x;

temp1 = x;
temp2 = temp1*x;
temp3 = temp2*x;
temp4 = temp3*x;
temp5 = temp4*x;
return temp5;

_camlKjljl__aux_60:
L101:
    cmp    ebx, 1
    jne    L100
    ret
L100:
    add    ebx, -2
    mov    edx, DWORD PTR [ecx+12]
    sar    edx, 1
    dec    eax
    imul    eax, edx
    inc    eax
    jmp    L101

E>>let rec power5 x =
E>>    let rec aux acc n = if n=0 then acc else aux (acc * x) (n - 1) in aux 1 5;;
E>>

if n=0 then acc ...

if(n=0) return acc; ...

aux (acc * x) (n - 1)

acc * (aux x (n-1))

int sum( int[] a ) {
  int r = 0;
  for( int i = 0; i != a.length; ++i )
    r += a[ i ];
  return r;
}

new StringBuilder.Append("A").Append("B");

new int[] {1,2,3}.Where(i=>i>2).Select(i=>"#" + i.ToString());

from i in new int[] {1,2,3} where i>2 select "#" + i.ToString());

qPressed = do
    mb <- getUserInput
    return (mb == Just 'q') -- представим, что getUserInput неблокирующее чтение, для этого Maybe Char

main = loop
  where
    loop = do
      quitCond <- qPressed
      unless quitCond loop

netQuit = do
  mb <- readFromNet
  return (mb == CmdQuit)

main = loop
  where
    loop = do
      q1 <- qPressed
      unless q1 $ do
         q2 <- netQuit
         unless q2 loop

-- если первая акция не прошла, применяем вторую.
orM act1 act2 = do
  b <- act1
  unless b q2

main = loop
  where
    loop = do
      q <- qPressed `orM` netQuit
      unless q loop

q <- qPressed `orM` netQuit `orM` someQuitCond

q <- foldr orM [qPressed, netQuit, someQuitCond, ...]

Q>Я не об этом. Я о том, что человек начинает въезжать в ФП, и объяснить через C++ проще, чем через Карри, Чёрча и Россера 

struct Foo
{
\\...
std::string name;
\\...
}

struct Bar
{
\\...
long val;
\\...
}

std::map<std::string,Bar> barMap;

Foo s;
\\...
s.name = "blabla";
\\..
Bar b = barMap[s.name];

let bars = map ((\ arr (_,name,_) -> arr!name ) arr) foos
in 
-- ...

int sum( int[] a ) {
  int sum_impl( int[] a, int index, int result ) {
    if( index != a.length )
      return sum_impl( a, i + 1, result + a[ index ] );
    else
      return result;
  }
  return sum_impl( a, 0, 0 );
}

r+=a[i]

int sum( int[] a ) {
    int sum_impl( int[] a, int index ) {
            if( index != a.length )
                return a[ index ] + sum_impl( a, i + 1);
            else
                return a[ index ];
    }
    return sum_impl( a, 0);
}

Отсутствие аналога FoldRight, конечно же, факт неприятный, но особой проблемой это не является, так как, во-первых, FoldRight требуется довольно редко, а во-вторых, его нетрудно написать самостоятельно:

Аналога FoldRight нет, но требуется он довольно редко, и его нетрудно написать самостоятельно:

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

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

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

S>Гм... может у нас просто взаимонедоперенепонимание?

- какого цвета вон тот дом на холме?
— те две стены, которые я вижу отсюда, светло-голубые.

S>ЗЫ. Может уже закончим переуточнять? По-моему, тема исчерпана.