den73 переходит на Python

Функция restart-example вызывает restartable-/

Если в restartable-/ возникает ошибка(например, аргумент - не число, или деление на 0), она выбрасывает исключение.

Исключение поднимается до restart-example, а в нем стоит перехватчик исключений, который, в зависимости от кейворд-аргумента(try-again) выбирает, ввести ли новые значения, или же вернуть 0. Выбрав, обработчик снова передает управление вниз, в функцию restartable-/, которая, в зависимости от выбранного перезапуска, либо возвращает нуль, либо применяет сама себя к новым аргументам(и так до тех пор, пока аргументы не окажутся валидными)

во втором случае (+ a b), конечно же

притом, в обработчике "restartable-/" снова не вызывается, а именно что передается управление унутрь стека.

Тут это, может быть, не так заметно, т.е. можно было бы и прямо вызывать снова.

А если, допустим, между функцией с перехватчиком, и функцией, в которой установлен перезапуск - несколько уровней стека вызовов...

> возобновляемые ошибки.

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

Все это спокойно делается анонимными функциями, либо не дожидаясь С++0х превращаем функцию в класс, или в С просто передавая кучу указателей на нужные переменные в стэковом фрейме.

Где я не прав?

З.Ы. оказывается прыжки по стэку -- это любопытно.

> несколько уровней стека вызовов...

Мне бы хотелось не код, а словесный пример типа моего http://www.linux.org.ru/jump-message.jsp?msgid=3667009&cid=3668073

Чего-то запоздалый переход на Python.

Может лучше на Scala?

http://en.wikipedia.org/wiki/Scala_(programming_language)

Ты уже писал пример, как забоксить с помощью темплейтов, а разбоксить отказался. Задача - сделать полиморфный вариант с помощью шаблонов, при этом не регистрируя отдельно каждый новый тип. В лиспе ты определяешь новый тип и, если его можно читать с консоли, его сразу можно вставлять в список, т.к. он является подтипом типа t (всё). Я считаю, что в С++ так сделать просто в принципе невозможно. Кроме определения типа, нужно определить ещё и способ сворачивания-разворачивания его в-из полиморфный вариант. Ты написал способ сворачивания (хотя и некрасивый) на темплейтах и сказал, что разворачивание очевидно и делается по аналогии. Но, с моей точки зрения, всё упирается в невозможность получить по объекту его тип. Значит, и шаблон, к-рый делает обёртку, не сможет эту информацию в себя записать (разве только в виде текста, но радости в этом никакой). Значит, нужно ещё одно явное указание типа в какой-то закодированой форме. А ты утверждаешь, что разбоксить можно, для этого нужно написать что-то одно на всю программу (а не на каждый тип, к-рый хочется боксить).

Вот это я и хотел.

А лисп пользуют не ради типов. Там типами вообще особо не парятся.

>(defgeneric add (object &key))
Ну скорее тогда &rest. Проблема в том, что у тебя
может быть библиотека. Допустим, две библиотеки. В одной
(add container element)
в другой
(add element container)
т.е., несовместимые по смыслу сигнатуры. И что, патчить чужой код?
Этот вопрос решается пакетами. Но пакеты имеют длинные имена (плохо разработана система модулей и нет import as, хотя я вроде сделал, см. comp.lang.lisp). И главное, что в статических языках ты ОДИН раз написал тип переменной и получаешь контекст: все, что после этой переменной и точки - относится к этому типу. В лиспе такого нет. Это иногда хорошо, но для больших программ это скорее плохо: приходится многократно повторять одно и то же, задавая контекст тем или иным способом. "Создадим объект Ой и назовём его ой. Возьмём от объекта ой поле ой типа ой. Вызовем функцию добавить ой от объекта ой." В естественном языке считается плохим стилем,когда одно и то же слово повторяется много раз. gzip хорошо сожмёт такой текст, где слово повторяется, а значит, в этом тексте много воды. Хороший стиль - это когда одно слово вводит локальный контекст и этот контекст держится некоторое (обычно небольшое) время. Такой же стиль должен быть и в хорошем языке программирования. Плюсы и ява этому (в данном аспекте) удовлетворяют.

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

Ну и в общем, лисп плох слабыми библиотеками. Я на самом деле, пытаюсь подогнать разные объяснения под это. Если бы лисп пользовался популярностью и библиотеки были сильны, я был бы менее уверен, что дело в самом языке. А так, по той ли причине, по этой ли, но лисп умирает. В общем, наверное, сама причина не особо важна, хотя нужно сделать выводы, чтобы не повторять ошибок. Что я и попытался сделать.

> den73 переходит на Python

Переходи на зелёный свет.

>Переходи на зелёный свет.

смешно считаешь?

> Ну и в общем, лисп плох слабыми библиотеками.

Лисп плох слабыми людьми. Посмотри на php или java - ничего выдающегося, поэтому доступны массам, поэтому море библиотек. Что в свою очередь, как мух на запах говна, привлекает коммерческие организации и более-менее адкватных людей (мейнстрим же!), пишущие уже нормальные библиотеки. У Лиспа его сила и слабость - это одно и то же.

>Ну и в общем, лисп плох слабыми библиотеками.

Единственное с чем согласен. Ну ещё с куцым "комьюнити".

От себя: нет compile-time анализа типов в макрах, нельзя перегружать дженерики по переменному количеству полей.

Из личного: не хватает полноценной реализации sbcl под офтопик, все остальные свободные не дотягивают по тем или иным параметрам.

Лисп плох слабыми людьми. Посмотри на php или java
java - дерьмо. php - всё же имеет божью искру. После того, как все несколько лет делали веб на перле, только один человек (и вроде даже не программист) сумел снова изобрести квазицитирование. Очевидно же, что веб-страницы удобнее делать в виде шаблонов, а не принтами печатать.
Да, у лиспа сила и слабость - это одно и то же, но в итоге, пытающийся на нём делать какой-то конечный продукт, вынужден поддерживать все библиотеки (начиная от asdf и cffi-grovel и кончая weblocks) и ещё думать, как бы срезать острые углы в самом языке. Соответственно, результата можно ждать очень долго.

>т.е., несовместимые по смыслу сигнатуры. И что, патчить чужой код?
Нет, пользоваться пакетами.
>Этот вопрос решается пакетами
Верно
>плохо разработана система модулей
Нормально, другой подход просто.
>. И главное, что в статических языках ты ОДИН раз написал тип переменной и получаешь контекст: все, что после этой переменной и точки - относится к этому типу. В лиспе такого нет.
Естественно, это же динамический язык.

Про повторения не понял, совсем. В CL мощнейшие средства для построения абстракций присутствуют - макросы, clos.
>Ну и в общем, лисп плох слабыми библиотеками. Я на самом деле, пытаюсь подогнать разные объяснения под это
http://video.google.com/videoplay?docid=-1331906677993764413
>лисп умирает
Такие далеко идущие выводы сделаны из того, что вам не понравилась система пакетов? Живее всех живых. Уже 50 лет.

> http://video.google.com/videoplay?docid=-1331906677993764413

:-D

>нет compile-time анализа типов в макрах Типизация ведь динамическая. Но можно прикрутить. >нельзя перегружать дженерики по переменному количеству полей Дык можно, см. выше. Пользоваться именованными/необязательными аргументами вместо статической перегрузки. Нельзя - по аргументам диспетчеризации. А где такое можно? >все остальные свободные не дотягивают по тем или иным параметрам OpenMCL, ECL?

> OpenMCL, ECL?

Уж лучше CLISP. SBCL хотя бы более-менее приемлемый маш.код выдаёт.

> >. И главное, что в статических языках ты ОДИН раз написал тип переменной и получаешь контекст: все, что после этой переменной и точки - относится к этому типу. В лиспе такого нет.
> Естественно, это же динамический язык.
Не знаю, насколько это естественно. И меня это не радует. На самом деле, динамически типизированный язык является частным случаем статически типизированного, если позволить переменным иметь по умолчанию тип t ( = variant). Просто наиболее популярные статические языки либо не имеют типа t вообще, либо он плохо прикостылен где-то сбоку, и поэтому эта мысль не вполне очевидна. Поскольку в лиспе есть и декларации типов и, по факту, type inference, но они плохо доступны пользователю (ещё одна проблема, к-рую упомянул и yyk), то common lisp - это просто недоделанно типизированный язык. А динамизм и динамическая типизация - вещи более-менее слабо связанные. Пример: SQL сервера. В них по факту есть defun, eval, compile и change-class, но при этом они статически типизированные.

Ладно, не будем спорить про лисп. Про него можно много говорить, спорить и т.п. Мой вывод - проще, чем подгонять под себя лисп, будет изучить питон. Т.к. в нём большая доля нужной работы сделана. А раз есть cython, то и проблемы со скоростью не настолько страшны. Поэтому, я перехожу на ПИТОН.

И вообще, мне скоро на поезд, а лодка ещё требует починки. Я пошёл отсюдова. Всех поздравляю с наступающим праздником труда и желаю поменьше труда за компьютером и провести время на природе, а не за монитором!

все эти чистые функциональные языки не нужны. не нужны и полуфункциональные языки (F# и т.д.). а нужны императивные ООП языки (C#, Java) с полезными фичами функциональных, аспектно-ориентированных и т.д. языков. разработчикам жабы надо вылезть из танка и понять, что нужно расширять функционал своего недоязычка, а не дрочить на 100% pure. в жабе много чего нужного нет. в выкидыше страуса наоборот много всего, но оно сложно и неэффективно. и чем дальше, тем хуже. гораздо приятнее иметь новый стандарт юникод С с классами без звездочек и опциональной сборкой мусора (Vala не Vala, D не D).

>>нет compile-time анализа типов в макрах

>Типизация ведь динамическая. Но можно прикрутить.

Не представляю как не переписывая пол лиспа (ну или корёжить конкретную версию - допустим sbcl, "принудительную" типизацию он очень хорошо понимает на уровне кода/функций)

>Нельзя - по аргументам диспетчеризации.

Именно это я и имел в виду. Хотя чисто теоретически и это возможно - весь CLOS на макрах, но это сколько-же "траха"...

>А где такое можно?

если учесть что "множественная диспетчеризация" и так редкость, то найти "оппонента" не более "маргинального" будет не легко... Не в курсе.

>OpenMCL, ECL?

Первый так и не удосужился посмотреть - уж не вспомню что остановило. Надо обновить воспоминания новой попыткой. Второй - много недоделок (по сравнению с sbcl) и скорость оставляет желать лучшего (или скорее у SBCL скорость кода по сравнению с другими лиспами такая, что на все остальные потом трудно смотреть :))

>Мой вывод - проще, чем подгонять под себя лисп, будет изучить питон.

Попробуй. Мне будет очень интересно, ибо именно с питона пришёл к лиспу. Правда питон так до конца и не "охватил". Но "возвращаться" нет никакого желания. Поэтому твой опыт будет очень интересен. Только не моментальный, а где-то через годик ;)

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

почему всё ещё не на главной?

>Прикольно. Обычно питонщеги делают из лиспотредов флейм, а здесь - наоборот :)

Где флейм?

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

Ну может оно ему и надо... ;)

P.S. Просьба в меня ничем не кидаться тем, кому аналогия/аллегория не понравились - сам знаю про ложь и т.д.

> Где флейм?

ВотЪ, например:

> Пожаловался человек: мол надоело в ресторанах питаться - запаришься выбирать, готовят долго, стоит люто. Хочу, мол, фастфуд попробовать: выбирать не приходится, выдают моментально, стоит копейки.

но это не значит что надо из фастфуда делать ресторан
фаст на то и фаст что не ресторан ;-)

>> Где флейм?

>ВотЪ, например:

"Нисчитацца!" Где ты флейм (т.е. цепочку из нескольких пустых постов) до своего поста нашёл?

>den73 переходит на Python

А питон тем временем потихоньку движется в сторону хаскелля, те же генераторы взять - а теперь и generator comprehensions, и map, zip от генераторов возвращают генераторы. То есть хотя бы для последовательностей они осилили ленивость и list folding - им вы еще pattern matching нормальный...

> То есть хотя бы для последовательностей они осилили ленивость и list folding - им вы еще pattern matching нормальный...

Ленивость не нужна, а вот pattern matching - хотеть!!!11

>вот pattern matching - хотеть

а что, в питоне есть ADT?

>> вот pattern matching - хотеть

> а что, в питоне есть ADT?

А что, pattern matching делается исключительно на ADT? :D

P.S. ADT - это еще и Abstract Data Types ;)

>А что, pattern matching делается исключительно на ADT? :D

да нет, конечно. просто спросил

>P.S. ADT - это еще и Abstract Data Types ;)

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

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

Это лучше, чем вообще без.

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

Такое то уже в питоне давно работает:

(a,b,c) = (1,2,3)

Я тоже рекомендую ipython -- шикарная вещь, незаменим для интроспекции
и быстрой проверки / повторения / исправления кусочков кода.
По факту интреспекции несколько hint'ов:
some_thing?<Enter>
some_thing??<Enter>
some_thing.<Tab>

Попробуйте, оно явно того стоит.

Далее, pyrex / cpython -- лично меня не устроили именно
производительностью и лишним слоем трансляции в голове. Дело в том,
что pyrex/cython это уже не питон (как это не прискорбно), но ещё не C.
Вам фактически нужно будет знать и держать в голове три языка плюс знать/
угадывать какой код из возможных позволит cython'у сгенерировать достойный
С-код. Это лишний ненужный слой. Он не упрощает процесс (как должен), а
лишь добавляет сущностей, которые Вам предстоит постоянно держать в голове.
Головы у нас не резиновые, поэтому не советую.

Я пробовал использовать cython для аккселерации готовых модулей на
python (его для этих целей и позиционируют) -- даже с принудительной типизацией всего и вся производительность очень далека от аналогичного
модуля на C. Конечно для hello world будет сопоставимая скорость
(как например в tutorial по cython, где вычисляли синус).

В общем мой выбор -- python + некоторые модули на C.

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

> Такое то уже в питоне давно работает:

> (a,b,c) = (1,2,3)

Это совсем не то. В конструкцию выбора такое не вставишь.

>Это совсем не то. В конструкцию выбора такое не вставишь.

Да не то, но сделать for с разбором по результатам zip можно...

> сделать for с разбором по результатам zip можно...

Хм, это как? Пример можно?

Для REPL ipython must have. Так как, подозреваю, привык к emacs, спешу обрадовать, есть мод для этого самого ipython.

Для всяких автодополнений есть rope и ropemacs.

P.S. Для тебя, как лиспера, есть вот такая вещь: http://peak.telecommunity.com/DevCenter/RulesReadme

P.P.S. Многих лисповых фишек будет реально не хватать, но зато сколько библиотек... Если честно, шикарные возможности Lisp уже не являются kill feature и сильно затмеваются его недостатками.

> если учесть что "множественная диспетчеризация" и так редкость, то найти "оппонента" не более "маргинального" будет не легко... Не в курсе.

Так как уверен, что лиспер не особо заинтересуется ссылкой, приведенной по поводу python (без подколок, я прекрасно понимаю мнение лисперов о python, сам от него не в восторге, но более practical сейчас походу просто нет), приведу ссылку еще раз: http://peak.telecommunity.com/DevCenter/RulesReadme

>Хм, это как? Пример можно?

Типа так:

[2*k+b for (k,b) in zip(xrange(1,5), xrange(6,10))]

Но мне больше нравится такой вариант:

map(lambda k,b: 2*k+b, xrange(1,5), xrange(6,10))

> [2*k+b for (k,b) in zip(xrange(1,5), xrange(6,10))]

Что-то я не вижу здесь pattern matching.

>Что-то я не вижу здесь pattern matching.

результат zip -> список пар, (k,b) = элементу этого списка - при этом pattern matching (его убогое подобие) раскидывает k=первый элемент пары, b = второй элемент пары.

> результат zip -> список пар, (k,b) = элементу этого списка - при этом pattern matching (его убогое подобие)

Ну это ровно то же, что и в примере с присваиванием.

>Ну это ровно то же, что и в примере с присваиванием.

Да

Что с Лором? Господа, plot please, как от:

> Ибо воистину. Первый Язык, жемчужина посреди простых камней, и нет языков кроме Него. Скобки, в которых пустота — тело Его, мистическое двуединство кода и данных — дух Его, божественная рекурсия — сердце Его. Истинно говорю вам, избегающий света Его есть безумец, вот, свершается кара над главой его, и убогостью отмечены поделия его, подобные пустым глиняным горшкам рядом с хрустальным сосудом благодати Его. Принявший же и постигший истинный свет Его подобен прямой и отточенной стреле, чисты помыслы его и крепка рука его, и благословенны творения его, дарующие радость и утоляющие печали, ибо одухотворены духом Его и отмечены благодатью Его.

-- ero-sennin ** (*) (26.09.2006 19:47:34)

дошло до %subj%? Или даже не от этого, а от vsl, DSL, ну вы поняли.

Вот в толксах пишут сводки новостей, может, кто-то не поленится и напишет коротенький рассказ, как из почти культа Лисп превратился в "мертвеца" в в-какой-то-степени-массовом сознании ЛОРа? Могла бы получиться поучительная история о разочарованиях.

> может, кто-то не поленится и напишет коротенький рассказ ...

Неоправданные ожидания. Вот и весь рассказ.

>> Ну это ровно то же, что и в примере с присваиванием.

> Да

А я подумал, что упустил какой-то эффектный трюк :/