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

Взаимную же рекурсию, которая сплошь и рядом в настоящем ФП, это дерьмо никак оптимизирует.

На взаимную рекурсию там другой костылик есть %)

А криков-то было. Интерпретатор нипричёёооом, эвал-вен убер аллеееес! %)

Алло, они и в CL так вычисляются. Ты не понял сути. Еще раз перечитай сообщение Хики.

Компилятор не дает тебе гарантии как и сколько раз макросы раскроются

Компилятор не дает тебе гарантии как и сколько раз макросы раскроются

Ну вот, допустим, ты упоролся и хочешь при раскрытии макроса сходить в сеть, получить жсон со списком сигнатур функций, нагенерировать по нему собственно функций и положить ссылки на них в какую-то структуру данных (оставим за кадром вопрос, что мешает сделать это в рантайме — см. условие №1). Что мешает тебе во время раскрытия этого макроса проверять состояние запроса и наличие данных, не отправлять повторные запросы и возвращать сразу готовую структуру при повторном раскрытии?

Небольшие проекты на питоне писать легко и приятно.

Проблема Питона в том, что питонясты не ограничиваются небольшими проектами.

API для AST (по сути там ерунда) и разрешить писать функции, возвращающие этот самый AST

https://docs.python.org/3/library/ast.html

питонщики же как-то живут вообще практически без метапрограммирования

Просто питон настолько гибок, что в 99% случаев оно там ненужно. Но если нужно - есть ast, есть декораторы, есть фп и функции как перворанговые объекты - при необходимости можно сделать из питона в этом смысле практически лисп, тока лучше:-)

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

Там можно вставить в произвольное место (в том числе внутри функции) eval(process_ast(b + c)), чтобы функция process_ast на вход приняла выражение plus(identifier("b"), identifier("c")) и вернула произвольный AST, которым бы eval заменился? В том числе объявить новые переменные, использовать другие переменные из области видимости и тд.

Насчёт конкретно там не уверен, но вообще в питоне можно.

практически лисп, тока лучше:-)

Когда наконец напишешь на петоне функцию unless, которая делает то же, что if, только наоборот — поговорим %)

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

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

Похоже, это просто программирование.

делает то же, что if, только наоборот

В питоне от рождения есть операция not и скобочки. Ваш К.О.

Некоторые задачи не решают не потому что они неразрешимы, а потому что они идиотские.

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

Любая перегрузка операций меняет семантику. Можно поменять настройки так, что алгебраическое выражение будет приезжать в виде ast допускающего замены, конвертацию в другие форматы и пр.

Некоторые задачи не решают не потому что они неразрешимы, а потому что они идиотские.

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

Любая перегрузка операций меняет семантику

Если определение новых функций — это метапрограммирование, то что тогда обычное программирование?

Насколько я понимаю, программирование — это описание вычислительного процесса по заранее определённым (автором интерпретатора) правилам. Определение новых функций автором языка петон предусмотрено.

А метапрограммирование — это возможность изменения и дополнения этих правил (изменение самого интерпретатора). Скажем, управление порядком вычисления аргументов функции. Такой возможности в языке петон нет.

Где петон, а где метапрограммирование.

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

Гомоиконных языков меньше десятка и половина из них - диалекты/дети лиспа. Остальные используют интроспекцию. Поэтому сводить метапрограммирование только к гомоиконности имхо - неверно.

А метапрограммирование — это возможность изменения и дополнения этих правил.

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

Плюсовые шаблоны это метапрограммирование?:-)

По умолчанию операция + возвращает сумму, но я могу её перегрузить так, что она будет возвращать разность - это не метапрограммирование?

ИМНО метапрограммирование это любое программирование дающее в итоге программу а не данные.

Получение ast и его модификация это не гомоиконность?

По умолчанию операция + возвращает сумму, но я могу её перегрузить так, что она будет возвращать разность - это не метапрограммирование?

Можно и так.

У меня можно полям и объектам назначить динамически (в т.ч. в run-time) семантику любой сложности.
run-time использует её.

Получение ast и его модификация это не гомоиконность?

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

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

В этом смысле гомоиконность это инстроспекция+прямой доступ к ast. У гомоиконности есть правда ещё требования к синстаксису…

monk - где заканчивается интроспекцмя и начинается гомоиконность?:-)

В этом смысле гомоиконность это инстроспекция+прямой доступ к ast.

Нет, гомоиконность лежит на уровень ниже так сказать.

Вообще, гомоиконность Lisp это его побочный эффект из-за «бедности» возможностей во времена его создания. А макросы это буквально суть лиспа, нет макросов нет диалектов в том виде что мы их знаем, ведь всякие setq, defun и даже if - это все макросы.

Ну я например использую

ifch(expr1, cond1, expr2, cond2, epxr3...)

причём эта штука конвертится в разные ЯП в зависимости от, включая LaTeX.

Вполне себе метапрограммирование…

Т.е. гомоиконность это когда мы можем взять фрагмент исходного кода as is и че то с ним учудить без доп.преобразований?

Гомоиконность это когда код может быть данными и наоборот без изменения AST, т.е. структура кода и AST имеют одинаковое представление. Буквально, структура кода в этом случае является и структурой данных.

самомодифицирующийся код через интроспекцию

генераторы кода это тоже метапрограммирование

Неписаное Правило Лора №21: на десятой странице срача можно уже сходить и посмотреть наконец определение.

И действительно, общепринятый смысл термина «метапрограммирование» — это оперирование программами как данными: модификация, генерирование и так далее. Программы высшего порядка. Ну как функции высшего порядка, только программы.

Лисповые макросы, выходит, только частный случай — интерпретатор модифицирует сам себя.

Ну так под это определение и питоньи скачки с ast вполне подходят…

Ну как функции высшего порядка, только программы.

Именно так, лучше и не сказать.

Лисповые макросы, выходит, только частный случай

Да, лисп использует один из самых расово верных методов реализации метапрограммирования, но этот метод все еще один из.

Ну так под это определение и питоньи скачки с ast вполне подходят…

Из меня плохой объяснятор. Вот именно питоньи скачки с AST и определяют что это не гомоиконность, а интроспекция.

monk - где заканчивается интроспекцмя и начинается гомоиконность?:-)

гомоиконность == структура, написанная в коде, равна структуре, возвращаемой интроспекцией.

Гомоиконность это когда код может быть данными и наоборот без изменения AST

Кстати, является ли гомоиконной Scala?

val quotedMethod = q"def add(nr: Int) = nr + 30"

и Scheme с её #'(code ast)

Автокомплит и детальная подсветка синтаксиса (а не просто ключевых слов).

В Racket эту проблему решили. DrRacket делает частичное раскрытие макросов + при раскрытии макроса отслеживается источник куска кода.

Но других таких примеров не вспомню.

Кстати, является ли гомоиконной Scala?

Вот тут мне сложно ответить, она может сувать AST в переменную, но меня все равно клонит к «частичной гомоиконности» хотя такого термина не существует.

и Scheme

Scheme однозначно - да. Как и Clojure.

Куча макросов имеет сайд-эффекты (def макросы по определению сайд-эффектят — модифицируют текущее окружение, это смысл вообще их существования) и никто не делает из этого драмы

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

def-like макросы — это первый случай и тут по уместности сайд-эффектов ни у кого возражений нет — это обычный кот, которому всё можно. Со вторым немного сложнее — мнения сходятся на том, что там сайд-эффектов надо бы избегать. Но если очень надо… то можно. В крайнем случае спрячем их в eval-when и сделаем вид, что их не было %)

в питоне есть гомоиконность?:-)

Проблема макросов не в сайд эффектах, вернее это не главная проблема.

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

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

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

меня все равно клонит к «частичной гомоиконности» хотя такого термина не существует.

Скажем гомоиконность есть для алгебраических выражений, но её нет для циклов и условий. Обычное дело…

Да, можно сказать что он «местами гомоиконен». Имхо, Scala это попытка скрестить теплое с мягким, сразу из двух парадигм черпают полной ложкой и пытаются выстроить кадавра. Это естественный процесс объединения знаний, но чет пока не задалось также как с объединением ОТО и квантовой механики.

Когда наконец напишешь на петоне функцию unless, которая делает то же, что if, только наоборот — поговорим %)

if – не функция. Вполне можно написать конструкцию

with unless(cond()) as c:
  func1()
  funс2()

в которой функции func1 и func2 выполняются только при ложном результате cond().

Или можно написать макрос

with unless:
  cond() # первое выражение трактуем как условие
  if_false1()
  if_false2()
  ...
  else   # символ else трактуем как разделитель
  if_true1()
  if_true2()
  ...

if – не функция

Да лаааадно? %)

Да лаааадно? %)

Да. Это макрос, кек.

if not - 6 символов unless - 6 символов но как же сущности без необходимости?

Я тоже решил пойти к определению. И к списку примеров. И теперь я вообще ничего не понимаю. У них к гомоиконным относятся Java и C# и меньше относится Tcl…

В общем, термин понимает кто как: кто-то приравнивает к наличию «eval», кто-то к программе в виде списка элементов.

в питоне есть гомоиконность?:-)

Если использовать https://macropy3.readthedocs.io/en/latest/ , то есть:

@macros.expr
def expand(tree, **kw):
    return q[lambda x: x * ast_literal[tree] + 10]

меня все равно клонит к «частичной гомоиконности» хотя такого термина не существует

Англоязычные придумали слабую гомоиконность для такого.

К ней, в частности, относится Common Lisp, потому что в нём есть макросы чтения.

Англоязычные придумали слабую гомоиконность для такого.

weakly homoiconic (term invented for this page)

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

А я подозревал что там такой же бардак как с типизацией:-)

Спасибо!

Так а нахрена тогда Хикки взял S-выражения за основу для языка?

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

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

емаксе все для лиспа с макросами прекрасно кастомизируется

Емакс бы ещё с виндой дружил получше, цены бы не было.

Народ по привычке всё это думает, что раз с виду (синтаксически) похоже на лисп, значит лисп.

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

Емакс бы ещё с виндой дружил

Нет в тебе ни на грош стратегического мЫшления. Тут ведь надо соблюсти тонкий баланс — с одной стороны, емаксом на венде ты должен мочь пользоваться, чтобы подсесть на его благодать, но при этом должен немного страдать, чтобы иметь мотивацию в конце концов с венды спрыгнуть.