Здравствуйте, Mr.Cat, Вы писали:

А>> Не, я предпочитаю простые и надёжные методы — System.Reflection.Emit и Лисп с макрами поверх него.
MC>Какую имплементацию лиспа используешь для дотнета?

Свою собственную, специально для кодогенерации писанную.

MC>К слову о dsl на макрах. Чем дальше семантика dsl от семантики самого лиспа — тем ближе набор макров будет к традиционному компилятору.

Это не совсем и не всегда так. Можно очень далеко уйти от Лиспа (то есть, от eager application, и т.п.) инкрементально добавляя макры. А чем больше языковых фичей (в том числе и с очень другой семантикой), тем проще делать каждую новую фичу, просто преобразуя её к комбинации существующих. А если и целевых языков более одного, например, кроме Лиспа можно (пользуясь теми же S-выражениями) и более низкоуровневые языки описывать — то вообще любой язык можно из одних только макр сделать.

Это ровно то же, что и компиляция, да. Только проще. Вместо AST и всяких там визиторов мозголомных — тупое и прямолинейное указание, как конкретную конструкцию разворачивать, а уж когда разворачивать — это компилятор Лиспа разберётся.

Ну а на случай, когда простыми макрами всё же сложно пользоваться — тут можно и специальный язык для описания и AST, и преобразований сделать. Как вот здесь, например:

http://www.meta-alternative.net/calc.pdf (отсюда: http://lambda-the-ultimate.org/node/2895)

Можно и ещё проще сделать, и мощнее — Лисп бесконечно гибкий.

Здравствуйте, cadet354, Вы писали:

А>> Правда, всегда можно таскать компилятор от Mono в виде dll, если уж так хочется генерить код именно на C# (не вижу, однако, никаких причин, почему такие странные желания могли бы у кого либо возникнуть).
C>попробуй Linqpad, станет понятно зачем это надо.

Посмотрел. Всё равно не понял. Это же всё ещё C#. Далеко не лучший скриптовый язык. Linq хорош, но вокруг всё тот же тяжеловесный C# остаётся.

Здравствуйте, Turtle.BAZON.Group, Вы писали:

DM>>Спасибо! Теперь я точно не стану использовать лисп на таких задачах.
TBG>А аргументированный ответ, мы, наверное, увидим после обеда?

Что ж, обед прошел, аргументы простые: по сравнению с моим решением на Окамле тут кода сильно больше, а скорость на порядок ниже. Подозреваю, что скорость можно улучшить, но тогда код еще втрое больше станет.

Здравствуйте, Аноним, Вы писали:

DM>>Спасибо! Теперь я точно не стану использовать лисп на таких задачах.

А> А зря. На Лиспе, например, очень легко можно написать эффективный компилятор для любой ВМ, используя одни только макры. На языке без макр это будет очень и очень сложной задачей, или придётся ограничиваться тормозным интерпретатором.

Пока это лишь слова. На деле придется выбирать: или "очень легко", или "эффективный". В примере топикстартера не похоже, что компиляция/кодогенерация вообще имела место — ускорение получилось как при простой замене инструкций на выполняющие их лямбды. А итоговая скорость в 4-5 раз ниже "тормозного интерпретатора" на языке со статической типизацией. Т.е. пока что я вижу контрпример — "ВМ на лиспе писать можно, но получается медленно и громоздко".

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, cadet354, Вы писали:

А>>> Правда, всегда можно таскать компилятор от Mono в виде dll, если уж так хочется генерить код именно на C# (не вижу, однако, никаких причин, почему такие странные желания могли бы у кого либо возникнуть).
C>>попробуй Linqpad, станет понятно зачем это надо.

А> Посмотрел. Всё равно не понял. Это же всё ещё C#. Далеко не лучший скриптовый язык. Linq хорош, но вокруг всё тот же тяжеловесный C# остаётся.
ты не понял, так кроме линка можно писать код, на обычном C#.

Здравствуйте, D. Mon, Вы писали:

А>> А зря. На Лиспе, например, очень легко можно написать эффективный компилятор для любой ВМ, используя одни только макры. На языке без макр это будет очень и очень сложной задачей, или придётся ограничиваться тормозным интерпретатором.

DM>Пока это лишь слова.

Это практический опыт.

DM> На деле придется выбирать: или "очень легко", или "эффективный".

Прелесть Лиспа как раз в том и заключается, что выбирать не надо. За эффективность компилятор Лиспа отвечает — его много лет много людей писали. Зачем их труд повторять? Мы просто преобразуем код VM в код на Лиспе. Макрами. Проще уж и вовсе некуда. Такой компилятор намного проще любого интерпретатора.

DM> В примере топикстартера не похоже, что компиляция/кодогенерация вообще имела место

К сожалению, я не имел возможности посмотреть на его пример — ссылка не работает.

DM> — ускорение получилось как при простой замене инструкций на выполняющие их лямбды. А итоговая скорость в 4-5 раз ниже "тормозного интерпретатора" на языке со статической типизацией.

Это претензии к конкретной реализации. Если там просто интерпретатор — тогда это не интересно. Это не lisp way.

DM> Т.е. пока что я вижу контрпример — "ВМ на лиспе писать можно, но получается медленно и громоздко".

Можно в разы быстрее, чем на OCaml. Разве что у MetaOCaml появится native backend — тогда только и будет смысл с Лиспом в эффективности тягаться.

Здравствуйте, cadet354, Вы писали:

А>> Посмотрел. Всё равно не понял. Это же всё ещё C#. Далеко не лучший скриптовый язык. Linq хорош, но вокруг всё тот же тяжеловесный C# остаётся.
C>ты не понял, так кроме линка можно писать код, на обычном C#.

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

Здравствуйте, D. Mon, Вы писали:
DM>Пока это лишь слова. На деле придется выбирать: или "очень легко", или "эффективный".
Соглашусь. При использовании макросов целевой язык будет лиспом, т.е. при реализации сабжевой vm таким образом мы получим преобразование:
низкоуровневый язык -макросы-> высокоуровневый язык -имплементация лиспа-> низкоуровневый язык.
Вполне очевидно, что среднее звено часто стоит исключить.

Хотя для высокоуровневых dsl макросы часто хороши.
Вообще, мне кажется, что имплементация некоего языка (vm) должна по возможности выполняться на языке более низкого уровня, а если ниже уж некуда — то на чем-то типа C.

Здравствуйте, Mr.Cat, Вы писали:

MC>Вполне очевидно, что среднее звено часто стоит исключить.

Естественно. Потому и говорю, что очень полезно иметь в Лиспе встроенный низкоуровневый язык, чтоб он был целевым языком для таких преобразований. Например, был такой muLisp под MS DOS — там можно было вообще ассемблер встраивать.

MC>Вообще, мне кажется, что имплементация некоего языка (vm) должна по возможности выполняться на языке более низкого уровня, а если ниже уж некуда — то на чем-то типа C.

Язык самих макр не обязательно должен совпадать с целевым языком — и в этом вся сила Лиспа и есть. Я тут приводил уже примеры.

Здравствуйте, Аноним, Вы писали:
MC>>Вообще, мне кажется, что имплементация некоего языка (vm) должна по возможности выполняться на языке более низкого уровня, а если ниже уж некуда — то на чем-то типа C.
А> Язык самих макр не обязательно должен совпадать с целевым языком — и в этом вся сила Лиспа и есть. Я тут приводил уже примеры.
Кто ж спорит-то?
Я немного неточно выразился. Под "имплементация некоего языка" имел в виду "интерпретация на" или "компиляция в".

Здравствуйте, Аноним, Вы писали:

А> За эффективность компилятор Лиспа отвечает — его много лет много людей писали.

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

A>Зачем их труд повторять? Мы просто преобразуем код VM в код на Лиспе. Макрами. Проще уж и вовсе некуда. Такой компилятор намного проще любого интерпретатора.

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

Здравствуйте, D. Mon, Вы писали:

DM>Плохо писали, видимо.

Не очень уж и плохо. SBCL весьма шустрый.

DM>Вроде, ТС так и сделал.

Страница всё так же недоступна. Не могу посмотреть.

DM> Получилось плохо — не проще интерпретатора и не сильно быстрее (в полтора раза всего).

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

Mr.Cat пишет:

> А> А зря. На Лиспе, например, очень легко можно написать эффективный
> компилятор для любой ВМ, используя одни только макры. На языке без макр
> это будет очень и очень сложной задачей, или придётся ограничиваться
> тормозным интерпретатором.
> Тут скорее дело не в макросах, а в возможностях кодогенерации как таковой.

Безусловно. Но кодогенерация на (комон) лиспе доведена до совершенства,
почему бы её не использовать ? Код может генерировать код, который может
генерировать код, который может генерировать код ...

И так до бесконесности. И всё будет лисп. Почему бы и нет ?

Здравствуйте, frontsquat, Вы писали:

F>А ссылка рабочая? Сейчас что-то нет.

Возникли проблемы с сетью. Ссылка временно нерабочая. Надеюсь, это быстро будет исправлено.

Здравствуйте, Аноним, Вы писали:

А> Можно в разы быстрее, чем на OCaml. Разве что у MetaOCaml появится native backend — тогда только и будет смысл с Лиспом в эффективности тягаться.

Для подобных вещей и camlp4 достаточно.

Здравствуйте, FR, Вы писали:

FR>Для подобных вещей и camlp4 достаточно.

MetaOcaml все же по смыслу ближе к лиспу — на нем можно специализировать функции в рантайме, а camlp4 — это все же компайлтайм. В версии 3.11 у окамла появилась нативная подгрузка кода, поэтому теперь теоретически нативному MetaOcaml'у ничего не мешает быть. Но на практике я его не щупал, а без этого это тоже лишь слова.

Здравствуйте, FR, Вы писали:

А>> Можно в разы быстрее, чем на OCaml. Разве что у MetaOCaml появится native backend — тогда только и будет смысл с Лиспом в эффективности тягаться.

FR>Для подобных вещей и camlp4 достаточно.

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

Здравствуйте, D. Mon, Вы писали:

DM>MetaOcaml все же по смыслу ближе к лиспу — на нем можно специализировать функции в рантайме, а camlp4 — это все же компайлтайм.

Рантайм или время компиляции — без разницы. В Лиспе макры во время компиляции раскрываются, а не во время исполнения. Важно, что с MetaOCaml можно многоуровневые макры делать, а camlp4 должен породить валидный OCaml с первого же прохода.

DM> В версии 3.11 у окамла появилась нативная подгрузка кода, поэтому теперь теоретически нативному MetaOcaml'у ничего не мешает быть. Но на практике я его не щупал, а без этого это тоже лишь слова.

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

Так что если так хочется метапрограммирование, но в статически типизированном языке, то выбирать придётся между Template Haskell и Nemerle.

D. Mon пишет:

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

Зачем он в лиспе-то ?

Здравствуйте, MasterZiv, Вы писали:

MZ>Зачем он в лиспе-то ?

Чтобы пример из первого поста (уже доступен, кстати) работал не 30 секунд, а 3, и при этом не надо было раздувать код аннотациями типов. Вот зачем.