22.8.6 Dependências do módulo cíclico

Embora não possa haver dependências circulares entre pacotes, o mecanismo frouxo de carregamento de módulos do Guile permite dependências circulares entre módulos do Guile, o que não causa problemas, desde que as seguintes condições sejam seguidas para dois módulos que fazem parte de um ciclo de dependência:

1. As macros não devem ser compartilhadas entre os módulos co-dependentes
2. Variáveis de nível superior são referenciadas apenas em campos de pacote atrasados (thunked): arguments, native-inputs, inputs, propagated-inputs ou replacement
3. Procedimentos que fazem referência a variáveis de nível superior de outro módulo não são chamados no nível superior de um módulo.

Afastar-se das regras acima pode funcionar enquanto não houver ciclos de dependência entre os módulos, mas como tais ciclos são confusos e difíceis de solucionar, é melhor seguir as regras para evitar a introdução de problemas no futuro.

Aqui está uma armadilha comum a ser evitada:

(define-public avr-binutils
  (package
    (inherit (cross-binutils "avr"))
    (name "avr-binutils")))

No exemplo acima, o pacote avr-binutils foi definido no módulo (gnu packages avr), e o procedimento cross-binutils em (gnu packages cross-base). Como o campo inherit não é atrasado (thunked), ele é avaliado no nível superior no momento do carregamento, o que é problemático na presença de ciclos de dependência do módulo. Isso pode ser resolvido transformando o pacote em um procedimento, como:

(define (make-avr-binutils)
  (package
    (inherit (cross-binutils "avr"))
    (name "avr-binutils")))

Seria necessário tomar cuidado para garantir que o procedimento acima só seja usado em campos atrasados de pacote ou dentro de outro procedimento também não chamado no nível superior.