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

DM>> В архиве некий компилятор, который, используя готовый фреймворк,

А> ровно тот же самый Лисп. Любой Лисп таким фреймворком работать может.

Т.е. в любом Лиспе из коробки уже есть

# Natural abstract syntax trees support
# Efficient AST visitors' DSL
# Advanced pattern matching
# Embedded Prolog
# Various .NET type system oriented tools
# Easy to use lexing and parsing DSLs
# Trendy PEG/Packrat implementation
# Automatic generation of syntax highlighting and pretty-printing for every user-defined language

?

А> В MSIL компилируется уже сам Лисп. Точно так же, если бы это было на SBCL, то "большой готовой библиотекой", которая компилирует это промежуточное представление, был бы сам SBCL. Потому как весь "компилятор" завёрнут в макру, которая разворачивает ML в Лисп и подставляет в месте вызова макры.

А, так понятнее. А в решении из первого поста не так сделано, кстати?

DM>>PS. Похожие компиляторы мини-МЛ на окамле (см. Programming Language Zoo и MinCaml) выглядят лаконичнее и читабельнее, причем не используют больших фреймворков, скрывающих еще бабиллионы строк кода.

А> Каких таких фреймворков? Там только лисповские макры. И я бы посмотрел на более лаконичную реализацию Хиндли-Милнера, чем компиляция в Пролог.

Выше процитированы. И пролог тоже еще реализовать надо. Или он в любом лиспе есть встроенный?

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

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

А>>> Как будто в Лиспах нет pattern matching-а. Есть, и погибче даже, чем в OCaml.

T>>"Погибче" не означает "поудобней". А также это не означает "побезопасней".
А> Про безопасность соглашусь. Но за безопасность приходится платить жестокостью системы типов. А удобство — это уже дело субъективное.

Вполне объективное.

T>>Здесь присутствуют два бывших Лисповика, vshabanov и lomeo, оба покинули его и из-за невозможности нормального сравнения с образцом в том числе.
А> Интересно было бы послушать, чего именно им не хватило.

Ошибки вылезали. Система не отлавливала расхождений между создателем структур и их приёмником.

T>>Где эта реализация, на которую надо посмотреть?
А> Ранее в этой теме была ссылка.

Ранее в этой теме

Автор:
Дата: 12.08.09

не было ссылки.

А>>> Примитивный, но эффективный (потому что всё же компилятор).
T>>Похоже, что Lisp используется, как RTL в gcc.
А> Не совсем. RTL низкоуровневый и фиксированный. А Лисп можно специализировать под промежуточное представление для весьма сложных языков.

Это частности, если не вдаваться в подробности.

RTL тоже разные бывают.

T>>А если мы ML в gcc странслируем, получится эффективней, или примитивней?
А> Сложнее получится. И он не будет embedded.

Как часто нужен встроенный транслятор?

T>>Здесь не было. Где было-то?
А> Было-было.

Не было. Если было, то я хотел бы увидеть, где.

T>>Перечисли, пожалуйста, "удобные вещи", которые можно быстро добавить в Лисп и тяжело добавить в программу на Хаскеле.
А> Ну, например, систему типов. Как, например, в Qi II. Да, да, в Хаскелле уже есть одна, знаю. А я вот другую хочу. Как мне её поменять, не меняя языка?

Сменив язык?

Как в Лиспе решается вопрос с совмещение систем типов?

Как у фортеров с EXEC — "здесь типизируем, а вот здесь не типизируем", или, все же, по-другому?

А> Или, например, Пролог встроить хочу. Чтоб эффективно в WAM компилировался.

Monadic constraint programming?

T>> Если не сложно, то укажите альтернативные варианты и оцените их трудоемкость по написанию и использованию.
А> Альтернативный вариант — Template Haskell. Но у него свои сложности и ограничения есть. И я не уверен, что там всё в порядке с интроспекцией определений типов — давно в последний раз с ним играл.

Ценность метапрограммирования сильно преувеличена.

T>>Я не очень понимаю на словах.
T>>Нельзя ли кода кусочек?
А> Ок, завтра пришлю простенький Лисп, сделанный на TH.

Отлично.

А>>> А на Java ещё больше, чем на всём остальном, вместе взятом. Это не показатель.
T>>Но не языков.
А> Именно языков. Из свежачка, например — Guru.

Отлично. Idris/Ivor, Epigram, Agda2. Старенький Cayenne.

T>>Видимо, это оптимум, sweet spot. И быстро, и безопасно.
А> Соглашусь, что это оптимум по скорости разработки и безопасности. Лисп — оптимум по скорости разработки и эффективности результата.

Как определена "эффективность результата"?

T>>Вот именно. Здесь Хаскель рулит. Хочешь — добавляй свою фичу и поддерживай её.
А> А я не хочу. Меня не тянет копаться в разжиревших чрезмерно за последние годы потрохах GHC. И уж тем более поддерживать каждую нужную мне фичу вечно. Я хочу фичи добавлять точно так же, как пишутся библиотеки. И не трогать компилятор языка.

Большей частью они библиотеками и добавляются.

Почему я и сказал, что ценность метапрограммирования преувеличена.

T>>Поэтому вопрос: software transactional memory для лиспа есть?
А> CL-STM, например.

par/pseq?

Склейка вычислений (rewrite rules)?

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

DM>Вариант на С++, очевидно, виндовый (писал для себя, поэтому кроссплатформенность целью не была). А окамловый требует extLib, сорри.

Ну вот... Так всегда. Хотя для окамла теперь, когда знаю как называется, нашёл либу, но ошибка та же.

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

DM>Т.е. в любом Лиспе из коробки уже есть

Зачем из коробки, когда есть http://www.cliki.net/

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

DM>А, это да. Вот и интересно увидеть всю хваленую эффективность. А то пока что не видно.

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

Оригинальная копипаста примерно такая:

LISPеры <...> пользуются технологией «ленивого программирования», аналогичной lazy evaluation.
При этом программа не пишется, а сразу объявляется написанной. Фактическое формирование кода программы должно происходить при первом непосредственном обращении к ней, но поскольку никто не обращается, код тоже не формируется.
Благодаря этому LISP разработчики экономят много времени, которое могут с пользой использоваться для эффективного троллинга.

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

DM>>Т.е. в любом Лиспе из коробки уже есть

А> Зачем из коробки, когда есть http://www.cliki.net/

Мне было сказано, что никакие дополнительные фреймворки/библиотеки не нужны, нужен только сам лисп:

DM> В архиве некий компилятор, который, используя готовый фреймворк,
A> ровно тот же самый Лисп. Любой Лисп таким фреймворком работать может.
A> Каких таких фреймворков? Там только лисповские макры. И я бы посмотрел на более лаконичную реализацию Хиндли-Милнера, чем компиляция в Пролог.

T>>>Тогда как примитивный ОКамл на Лиспе потребует гораздо больше работы.
А>> Не гораздо. Два-три часа максимум. Конкретнее — чуть больше тысячи строк кода с комментариями выходит.

T>А это будет "примитивный" или "эффективный" вариант?

T>Где бы на это посмотреть?

Да что там смотреть? Mincaml — реализация подмножества окамла на окамле. С оптимизирующим компилятором для SPARC.
Около пятисот, что ли, строк. http://min-caml.sourceforge.net/index-e.html

Так что нашли чем похваляться. Около тысячи строк, блин. ML-и вообще очень простые для разбора языки.
Грамматика ml-подобных языков на Language Zoo занимает пару экранов максимум в ocamlyacc-файлах.

На camlp4 можно сделать компиляцию в AST окамла, поиметь семантические проверки нахаляву и сгенерить нативный код.
Или тоже самое, но при помощи биндингов к LLVM, примеры, кстати есть. Так что вообще непонятно, чем тут меряются.

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

А> Ну вот, например — аляповатый но примитивный компилятор ML на Лиспе:
А> http://www.meta-alternative.net/MBaseML.zip

Хм. Какой-то он неюзабельный: нет оптимизации хвостовой рекурсии и нет цикла for, т.е. поэтому цикл на 100000 итераций уже не получается сделать. А на таком коде просто умирает, разбрасывая кишки:

let repeat n f =
 let rec loop i =
   if (i `eq` n) then () else
     begin f (); loop (i+1) end in
 loop 0;;
 
repeat 10 (function ()-> () );;

repeat:: number -> ( unit -> 'alpha) -> unit
Exception (EMIT_ERR_P2 (class ("cZ152074_Z152098" NestedPublic) (extends
?:Meta.Scripting.AltClosure) (implements ?:Meta.Scripting.AltClosure1)
(field "f0" ?:System.Object (Public)) (constructor ("make" (Public HideBySig)
(Standard) (?:System.Object)) (Ldarg_0) (Call ?:Void .ctor()) (Ldarg_0)
(Ldarg_1) (Stfld (field f0)) (Ret)) (method ("run" (Public) (Standard)
?:System.Object (?:System.Object)) (local obj_1 ?:System.Object) (Ldnull)
(Ldarg_1) (Ldarg_0) (Ldfld (field f0)) (Newobj (method cZ152074_Z152090/make))
(Stloc (var obj_1)) (Ldloc (var obj_1)) (Castclass (class cZ152074_Z152090))
(Dup) (Ldloc (var obj_1)) (Stfld (field cZ152074_Z152090/f0)) (Pop) (Ldloc
(var obj_1)) (Ldc_I4 0) (Box ?:System.Int32) (Tailcall)
(Call ?:System.Object call_generic__1(System.Object, System.Object)) (Ret)))
"Выдано исключение типа \"Meta.Scripting.MBaseException\"." (INNER IN2
"cZ152074_Z152098" (EMIT_ERR_MTD_I "run" (EMIT:NOTFOUND cZ152074_Z152090
in clshash) ((local obj_1 ?:System.Object) (Ldnull) (Ldarg_1) (Ldarg_0)
(Ldfld (field f0)) (Newobj (method cZ152074_Z152090/make)) (Stloc (var obj_1))
(Ldloc (var obj_1)) (Castclass (class cZ152074_Z152090)) (Dup) (Ldloc (var
obj_1)) (Stfld (field cZ152074_Z152090/f0)) (Pop) (Ldloc (var obj_1))
(Ldc_I4 0) (Box ?:System.Int32) (Tailcall) (Call ?:System.Object
call_generic__1(System.Object, System.Object)) (Ret)))))
While expanding (ml-file "mltest2.ml")
SysException ?:System.NotSupportedException: Тип "mltest2.Z152117" не завершен.
в Meta.Scripting.SCWrapper.run(Object[] args)
в Meta.Scripting.MakeApp.run(Object[] frame)
в Meta.Scripting.MakeSequence.run(Object[] fr)
в Meta.Scripting.Runtime.eval(Object[] f)
в MBaseBin.Z768.mread_compile_eval0_Z677(Object )
в MBaseBin.Z768.mcore_read_int_eval_Z678(Object )
в MBaseBin.Z46321.mnew_read_int_eval_Z46318(Object )
в MBaseBin.Z46803.mcc_toplevel_expand_Z46635(Object , Object , Object , Object )
в MBaseBin.Z46803.mcc_toplevel_expand_Z46635(Object , Object , Object , Object )
в MBaseBin.Z46803.mcc_toplevel_devour_Z46636(Object , Object )
While expanding (n.save)

Хотел на скорость полюбоваться, не получилось.

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

DM>Мне было сказано, что никакие дополнительные фреймворки/библиотеки не нужны, нужен только сам лисп:

Тебе шашечки? Или ехать?

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

T>Неужто тоже может?

А как сам где-то в этой теме говоришь: "Ценность этого действа сильно преувеличена".
Если честно, даже проверять не хочу, потому что ценности этот пример для меня не имеет.

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

DM>Вариант на С++, очевидно, виндовый (писал для себя, поэтому кроссплатформенность целью не была). А окамловый требует extLib, сорри.

Тогда оптимизируй вот этот вариант.

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

TBG>Тогда оптимизируй вот этот вариант.

Зачем? Можно так с ним сравнить. Насколько сейчас отличается скорость твоего решения от данного интерпретатора?

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

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

T>>Неужто тоже может?

TBG>А как сам где-то в этой теме говоришь: "Ценность этого действа сильно преувеличена".

Я говорю, что ценность метапрограммирования преувеличена.

Так что действо вполне определённо.

Не надо меня толковать расширительно.

TBG>Если честно, даже проверять не хочу, потому что ценности этот пример для меня не имеет.

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

У нас, например, кое-где статически проверяется соответствие длин операндов и результатов. В bitvec a[10] можно присвоить результат mul(bitvec [5],bitvec [5]) или bitconcat(bitvec [3], bitvec [7]). Техника посложней, но в основе ровно то же самое.

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

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

dmz>Да что там смотреть? Mincaml — реализация подмножества окамла на окамле. С оптимизирующим компилятором для SPARC.
dmz>Около пятисот, что ли, строк. http://min-caml.sourceforge.net/index-e.html

Никак не 500, а побольше. И там даже pattern matching нет, совсем уж игрушечный ML.

dmz>Так что нашли чем похваляться. Около тысячи строк, блин. ML-и вообще очень простые для разбора языки.

Именно. О том и речь, что ML-подобный вывод типов к Лиспу прикрутить можно элементарно, после чего проблем с "лишними" аннотациями уже не будет.

dmz>Грамматика ml-подобных языков на Language Zoo занимает пару экранов максимум в ocamlyacc-файлах.

Грамматика в обсуждаемой задаче вообще не нужна. Нужен вывод типов.

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

Можно, конечно же. И это будет lisp way. Метапрограммирование. Простенькое, правда, однопроходное — но для такой задачи и это сойдёт.

dmz>Или тоже самое, но при помощи биндингов к LLVM, примеры, кстати есть. Так что вообще непонятно, чем тут меряются.

Тут обсуждают, а нужно ли вообще метапрограммирование, или и без него жить можно.

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

TBG>>А как сам где-то в этой теме говоришь: "Ценность этого действа сильно преувеличена".

T>Я говорю, что ценность метапрограммирования преувеличена.

Qi — по сути, расширение Лиспа. Да и Axiom тоже. И в Qi, и в Qi II, и в Axiom зависимые типы присутствуют.

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

DM>Хм. Какой-то он неюзабельный: нет оптимизации хвостовой рекурсии и нет цикла for, т.е. поэтому цикл на 100000 итераций уже не получается сделать. А на таком коде просто умирает, разбрасывая кишки:

А, ясненько. Это очень древняя версия. В свежей версии компилятора давно уже исправлен pattern matching. Это глюка не ML, а Лиспа. Добавить for там, кстати, можно очень легко.

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

DM>Щито? Или я чего-то недопонял, или вот тут подобные вещи давно уже отличненько реализованы:
DM>http://www.seedwiki.com/wiki/shifting_focus/tywith
DM>http://code.google.com/p/deriving/wiki/Introduction

Нет, они совсем не подобные. Генерить функцию-визитора надо не при определении типа, а в каждом конкретном случае отдельно. Для чего при раскрытии этого самого "конкретного случая" препроцессор должен иметь представление об определении типа. А он его, представления, таки не имеет.

DM>Из этого примера смысл ast:visit в МЛ ускользает — чем плох обычный рекурсивный обход дерева?

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

DM> В нем гораздо больше свободы действий

Не больше. Явный обход дерева — это частный случай.

DM> плюс гарантия полноты матчинга и проверка корректности (проверяет ли ast:visit типы аргументов или хотя бы их число?),

Проверяет

DM> а текста немного, т.к. есть нормальный синтаксис.

Синтаксис и там есть (см. PFront: http://lambda-the-ultimate.org/node/3281). А текста — очень много получается обычно, каким бы синтаксис не был.

Допустим, такая задача — есть AST довольно сложного языка, в котором, кроме всего прочего, есть конструкции let id = expr in expr и function (args) = expr;

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

В варианте со всякими там ML придётся писать рекурсивный обход всего дерева, не забывая ни одного пути, на котором может втретиться значение типа expr. И в каждом рекурсивном вызове тащить за собой ещё и окружение (таблицу переменования переменных). Очень многословно выходит. В варианте с ast:visit это будет несколько строчек, где из всего AST будут упомянуты только изменяемые узлы. Всё остальное будет сгенерено автоматически.

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

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

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

Оно же, но на Nemerle — тыц-клац.

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

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

M>Оно же, но на Nemerle — тыц-клац.

Все-таки на .NET функциональщина тормозная выходит. Жалко.