LINUX.ORG.RU

Чем так хороши макросы в Lisp?

 


4

7

Уже много всякого прочитал про лисп(в том числе Practical Common Lisp и уже даже освоился с Clojure), но никак не могу понять, чем же на самом деле являются макросы в этом языке. И этот вопрос не дает мне покоя т.к. лисп сильно повлиял на мое мышление и я вижу, что лисп (а особенно, common lisp для своего времени), действительно, лучше и удобней других языков (ну, за исключением странного скобочного синтаксиса ^^) ... Если бы его преимущества заключались в динамической типизации, сборке мусора и интерактивном цикле разработки, то их в полной мере имели бы питон, javascript и даже php.

Обычно пишут, что макросы - сильная сторона лиспа, которая отличает его от других языков и в качестве аргументов приводят неудачные примеры, которые довольно просто реализовать в других языках. Может кто-нибудь объяснить более-менее формально, что такое макросы? В чем их преимущества?

Для себя мне удалось выделить лишь два свойства макроса, отличающих его от функции:

макрос выполняется до исполнения кода; вычислением аргументов макроса управляет программист.

Первое мне видится ограничением, которое приводит к целому ряду неудобств, как, например, невозможность применить apply к макросу(особено часто хочится сделать (apply and ...) или (reduce and ...)).

А второе может быть легко реализовано посредством функций высшего порядка хоть в C и C++. Для примера, в весьма популярной книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования» Э. Гамма, Р. Хелм, Р. Джонсон, Д.Влиссидес описываются пaттерны Command и Interpreter - в комбинации это в точности макросы времени выполнения...



Последнее исправление: CheKastro (всего исправлений: 1)
Ответ на: комментарий от anonymous

На Си, блядь, плюс блядь плюс! Что ж вы такие тупые-то все, борщехлебы?!? А какими там говноскриптиками бойлерплейт в контенте генерился вообще не важно, основная часть контента вообще не автоматизируется, это результат работы художников, моделлеров, актеров озвучки и т.п., которым всем эти ваши «DSL»-шаблонишки вообще по барабану.

anonymous
()
Ответ на: комментарий от anonymous

На Си, блядь, плюс блядь плюс!

На C++ написан только игровой движок, который как правило уже готовый используется. Мелочевка написана на C#. Весь же код, который и составляет игру, написан на DSL'ях.

anonymous
()
Ответ на: комментарий от anonymous

Хватит называть контент «кодом».

Хватит называть код «контентом». Вот тебе пример кода:

(state ("shake-hands")
  (on (begin)
   (track ("player"))
     [wait-move-to "player" "waypoint7"]
     [signal "player-at-waypoint"]
     [wait-for-signal "sully-at-waypoint"]
     [wait-animate "player" "shake-sullys-hand"]
   )
   (track ("sullivan"))
     [wait-move-to "sullivan" "waypoint7"]
     [signal "sully-at-waypoint"]
     [wait-for-signal "player-at-waypoint"]
     [wait-animate "sullivan" "shake-drakes-hand"]
    ) 
  )
)

Ну и про какой-такой «контент» ты говоришь?

anonymous
()
Ответ на: комментарий от anonymous

Игра чуть менее чем полностью состоит из этого «контента». Он, в частности, содержит игровую логику и скрипты.

anonymous
()
Ответ на: комментарий от anonymous

Он не «написан»

что значит «не написан»? Именно что написан, на специальном ДСЛе. Что делали с текстом на этом ДСЛе - уже другой вопрос.

anonymous
()
Ответ на: комментарий от anonymous

C точки зрения C++-кодера - это контент. Технический аниматор приносит вот такое описание C++-птушнику, и птушник пыхтит неделю, пишет это на C++.

В случае с DSL'ем на Лиспе - этот контент исполняемый. Аниматор тут же может его запустить и посмотреть результат. А C++-птушник в этом время будет заниматься своим прямым делом - подметать дворы.

anonymous
()
Ответ на: комментарий от anonymous

То есть «декларативное описание» = «контент». Так что при использовании ДСЛ у тебя всегда будет получаться контент вместо кода. Решающий ту же задачу, что и код.

anonymous
()
Ответ на: комментарий от anonymous

Этот у нас последний неслитый остался? Вряд ли он уже очухается.

Слив засчитан.

anonymous
()
Ответ на: комментарий от anonymous

основная часть контента вообще не автоматизируется,

то есть, как это «не автоматизируется»? ты вообще себе геймдева воркфлоу представляешь, борщехлеб?

представляешь себе отличия от пропертарных форматов старых моделлеров и формата COLLADA .dae?

как там задаются: сцена, шейдеры, анимация, трансформации, меши, модельки?

что такое параметрическое моделирование?

почему моделлер типа Daz 3D (бесплатно раздавали когда-то) предлагает модели в виде Genesis формате : где можно настраивать типовые модели, совмещая ноги от одной, руки от другой, сиськи от третьей?

как вообще там задаётся анимация?

что такое preconditioners и препроцессоры в COLLADA?

и что мешает этот COLLADA XML грузить не через C++-шный DOM, а через свой SXML загрузчик, добавляя атрибуты по вкусу и рассчитывая параметрические модели?

это результат работы художников, моделлеров, актеров озвучки и т.п., которым всем эти ваши «DSL»-шаблонишки вообще по барабану.

ты бы их загрузил, эти .dae в текстовый редактор, да посмотрел, что именно там написано в этом XML

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.