Ответ на »сообщение 303« (Jack Of Shadows)
___________________________
На маленьких числах (100 или 1000) прекрасно работает.
На больших (100000) Вылетает с ошибкой Stack Overflow.
Что означает что использование рекурсии в дельфи на больших массивах НЕВОЗМОЖНО !!!

Это означает невозможность её использования "на больших массивах" для данной конкретной версии компилятора.
Причём тут Дельфи, ИЯ-ФЯ? Это проблемы компилятора, умеет он раскручивать хвостовую рекурсию или нет.
GCC умеет, IBM'овский JIT для явы умеет, дотнетовский MSIL имеет специальную инструкцию tail (хотя компилятор сишарпа её и не использует).

Ответ на »сообщение 315« (Q. Werty)
___________________________
>>>Почему в лиспе рекурсия повсеместно ? Почему в дельфи не повсеместно ?
Я уже где-то тут говорил по поводу отношений "цикл-рекурсия". Цикл и рекурсия - это СЕМАНТИЧЕСКИ эквивалентные понятия. Разница только в технической реализации.
Рекурсивный подход более общ, прост, естественен и мощен. Пожалуйста, примените итеративный подход к обходу дерева. Без дополнительных "поддерживающих" операций и структур данных, вы не обойдётесь. Разница проистекает от того, с выражением каких отношений, свойств и понятий предметной области, мы работаем при "переборе" элементов... И – от естественности выражения этих отношений, свойств и понятий в ЯП.

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

Тут просто цикл другой:
while <я голоден> do
  <съесть ещё кусочек>;
Цикл - это не обязательно for.

Вы с лёгкостью положите в чашку ровно 10 ложек сахара.
Папуас, умеющий считать "один-два-много", с той же лёгкостью положит в неё не ровно 10, а примерно 10 = 8-12 ложек.

Потому что вы с ним оба думаете не циклами, а рекурсией. У вас обоих нет в голове флажка ещё/хватит. Вашими действиями руководит последовательная смена физических ощущений.
Просто Вы, в отличие от папуаса, стремитесь к большей точности и потому изобретаете себе костыль в виде воображаемого счётчика. Т.е. подменяете для себя намерение "сделать чай сладким" намерением "досчитать до 10, одновременно кладя ложки".
Папуас же следует естественной модели поведения.

Ответ на »сообщение 314« (Антон Григорьев)
___________________________
И все функции должны следить, что в списке - именно два элемента. И что оба этих элемента - числовые, а не строковые. Не слишком ли сложно получается?
Немного не понятно, что имеется в виду... Вы предполагаете в одной и той же коллекции хранить вместе с комплексными числами элементы других типов?

Упоминание комплексных чисел навеяло вопрос: а как реализовать работу с ними в Лиспе? Единственный тип данных - это список. Следовательно, комплексное число следует представлять списком из двух элементов.
...
В ИЯ таких проблем не существует - просто объявляем соответсвующую структуру, и дальше обо всём заботится компилятор.
DEFSTRUCT
Хотя, я не вижу абсолютно каких-либо трудностей при представлении комплексных чисел списками.

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

Ответ на »сообщение 317« (Гость)
___________________________

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

Ого! То есть, когда Вы собираетесь положить себе в чай N ложек сахара -- это рекурсия?
Ну, если Вы мне покажете, где у Вас на столе лежит переменная цикла...
По-моему, она существует только в Вашем воображении. А объективно есть только ощущение вроде_мало/вроде_хватит.
Кошки и собаки не умеют считать, тем не менее приём пищи дозировать вполне способны.

Тут просто цикл другой:

while <я голоден> do
  <съесть ещё кусочек>;

Цикл - это не обязательно for.

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

Ого! То есть, когда Вы собираетесь положить себе в чай N ложек сахара -- это рекурсия?
Ну, если Вы мне покажете, где у Вас на столе лежит переменная цикла...
По-моему, она существует только в Вашем воображении. А объективно есть только ощущение вроде_мало/вроде_хватит.
Кошки и собаки не умеют считать, тем не менее приём пищи дозировать вполне способны.

Ответ на »сообщение 236« (info21)
___________________________
Как насчет осцилляторов и всяких прочих волн? Раз уж о метафизике речь зашла -- любопытно.
(Вообще, это - оффтопик.)
Ну и что? Отображение скаляра (текущей величины) на рекурсивную последовательность (время).
Надеюсь, о фрактальной структуре вселенной сейчас спорить не будем?

>>>Почему в лиспе рекурсия повсеместно ? Почему в дельфи не повсеместно ?

Я уже где-то тут говорил по поводу отношений "цикл-рекурсия". Цикл и рекурсия - это СЕМАНТИЧЕСКИ эквивалентные понятия. Разница только в технической реализации. Просто в математике укрепилось понятие "рекурсивная функция" (т.е. вычислимая, имеющая алгоритм вычисления на всей области определения). Потом "рекурсивность", т.е. "вычисляемость" приобрела на практике в ИЯ форму "циклически" организованных алгоритмов, а в ФЯ снова вернулась к "истокам", когда форма и содержание понятия снова смыкаются: рекурсивный по сути характер вычислимости становится рекурсивным и по своей форме.
К чему это? А к тому, что выяснение вопроса что "круче" цикл или рекурсия - это тоже самое, что спор о том, какого конца надо яйца разбивать (помните Свифта, борьба между остроконечниками и тупоконечниками в Приключениях Гулливера).
Вот перед Вами типичная СЕМАНТИКА рекурсии:
ФУНКЦИЯ whiledo
ЕСЛИ условие
выход-и-возврат-значения
КОНЕЦ_ЕСЛИ
какие-то-действия-алгоритма
ВЫЗОВ whiledo
КОНЕЦ whiledo
Ну и где тут цикл, а где рекурсия? Перед нами одновременно и рекурсия, т.е. вызов из функции самой себя, и обычная семантика цикла типа "while-do".
Так все эти споры не стоят ничего в смысле достижения какой-либо истины.

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

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

Хочу рассказать об интересной (для функциональных программистов) лисповой библиотеке cells.
http://common-lisp.net/project/cells/

Эта библиотека добавляет интересное расширение к обьектной системе лиспа CLOS.
Она позволяет задавать значения полей обьекта в виде формул, как в Excel вы выражаете значение ячейки (название cells отсюда) в виде формулы. После чего уже не заботитесь о ее обновлении.
Она обновляется автоматически, как только данные, на которые ссылается формула меняют свое значение.
Когда у вас большое количество взаимосвязанных обьектов, которые должны отслеживать и показывать состояние системы, такой подход (декларативный) сильно упрощает код.
А где у вас большое количество взаимосвязанных обьектов, отслеживающих состояние системы ? Правильно! GUI!
Дельфисты хорошо знают и любят этот механизм. DB-Aware visual controls.
Просто указываете Datasource, поле, и больше не беспокоитесь об обновлении окна.
Как хорошо было бы если это можно было бы делать с любым визуальным обьектом, а не только с db-aware controls.
Например чтобы менюшки и кнопки меняли свои свойства автоматически (enabled, disabled) когда какие то данные меняются.

Или progress bar сам бы показывал текущее состояние операции (заргузка чего то) вместо того чтобы явно писать процедуру, навешивая ее на какой то event.

Когда GUI становится сложным, когда обьектов на экране несколько десятков (даже сотен!), и нужно оркестрировать их взаимодействие и отклик на изменение состояния системы, код для такой оркестровки становится сложным, громоздким.
Попробуйте не пользоваться db-aware controls и сделать так чтобы и в таблице и в стоящих рядом editbox, данные менялись синхронно. Попотеете изрядно. Слава богу для нас Борланд уже постралась. И делать этого не нужно. Но вот во всем остальном, в том что не касается баз данных - все та же ручная работа.

Библиотека cells быстро пришлась по вкусу именно в деле автоматизации GUI. И очень быстро на ее основе появились такие GUI библиотеки как Cells-GTK и Cello (OpenGL)

Дальше больше! библиотекой заинтересовались и Питонисты.
И вот уже в рамках спонсируемого Google Summer of Code идет портирование cells на Python, проект PyCells.

Я сам обязательно буду использовать cells если у меня будет проект с GUI на лиспе.
Когда видишь такие вещи то возвращается давно позабытое состояние радости, которое когда то испытывал знакомясь с Delphi 1 :))
Это действительно принципиальное изменение в технике работы с некоторыми задачами (GUI)
При этом возможности cells не ограничиваются только GUI. В принципе любая взаимосвязанная группа обьектов может при помощи cells описывать свои связи декларативно через функции.

О том что такое направление может быть эффективным догадались и в Adobe.
Они выпускают свою собственную декларативную библиотеку для работы с GUI
Adam and Eve http://opensource.adobe.com/group__asl__overview.html

Так что кто знает, может знакомство многих программистов с ФП начнется именно с выполнения такой привычной задачи, как построение GUI :))