[asdf-devel] MCL issue

Robert Goldman rpgoldman at sift.info
Thu May 19 18:58:32 UTC 2011


On 5/19/11 May 19 -1:24 PM, Pascal Costanza wrote:
> 
> On 18 May 2011, at 15:28, Robert Goldman wrote:
> 
>> On 5/18/11 May 18 -12:26 AM, Chun Tian (binghe) wrote:
>>> I found a workaround for myself:
>>>
>>> (in-package :asdf)
>>>
>>> (defun user-homedir ()
>>>  #P"Macintosh HD:Users:binghe:")
>>>
>>> with above code loaded as a ASDF patch, I can load other packages well.
>>
>> As I read this, it's simply a bug in MCL --- they just aren't
>> implementing user-homedir-pathname properly.
>>
>> Isn't that right?
> 
> No, it's not right. The meaning of user-homedir-pathname is (intentionally) underspecified in ANSI CL.

I was not very careful here.  The meaning of U-H-D is *not*
underspecified when the host is provided as an (optional) argument.  If
we were providing our host as an argument to the function, then I
believe the MCL behavior would be clearly buggy, since the spec says:

"The definition of home directory is implementation-dependent, but
defined in Common Lisp to mean the directory where the user keeps
personal files such as initialization files and mail."

I don't think that the MCL behavior of supplying the installation
directory of the lisp implementation is defensible in light of the above
language.

*HOWEVER*, the behavior is allowed to be more implementation specific in
the case where we do not provide the host as an argument, so in that
sense what MCL does is defensible.
...

Unfortunately, I don't believe that there is a specified way to indicate
a host, so AFAICT, there is no portable way to provide a host argument
to U-H-D, which makes it somewhat perverse to make this the case where
the behavior is defined!

> It would be good if ASDF wouldn't rely on such underspecified features, or if
> it would have a way to deal with the lack of such features in a more
> meaningful way because, for example, this may not be the last time in history
> that the notion of a user directory isn't supported or, as another example,
> that pathnames look different from the usual Unix flavors that you see these
> days.

Point taken, but I think this is unfair to ASDF.  This seems more like a
case where (as with many things involving interaction with filenames and
directories) the ANSI standard doesn't give us any /specified/ features
that fill a very real need.  So we necessarily rely on underspecified
features.  What are the /specified/ features that will fill this need?

Indeed, one of the things that ASDF does is provide a POSIX-ish portable
file system sub-system precisely because the specified facilities
(pathnames, logical pathnames) didn't do the job.

Best,
r




More information about the asdf-devel mailing list