Decoradores Python e macros Lisp

Ao olhar para os decoradores de Python, alguém fez a afirmação de que eles são tão poderosos quanto as macros Lisp (principalmente o Clojure).

Olhando para os exemplos dados no PEP 318 , parece-me que eles são apenas uma maneira elegante de usar funções simples de ordem superior antigas no Lisp:

def attrs(**kwds):
    def decorate(f):
        for k in kwds:
            setattr(f, k, kwds[k])
        return f
    return decorate

@attrs(versionadded="2.2",
       author="Guido van Rossum")
def mymethod(f):
    ...

Não vi nenhum código se transformar em nenhum dos exemplos, como descrito em Anatomia de uma macro Clojure . Além disso, a falta de homoiconicidade do Python poderia impossibilitar as transformações de código.

Então, como esses dois se comparam e você pode dizer que eles são iguais no que você pode fazer? As evidências parecem apontar contra.

Editar: Com base em um comentário, estou procurando duas coisas: comparação entre "tão poderoso quanto" e "tão fácil de fazer coisas incríveis".

Um decorador é basicamente apenas uma função .

Exemplo no Lisp comum:

(defun attributes (keywords function)
  (loop for (key value) in keywords
        do (setf (get function key) value))
  function)

Acima, a função é um símbolo (que seria retornado por DEFUN ) e colocamos os atributos na lista de propriedades do símbolo .

Agora podemos escrever em torno de uma definição de função:

(attributes
  '((version-added "2.2")
    (author "Rainer Joswig"))

  (defun foo (a b)
    (+ a b))

)  

Se queremos adicionar uma sintaxe sofisticada como no Python, escrevemos uma macro de leitor . Uma macro de leitor nos permite programar no nível da sintaxe da expressão s:

(set-macro-character
 #\@
 (lambda (stream char)
   (let ((decorator (read stream))
         (arg       (read stream))
         (form      (read stream)))
     `(,decorator ,arg ,form))))

Podemos então escrever:

@attributes'((version-added "2.2")
             (author "Rainer Joswig"))
(defun foo (a b)
  (+ a b))

O leitor Lisp lê acima para:

(ATTRIBUTES (QUOTE ((VERSION-ADDED "2.2")
                    (AUTHOR "Rainer Joswig")))
            (DEFUN FOO (A B) (+ A B)))

Agora, temos uma forma de decoradores no Common Lisp.

Combinando macros e macros de leitor.

Na verdade, eu faria a tradução acima em código real usando uma macro, não uma função.

(defmacro defdecorator (decorator arg form)
  `(progn
     ,form
     (,decorator ,arg ',(second form))))

(set-macro-character
 #\@
 (lambda (stream char)
   (declare (ignore char))
   (let* ((decorator (read stream))
          (arg       (read stream))
          (form      (read stream)))
     `(defdecorator ,decorator ,arg ,form))))

O uso é como acima com a mesma macro do leitor. A vantagem é que o compilador Lisp ainda o vê como um formulário de nível superior - o compilador de arquivos * trata os formulários de nível superior especialmente, por exemplo, adiciona informações sobre eles no tempo de compilação ambiente de . No exemplo acima, podemos ver que a macro analisa o código-fonte e extrai o nome.

O leitor Lisp lê o exemplo acima em:

(DEFDECORATOR ATTRIBUTES
  (QUOTE ((VERSION-ADDED "2.2")
           (AUTHOR "Rainer Joswig")))
  (DEFUN FOO (A B) (+ A B)))

Que então é expandida para a macro:

(PROGN (DEFUN FOO (A B) (+ A B))
       (ATTRIBUTES (QUOTE ((VERSION-ADDED "2.2")
                           (AUTHOR "Rainer Joswig")))
                   (QUOTE FOO)))

Macros são muito diferentes das macros do leitor .

As macros passam o código fonte, podem fazer o que quiserem e depois retornar o código fonte. A fonte de entrada não precisa ser um código Lisp válido. Pode ser qualquer coisa e pode ser escrito totalmente diferente. O resultado deve ser um código Lisp válido. Mas se o código gerado também estiver usando uma macro, a sintaxe do código incorporado na chamada de macro poderá ser novamente uma sintaxe diferente. Um exemplo simples: pode-se escrever uma macro matemática que aceite algum tipo de sintaxe matemática:

(math y = 3 x ^ 2 - 4 x + 3)

A expressão y = 3 x ^ 2 - 4 x + 3não é um código Lisp válido, mas a macro poderia, por exemplo, analisá-la e retornar um código Lisp válido assim:

(setq y (+ (* 3 (expt x 2))
           (- (* 4 x))
           3))

Existem muitos outros casos de uso de macros no Lisp.

No Python (a linguagem), os decoradores não podem modificar a função, apenas envolvê-la, portanto são definitivamente muito menos poderosos do que as macros lisp.

No CPython (o intérprete), os decoradores podem modificar a função porque têm acesso ao bytecode, mas a função é compilada primeiro e pode ser manipulada pelo decorador, portanto, não é possível alterar a sintaxe, uma coisa lisp-macro -equivalente precisaria fazer.

Observe que os lisps modernos não usam expressões S como bytecode, portanto, as macros que trabalham nas listas de expressões S definitivamente funcionam antes da compilação do bytecode, conforme observado acima, em python o decorador corre atrás dele.

É muito difícil usar decoradores Python para introduzir novos mecanismos de fluxo de controle.

É quase trivial usar macros Common Lisp para introduzir novos mecanismos de controle de fluxo.

A partir disso, provavelmente decorre que eles não são igualmente expressivos (eu escolho interpretar "poderoso" como "expressivo", pois acho que eles realmente significam).

É certamente uma funcionalidade relacionada, mas, para um decorador Python, não é trivial modificar o método que está sendo chamado (esse seria o fparâmetro no seu exemplo). Para modificá-lo, você pode enlouquecer com o módulo ast ), mas precisará de uma programação bastante complicada.

No entanto , algumas coisas foram feitas: verifique o pacote de macropy para obter alguns exemplos realmente alucinantes.