Занимаясь веб-девелопментом

> Но это плохой пример, давай лучше (АТД -> генерирует функцию-катаморфизм избавленную от страшных рекурсий) покажи

да, это хороший пример, и там, можно сказать, случится облом

но учти, я за ридеровские макры или че-то похожее

tl;dr

пожалей свое время

Мне почему-то очевидно, что непустое

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

только попозже или завтра

я за ридеровские макры или че-то похожее

И мнение не хочешь поменять? Как я выше уже написал - ридеровские макросы это хук на read позволяющий определять _любые_ пользовательские процедуры чтения (тект -> термы), обычные макросы - хук на eval (или compile) позволяющий определять _любые_ пользовательские процедуры трансформации (терм -> терм). Т.е. какая разница? Чем хук на read круче хука на eval/compile? По момему просто два разных инструмента.

доказательства

Вот, для меня это o_0 потому что «очевидно» это как «и слону понятно», никак не «доказательство». Ну ладно, посмотрю - если напишешь.

не доказательство, а наборосок оного; и вообще это снова откладывается

> Как я выше уже написал - ридеровские макросы это хук на read позволяющий определять _любые_ пользовательские процедуры чтения (тект -> термы), обычные макросы - хук на eval (или compile) позволяющий определять _любые_ пользовательские процедуры трансформации (терм -> терм). Т.е. какая разница? Чем хук на read круче хука на eval/compile? По момему просто два разных инструмента.

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

хотя на самом деле там вовсе не текст -> термы, а допустим текст -> AST

терм -> терм это безусловно harmful

компилятор это тоже делает, допустим при оптимизации, но лезть туда грязными лапами категорически воспрещается; если, допустим, нужен «открытый фреймовк для оптимизации», то там будет немного посложнее, чем просто макросы, т.к. 1. преобразования некоммутативны 2. граф применения преобразований часто неограничен или очень велик, и нужны эвристики для последовательности применения

че-то я смотрю, народ в дискуссии не участвует, может нам в жаббер перенести ее?

че же там стоит после стрелки вместо термов — весьма важный вопрос

в лиспе необходимость *иметь* возможность «все интрпретировать» приводит к тому, что там ниче кроме термов не может быть; но современные компилируемые языки в такую модель не вписываются и требуют более сложную (и имхо более удобную программисту)

Что-то я смотрю градус бреда в этой теме уже превышает всякие пределы.

в лиспе необходимость *иметь* возможность «все интрпретировать» приводит к тому, что там ниче кроме термов не может быть;

И где эта необходимость прописана? А то вот SBCL нихрена об этой необходимости не знает, и до недавнего времени вообще интерпретатора не имел.

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

CL - самый современный компилируемый язык. В нем компиляция аж в стандартную библиотеку включена.

Может хватит уже нести бред, совершенно не разбираясь в предмете(в CL)?

хотя на самом деле там вовсе не текст -> термы, а допустим текст -> AST

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

терм -> терм это безусловно harmful

Макротрансформации это ранняя стадия призваная работать с AST как с данностью. Т.е. мы восстановили AST из текста (и не забыли про макросы чтения) мы поработали с AST (макросы, т.е. ввели себе специальные формы, например - нет в CL средства инкрементальной компиляции систем, а мы строим ASDF и определяем макрос defsystem - удобную специальную форму для определения систем, и все довольны).

компилятор это тоже делает, допустим при оптимизации, но лезть туда грязными лапами категорически воспрещается;

Привильно, defmacro вовсе туда и не лезет. Оно даёт работать с AST, оно даёт притянуть сюда «оптимизации», в смысле того что мы что-то упростили в AST, или что-то сгенерировали из DSL (как у swizard-а, в соседней теме было). В SBCL есть и более позние формы, определяющий трансформации - define-source-transformation, deftransform, defoptimizer, def-ir1-transform (примерно, по памяти) и так далее - вот это уже действительно internals и лезть туда нужно только при соответсвующей необходимости.

А то вот SBCL нихрена об этой необходимости не знает, и до недавнего времени вообще интерпретатора не имел.

Интерпретатор там был с самого начала - ещё в CMU CL. И одним из нововведений форка (~ 10 лет назад) была не интерпретация, а компиляция форм в top-level по умолчанию. Это как раз на тему - иногда бывает удобнее интерпритировать (eval как интерпретирующая процедура - CL на CL), а иногда компилировать (eval как интерфейс к компилятору, который строит отбражения CL кода в терминах регистрово-стекового вычислителя). Там на этот счёт как раз есть *параметр*.