Разрешите еще два вопроса по идеологии ФП.
1) Как я понял, программа на "чистом" ФЯ - это набор определений взаимосвязанных функций. Можно сказать, что программа представляет собой одно большое вычисляемое выражение. С другой стороны, любая "нормальная" программа - это все-таки какая-то определенная последовательность действий - сначала пользователь открывает какую-то форму, потом заполняет поля, потом нажимает кнопку, потом программа вычисляет что-то одно, потом что-то другое и т.д. Как при этом можно обходится без четкого указания что должно следовать за чем, т.е. без "императивности". Пока это не очень понятно.
2) Как вообще в ФЯ, например, в том же Haskell, создавать визуальные элементы управления. В Блэкбокс все ясно - открыл меню, создал форму, на форме создал контролы, связал их с переменными и процедурами и все. А в полной версии WinHugs (~40МБ) в меню даже намека на операцию создания формы нет. Какая в функциональных языках используется "идеология" для создания элементов графического интерфейса? Человеку, испорченному визуальными и компонентными средами, этот вопрос тоже с ходу не дается :))

P.S.
Дошел до своей первой программы на ФЯ - что-то вроде личного варианта Hello, world на незнакомом языке. Написал программу на Хаскеле, которая формирует и выводит список из 10 чисел Фибоначчи, используя для этого рекурсивное определение функции F(N), где N - номер числа в последовательности, а F - значение числа.

-- Последовательность чисел Фибоначчи
module Fibonachi where
main = t >> s
t = putStrLn "Числа Фибоначчи"
s = print ( map f [1..10] )
f :: Int -> Int
f 1 = 1
f 2 = 1
f n = f(n-1) + f(n-2)

Чтобы вывести сначала текст заголовка, а потом список чисел использовал >> (это, наверно, следы императивности, от которых трудно полностью избавиться :). В общем в результате получился модуль Хаскел, который делает то, что мне надо. Но уверенности в его качестве нет - все-таки первая программа на новом языке, мало ли, что я тут наваял :))) Поэтому вопрос к знатокам - что тут плохо, что нормально, и как вообще можно записывать функции, которые должны выполняться в определенной последовательности, но не прибегать при этом к "императивному мышлению" как в данном случае (>>)?

Спасибо за ссылку!
Слишком рано заволновался :)).
Поработал с модулями - там все нормально. Этот паразит в режиме командной строки кириллицу игнорирует, а когда из модуля, то пожалуйста, выводит любой литерал!
Ну, так еще жить можно.

Мои отношения с Haskell 98 (Hugs) под угрозой :))).
Выполняю код типа: putStrLn "Hello, world!"
Получаю свой текст без проблем.
Набираю putStrLn "Привет, мир!"
Интерпретатор выдает что-то типа: "??????, ???!"
Опять "проблема кириллицы" встала на пути прогресса ))).
И почему ребята совершенно не думают, что кто-то может использовать в их замечательной системе не только латынь? Кстати, с набором кириллицы нет никаких проблем - значит это уже интерпретатор так интерпретирует? Коллеги, которые "съели собаку" на этих вещах - что можете сказать по этому поводу. Клинический случай или есть решение? Заранее, спасибо.

Вот насчет практического применения...
Подскажите пожалуйста есть ли такая возможность в ЛИСПЕ
Это больше относится к биб-кам, чем к "языку будущего".
Необходима правильная консольная работа. Типа curses.
прямой доступ к символу по адресу (строка, столбец) и управление цветом
(текст, фон) как это делается в ФАРе.
Подскажите где копать.

как  писать в функциональном стиле на js
http://www.remast.de/javascript.php
http://javascript.infogami.com/Functional_Javascript

Ответ на »сообщение 383« (Антон Григорьев)
___________________________
>>> "если первый ряд кубиков пуст, возвращаем без изменения второй ряд, иначе откладываем из первого ряда кубик, а к тому, что осталось, применяем ту же операцию, и её результат объединяем с отложенным кубиком".

"возвращаем" "откладываем" - императивные слова, обозначающие действия.

Функционально думать, наверное, так:

"соединение списков а и b это:

• список b, если a пуст
  
• список из (головы A) и (соединения (хвоста A) и B)
  

"

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

Еще мне кажется что цикл проще для понимания, потому что использованы разные примитивы. Допустим у нас были было бы функция add(xs, x) - присоединение к списку xs элемента x

append(a, b)=
  if b=nil then
      a
  else
      append(add(a, head(b)), tail(b))

вот, допустим питоновский код:

def append(xs, ys):
  result=xs
  for y in ys:
      result+=y
  return result

но здесь у нас есть for .. in а теперь давайте попробуем построить его на тех же примитивах

def append(xs, ys):
  result=xs
  rest=ys
  while rest:
      add(result, head(rest))
      rest=tail(rest)
  return result

а теперь попробуюем написать то же в функциональном стиле, но с аналогом for .. in

def append(a, b):
  return reduce(add, b , a)

функция reduce:

reduce( function, sequence[, initializer])

Apply function of two arguments cumulatively to the items of sequence, from left to right, so as to reduce the sequence to a single value. For example, reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2)+3)+4)+5). The left argument, x, is the accumulated value and the right argument, y, is the update value from the sequence. If the optional initializer is present, it is placed before the items of the sequence in the calculation, and serves as a default when the sequence is empty. If initializer is not given and sequence contains only one item, the first item is returned.


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

Ответ на »сообщение 383« (Антон Григорьев)
___________________________

но всё равно - итерация проще.

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

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

Книга же которую вы читаете не поможет вам освоить лисп. Вам нужен что то типа htdp.org Увы может на русском его и нет. И практика. Префиксная запись слишком чужда вам чтобы безо всякой практики вы могли легко читать код и делать обьективные сравнения по легкости/сложности подходов.

Вы бы хотя бы что нибудь попривычнее взяли - ocaml или haskell. Там хоть форма записи инфиксная.

Решил освежить свои знания Лиспа по книге http://www.delphikingdom.com/asp/book.asp?BookID=63 Там описан диалект Лиспа Scheme.

Сначала - ликбез для тех, кто с Лиспом не знаком совсем. Основной элемент данных - атомы и списки. Атом - это идентификатор или число, список - это список из нескольких элементов, каждый из которых может быть атомом или списком. Список заключается в круглые скобки. Например, (A B C) - список из трёх элементов A, B и C, (A (B C)) - список из двух элементов - атома A и списка (B C).

Список является не только элементом данных, но и синтаксической конструкцией языка. (A B C) интерпретируется как "применить функцию A к аргументам B и C). Если перед списком поставить одиночный апостроф, то он не вычисляется, а передаётся как есть. Например:

(A (B C D)) - применить функцию А к результату применения функции В к аргументам С и D
(A '(B C D)) - применить функцию А к списку (B C D)

Основные функции работы со списком - CAR и CDR. CAR возвращает первый элемент списка, CDR возвращает хвост списка - список без первого элемента. Например:

(CAR '(A B C)) вернёт A
(CAR '((A B) C) вернёт (A B)
(CDR '(A B C)) вернёт (B C)
(CDR '((A B) C) вернёт (С)

Ещё есть функция CONS - конструиование списка из двух элементов. Первый аргумент может быть атомом или списком, второй должен быть списком. На выходе получается список, первым элементом является первый аргумент, хвостом - второй. Например:

(CONS A '(B C)) восзвращает (A B C)
(CONS '(A B) '(C D)) возвращает ((A B) C D)

Для любых аргументов a1, lst1 верны отношения

(CAR (CONS a1 lst1)) = a1
(CDR (CONS a1 lst1)) = lst1

Теперь рассмотрим, как в Лиспе определяется функция для объединения двух списков. Назовём эту функцию append. От CONS она отличается вот чем:

(CONS '(A B) '(C D)) даёт ((A B) C D)
(append '(A B) '(C D)) даёт (A B C D)

Итак, вот эта функция:

DEFINE (append lst1 lst2)
  (COND
    ((NULL? lst1) lst2)
    (ELSE (CONS (CAR lst1) (append (CDR lst1) lst2)))
))

COND - это аналог case, NULL? - функция, возвращающая #T (т.е. True), если её аргумент - пустой список. Переведём на человеческий язык, что делает эта функция. Пусть у нас есть два ряда кубиков, и нам нужно объеденить их в один. Тогда функция append работает так: "если первый ряд кубиков пуст, возвращаем без изменения второй ряд, иначе откладываем из первого ряда кубик, а к тому, что осталось, применяем ту же операцию, и её результат объединяем с отложенным кубиком". Немного напрягшись, конечно, можно понять, что в результате мы получим то, что нам нужно, но сравните то же самое с чётким и ясным итеративным описанием: "пока во втором ряду есть кубики, повторять: взять первый кубик из второго ряда и перенести его в конец первого ряда".

Одним словом, я могу поверить, что ФЯ имеют серьёзные преимущества при распараллеливании. Что Лисп имеет уникальные возможности по созданию самомодифицирующегося кода благодаря тому, что список - это и элемент данных, и команда языка. Но вот поверить в то, что рекурсия ближе к человеку, чем итерация, я, извините, не могу. Можете считать меня человеком, безнадёжно испорченным императивными языками, но всё равно - итерация проще.

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