LINUX.ORG.RU

История изменений

Исправление den73, (текущая версия) :

Я вот что-то не готов с тобой согласиться. Насколько я понял, fwrap в Allegro хорош тем, что он меняет код, а не просто symbol-function. Как это согласуется с приведённым тобой макрорасширением, я сказать не могу. Как минимум, создание frwap в Аллегро состоит из двух частей - сначала его определяешь, а потом вызываешь с ним fwrap. Вот что пишут в Allegro в обосновании fwrap-ов:

This means that for example if #'foo were encapsulated, but had been previously captured and stored in a variable to be later funcalled, the funcalled function does not execute the encapsulating functionality.

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

fwrapper-ы в CMUCL определены здесь: https://github.com/rtoy/cmucl/blob/master/src/code/fwrappers.lisp

Похоже, что и вправду в CMUCL действуют по стандарту. А я ожидал, что они будут патчить исполняемый код (правда, это ненадёжно, поскольку код может исполняться в момент наложения патча). Даже если и так, всё равно в них есть функционал, позволяющий добавить несколько советов к одной функции. Во всяком случае, пока этот код обсуждается, я уже запустил Яр и под CCL, и под SBCL и в этом мне очень сильно помогли мои полсотни define-advice-ов, к-рыми я патчу сами реализации, swank и asdf. Возможность найти определение функции И одновременно определение всех его адвайсов даёт чёткий контроль над тем, что происходит в коде. Так что вы как хотите, а для меня этот опыт был полезным, и, более того, данное обсуждение уже несколько устарело.

Исходная версия den73, :

Я вот что-то не готов с тобой согласиться. Насколько я понял, fwrap в Allegro хорош тем, что он меняет код, а не просто symbol-function. Как это согласуется с приведённым тобой макрорасширением, я сказать не могу. Как минимум, создание frwap в Аллегро состоит из двух частей - сначала его определяешь, а потом вызываешь с ним fwrap. Вот что пишут в Allegro в обосновании fwrap-ов:

This means that for example if #'foo were encapsulated, but had been previously captured and stored in a variable to be later funcalled, the funcalled function does not execute the encapsulating functionality.

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

fwrapper-ы в CMUCL определены здесь: https://github.com/rtoy/cmucl/blob/master/src/code/fwrappers.lisp

Похоже, что и вправду в CMUCL действуют по стандарту. А я ожидал, что они будут патчить исполняемый код (правда, это ненадёжно, поскольку код может исполняться в момент наложения патча). Даже если и так, всё равно в них есть функционал, позволяющий добавить несколько советов к одной функции. Во всяком случае, пока этот код обсуждается, я уже запустил Яр и под CCL, и под SBCL и в этом мне очень сильно помогли мои полсотни define-advice-ов, к-рыми я патчу сами реализации, swank и asdf. Возможность найти определение функции И одновременно определение всех его адвайсов даёт чёткий контроль над тем, что происходит в коде. Так что вы как хотите, а для меня этот опыт был полезным, и, более того, данное обсуждение уже несколько устарело.