Perhaps I missed something in my reading, but what I'd like
to do is specify the order components are connected together
in the translation. i.e. under win32 have name.version.type
Even to the point of envisioning a system that put type
first.
i.e. lisp.myfile.3
This train of thought comes from LW(Personal win32 4.1.20)
giving an error when version is not nil. It struck me
that I could solve both problems (LW's and Windows relying
on the last extension of the filename to determine type)
in one fell swoop if I had a little more control over the
assembly. Is there a way to do this other than rolling
my own logical translation functions?
-------
Geoff
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> Perhaps I missed something in my reading, but what I'd like
> to do is specify the order components are connected together
> in the translation. i.e. under win32 have name.version.type
> Even to the point of envisioning a system that put type
> first.
> i.e. lisp.myfile.3
> This train of thought comes from LW(Personal win32 4.1.20)
> giving an error when version is not nil. It struck me
> that I could solve both problems (LW's and Windows relying
> on the last extension of the filename to determine type)
> in one fell swoop if I had a little more control over the
> assembly. Is there a way to do this other than rolling
> my own logical translation functions?
This is not a problem with logical pathnames but with pathnames.
ANSI CL does not specify the syntax of pathnames, so any order that
you think there is in a namestring is a vendor choice, unrelated to
what is in the file system. USUALLY a vendor will map to the native
file system directly, but they could change the mapping to offer you
versions if they wanted.
There is no ambiguity in the specification of the portable namestring
of logical pathnames.
There is nothing that requires you to use implementation namestrings
for translations; you can use pathnames, and so then it comes down to
how the implementation maps namestrings to external filenames.
Now, common sense means that most vendors have chosen to map namestrings
using the native host mapping. The Lisp Machine did not, by the way.
It ALWAYS uses a convention called the "host colon" convention so that
if there is a ":" in the name, the part preceding it is a hostname and
the part after the colon is the namestring for the host. This may seem
subtle, but I cna assure you that the namestring "MY-UNIX:/foo/bar" will
not be a happy thing to give to MY-UNIX any more than the bar.3.lisp you
want. Some transformation, even if trivial, is required to make the
lispm's namestring appropriate for the native host. Other implementations
could offer you mapping capability, though probably most don't.
Pre-CL, I vaguely recall there might have been implementations of Maclisp (or maybe it was Franz
Lisp -- not Allegro -- something else) had a convention whereby under
Eunice (a unix compatibility environment for VAX VMS?) you could emulate
upper and lowercase filenames in an all-uppercase file system by having
the Lisp filename "Foo" map to "$FOO". That is, $'s were actually in the
real OS file system name for a file that wanted to be uppercase in the
virtual environment.
One problem you run into when you use such mapped file systems, btw, is
that although you can do cool things like foo.3.lisp, you can also
accidentally get in a situation where some legitimate files natively
named in a certain way might not have mappings (or might not have CONVENIENT
mappings) into Lisp, and Lisp might be crippled in its ability to manipulate
all files in the native operating system. Ultimately, I think it's this
fact which is the reason no one really does this. It may be sometimes
handy for Lisp to have a lot of control of the filenames it deals
with, but it's MORE important for Lisp to be able to manipulate files
given to it with whatever names by externally fixed places.
This may cause you to come back and say "no, I really meant that I
wanted logical pathnames to handle this because I *don't* want to do
it in native pathnames". Maybe. This isn't really the problem
logical pathnames set out to solve. Logical pathnames are supposed to
be a trivial mapping that lets you use a lot of file systems in a
least common denominator way. To do what you want, you'd need heavily
articulated understanding of wildcards and filename manipulation with
mappings and reverse mappings that have to be kept consistent.
(There's a similar problem in hash tables, btw. Lots of people want
to extend them to other test types, but you can't just allow an
arbitrary :test. It's harder than it looks to add a new operator and
keep the hashing working. Ditto here, logical pathnames are doing a
lot of things for you, or potentially are in some implementations,
that are not as simple as just defining translations. e.g., some
offer reverse translations, interning, etc.) It might be that hairing
up logical translations wouldn't be so bad. It is more likely to me
that you could add another facility, call it "vritual hosts" which
were like "real hosts" but were free of any translation issues they
didn't like. They might even just work for a given directory on a h ost
and not be totally general. That could make them a lot easier. And they
might be possible to add without voiding the standard, which I am not
sure logical pathname changes are.
Well, those are the issues that come to mind, anyway. Hope that helps.
I am continually astonished by KMP's breadth and depth of vision. His
previous message laid out issues I had never considered with respect
to the pathname system. And not just one or two, but a bunch of
different perspectives.
Thank you KMP, for participating in this forum. I'm sure we all
appreciate your deep grasp on the foundational issues in Lisp and your
perspective as a standards editor (and language lawyer).
:-)
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.