On 22 February 2010 11:25, Robert Goldman <rpgold...@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. _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel