Вопрос по lisp...

(loop for x from 1 to 100 collect x)

Сначала

(defun seq (start end)
(loop for i from start to end collect i))

А потом еще проще, чем в erlang --- (seq 1 100)

эх... лууп... а без лупа так никак низя? :)

всё равно спасибо за советы!

Ну и ещё один вопросец... как можно отфильтровать список... ну допустим у нас есть список какой-то... есть вот этот новый 1..100.. как из 1..100 отфильтровать всё что есть в нашем исходном? кроме как через remove-if =)

Определил себе функцию и забыл, с loop'ом она или без.

тоже верно :)

(defun filter (a b)
	   (remove-if #'(lambda (x) (member x b)) a))

О! То что нужно! Спасибо тебе :)

P.S.: чуть позже расскажу зачем мне всё это надо :)

Кстати, в этом плане хорошо почитать On Lisp, там как раз описываются мелкие полезные утилиты, с чем их едят и прочее.

Он лисп у меня следующий на очереди... я сейчас конкретно затарился литературой... боюсь как бы голова не лопнула от всего и сразу :)

> эх... лууп... а без лупа так никак низя? :)

а чем кстати луп не устраиват? он между прочим side-effect safe.

Хм, тоже верно, я об этом не думал :) спасибо за информацию, на будущее учту...

просто мне как человеку только-только приобщающемуся к ФП, начитавшемуся хороших, и не очень, книжек, показалось что конструкция loop не очень ФП way`ная :)

спасибо что развеял это моё заблуждение ;)

А Common Lisp мультипардигмен, поэтому замыкаться на ФП вовсе не стоит, пользы от этого не будет. Тем более, что стандарт CL не указывает необходимость оптимизации хвостовой рекурсии.

Кстати, а что ты там говорил про макрос, проверяющий на side effect'ы?

для фильтрации списка очень часто используют mapcan но remove-if наверное пошустрее будет

> просто мне как человеку только-только приобщающемуся к ФП, начитавшемуся хороших, и не очень, книжек, показалось что конструкция loop не очень ФП way`ная :)

в common lisp hyperspec(http://www.lisp.org/HyperSpec/FrontMatter/index.html) указывается имеет ли данная ф-я или макрос side-effect или нет.

Точно шустрее будет delete-if, но он деструктивный и, как следствие, с сайд эффектами.

> А Common Lisp мультипардигмен, поэтому замыкаться на ФП вовсе не стоит, пользы от этого не будет. Тем более, что стандарт CL не указывает необходимость оптимизации хвостовой рекурсии.

Агам, про это я в курсе :) просто я сейчас познаю дзен ФП, и выбрал для начала лисп :)

> для фильтрации списка очень часто используют mapcan но remove-if наверное пошустрее будет

Хм, погляжу на mapcan, возможно получится красивее :) скорость тут не самое главное на данный момент :)

спасибо!

Про hyperspec в курсе, просто почему-то не обращал на данные указания по поводу сайд-эфектов...

спасибо за информацию :)

> просто я сейчас познаю дзен ФП, и выбрал для начала лисп :)

В таком случае лучше было бы выбрать чисто функциональный язык --- haskell (мне еще нравится unlambda), ну или хотя бы Scheme, он поболее функционален, чем CL.

> Точно шустрее будет delete-if, но он деструктивный и, как следствие, с сайд эффектами.

есть же remove-if, который не деструктивный ;)

Если вопрос стоит в производительности.

>Тем более, что стандарт CL не указывает необходимость оптимизации хвостовой рекурсии.

Кстати насчет хвостовой рекурсии. В c.l.l. недавно пробегал код, как сделать хвостовые вызовы, если их оптимизация не предусмотрена. Там был простой случай, но он может быть и обобщен. Надо бы найти сейчас в gnus'е. Просто иллюстрация хорошая. Немного макрологии и вуаля.

Ну хаскелл я параллельно смотрю :) просто если хаскелл все же больше академически язык, то лисп более подходит для реальных проектов... Поэтому я их рассматривая параллельно... А схему мне как то не хочется :) лисп мне больше понравился.

>А схему мне как то не хочется :) лисп мне больше понравился.

Схема это тоже лисп, несмотря на то, что слова лисп в ее названии нет :)

Ага, нашел эту иллюстрацию:

http://groups.google.com/group/comp.lang.lisp/msg/8f9dcf58a00aca27

весь тред про tail-call optimization:

http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/d62865297b...

P.S. Кстати, про CLISP я прогнал по поводу оптимизации хвостовой рекурсии. Оптимизирует он ее, но только в том случае, когда код скомпилирован. Если нет, то не оптимизирует. Я нарвался на переполнение стека, загружая примеры без компиляции. Недавно перепробовал с компиляцией и все стало ОК.

> Ага, нашел эту иллюстрацию:

Спасибо.

> P.S. Кстати, про CLISP я прогнал по поводу оптимизации хвостовой рекурсии. Оптимизирует он ее, но только в том случае, когда код скомпилирован.

У CLISP вообще многое отличается при компиляции и интерпретации.

> эх... лууп... а без лупа так никак низя? :)

А чё - тошнит? 0_0

Можно и без лупа. Даже можно и без лиспа. И совсем без компьютера - тоже можно...

Скажем так, меня не устраивает её (схемы) ограниченность, все же CL пофичастей будет :)

> P.S. Кстати, про CLISP...

А доку читать начнёшь когда совсем всё перестанет работать?...

Да ладно тебе, не придирайся :) не тошнит меня совсем... Был неправ - исправлюсь! :)

Можешь привести какой-нибудь пример, демонстрирующий ограниченность Схемы?

> Да ладно тебе, не придирайся :)

Да ладно тебе - не обращай внимания. Это у меня неестественная реакция в виде ворчания по поводу поросячьих восторгов при ознакомлении с лиспом... :D

> Можешь привести какой-нибудь пример, демонстрирующий ограниченность Схемы?

http://www.schemers.org/Documents/Standards/R5RS/

Я тупой, наверное. Какая связь между стандартом R5RS и ограниченностью языка?

А что, по-твоему, ограничивает язык, как не стандарт?

Объясни, в чём именно проявляется ограниченность Схемы. Пока вижу от тебя только бессмысленную ссылку и какие-то мутные намёки. Текущий стандарт R6RS, кстати.

> А что, по-твоему, ограничивает язык, как не стандарт?

Ну стандарт это хорошо, только в реальной жизни мало, например, программ, которые полностью написаны на ANSI/ISO C. Что касается макросов в CL-стиле (которые часто приводятся как пример крутизны CL), то они хоть и не стандартизованы, но есть в любой вменяемой реализации Схемы. Мне кажется автор сей темы ясно сказал, что он понимает под "ограниченностью" --- это кучу "фичей" прописанных в стандарте. Поэтому не вижу смысла в очередной баталии Scheme vs CL :)

С учётом наличия в стандарте R6RS syntax-case, лисповые макры уже не аргумент -- они реализуемы на Схеме.

А если ограниченностью называть компактность стандартной библиотеки -- ну, это какое-то шибко альтернативное представление об ограниченности...

> Объясни, в чём именно проявляется ограниченность Схемы. Пока вижу от тебя только бессмысленную ссылку и какие-то мутные намёки. Текущий стандарт R6RS, кстати.

Ну уж если ссылки на стандарт (видимо, в нем нет смысла) мало, то как мне объяснить ограничения Scheme? И как много реализаций поддерживает R6RS?

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

> А если ограниченностью называть компактность стандартной библиотеки -- ну, это какое-то шибко альтернативное представление об ограниченности...

Как следствие компакности --- многое, что есть в CL, приходится делать руками, либо использовать SRFI и иже с ними. Так что компактнее, еще вопрос --- Scheme + SRFI или Common Lisp.

> Точно шустрее будет delete-if, но он деструктивный и, как следствие, с сайд эффектами.

Совсем не обязательно. В списке m + n элементов, из которых n останется и m отфильтруется. Вопрос на засыпку: сколько раз

(1) будет вызван предикат
(2) будут вызваны элементарные операции над списком

при

(a) remove-if
(b) delete-if
(c) mapcan

?

>А доку читать начнёшь когда совсем всё перестанет работать?...

Я не могу держать в голове столько мелочей по каждой реализации, потому что проверяю свой код в трех реализациях время от времени. Я могу знать мелочи одной реализации, но у меня нет возможности и времени докопаться до мелочей в другой. Один раз была проблема с CLISP. Теперь ее нет. Других проблем нет. Есть смысл читать документацию или стандарта хватит пока? Заворчался ты что-то реально. Отдохнул бы :)

Я имел ввиду, что delete-if будет быстрее remove-if. Насчет mapcan я вообще не знаю.

>Да ладно тебе - не обращай внимания. Это у меня неестественная реакция в виде ворчания по поводу поросячьих восторгов при ознакомлении с лиспом... :D

А вот тут согласен, потому что на ЛОРе CL *перепиарили*, не уточнив про имеющиеся проблемы в реализациях, библиотеках, про проблемы, которые еще надо порешать самому. В итоге довольно много людей приходят в надежде сразу нажать кнопку в чтобы из REPL выпархал надежный, работающий какой-нибудь трехмерный CL-Compizd. Но наткнувшись на проблему сразу заявляют, что говно этот ваш Лисп. Лично я вот пытаюсь проблемы молча решать. Но наверняка есть люди, которые думают, что в CL все за него напишут Великие Макросы. Некоторые тут начинали с вопросов, а как у него с GTK? А Qt? То есть вопросы просто нерелевантные изучению и вхождению (это при том, что информация по этому есть в инете и легко находима). Книжки тоже не могут в сети найти. "С чего начать изучение Лиспа?". Пипец. После такого вопроса хочется сказать: "С себя начни!". Ну какой Лисп может быть в этом случае, если справиться с англоязычным поиском не в состоянии!

> Я имел ввиду, что delete-if будет быстрее remove-if.

Зависит от имплементации remove-if. Если он будет *собирать* нужные элементы, то не обязательно. Если он будет тупо, как в sbcl, копировать, а потом вызывать delete-if, то да.

Еще зависит, от того, сколько остается после фильтрации.

Кто-то мне на форуме этом ответил, а зачем искать, если можно спросить?

Что касается поиска, то на cliki собрана наиболее актуальная коллекция туториалов: http://www.cliki.net/Online%20Tutorial

Там же живут книги: http://www.cliki.net/Online%20Tutorial

И просто какие-то интересные записи: http://www.cliki.net/document

Можно начинать читать с этого, как будет прочитано все (хорошо, просмотрено 3 раза по диагонали) можно приступать к написанию своего :)

Да, еще есть http://lispy.wordpress.com/