Что круче: Лисп или Хаскелль?

> Макры в CL тупые и примитивные. Писать их корректно не проблема вообще.

Макросы в CL нельзя писать корректно вообще - по-этому это, конечно, не проблема - раз писать так нельзя, то никто и не пишет. Можешь на досуге попробовать написать корректный aif (который не будет шадовить внешние локальные биндинги it).

шадовить внешние локальные биндинги

Что, простите?

Макросы в CL нельзя писать корректно вообще

Тупица, штоле? Можно. Я ж пишу.

Можешь на досуге попробовать написать корректный aif (который не будет шадовить внешние локальные биндинги it).

А мне это на хер не упало. Меня устраивает такая семантика. Она корректна ровно до тех пор, пока пользователь осведомлен о подобном поведении.

Тем более что мне и не нужно определять такого рода макры, не вижу в них смысла. Макры полезны для написания компиляторов eDSL-ей, а не для всяких дебильных конструкций типа того же уродливого LOOP.

И если бы мне вдруг (ну, головой бы стукнулся, например) потребовалось подобную херню сделать, то я написал бы что-то вроде

(defmacro aif (it-test-form then-form &optional else-form)
  (match-format ittest-form
    ((it test-form)
       `(let ((,it ,test-form))
          (if ,it ,then-form ,else-form))))

Если же кому-то нужно неявное связывание it - то бить его по наглой морде, пусть себе валит обратно в C, там для него специально всякие дебильные break придуманы.

> Качество чего?

Кода. Чего же еще?

Попробуйте разбить проект на несколько библиотек и начать менять макросы то здесь, то там.

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

Надоест очень быстро.

До сих пор не надоело.

Вообще на таком уровне может рассуждать только тот, кто ничего серьёзней «Hello world» не писал.

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

А мы без тебя не догадались...

Судя по коду, который кложурасы да и большая часть CL-оунов пишет - не догадываетесь.

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

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

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

Каких к бесам «интерфейсов»? Ты просто тупо не понимаешь вообще, о чем говоришь.

А в остальной «динамщине» приходится себя вести несколько по-другому.

А в CL я могу этим мелким eDSL-ам приделать такую систему типов, какую захочу. И семантику expand-а могу изменить так, как захочу. Надо будет проверять корректность склейки - буду проверять, без каких либо дополнительных телодвижений. Например, если надо из eDSL генератора парсеров выдавать корректный AST - проверю корректность, тем же самым Хиндли-Милнером, которым ты так гордишься в своем хаскеле.

> Потому что декомпозиция на мелкие, простые и понятные функции использует примитивы самого языка. Функцию можно передать аргументом. На функцию можно навесить хук. Функции можно добавить контракты.

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

В функции можно прохинтить типы. Макрос - это последняя инстанция, последняя остановка.

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

Чего ты не можешь делать с макросами, что мешало бы полноценной декомпозиции?

Всем, кто ни хера не понимает про макросы, настоятельно рекомендую подробно изучить все, что связано с Term Rewriting Systems. Очень сильно просветляет, знаете ли.

Тоже как мантру читаешь?

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

> Только этим и занимаюсь постоянно. Проблем не было.

Неужно используете XCVB? Потому что иначе проблемы гарантированны. Либо вы мазохист и просто не обращаете на них внимание.

Ты хоть программировать научись сначала, да?

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

Вообще, что за манера постоянно разную дезинформацию и собственную тупость в массы нести?

> Term Rewriting Systems.

Извините, вы та самая АЛГЕБРА?

> Что, простите?

(let ([i 10]) (aif #t it it))

должно быть 10

>А в CL я могу этим мелким eDSL-ам приделать такую систему типов, какую захочу.

::Зевает:: Сколько раз я это слышал... Но ни разу не видел... Тем более вариантов System F на CL.

> Тупица, штоле? Можно. Я ж пишу.

Ну если тебе _кажется_ что твои макросы корректны - это на значит, что они корректны.

А мне это на хер не упало. Меня устраивает такая семантика. Она корректна ровно до тех пор, пока пользователь осведомлен о подобном поведении.

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

И если бы мне вдруг (ну, головой бы стукнулся, например) потребовалось подобную херню сделать, то я написал бы что-то вроде

Так и запишем: «корректные анафорические макросы на CL писать нельзя». Ок, одно из самых выразительных средств метапрограммирования исключили.

Макры полезны для написания компиляторов eDSL-ей

Можно пример такого eDSL?

> А в CL я могу этим мелким eDSL-ам приделать такую систему типов, какую захочу.

Прикрутить систему типов к языку не так просто. При чем если это именно eDSL, а не DSL - ты НЕ прикрутишь, потому что не сможешь типизировать выражения самого CL. Типизировать можно только подмножество CL.

>Но вы не будете так любезны продемонстрировать что-либо из своего творчества?
Чувствую, сейчас в треде появятся ссылки на doors и virgil. Кто же еще может так брызгать слюной по поводу убермакросов.

Не должно. Ни в Scheme, ни в CL.

> Неужно используете XCVB?

А оно как-то позволяет не перекомпилировать файлы, в которых макрос использован, после того, как этот макрос в другом файле переопределен? Или хотя бы автоматом производит их перекомпиляцию после C-c C-c на макросе?

>Верую, мол, что макры невозможно отлаживать, верую, что как не пиши, а простыня получится - и плевать на реальность.
Глаза протри. Я говорю о том, что макросы нужно использовать трижды подумав и рассмотрев другие варианты. Я не говорю, что их не нужно использовать.
Аргументы чем функция лучше макроса я уже привел.

Не должно. Ни в Scheme, ни в CL.

Должно, вопрос только в том. Как сделать, чтобы так было. Вообще - это побочный продукт, скажем так, суть тут в следующем:

(module m racket
  (require aif)
  (provide macro)
  
  (define-syntax-rule (macro test x)
    (aif test it x)))

(module m2 racket
  (require 'm)

  (define it 10)
  (macro #t it) ; -> #t
  (macro #f it) ; -> 10
)

Другими словами - мы спокойно используем macro и нам не надо знать, что там где-то aif в недрах, все будет работать корректно. Это становится особенно важно, когда несколько макросов вводят одну и ту же анафору, но в разных значениях, при чем сама эта анафора - анафорический макрос.

(не удержался, встрял)

Ну да, «Turing tarpit», вид сбоку. Как много раз мы уже слышали эти аргументы: «на c/фортране/ассембли можно написать компилятор CL/Haskell/чего угодно».

В том-то и беда, что такие вещи (например типизация, полноценные продолжения а-ля схемы, гигиена и т.п. — вынесем за скобки вопрос нужности) не встраиваются в язык. Приходится писать свой компилятор в подможество CL, с tree-walk и прочим.

То, что на CL (шире: на лиспе вообще) весьма удобно писать компиляторы, и то, что DSL (не eDSL!) на лиспе не выглядит настолько гетерогенно, сути дела не меняет.

Оно позволяет получить корректный образ после пересборки, asdf без чистки fasl-файлов обеспечить этого не может.

Или хотя бы автоматом производит их перекомпиляцию после C-c C-c

на макросе?

XCVB это система сборки. Таким просто не занимается. А вопрос вообще тёмный. Истинной «горячей замены кода» в CL нет. Я после серьёзных изменений обычно просто перезапускаю систему, иначе хрен что проконтролируешь, но это, конечно, требует времени и не очень удобно.

> ::Зевает:: Сколько раз я это слышал... Но ни разу не видел... Тем более вариантов System F на CL.

Ну система типов Qi, вообще говоря, намного мощнее System F.

А может быть потому что не прошло достаточно времени?

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

> криво-непонятный код

Очевидно же, он сейчас скажет, что на ЯП без статической типизации любой код - криво-непонятен.

эх, вот теперь может и не скажет :)
а мне так хотелось поднять себе настрой петросяном

>Ну система типов Qi

Ну Qi как бы сдох... Да и не жил он особенно.

Ну, судя по всему, не сдох (если судить по сообщениям).

имеется ввиду применение shadow

Ага, и не дает гарантий по завершаемости тайпчекера? Зато какая мощная система типов!

>если судить по сообщениям

По каким сообщениям? Я значит от жизни отстал.

http://www.reddit.com/r/lisp/

по сообщениям смотри

В лучшем случае Qi это зомби от рождения, ибо оказался нах никому не нужен.

Из вышеприведенной странички следует, что он кому-то нужен. Зачем так категорично. И над Shen работают - http://www.lambdassociates.org/News/july11/index.htm

>А в CL я могу этим мелким eDSL-ам приделать такую систему типов, какую захочу. И семантику expand-а могу изменить так, как захочу. Надо будет проверять корректность склейки - буду проверять, без каких либо дополнительных телодвижений. Например, если надо из eDSL генератора парсеров выдавать корректный AST - проверю корректность, тем же самым Хиндли-Милнером, которым ты так гордишься в своем хаскеле.

Теоретически - можешь. Практически - это все равно что половину компилятора какого-нибудь ML реализовать.

> Из вышеприведенной странички следует, что он кому-то нужен.

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

> Ну Qi как бы сдох... Да и не жил он особенно.

Вам шашечки или ехать?

> Практически - это все равно что половину компилятора какого-нибудь ML реализовать.

Ну тайпчекер - это самая простая часть компилятора, так тчо не половину, а скорее 1% :) проблема в том, что на лисп та же System F не налезет.

Ах, да - еще очень интересный вопрос, как типизировать макросы - до экспанда или после него?

>Ну тайпчекер - это самая простая часть компилятора, так тчо не половину, а скорее 1% :) проблема в том, что на лисп та же System F не налезет.

Ну, да. Но речь то шла о eDSL. Вот и получается, что нужно будет писать транслятор недоML в лисп на лиспе.

> Ну тайпчекер - это самая простая часть компилятора, так тчо не половину, а скорее 1% :)

Люблю анонимусов за крутизну их немеряную. Вот читаю такое и понимаю - есть куда расти, есть.

> Люблю анонимусов за крутизну их немеряную. Вот читаю такое и понимаю - есть куда расти, есть.

Тайпчекер той же System F занимает пару сотен строк от силы, причем алгоритм есть в книжках. Если для тебя переписать 200 строк из книжки - немереная крутизна, то ок.

> Тайпчекер той же System F занимает пару сотен строк от силы, причем алгоритм есть в книжках. Если для тебя переписать 200 строк из книжки - немереная крутизна, то ок.

Если ты считаешь, что переписывания алгоритма из книжки хватит, то ок.

> Вот и получается, что нужно будет писать транслятор недоML в лисп на лиспе.

Это, опять же, тривиальная задача. Проблемы начнутся, когда мы захотим вызывать типизированный/нетипизированный код друг из друга.

> Если ты считаешь, что переписывания алгоритма из книжки хватит

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

>Это, опять же, тривиальная задача. Проблемы начнутся, когда мы захотим вызывать типизированный/нетипизированный код друг из друга.

С таким подходом все тривиальное. И где же хваленая простота написания eDSL на лиспе?

> С таким подходом все тривиальное.

Ну описать для ДСЛ грамматику и оттранслировать код - тривиально, а вот все остальное (собственно, самая важная часть) - уже нет.

Ее слишком громко хвалили - она смутилась и так и не появилась :)
p.s. правда, если не «простота», то «значительное упрощение» в случае нормального понимания CL таки видится.

И где же хваленая простота написания eDSL на лиспе?

Embedded DSL в CL как раз нефиг делать писать. Если у вас другое мнение, то докажите его правоту.

> Embedded DSL в CL как раз нефиг делать писать.

Конечно, вот пример: iterate.lisp. А если кому-то кажется, что это код не так уже прост и ясен, то он сам дурак.

Конечно, вот пример: iterate.lisp. А если кому-то кажется, что это код не так уже прост и ясен, то он сам дурак.

У меня используются edsl с терминами всего по полстраницы.

> У меня используются edsl с терминами всего по полстраницы.

Ну ладно, iterate в конце то концов это излишество, навороченная версия совсем уж тривиального loop.lisp.

У меня большая просьба к тем, кто знает как писать полезные eDSL просто и ясно - ну расскажите об этом кому-нибудь, ну хоть тем же разработчикам SBCL, сразу куча профита для простых смертных будет.

А вот в iterate написано, что (for i from 1 to 10) это

(initially (setq i 0))

(for i next (if (> i 10) (terminate) (incf i)))

То есть проверка на то, окончился ли наш секвенс производится непосредственно в месте расположения (for ...) формы. А если мы возьмем (for var in-stream ...) то доступ к следующему элементу мутабелен. если у нас

(for var in-stream stream1)

(for var in-stream stream2)

допустим, второй поток заканчивается до первого. если завершение работы iter будет в месте второй формы (for ...) то к этому моменту будет уже извлечен лишний элемент из stream1. Оно действительно так работает?