From: Tin Gherdanarra
Subject: require, provide and translate-logical-pathnames
Date:
Message-ID: <45AF673C.80300@gmail.com>
What do you guys think about this?
I have a set of libraries with circular dependencies.
Question 1: Chris Riesbeck states that "circular dependencies
should be fixed, not supported". Why is this so? What's
bad about circular dependencies?
As ressourceful c.l.l.ers have suggested, circular
dependencies can be addressed with provide/require.
I will set up a central "register" or "declaration"
of all files in my system:
(setf '(logical-pathname-translations "tin-lib")
'(("string" "/home/tin/lisp/string.lisp")
("matrix" "/home/tin/lisp/matrix.lisp")
("parser" "/home/tin/lisp/parser.lisp")))
Let's name this register "register.lisp".
This has the additional benefit that we can make
the paths portable across all sorts of platforms.
In a slightly simpler world, REQUIRE and PROVIDE
could handle (translated) pathnames:
(provide (translate-logical-pathname "tin-lib:string"))
(require (translate-logical-pathname "tin-lib:matrix"))
but both calls give a type error, because
#P"/home/tin/lisp/string.lisp" is not a valid type
for either function. So I create two new functions
in register.lisp:
(defun tin-provide (name)
(provide (format nil "~A" (translate-logical-pathname name))))
(defun tin-require (name)
(require (format nil "~A" (translate-logical-pathname name))))
Consequently, any file in the tin-system would
stereotypically start like this:
;;; THIS FILE IS PARSER.LISP
(load "register.lisp")
(tin-provide "parser")
Using string.lisp, for example, would mean to
(load "register.lisp")
(tin-require "string")
Chris Riesbeck suggests to solve such problems with
add-search-path, but this is not CL, it does not work
in Clisp, for example.
The scheme presented here might not be as advanced as
defpackage, but it is easy to explain and use.
Question 2: Anything wrong with that? Does it look
amateurish?
Thanks for your attention
--
Lisp kann nicht kratzen, denn Lisp ist fluessig
Tin Gherdanarra wrote:
> What do you guys think about this?
>
> I have a set of libraries with circular dependencies.
>
> Question 1: Chris Riesbeck states that "circular dependencies
> should be fixed, not supported". Why is this so? What's
> bad about circular dependencies?
Circular dependencies typically arise from poorly factored code. If file
A needs something from file B and vice versa, then there's a body of
interrelated interdependent code that's been split over two files. That
code should either be all in A, all in B, or in some third file C, which
both A and B require. This is not just to avoid circularities in
loading. It's to improve modularity and maintainability. Interdependent
code over multiple files is easy to break.