[asdf-devel] MCL issue

[Pascal Costanza]

On 19 May 2011, at 20:58, Robert Goldman wrote:

> 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."

There is no such directory in pre Mac OS X.

> 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.

OK, in this case I was not careful. Here is what the documentation says:

When Macintosh Common Lisp is run, two logical hosts are set up automatically:
* The host "ccl" is set to the directory holding the MCL application.
* The host "home" is set to the directory holding the document that was launched with Macintosh Common Lisp.

user-homedir-pathname returns #P"home:" which points to wherever you started MCL from (for example, by double-clicking on some .lisp file).

>> 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.

Because ASDF 2.x caused me some trouble in RMCL, I actually put some effort into learning logical pathnames - and they seem to work extremely well, as far as I can tell (but it requires specifying :ignore-inherited-configuration in my source registry configuration, which seems somewhat unclean to me - but I don't really know...)


Pascal

--
Pascal Costanza