Ответ на »сообщение 1540« (Geniepro)
___________________________
Да забыл ответить на вопрос :)
Для ручной мемоизации можно воспользоваться функцией memo из модуля memo
То есть

import Memo

fdec n = memo dec n

После чего вместо dec используете fdec.

Ответ на »сообщение 1540« (Geniepro)
___________________________
Прошу прощения, я ошибся.
В хаскеле нет автоматической мемоизации вызовов функций. Это можно сделать только вручную.
Меня сбила с толку автоматическая мемоизация выражений (memoization of expressions).
То есть напишите для первого вызова let x = dec 1000000000
dec не выполнится сразу же а только когда понадобится то есть когда print x
А вот на второй раз print x не будет выполнять dec, а возьмет запомненное значение.

Ответ на »сообщение 1539« (Jack Of Shadows)
___________________________

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

кстати, а как заставить GHC запоминать это значение? Вот пример:

main = do t1 <- getClockTime
          print t1
          print (dec 1000000000)
          t1 <- getClockTime
          print t1
          print (dec 1000000000)
          print (dec 1000000000)
          t1 <- getClockTime
          print t1

dec :: Int -> Int
dec n = f n 0 0
  where
    f x y z  = if x==1 then 0 else f2 x y z
      where
        f2 x y z = if (y+1)==x then z else f2 x (y+1) (z+1)

dec 1000000000 вычисляется КАЖДЫЙ раз перед распечаткой, причём одинаковое время.
То есть в данном случае мемоизации нет?
Я замечал это кеширование только со списками - результаты работы функций обработки списков как-будто действительно запоминаются.

Ответ на »сообщение 1538« (Сергей Перовский)
___________________________
Как насчет общения с другими программами?
С другими модулями?
Вы им параметры - они вам результат :))

Как вы общаетесь скажем с математической библиотекой ? Разве функциям sin, cos нужно от вас что либо кроме передаваемого им параметра ? Разве они должны делать что то еще помимо вычисления и ВОЗВРАТА результата ?
Разве они ответственны за то куда этот результат сохранить ?

В принципе любую работу можно представить как выборку из базы данных разных заранее записанных туда значений, например заменить функцию sin на функцию которая будет по параметру искать из таблицы и возвращать значение результата. Это императивность, когда вы не знаете, не можете выразить взаимосвязь между параметром и возвращаемым значением и потому вам эту взаимосвязь приходится вычислять и временно ХРАНИТЬ где то, до того момента когда понадобится. Однако если вы знаеете формулу, зачем ее вычислять и где то хранить ?
Это же низкоуровневая оптимизация. Пусть ею компьютер занимается (мемоизация).
Так в хаскеле функция отработавшая один раз по какому то параметру не будет вычисляться заново по тому же параметру, а просто вернет запомненное с первого раза значение.
Точно также как вы бы запомнили это значение для последующего применения, только здесь это за вас сделает компилятор.
Как видите императивность все равно существует, состояние существует, но от микроменеджмента ФЯ вас избавляет.
Вместо ручного управления состоянием - автоматическое, как вместо ручного управления освобождением памяти - автоматическая сборка мусора. Только вот сборка мусора по сравнению с автоматическим управлением состоянием - это такая мелочь, которая даже не стоит упоминания.
Это по ее уровню воздействия и важности для повышения качества программ, упрощения алгоритма, и контроля сложности систем.
При этом сборка мусора не отменила ручное управление рессурсами.
Так например открытый файл все равно надо закрывать вручную, открытый connection к базе данных все равно надо закрывать вручную. Никакой сборщик мусора за вас это не сделает. То есть ручное управление рессурсами осталось, просто его стало гораздо меньше. Ту часть с которой может справиться машина - отдали машине.
Также и с состоянием. Он никуда не исчезнет, и нам все равно придется в ручную управлять им, изменять его.
Но не повсеместно в программе, а только на небольших ее участках.

Ответ на »сообщение 1534« (Jack Of Shadows)
___________________________
>>>ФЯ не может отменить ИЯ (по крайней мере на машинах существующей архитектуры), просто потому что ИЯ - это единственный способ общения программы с внешним миром.
>>>Давайте в конце концов перестанем обвинять друг друга в попытках взаимного уничтожения :))
А кто обвиняет? Да ни разу :)
Мне только подозрительно утверждение
>>>ИЯ - это единственный способ общения программы с внешним миром.
Только ли с внешним миром?
Как насчет общения с другими программами?
С другими модулями?
Как часто удастся свести общение к вызову функций?

>>>Однако убрать состояние оттуда где оно не нужно (описание процессов и взаимосвязей системы) - вот это ФЯ должно и будет делать.
Например технологический процесс с точки зрения оборудования - последовательность операций, а с точки зрения объекта обработки - последовательность изменения его состояния. Взаимосвязи элементов системы типа  сообщение-реакция вряд ли можно описать не опираясь на понятие состояния.
Похоже тут у нас тоже терминологические разночтения. Сами понятия процессов и взаимосвязей видимо отличаются :(

Ответ на »сообщение 1533« (Владимир Лось)
___________________________
Представьте себе, что астроном заявит, что по его расчетам Земля столкнется с крупным астероидом, и на Ваш резонный вопрос "Когда?" скажет: 
<<<"это произойдёт, когда выполнятся условия ...(перечисление условий)". 

Мы имеем дело с разными моделями и по разному интерпретируем термины.
Если мы, всего навсего, пытаемся произвести некоторые вычисления, например расчитываем напряженное состояние конструкции, то время появляется только из за последовательности шагов алгоритма и от него можно абстрагироваться - ура функциональному программированию.
Если мы моделируем работу аэропорта в критической ситуации, для нас важно время, идущее в нашей модели.
Я не могу позволить себе сказать: "при условии перегрузки таких то ресурсов аэропорт будет закрыт", мне необходимо явно указать, что "это произойдёт в АА часов ББ минут ВВ секунд".
Имитационное моделирование представляет собой эксперимент, проводимый над моделью системы. И модельное время, с точки зрения экспериментатора - объективная реальность. И состояния всех элементов в интересующий нас момент времени - объективная реальность. И как тут приложить функциональный подход?

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

Ответ на »сообщение 1535« (Lisp Hobbyist)
___________________________
Сам жду. Пока Тилтон ничего на CVS не выложил.
Дам ему еще пару дней, потом спрошу опять.
Там из кода видно будет что он имел в виду под тем что любой символ уже обьект с нескольким слотами.

Ответ на »сообщение 1525« (Jack Of Shadows)
___________________________

Я написал Кени Тилтону об идее макроса def-cells-var с symbol macros внутри.
Он ответил что идея ему понравилась и он уже добавил два новых макроса def-с-var и def-с-parameter в cells.
Причем что самое интересное, оказалось даже не нужно создавать обьект с один слотом. Любой символ в лиспе - уже обьект с несколькими слотами, только один из которых хранит его значение.

CL-USER 1 > (class-of 'foo)
#<BUILT-IN-CLASS SYMBOL 20731A6C>

CL-USER 2 > (class-effective-slots (class-of 'foo))
NIL

Где слот со значением? (symbol-value 'foo) за слот не считается, так как не управляется через MOP.


Вот вам и cells с поддержкой простых типов а не только обьектов.
Я думаю он скоро выложит код на CVS.


Насколько я могу видеть,

(setf (symbol-value '*xxx*) 'foo)

игнорирует setter function, что, собственно, и зафиксировано в CLHS. Без этого, ИМХО, решение неполное --- пусть сам программист так и не напишет, а вот какой-нибудь макрос из сторонней библиотеки --- запросто.

Господа вопрошающие. Вы опять скатываетесь к двум утверждениям, которые многокоратно здесь опровергались.

Так надо ли в 21 веке делать революцию и во имя торжества определенной парадигмы (ФЯ) полностью отказываться от другой (ИЯ)?

ФЯ не может отменить ИЯ (по крайней мере на машинах существующей архитектуры), просто потому что ИЯ - это единственный способ общения программы с внешним миром.
Давайте в конце концов перестанем обвинять друг друга в попытках взаимного уничтожения :))

Функциональный подход, отвергая понятие состояния, тем самым отвергает понятие модельного времени. 

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

По поводу моделей как отображения и прочей лабуды, будет время напишу свои мысли. Вам они не понравятся :))

Ответ на »сообщение 1532« (Владимир Лось)
___________________________
Что бы было понятно. Для меня не имеют смысл слова "это произойдёт в АА часов ББ минут ВВ секунд", скорее я пойму, когда скажут "это произойдёт, когда выполнятся условия ... (перечисление условий)".