Лисперы, что я делаю не так?

> Вопрос не в том что можно сделать. Вопрос в maintainability макросов.

Да нет никакого вопроса. Макросы более легко поддерживать, чем что либо еще. Ровно по той же причине, по которой language oriented programming позволяет делать более читабельный и простой в поддержке код, чем всякие там ООПы.

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

> о убежден в том, что символьные вычисления - это операции
> над типом symbol в Лиспе

Так и не ознакомился Common Lisp: A Gentle Introduction to Symbolic Computation и «LISP 1.5 Programmer's Manual»? Ну да, ты же с традицией и терминологией, принятой в Common Lisp вообще не знаком.

> Просто интересно мнение людей которые пользуют лисп и

всяко-разно мета-макро-прочее.

Просто имей в виду, что бред этого анонимуса не имеет никакого отношения к реальной практике программирования на Common Lisp.

> Просто интересно мнение людей которые пользуют лисп и всяко-разно мета-макро-прочее.

Тогда лучше запрашивай ссылки на реальные проекты, которые используют все эти мета- и макро. Альтернативно, тебе придется поверить, что «любое иное решение всегда менее элегантно» (с) (r) (tm).

> Так и не ознакомился Common Lisp: A Gentle Introduction to Symbolic Computation и «LISP 1.5 Programmer's Manual»?

Идиот, ну какой идиот! Тебе еще раз объяснить, почему это совершенно нерелевантно, и почему это именно ты не осилил этих текстов, а не наоборот?

Ну да, ты же с традицией и терминологией, принятой в Common Lisp вообще не знаком.

Я на Common Lisp писал, когда ты писал в пеленки, так что не надо тут ля-ля.

> Просто имей в виду, что бред этого анонимуса не имеет никакого отношения к реальной практике программирования на Common Lisp.

Да нет, это бред быдлокодера archimag-а, который всякое веб-говно ваяет, никакого отношения к практике не имеет.

А вот книга Зибеля «Practical Common Lisp» имеет к практике самое непосредственное отношение. Книга Грэма «On Lisp» - тоже самое непосредственное. И слушать надо их, а не быдлокодера-формошлепщика.

На кой ему эти ссылки спрашивать, когда он их сам надавал тут - Mathematica, Maxima. Можно Axiom добавить, как еще более яркий пример.

Да, а ты уже убедился, что Лисп - это алгебра? Или все еще упорствуешь?

> На кой ему эти ссылки спрашивать, когда он их сам надавал тут - Mathematica, Maxima. Можно Axiom добавить

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

мне интересно, когда уже этот селюк-похапист архимаг вылезет за пределы своих уеб-хелловорлдов и попробует написать что-то хотя бы такого уровня:
http://github.com/Lovesan/doors (в т.ч. COM-интероп)
но без злых страшных и вредных макросов

боюсь что никогда.

вообще, советую всем этого смешного дурака игнорировать либо просто посылать подальше

Maxima и Axiom, оказывается, уже «закрытые»?

Или «старье»? Ну тогда посвежее код: https://github.com/jolby/rincanter

Ну или вот, показательный пример: http://formpluslogic.blogspot.com/2010/04/clojure-macros-make-me-happy.html

> А вот книга Зибеля «Practical Common Lisp» имеет к практике
> самое непосредственное отношение.

Открою страшный секрет - Peter Seibel изучал CL прямо во время написания PCL и судя по его открытому коду пишет на CL довольно посредственно (на фоне лучших современных образцов). Никакой достой библиотеки мы от него до сих пор не получили. Он уже давно писатель, а не программист.

> http://github.com/Lovesan/doors

Ну что, у тебя уже получилось показать треугольник в окне? А то за столько лет мы видели пока только треугольник и окно, по отдельности, надо в конце концов двигаться дальше и показать нам треугольник в окне - это будет прорыв.

А «не посредственно» пишет, конечно же, вебобыдлокодер архмаг?

> Ну тогда посвежее код: https://github.com/jolby/rincanter

Нашел там 6 defmacro, 19 строк в общем. Или в Clojure макры определяются через defn?

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

Под «макросы надо использовать осторожно» как раз и подразумевалось, что следует использовать макросы только в том случае, если они простые и процесс макроэкспанда достаточно прозрачен. «Сложные» макросы тоже, вообще говоря, писать можно (и даже нужно), но только тогда, когда есть поддержка со стороны языка, в CL же даже обработку ошибок придется делать руками от начала и до конца.

> Ну или вот, показательный пример: http://formpluslogic.blogspot.com/2010/04/clojure-macros-make-me-happy.html

Страница с кодом макроса выдает 404. И, насколько я понял, это такая же вебель, работу с которой ловсанчег ставит в вину архимагу %)

http://github.com/Lovesan/doors

Почерк Lovesan уже за километр почувствовал, но теперь уже можно точно утверждать кто из-под анонимуса партизанит.

> А «не посредственно» пишет, конечно же

Nikodemus Siivola, Stelian Ionescu, Nathan Froyd, Hans Hübner и т.д. Я до их уровня ещё не добрался, но работаю над этим.

> Грэм не зря утверждает, что макры должны составлять около 20% от всего кода.

Ну Грэм тут совсем не авторитет, достаточно вспомнить Arc. Зачем-то руками писал реализацию с нуля, на которую без слез глядеть нельзя, когда можно было сделать буквально несколько макросов поверх хост-языка и добиться того же эффекта.

> Под «макросы надо использовать осторожно» как раз и подразумевалось, что следует использовать макросы только в том случае, если они простые и процесс макроэкспанда достаточно прозрачен.

А они всегда должны быть простые. Зачем нужны вообще сложные, когда все можно и нужно делать просто?

«Сложные» макросы тоже, вообще говоря, писать можно (и даже нужно), но только тогда, когда есть поддержка со стороны языка, в CL же даже обработку ошибок придется делать руками от начала и до конца.

Зачем это может быть нужным писать сложные макросы? Вместо одного сложного можно написать цепочку из простых.

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

> Вопрос не в том что можно сделать. Вопрос в maintainability макросов.

Заведомо не хуже, чем у обычных средств.

Ты сейчас на уровне пыхпыхокодера, который зачем-то взялся за Лисп. Возвращайся лучше обратно на пыхпых.

Подозреваю, что это не лавсан.

З.Ы. Совершенно другой аноним.

> Ты сейчас на уровне пыхпыхокодера, который зачем-то взялся за Лисп.

Думаю, не тебе об этом судить.

Возвращайся лучше обратно на пыхпых.

Просто к сведению - я никогда не писал PHP, хотя и отношусь к успехам PHP-программистов (не языка) с большим уважением.

Ну давай посмотрим на код этого Nathan Froyd: https://github.com/froydnj/binascii/blob/master/format.lisp

И что мы видим? Очень плохо написанная, громадных размеров макра, которая должна была быть сделана в виде трех-четырех отдельных макр. Ну и кумиры у тебя.

Мне, мне судить, кому же еще.

Но почему на практике не выливается?

Потому что пишут юнит тесты? Сам с таким сталкивался - в цепочке конструкторов забыл один конструктор (элементарно отслеживается системой типов) и отследил это только в юнит тесте (благо решил их написать). И так постоянно. Для любой большой системы это проблема. Для того же SBCL (с точки зрения того как он сделал) это одна из проблем - очень весело выявлять причину «NIL is not INTEGER» в такой большой системе (а падать из-за этого в кору ещё веселей :)). Другая проблема это отсутствие в языке ориентированности на вложенные типы данных - там в основном графы высокой вложенности, если построить их более менее правильно ещё можно, то дотягиваться до отдельных объектов приходится вручную (defun ... (node) и дальше такая кауча let-ов которая тянется куда-то далеко по аккессорам), тогда как паттерн-матчинг избавил бы от множества проблем.

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

> Зачем это может быть нужным писать сложные макросы? Вместо одного сложного можно написать цепочку из простых.

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

> Подозреваю, что это не лавсан.

Это по любому он, ведь никто бы другой не стал ссылаться на эту «разработку». Другое дело, что в треде присутствует и другой старый «друг» (всё есмь АЛГЕБРА, ну или типа того).

> Подозреваю, что это не лавсан.

Думаю, здесь отписались как минимум 2 анонима, один из которых - не ловсанчег.

> Ну да, можно, но только не в CL - там нету никаких средств, которые бы позволяли протягивать некоторый контекст во время макроэкспанда и гибко управлять им,

Неявный контекст не нужен. А явный протягивается элементарно через аргументы макр.

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

Гигиена - ЗЛО. Она сразу же уничтожает практически весь потенциал макросов.

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

Да не проще. Сложнее. Ты просто не понимаешь, как это делать.

А ты все еще утверждаешь, что Лисп это не алгебра? Ты все еще так и не прочитал Чейтина?

> Потому что пишут юнит тесты? Сам с таким сталкивался - в цепочке конструкторов забыл один конструктор (элементарно отслеживается системой типов) и отследил это только в юнит тесте (благо решил их написать).

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

очень весело выявлять причину «NIL is not INTEGER» в такой большой системе (а падать из-за этого в кору ещё веселей :)).

А зачем выявлять-то? Тебе сразу напишет где эта ошибка и откуда она. Это же не статика, где ошибка может быть указано совершенно не в том месте, где она находится по факту, благодаря тому, что проверка делается в рантайме, мы получаем абсолютно точную и достоверную информацию. В статике такое никогда не будет возможно.

тогда как паттерн-матчинг избавил бы от множества проблем

Ну паттерн-матчинг есть.

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

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

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

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

> Неявный контекст не нужен.

В том и дело, что нужен, иначе никакого дсл ты не напишешь.

Она сразу же уничтожает практически весь потенциал макросов.

С какой стати? Гигиена как раз позволяет писать сложные поддерживаемые макры. Кроме того, все, что можно написать без гигиены - можно написать с гигиеной, причемн не сложнее. Но не наоборот.

Да не проще. Сложнее.

Проще, проще.

> Потому что SBCL показать место ошибки может только в тривиальных случаях.

для CL нету отладчиков чтоли?

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

Будет запущен код в котором есть, скажем так, «недопустимая дорожка», например эффект при котором в арифметическое выражение попадает NIL и такой код будет работать нормально до тех пор пока control flow не пойдёт по этой дорожке - во время прохождения юнит-теста, или в продакшене (мы же не будем отрицать наличия элементарных багов в продакшене). Т.е. есть класс «недопустимых дорожек» который нужно покрыть юнит тестами, мне странно слышать, что это всегда и везде выполнимо. При наличии системы типов у нас сразу отсекается подкласс этого класса (в том числе и что-то, что не получилось покрыть юнит-тестами).

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

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

А зачем выявлять-то? Тебе сразу напишет где эта ошибка и откуда она. Это же не статика, где ошибка может быть указано совершенно не в том месте, где она находится по факту, благодаря тому, что проверка делается в рантайме, мы получаем абсолютно точную и достоверную информацию.

Ну вот на практике мы видим это самое «NIL is not INTEGER» и малоинформативный стек вызовов (если речь о SBCL). Причём видим это не сразу при запуске системы а в совсем произвольное время после. Если мы говорим о ошибках типов, то как раз компилятор с системой типов в таком случае напишет очень хорошее и информативное сообщение - что как и почему.

В статике такое никогда не будет возможно.

Что «такое»? Как будто в языках со статической типизацией нет системы рантайм ошибок рядом с этими статическими ошибками (которые верифицируются). Другое дело, что нет рестартов, но это уже немножко другое.

Ну паттерн-матчинг есть.

Нету его :) Миллионы кода написаны на ANSI Common Lisp, наличие где-то полусырой библиотеки ничего не меняет. Кстати, нормальной реализации я не видел - всё потому что отдельно «паттерн-матчинг» не представляет собой ценности, он только одна сторона медали (или даже грань куба), а реализовать всё вместе и чтобы было как родное достаточно сложно.

При наличии системы типов у нас сразу отсекается подкласс этого класса (в том числе и что-то, что не получилось покрыть юнит-тестами).

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

А ты все еще утверждаешь, что Лисп это не алгебра?

А Си - алгебра?

> Будет запущен код в котором есть, скажем так, «недопустимая дорожка», например эффект при котором в арифметическое выражение попадает NIL и такой код будет работать нормально до тех пор пока control flow не пойдёт по этой дорожке

Такое (когда ошибка в типах на одной редковыполняемой дорожке) на практике практически не встречается. 99% ошибок, которые статика отлавливает, ловятся на первом же запуске. Я уж не говорю о том, что качество кода, в котором такие ошибки возможны, вообще очень сомнительно - получается семантика кода такова, что тип возвращаемый ф-ей существенно зависит от control-flow, причем неким нетривиальным способом. Но так ведь не пишут.

Т.е. есть класс «недопустимых дорожек» который нужно покрыть юнит тестами

Да нету этих дорожек фактически. Не секрет, что подавляющее большинство ф-й принимает/возвращает конкретные типы, а не «может строку может число». «Может строку может число» - встречается, конечно, и в нем нету ничего слишком уж необычного, но нетривиальная зависимость типа от потока исполнения - это уже что-то реально из ряда вон выходящее.

Ну вот на практике мы видим это самое «NIL is not INTEGER» и малоинформативный стек вызовов (если речь о SBCL).

Ну если для CL действительно нету отладчиков, которые могут тыкнуть палцьем - то ок (хотя непонятно, почему их нет, если нет).

Нету его :)

Ну как нету - если есть?

Кстати, нормальной реализации я не видел

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

ЗЫ: Это уже третий раз, когда мы говорим с тобой о статической типизации и аргументы все те же. Ты говоришь о существовании некоего класса ошибок, которые пройдут до продакшена в динамике и не пройдут в статике, я упираю на то, что этот класс есть, но он чрезвычайно узок и возможность его покрытия статикой не стоит профитов динамики. Предлагаю остановиться на том, что ответ на этот вопрос существенно зависит от рассматриваемой задачи (высокая/низкая цена ошибки, польза «эксклюзивных» методов динамики при решении конкретной задачи и т.п.).

Я видел несколько реализаций ML поверх Лиспа, полностью на макрах сделано.

ссылки!

Предлагаю остановиться на том, что ответ на этот вопрос существенно зависит от рассматриваемой задачи (высокая/низкая цена ошибки, польза «эксклюзивных» методов динамики при решении конкретной задачи и т.п.).

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

Про паттерн-матчинг тут два момента - востребованность и реализация. Как мы видим - востребованности никакой (ни в каких проектах не используется). Насчёт реализаций - везде начинают плясать от самого паттерн-матчинга (в arnesi определяются конкретные матчеры которые работают на основе CPS (вместо генерации кода), в fare-matcher всё то же, только на основе генерации кода). Тогда как нужно начинать с ADT - паттерн-матчинг это просто одно из многих применений. А именно, всё что можно сказать о любом алг. типе укладывается в цепочку высказываний о принадлежности одних множеств другим, такой язык:

universes ::= U | U' | U'' | ...
set-prod  ::= set [ × set-prod ]
set-expr  ::= set | set-prod | universes
in-expr   ::= set-expr [ ∈ in-expr ]
expr      ::= in-expr [expr]

  например

Boolean ∈ U
True    ∈ Boolean
False   ∈ Boolean

ℕ  ∈ U
0  ∈ ℕ
+1 ∈ ℕ × ℕ

ℤ  ∈ U
0  ∈ ℤ
-1 ∈ ℤ × ℤ
+1 ∈ ℤ × ℤ

List ∈ U
Nil  ∈ List
Cons ∈ U × U ∈ List

(->) ∈ U × U

Functor ∈ U'
map ∈ (->) × U × U

т.е. узкое подмножество логики первого порядка. Любое определение структур, классов или ADT это уже более высокоуровневое представление, которое сводится к этому. Далее, на основе этих _высказований_ можно делать много разных вещей - генерировать функции чтения/печати, функции отображений/свёртки/обхода, использовать эту информацию в generic алгоритме вложенного паттерн-матчинга и т.п. (type check может быть аналогом прувера в логике, но он плохо укладывается в такую схему).

Вот кстати в SBCL есть некоторое подобие такой схемы - при определении defclass/defstruct определяется метаинформация о классах/классоидах (в MOP) и потом компилятор использует эту информацию для оптимизаций, причём оптимизации подобны тем что делают компиляторы с системами типов (например, compile-time подстановка аккессора, ещё немного и можно было бы подставлять методы в compile-time (ad-hoc полиморфизм времени компиляции, как в классах типов, вместо runtime диспетчеризации, которая делается сейчас)).

Правильной реализацией было бы определение нужной метаинформации в defclass/defstruct, непосредственный defdata (который может хоститься на структурах) и виртуальный defdata, чтобы добавлять эту информацию (без создания конструкторов и аккессоров) к существующим уже примитивам вроде cons. Причём всё это должно быть в стандарте :)

Я уж не говорю о том, что качество кода, в котором такие ошибки возможны, вообще очень сомнительно - получается семантика кода такова, что тип возвращаемый ф-ей существенно зависит от control-flow, причем неким нетривиальным способом. Но так ведь не пишут.

Представь, что программа это граф - вершины (функции и спец. формы) имеют несколько входов (аргументы) и несколько выходов (значения). Всё будет хорошо до тех пора пока какой-либо элемент графа не потеряется. Стиль тут ни причём, просто обычная человеческая невнимательность. Вот система типов занимается тем, что раскрашивает этот граф и не даёт пройти неправильно раскрашенным вариантам - средство борьбы с семантическими ошибками, вызванными этой невнимательностью.

>На кой ему эти ссылки спрашивать, когда он их сам надавал тут - Mathematica, Maxima. Можно Axiom добавить, как еще более яркий пример.

Кто мешает Аксиому и творения рукожопых обезьян?1 Слава Отцу Нашему, язык аксиомы и рядом не лежал с сраным лиспом. То, что он был реализован на лиспе и транслируется в него для компиляции только говорит о том, насколько лисп убог для целей компьютерной алгебры.

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

>Ты все еще так и не прочитал Чейтина?

Хайтин он, Хайтин.

> Clojure

Да-а-а. Собрался Емакс для Clojure настроить - таких километровых простыней-инструкций я еще не видел. Причем их таких много и они все разные.

Тем не менее, кто-то сослался.

Я тут, в этом треде, первое сообщение пишу, если что.

«разработки» _в_кавычках_ - это как раз твои веб-поделки.
А я пишу реально полезные штуковины. Понимаешь, ты конечно, можешь сидеть на своем линупсе и дрочить на светлое будущее веба, но пока у лиспа не будет нормальной инфраструктуры на винде, то есть пока у него, как минимум, не будет нормальных интерфейсов к API винды, он так и будет никому, кроме кучки маргиналов, не нужен.

Я, например, уже наполовину запилил COM-интероп(наполовину потому, что IDispatch пока нет). Что такое COM, напоминать тебе, дурику красноглазому, надо?

Во-первых, COM на винде присутствует в подавляющем большинстве API - от ODBC до DirectX; всё мультимедиа, всё gui(особенно новое, типа Ribbon) - на COM.

Во-вторых, с COM-интеропом будет возможность использовать кучу существующих компонентов, в т.ч. написанных на .NET.

В-третьих, можно будет писать свои компоненты. Среди прочего, COM дает возможность обойти трудности с созданием разделяемых библиотек на CL(через out-of-process серверы):
http://love5an.livejournal.com/365354.html

Но, естественно, моя библиотека не только про COM. Вообще, она про человеческий интерфейс к базовому Windows API. Без такого интерфейса, писать на лиспе под винду что-либо серьезное - невозможно. Это не только к винде относится, естественно - вы вон, дурики красноглазые, со своей недоделанной iolib носитесь по всему интернету, только свист стоит.



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

> А я пишу реально полезные штуковины

Без вопросов. Хотя один всё же есть - сколько ещё лет должно пройти, прежде чем от этих реально полезных штуковин появится наконец какая-нибудь реальная польза?