Ответ на »сообщение 2129« (Сергей Перовский)
___________________________

>>> Функция возвращает вам НОВЫЙ список шаров с новыми координатами.

Собственно функция меня и интересует :)
По ходу дела нужно определить моменты соударений, т.к. они меняют траектории шаров и ДАЛЬНЕЙШИЕ расчеты нужно вести по другому. Без явного введения в модель времени нам не обойтись. В императивном мире тут есть два подхода - тактовый и событийный. В функциональном нам придется использовать один из них, видимо предпочтительнее событийный.

А чем Вас тактовая модель не устраивает?
Ленивые списки, которые хранят в своих элементах состояние мира модели, приходящееся на некие такты этого самого модельного мира...

Ответ на »сообщение 2127« (Руслан Богатырев)
___________________________


Давайте попробуем разобрать модель ФП с позиций императивщика...

Напомнило отрывок из поэмы "Три дервиша" некоей Феаны .
Просьба помидорами не кидаться и на себя эту поэму не проецировать! :о))

*****

Итак, пошёл наш Як-баба искать дорогу.
Он раньше спрашивал: - Живёт ли здесь мудрец?
Теперь - страну для Дураков… Один отец
Спустя три месяца направил, дал подмогу.

И он нашёл свою страну для Дураков,
Где удивительные вещи происходят!
Но, как ни странно, солнце всходит и заходит,
И ночь темна, и светел день, и нет замков…

Вот он идет и… видит, женщина несёт
Дверь… на себе! И он спросил её об этом.
- Да, уходя, мой муж порадовал советом:
Не поздоровится тебе, коль кто войдёт

Вот в эту дверь! - и мне пора идти уж дальше.
- Я объясню тебе, как тяжесть не таскать.
- О, нет, не надо, мне пора уже бежать…
А то мой муж вернётся к дому часом раньше.

Идёт он грустный. Видит люди у дороги
Дрожат от страха, взгляд направлен на арбуз.
- Какое чудище! Спаси нас, бог Иисус!
Оно убьёт нас. Как же боги стали строги!

А дервиш Як им говорит: - Я объясню!
Толпа кричит в ответ: - Не будь же дураком!
Мы не желаем знать. Убей его тайком!
А он арбуз ножом разрезал и вкусил!

Крестьяне в ужасе: - Уйди, не возвращайся,
Чтоб не убил и нас как монстра тем ножом!
А Як-баба подумал: - Нужно дураком
Стать, как они, чтоб их понять, не обольщайся…

Так он учил их много лет и, наконец,
Достиг он Знания Великой Глубины…
И стал святым для обитателей страны,
Где называли все его “Наш Як - мудрец”!

И даже Книгу Бытия о нем создали,
Как о Великом Покорителе арбузов,
О просветлённом, разъяснившем тайну грузов.
И с той поры уж Книгу в школах изучали…

*****

Ответ на »сообщение 2119« (Geniepro)
___________________________
>>>Посмотрите на Функциональное Реактивное Программирование
То, что обработчики событий удобно писать в функциональном стиле мне объяснять не надо: сам стараюсь по возможности так делать.
Я пытаюсь донести простую мысль, что в сложных системах события возникают не только от взаимодействия с пользователем, но и от взаимодействия частей программы, как их не называй. К сожалению это сложно показать на простых примерах. В результате получаем интенсивный поток событий, обрабатываемых относительно простыми функциями. В такой конфигурации важнее, чтобы язык позволял наиболее простую работу с объектами и событиями, чем с функциями.

Ответ на »сообщение 2114« (Jack Of Shadows)
___________________________
>>>Функция возвращает вам НОВЫЙ список шаров с новыми координатами.
Собственно функция меня и интересует :)
По ходу дела нужно определить моменты соударений, т.к. они меняют траектории шаров и ДАЛЬНЕЙШИЕ расчеты нужно вести по другому. Без явного введения в модель времени нам не обойтись. В императивном мире тут есть два подхода - тактовый и событийный. В функциональном нам придется использовать один из них, видимо предпочтительнее событийный. Придется построить три функции: вычисление времени до ближайшего соударения, вычисление положения( и скорости) через заданное время при отсутствии соударений и вычисление изменений скорости при соударении.
И вызывать их придется последовательно, т.е. императивность будет возникать не только в моменты ударов - взаимодействие с пользователем, но и в моменты соударений - взаимодействие между объектами. Рекурсия в данном случае нисколько не упрощает алгоритм, а накладные расходы увеличивает.

Ответ на »сообщение 2118« (Geniepro)
___________________________

Ответ на »сообщение 2111« (Руслан Богатырев)
___________________________
Я не хочу использовать модули как объекты - для хранения какого-то изменяемого состояния.
Роль объектов должны играть объекты или временные переменные, явно передаваемые через параметры функциям.

Речь идет не о "каком-то изменяемом состоянии", а о выстраивании динамических связей между модулями. В ИП для этого можно применить, например, инсталлируемые объектные разъемы - на основе переменных модуля.
В ФП можно подумать о введении какого-либо рода декларативных слотов, по которым можно формировать динамические связи между модулями. И присваивания, и переменных не нужно. Однако все равно этот механизм является синхронным, то есть, изменяющим некоторое состояние во времени (какой модуль с каким связан).

В текущем варианте "модули" в ФП - это всего лишь пассивные пакеты, поддерживающие сокрытие информаци, не более. На большее они не способны.

Давайте попробуем разобрать модель ФП с позиций императивщика. Представим себе, что перед нами стоит задача реализовать run-time для какого-то ФЯ.

Итак есть функции без побочных эффектов. Т.е. это почти те же процедуры-функции, что и в случае ИП, только подчиняющиеся определенным ограничениям:
1. Функция имеет доступ к контексту вызова внешней функции -- инициатора вызова, причем только на чтение.
2. Функция не может изменять свои формальные параметры.
3. Функция возвращает результат в виде функции или атома/списка.

Создаваемые в результате работы сущности носят "одноразовый" характер. Как только произошла их конкретизация (из состояния UNDEFINED), другие значения приниматься не могут. Сущности заводятся в динамической куче с автоматической сборкой мусора. Подавляющее большинство сущностей носит временно-вспомогательный характер и уничтожается за ненадобностью.

Если функция (обычно унарная) уже вызывалась с конкретными параметрами, то ее значение может быть занесено в "мемоизированную" память (кэширование), чтобы потом не вычислять по новой. В ФП используется карринг (currying) -- сведение обработки функции от n-аргументов к конкатенации n-функций от одного аргумента. Кроме того, есть closure ("герметик") -- контекст вызываемой функции, который принадлежит инициатору вызова -- вызывающей функции. Функция может попользовать внешние данные как read-only. В ФП различают прямые и отложенные (ленивые) вычисления. Прямые требуют непосредственного вычисления, отложенные -- по мере надобности.

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

Ничего существенного не забыл?

Ответ на »сообщение 2124« (Max Belugin)
___________________________

>>>Логически продолжите эту мысль, и, думается, Вы придете к тому же подозрению, что возникло у меня: в ФП состояние "всплывает наверх".

Наверх, это куда?

Туда. (AVC машет рукой в неопределенном направлении.)
Это не совсем шутка.
Я действительно не знаю, куда функциональщики "прячут свое состояние" в чистом ФП.
Сначала я предположил, что состояние всплывает наверх и оседает где-то "на глобальном уровне".
Меня вежливо поправили (и здесь, и на RSDN), сказали что это не так.
Вместе с тем, если состояние программной системы меняется в результате вычислений (она "учится" :) ), то изменения должны где-то накапливаться.
Проблема?

Ответ на »сообщение 2118« (Geniepro)
___________________________

Если честно, то я просто не вижу каких-то проблем с модульностью в ФП.

Это меня и настораживает. Особенно в свете того, что если функция и класс -- законченные сущности (получилось двусмысленно, но не обижайтесь), то модуль -- это полуфабрикатный контейнер. Без вещей другого уровня (процедур, конструкторов типов) он как горшочек без меда. Разве что в руках покрутить. Модуль в модульном программировании -- это не только область видимости, но и область существования. Поскольку память в ФП весьма своеобразная и ей противопоказано иметь на борту модулей какие бы то ни было переменные, то тут не все так очевидно.

В ФП есть функция. В ИП тоже есть функция. Но это, мягко говоря, разные вещи (хотя  и родственные), называемые одним словом. С модулем, похоже, ситуация обстоит аналогично.

Ответ на »сообщение 2123« (AVC)
___________________________


Логически продолжите эту мысль, и, думается, Вы придете к тому же подозрению, что возникло у меня: в ФП состояние "всплывает наверх".

Наверх, это куда?

Ответ на »сообщение 2122« (Max Belugin)
___________________________

>>>В чистом ФП нет не состояния а побочных эффектов. То есть состояние является всегдя явным аргументом и только той функции которой оно нужно и только состояние того куска мира, которая нужна функции. Насколько я понял.

Логически продолжите эту мысль, и, думается, Вы придете к тому же подозрению, что возникло у меня: в ФП состояние "всплывает наверх".