HOWTO по написанию виртуальной машины на Common Lisp по спецификации из ICFPC-2009

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

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

А аргументированный ответ, мы, наверное, увидим после обеда?

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

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

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

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

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

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

MC>Тут скорее дело не в макросах, а в возможностях кодогенерации как таковой.

Такая возможность есть почти везде (ну кроме разве что айфона). Просто одно дело генерить напрямую биткод LLVM или там например JVM через BCEL — это сложно и потенциально взрывоопасно, и совсем другое дело использовать для кодогенерации метапрограммирование — это прозрачно, тривиально, и возможностей ошибиться на этом пути гораздо меньше.

Здравствуйте, Аноним, Вы писали:
А> Такая возможность есть почти везде (ну кроме разве что айфона). Просто одно дело генерить напрямую биткод LLVM или там например JVM через BCEL — это сложно и потенциально взрывоопасно, и совсем другое дело использовать для кодогенерации метапрограммирование — это прозрачно, тривиально, и возможностей ошибиться на этом пути гораздо меньше.

Ну например рантайм .net включает в себя компилятор c#. Т.е. часто можно просто генерить код в виде текста.
Конечно, приятнее генерить не текст, а ast. В дотнете, например, есть вроде codedom И dlr для этого (хотя я не работал с ними). Так что все, ИМХО, упирается в удобство инструментов.

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

MC>Ну например рантайм .net включает в себя компилятор c#.

С каких это пор? У них нет ещё managed компилятора, они о нём только мечтают. С Mono это ещё возможно в принципе, а в родном .NET — фигушки.

MC> Т.е. часто можно просто генерить код в виде текста.

Можно. Это тоже своего рода метапрограммирование. Но оно намного хуже того, что есть в Лиспах и прочих Немерлах, в силу сугубой однопроходности. Преобразование от виртуальной машины, от AST какого либо экзотического DSL, от комманд хитрого агентного протокола, и т.п., необходимо непременно делать в один шаг. При малейшей нетривиальности языка это становится крайне сложной и потенциально ошибкоёмкой задачей. Тогда как с метапрограммированием на макрах преобразование из DSL в целевой язык может идти во много этапов, через промежуточные языки, и каждое такое преобразование формулируется единообразно, в виде набора макр.

MC>Конечно, приятнее генерить не текст, а ast. В дотнете, например, есть вроде codedom И dlr для этого (хотя я не работал с ними). Так что все, ИМХО, упирается в удобство инструментов.

Не только "удобство", но и вообще адекватность. Инструмент, требующий чрезмерно сложной кодогенерации, приводит к серьёзным ошибкам, неизбежно. Я уж не говорю о стоимости разработки с неадекватным инструментом.

Здравствуйте, Аноним, Вы писали:
MC>>Ну например рантайм .net включает в себя компилятор c#.
А> С каких это пор? У них нет ещё managed компилятора, они о нём только мечтают. С Mono это ещё возможно в принципе, а в родном .NET — фигушки.
А при чем тут managed-компилятор? Виндоз\Microsoft.NET\Framework\Версия\csc.exe.

С остальным спорить не стану.

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

MC>А при чем тут managed-компилятор? Виндоз\Microsoft.NET\Framework\Версия\csc.exe.

Ну и какая это на фиг часть рантайма? На ASP.NET хостинге за него не подёргаешь. На пользовательском компьютере с голым framework, без SDK — тем более. С тем же успехом можно и на наличие gcc на пользовательской машине рассчитывать.

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

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

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

MC>>А при чем тут managed-компилятор? Виндоз\Microsoft.NET\Framework\Версия\csc.exe.

А> Ну и какая это на фиг часть рантайма? На ASP.NET хостинге за него не подёргаешь. На пользовательском компьютере с голым framework, без SDK — тем более. С тем же успехом можно и на наличие gcc на пользовательской машине рассчитывать.

http://msdn.microsoft.com/en-us/library/microsoft.csharp.csharpcodeprovider.aspx
Assembly: System (in System.dll)

Я полагаю, что на наличие System.dll можно рассчитывать.

а csc.exe — не совсем компилятор. Это его command-line оболочка, на сколько мне известно.

Здравствуйте, Аноним, Вы писали:
А> Ну и какая это на фиг часть рантайма? На ASP.NET хостинге за него не подёргаешь. На пользовательском компьютере с голым framework, без SDK — тем более. С тем же успехом можно и на наличие gcc на пользовательской машине рассчитывать.
Это как раз в голом FW без sdk. Как он дружит с asp (в плане наличия привилегий на запуск) — хз.

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

S>http://msdn.microsoft.com/en-us/library/microsoft.csharp.csharpcodeprovider.aspx
S>Assembly: System (in System.dll)

Он вызывает csc.exe

S>Я полагаю, что на наличие System.dll можно рассчитывать.

А вот на работоспособность CSharpCodeProvider без SDK — нельзя. Он исключение кинет, что мол "csc.exe не найден".

S>а csc.exe — не совсем компилятор. Это его command-line оболочка, на сколько мне известно.

Сам компилятор полностью unmanaged.

И частью framework-а не является.

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

А> И частью framework-а не является.

Ха. А я таки облажался. Он всё же идёт с framework. А с ASP.NET не работает как раз таки благодаря ограничениям на security.

Но в любом случае — решение неюзабельное, важно, что не работает, а не почему оно не работает.

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

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

S>>http://msdn.microsoft.com/en-us/library/microsoft.csharp.csharpcodeprovider.aspx
S>>Assembly: System (in System.dll)

А> Он вызывает csc.exe

S>>Я полагаю, что на наличие System.dll можно рассчитывать.

А> А вот на работоспособность CSharpCodeProvider без SDK — нельзя. Он исключение кинет, что мол "csc.exe не найден".
Честно, говоря, не пробовал удалять csc.exe

S>>а csc.exe — не совсем компилятор. Это его command-line оболочка, на сколько мне известно.

А> Сам компилятор полностью unmanaged.
Да, известный факт. Ну и что что unmanaged.

А> И частью framework-а не является.
Является.
Не уверен, является ли он частью .NET Framework Client Profile.

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

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

А>> И частью framework-а не является.

А> Ха. А я таки облажался. Он всё же идёт с framework. А с ASP.NET не работает как раз таки благодаря ограничениям на security.

А> Но в любом случае — решение неюзабельное, важно, что не работает, а не почему оно не работает.
Почему же, очень даже юзабельное. Область приложения framework несколько шире, чем ASP.NET.

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

TBG>HOWTO по написанию виртуальной машины на Common Lisp по спецификации из ICFPC-2009

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

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

А>> Но в любом случае — решение неюзабельное, важно, что не работает, а не почему оно не работает.
S>Почему же, очень даже юзабельное. Область приложения framework несколько шире, чем ASP.NET.

Ага, вот поюзает его кто-то, от широты души, а потом мне его код из ASP.NET дёргать.

Не, я предпочитаю простые и надёжные методы — System.Reflection.Emit и Лисп с макрами поверх него.

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

К слову о dsl на макрах. Чем дальше семантика dsl от семантики самого лиспа — тем ближе набор макров будет к традиционному компилятору. Так что я немного не разделяю лисподиферамбов в этой ветке.

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


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