То ли янус глючит, то ли забанили... Но по веб ветка тоже какая-то не такая. В общем, в пример функциям Влада.

До сих пор хочется внятного объяснения, что макры лиспа слабее.

VD>

VD>macro WithMathDefines()
VD>{
VD>    <[ def (("pi" : usesite), ("pi" : usesite)) = (3.14, 2.72); ]>
VD>}
VD>

(defmacro my_if (cond iftrue iffalse)
  `(cond (,cond ,iftrue)
     (t ,iffalse)))

VD>

VD>macro MyIf(cond, ifTrue, ifFalse)
VD>  syntax ("my_if", cond, "then", ifTrue, "else" ifFalse)
VD>{
VD>    <[ if ($cond) $ifTrue else $ifFalse ]>
VD>}
VD>

(defmacro with-math-defines (&;rest body)
  `(let ((pi 3.14) (e 2.7))
     ,@body))

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

TBG>То ли янус глючит, то ли забанили... Но по веб ветка тоже какая-то не такая. В общем, в пример функциям Влада.

TBG>До сих пор хочется внятного объяснения, что макры лиспа слабее.

VD>>

VD>>macro MyIf(cond, ifTrue, ifFalse)
VD>>  syntax ("my_if", cond, "then", ifTrue, "else" ifFalse)
VD>>{
VD>>    <[ if ($cond) $ifTrue else $ifFalse ]>
VD>>}
VD>>

TBG>

TBG>;(defmacro my_if (cond iftrue iffalse)
TBG>;  `(cond (,cond ,iftrue)
TBG>;     (t ,iffalse)))
TBG>;

Именно здесь не всё так просто. Влад ввёл доп. "слово" — then. И там есть else. Я не знаю — можно ли в Немерле между ними вставлять несколько выражений. Но если можно, то лисповая макра будет чуть по-сложнее (если не оформлять отдельные секции одним списком): надо будет перебирать все элементы списка в поиске ключевых слов и по их "границам" бить весь список параметров.

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

TBG>До сих пор хочется внятного объяснения, что макры лиспа слабее.

Тебе двадцать раз объясняли, но ты просто игнорируешь.

TBG>

TBG>;(defmacro my_if (cond iftrue iffalse)
TBG>;  `(cond (,cond ,iftrue)
TBG>;     (t ,iffalse)))
TBG>;

1. Это пример не на Схеме, в отличии от обсуждаемого мной.
2. Это дургой пример. В нем не вводится новый синаксис. Мой макрос позволяет писать так:

my_if 1 > 2 then someCode() else someelse()

Его аналог на Схеме и был привден:

;;определить my-if как макрос
(define-syntax my-if
  (lambda (x)
    ;;установить, что "then" и "else" - это ключевые слова
    (syntax-case x (then else)
      (
        ;;образец для сопоставления
        (my-if condition then yes-result else no-result)
        ;;преобразователь
        (syntax (if condition yes-result no-result))
       )
)))

TBG>

TBG>;(defmacro with-math-defines (&rest body)
TBG>;  `(let ((pi 3.14) (e 2.7))
TBG>;     ,@body))
TBG>;

Опять же это не Схема. На CL такой макрос делается проще чем на Схеме, но проблемы возникают когда имена должны быть локальными внутри макроса.
Хотя и этот пример показывает кривость Лиспа. Все эти шаманства с "(&rest body)"...",@body".

VladD2,

TBG>>До сих пор хочется внятного объяснения, что макры лиспа слабее.

VD>Тебе двадцать раз объясняли, но ты просто игнорируешь.

Кхе. Основной упор на более мощную мощность макросов в Немерле ты считаешь доступ к информации о типах. Да, доступ к типам — это круто. Но причём тут мощность?

Типы — это структуры для создания абстрактных слоёв. Иметь доступ к типу значит иметь доступ к структурам за слоем. Зачем нужны абстрактные слои? Чтобы оградить нас от лишней информации. Всё логично.

Но разве в Лиспе нет абстрактных структур и нет способа работать с ними? Конечно же есть!

(setq tx (make-structure ...))
(look-into-1 (...))
(look-into-2 (...))
(look-into-3 (...))
(look-into-4 (...))

Фактически мы имеем конструктор (make-structure) для воображаемого типа Structure. И вполне можем (в т.ч. и в макросах) обойтись интерфейсом (look-into-N), если этого достаточно. Ключевое различие в том, что Немерле вынуждает считаться с типами.

В свете этого то, что макросы Немерле безопаснее и легче в использовании — с этим соглашусь. Но отсюда не следует, что они более мощные. Чтобы показать, что они мощнее, нужно продемонстрировать некоторое преобразование АСТ-а, которое возможно в Немерле, и невозможно в Лиспе. Сомневаюсь в существовании такого преобразования.

Поправка

LCR>Чтобы показать, что они мощнее, нужно продемонстрировать некоторое преобразование АСТ-а, которое возможно в Немерле, и невозможно в Лиспе.

Или по крайней мере тяжелее в реализации.

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

CU>Именно здесь не всё так просто. Влад ввёл доп. "слово" — then. И там есть else. Я не знаю — можно ли в Немерле между ними вставлять несколько выражений. Но если можно, то лисповая макра будет чуть по-сложнее (если не оформлять отдельные секции одним списком): надо будет перебирать все элементы списка в поиске ключевых слов и по их "границам" бить весь список параметров.

Ах, вот оно что.. Так можно написать макру, которая будет утилизовать этот перебор, проверять на валидность.. А потом использовать в стиле (with-syntax ...бла-бла-бла...)

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

TBG>Ах, вот оно что.. Так можно написать макру, которая будет утилизовать этот перебор, проверять на валидность.. А потом использовать в стиле (with-syntax ...бла-бла-бла...)

Так кое-кого именно от этого и тошнит

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

TBG>>До сих пор хочется внятного объяснения, что макры лиспа слабее.
VD>Тебе двадцать раз объясняли, но ты просто игнорируешь.

Ну-ну...

VD>1. Это пример не на Схеме, в отличии от обсуждаемого мной.

Ну дык.

VD>2. Это дургой пример. В нем не вводится новый синаксис. Мой макрос позволяет писать так:

Ну понял, мне cl-user уже объяснил. Но я же уже ответил по теме.

VD>Опять же это не Схема. На CL такой макрос делается проще чем на Схеме, но проблемы возникают когда имена должны быть локальными внутри макроса.

Есть такая проблем.

VD>Хотя и этот пример показывает кривость Лиспа. Все эти шаманства с "(&rest body)"...",@body".

Есть небольшие кривульки, неудобные некоторые вещи если делать именно так. В немерле тоже кривости найти можно. ОКи, переходим в КСВ.

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

VD>1. Это пример не на Схеме, в отличии от обсуждаемого мной.
VD>2. Это дургой пример. В нем не вводится новый синаксис. Мой макрос позволяет писать так:
VD>

VD>my_if 1 > 2 then someCode() else someelse()
VD>

А между then и else можно вставить более одного "телодвижения", или без "операторных скобок" никак?

TBG>>

TBG>;>(defmacro with-math-defines (&rest body)
TBG>;>  `(let ((pi 3.14) (e 2.7))
TBG>;>     ,@body))
TBG>;>

VD>Опять же это не Схема. На CL такой макрос делается проще чем на Схеме, но проблемы возникают когда имена должны быть локальными внутри макроса.

Не понял — pi и e и так будут локальны внутри let. Или мы про другое?

VD>Хотя и этот пример показывает кривость Лиспа. Все эти шаманства с "(&rest body)"...",@body".

А что здесь не так? Или "дело привычки"?

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

LCR>В свете этого то, что макросы Немерле безопаснее и легче в использовании — с этим соглашусь. Но отсюда не следует, что они более мощные. Чтобы показать, что они мощнее, нужно продемонстрировать некоторое преобразование АСТ-а, которое возможно в Немерле, и невозможно в Лиспе. Сомневаюсь в существовании такого преобразования.

Макросы Лиспа конечно мощнее в том плане, что они могут генерировать определения других макросов, насколько я понимаю.
С другой стороны, в Немерле можно иметь и гигиену для одних переменных и ее отсутствие для других в одном макросе.

У меня есть два вопроса по поводу мощности макросов Лиспа:

1) Можно ли там принимать решения в зависимости от типа аргументов (не литералов, а переменных определенного типа)?
2) Какой контроль области действия макроса?

А вообще для того чтобы сравнить более-менее объективно нужен человек который хорошо разбирается и в Лиспе и в Немерле, в противном случае можно только в пинг-понг играть: один дает свой пример и объясняет что он делает, другой пишет аналог на другом языке.

Кстати, а как в CL с паттерн-матчингом?

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

АХ>У меня есть два вопроса по поводу мощности макросов Лиспа:

АХ>1) Можно ли там принимать решения в зависимости от типа аргументов (не литералов, а переменных определенного типа)?

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

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

CU>Не понял — pi и e и так будут локальны внутри let. Или мы про другое?

Дело про hygenius макросы, но Влад выбрал неудачный пример.

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

LCR>Кхе. Основной упор на более мощную мощность макросов в Немерле ты считаешь доступ к информации о типах. Да, доступ к типам — это круто. Но причём тут мощность?

Хм, а что ты тогда понимашь под мощьностью? Если о ЯП или технологии ты говоришь "да, ... — это круто", то это и является признанием мощьности.

LCR>Типы — это структуры для создания абстрактных слоёв. Иметь доступ к типу значит иметь доступ к структурам за слоем. Зачем нужны абстрактные слои? Чтобы оградить нас от лишней информации. Всё логично.

Хорошо излагаешь. Почти как Мечников. Смысл не уловить, но звучит складно.
Если серьзно, то я не вижу ничего логичного.

Типы есть всегда и везде. И знание о них — это всегда плюс. Знание о типах внутри макросистемы позволяет делать более сложные и более гибкие решения.

LCR>Но разве в Лиспе нет абстрактных структур и нет способа работать с ними?

Извини, смысл я в твоих расуждениях не улавливаю. Они слишком абстрактны и туманнны.

LCR>В свете этого то, что макросы Немерле безопаснее и легче в использовании — с этим соглашусь. Но отсюда не следует, что они более мощные.

Если что-то более просто исползовать при аналогичном результате, то это жуе более мощьное средство. Ведь дырку в бетоне можно проковырять и гвоздями. Просто перворатором со спец. сверлом это сделать легче. Не так ли?

LCR> Чтобы показать, что они мощнее, нужно продемонстрировать некоторое преобразование АСТ-а, которое возможно в Немерле, и невозможно в Лиспе. Сомневаюсь в существовании такого преобразования.

Да сколько угодно. Вот, например, я как-то написал макрос SupportRelocation (см. файл compiler.n).

Если в двух словах, то он проходится по всем типам проекта, выискивает в них поля имеющие тип Location (см. файл AST.n), проверяет являются ли они mutable, добавляет в анализируемый тип метод RelocateImplInternal() содержащий код пересчета Location-ов для заданного смещения, и генерирует код вызова таких же методов для всех вложенных полей. При этом ссылки на некоторые (заранее известные) типы игнорируются, чтобы не осуществлять заранее ненужной работы по обходу.

Особо стоти обратить внимание на строкчку 229:

def ty = tb.MonoBindType (field.ty);

в ней производится вычисление типа для обрабатываемого поля. Без нее задаче становится нерешаемой.

Так вот этот макрос невозможен ни на Лиспе, ни на чем либо другом не предоставляющем информацию о типах.

---

Из более простых примеров можно привести макрос foreach. В нем поодерживаются разные источники информации (коллекции, списки, массивы, лист-компрехеншон). Для того чтобы сгенерировать оптимальный для каждого из источников код нужно знать информацию о типах.

И таких случаев масса. Упоминаемый макрос AbstractFactory тоже сложно реализовать без наличия информации о типх. Правда, возомножно, в этом случае ее можно будет вычислить вручную путем парсинга АСТ класса для которого создается фабрика (незнаком с ООП в Лиспе настолько чтобы утверждать, что это невозможно).

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

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

АХ>Макросы Лиспа конечно мощнее в том плане, что они могут генерировать определения других макросов, насколько я понимаю.

Это не дает реального приемущества. Н-уровневую схему генерации можно организовать и на Немребле (правда, сложнее, так как каждый уровень обязан быть в отдельной сборке). А рекурсивные макросы способны порвать крышу любому гению.

К тому же возможность применять макросы там же где они создаются имеет очень серьезные побочные эффекты.

Главный из них — это размывание границ действия макрса. Становится не ясно где данные, где код, где что. Самые частые проблемы с макросами Лиспа как раз связаны с тем что прогарммисты запутываются и не могут найти концов.

Вторая проблема — это производительность. При некоторых объемах и сложности макросов в некомпилированном виде они будут сильно тормозить, а их динамическая компиляция может занять не мало времени. Пока задачи просты (балавство и тесты) проблем нет. Но в реальных больших проектах проблемы могут быть очень существенны. Кстати, тот же Немерле без пре-джита использовать очень неприятно.

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

Если проблемы и есть, то они скорее лежатк в области отладки макросов.

АХ>С другой стороны, в Немерле можно иметь и гигиену для одних переменных и ее отсутствие для других в одном макросе.

Это можно сделать и в Схеме. Но куда более большой ценой. Главное, что в Немреле это делается очень просто. Написал:

$(xxx : name)

или

$("xxx" : usesite)

и получи себе обкод гигееничности. Простой и удобный. При этом никаких граблей от того, что по умолчанию переменные пересекаются с внешним контекстом.

АХ>У меня есть два вопроса по поводу мощности макросов Лиспа:
АХ>1) Можно ли там принимать решения в зависимости от типа аргументов (не литералов, а переменных определенного типа)?

Нет. Практически — нет. На входе макроса S-выражения и весь анализ типов ты дожен делать сам. На практике это приводит к томе, что анализировать можно только явно заданные вещи.

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

CU>>Не понял — pi и e и так будут локальны внутри let. Или мы про другое?

TBG>Дело про hygenius макросы,

Именно.

TBG>но Влад выбрал неудачный пример.

Я выбрал пример из статьи одного из проповедников Схемы.


Вы твту в один голос кричите, что мол Лисп проще, Лисп круче, а на самом деле это далеко не так. Как минимум он может соревнаваться на равный. А учитывая прочее, он вообще частенько будет в аутсайдерах.

Оно, в общем-то, и не мудренно. Немерле появился в 21 веке и основные проблемы макросистем к этму времени уже были известны. Авторы Немерла просто проанализирвоали имеющиеся макросистемы и посторались выбрать те рещения которые учитывают опыт предыдущих преализаций и по возможности обходят их пробелмы. И им это удалось довольно хорошо.

Так что довольно бессмысленно сревнивать Немерле с Лиспом или там МетаХаскелем. Немелре учитывает их опыт. Конечно он не может быть во всем лучше своих предков. Это вызвано тем, что нельзя сесть аразу на 10 стульев. Приходится принимать решение о выборе того или иного дизайнерского решения. Одно решение может предотавращать другое.

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

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

Еще один выбор был сделан между гибкостью подсистемы макросво и контролем ошибок. Но тут выбор был сделан именно в пользу гибкости. Авторы эксперементируя с разными МетаХаскелями пришли к выводу, что ранний контроль типов резко усложняет задачу генерации кода, а то что Немерле компилятор позволяет проверить код хотя и позже (после его генерации), но до запуска, еустранив тем самым проблемы в рантайме. Так что тут выбор авторов Немерла был в пользу подхода Лиспов, то есть герации кода в виде не типизированного АСТ. Однако в оличии от Лиспа они позволяют получать информацию о типах остальных частей проекта. И это несомненно огромный шаг вперед по сравнению с подходом Лиспа.

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

VD>Еще один выбор был сделан между гибкостью подсистемы макросво и контролем ошибок. Но тут выбор был сделан именно в пользу гибкости. Авторы эксперементируя с разными МетаХаскелями пришли к выводу, что ранний контроль типов резко усложняет задачу генерации кода, а то что Немерле компилятор позволяет проверить код хотя и позже (после его генерации), но до запуска, еустранив тем самым проблемы в рантайме.

Это просто оборот речи или тебе известно несколько разных МетаХаскеллов? Я только с одним знаком.

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

АХ>А вообще для того чтобы сравнить более-менее объективно нужен человек который хорошо разбирается и в Лиспе и в Немерле, в противном случае можно только в пинг-понг играть: один дает свой пример и объясняет что он делает, другой пишет аналог на другом языке.

АХ>Кстати, а как в CL с паттерн-матчингом?

Как я понимаю будет если напишешь
По моему самый интересный из лиспов, вернее его потомков это QI (http://www.lambdassociates.org/) уже вполне удобный и понятный язык там и типизация есть и паттерн матчинг и макросы. В общем очень интересная штучка. Можно с ним сравнить, правда я глубоко еще не ковырялся.

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

D>Это просто оборот речи или тебе известно несколько разных МетаХаскеллов? Я только с одним знаком.

Имелись в виду аналоги на базе других языков. Можешь считать это оборотами речи. Вообще, проще чем слушать испорченный телефон просто прочесть статью о которой я говорю

Автор(ы): Kamil Skalski, Michal Moskal и Pawel Olszta
Дата: 23.05.2006
Пример C++ показывает, что индустрии нужны системы метапрограммирования – даже достаточно причудливая система шаблонов широко используется для вычислений во время компиляции. Эта статья является исследованием возможного внедрения техники метапрограммирования в индустриальную среду в более чистой форме. Мы, таким образом, фокусируемся на том, чтобы сделать нашу систему легкой в использовании для программистов, как пишущих, так и использующих макросы.

(раздел 10. Связанные работы). Информация в ней немного устарела, но тем не менее актуальна и интересна.

VladD2,

LCR>> Чтобы показать, что они мощнее, нужно продемонстрировать некоторое преобразование АСТ-а, которое возможно в Немерле, и невозможно в Лиспе. Сомневаюсь в существовании такого преобразования.

VD>Да сколько угодно. Вот, например, я как-то написал макрос SupportRelocation (см. файл compiler.n).
VD>...
VD>Особо стоти обратить внимание на строкчку 229:

VD>def ty = tb.MonoBindType (field.ty);

VD>в ней производится вычисление типа для обрабатываемого поля. Без нее задаче становится нерешаемой.

VD>Так вот этот макрос невозможен ни на Лиспе, ни на чем либо другом не предоставляющем информацию о типах.

Ок, Влад, ты меня убедил, информация о типах здесь очень важна и нужна (хотя я и раньше не сильно сопротивлялся этому). Тем не менее в Лиспе информация о типах тоже есть, взгляни:

CL-USER 1 > (defstruct point x y z)
POINT

CL-USER 2 > (defun distance-from-origin (point)
              (let* ((x (point-x point))
                     (y (point-y point))
                     (z (point-z point)))
                (sqrt (+ (* x x) (* y y) (* z z)))))
DISTANCE-FROM-ORIGIN

CL-USER 3 > (defun reflect-in-y-axis (point)
              (setf (point-y point)
                    (- (point-y point))))
REFLECT-IN-Y-AXIS

CL-USER 4 > (setf my-point (make-point :x 3 :y 4 :z 12))
#S(POINT X 3 Y 4 Z 12)

CL-USER 5 > (type-of my-point)
POINT

CL-USER 6 > (distance-from-origin my-point)
13.0

CL-USER 7 > (reflect-in-y-axis my-point)
-4

CL-USER 8 > my-point
#S(POINT X 3 Y -4 Z 12)

(всё это легко посмотреть прямо в лиспбоксе)

Однако спасибо за хороший ответ. Ты дал хорошую пищу для анализа возможностей макросов Немерла.

Андрей Хропов, Вы писали:

АХ>С другой стороны, в Немерле можно иметь и гигиену для одних переменных и ее отсутствие для других в одном макросе.
Нарисуешь маленький примерчик?

АХ>У меня есть два вопроса по поводу мощности макросов Лиспа:

АХ>1) Можно ли там принимать решения в зависимости от типа аргументов (не литералов, а переменных определенного типа)?
С одной стороны всё есть S-выражение. С другой — типы вполне есть, и мы можем принимать решения в зависимости от того, что выдаст type-of, посмотри мой ответ

Автор: Lazy Cjow Rhrr
Дата: 25.01.07

Владу.

АХ>2) Какой контроль области действия макроса?
Из PCL:

(defmacro do-primes ((var start end) &;body body)
  (let ((ending-value-name (gensym)))
    `(do ((,var (next-prime ,start) (next-prime (1+ ,var)))
          (,ending-value-name ,end))
         ((>; ,var ,ending-value-name))
       ,@body)))

Функция gensym генерирует уникальный символ каждый раз, когда вызывается. Так что наружу не светит ничего, кроме do-primes.

АХ>А вообще для того чтобы сравнить более-менее объективно нужен человек который хорошо разбирается и в Лиспе и в Немерле, в противном случае можно только в пинг-понг играть: один дает свой пример и объясняет что он делает, другой пишет аналог на другом языке.

Увы, +1. Но пока ветка достаточно "креативная".