Re: [cclan-list] asdf and relative names

[F. <fa...@gm...>]

2008/9/4 Richard M Kreuter <kr...@pr...>:
> 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.
>
and treat any character escaping (or lack thereof) portably across
implementations. So that I can have a module named "foo/quux-V1.234"
or a file component named "bar_fly/baz-1.234" (implicitly .lisp,
:newest) and it will do the right thing.

> 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.
Logical pathnames won't help with any of the examples above, which are
dear to me (or at least to ITA). By avoiding PARSE-NAMESTRING, I'm
making ASDF systems using this feature portable (though not
CLHS-portable) to more platforms, including say Genera or MCL
(irrelevant as they may be).

> 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.
>
My interpretation is that ASDF is *already* doing that, only its
current abstract file name syntax doesn't currently support relative
pathnames.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
"Reality is that which, when you stop believing in it, doesn't go away".
                -- Philip K. Dick