lomeo пишет:
> Я CL не знаю, видел только insensitive там — расскажи.
ВКратце:
0) Как читать символы -- режим настройки lisp reader,
есть (кажется) четыре варианта -- преобразовывать буквы в
верхний регистр, в нижний регистр, капитализировать, или
не менять ничего. по умолчанию -- первый вариант. Настраиваешь
по-другому -- имеешь другие варианты.
1) есть специальный синтаксис записи символов, который
сохраняет регистр букв:
'|QwErTy| ==> QwErTy
> Чтобы не было #' / funcall, я думаю. Единообразненько чтобы было.
Ну я не понимаю, чем оно мешает. Кстати, по стандарту #' требуется
писать не везде.
Здравствуйте, Mr.Cat, Вы писали:
M>>Гигиена тоже реализуется, легко. MC>Ну раз не реализована — видимо, не так легко. Для гигиены нужен, например, полный список биндингов в месте объявления макры. В CL его можно получить?
Достаточно списка биндингов в самой макре.
MC>>>Можно пример реализации? M>> Уже приводил в соседней ветке. MC>Напомни плз. ссылку, там вы с thesz так нафлудили, что нифига не найдешь.
А мне, думаешь, легко искать? Придётся заново копипастить...
Здравствуйте, Mr.Cat, Вы писали:
MC>А зачем так дизайнить макры? Надо чтобы писалось примерно так:
(let ((x the-other-x-value))
(match something ((tag x . y) (do-something x y))))
MC>Тогда к x и y можно будет делать биндинг, видимый для do-something. Погляди match.scm.
Нет. Не надо. tag — константа. Как отделишь от биндингов? Такой убогий match не нужен — надо разделять биндинги и символы. Соответственно, содержимое символов приходится парсить. Это сразу многократно увеличивает возможности синтаксиса. Зачем себя ограничивать ради дебильной и в принципе бесполезной гигиены? Зачем делать язык сложнее и глючнее, когда можно сделать проще, мощнее и надёжнее? А ведь это простейший пример. Посмотри на ранее обсуждавшийся def:ast, или на Infix, и на генератор парсеров — везде есть смысл кодировать символы. Везде гигиена только навредила бы. А пользы от неё ровным счётом никакой, вообще.
MC>Каюсь, прочитал довольно поверхностно, но тебе вроде бы всего-то и надо — разбить на пару модулей, не?
Не не не. Мне надо определять и тут же использовать. Возможно — в коде, который тут же был из этой же макры получен. Иначе это не метапрограммирование, а убожество будет, ничем не лучше препроцессора в Си.
MC>Вообще-то сплайс бегина чуть ли не в r5rs есть. В r6rs точно.
Однако некоторые реализации его не понимают.
M>>Ещё одна гадость — невозможность передачи контекста между разными макрами. Простейшее (хоть и малость хаковатое) решение — это возможность контроля за порядком раскрытия макроопределений. В большинстве Схем тоже нереализуемо. MC>Порядок в r6rs стандартизован. А как его контролируют с defmacro?
В CL — тоже никак. Но тривиальное расширение к макросистеме позволяет решить эту проблему.
MC>Ну если серьезное метапрограммирование — это куча макросов, вводящих левые биндинги (пишешь ~x — биндишь к x, не понимаю смысла в этом), и все в одно файле — то да.
Серьёзное метапрограммирование — это реализация компилируемых eDSLей. Всяких, разных/ С гигиеной таких языков делать не получается:
Здравствуйте, Zert, Вы писали: Z>Давно пора. Z>В результате получатся Школьный Функциональный Язык и Common Scheme. Common Scheme можно будет использовать.
Идея здравая, однако же интересно, что из этого получится на деле.
Боюсь, что все останется как было: часть имплементаций (те, которые сейчас нацелены r6rs) будут нацелены на "большой" стандарт. В других (которые остались на r5rs) по-прежнему будут процветать проституция и азартные игры.
Здравствуйте, MasterZiv, Вы писали: MZ>О, если такие любители схемы собрались, объясните MZ>мне на пальцах в двух словах, почему некоторые люди MZ>так любят схему, когда есть common lisp ?
Мне схема просто показалась логичней и удобней, без объективных причин.
Теперь твоя очередь рассказывать, чем cl лучше схемы.
Здравствуйте, Аноним, Вы писали:
А>Я тебе сразу говорю, что задачи сильно объемные, чтоб решать их только для того, чтобы ПОПЫТАТЬСЯ чего то доказать тупому общелисповому троллю (хотя весь опыт, накопленный человечеством, говорит, что троллю ничего доказать нельзя — его можно только контртроллить).
"Mr.Cat" <64543@users.rsdn.ru> writes:
> Боюсь, что все останется как было: часть имплементаций (те, которые > сейчас нацелены r6rs) будут нацелены на "большой" стандарт. В других > (которые остались на r5rs) по-прежнему будут процветать проституция и > азартные игры.
А можешь в двух словах разницу между r5rs и r6rs пояснить ?
Здравствуйте, DemAS, Вы писали: DAS>А можешь в двух словах разницу между r5rs и r6rs пояснить ?
Основное на мой взгляд — в r6rs стандартизована система модулей, введено понятие стадий компиляции/выполнения.
Также в r6rs вошло несколько srfi (например, syntax-case, исключения, структуры — точно номера не помню).
R6rs в целом более точен, меньше оставлено на откуп разработчику. Из того, что помню — например, семантика eval и топлевельного кода.
В общем, сделан первый шаг к реальной совместимости между имплементациями.
FR пишет:
> Схему хотят разделить на два языка http://lambda-the-ultimate.org/node/3582 > Один простой для обучения, другой сложный промышленный. > Scheme to be split into two language <message/3512299.aspx> Оценить
Идея здравая, но я не понимаю, зачем нужен второй CommonLisp.
Ну будет он конечно lisp-1, а не lisp-2, но это по-моему не принципиально.
MasterZiv пишет:
> Идея здравая, но я не понимаю, зачем нужен второй CommonLisp. > Ну будет он конечно lisp-1, а не lisp-2, но это по-моему не принципиально.
Я, в смысле, может мне объяснит это кто ? Почему люди так lisp-1 любят ?
Здравствуйте, MasterZiv, Вы писали:
MZ>Идея здравая, но я не понимаю, зачем нужен второй CommonLisp. MZ>Ну будет он конечно lisp-1, а не lisp-2, но это по-моему не принципиально.
Я конечно с лиспом очень поверхностно соприкасаюсь, но от Common Lisp у меня очущения
такие же как от C++, язык уже перешел за грань переусложнения.
Здравствуйте, yumi, Вы писали:
FR>>Так он только на одной платформе.
Y>Чего-чего? Он же под java, а java в свою очередь почти под все платформы, соответственно сlojure работает везде, где есть java.
Ява и есть плафторма, и далеко не доминирующая во многих отраслях. А язык только под одну платформу никак ни может притендовать на мировое господство
Здравствуйте, FR, Вы писали:
FR>Ява и есть плафторма, и далеко не доминирующая во многих отраслях. А язык только под одну платформу никак ни может притендовать на мировое господство
Спрашивается, нафига нам мировое господство, нам просто нужен эффективный инструмент решения наших задач
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, DemAS, Вы писали: DAS> Особенно, если есть Clojure
Clojure — все-таки немного из другой оперы. Взгляд на лисп одного конкретного человека, тогда как scheme — результат столкновения множества различных точек зрения.
Здравствуйте, Mr.Cat, Вы писали:
MC>Clojure — все-таки немного из другой оперы. Взгляд на лисп одного конкретного человека, тогда как scheme — результат столкновения множества различных точек зрения.
Но, таки, в Clojure есть defmacro. В Scheme нет defmacro. Closure более лиспистый лисп, чем Схема.
Здравствуйте, metaprogrammer, Вы писали: M> Но, таки, в Clojure есть defmacro. В Scheme нет defmacro. Closure более лиспистый лисп, чем Схема.
В scheme минимум штуки три-четыре более-менее известные макросистемы (это из того, о чем я в курсе — наверняка не все) — всегда можно выбрать подходящую. Если я правильно себе представляю defmacro, то ближе всего к нему syntactic closures или основанный на них explicit renaming.
M>P.S. я бывший аноним из треда про "VM на лиспе"
Приятно познакомиться
Здравствуйте, yumi, Вы писали: Y>И таки clojure более правосла... тьфу функционален, чем Схема.
Ты про фичастость или про связь с функциональным программированием?
Здравствуйте, Mr.Cat, Вы писали:
MC>В scheme минимум штуки три-четыре более-менее известные макросистемы (это из того, о чем я в курсе — наверняка не все) — всегда можно выбрать подходящую.
Я говорю про R5RS конкретно. R6RS не лучше в этом плане. А так — практически каждая внятная реализация схемы имеет define-macro (bigloo, kawa, и т.п.) или аналоги.
MC> Если я правильно себе представляю defmacro, то ближе всего к нему syntactic closures или основанный на них explicit renaming.
Это совсем не из той сказки. defmacro предельно прост и туп, гигиену там надо руками делать.
Здравствуйте, Mr.Cat, Вы писали:
Y>>И таки clojure более правосла... тьфу функционален, чем Схема. MC>Ты про фичастость или про связь с функциональным программированием?
Конечно второе.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, metaprogrammer, Вы писали:
M> Это совсем не из той сказки. defmacro предельно прост и туп, гигиену там надо руками делать.
И это правильно, ибо так гибче. А еще правильнее иметь и тот и другой путь, как например, мне понравилось сделано в Немерле, возможность прерывать гигиену.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
"Mr.Cat" <64543@users.rsdn.ru> writes:
> Ты про фичастость или про связь с функциональным программированием?
Clojure хорош тем, что позволяет снизить порог вхождения за счет
использования Java классов. Ну например, я могу соорудить вот такой
ужасный, с точки зрения функционального подхода, код:
Но все-таки достичь своей цели. В scheme бы я просто даже не знал с чего
начать. Речь идет про практические задачи — GUI, работа с БД, OpenGl и так далее.
Здравствуйте, yumi, Вы писали:
M>> Это совсем не из той сказки. defmacro предельно прост и туп, гигиену там надо руками делать.
Y>И это правильно, ибо так гибче. А еще правильнее иметь и тот и другой путь, как например, мне понравилось сделано в Немерле, возможность прерывать гигиену.
Собственно, второй путь является подмножеством первого, поскольку компилятор syntax rules в обычные макры реализуется тривиально. А вот первое на уровне второго сделать невозможно, даже не смотря на тьюринг-полный язык.
Здравствуйте, metaprogrammer, Вы писали: M> Я говорю про R5RS конкретно. R6RS не лучше в этом плане. А так — практически каждая внятная реализация схемы имеет define-macro (bigloo, kawa, и т.п.) или аналоги.
R5rs поглядеть — так там вообще шаром покати. Это даже не стандарт, пожалуй — а просто общий знаменатель. Программировать проходится под конкретную имплементацию.
MC>> Если я правильно себе представляю defmacro, то ближе всего к нему syntactic closures или основанный на них explicit renaming. M> Это совсем не из той сказки. defmacro предельно прост и туп, гигиену там надо руками делать.
Ну а в sc/er автоматической гигиены и нет. Она руками включается.
Здравствуйте, yumi, Вы писали: Y>>>И таки clojure более правосла... тьфу функционален, чем Схема. MC>>Ты про фичастость или про связь с функциональным программированием? Y>Конечно второе.
Объясни, плз. У меня пока прямо противоположное мнение.
Здравствуйте, yumi, Вы писали: Y>А еще правильнее иметь и тот и другой путь, как например, мне понравилось сделано в Немерле, возможность прерывать гигиену.
Это есть и в scheme. Если я правильно помню, в nemerle макросы аналогичны syntax-case.
Здравствуйте, DemAS, Вы писали: DAS> Clojure хорош тем, что позволяет снизить порог вхождения за счет DAS>использования Java классов.
Из жавских схем есть sisc и kawa — обе не особо на слуху, но живы. Под дотнет есть ironscheme и (могу ошибаться) larceny и bigloo. Так что если тебя интересуют имплементации на базе глобальной и надежной платформы — велкам.
DAS>В scheme бы я просто даже не знал с чего DAS>начать. Речь идет про практические задачи — GUI, работа с БД, OpenGl и так далее.
Ну начать вестимо надо с документации по стандартной библиотеке твоей имплементации scheme (может у тя там вообще дотнет — см. IronScheme) а также поискать стороннии модули биндинги к нужным тебе библиотекам (у plt есть planet, у chicken — eggs). Короче, как обычно.
Здравствуйте, Mr.Cat, Вы писали:
MC>Из жавских схем есть sisc и kawa — обе не особо на слуху, но живы.
Kawa довольно шустра, но глючновата, и очень медленно развивается.
SISC — добротная реализация, но тормозноват, интерпретатор. Идеально подходит как встраиваемый скриптовый язык, разве что.
Очень много пользовался и тем, и другим, и остался в общем и целом разочарован.
MC> Под дотнет есть ironscheme и (могу ошибаться) larceny и bigloo. Так что если тебя интересуют имплементации на базе глобальной и надежной платформы — велкам.
Схем под .NET нормальных нет. Bigloo сам не managed, использовать его очень сложно. Остальные все какие-то недоделанные.
Здравствуйте, metaprogrammer, Вы писали: M> Схем под .NET нормальных нет. Bigloo сам не managed, использовать его очень сложно. Остальные все какие-то недоделанные.
Смотря что считать нормльным... Но да, имеет место недоделанность.
Здравствуйте, Mr.Cat, Вы писали:
MC>Объясни, плз. У меня пока прямо противоположное мнение.
А ты сходи на сайт, почитай, а еще лучше попиши. Ну например, что его делает более функциональным, так это immutability by default, все core data structures — immutable.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
FR пишет:
> Я конечно с лиспом очень поверхностно соприкасаюсь, но от Common Lisp у > меня очущения > такие же как от C++, язык уже перешел за грань переусложнения.
Да нет, думаю ты не прав. По крайней мере Common Lisp гораздо проще C++,
и мощнее, естественно.
В Common Lisp есть некоторые исторические наслоения, которые может быть
убрались бы следующим стандартом, если бы он был, но его всё нет и нет ...
Здравствуйте, metaprogrammer, Вы писали:
M> Kawa довольно шустра, но глючновата, и очень медленно развивается.
На счёт глюков: список в багзиле не длиннее прочих. А касательно развития: так kawa позиционирует себя как scheme — в определённой части "связана" стандартами. С другой стороны: def-syntax присутствует (как и defmacro) — творите.
Чем обе не нравятся: тяжело получить bytecode максимально приближённый к java-вскому (когда таки хочется скорости исполнения, но лень писать на pure java). И в этом плане clojure не устраивает в большей степени (как и суммарной своей тормознутостью). Приличнее прочих в этом плане выглядит scala. Но там нет макр
Здравствуйте, MasterZiv, Вы писали:
MZ>О, если такие любители схемы собрались, объясните MZ>мне на пальцах в двух словах, почему некоторые люди MZ>так любят схему, когда есть common lisp ?
MZ>Что в ней такого преимущественного ?
1. Схема маленькая и простая
2. Есть continuations
3. Case sensitive символы
4. Единое пространство имён для функций и переменных
5. Гораздо больше реализаций (в том числе и для всяких там JVM). ABCL не очень юзабелен пока.
Здравствуйте, cl-user, Вы писали:
CU>На счёт глюков: список в багзиле не длиннее прочих. А касательно развития: так kawa позиционирует себя как scheme — в определённой части "связана" стандартами. С другой стороны: def-syntax присутствует (как и defmacro) — творите.
Конкретно что меня достало — очень трудноуловимые и трудновоспроизводимые глюки кодогенератора. В последний раз я kawa использовал года четыре назад, когда окончательно убедился, что в ближайшее время ситуация лучше не станет. Перешел тогда на SISC. А что багзилла пуста — так оно и понятно, пользователей мало, сообщество куцее. Я вот, каюсь, грешен, ни одну из обнаруженных ошибок Перу Боснеру не сообщил. Они настолько все мутные были, что довести до легковоспроизводимого минимального теста и не получалось даже.
CU>Чем обе не нравятся: тяжело получить bytecode максимально приближённый к java-вскому (когда таки хочется скорости исполнения, но лень писать на pure java).
Угу. В идеале надо бы вообще иметь возможность встраивать близкие к Java конструкции в код, что на пару с макрами даёт офигенные результаты.
Кстати, в mbase так сделано (только для .net), там есть встроенный целевой язык !net, и есть возможность ембеддить IL-ассемблер.
CU> И в этом плане clojure не устраивает в большей степени (как и суммарной своей тормознутостью).
Зато динамические биндинги к жабе там наиболее красиво и прямо сделано, даже лучше, чем в SISC.
CU> Приличнее прочих в этом плане выглядит scala. Но там нет макр
metaprogrammer пишет:
> MZ>Что в ней такого преимущественного ? > > 1. Схема маленькая и простая > 2. Есть continuations > 3. Case sensitive символы > 4. Единое пространство имён для функций и переменных > 5. Гораздо больше реализаций (в том числе и для всяких там JVM). ABCL не > очень юзабелен пока.
Как-то это всё не очень убедительно.
1. Схема маленькая и простая
и + и — > 2. Есть continuations
Ну, бог с ними.
> 3. Case sensitive символы
Есть и в CL.
> 4. Единое пространство имён для функций и переменных
Ну на кой фиг оно ?
> 5. Гораздо больше реализаций (в том числе и для всяких там JVM). ABCL не > очень юзабелен пока.
Недо статка в реализациях CL тоже вроде бы нет. А Java -- да ну её ...
Здравствуйте, 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 -- да ну её ...
Жизнь — сука
Re[13]: Scheme to be split into two language
От:
Аноним
Дата:
27.08.09 09:53
Оценка:
Здравствуйте, 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 -- да ну её ...
Хочу уйти жить в параллельную реальность. В утопию, где о Жабе можно сказать "да ну её".
Здравствуйте, metaprogrammer, Вы писали: M> Собственно, второй путь является подмножеством первого, поскольку компилятор syntax rules в обычные макры реализуется тривиально. А вот первое на уровне второго сделать невозможно, даже не смотря на тьюринг-полный язык.
Видимо, комьюнити схемы состоит из ненавистников негигиенических макросов чуть менее, чем наполовину. Вплоть до таких вот мнений: http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/4e55b0c54d59e710?hl=en
Автор выступает в защиту 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-у? =)
А> Опять же — зачем просить, когда можно взять и сделать?
Здравствуйте, 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> А из этого места растут некоторые проблемы. Да и я практически уверен что подобные "фиксы" в "мэйнстрим" не пустят.
Здравствуйте, metaprogrammer, Вы писали:
M> Не, я пока ещё в .NET-песочнице покопаюсь.
Ок, может потом встретимся =)
CU>>От доступа к байткоду — да. Но это не изменит общей направленности clojure на immutable data.
M> У них ещё и общая направленность на как можно более прозрачную интеграцию с JVM.
У них напрочь нет "прозрачной интеграции" с обычными массивами, а с массивами простых типов — вообще труба. На чём и просаживается скорость при необходимости их использовать.
CU>> А из этого места растут некоторые проблемы. Да и я практически уверен что подобные "фиксы" в "мэйнстрим" не пустят.
M> Это только если для них killer app не показать.
Намедни наткнулся в эхе на сообщение, что "прозрачное" использование массивов простых типов не вписывается в "политику партии" и все страждущие идут лесом.
А базу пусть нарабатывают — пригодится. =) Интересного кода у них уже много
Re[5]: Scheme to be split into two language
От:
Аноним
Дата:
29.08.09 03:27
Оценка:
Здравствуйте, metaprogrammer, Вы писали:
M> Но, таки, в Clojure есть defmacro. В Scheme нет defmacro. Closure более лиспистый лисп, чем Схема.
Таки defmacro реализуется в десяток строк на syntax-case. Обратное неверно. И да, defmacro гораздо менее удобный и мощный, чем syntax-case
Re[7]: Scheme to be split into two language
От:
Аноним
Дата:
29.08.09 03:43
Оценка:
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 имеется. Плохо то, что у него кривая семантика в связке с модулями — как правило нельзя воспользоваться макрой, определённой внутри модуля, в этом самом модуле.
Re[7]: Scheme to be split into two language
От:
Аноним
Дата:
30.08.09 01:21
Оценка:
А>>Таки defmacro реализуется в десяток строк на syntax-case. M> Которого нет в стандарте.
Забавно беседовать о вкусе устриц с теми, кто их не только не пробовал, но даже не видел.
А>> Обратное неверно. M> Нет. Я делал — ничего сложного.
Ну раз "ничего сложного", думаю pastebin выдержит — давайте-ка реализацию syntax-case на defmacro.
А>> И да, defmacro гораздо менее удобный и мощный, чем syntax-case M> Не согласен. syntax-case — это излишества и чрезмерная декларативность там, где ей не место. Базовой макросистемой должна быть более простая и фундаментальная.
Более простая как раз syntax-case (и, что парадоксально, при этом более мощная). Она проще и при написании и при понимании уже написанного. Выше же приведен пример. Вы конечно можете сказать, что нечитаемость это только плюс (+15 к илитарности, ага), но вряд ли с Вами согласится кто-нибудь кроме таких же коммонлисперов, как Вы.
M> Благо, во всех нормальных Схемах define-macro имеется. Плохо то, что у него кривая семантика в связке с модулями — как правило нельзя воспользоваться макрой, определённой внутри модуля, в этом самом модуле.
Чьорт. Кривая. Нельзя воспользоваться. Вы таки открыли мне глаза. То, что делается едва ли не в каждом проекте на схеме "на самом деле" делать нельзя. Понабирают, блин, по объявлениям.
Здравствуйте, Аноним, Вы писали:
А>>>Таки defmacro реализуется в десяток строк на syntax-case. M>> Которого нет в стандарте. А>Забавно беседовать о вкусе устриц с теми, кто их не только не пробовал, но даже не видел.
Хе хе. Посмешил. R6RS это не стандарт, а фигня. А в R5RS только syntax-rules с гигиеной.
А>Ну раз "ничего сложного", думаю pastebin выдержит — давайте-ка реализацию syntax-case на defmacro.
Другие варианты трансформеров там не нужны, и так defmacro есть.
А>Более простая как раз syntax-case (и, что парадоксально, при этом более мощная).
Да нет, не более мощная. Проще чем defmacro нет ничего, он туп до невозможности. syntax-rules же весьма сложен, и, что характерно, абсолютно не нужен. В качестве весёлого упражнения предлагаю попробовать реализовать на syntax-rules инфиксный синтаксис с биндингами и лямбдами, а так же pattern matching и list comprehensions.
А> Она проще и при написании и при понимании уже написанного.
Да ни фига оно не проще. Или ты из тех извращенцев, кто и про темплейты в C++ скажет, что оно "проще"? Тьюринг-полнота языка syntax-rules ещё ничего не значит. Внутри defmacro можно воспользоваться всем, что уже опделелено (включаяя и syntax-rules, между прочим).
А> Выше же приведен пример.
Где?!?
А> Вы конечно можете сказать, что нечитаемость это только плюс
Нечитаемость — это как раз про syntax-rules. Надо постараться очень, чтоб на них написать читаемо, если только не реализуешь очередную примитивную чушь вроде очередного for или там враппера для let и if. А вот с defmacro надо постараться, чтоб написать нечитаемо.
А> (+15 к илитарности, ага), но вряд ли с Вами согласится кто-нибудь кроме таких же коммонлисперов, как Вы.
А кто сказал, что я коммонлиспер? Я очень не люблю CL, меня бесит #' и funcall.
А>Чьорт. Кривая.
Именно так.
А> Нельзя воспользоваться.
Да, совершенно невозможно. Для чего либо серьёзного. Для очередного тупенького синтаксического сахара — запросто, а для компиляции сложного DSL — фигушки.
А> Вы таки открыли мне глаза. То, что делается едва ли не в каждом проекте на схеме "на самом деле" делать нельзя. Понабирают, блин, по объявлениям.
В практически каждом проекте на Схеме метапрограммирование практически не используется.
Здравствуйте, Аноним, Вы писали:
А> Выше же приведен пример.
А, понял, это про тот пример с LINQ... Так и то, и другое решение — нечитаемая каша. Можно было гораздо проще всё сделать.
Re[9]: Scheme to be split into two language
От:
Аноним
Дата:
30.08.09 17:50
Оценка:
Здравствуйте, metaprogrammer, Вы писали:
M> Хе хе. Посмешил. R6RS это не стандарт, а фигня. А в R5RS только syntax-rules с гигиеной.
Ясно, очередной упоротый коммон-лиспер, не читавший Пастернака.
А>>Ну раз "ничего сложного", думаю pastebin выдержит — давайте-ка реализацию syntax-case на defmacro. M> Вот для CL, например, реализация syntax-rules: M>http://www.ccs.neu.edu/home/dorai/mbe/mbe-lsp.html
Так как насчет syntax-case (можешь начать с добавления гигиены в свой MBE)?
M> Другие варианты трансформеров там не нужны, и так defmacro есть.
Конечно "не нужны". Кто ж сомневается. Даже в твоем примере — полторы сотни строк только для разбора темплейта. Примерный размер велосипеда, который нужно добавлять в defmacro КАЖДЫЙ РАЗ в более менее нетривиальном случае (причем в MBE реализованы далеко не все возможности схемовской деструктуризации). И, кстати, изобретение своих терминов (MBE) при наличии устоявшихся говорит о том, что чувак, писавший это понятия не имеет о терминологии (и соответственно о области знаний, в которой она используется).
А>>Более простая как раз syntax-case (и, что парадоксально, при этом более мощная). M> Да нет, не более мощная. Проще чем defmacro нет ничего, он туп до невозможности. syntax-rules же весьма сложен, и, что характерно, абсолютно не
Машина тьюринга (ок, можешь взять чистое лямбда-исчисление) — твой выбор. Зачем тебе лишний сахар? К чему это я? Ах да, "туп до невозможности" не означает "проще ничего нет".
>нужен. В качестве весёлого упражнения предлагаю попробовать реализовать на syntax-rules инфиксный синтаксис с биндингами и лямбдами, а так же pattern matching и list comprehensions.
А почему syntax-rules? На syntax-case оно ТОЧНО не будет сложнее defmacro (в худшем случае больше на тот самый десяток строк, необходимый для реализации defmacro на syntax-case), а скорее всего будет значительно проще (ибо деструктуризация входной формы производится автоматически, да и gensym-ами обмазываться не нужно)
А>> Она проще и при написании и при понимании уже написанного. M> Да ни фига оно не проще. Или ты из тех извращенцев, кто и про темплейты в C++ скажет, что оно "проще"? Тьюринг-полнота языка syntax-rules ещё ничего не значит. Внутри defmacro можно воспользоваться всем, что уже опделелено (включаяя и syntax-rules, между прочим).
Да уж. Когда тебе прямым текстом пишут в коде примеры синтаксиса это, конечно же, очень нечитаемо (паттерн-матчинг не нужен). Все эти car, cadar, caddaar читаются гораздо легче.
А>> Выше же приведен пример. M> Где?!?
Выше
А>> Вы конечно можете сказать, что нечитаемость это только плюс M> Нечитаемость — это как раз про syntax-rules. Надо постараться очень, чтоб на них написать читаемо, если только не реализуешь очередную примитивную чушь вроде очередного for или там враппера для let и if. А вот с defmacro надо постараться, чтоб написать нечитаемо.
А чего стараться-то. С defmacro ВСЕГДА выходит нечитаемая каша. Старайся, не старайся — этого не избежать.
А>> (+15 к илитарности, ага), но вряд ли с Вами согласится кто-нибудь кроме таких же коммонлисперов, как Вы. M> А кто сказал, что я коммонлиспер? Я очень не люблю CL, меня бесит #' и funcall.
Да по степени упорости видно.
А>>Чьорт. Кривая. M> Именно так.
Ога.
А>> Нельзя воспользоваться. M> Да, совершенно невозможно. Для чего либо серьёзного. Для очередного тупенького синтаксического сахара — запросто, а для компиляции сложного DSL — фигушки.
О. Начал вводить граничные условия. Чувствуешь что облажался? Напомнить, чего ты там говорил? Таки давай уже расскажи людям, какие именно макросы нельзя использовать в том же модуле (или TLP), в котором они определены.
А>> Вы таки открыли мне глаза. То, что делается едва ли не в каждом проекте на схеме "на самом деле" делать нельзя. Понабирают, блин, по объявлениям. M> В практически каждом проекте на Схеме метапрограммирование практически не используется.
Идиоты атакуют.
Здравствуйте, Аноним, Вы писали:
M>> Хе хе. Посмешил. R6RS это не стандарт, а фигня. А в R5RS только syntax-rules с гигиеной. А>Ясно, очередной упоротый коммон-лиспер, не читавший Пастернака.
А не пойти ка ли тебе погулять мимо, а? И гулять до тех пор, пока все основные реализации не будут поддерживать R6RS?
И ещё — я не коммонлиспер. Я лет десять на CL не писал. Мой основной инструмент — Схема.
А>Так как насчет syntax-case (можешь начать с добавления гигиены в свой MBE)?
Это тривиальное расширение. Мой вариант показывать не буду — явно не в коня корм.
А>Конечно "не нужны". Кто ж сомневается. Даже в твоем примере — полторы сотни строк только для разбора темплейта.
Ну, это же CL, там всё перанально делается. Важен лишь тот факт, что достаточно сделать это ровно один раз, средствами тупых макр, и больше не париться.
А>Машина тьюринга (ок, можешь взять чистое лямбда-исчисление) — твой выбор. Зачем тебе лишний сахар? К чему это я? Ах да, "туп до невозможности" не означает "проще ничего нет".
Ты чушь несёшь. Феерическую.
А>А почему syntax-rules?
Потому что именно к нему претензии, и вообще к гигиеническим макрам.
А> На syntax-case оно ТОЧНО не будет сложнее defmacro (в худшем случае больше на тот самый десяток строк, необходимый для реализации defmacro на syntax-case),
defmacro на syntax-case — это одна строка, умник ты недоделанный. Если это полноценная реализация syntax-case, а не как обычно.
А> а скорее всего будет значительно проще (ибо деструктуризация входной формы производится автоматически, да и gensym-ами обмазываться не нужно)
Да на хрен не нужна ТАКАЯ деструктуризация. Ты реши, реши мои задачки. Я поржу.
А>Да уж. Когда тебе прямым текстом пишут в коде примеры синтаксиса это, конечно же, очень нечитаемо (паттерн-матчинг не нужен). Все эти car, cadar, caddaar читаются гораздо легче.
Криволапость отдельных лиспокодеров никакого отношения к фундаментальности defmacro не имеет.
M>> Нечитаемость — это как раз про syntax-rules. Надо постараться очень, чтоб на них написать читаемо, если только не реализуешь очередную примитивную чушь вроде очередного for или там враппера для let и if. А вот с defmacro надо постараться, чтоб написать нечитаемо. А>А чего стараться-то. С defmacro ВСЕГДА выходит нечитаемая каша. Старайся, не старайся — этого не избежать.
Как смешно бредит. Даже я так не умею. Тебе уже показали, что этот тупой и убогий вариант pattern matching, который есть в syntax-rules, реализуется тривиально. Так же тривиально реализуются и другие — в том числе и, например, PEG, или любой другой способ описания синтаксиса. Посмеши публику, сделай это на syntax-rules и прочих чисто схемских фичах.
M>> Да, совершенно невозможно. Для чего либо серьёзного. Для очередного тупенького синтаксического сахара — запросто, а для компиляции сложного DSL — фигушки. А>О. Начал вводить граничные условия. Чувствуешь что облажался?
Облажался ты и только ты.
А> Напомнить, чего ты там говорил? Таки давай уже расскажи людям, какие именно макросы нельзя использовать в том же модуле (или TLP), в котором они определены.
Берём, например, свежий SISC или ещё какую практически применимую Схему. Определяем в модуле функцию f, и (define-macro mf (x) (f x)). В том же модуле пытаемся использовать (mf ...). Обламываемся и горько плачем.
А>>> Вы таки открыли мне глаза. То, что делается едва ли не в каждом проекте на схеме "на самом деле" делать нельзя. Понабирают, блин, по объявлениям. M>> В практически каждом проекте на Схеме метапрограммирование практически не используется. А>Идиоты атакуют.
Я вижу, ты самокритичен. Это хорошо. А что такое метапрограммирование ты не знаешь. Попробуй, если не согласен с моим вердиктом и не считаешь себя шибко неумным, реши мои задачки. Инфиксный синтаксис, pattern matching (с ellipsis, конечно же, и с banana brackets в стиле F#). Да ещё обязательно с гигиеной, ведь без гигиены — это же defmacro получится. А, да, чуть не забыл — ещё и list comprehensions сделай. Порадуй почтенную публику.
Здравствуйте, metaprogrammer, Вы писали: M> Хе хе. Посмешил. R6RS это не стандарт, а фигня.
Что не нравится в r6rs?
M> Вот для CL, например, реализация syntax-rules: M>http://www.ccs.neu.edu/home/dorai/mbe/mbe-lsp.html
The Scheme report requires that the macro definers be hygienic, i.e., that they automatically avoid these lexical captures. This Common Lisp implementation does not provide hygiene.
Вроде это-таки никакие не syntax-rules, а просто ими прикидываются? Я что-то не то смотрю?
M>инфиксный синтаксис
Можно пример реализации?
M>pattern matching
match.scm M>list comprehensions.
srfi-42
Здравствуйте, metaprogrammer, Вы писали: M> Благо, во всех нормальных Схемах define-macro имеется. Плохо то, что у него кривая семантика в связке с модулями — как правило нельзя воспользоваться макрой, определённой внутри модуля, в этом самом модуле.
Ну это проблемы этого самого define-macro.
С syntax-rules/case это не всегда так. Chicken-у как правило по барабану. В plt и в r6rs действуют определенные ограничения, связанные с разделением на стадии выполнения, но это не мешает юзать простые макросы:
[cat@cat-arch tmp]$ cat macro.ss
(import (rnrs))
(define f +)
(define-syntax g
(syntax-rules ()
((g stuff ...)
(f stuff ...))))
Здравствуйте, Mr.Cat, Вы писали:
M>> Хе хе. Посмешил. R6RS это не стандарт, а фигня. MC>Что не нравится в r6rs?
То, что работать сейчас надо, а поддерживать его ещё незнамо когда будут.
MC>Вроде это-таки никакие не syntax-rules, а просто ими прикидываются? Я что-то не то смотрю?
Базар не за гигиену был, а за destructuring. Гигиена тоже реализуется, легко.
M>>инфиксный синтаксис MC>Можно пример реализации?
Уже приводил в соседней ветке.
M>>pattern matching MC>match.scm
Без бананов и ..., фигня. И криво сделано.
M>>list comprehensions. MC>srfi-42
Здравствуйте, metaprogrammer, Вы писали: M>Гигиена тоже реализуется, легко.
Ну раз не реализована — видимо, не так легко. Для гигиены нужен, например, полный список биндингов в месте объявления макры. В CL его можно получить?
MC>>Можно пример реализации? M> Уже приводил в соседней ветке.
Напомни плз. ссылку, там вы с thesz так нафлудили, что нифига не найдешь.
M>>>pattern matching MC>>match.scm M> Без бананов
Это кто такие?
M>криво
В чем кривизна (и match, и ec)? Юзал — доволен.
Здравствуйте, metaprogrammer, Вы писали: MC>>Что не нравится в r6rs? M> То, что работать сейчас надо, а поддерживать его ещё незнамо когда будут.
Plt, ikarus, ypsilon, iron, mosh. Особенно первые три.
Здравствуйте, Mr.Cat, Вы писали:
M>> Это раскроется в (f 1 2 3), f в рантайме только вызывается. MC>Ессно, а как тебе надо?
А мне надо из трансформера вызвать функцию, которая тут же была определена. Более того, которая была порождена при раскрытии другой макры, вместе с определением самого этого трансформера.
Здравствуйте, Mr.Cat, Вы писали:
M>> То, что работать сейчас надо, а поддерживать его ещё незнамо когда будут. MC>Plt, ikarus, ypsilon, iron, mosh. Особенно первые три.
Здравствуйте, metaprogrammer, Вы писали: MC>>Ну раз не реализована — видимо, не так легко. Для гигиены нужен, например, полный список биндингов в месте объявления макры. В CL его можно получить? M> Достаточно списка биндингов в самой макре.
Ты имеешь в виду биндингов, вводимых самой макрой? Нет, не достаточно. Один из аспектов гигиены — существующие в месте объявления макры биндинги, если они используются в макре, не должны перекрываться одноименными биндингами, существующими в месте использования макры.
M>http://pastebin.org/13419
Благодарю.
M> Это banana brackets в F#.
Это они: http://en.wikibooks.org/wiki/F_Sharp_Programming/Active_Patterns ?
Непонятно, зачем они нужны в scheme, это ведь свсего лишь "анонимные типы" — чтобы не объявлять вручную лишних типов в статически типизированном языке. Не?
M>>>криво MC>>В чем кривизна (и match, и ec)? Юзал — доволен. M> В реализации. Сложно.
Не буду спорить: арбуз и свиной хрящик.
Здравствуйте, metaprogrammer, Вы писали: M>http://pastebin.org/13419
А чем, если не секрет, там мешает гигиена?
И да, что за либа используется для определения парсера?
Здравствуйте, metaprogrammer, Вы писали: M> А мне надо из трансформера вызвать функцию, которая тут же была определена. Более того, которая была порождена при раскрытии другой макры, вместе с определением самого этого трансформера.
Это вроде можно в chicken — попробуй. В plt и r6rs с этим сложнее, да.
Здравствуйте, metaprogrammer, Вы писали: MC>>Plt, ikarus, ypsilon, iron, mosh. Особенно первые три. M> Ни одна из них не подходит, по разным причинам.
То есть дело не в r6rs, а в тебе.
Тьфу ты, ошибся. Это-то можно реализовать и без списка внешних биндингов.
А вот как повторить сочетание гигиены и модулей? Например, в r6rs макрос может ссылаться на определенные в модуле неэкспортируемые идентификаторы:
Здравствуйте, metaprogrammer, Вы писали: M>(Infix "a+a").
Емнип, если ты откажешься от закавычивания — получишь возможность ссылаться на внешние биндинги:
(infix a + a)
Но такие вещи, кочнечно, проще делать без гигиены (хотя надо-таки будет попробовать сделать гигиенический инфиксный).
M> Честно говоря, я вообще не понимаю, на фига нужна гигиена.
Мой философский (т.е. в отрыве от практических задач) взгляд лежит здесь: http://rsdn.ru/forum/message/3285913.1.aspx
На практике же 100% гигиена, бывает, мешает реализации тех или иных вещей. Но для тех, имхо, не очень многочисленных случаев придумана отключаемая гигиена.
Здравствуйте, metaprogrammer, Вы писали: M> А вообще — поглядываю на Iron Scheme
Там вроде была проблема с call/cc (когда leppie включал полноценные континуации — начинались тормоза) — не знаю, исправлено уже или нет.
Здравствуйте, metaprogrammer, Вы писали: M> Честно говоря, я вообще не понимаю, на фига нужна гигиена.
И да, гигиена хорошо сочетается с другими проявлениями концепции областей видимости. Например, с модулями.
Re[11]: Scheme to be split into two language
От:
Аноним
Дата:
31.08.09 02:43
Оценка:
Здравствуйте, metaprogrammer, Вы писали:
Общелиспер великолепен в своей незамутненной тупости.
M> А не пойти ка ли тебе погулять мимо, а? И гулять до тех пор, пока все основные реализации не будут поддерживать R6RS?
Дай угадаю. Те, что не поддерживают — не основные?
M> И ещё — я не коммонлиспер. Я лет десять на CL не писал. Мой основной инструмент — Схема.
Коммонлиспер.
А>>Так как насчет syntax-case (можешь начать с добавления гигиены в свой MBE)? M> Это тривиальное расширение. Мой вариант показывать не буду — явно не в коня корм.
Ну ясен пень. Ленивое программирование освобождает столько времени для троллинга.
А>>Конечно "не нужны". Кто ж сомневается. Даже в твоем примере — полторы сотни строк только для разбора темплейта. M> Ну, это же CL, там всё перанально делается. Важен лишь тот факт, что достаточно сделать это ровно один раз, средствами тупых макр, и больше не париться.
Ну вот оно ровно один раз сделано в схеме. Я разве утверждаю, что чего то нельзя сделать в тьюринг-полном языке?
А>>Машина тьюринга (ок, можешь взять чистое лямбда-исчисление) — твой выбор. Зачем тебе лишний сахар? К чему это я? Ах да, "туп до невозможности" не означает "проще ничего нет". M> Ты чушь несёшь. Феерическую.
Да нет. Если тебе нравится тупость и незамутненность — пиши на брейнфаке. Так будет проще.
А>>А почему syntax-rules? M> Потому что именно к нему претензии, и вообще к гигиеническим макрам.
Перечитай еще раз. Я ИЗНАЧАЛЬНО говорил о syntax-case. Ты начал задвигать про их ограниченность и тривиальность реализации. Примеров конечно же привести не смог.
А>> На syntax-case оно ТОЧНО не будет сложнее defmacro (в худшем случае больше на тот самый десяток строк, необходимый для реализации defmacro на syntax-case), M> defmacro на syntax-case — это одна строка, умник ты недоделанный. Если это полноценная реализация syntax-case, а не как обычно.
Удавка затягивается. Жду однострочник (ты всегда сможешь выкрутиться объединив десять SLoC в одну).
А>> а скорее всего будет значительно проще (ибо деструктуризация входной формы производится автоматически, да и gensym-ами обмазываться не нужно) M> Да на хрен не нужна ТАКАЯ деструктуризация. Ты реши, реши мои задачки. Я поржу.
Я тебе сразу говорю, что задачи сильно объемные, чтоб решать их только для того, чтобы ПОПЫТАТЬСЯ чего то доказать тупому общелисповому троллю (хотя весь опыт, накопленный человечеством, говорит, что троллю ничего доказать нельзя — его можно только контртроллить). Ты же сказал, что реализация syntax-case тривиальна — за язык я тебя не тянул — но все еще не можешь разродиться хотя бы полноценной деструктуризацией, не говоря уже о гигиене (хотя бы уровня syntax-rules)
А>>Да уж. Когда тебе прямым текстом пишут в коде примеры синтаксиса это, конечно же, очень нечитаемо (паттерн-матчинг не нужен). Все эти car, cadar, caddaar читаются гораздо легче. M> Криволапость отдельных лиспокодеров никакого отношения к фундаментальности defmacro не имеет.
Я ждал этого момента. Лучший конпелятор коммонлиспа написан криволапыми лиспокодерами. Фишка в том, что лучше не бывает.
M> Как смешно бредит. Даже я так не умею. Тебе уже показали, что этот тупой и убогий вариант pattern matching, который есть в syntax-rules, реализуется тривиально. Так же тривиально реализуются и другие — в том числе и, например, PEG, или любой другой способ описания синтаксиса. Посмеши публику, сделай это на syntax-rules и прочих чисто схемских фичах.
Сливай сливай, зелененький. Я от тебя только и прошу, что тривиальную реализацию syntax-case.
M>>> Да, совершенно невозможно. Для чего либо серьёзного. Для очередного тупенького синтаксического сахара — запросто, а для компиляции сложного DSL — фигушки. А>>О. Начал вводить граничные условия. Чувствуешь что облажался? M> Облажался ты и только ты.
Ути-пути. Какие мы серьезные. Главное громогласно заявить о своей победе в споре. Все остальные просто вынуждены будут с тобой согласиться.
А>> Напомнить, чего ты там говорил? Таки давай уже расскажи людям, какие именно макросы нельзя использовать в том же модуле (или TLP), в котором они определены. M> Берём, например, свежий SISC или ещё какую практически применимую Схему. Определяем в модуле функцию f, и (define-macro mf (x) (f x)). В том же модуле пытаемся использовать (mf ...). Обламываемся и горько плачем.
Вот, пример TLP (семантически очень близок к модулям):
Каким то магическим образом таки выводит 1.
А>>Идиоты атакуют. M> Я вижу, ты самокритичен. Это хорошо. А что такое метапрограммирование ты не знаешь.
Говоришь на меня — переводишь на себя. Тупость общелисперов не знает границ.
M> Попробуй, если не согласен с моим вердиктом и не считаешь себя шибко неумным, реши мои задачки. Инфиксный синтаксис, pattern matching (с ellipsis, конечно же, и с banana brackets в стиле F#). Да ещё обязательно с гигиеной, ведь без гигиены — это же defmacro получится. А, да, чуть не забыл — ещё и list comprehensions сделай. Порадуй почтенную публику.
Обязательно так и сделаю, как только получу "тривиальную" реализацию syntax-case.
Re[15]: Scheme to be split into two language
От:
Аноним
Дата:
31.08.09 03:09
Оценка:
Здравствуйте, metaprogrammer, Вы писали:
MC>>А чем, если не секрет, там мешает гигиена? M> Хотя бы тем, что нельзя определить, откуда имена пришли — сгенерены или подставленны извне. В ситуации, например, с (let ((a 2)) (Infix "a+a")).
И каким образом в этом случае может помешать гигиена? Она мешает захватывать идентификаторы из внешних контекстов?
Не хочешь ли ты сказать, что вот это (infix не более упрощенный, чем твой "syntax-case") не запустится? И все из-за этой б$%кой топологии... тьфу гигиены.
(define-syntax infix
(syntax-rules (+ -)
((_ a) a)
((_ a + rest ...) (+ a (infix rest ...)))
((_ a - rest ...) (- a (infix rest ...)))))
(let ([a 1])
(infix a + a - 1))
M> Честно говоря, я вообще не понимаю, на фига нужна гигиена.
Не так. Ты не понимаешь, ЧТО ТАКОЕ гигиена.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, metaprogrammer, Вы писали:
А>Общелиспер великолепен в своей незамутненной тупости.
А ты однако хамло. Думаешь, с хамлом кто либо станет говорить как с человеком? Заблуждаешься.
M>> А не пойти ка ли тебе погулять мимо, а? И гулять до тех пор, пока все основные реализации не будут поддерживать R6RS? А>Дай угадаю. Те, что не поддерживают — не основные?
Дай угадаю. У тебя серьёзные проблемы с психикой, да?
А>>>Так как насчет syntax-case (можешь начать с добавления гигиены в свой MBE)? M>> Это тривиальное расширение. Мой вариант показывать не буду — явно не в коня корм. А>Ну ясен пень. Ленивое программирование освобождает столько времени для троллинга.
Троллишь тут только ты.
А>>>Конечно "не нужны". Кто ж сомневается. Даже в твоем примере — полторы сотни строк только для разбора темплейта. M>> Ну, это же CL, там всё перанально делается. Важен лишь тот факт, что достаточно сделать это ровно один раз, средствами тупых макр, и больше не париться. А>Ну вот оно ровно один раз сделано в схеме.
Более того — оно сделано средствами более простой макросистемы, как правило.
А> Я разве утверждаю, что чего то нельзя сделать в тьюринг-полном языке?
Ты утверждаешь, что более сложная макросистема является более фундаментальной, тогда как она реализуется на более простой.
А>>>Машина тьюринга (ок, можешь взять чистое лямбда-исчисление) — твой выбор. Зачем тебе лишний сахар? К чему это я? Ах да, "туп до невозможности" не означает "проще ничего нет". M>> Ты чушь несёшь. Феерическую. А>Да нет. Если тебе нравится тупость и незамутненность — пиши на брейнфаке. Так будет проще.
Хамло ты. Очень неумное хамло.
А>>>А почему syntax-rules? M>> Потому что именно к нему претензии, и вообще к гигиеническим макрам. А> Перечитай еще раз. Я ИЗНАЧАЛЬНО говорил о syntax-case.
Ты глуп. syntax-case — это макросистема с гигиеной и с обобщёнными трансформерами, то есть, с аналогом defmacro. Ты утверждаешь, что эта система проще и фундаментальнее, чем только defmacro. Так что обсуждению подлежит только syntax-rules, тем более что именно на них твои смешные примеры сделаны.
А> Ты начал задвигать про их ограниченность и тривиальность реализации. Примеров конечно же привести не смог.
Примеры для людей. Не для тупых отморозков.
А>Я тебе сразу говорю, что задачи сильно объемные,
Слил, лошара.
А> Ты же сказал, что реализация syntax-case тривиальна — за язык я тебя не тянул — но все еще не можешь разродиться хотя бы полноценной деструктуризацией, не говоря уже о гигиене (хотя бы уровня syntax-rules)
У меня такая реализация есть. Но ты рыльцем не вышел, чтоб её обсуждать. В конце концов, реализации Схемы я писал, в отличии от тебя, тупого теоретика.
А> Я ждал этого момента. Лучший конпелятор коммонлиспа написан криволапыми лиспокодерами.
А тебя, дурака, это удивляет?
А> Фишка в том, что лучше не бывает.
Фишка в том, что половина Схем написана поверх таких макросистем.
А>Сливай сливай, зелененький. Я от тебя только и прошу, что тривиальную реализацию syntax-case.
Рыльцем ты не вышел, чтоб что либо просить. Ты хамло. Пусть кто либо другой попросит.
А>(mf 1)
А>Каким то магическим образом таки выводит 1.
f в рантайме вызывается.
А>Обязательно так и сделаю, как только получу "тривиальную" реализацию syntax-case.
Здравствуйте, Аноним, Вы писали:
А>И каким образом в этом случае может помешать гигиена? Она мешает захватывать идентификаторы из внешних контекстов?
Она мешает различать, какие идентификаторы новые, а какие введены преднамеренно.
А>Не хочешь ли ты сказать, что вот это (infix не более упрощенный, чем твой "syntax-case") не запустится? И все из-за этой б$%кой топологии... тьфу гигиены.
У него на входе не строка, гигиену им не обманешь.
M>> Честно говоря, я вообще не понимаю, на фига нужна гигиена. А>Не так. Ты не понимаешь, ЧТО ТАКОЕ гигиена.
Смешной буратинка ты. Я понимаю, что такое гигиена, я её реализовывал десятки раз в разных макросистемах. Я не понимаю, на хрена она нужна, и почему некоторые несознательные граждане из несознательных комитетов ей так озабочены. Практической пользы от гигиены нет.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, metaprogrammer, Вы писали: M>> А вообще — поглядываю на Iron Scheme MC>Там вроде была проблема с call/cc (когда leppie включал полноценные континуации — начинались тормоза) — не знаю, исправлено уже или нет.
Это .net, там continuations без тормозов принципиально реализовать нельзя. Только через CPS с трамплинами, или ещё как по тормозному.
Re[13]: Scheme to be split into two language
От:
Аноним
Дата:
31.08.09 05:12
Оценка:
Собственно все ясно. На прямые вопросы не отвечаешь, допускаешь грубейшие ошибки, демонстративно "обижаешься", бравируешь собственной "крутостью", которую, однако, не можешь продемонстрировать (да и по остальным твоим комментариям видно, что ничего, представляющего из себя хоть какую то ценность там и не валялось). Удачи в дописывании "тривиального" syntax-case и освоении ОСНОВ схемы.
Здравствуйте, metaprogrammer, Вы писали:
M> Смешной буратинка ты. Я понимаю, что такое гигиена, я её реализовывал десятки раз в разных макросистемах. Я не понимаю, на хрена она нужна, и почему некоторые несознательные граждане из несознательных комитетов ей так озабочены. Практической пользы от гигиены нет.
Я не тот злой аноним, но все же вмешаюсь. Польза для меня есть одна и очень существенная, она защищает от глупых ошибок.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, metaprogrammer, Вы писали: M>по тормозному M>CPS M>с трамплинами
CPS по идее не должен особо тормозить, тем более в дотнете, где вроде есть нормальная поддержка хвостовых вызовов.
Чувак писал, что юзает dlr и что проблема с хвостовыми вызовами где-то в нем.
Здравствуйте, Аноним, Вы писали:
А>Собственно все ясно. На прямые вопросы не отвечаешь, допускаешь грубейшие ошибки, демонстративно "обижаешься", бравируешь собственной "крутостью", которую, однако, не можешь продемонстрировать (да и по остальным твоим комментариям видно, что ничего, представляющего из себя хоть какую то ценность там и не валялось). Удачи в дописывании "тривиального" syntax-case и освоении ОСНОВ схемы.
Пшел вон, быдло. Я не обижаюсь — на дураков и хамов не обижаются. Просто не опускаюсь до обсуждения интересных и важных тем с такими ничтожествами, как ты. И ты бы хотя бы аналогичную моей реализацию инфиксного синтаксиса выродил — тогда был бы разговор.
P.S. для всех прочих, не для хамоватого ничтожества: занятно, что находятся глупцы, не считающие syntax-case тривиальным. Это одна из самых примитивных форм pattern matching.
P.P.S. и я таки конкретно облажался, да, когда говорил о том, что syntax-case равномощен define-macro. Это не так. Стандарт позволяет ограничивать окружение трансформеров.
Здравствуйте, Mr.Cat, Вы писали:
MC>CPS по идее не должен особо тормозить, тем более в дотнете, где вроде есть нормальная поддержка хвостовых вызовов. MC>Чувак писал, что юзает dlr и что проблема с хвостовыми вызовами где-то в нем.
Дык, ведь нормальной поддержки хвостовых вызовов до сих пор нет, даже в Моно насколько мне известно было с этим получше.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Я не тот злой аноним, но все же вмешаюсь.
Оно не злое. Оно малолетнее и безмозглое.
Y> Польза для меня есть одна и очень существенная, она защищает от глупых ошибок.
Я использую метапрограммирование гораздо в больших масштабах, чем это обычно делается всеми другими в коде на Лиспе или Схеме. И ни разу за всю мою практику я не сталкивался с ошибками, которые должна предотвращать гигиена. Вообще ни разу. А вот ограничения гигиены мне бы мешали на каждом шагу.
Здравствуйте, yumi, Вы писали:
MC>>CPS по идее не должен особо тормозить, тем более в дотнете, где вроде есть нормальная поддержка хвостовых вызовов. MC>>Чувак писал, что юзает dlr и что проблема с хвостовыми вызовами где-то в нем.
Y>Дык, ведь нормальной поддержки хвостовых вызовов до сих пор нет,
Нормальная она, медленнее обычных вызовов процентов на 20 в самом худшем случае. Проблема не в этом, а в оверхеде на реализации замыканий, которые плодятся при CPS.
Y> даже в Моно насколько мне известно было с этим получше.
В моно, кстати, не на всех платформах .tail работает.
Здравствуйте, metaprogrammer, Вы писали: А>>Сливай сливай, зелененький. Я от тебя только и прошу, что тривиальную реализацию syntax-case. M> Рыльцем ты не вышел, чтоб что либо просить. Ты хамло. Пусть кто либо другой попросит.
А что ее просить-то? Вон она, psyntax называется (точнее — это имплементация большого куска r6rs). Что-то около 4000 строк кода, кажется.
M> f в рантайме вызывается.
Я давал ссылку на пример, работающий в chicken scheme и где трансформер юзает функции из того же файла. Принципиальных препятствий этому нет — только искусственное ограничение.
Здравствуйте, yumi, Вы писали: Y>Дык, ведь нормальной поддержки хвостовых вызовов до сих пор нет, даже в Моно насколько мне известно было с этим получше.
Честно говоря, я не в курсе. Просто передаю, что слышал.
Здравствуйте, Mr.Cat, Вы писали:
MC>CPS по идее не должен особо тормозить, тем более в дотнете, где вроде есть нормальная поддержка хвостовых вызовов.
Тормоза при CPS берутся от расходов на замыкания, от черзмерного количества вызовов и от мелкого размера каждой функции, что отрубает все возможности для оптимизации. Чтоб CPS-ный код не тормозил — это уж очень специализированная VM нужна.
MC>Чувак писал, что юзает dlr и что проблема с хвостовыми вызовами где-то в нем.
Здравствуйте, metaprogrammer, Вы писали: M> Нормальная она, медленнее обычных вызовов процентов на 20 в самом худшем случае. Проблема не в этом, а в оверхеде на реализации замыканий, которые плодятся при CPS.
Даже если используются более-менее умные cps-трансформеры? Наивное преобразование — да, плодит замыкания, но про борьбу с этим чуть ли не докторские пишут.
Здравствуйте, metaprogrammer, Вы писали: M> Тормоза при CPS берутся от расходов на замыкания, от черзмерного количества вызовов и от мелкого размера каждой функции, что отрубает все возможности для оптимизации.
Тут не могу прокомментировать — не знаю. А чем вредны мелкие функции? Малая длина "последовательного" кода и частые безусловные переходы как-то влияют?
M>Чтоб CPS-ный код не тормозил — это уж очень специализированная VM нужна.
Хм, а не дашь ссылочек на более оптимальный способ сделать call/cc? Любопытно.
Здравствуйте, Mr.Cat, Вы писали:
MC>Даже если используются более-менее умные cps-трансформеры? Наивное преобразование — да, плодит замыкания, но про борьбу с этим чуть ли не докторские пишут.
Да даже самые умные плодят замыкания. Требование "каждый вызов — хвостовой" мешает любым возможным оптимизациям. Можно не плодить ненужные административные лямбды, но как минимум по лямбде на каждый вызов получится всё равно.
Здравствуйте, Mr.Cat, Вы писали:
MC>А что ее просить-то? Вон она, psyntax называется (точнее — это имплементация большого куска r6rs). Что-то около 4000 строк кода, кажется.
Это из бывшего SRFI? Там не только syntax-case, там много всякой шелухи.
M>> f в рантайме вызывается. MC>Я давал ссылку на пример, работающий в chicken scheme и где трансформер юзает функции из того же файла. Принципиальных препятствий этому нет — только искусственное ограничение.
В chicken сработает, в plt — уже не обязательно. Стандарт не оговаривает окружение, доступное из трансформеров.
Здравствуйте, Mr.Cat, Вы писали:
M>> Тормоза при CPS берутся от расходов на замыкания, от черзмерного количества вызовов и от мелкого размера каждой функции, что отрубает все возможности для оптимизации. MC>Тут не могу прокомментировать — не знаю. А чем вредны мелкие функции?
У JIT очень мало времени на оптимизации. Так что ничего умного и сложного он делать не может. А при хвостовых вызовах не может даже инлайнить (он и так это не очень охотно делает). Более крупные методы оптимизируются лучше.
MC>Хм, а не дашь ссылочек на более оптимальный способ сделать call/cc? Любопытно.
Да даже знаменитый 90 minutes scheme compiler даёт более-менее эффективное решение. Тоже CPS, причём наивный — но при трансляции в Си всё это намного дешевле, чем в .NET.
Здравствуйте, metaprogrammer, Вы писали: M> Это из бывшего SRFI? Там не только syntax-case, там много всякой шелухи.
Наверное. Там еще модули как минимум. Но без модулей гигиена уже не та.
M>>> f в рантайме вызывается. M> В chicken сработает, в plt — уже не обязательно. Стандарт не оговаривает окружение, доступное из трансформеров.
Угу, что в r6rs, что в plt начинаются пласки, когда появляется много стадий выполнения (больше, чем 2).
Здравствуйте, metaprogrammer, Вы писали: M> Да даже знаменитый 90 minutes scheme compiler даёт более-менее эффективное решение. Тоже CPS, причём наивный — но при трансляции в Си всё это намного дешевле, чем в .NET.
Его точно так же можно транслировать в дотнет. Дотнет загнется от большого количества "джампов"?
Здравствуйте, Mr.Cat, Вы писали:
MC>Наверное. Там еще модули как минимум. Но без модулей гигиена уже не та.
Модули с полноценным метапрограммированием вообще хреново сочетаются.
MC>Угу, что в r6rs, что в plt начинаются пласки, когда появляется много стадий выполнения (больше, чем 2).
Именно. Стандарт хоть модули и описал, но оставил много простора для отсебятины.
Здравствуйте, metaprogrammer, Вы писали:
M> Я использую метапрограммирование гораздо в больших масштабах, чем это обычно делается всеми другими в коде на Лиспе или Схеме. И ни разу за всю мою практику я не сталкивался с ошибками, которые должна предотвращать гигиена. Вообще ни разу. А вот ограничения гигиены мне бы мешали на каждом шагу.
А я за свою практику сталкивался, да и вообще, человек я рассеянный и глупый, мне нужно, чтобы мой инструмент не давал мне возможности делать глупые и трудноуловимые ошибки. Пишешь себе макрос, отлаживаешь, все вроде бы работает отличненько, начинаешь его юзать везде, где надо и тут начинается веселье, маловнятные ошибки, макрос отлажен, работает 100%, претензий к нему никаких. И тут опачки, протечка абстракции в макросе в виде неэкранированной генсимом внутренней переменной.
Конечно, этого довольно легко избежать, если выработать в себе ряд правил и всегда их придерживаться.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, metaprogrammer, Вы писали:
M> Нормальная она, медленнее обычных вызовов процентов на 20 в самом худшем случае. Проблема не в этом, а в оверхеде на реализации замыканий, которые плодятся при CPS. M> В моно, кстати, не на всех платформах .tail работает.
Да, отстал я от жизни видимо, надо будет освежить свои знания.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>А я за свою практику сталкивался,
Научи!
Y> да и вообще, человек я рассеянный и глупый, мне нужно, чтобы мой инструмент не давал мне возможности делать глупые и трудноуловимые ошибки.
1. Use Haskell
2. Проблема не в инструменте, а в методологии. При правильном подходе никаких проблем с именами быть не может и не должно.
Y> Пишешь себе макрос, отлаживаешь, все вроде бы работает отличненько, начинаешь его юзать везде, где надо и тут начинается веселье, маловнятные ошибки, макрос отлажен, работает 100%, претензий к нему никаких. И тут опачки, протечка абстракции в макросе в виде неэкранированной генсимом внутренней переменной.
Ради такой фигни, как собственные биндинги, и городить целую гигиену? Перанальное решение.
Y> Конечно, этого довольно легко избежать, если выработать в себе ряд правил и всегда их придерживаться.
Именно. Без них и с гигиеной код будет нечитабельным уродством.
Здравствуйте, metaprogrammer, Вы писали:
M> 1. Use Haskell
But sometimes I do...
M> 2. Проблема не в инструменте, а в методологии. При правильном подходе никаких проблем с именами быть не может и не должно.
Вот об этом я тебе и говорил ниже, но до выработки этой методологии нужно еще дожить, и особенно это актуально для маленького учебного языка вроде Схемы.
M> Ради такой фигни, как собственные биндинги, и городить целую гигиену? Перанальное решение.
Здравствуйте, yumi, Вы писали:
Y>Вот об этом я тебе и говорил ниже, но до выработки этой методологии нужно еще дожить, и особенно это актуально для маленького учебного языка вроде Схемы.
Я уже ранее писал, что в учебном языке никакими defmacro даже вонять не должно. Это убойный инструмент для профессионалов.
Y>Ну можно конечно примерно как-то так,
Так и делается.
Y>Но проблема все равно остается, можно забыть использовать with-gensym.
Много чего забыть можно.
Проблема в том, что при многоуровневом метапрограммировании запаришься отслеживать, кто и где вводит новые имена. Потому и проще везде использовать gensym, и не надеяться на гигиену.
M>> Именно. Без них и с гигиеной код будет нечитабельным уродством.
Y>О да, а куча (let ((variable-name (gensym)) ... в коде макроса добавляют читабельности...
Здравствуйте, metaprogrammer, Вы писали:
M> Проблема в том, что при многоуровневом метапрограммировании запаришься отслеживать, кто и где вводит новые имена. Потому и проще везде использовать gensym, и не надеяться на гигиену.
Я может плохо гигиену понимаю (да, на Схеме я почти не писал), но мне всегда казалось что именно для этого и нужна гигиена, чтобы не париться и не отслеживать кто и где вводит новые имена и что гигиена это грубо говоря автоматическое использование gensym везде где можно
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>Я может плохо гигиену понимаю (да, на Схеме я почти не писал), но мне всегда казалось что именно для этого и нужна гигиена, чтобы не париться и не отслеживать кто и где вводит новые имена и что гигиена это грубо говоря автоматическое использование gensym везде где можно
В том и дело, что тогда надо париться и отслеживать, где наоборот переименовывать нельзя (и это более частый случай, кстати). А поскольку семантика у гигиены весьма сложна, то ошибиться на этом пути намного проще, чем при ручной раздаче имён.
В качестве примера задачи, где введённые при раскрытии макры биндинги нельзя переименовывать — любой pattern matching.
Здравствуйте, metaprogrammer, Вы писали:
M> В том и дело, что тогда надо париться и отслеживать, где наоборот переименовывать нельзя (и это более частый случай, кстати). А поскольку семантика у гигиены весьма сложна, то ошибиться на этом пути намного проще, чем при ручной раздаче имён.
А, все, я понял. Да, ты прав.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, metaprogrammer, Вы писали: MC>>много стадий выполнения (больше, чем 2).
Имел в виду три, конечно: expand, компиляция и выполнение — это все можно в r6rs в 1 модуле уместить. Больше вроде не влазит.
M> Именно. Стандарт хоть модули и описал, но оставил много простора для отсебятины.
Не обратил внимание, где там отсебятина. В одном модуле экспортишь, в другом импортишь for expand.
Здравствуйте, metaprogrammer, Вы писали: M> Один метод с большим селектом — не загнётся, очень даже эффективно получается. Но динамически такой код генерить уже нельзя.
Почему нельзя динамически?
Здравствуйте, metaprogrammer, Вы писали: M> В качестве примера задачи, где введённые при раскрытии макры биндинги нельзя переименовывать — любой pattern matching.
А они и не переименовываются. Если ты биндишь к пришедшему в макрос извне идентификатору — все ок.
Mr.Cat wrote:
> Теперь твоя очередь рассказывать, чем cl лучше схемы.
Ну я -то схемы не знаю толком, чтобы сравнивать.
CL -- промышленно применимый язык. Он готов для разработки.
Со схемой в этом отношении -- я не могу дать гарантий.
Здравствуйте, Mr.Cat, Вы писали:
M>> В качестве примера задачи, где введённые при раскрытии макры биндинги нельзя переименовывать — любой pattern matching. MC>А они и не переименовываются. Если ты биндишь к пришедшему в макрос извне идентификатору — все ок.
Тут создаются новые биндинги для x и y, и если бы тут была гигиена, то она бы защитила от внутреннего переопределения (do-something x y), в результате чего получился бы конфуз.
Не, гигиена — штука запредельно бесполезная. Вреда от неё полно — ограничения на возможности метапрограммирования, сложная и потенциально глюкоёмкая семантика, а вот пользы — ни-ка-кой. Совершенно никакой.
И кстати о гигиенах и прочей фигне. Вот этот код ни в Ypsilon, ни в PLT не работает:
И не работает он по вполне понятным причинам. Что делает вообще хоть немного сложное метапрограммирование в Схемах без define-macro просто невозможным. Те, кто любит кричать за гигиену, всегда приводят в пример только всякую чушь — очередную макру let или там while. А макры — они вовсе не для того нужны, чтоб такие примитивные конструкции в язык добавлять, у них намного более широкая область применения.
Ещё кстати интересная неоднозначность — далеко не все Схемы понимают (begin (define ...) (define-macro ...) ...) в топлевеле. Соответственно, если одна макра не может раскрыться в несколько топлевел-определений, то это тоже сразу делает метапрограммирование в таком языке убогим и ни к чему полезному не пригодным.
Ещё одна гадость — невозможность передачи контекста между разными макрами. Простейшее (хоть и малость хаковатое) решение — это возможность контроля за порядком раскрытия макроопределений. В большинстве Схем тоже нереализуемо.
В общем, для серьёзного метапрограммирования голый R6RS не годится (про убогий R5RS с его syntax-rules я и вовсе помолчу). Рулят только Схемы, где есть define-macro из коробки.
Аноним 585 wrote:
> CL — write only каша, где глазу не за что зацепиться. В схеме не только > сразу виден синтаксис DSL-а, который вводится макросами, но и сразу > видно как его расширять.
1) ты привёл ссылку на внутренний код SBCL, он вообще не предназначен для
чтения нормальными людьми. Это — грубо говоря, вообще не common lisp.
2) loop в CL обсуждать вообще бессмысленно, многие его не любят, им не пользуются.
3) думаю, всё остальное достаточно субъективно.
ЗЫ: прочитал топик до конца, нет, я больше сюда не пишу
Почему схема может быть лучше я тоже не понял. Я понял,
что не пойму, пока не изучу схему так же хорошо, как я знаю CL.
Спасибо всем.
Здравствуйте, Mr.Cat, Вы писали:
M>> Один метод с большим селектом — не загнётся, очень даже эффективно получается. Но динамически такой код генерить уже нельзя. MC>Почему нельзя динамически?
А как? Каждый раз при добавлении нового определения перекомпилировать всё? Так в .NET даже class GC отсутствует.
Здравствуйте, MasterZiv, Вы писали:
MZ>ЗЫ: прочитал топик до конца, нет, я больше сюда не пишу MZ>Почему схема может быть лучше я тоже не понял. Я понял, MZ>что не пойму, пока не изучу схему так же хорошо, как я знаю CL.
Мне хватает одного аргумента — семантика (функционального подмножества) Схемы ближе к лябмда-исчислению. Так что изучать не Схему надо, а лямбда-исчисление, чтоб понять претензии к CL.
А зачем так дизайнить макры? Надо чтобы писалось примерно так:
(let ((x the-other-x-value))
(match something ((tag x . y) (do-something x y))))
Тогда к x и y можно будет делать биндинг, видимый для do-something. Погляди match.scm.
M>И кстати о гигиенах и прочей фигне. Вот этот код ни в Ypsilon, ни в PLT не работает: M> http://pastebin.org/13682
Каюсь, прочитал довольно поверхностно, но тебе вроде бы всего-то и надо — разбить на пару модулей, не?
M>Ещё кстати интересная неоднозначность — далеко не все Схемы понимают (begin (define ...) (define-macro ...) ...) в топлевеле.
Вообще-то сплайс бегина чуть ли не в r5rs есть. В r6rs точно.
M>Ещё одна гадость — невозможность передачи контекста между разными макрами. Простейшее (хоть и малость хаковатое) решение — это возможность контроля за порядком раскрытия макроопределений. В большинстве Схем тоже нереализуемо.
Порядок в r6rs стандартизован. А как его контролируют с defmacro?
M>В общем, для серьёзного метапрограммирования голый R6RS не годится (про убогий R5RS с его syntax-rules я и вовсе помолчу). Рулят только Схемы, где есть define-macro из коробки.
Ну если серьезное метапрограммирование — это куча макросов, вводящих левые биндинги (пишешь ~x — биндишь к x, не понимаю смысла в этом), и все в одно файле — то да.
Здравствуйте, metaprogrammer, Вы писали: M> Нет. Не надо. tag — константа. Как отделишь от биндингов? Такой убогий match не нужен — надо разделять биндинги и символы. Соответственно, содержимое символов приходится парсить.
Их можно матчить в syntax-rules. Просто указываешь в опредлении макры, что tag — не синтаксическая переменная, а должен встретиться такой символ.
M>Везде гигиена только навредила бы.
Вредит часто не гигиена, а неумение (нежелание) ее использовать. Паттерн-мачинг прекрасно реализуется с гигиеной. Инфиксный синтаксис навскидку тоже. Def:ast не смотрел.
M> Однако некоторые реализации его не понимают.
Не встречал. Видать, что-то сравнительно древнее.
M> Серьёзное метапрограммирование — это реализация компилируемых eDSLей.
DSL DSLю рознь.
M> http://lambda-the-ultimate.org/node/3281
Интересненько
Здравствуйте, Mr.Cat, Вы писали:
MC>Их можно матчить в syntax-rules. Просто указываешь в опредлении макры, что tag — не синтаксическая переменная, а должен встретиться такой символ.
На syntax-rules ты вообще не сделаешь нормальный pattern matching, в принципе.
И как это я укажу "при определении макры"? А если я хочу матчить, например ((for $$M:id in $expr1 do $expr2) ...)?
Где мне указывать, что for, in и do — символы? Как мне проще и короче указать, что id — непременно символ, а не число или список?
Зачем мне прогибаться под уродство гигиены, если без неё лучше? Всегда лучше, без исключений. Инструмент не должен навязывать мне свои нелепые ограничения.
M>>Везде гигиена только навредила бы. MC>Вредит часто не гигиена, а неумение (нежелание) ее использовать.
Ну а с чего бы желать использовать что-то настолько кривое и неудобное? Мне код писать надо, а не изобретать кривые хитрые способы обмана гигиены.
MC> Паттерн-мачинг прекрасно реализуется с гигиеной.
Нет, не реализуется.
MC> Инфиксный синтаксис навскидку тоже.
Не реализуется, только исключительно уродские варианты.
MC> Def:ast не смотрел.
А макросистема должна быть универсальной. Чтоб любые DSLи можно было делать. Гигиена неуниверсальна, и при этом никакой пользы от гигиены нет и быть не может.
M>> http://lambda-the-ultimate.org/node/3281 MC>Интересненько
Посмотри, там в документации полностью исходники приведены. С гигиеной так сделать нельзя, вообще.
Здравствуйте, MasterZiv, Вы писали: MZ>CL -- промышленно применимый язык. Он готов для разработки. MZ>Со схемой в этом отношении -- я не могу дать гарантий.
Сосбсно, эта ветка отчасти следствие того, что схему хотят сделать пригодным для серьезной разработки языком. Пока практика ее использования "неровная": кто-то юзает plt в вебе, автор ypsilon пишет на ней какой-то шароварный софт (могу ошибаться), ну и т.д.
Здравствуйте, metaprogrammer, Вы писали: M> И как это я укажу "при определении макры"? А если я хочу матчить, например ((for $$M:id in $expr1 do $expr2) ...)? M>Где мне указывать, что for, in и do — символы?
(define-syntax for
(syntax-rules (in do) ...
M>Как мне проще и короче указать, что id — непременно символ, а не число или список?
Проще и короче — нигде, т.к. ты все равно к нему будешь биндить.
M>>Где мне указывать, что for, in и do — символы?
MC>(define-syntax for MC> (syntax-rules (in do) ...
Во первых, это криво. Представь, что у тебя под сотню паттёрнов...
Во вторых, syntax-rules средствами syntax-rules не реализуется. А сам он для произвольных списков, векторов и прочего не приспособлен, он для syntax objects только.
M>>Как мне проще и короче указать, что id — непременно символ, а не число или список? MC>Проще и короче — нигде, т.к. ты все равно к нему будешь биндить.
Обращаюсь я к имени id. Ты не понял — в шаблоне сказано, что на этом месте распознаётся только символ. Аналогично можно, например, только строку, только число, или только что-то удовлетворяющее заданному предикату, и т.п. По сравнению с этим pattern matching-ом всякие там syntax-case — это убожество. Кстати, моя реализация syntax-rules и syntax-case — 150 строк с комментариями. Без гигиены, но исключительно по причине презрения к таковой. Сложного в ней ничего нет.
Здравствуйте, metaprogrammer, Вы писали: M> Обращаюсь я к имени id. Ты не понял — в шаблоне сказано, что на этом месте распознаётся только символ. Аналогично можно, например, только строку, только число, или только что-то удовлетворяющее заданному предикату, и т.п. По сравнению с этим pattern matching-ом всякие там syntax-case — это убожество.
Проверить, что за литерал приехал в syntax-rules — нельзя. Можно в syntax-case сделать syntax->datum, только зачем? Чтобы что-то вычислять в expand-time?
M>Кстати, моя реализация syntax-rules и syntax-case — 150 строк с комментариями.
Код в студию.
Здравствуйте, Mr.Cat, Вы писали:
MC>Проверить, что за литерал приехал в syntax-rules — нельзя. Можно в syntax-case сделать syntax->datum, только зачем? Чтобы что-то вычислять в expand-time?
Ваще-то pattern matching нужен далеко не только для написания макр. У него миллионы других применений имеется.
M>>Кстати, моя реализация syntax-rules и syntax-case — 150 строк с комментариями. MC>Код в студию.
Здравствуйте, metaprogrammer, Вы писали: MC>>Проверить, что за литерал приехал в syntax-rules — нельзя. Можно в syntax-case сделать syntax->datum, только зачем? Чтобы что-то вычислять в expand-time? M> Ваще-то pattern matching нужен далеко не только для написания макр. У него миллионы других применений имеется.
А вне макр матчить литерал заданного типа и подавно бессмысленно. Т.е. 6 пропускаем, а (+ 1 2 3) — нет? Не улавливаю ход твоих мыслей.
Здравствуйте, Mr.Cat, Вы писали:
M>> Ваще-то pattern matching нужен далеко не только для написания макр. У него миллионы других применений имеется. MC>А вне макр матчить литерал заданного типа и подавно бессмысленно.
Да ну? Очень даже осмысленно. Это ведь не ML и не Haskell, строгих ADT нет — так что сложные структуры только в списках и представимы. И эти структуры деструктурировать надо по всякому, по разному. Так что и предикаты нужны, и самые разные варианты ellipsis, и хитрые биндинги (например, задать имя для всей подструктуры, и при этом определить структуру её элементов). Чем мощнее pattern matching, тем проще с разными структурами работать.
MC> Т.е. 6 пропускаем, а (+ 1 2 3) — нет? Не улавливаю ход твоих мыслей.
Ты думаешь только о коде. Подумай ширше, о списках и векторах вообще.
И, кстати, даже если и код — для 6 у нас может один паттёрн срабатывать, а для (+ 1 2 3) уже совсем другой.
Здравствуйте, metaprogrammer, Вы писали: M> В той же, в которой и PFront.
Ну а конкретнее?
И да, юзая mbase — неспортивно хвастаться строками собственного кода.
Здравствуйте, metaprogrammer, Вы писали: M>И эти структуры деструктурировать надо по всякому, по разному. Так что и предикаты нужны, и самые разные варианты ellipsis, и хитрые биндинги (например, задать имя для всей подструктуры, и при этом определить структуру её элементов). Чем мощнее pattern matching, тем проще с разными структурами работать.
Ну так тот же match.scm вроде умеет чуть ли не все это.
Здравствуйте, Mr.Cat, Вы писали:
M>> В той же, в которой и PFront. MC>Ну а конкретнее?
mbase последней версии, где шаблон $RP: в p:match появился (честно! он там не для syntax-case, и является частным случаем шаблона $$XXX).
MC>И да, юзая mbase — неспортивно хвастаться строками собственного кода.
Почему неспортивно? p:match — совершенно обобщённое решение, которое применятся вообще для всего (даже для компиляции из ML). Ничего syntax-case-специфичного в библиотеки не выносилось.
Здравствуйте, metaprogrammer, Вы писали: M> И половины не умеет (например, предикатов).
Matchable из chicken умеет (http://chicken.wiki.br/eggref/4/matchable) вроде это примерно тот же match.scm, не?
M>Кроме того — генерит нехвостоворекурсивный код (ну и словечко...).
Надо проверять конкретные случаи. Например?
Не не не. Chicken кстати внутри весь целиком на define-macro сделан. Ни единого syntax-rules и прочих руковыворачивателей для неуверенных в себе программистов.
M>>Кроме того — генерит нехвостоворекурсивный код (ну и словечко...). MC>Надо проверять конкретные случаи. Например?
Здравствуйте, metaprogrammer, Вы писали: MC>>Matchable из chicken умеет (http://chicken.wiki.br/eggref/4/matchable) вроде это примерно тот же match.scm, не? M> Не не не.
А вот и да да да. Скачай matchable.egg и погляди внутрь.
M>Сhicken кстати внутри весь целиком на define-macro сделан.
Они в 4 на er емнип перешли.
Здравствуйте, Mr.Cat, Вы писали:
MC>А вот и да да да. Скачай matchable.egg и погляди внутрь.
Ну, ладно. Более 2000 строк совершенно нечитабельного и неподдерживаемого кода против 200 строк реализации p:match, при значительно меньшей функциональности. И надо оно — религиозная гигиена такой ценой?
MC>Они в 4 на er емнип перешли.
Здравствуйте, metaprogrammer, Вы писали: M>>>Кроме того — генерит нехвостоворекурсивный код (ну и словечко...). MC>>Надо проверять конкретные случаи. Например? M>
Здравствуйте, metaprogrammer, Вы писали:
M> mbase последней версии, где шаблон $RP: в p:match появился (честно! он там не для syntax-case, и является частным случаем шаблона $$XXX).
Как можно получить эту версию? по-прежнему надо писать авторам? На сайте всё ещё ссылка на 0.6
Здравствуйте, MasterZiv, Вы писали:
MZ>Не скатимся. Переменные и функции разделять хорошо тем, что MZ>не надо тогда лишний раз думать о названии переменных.
MZ>(let ((elt (elt seq 5))) MZ> ... MZ> )
Я вот посмотрел в свои многочисленные исходники и нашёл, что функции и переменные я почти всегда (нашёл только два одинаковых случая и то меня скривило от названий функций) называю по разному.
Наверное, связано это с тем, что функции у меня обычно глаголы, а переменные — существительные. Хотя в английском одно и то же слово и может быть и глаголом и существительным, у меня (и у тех, с кем я работал) такое практически не встречается.
Отсюда я могу сделать вывод, что это очень редкая ситуация (у тебя не так?). Значит преимущества мизерны. А вот минусы вполне осязаемы.
Ещё пример — в Haskell я никогда не страдал от того, что не могу назвать и функцию и значение одним именем.
Допускаю, что не страдал, потому что не задумывался о такой возможности. Интересно, насколько удобнее было бы писать
Здравствуйте, metaprogrammer, Вы писали: M>Кстати, моя реализация syntax-rules и syntax-case — 150 строк с комментариями.
Btw:
How small does it have to be? Chibi Scheme does syntax-rules in 174 lines of Scheme, layered over explicit renaming. Indeed, Chibi does essentially all of R5RS in 4822 lines of C + 708 lines of Scheme.
Здравствуйте, Mr.Cat, Вы писали:
MC>How small does it have to be? Chibi Scheme does syntax-rules in 174 lines of Scheme, layered over explicit renaming. Indeed, Chibi does essentially all of R5RS in 4822 lines of C + 708 lines of Scheme. MC>И никакого mbase не надо.
Ну ты сравнил, chibi — игрушка, да ещё и интерпретатор. У меня вот игрушечный быстрый компилятор Arc и того меньше, и без всякого Си.
Кроме того, в chibi очень нечитабельный и медленный интерпретатор syntax-rules (как и та реализация на CL, которую я ранее приводил). Моя реализация — эффективный компилятор syntax-rules, работает на порядок быстрее.
Основные причины: много кода, жестко завязанного на bigloo и его нестандартные библиотеки. bigloo пока на r6rs и не смотрит. Другая часть моего схемского кода привязана к фичам SISC (в особенности — биндинги к жабе). Так что, каким бы прелестным ни был plt, но я на него могу только издалека радоваться. Кроме того, весь новый код всё равно на mbase пишу.