[asdf-devel] patch for component-relative-pathname

[Faré]

On 22 February 2010 11:25, Robert Goldman <rpgoldman at 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.