On 22 February 2010 11:25, Robert Goldman rpgoldman@sift.info wrote:
On 2/22/10 Feb 22 -10:02 AM, Faré wrote:
I am inclined to agree. I'd be happier if we could just say something like
(:file "foo" :relative-directory "bar")
instead of
(:file "bar/foo")
Why? You're just moving the complexity around, without simplifying the overall design. Moreover, the astute user is already familiar with /-separated paths (from URLs if not from his filesystem) and the second notation leverages this familiarity. Which comes very handy when files are shuffled around. Finally, we need to parse names if only to portably handle the :static-file "foo.lisp" case -- why can't we parse paths at the same time?
Least surprise: reuse familiarity with filesystem paths and/or URLs Conciseness: fewer slots that get out of sync Generality: share the same mechanism with :static-file "foo.lisp"
Counterargument:
Confusion/duplication: Compute the component-relative-pathname through some confusing combination of :pathname and :name. Abuse of the :name to provide pathname functionality.
The so-called "abuse" ALREADY exists, and has ALWAYS existed.
Non-orthogonality: Compute the pathnames of modules and files differently (name not used to give
In 1.624, this is solved: string arguments to pathname are processed exactly the same portable way as name. No more non-portability there.
You don't have to map modules one to one to files. E.g.
(:module "bar" :components ((:file "foo"))) (:module "bar1" :pathname "bar/" :components ((:file "bletch"))
Right?
Wrong! "bar/" was non-portable, until 1.624. Now it is portable. And if you're going to have only one file per module, you may as well (:file "bar/foo") (:file "bar/bletch") That said, if you *insist* on the above for your own software, no one will prevent you from using that style.
The hair is in the notion of CL pathnames itself. Get rid of it. How do you think this feature can be modularized anyway?
I don't agree. I think the hair comes from putting pathname computation into two places: into the name and into the :pathname. I'd rather see all the pathname computation delegated to the :pathname argument.
It is. With the :pathname argument defaulting to :name. As has always been the case. Except that now the interpretation of strings as pathnames is portable.
The feature is now solved. It is a bug in the documentation if it says otherwise.
I simplified the documentation accordingly.
Actually, now that I think of it, for portability reasons, and to avoid all these ugly :pathname #.(make-pathname ...) any string argument to :pathname should be processed through component-name-to-pathname-components. You can still #p"..." if you want your system's non-portable parse-namestring, or #.(make-pathname ...) if you are crazy about it.
Currently, :pathname <string> is non-portable and thus USELESS.
I'd rather fix :pathname than add hair to name....
I just fixed it.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Watt refused applications for licenses to make engines under his patent: he discouraged experiments by Murdoch with locomotive models; he was hostile to the use of steam at high pressure; and the authority he wielded was such as to clog engineering enterprise for more than a generation. If his monopoly had been allowed to expire in 1783 England might have had railways earlier. If a similar privilege had been extended to Arkwright - if, indeed, his wide patents had not been annulled in 1781-5 - it is at least possible that a dead hand might have rested on the cotton industry also, and that forces tending to raise the standard of life of the poor would have been stifled.
— Ashton T.S., An Economic History of England: The 18th Century.