Re[6]: Сильные стороны функционального программирования - Декларативное программирование

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

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

Ну, прям картина апокалипсиса. Вот толко по жизни писать на Шарпе как раз просто, а на ОКамле не очень.

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

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

Это никто не мешает сделать. Итератор по сути это класс с методом Next() и свойством Current. Никто не мешает в Next() генерировать новый элемент последовательности. Новый синтаксис просто избавляет от необходимости писать еще один класс.

G> Ух, какие это жесткие грабли в ИЯ! Брр!

Ты себе эти это специально внушаешь? Может чем тешить себя небылицами просто взять и попробоват пописать на Шарпе?

G>А так — вовсе они не ленивы.

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

S>>Никто мне не мешает и на C# 1.0 написать итератор, который возвращает числа Фибоначчи. Вместе с классом Fibonacci :IEnumerable, который этот итератор возвращает.
G>Ну, в общем случае — да. Никто не мешает так писать, и это в целом хороший стиль.

S>>А также написать алгоритм, который получает на вход IEnumerable и проверяет, больше ли сумма ряда предопределенной константы. yield просто делает код короче.
G>Возможно.

100%. yield — это синтаксический сахар. Энумераторы (IEnumerable) паттерн введенный в язык еще при его рождении.

S>>Конечно, честные функции высшего порядка мы так не получим.
G>

Nemerle. Получите, если захотите взять

Все еще проще. В Шарпе есть делегаты которые позволяют передавать ссылки на функции, так что формально функции высшего порядка в шарпе делаются. В шарпе нет патерн-мотчинга, что не позволяет писать в функциональном стиле на 100%. Но писать в СТЛ-ном стиле можно легко. Вот, например, методы из коллекции R#-а:

        /// <summary>
        /// Позволяет найти элемент.
        /// </summary>
        /// <param name="predicate">
        /// Предикат поиска (делегат возвращающий true если текущий 
        /// элемент удовлетворяет критериям поиска).</param>
        /// <returns>Искомый элемент.</returns>
        public T Find(Predicate<T> predicate)
        {
            for (int i = 0; i < _len; i++)
                if (predicate(_ary[i]))
                    return _ary[i];

            return default(T);
        }

        /// <summary>
        /// Позволяет найти индекс элемента. Перебор начинается с конца списка и 
        /// продолжается до нулевого элмента.
        /// </summary>
        /// <param name="predicate">
        /// Предикат поиска (делегат возвращающий true если текущий 
        /// элемент удовлетворяет критериям поиска).</param>
        /// <returns>Искомый элемент.</returns>
        public int FindLastIndex(Predicate<T> predicate)
        {
            for (int i = _len - 1; i >= 0; i--)
                if (predicate(_ary[i]))
                    return i;
            return -1;
        }

        /// <summary>
        /// Позволяет найти индекс элемента. Перебор начинается с конца списка и 
        /// продолжается до нулевого элмента.
        /// </summary>
        /// <param name="predicate">
        /// Предикат поиска (делегат возвращающий true если текущий 
        /// элемент удовлетворяет критериям поиска).</param>
        /// <returns>Искомый элемент.</returns>
        public int FindIndex(Predicate<T> predicate)
        {
            for (int i = 0; i < _len; i++)
                if (predicate(_ary[i]))
                    return i;

            return -1;
        }
        
        
        /// <summary>
        /// <para>Позволяет выполнить некоторое действие для каждого элемента.
        /// </para>
        /// <para>Перебор осуществляется в прямом порядке.</para>
        /// </summary>
        /// <param name="action">Делегат выполняемый для каждого элемента.</param>
        public void ForEeach(Action<T> action)
        {
            for (int i = 0; i < _len; i++)
                action(_ary[i]);
        }

Вот определения делегатов (они объявлены во фрэймворке):

public delegate void Action<T>(T obj);
public delegate bool Predicate<T>(T obj);

А вот так можно применить данные методы:

SomeCollection<int> list = SomeCollection<int>(new int[]{ 1, 3, 4, 6, 9 });
int sum = 0;
// Жирным выделен анонимный метод, т.е. метод обявляемый инлайном.
// Забавно так же что можно использовать переменную sum объявленную
// в том же методе где вызывается list.ForEeach.
list.ForEeach(delegate(int elem){ sum += elem; });
Console.WriteLine(sum);

// В принципе можно вместо делегата просто передать ссылку на метод
// реализованный где угодно.
Multiplier multiplier = new Multiplier();
list.ForEeach(multiplier.Multiply);
Console.WriteLine(multiplier.Result);

...

class Multiplier
{
    public int Result = 0;
    public void Multiply(int elem)
    {
        Result *= elem;
    }
}

По большому счету не долго создать делегаты и функции вроде head(), tial(), prefix(), ... и реализовать функциональные выверты со списками. Вот только оно нафиг никому не нужно. Так как намного эффективнее и проще реализуется в императивном стиле. А вот когда функцональный становится удобнее, то можно прибегнуть и к нему.