Ответ на »сообщение 271« ()
___________________________
Я думаю, всем здесь было бы удобнее и приятнее с Вами дискутировать, если бы Вы подписывали свои сообщения.

Ответ на »сообщение 266« (panda)
___________________________
Уважаемый panda, ваш пример будет расти (в сложности) по мере осознания разделённости понятий элемента списка и его содержимого. Вы постоянно будете "сшивать" в ваших алгоритмах логику обработки эементов списков и получения/изменения их значений. В конце концов вы придёте к дилеме, что предоставлять для опереирования внешнему пользователю: сами значения или элементы списка, хранящие их. Это не так несусественно, как вам кажется...
JOS всё время говорит, об адекватности и удобстве. В Лиспе идеи и принципы могут быть адекватно реализованы удобным инструментом.
На забывайте, что Лисп позиционируется и как язык СИМВОЛЬНЫХ ВЫЧИСЛЕНИЙ.
Готовое к использованию средство. Попытайтесь те же самые задачи решать в чисто императивных языках и я вам не позавидую... У вас больше времени уйдёт на формирование наборов библиотек и создания инфраструктуры, в которой они должны будут выполняться (желательно, правильно)...

Похоже, что Гата и Грэма так никто и не просмотрел... А почему? Ведь те, кто пришёл к Лиспу, также начинали с Паскаля и Си. Следовательно, эту систему взглядов и подходов они так же прекрасно знают и понимают. Когда императивщики приводят аргументы, функциональщики их ПРЕКРАСНО понимают. Теперь осталось, что бы была взаимность. Но складывается впечатление, что функциональщики это просто те, кто не поленился "заглянуть за грань". Интересно, что большинство из них обратно не возвращаются...
Есть ещё гипотеза, что у людей действительно существуют склонности к тому или иному способу изложения решений. А вдруг вы "латентный функциональщик"? ;) Попробуйте! А то ведь так всю жизнь и будете квадратное (в вашей модели мышления) катать, а круглое носить... ;)

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

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

Я прекрасно понял, что речь идет о вызове функций.
Но представьте себе на минуту, что Вы - человек, не знакомый с императивным программированием :)).

И вот Вы задаете мне вопрос: а как будет выглядеть на императивном языке X запись программы транспонирования матрицы? А я Вам отвечаю: элементарно, Ватсон. Она будет выглядеть так:

Trans(A);

Вы удовлетворены ответом? И Вам не нужно никаких комментариев? Впрочем здесь случай простой - конечно, это стандартная функция языка X для транспонирования матриц. Разве Вы этого не знали?

Да, идет обращение к функции по имени map. Но разве это ответ на вопрос? А откуда эта функция взялась и что она конкретно делает со списком? Ее Jack of Shadows написал или она стандартная для данного языка? А если стандартная, то как выглядит ее определение?
Или Вы, что на полном серьезе считаете, что в записи вида apply map list полностью содержится семантика выполняемого алгоритма? Т.е. по одному только имени map мне уже должно быть ясно, как эта функция работает. Кстати если эта функция транспонирует матрицы, то почему она называется map, а не, скажем, trans?

Ответ на »сообщение 268« (panda)
___________________________
вот знаю только
http://www.haskell.org/haskellscript/

Ответ на »сообщение 267« (Jack Of Shadows)
___________________________
А не можете подсказать насчет такой задачки: как использовать фрагменты кода на Lisp из Delphi? Т.е. есть функция на Lisp, я хочу вызвать ее из Delphi, передав аргументы и получив результат. Очень желательно не используя командную строку. Например, есть ли Lisp, который умеет встраиваться в Microsoft Script Control (как ActivePython)?

Ответ на »сообщение 266« (panda)
___________________________
Сходите, будете неприятно удивлены тем, что там изучают приведенный мной пример на Паскале, 

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

Далее я никогда и нигде не заявлял что в ИЯ рекурсия НЕВОЗМОЖНА В ПРИНЦИПЕ.
Однако везде говорил, что практически всегда цикл легче рекурсии в ИЯ.
Это не только мое мнение. Это мнение всех тех программистов которые в 99% случаев предпочитают цикл рекурсии в дельфи, то есть всех нас :)))


Выбирайте на любой вкус:


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

Если вы будете приделживаться стандартных инструментов, имеющихся в дельфи, то вам таки придется признать что рекурсию со списком по методу первый-остальные сделать не получится (если докажите что я ошибаюсь, буду рад)
А если вы для этого свой список пишете, да еще с кучей своих функций, да еще с вариантами для string или real (а то ведь у вас структура то жестко на integer :)) ) То чем больше вы будете писать, тем больше вы будете доказывать мою точку зрения. НУ ОЧЕНЬ ГРОМОЗДКО ! :)))

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

Я вам приводил примеры работы со списком, используемые повсеместно.
Вы же мне в ответ какую то кунсткамеру привели.
Вы давно заглядывали в школу, поинтересоваться, как детей учат программированию?
Сходите, будете неприятно удивлены тем, что там изучают приведенный мной пример на Паскале, а вовсе не Лисп.

Этого уродца только в цирке показывать. Как вы будете в такой доморощенный список добавлять элементы ?
Выбирайте на любой вкус:

// Добавить 1 элемент.
procedure AddAfter(SourceItem: PListItem; AddingItem: PListItem);
begin
  AddingItem.Next := SourceItem.Next;
  SourceItem.Next := AddingItem;
end;

// Найти конец списка.
function FindLasItem(List: PListItem): PListItem;
begin
  if List.Next = nil then
    Result := List
  else
    Result := FindLasItem(List.Next);
end;

// Добавить список.
procedure AddListAfter(SourceList, AddingList: PListItem);
begin
  FindLasItem(SourceList).Next := AddingList;
end;

Как будете удалять ?
Удалять после конкретного элемента - по аналогии. Если надо удалять конкретный элемент, имея указатель на него самого - нужен двунаправленный список.

Приведите прием применяемый на практике.
А такое и применяется на практике, когда требуется реализовать высокоскоростные операции вставки/удаления элементов на Паскале или С++.

Быстро выяснится что вам придется написать половину функциональности лиспа, чтобы сделать такой подход практичным.
Не увилививайте! Вы сказали, что на императивном языке такие операции со списком написать невозможно. Я Вам написал. Вы начинаете дополнительные ухищрения.

Где вы видели на практике в ИЯ применение такого подхода для работы со списками ?
Повторю (на всякий случай): такое и применяется на практике, когда требуется реализовать высокоскоростные операции вставки/удаления элементов на Паскале или С++.

Ваш пример доказывает возможность (в которой никто не сомневался)
В том-то и дело, что Вы сомневались. Сможете сами отмотать несколько сообщений назад или сделать это за Вас?

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

Никто просто не будет морочить себе голову. О том и речь, рекурсия в ИЯ непрактична.
Порешайте олимпиадные задачки тех лет, когда Паскаль был популярен. Я в свое время написал кучу подобного кода и не считаю такой подход громоздким или непрактичным. Для конкретной задачи (работа со списком в императивном языке) он подходит очень хорошо.


PS. Я НЕ утверждаю, что в ИЯ со списками работать удобнее, чем в ФЯ. Я лишь говорю о том, что возможность работы со списками в ИЯ есть и очень многие люди работали так раньше и работают сейчас.

Ответ на »сообщение 263« (Mirage)
___________________________
Наверное данного конкретного примера нигде не увидеть, ибо неэффективно так складывать.

ОК будем считаь пример приведенный panda неудачным. Ведь сторонники ФЯ приводят именно практичные, удобные примеры а не изворачиваются ради доказательства "и мы так могем"

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

Тогда будет что обсуждать.

Ответ на »сообщение 263« (Mirage)
___________________________
  Нужна причина чтобы делать именно так. Эту причину Вы и взялись всем объяснить.:)
А разве не обьяснил ?
Причина любого выбора в пользу той или иной техники заключается в ее удобстве, легкости и практичности по сравнению с остальными вариантами. В ИЯ рекурсия неудобна, трудна и непрактична по сравнению с вариантом решения при помощи итераций (циклов).
Гляньте на приведенного panda уродца и сравните просто с обрабокой массива в цикле. Все вопросы отпадут сами собой.

В ФЯ рекурсия удобна, легка и практична по сравнению с той же итерацией.
Одна единственная строчка для транспонирования матрицы на лиспе по сравнению с двумя вложенными циклами прекрасно это иллюстрирует.

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

Вы же мне в ответ какую то кунсткамеру привели.
Этого уродца только в цирке показывать. Как вы будете в такой доморощенный список добавлять элементы ?
Как будете удалять ?

Но сама-то запись вполне себе компактна и функциональна?
А список вообще говоря обычный, односвязный.
Если программа работает с такими, то вся инфраструктура есть. В том числе добавление/удаление. Даже обобщается на любой тип. И готовые библиотеки есть.

Где вы видели на практике в ИЯ применение такого подхода для работы со списками ?

Наверное данного конкретного примера нигде не увидеть, ибо неэффективно так складывать. Нужна причина чтобы делать именно так. Эту причину Вы и взялись всем объяснить.:)