[Clojure] Кодогенерация

Можно ли в результате получить jar, не зависящий от кложуровских либ?

lein uberjar

Можно ли в результате получить jar, не зависящий от кложуровских либ

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

Если нет, то какова толщина необходимых рантайм-библиотек?

Сложный вопрос. Всех — 3.4MB. Необходимых — зависит от приложения.

a * b + c

Парсер такого уровня берется из туториалов. Кодогенератор такого уровня тоже берется из туториалов.

Если тебе Clojure нужен как макрогенератор (виртуально)машинного кода а-ля CL, то такой фичи в Clojure нет.

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

Парсер такого уровня берется из туториалов.

Парсер есть на JavaCC. К нему особых претензий нет, так что, думаю, его я трогать не буду.

Интересует компилятор AST -> байт код.

Если тебе Clojure нужен как макрогенератор (виртуально)машинного кода а-ля CL, то такой фичи в Clojure нет.

А можно поподробнее, пожалуйста? А то я в лиспах не санчопансо.

Если тебе нужна нотация а-ля S-выражения - юзай JSON.

Да не, не особо.

Нужно:

1. компилятор

2. возможность определять фунции для разных жабских числовых типов данных в общем виде.

Интересует компилятор AST -> байт код.

ну и возьми asm, там есть «low level» древовидный AST, дальше - сам

возможность определять фунции для разных жабских числовых типов данных в общем виде.

ну как напишешь свой компилятор - так и будет :)

ну и возьми asm, там есть «low level» древовидный AST, дальше - сам

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

Интересует компилятор AST -> байт код.

Я никогда не рещал подобные задачи, тем более на яве. Твой парсер генерирует нужный AST. Библиотека генерации байт-кода, либо сама жрет этот AST, либо в процессе обхода дерева ей помогает твоя программа, вызывая нужные методы на нужных узлах дерева.

Попробуй сначала генерировать нужный байт-код без обработки AST. У явских библиотек для манипуляции байт-кодом своя кривая обучения.

А можно поподробнее, пожалуйста?

Одной из особенностей CL, ради которой его стоит вообще рассматривать как технологию, является возможность в т.ч. и динамической генерации машинного кода. Разными способами, начиная от самого обычного штатного «компилятора», заканчивая DSL, очень похожим на ассемблер.

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

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

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

Кстати, о птичках. Я чего-то забыл, что есть ABCL. И он даже в последнее время развивается :))

А clojure так не умеет? Я на это надеялся.

Можно ли в результате получить jar, не зависящий от кложуровских либ?

Нет принципиальной невозможности такого. Некоторые IDE могут вытаскивать требуемые приложению классы из библиотечных JAR и запаковывать их вместе с файлами классов приложения.

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

Опять статикосказки.

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

Опять статикосказки.

Опять лиспокомплексы?

Как еще лиспокомплексы? Я знаю только о статикокомплексах, из-за которых люди начинают скакать ебанашками по форумам и в каждом посте убеждать окружающих, что без системы типов даже в хелловорлде будут принципиально необнаруживаемые ошибки из разряда «сложили жирафов с носорогами».

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

А clojure так не умеет? Я на это надеялся.

По крайней мере у меня не получилось. Правда с моего последнего знакомства прошло достаточно много времени... А Clojure очень быстро развивается.

У динамической типипзации есть очевидные минусы

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