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

M> В последний раз я kawa использовал года четыре назад, когда окончательно убедился, что в ближайшее время ситуация лучше не станет.

За четыре года много воды утекло...

M> Угу. В идеале надо бы вообще иметь возможность встраивать близкие к Java конструкции в код, что на пару с макрами даёт офигенные результаты.

Да только не видать на горизонте такого...

M> Кстати, в mbase так сделано (только для .net), там есть встроенный целевой язык !net, и есть возможность ембеддить IL-ассемблер.

Хм, попросить в clojure доступ к asm-у? =)

CU>> Приличнее прочих в этом плане выглядит scala. Но там нет макр

M> Зато там много всякого другого интересного есть.

Есть. Но и ограничений хватает...

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

>> 3. Case sensitive символы
MZ>Есть и в CL.

Я CL не знаю, видел только insensitive там — расскажи.

>> 4. Единое пространство имён для функций и переменных
MZ>Ну на кой фиг оно ?

Чтобы не было #' / funcall, я думаю. Единообразненько чтобы было.

MZ>Недо статка в реализациях CL тоже вроде бы нет. А Java -- да ну её ...

Жизнь — сука

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

M>> В последний раз я kawa использовал года четыре назад, когда окончательно убедился, что в ближайшее время ситуация лучше не станет.

CU>За четыре года много воды утекло...

Да не так уж и много, судя по количеству изменений в коде. Может когда либо ещё у меня опять руки дойдут Kawa попробовать.

M>> Угу. В идеале надо бы вообще иметь возможность встраивать близкие к Java конструкции в код, что на пару с макрами даёт офигенные результаты.

CU>Да только не видать на горизонте такого...

А что "видать" то? Взять и сделать. Apache BCEL, и вперёд.

CU>Хм, попросить в clojure доступ к asm-у? =)

Опять же — зачем просить, когда можно взять и сделать?

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

MZ>Как-то это всё не очень убедительно.

Лично на мой выбор это всё повлияло.

>> 2. Есть continuations
MZ>Ну, бог с ними.

А ведь офигенно мощная вещь.

>> 3. Case sensitive символы
MZ>Есть и в CL.

Не то чтобы очень есть.

>> 4. Единое пространство имён для функций и переменных

MZ>Ну на кой фиг оно ?

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

>> 5. Гораздо больше реализаций (в том числе и для всяких там JVM). ABCL не
>> очень юзабелен пока.

MZ>Недо статка в реализациях CL тоже вроде бы нет.

Есть-есть. Увы.

MZ> А Java -- да ну её ...

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

Здравствуйте, MasterZiv, Вы писали:
MZ>О, если такие любители схемы собрались, объясните
MZ>мне на пальцах в двух словах, почему некоторые люди
MZ>так любят схему, когда есть common lisp ?
Мне схема просто показалась логичней и удобней, без объективных причин.

Теперь твоя очередь рассказывать, чем cl лучше схемы.

Здравствуйте, metaprogrammer, Вы писали:
M> Собственно, второй путь является подмножеством первого, поскольку компилятор syntax rules в обычные макры реализуется тривиально. А вот первое на уровне второго сделать невозможно, даже не смотря на тьюринг-полный язык.
Видимо, комьюнити схемы состоит из ненавистников негигиенических макросов чуть менее, чем наполовину. Вплоть до таких вот мнений:
http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/4e55b0c54d59e710?hl=en
Автор выступает в защиту syntax-case, который лично мне не особо нравится.

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

MC>Видимо, комьюнити схемы состоит из ненавистников негигиенических макросов чуть менее, чем наполовину. Вплоть до таких вот мнений:
MC>http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/4e55b0c54d59e710?hl=en
MC>Автор выступает в защиту syntax-case, который лично мне не особо нравится.

А я вот готов автора поддержать. В учебном языке, в той самой "маленькой схеме" не должно быть defmacro. Поскольку это слишком уж мощный инструмент, не для неокрепших умов. С другой стороны, syntax rules — идеальная мозголомка, годится для этюдов. Так что, всё верно. В большой и промышленный язык — defmacro и syntax rules сделанные поверх него, в маленький академический язык — полный запрет на defmacro и аналоги.

Здравствуйте, metaprogrammer, Вы писали:
M>Так что, всё верно. В большой и промышленный язык — defmacro и syntax rules сделанные поверх него
Ну что-то вроде того. Но насколько я понимаю, основной поинт за то, чтобы "главной" макросистемой делать не defmacro, а что-то гигиеническое (например, er — например, так оно в chicken4) — это то, что те же er легко реализовать на уровне компилятора/интерпретатора, возможно, проще, делать гигиену на defmacro. Своего мнения на этот счет не имею, к сожалению, но мнение таковое слышал.

Впрочем, главные схемеры уже в r6rs определились со стандартом на "полугигиенические макросы" — syntax-case (который и восхваляется в том обсуждении, на которое я давал ссылку). Интересно, поменяется ли что-то в новом стандарте.

M>в маленький академический язык — полный запрет на defmacro и аналоги.
Согласен

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

MC>Ну что-то вроде того. Но насколько я понимаю, основной поинт за то, чтобы "главной" макросистемой делать не defmacro, а что-то гигиеническое (например, er — например, так оно в chicken4)

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

Здравствуйте, metaprogrammer, Вы писали:
MC>>Ну что-то вроде того. Но насколько я понимаю, основной поинт за то, чтобы "главной" макросистемой делать не defmacro, а что-то гигиеническое (например, er — например, так оно в chicken4)
M> Главной гигиеническая система быть не может, она не равномощна defmacro. defmacro на syntax rules сделать нельзя (да, да, я видел компилятор функционального подмножества Схемы в syntax rules, это не вариант), тогда как наоборот — можно.
Er, если я не ошибаюсь — тот же defmacro, просто с опциональной гигиеной.

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

CU>>Да только не видать на горизонте такого...

А> А что "видать" то? Взять и сделать. Apache BCEL, и вперёд.

Быстрый ты... И почему именно BCEL? (это не "наезд" а именно вопрос — какие преимущества?) Средств ковыряния/генерации байткода — вагон и маленькая тележка...

CU>>Хм, попросить в clojure доступ к asm-у? =)

А> Опять же — зачем просить, когда можно взять и сделать?

Это была именно что шутка

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

CU>Быстрый ты...

А что, в этой задаче есть что-то хоть немного сложное?

CU> И почему именно BCEL? (это не "наезд" а именно вопрос — какие преимущества?)

Это я для примера. Поскольку у меня больше всего опыта именно с BCEL.

CU> Средств ковыряния/генерации байткода — вагон и маленькая тележка...

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

CU>Это была именно что шутка

Опять же — ничего смешного. Задача тривиальная, бенефиты от её решения очевидные.

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

M> А что, в этой задаче есть что-то хоть немного сложное?

Во-первых, я говорил о скорости а не о сложности. Во-вторых, ну открой проектик — я помогу

M> Это я для примера. Поскольку у меня больше всего опыта именно с BCEL.

Меня смущает отсутствие релизов с лохматого года... А в jdk7 уже invokedynamic есть =)
ASM (из svn) мне в этом плане больше нравится

CU>>Это была именно что шутка

M> Опять же — ничего смешного. Задача тривиальная, бенефиты от её решения очевидные.

От доступа к байткоду — да. Но это не изменит общей направленности clojure на immutable data. А из этого места растут некоторые проблемы. Да и я практически уверен что подобные "фиксы" в "мэйнстрим" не пустят.

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

CU>Во-первых, я говорил о скорости а не о сложности. Во-вторых, ну открой проектик — я помогу

Не, я пока ещё в .NET-песочнице покопаюсь.

CU>Меня смущает отсутствие релизов с лохматого года... А в jdk7 уже invokedynamic есть =)
CU>ASM (из svn) мне в этом плане больше нравится

А, есть такое дело. Ну так я и Java не трогал с лохматого года. На ASM посмотрел — подойдёт. Хотя, конечно, жаль, что столь фундаментальной функциональности нет из коробки, как в .NET с System.Reflection.Emit.

CU>От доступа к байткоду — да. Но это не изменит общей направленности clojure на immutable data.

У них ещё и общая направленность на как можно более прозрачную интеграцию с JVM.

CU> А из этого места растут некоторые проблемы. Да и я практически уверен что подобные "фиксы" в "мэйнстрим" не пустят.

Это только если для них killer app не показать.

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

M> Не, я пока ещё в .NET-песочнице покопаюсь.

Ок, может потом встретимся =)

CU>>От доступа к байткоду — да. Но это не изменит общей направленности clojure на immutable data.

M> У них ещё и общая направленность на как можно более прозрачную интеграцию с JVM.

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

CU>> А из этого места растут некоторые проблемы. Да и я практически уверен что подобные "фиксы" в "мэйнстрим" не пустят.

M> Это только если для них killer app не показать.

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

А базу пусть нарабатывают — пригодится. =) Интересного кода у них уже много

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

M> Но, таки, в Clojure есть defmacro. В Scheme нет defmacro. Closure более лиспистый лисп, чем Схема.
Таки defmacro реализуется в десяток строк на syntax-case. Обратное неверно. И да, defmacro гораздо менее удобный и мощный, чем syntax-case

MZ>так любят схему, когда есть common lisp ?
Схема чище и изящнее, а следовательно нагляднее и менее подвержена ошибкам.

MZ>Что в ней такого преимущественного ?
Можно сравнить две реализации одной и той же концепции: CL vs Scheme

CL — write only каша, где глазу не за что зацепиться. В схеме не только сразу виден синтаксис DSL-а, который вводится макросами, но и сразу видно как его расширять. В принципе cl-овскую реализаию loop можно сравнивавать и с foof-loop-ами, и с srfi-42, и с PLT-шными for-ами. Ситуация везде примерно одинаковая. Гигиена и высокоуровневость по дефолту (с опциональным отключением и того и другого) — колоссальное преимущество схемовской макросистемы перед CL-овскими макрами (назвать их макросистемой как то даже не поворачивается язык, ибо никакой, собственно, системы там и нет).

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

M>> Но, таки, в Clojure есть defmacro. В Scheme нет defmacro. Closure более лиспистый лисп, чем Схема.
А>Таки defmacro реализуется в десяток строк на syntax-case.

Которого нет в стандарте.

А> Обратное неверно.

Нет. Я делал — ничего сложного.

А> И да, defmacro гораздо менее удобный и мощный, чем syntax-case

Не согласен. syntax-case — это излишества и чрезмерная декларативность там, где ей не место. Базовой макросистемой должна быть более простая и фундаментальная.

Благо, во всех нормальных Схемах define-macro имеется. Плохо то, что у него кривая семантика в связке с модулями — как правило нельзя воспользоваться макрой, определённой внутри модуля, в этом самом модуле.

lomeo пишет:

> Я CL не знаю, видел только insensitive там — расскажи.

ВКратце:

0) Как читать символы -- режим настройки lisp reader,
есть (кажется) четыре варианта -- преобразовывать буквы в
верхний регистр, в нижний регистр, капитализировать, или
не менять ничего. по умолчанию -- первый вариант. Настраиваешь
по-другому -- имеешь другие варианты.

1) есть специальный синтаксис записи символов, который
сохраняет регистр букв:

'|QwErTy| ==> QwErTy

> Чтобы не было #' / funcall, я думаю. Единообразненько чтобы было.

Ну я не понимаю, чем оно мешает. Кстати, по стандарту #' требуется
писать не везде.

А>>Таки defmacro реализуется в десяток строк на syntax-case.
M> Которого нет в стандарте.
Забавно беседовать о вкусе устриц с теми, кто их не только не пробовал, но даже не видел.

А>> Обратное неверно.
M> Нет. Я делал — ничего сложного.
Ну раз "ничего сложного", думаю pastebin выдержит — давайте-ка реализацию syntax-case на defmacro.

А>> И да, defmacro гораздо менее удобный и мощный, чем syntax-case
M> Не согласен. syntax-case — это излишества и чрезмерная декларативность там, где ей не место. Базовой макросистемой должна быть более простая и фундаментальная.
Более простая как раз syntax-case (и, что парадоксально, при этом более мощная). Она проще и при написании и при понимании уже написанного. Выше же приведен пример. Вы конечно можете сказать, что нечитаемость это только плюс (+15 к илитарности, ага), но вряд ли с Вами согласится кто-нибудь кроме таких же коммонлисперов, как Вы.

M> Благо, во всех нормальных Схемах define-macro имеется. Плохо то, что у него кривая семантика в связке с модулями — как правило нельзя воспользоваться макрой, определённой внутри модуля, в этом самом модуле.
Чьорт. Кривая. Нельзя воспользоваться. Вы таки открыли мне глаза. То, что делается едва ли не в каждом проекте на схеме "на самом деле" делать нельзя. Понабирают, блин, по объявлениям.