Re: [cclan-list] asdf and relative names

[Richard M K. <kr...@pr...>]

"Faré" writes:
> 2008/9/3 Richard M Kreuter <kr...@pr...>:
> >>
> >> At ITA, we've been happily using the attached file to allow names
> >> such as "foo/bar/baz" to be used for component names, either
> >> modules or files. It works great for us, and allows to portably use
> >> #\/ to denote relative pathnames where the character was previously
> >> forbidden in portable systems.
> >
> > Why aren't you calling PARSE-NAMESTRING on the string?  Constructing a
> > pathname from substrings you parse manually will yield different
> > results on different Lisps in various cases.
>
> The whole point of the exercise is that for .asd files to be portable,
> you do NOT want to rely on non-portable PARSE-NAMESTRING to interpret
> the relative names of modules and other components. That ASDF should
> interpret / as a directory separator in an implementation-independent
> way is a feature that makes / useful at all in portable .asd files.
> Relying on PARSE-NAMESTRING means that you have to requiring different
> module names on different implementations - which completely defeats
> the purpose.

Oh.  I thought you were reasoning that because practical portability
nowadays means porting among Lisps on platforms that all treat #\/ as a
directory separator, ASDF might as well do so, too.  

As for portability, if you write a system definition that assumes
hierarchical file naming but doesn't use logical pathnames <I'll wait
for the audience to stop laughing>, you're already restricting yourself
to a subset of the file systems that Lisp's file naming mess was
intended to accomodate, so the system definition won't be portable in
the CLHS sense anyway.  (This is why I thought it odd that you didn't
reach for PARSE-NAMESTRING.  I think it turns out that the
PARSE-NAMESTRINGs on implementations of practical consequence already
treat #\/ as a directory separator for all two physical file systems
they talk to, and so your syntax will agree with PARSE-NAMESTRING for
strings whose elements are the already-portable file name characters
plus #\/.)

But it looks as though you're saying that ASDF should supply its own
abstract file name syntax that resembles and agrees with a de-facto
portable range of physical pathname namestrings on extant Lisps, but
that's strictly distinct from physical pathname namestring syntax
everywhere.  I think that's an aesthetic lose, but I don't oppose it.

--
Richard