Элементы функционального программирования в Axapta

[Андре]

Попытка эмулировать map(), filter() и reduce() средствами Аксапты:

static void FuncTest(Args _args)
{
    gm_containerCollection      list = new gm_containerCollection([1, 2, 3, 4, 5, 6, 7, 8]);
    ;
    // исходный список
    info(list.toString());    // 1, 2, 3, 4, 5, 6, 7, 8

    // map
    list = list.map('x * x');
    info(list.toString());    // 1, 4, 9, 16, 25, 36, 49, 64

    list = list.map('x + x');
    info(list.toString());    // 2, 8, 18, 32, 50, 72, 98, 128

    // filter
    list = list.filter('x > 10');   // 18, 32, 50, 72, 98, 128
    info(list.toString());

    // можно даже так
    list = list.filter('x > 50').map('x + 1');  // 73, 99, 129
    info(list.toString());

    // reduce
    info(list.reduce('x + y')); // 301

    // одной строкой
    info(new gm_containerCollection([1, 2, 3, 4, 5, 6, 7, 8]).map('x * x').map('x + x').filter('x > 10').filter('x > 50').map('x + 1').reduce('x + y'));
}

static void FuncTest2(Args _args)
{
    gm_containerCollection      list = new gm_containerCollection(['adfsd', 'bsdf', 'cwer']);
    ;
    // исходный список
    info(list.toString());    // adfsd, bsdf, cwer

    // map
    list = list.map('substr(x, 1, 1)');
    info(list.toString());    // a, b, c

    // filter
    list = list.filter('x > "a"');
    info(list.toString());    // b, c

    // reduce
    info(list.reduce('x + y')); // 'bc'

    // одной строкой
    info(new gm_containerCollection(['adfsd', 'bsdf', 'cwer']).map('substr(x, 1, 1)').filter('x > "a"').reduce('x + y'));
}

1. Идея навеяна вот этим постом (ContainerIterator).
2. Рассматривайте данный проект, как развлечение, а не как рекомендацию для промышленного использования.

Ограничения:

1. Ошибки, возникшие при выполнении lambda-функции не контролируются разработчиком. Наверное, этого можно избежать, использую xppCompiler вместо runbuf.
2. Корректность написания lambda-функции никак не проверяется на этапе компиляции. Данного ораничения избежать нельзя никак.

что-то обсудить предлагается или сразу похвалить?

[mazzy]

Цитата:

Сообщение от Андре

Попытка эмулировать map(), filter() и reduce()

А что это такое?

[Андре]

Цитата:

А что это такое?

Функции высших порядков. Искать по ключевым словам - функциональное программирование, list comprehension, lambda-функции.

Если хочется быстро получить представление можно почитать здесь
http://ru.wikipedia.org/wiki/Функцио...�_Питоне

о, эмуляция питона на хапепе!

у человека много свободного времени, однозначно.

[kashperuk]

Это конечно все здорово.
Но я еще когда смотрел код этих классов вчера, все думал, зачем там union, minus.
Вот теперь думаю еще и о map, reduce и filter

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

[Андре]

Про map(), reduce() и filter() - я писал, что это не практическое применение

Цитата:

Но я еще когда смотрел код этих классов вчера, все думал, зачем там union, minus.

А вот union и minus у меня в проекте реально используются:
- Есть функционал работающий c Excel документами
- Пользователь может в документе выбрать набор ячеек и дать им наименование ("именованные ячейки")
- В Аксапте, вместо того, чтобы перечислять все ячейки - он может сослаться на эту именованную область.

У меня есть:
- Функция, которая получает на вход имя диапазона ячеек и возвращает список ячеек (в виде gm_containerCollection.
- Если именованных диапазонов несколько, то с помощью union я могу изящно получить объединение множест ячеек.
- Функция minus бывает полезна, когда пользователь задает именованную область ячеек, которые должны исключаться из обработки, внутри другой именнованной области ячеек, которые должны обрабатываться.

[mazzy]

Цитата:

Сообщение от Андре

Функции высших порядков. Искать по ключевым словам - функциональное программирование, list comprehension, lambda-функции.

Если хочется быстро получить представление можно почитать здесь
http://ru.wikipedia.org/wiki/Функцио...�_Питоне

Если я правильно понимаю, то эти функции работают со списками.

В Аксапте актуальные не списки, а записи в базе.
Поэтому в Аксапте мало функций для работы о списками, но много для работы с базой.
update_recordset вполне заменяет и map, и filter. По-моему.

[mazzy]

Цитата:

Сообщение от Андре

набор ячеек

А этот набор хранится в естественном для Аксапты виде? В таблице?
Если нет, то и инструменты требуются неестественные

[Андре]

Цитата:

Если я правильно понимаю, то эти функции работают со списками.

Да, со списками.

Цитата:

А этот набор хранится в естественном для Аксапты виде? В таблице?

Набор не хранится, и не может храниться. Задаются наименования диапазонов - 'дипазон1', 'диапазон2'. В каждом приходящем документе под этим диапазоном скрывается свой набор ячеек. Что это за набор - решает пользователь, который даже не знает о существовании Аксапты. Он просто знает, что если он хочет, чтобы нужные ему данные были обработаны "центральным суперкомпьютером", то надо открыть свой любимый инструмент (excel) и пометить нужные области в документе определенным образом.
Таким образом список ячеек получается только в момент прихода документа. В тот же момент значения этих ячеек определенным образом обрабатываются. После этого документ уходит из поля зрения Аксапты - хранить этот список далее смысла не имеет.

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

[mazzy]

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

[kashperuk]

Кстати, раз уж мы опять вернулись к теме контейнерной коллекции, приведу немного "полезной критики". Меня очень сильно всегда волнует вопрос производительности
Так вот, несколько предложений (замечаний) по методам класса:

void add(anytype _value)
{
    con += _value;//conpoke(con, conlen(con) + 1, _value);
}

boolean in(anytype _value)
{
    int         i;
    ;
    //for (i=1; i<=conlen(con); i++)
    //{
    //    if (conpeek(con, i) == _value)
    //                            return true;
    //}

    if (conFind(con, _value))
        return true;

    return false;
}

Помимо этого, в класс итератора и энумератора я добавил доп. переменную conLength, в которую записывается длина (при удалении conLength--; надо сделать). Это позволит не пересчитывать длину контейнера на каждой итерации. Конечно, не сильно увеличит производительность, но все же.

[Андре]

Цитата:

думаю, что функции продвинутой работы со списками имеют смысл в языках, где нет доступа к реляционным СУБД

Тебе виднее. К слову, метод union() который мы сейчас обсуждаем присутствует в Аксаптовском классе Set. И выполняет он то, же, что и мой метод, только над set-ом (который, по сути, тоже список), а не над контейнером. Но ведь в Аксапте есть СУБД и необходимости в функциях работы со списками нет, вот так парадокс....

[Андре]

Цитата:

Кстати, раз уж мы опять вернулись к теме контейнерной коллекции, приведу немного "полезной критики".

Угу. Спасибо большое. Кстати, а первое исправление реально дает выигрыш в скорости? Хотя в любом случае, такая запись мне нравится больше.

[mazzy]

Цитата:

Сообщение от Андре

Тебе виднее. К слову, метод union() который мы сейчас обсуждаем присутствует в Аксаптовском классе Set. И выполняет он то, же, что и мой метод, только над set-ом (который, по сути, тоже список), а не над контейнером. Но ведь в Аксапте есть СУБД и необходимости в функциях работы со списками нет, вот так парадокс....

Да. Убил бы...

Не встречал использование Set, но Аксаптовские Map и List активно используются при закрытии склада. По сути дела, вместо того, чтобы сделать нормальную работу с СУБД разработчик копирует записи в своп клиента и делает вид, что это оптимизация - ведь блокировок нет! А потом доблестно бьется за целостность информации и умирающим от натуги клиентом...

Убил бы...

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

(Что-то я злой в последнее время... Завершаю оффтопик, извините)

[kashperuk]

Цитата:

Сообщение от Андре

Угу. Спасибо большое. Кстати, а первое исправление реально дает выигрыш в скорости? Хотя в любом случае, такая запись мне нравится больше.

Пред. ответ удалил.
Правильный ответ смотри по ссылке ниже:

[Lucky13]

Цитата:

Сообщение от mazzy

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

По-моему здесь дело не в способе хранения информации, а в способе вычислений.
Кажется Пролог когда-то умел работать с реляционными БД.

[Андре]

Цитата:

Что-то я злой в последнее время...

Ага, еще и раздражительный. Тоже заметил?

[Андре]

Цитата:

Хм. Взялся проверить, чтобы не быть голословным.
Получается как раз наоборот.

Хе.... спасибо

Цитата:

Кажется Пролог когда-то умел работать с реляционными БД.

Да и Python умеет, и Haskell и Lisp....

[mazzy]

Цитата:

Сообщение от Lucky13

По-моему здесь дело не в способе хранения информации, а в способе вычислений.
Кажется Пролог когда-то умел работать с реляционными БД.

Чистый Пролог никогда не умел работать с БД. Особенно с реляционными. В реляционных БД очень тяжело реализуется концепция отката, которая используется для перебора вариантов.

Пролог - сугубо спискоориентированный язык.