On 6/30/10 Jun 30 -2:11 PM, Faré wrote:
The contents of laturk-unique.asd:
(in-package :asdf) (defsystem "laturk-unique" :version "0.1.0" :name "laturk-unique" :author "Louis A. Turk" :description "Converts utf-8 text file to list of sorted unique words." :components ((:file "packages") (:file "iterate" :depends-on ("packages")) (:file "collate" :depends-on ("iterate")) (:file "laturk-unique" :depends-on ("collate"))))
A couple of random suggestions:
- Don't put this into the :asdf package. If you want to, create your
own package, using ASDF and COMMON-LISP, and put the definition in there (there's some debate about whether this is strictly necessary, but that's a subtlety we don't need to go into now).
I beg to disagree. If you're not going to define new bindings, and particularly if you're not even going to intern new symbols, there's nothing wrong with being in package ASDF.
I suppose that's true. I usually just use a dedicated package every time I make a system (it's part of a simple emacs template for .asd files), and then I know I'm safe and don't have to think.
If one is not going to intern new symbols, etc., one is safe, as you say. But to determine whether or not you are safe you have to think.
There's enough thinking to be done already, so I'm willing to dispense with it here! ;-)
- Don't rely on transitive closure for dependencies. E.g., probably
collate depends on packages as well as iterate and similarly for laturk-unique.
Here too I beg to disagree. Unless and until there is a tool for which this makes a difference, the only criterion for choosing what dependencies to explicitly include is what makes for a more maintainable result, at which point the author knows best.
Matter of style, I guess. I like to leave it to ASDF to do the transitive closure for me. Then if I cut a dependency (e.g., I realize that a file just contains DEFUNs that are not used at compile time), I don't end up inadvertently losing a dependency that only was tracked because of transitive closure.
As a matter of style, it's up to the author (as long as s/he gets it right!), since it should not have any effect on someone who just uses the library.
Best, r