LINUX.ORG.RU

[Lisp] туплю с defmacro

 


0

2

Есть код:


(defun get-action-name (list)
	(mapcar #'(lambda (def-list) (list (first def-list) (second def-list))) list))

(defmacro with-new-actions (parent actions-list
							&body body)
  (get-action-name actions-list))

(defparameter *workspace-actions-list* 
  '((aNew "&New" #'new-page-handler "tab- new" "Ctrl+N")
	(aOpen "&Open" #'open-page-handler "open" "Ctrl+O")))

(with-new-actions 'parent *workspace-actions-list*) ;; 1

(with-new-actions 'parent ((aNew "&New" #'new-page-handler "tab- new" "Ctrl+N")
	(aOpen "&Open" #'open-page-handler "open" "Ctrl+O"))) ;; 2

Проблема в том что строка (2) раскрывается, а строка (1) - нет.

Вопрос как раскрыть *workspace-actions-list* внутри defmacro ? Google молчит, вот туплю и мучаюсь.

★★★
Ответ на: комментарий от yyk

Это человек занимающийся разработкой реально больших систем на Common Lisp (ITA Software). Это не «эмоции и сранные ожидания», а просто опыт человека имеющего реально большой опыт работы как с CL, так и с другими системами.

Ну нельзя же отрицать очевидного. Стандарт CL был принят 15 лет назад и уже тогда не являлся «последним словом мысли» в данном вопросе. Многие вещи в него не были включены из cltl2, разные codewallker-ы и т.п. Почему это не включил вопрос отдельный, но явно не потому, что стандарт CL совершенен. 15 лет прошло. Над проблемой продолжали работать в рамках других языков. Были разработаны новые, хорошие решения в рамках PLT (Scheme) и других языков. По другому и быть не могло, ведь прогресс не стоит на месте, а стандарт CL застрял в прошлом веке.

Как пример сложности использования макросистемы CL на ЛОР-е уже приводили iterate - отличная библиотека, но 3700 строк кода на базе. Так тоже можно писать, просто сложно. В случае iterate это оправдывается профитом для всех использующих, но в большинстве случаев это слишком сложный подход.

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

> Ну а вот в CL они не должны объявляться в compile-time

с какого бодуна? Используешь что-то при работе макроса - изволь засунуть в compile-time (если это что-то автоматом не объявляется для всех «времён и народов»)

потому что функции одновременно можно вызывать и в компайл-тайме из макросов и в рантайме


для этого их и надо определять «для всех времён»

Вобщем-то в моем предыдущем примере, если я правильно понимаю принцип экспанда в CL, мы получим эрор в рантайме


и с такими знаниями ты выносишь столь категоричные суждения?!...

Ты получишь ошибку компиляции. А в случае REPL/интерпретации всё отработает.

А семантика какой-нибудь хрени типа:


Интересно, а как ты себе вообще представляешь вариант, когда при компиляции тела функции должна отработать сама эта функция? Ты меня пугаешь....

...но если пример еще немножко модифицировать...


...то можно и хер сломать. Да, в CL прострелить себе ногу можно очень многими способами. Но говорит это только о «пользователе» - ты ещё на asm наедь, что в нём можно сделать jmp куда угодно!

Там по крайней мере нельзя написать откровенно бредового кода


Ну с этого бы и начал, что ты пишешь бред и жалеешь, что тебе ни кто за это не дал в морду^W^W по рукам! А то я всё пытаюсь найти смысл в твоём коде...

это я даже не представляю


...и почему меня это совершенно не удивляет?

yyk ★★★★★
()
Ответ на: комментарий от archimag

>Это не «эмоции и сранные ожидания», а просто опыт человека имеющего реально большой опыт работы как с CL, так и с другими системами.

а по мне он описывает совершенно тривиальные вещи, густо приправив их сопливыми стенаниями «как всё плохо!» Нах!

Ну нельзя же отрицать очевидного.


А я отрицаю? Или ты мне сейчас будешь «шить измену Родине»?

Стандарт CL был принят 15 лет назад и уже тогда не являлся «последним словом мысли» в данном вопросе.


Кто спорит?

явно не потому, что стандарт CL совершенен


мля, сеньор Дон Кихот, оставьте свои мельницы при себе

сложности использования макросистемы CL


во-первых, довольно субъективная оценка, во-вторых, соглашусь - да, система не из простых. Но позвольте, при чём здесь «дефолтное отсутствие гигиены», обвинение в отсутствии стадий компиляции (что он курил?), «нечёткая семантика» (он ещё много других страшных слов знает?), призывом не использовать CL только потому, что в PLT, по его мнению, макросистема лучше - это что, у всех единственный критерий при выборе инструмента? Да нах таких упоротых, какой бы опыт у них не был - адекватности у них явно на порядок меньше, чем ЧСВ

я уж молчу о том полном бреде ононимуса, из-за которого начался этот срач^Wспор =)

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

[quote] с какого бодуна? Используешь что-то при работе макроса - изволь засунуть в compile-time (если это что-то автоматом не объявляется для всех «времён и народов») [/quote] А почему я должен засовывать, если могу не засовывать? Если предполагается, что я таки должен засунуть, зачем оставлять возможность не совать?

[quote] для этого их и надо определять «для всех времён» [/quote] Почему-то работает и так. Кстати, в коде ОПа точно такой же момент - в макросе вызывается обычная функция.

[quote] и с такими знаниями ты выносишь столь категоричные суждения?!...

Ты получишь ошибку компиляции. [/quote] Инфа 100%? А ты вот попробуй и скомпилируй три строчки с объявлениями (без вызовов). Все прекрасно компилируется. А если загружать через load, то это вообще ужас-ужас.

[quote] Интересно, а как ты себе вообще представляешь вариант, когда при компиляции тела функции должна отработать сама эта функция? Ты меня пугаешь.... [/quote] А меня пугает CL, в котором такое можно написать и все хорошо.

[quote] ...то можно и хер сломать. Да, в CL прострелить себе ногу можно очень многими способами. Но говорит это только о «пользователе» - ты ещё на asm наедь, что в нём можно сделать jmp куда угодно! [/quote] Ну вот CL и находится на таком же уровне развития, что asm. Низкоуровневое говно.

[quote] Ну с этого бы и начал, что ты пишешь бред и жалеешь, что тебе ни кто за это не дал в морду^W^W по рукам! [/quote] Развитая макросистема отличается от примитивной именно тем, что не позволяет писать заведомый бред. Ты правильную аналогию привел. Макросистема CL - это такое низкоуровневое метапрограммирование вроде ассемблера. Давным-давно это было круто, конечно, но сейчас уже пора бы научиться пользоваться более высокоуровневыми средствами. Но blub-эффект же.

[quote] ...и почему меня это совершенно не удивляет? [/quote] То есть ты знаешь, как это сделать? Может, даже продемонстрируешь?

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

Fare там всего-лишь пишет что макросы в CL формально не верифицируемые и недетерминистичны, в отличии от гигиенических макросов PLT или шаблонных подходов к кодогенерации в compile-time (C++, TH). С помощью макросов CL ты можешь разослать по сети широковещательные пакеты и перезагрузить машину, прямо в compile-time :)

quasimoto ★★★★
()
Ответ на: комментарий от yyk

на каждом шагу

а цитаты можно?

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

При том, что все это (отсутствие гигиены, стадий компиляции, нечеткая семантика) - объективные признаки неразвитой макросистемы.

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

С помощью макросов CL ты можешь разослать по сети широковещательные пакеты и перезагрузить машину, прямо в compile-time :)

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

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

призывом не использовать CL только потому, что в PLT, по его мнению, макросистема лучше - это что, у всех единственный критерий при выборе инструмента?

Ты невнимательно читаешь. Он призывал не использовать CL, если хочется нетривиального метапрограммирования - потому что для нетривиального метапрограммирования есть значительно более совершенные инструменты. О неиспользовании CL в общем речи не шло.

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

> вы вместо этого пытаетесь выполнять код приложения на стадии компиляции

Можно увидеть где здесь выполняется код _приложения_ ? :

(eval-when (:compile-toplevel :load-toplevel :execute)
  (defun get-action-name (list parent)
	(mapcar #'(lambda (def-list)
				`(,(first def-list) (new-action ,(second def-list) ,parent))) list))
  (defun get-action-handlers (list)
	(mapcar #'(lambda (def-list)
				`(action-with-data ,(first def-list) ,@(cddr def-list)))
			list)))

(defmacro with-new-actions (parent get-data actions-list
                     &body body)
  (let ((action-name (get-action-name (eval actions-list) parent))
      (action-handler (get-action-handlers (eval actions-list))))
   `(let ,action-name
      (flet ((action-with-data (action handler icon shortcut)
			   (set-action action handler icon :shortcut shortcut)
			   (qfun action "setData" (qnew "QVariant(int)" ,get-data))))
       ,@action-handler)
      ,@body)))
Darkman ★★★
() автор топика
Ответ на: комментарий от anonymous

А вот этот анонимус - известный идиот из 0chan.ru/c/
С ним спорить смысла тоже нет.

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

Я именно про «гигиенических макросов PLT», которые define-syntax.

Они там все гигиенические, то есть define-syntax (есть, конечно, и негигиенический defmacro, но это deprecated и никто его не использует). Просто гигиена легко обходится. Кроме того, гигиена никак не связана с невозможностью перезагрузить компьютер в компайл-тайме или чего-нибудь разослать. Вот например:

(define-syntax (yoba stx) 
  (syntax-case stx () 
    [(yoba) (begin (*здесь делаем что угодно в compile-time*) #`(void))]))
Здесь никакого обхода гигиены нету, все гигиенично. Да, кстати - не в компайл-тайме, а во время макроэкспанда. Все макросы гарантировано раскрываются до начала компиляции.

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

>А почему я должен засовывать, если могу не засовывать?

1) можешь не засовывать при интерпретации

2) а может сначала документацию почитать? а то ты, того и гляди, и минет захочешь от CL-я...

зачем оставлять возможность не совать


чтобы ты мог разделять - в какое время какие функции должны быть, а какие нет

Почему-то работает и так.


работает при интерпретации. При попытке откомпилировать получаешь ошибку. И это не отменяет бредовости кода...

Инфа 100%?


да, проверил

А ты вот попробуй и скомпилируй три строчки с объявлениями (без вызовов)


нах мне париться с твоим бредовым кодом? Ты можешь внятно описать чего ты хочешь?

А если загружать через load, то это вообще ужас-ужас.


загружал и через load - всё отработало. Если используешь sbcl - отключи предварительную компиляцию

А меня пугает CL, в котором такое можно написать и все хорошо.


А как же тебя тогда кухонные ножи то должны пугать - вообще до полусмерти...

Низкоуровневое говно.


Зато даёт возможность различных манипуляций на этом «низком уровне». Да, в CL меньше ограничений чем во многих других языках. И у этой медали две стороны. Одна тебе не нравится, вторая, похоже, не нужна. Ну значит CL не для тебя.

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


1) (низко|высоко)уровневость не отменяет необходимости ознакомиться с инструментов перед его использованием

2) низкоуровневость не снижает «мощности» данного инструмента

3) это СТАНДАРТ, пусть старый, но его изменение а) не так просто; б) вызывает проблемы совместимости

в любом случае, сопоставление конкретной реализации (PLT) со стандартом (CL) несколько... натянуто

А уж свои оценки [отсутствия] тех или иных возможностей могли бы и вовсе при себе и оставить... По мне достаточно констатации фактов =)

То есть ты знаешь, как это сделать? Может, даже продемонстрируешь?


манипуляции с областями видимости? использование макросов? Это есть практически в каждой книжке по CL. А заниматься вашим просвещением у меня нет ни малейшего желания.

yyk ★★★★★
()
Ответ на: комментарий от quasimoto

>Fare там всего-лишь пишет...

он эту возможность наделает негативным акцентом, вместо схематичного определения: в каких ситуациях это можно использовать, в каких не желательно и к каким последствиям это может привести (вернее последствий он там расписал вагон и маленькую тележку, но все с нескрываемым ужасом «Как так можно?!»)

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

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

Не знал. Ну тогда это style convention - как с восклицательными! функциями, использовать IO функции и системные вызовы в define-syntax это довольно старанно.

Да, кстати - не в компайл-тайме, а во время макроэкспанда. Все макросы гарантировано раскрываются до начала компиляции.

Вот CLHS эта стадия является одной из стадий компиляции, просто под compile-time подразумевается более широкое понятие.

quasimoto ★★★★
()
Ответ на: комментарий от yyk

> он эту возможность наделает негативным акцентом,

...

последствий он там расписал вагон и маленькую тележку, но все с


нескрываемым ужасом «Как так можно?!»



Поскольку он является разработчиком XCVB, то попробуй представить сложности, с которыми ему пришлось столкнуться при разработке «нормальной» системы сборки для больших проектов на CL.

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

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

>а цитаты можно?

начни с заглавия статьи...

При том, что все это (отсутствие гигиены, стадий компиляции, нечеткая семантика) - объективные признаки неразвитой макросистемы.


отсутствие (дефолтной!) гигиены - фича, отсутствие стадий компиляции - бред - он их сам описывает, нечеткая семантика - не меньший бред

характерные признаки макросистемы - ни как не «объективные признаки» на вашей субъективной шкале [не]развитости макросистемы

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

>Вообще, макросы PLT дают больше возможностей, чем макросы CL.

помимо дебага - что ещё? Автоматическая гигиена? Зато «негигиеничность» выливается в макаронный код. Короче - «пруф или не было» =)

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

>Он призывал не использовать CL, если хочется нетривиального метапрограммирования - потому что для нетривиального метапрограммирования есть значительно более совершенные инструменты.

вот со своим понятием «нетривиального метапрограммирования» пусть и долбается в PLT. Потом придут немерловцы и натянут ему жопу на уши уже со своим «нетривиального метапрограммированием»

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

чтобы ты мог разделять - в какое время какие функции должны быть, а какие нет

Вот в PLT я _обязан_ засунуть, иначе получу эррор еще до начала компиляции 0 фазы, и это никак не мешает мне разделять, в какое время какие функции должны быть, а в какое - нет.

работает при интерпретации. При попытке откомпилировать получаешь ошибку. И это не отменяет бредовости кода...

Нету никакой ошибки. Вот этот код:

(defparameter x (read))
(defun yobafun () (progn (setq x (+ 1 x)) x))
(defmacro yobamacro () (yobafun))
Прекрасно компилируется. Или надо компилировать не через (compile-file ...), а как-то по-другому?

нах мне париться с твоим бредовым кодом? Ты можешь внятно описать чего ты хочешь?

Я ничего не хочу. я просто демонстрирую, почему макросистема CL объективно плоха.

загружал и через load - всё отработало.

Вот именно, что все сработало. Но КАК сработало!

Зато даёт возможность различных манипуляций на этом «низком уровне». Да, в CL меньше ограничений чем во многих других языках. И у этой медали две стороны. Одна тебе не нравится, вторая, похоже, не нужна. Ну значит CL не для тебя.

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

1) (низко|высоко)уровневость не отменяет необходимости ознакомиться с инструментов перед его использованием

2) низкоуровневость не снижает «мощности» данного инструмента

1. А необходимость ознакомится с инструментом не отменяет необходимости этому инструменту вести себя предсказуемо. 2. Но почему-то высокоуровневый инструмент оказывается «мощнее».

манипуляции с областями видимости? использование макросов? Это есть практически в каждой книжке по CL. А заниматься вашим просвещением у меня нет ни малейшего желания.

Этого не может быть ни в одной книжке по CL, потому что это вообще невозможно сделать в CL. Если только не переписать все let-формы с кодеволкером по всему коду (что, понятное дело, нифига не решение). Еще в самом SBCL есть некоторые костыли, которые позволяют организовать что-то подобное (через ж*пу, конечно), но в стандарте такого нет - это чисто фишки SBCL. Если ты не понял, что надо сделать - надо, чтобы переменные, в которые раскрывается макрос, замыкались на ту область видимости, в которой он определен. То есть, если макрос (yoba) раскрывается в «x», то это должен быть «х» из области определения макроса yoba, а не из области его раскрытия. По-этому все используемые в макросе символы должны содержать как минимум информацию о своих биндингах.

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

>Поскольку он является разработчиком XCVB, то попробуй представить сложности, с которыми ему пришлось столкнуться при разработке «нормальной» системы сборки для больших проектов на CL.

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


это все не отменяет, а только подтверждает его предвзятость

yyk ★★★★★
()
Ответ на: комментарий от quasimoto

использовать IO функции и системные вызовы в define-syntax это довольно старанно.

Ну это вообще в макросах довольно странно. Однако, если очень хочется, то можно (зачем только? для каких-то нетривиальных методов отладки, разве что. Ах, ну да, если мы потом эти макросы будет евалить - то по факту сайдэффекты будут в рантайме - тогда, наверное, имеет какой-то смысл).

отсутствие (дефолтной!) гигиены - фича

Благодаря этой «фиче» написанный тобой макрос может сломаться при использовании в любой момент. Хороша фича. Про тот момент, что можно банально забыть добавить гигиену там, где она нужна, что может привести к весьма трудно отлаживаемым ошибкам, я уже не упоминаю.

отсутствие стадий компиляции - бред - он их сам описывает

Это не те стадии компиляции.

нечеткая семантика - не меньший бред

Нетривиальная семантика = непредсказуемая работа. Это объективный минус, по факту.

помимо дебага - что ещё? Автоматическая гигиена? Зато «негигиеничность» выливается в макаронный код.

Ничего никуда не выливается. Автоматическая гигиена, фазы, работа с синтаксическими объектами вместо символов, встроенные батарейки типа паттерн-матчинга - навскидку.

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

> это все не отменяет, а только подтверждает его предвзятость

В чём заключается предвзятость то? В том, что на всех углах трубят о крутости макросов в CL, а на проверку это не совсем так и есть языки, в которых макросистема лучше? Так это не предвзятость, а объективность.

Самый большой миф (раздутый троллями), связанный с CL, это то, что самое главная его фича это макросистема. Если бы это действительно было так, то CL был бы уже «не нужен». Но, развитие макросистемы и не было в приоритетах у разработчиков стандарта. И никаких особых достижений в этой области после принятия стандарта в сообществе CL ведь нет.

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

>Вот в PLT я _обязан_ засунуть, иначе получу эррор

я тебе уже говорил - при компиляции я тоже получил ошибку

Вот этот код: ... Прекрасно компилируется.


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

я просто демонстрирую, почему макросистема CL объективно плоха.


ни кто и не говорит, что у неё нет недостатков

Но КАК сработало!


как нах%ячил, так и сработало

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


вы хотите очередной эпичный срач scheme vs. CL? Их в инете вагон и маленькая тележка - я пасс

я могу согласится, что scheme имеет некоторый ряд «положительных моментов». Заниматься абстрактными сравнениями не намерен

Но ведь нет никаких преимуществ.


Не буду даже пытаться вас переубедить

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


из примера действительно только это и можно понять, доооо.... =)

По-этому все используемые в макросе символы должны содержать как минимум информацию о своих биндингах.


ну вот видишь, ты сам всё знаешь... ;)

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

>Благодаря этой «фиче» написанный тобой макрос может сломаться при использовании в любой момент.

если им будет пользоваться даун - да

Про тот момент, что можно банально забыть добавить гигиену


а можно забыть убрать...

Автоматическая гигиена, фазы, работа с синтаксическими объектами вместо символов, встроенные батарейки типа паттерн-матчинга - навскидку.


по мне - ни чего из списка не является «киллер-фичей»

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

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

Ну вот, а по-хорошему ошибку надо выкидывать еще на компиляции (defmacro yobamacro ...), потому что уже тогда понятно, что yobafun не определена. Почему SBCL этого не делает - тайна.

как нах%ячил, так и сработало

Вот скажи честно - ты мог по коду определить, что результат работы будет именно таким? Мне, например, до сих пор непонятно, почему он задерживает выполнение одного из print-ов до второго read-a.

ни кто и не говорит, что у неё нет недостатков

Ну так вот есть макросистемы, которые этих недостатков лишены. И потому они лучше.

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

>В том, что на всех углах трубят о крутости макросов в CL

А, ты опять на своём любимом коне... Иди в пень

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

если им будет пользоваться даун - да

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

а можно забыть убрать...

Если забудешь убрать - будет гарантированная ошибка во время макроэкспанда, с точным указанием характера и места ошибки. Если забудешь добавить - получишь трудноотлавливаемую ошибку в рантайме. Чувствуешь разницу?

по мне - ни чего из списка не является "киллер-фичей"

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

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

>Ну вот, а по-хорошему ошибку надо выкидывать еще на компиляции (defmacro yobamacro ...), потому что уже тогда понятно, что yobafun не определена.

Что мешает тебе потом определить её в compile-time? А может ты там какой-то сакральный смысл будешь потом вкладывать в тело этой функции

Почему SBCL этого не делает - тайна.


Для тебя - да, тайна.

Вот скажи честно - ты мог по коду определить, что результат работы будет именно таким?


Если бы у меня волосы на голове не встали дыбом от вида такого бреда - да =)

Мне, например, до сих пор непонятно, почему он задерживает выполнение одного из print-ов до второго read-a.


подумай ещё раз =)

Ну так вот есть макросистемы, которые этих недостатков лишены. И потому они лучше.


они сильно другие, посему характеристику «И потому они лучше» считаю субъективной

yyk ★★★★★
()
Ответ на: комментарий от archimag

>Ну признай просто, что макросы в PLT лучше, вот и всё.

признаю - они другие. Признаю - в чём-то они лучше

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

>Если забудешь убрать - будет гарантированная ошибка во время макроэкспанда, с точным указанием характера и места ошибки

а если я любитель коротких одинаковых имён?

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

Что мешает тебе потом определить её в compile-time?

То, что я ее уже там не определил? Или SBCL надеется, что я ее потом в репле (eval-when ...)? Хорошая надежда, ага.

Для тебя - да, тайна.

Для всех - тайна.

подумай ещё раз =)

Он задерживает тот print, что просто выводит х. Не вижу никаких оснований. Здесь нарушается порядок вычисления. Ну так что, ты уже придумал способ скопать переменные в макросе?

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

>Или SBCL надеется

он не надеется, он в тебя верит =) Ты для него «бог» и можешь делать всё что хочешь. Ты сам за всё отвечаешь. Не нравится - CL не для тебя.

Для всех - тайна.


Ай, тебя не учили за всех не говорить?...

Он задерживает тот print


ты так уверен, что print задерживает именно read?

Здесь нарушается порядок вычисления.


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

Ну так что, ты уже придумал способ скопать переменные в макросе?


локальные - никак

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

>Не понял, ну и что?

ну я внутри макроса объявляю и использую переменную x и мне вдруг надо взять x из «внешнего окружения» (я точно знаю, что переменная с таким именем там будет). Надо то надо, а вот взял да и забыл снять гигиену...

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

Я в очередной раз порекомендую не обращать внимания на того дебила и его бред.

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

> Не нравится - CL не для тебя.

Ну нельзя же так. Ведь есть CLOS, система обработки условий и ещё разные приятные плюшки (SLIME, например). Они могут нравится и нравится настолько, что макросистему CL можно терпеть, принимая её со всеми её недостатками.

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

>Ну нельзя же так.

Нееее, с такими предъявами, что ему кто-то что-то должен - пусть питоном пользуется =)

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

он не надеется, он в тебя верит =) Ты для него «бог» и можешь делать всё что хочешь. Ты сам за всё отвечаешь. Не нравится - CL не для тебя.

Факт состоит в том, что компилятор пропускает заведомо некорректный код, «веря» в то, что он чудесным образом потом, в рантайме станет корректным. Это дикость.

Ай, тебя не учили за всех не говорить?...

Ну если для тебя не тайна - может, ты ее раскроешь? Какие есть у компилятора основания верить в то, что кто-то потом «исправит» код?

ты так уверен, что print задерживает именно read?

Да вобщем-то не важно, что его задерживает. Факт в том, что

А выводы то какие громкие...

В коде

(defparameter x 100)
(print x)
(read x)
сперва выполняется read, а потом - print. Если для тебя это не нарушение порядка вычисления, то ок.

локальные - никак

Я так и думал.

ну я внутри макроса объявляю и использую переменную x и мне вдруг надо взять x из «внешнего окружения» (я точно знаю, что переменная с таким именем там будет). Надо то надо, а вот взял да и забыл снять гигиену...

Ну так в PLT ты хотя бы сможешь обратиться внешней переменной, отменив гигиену, а в CL ты к ней вообще никак обратиться не сможешь - только к той, что в макросе определена. Или я не понял, чего ты хочешь? Напиши пример кода, и что он должен делать.

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

>Факт состоит в том, что компилятор пропускает заведомо некорректный код, «веря» в то, что он чудесным образом потом, в рантайме станет корректным. Это дикость.

Это не дикость. Ибо код становится некорректным именно на этапе раскрытия макро, не ранее. Согласен, мог бы выдать предупреждение - функция не известна, может быть баг. Но стандарт сие не оговаривает =) Равно как, допустим, clisp выдаст предупреждение о вызове неопределённой функции только по окончании компиляции всего файла, а не именно в момент нахождения попытки её использовать.

сперва выполняется read, а потом - print


б#я, а о буферизации вывода Буратино будет помнить, дятел безмозглый?!

Я так и думал.


Чтобы этого хотеть надо совершенно не понимать как устроена макросистема CL. Ты, похоже, этого не понимаешь. Я так и думал.

а в CL ты к ней вообще никак обратиться не сможешь - только к той, что в макросе определена.


Садись, два. Про области видимости я тебе намекал. Не знаешь как - иди учись.

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

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

Это логично. А вот не выдать его после окончания компиляции всего файла, как это делает SBCL - не логично.

б#я, а о буферизации вывода Буратино будет помнить, дятел безмозглый?!

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

Чтобы этого хотеть надо совершенно не понимать как устроена макросистема CL.

Так я сразу и сказал, что этого в CL сделать нельзя.

Садись, два. Про области видимости я тебе намекал. Не знаешь как - иди учись.

Неуч, ты сперва сформулируй, что надо сделать. По твоему описанию ты хочешь нечто вроде:

(define x 5)
(let ([x 10])
  *и вот отсюда вызвать внешний х*)
Только непонятно, на самом деле, при чем тут макросы и гигиена.

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

>Это логично. А вот не выдать его после окончания компиляции всего файла, как это делает SBCL - не логично.

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

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


из документации на CL

Так я сразу и сказал, что этого в CL сделать нельзя.


а ещё нельзя использовать болид F1 в качестве тягача. И что?

По твоему описанию ты хочешь нечто вроде


это не я, это ты хочешь

Только непонятно, на самом деле, при чем тут макросы и гигиена.


у себя спроси

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

Наверное, но отсутствие предупреждения - не баг

Вот это:

(defparameter x (read))
(defun yobafun () (progn (setq x (+ 1 x)) x))
(defmacro yobamacro () (yobafun))
(eval `(yobamacro))
замечательно компилируется с ошибкой в рантайме. Не баг, да? Оооок.

из документации на CL

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

а ещё нельзя использовать болид F1 в качестве тягача. И что?

Ничего. Я лишь указал, что этого в CL сделать нельзя, хотя такая возможность очень удобна. Просто пример того, что невозможно в вашей «мощной» системе. Ты зачем-то спорить начал.

это не я, это ты хочешь

у себя спроси

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

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

>> Ну откуда я мог знать, что у вас стандартный вывод по дефолту

буферизованный?


из документации на CL


Не, ну это совсем тёмный лес. Даже в спецификации Gray Streams (которая не вошла в стандарт) ничего не говорится про буферезацию. Буферизация есть (при чём, обязательно) в simple streams, но в том же SBCL они в стадии альфы. Но это уже совсем не стандарт и надо читать доку на конкретную реализацию, а там могут про это ничего и не сказать. А что такое *standard-output* очень сильно зависит от контекста выполнения (например, в SLIME он свой). Так что ссылаться в этом вопросе на документацию не стоит.

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

>Вот это ... замечательно компилируется с ошибкой в рантайме. Не баг, да? Оооок.

ЁТМ, а где ты хочешь ошибку с eval? В compile-time? Ты совсем умом тронулся?!

...это проблемы ... а не моя


конечно, мудак, не читающий документацию, ни в чём не виноват, доооо...

Я лишь указал, что этого в CL сделать нельзя, хотя такая возможность очень удобна.


ну ты ещё попроси публичный доступ к локальным переменным внутри функции... Ладно, свободен.

А я-то при чем?


А чьи это слова:

...уж как сделать в CL локальный скоп макросов, вроде такого ... это я даже не представляю.


Один в один пример на CL пишется элементарно стандартными средствами. Но это тебе по прежнему в качестве домашнего задания =)

Вот только из примера нифига не понятно, что ты хочешь использовать не доступ к top-level переменной, а к [локальной] переменной из контекста объявления макроса. Опять-же, к top-level - через префикс package, а к локальной (внутри функции?) - никак, но это хуже, чем гланды через жопу...

yyk ★★★★★
()
Ответ на: комментарий от archimag

>Не, ну это совсем тёмный лес.

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

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

в общем, если ни кто явным образом не гарантирует _немедленного вывода_, то «закладываться» я на него не стал бы =)

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