[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-EXTENSIONS (Version 1)
- To: email@example.com
- Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 29 Dec 88 15:23 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: <8812291952.AA11022@bhopal>
Date: Thu, 29 Dec 88 11:52:09 PST
From: Jim McDonald <firstname.lastname@example.org>
Does this really need to be a part of the standard? Why can't it
just be privately distributed (or re-invented) by the few sites that
want it? As far as I can see, it is merely a syntax checker which
sits entirely on top of the current language, and anyone who cares
can implement it quickly after reading the standard.
The answer to this is in the proposal (Cost to Implementors):
Small. The program is fairly straightforward. It could almost be
written as a portable library if it weren't for detecting special
characters that have some special syntax.
A truly portable program cannot know that "*" or "~" or whatever
is special to some file systems and not to others.
If one is to persue portability in this fashion, I think it would be
more elegant to seriously implement the COMMON data type
I'd be really surprised if you could come up with a meaning for this
as a type. I could imagine you almost coming up with a meaning for COMMON
which was representable as a predicate, but I don't think you could do
it as a type. It's clear that some non-COMMON data types have to be
subtypes of COMMON. For example, arrays with array leaders on the 3600.
You might write a COMMON-P predicate which detected this, but you'd be
misled by subtypep relations if you really pursued this as part of the
and have a
pair of predicates that tested any given lisp form and said whether it
was data (or code) that adhered to the common lisp standard.
If you want to write a description of such a predicate, I think we should
have it. But I don't think you could describe it adequately, so I was biting
off a particular part of the problem that has some real world application.
Pathnames are interestingly different from other CL data because they involve
a syntax (namestrings) which are specified by an external agency (the file
system) and which correspond to data structures (directories, links, files,...)
which are also really beyond the scope of CL to legislate. As such, they are
more prone to legitimately deviate than other aspects of CL data. At least
in the case of other data, you can argue that the implementors could have
opted to not provide the extensions (eg, array leaders). You can't argue
that CL implementors should fail to support some kinds of files just because
the CL model doesn't suppor them. They must support all files, or CL programmers
will be laughed at by their friends that use -real- programming languages.
If they do support all files, then either we must have amazing foresight in
choosing just the right pathname model, or we must guard ourselves by providing
ways for CL implementors to legitimately deviate without screwing up normal
(The data predicate might itself be written portably.
It cannot be written portably. Examples:
- From Scheme: Scheme does not define a way to adjust the length of
a STRING. Unfortunately, some implementations do. The Scheme spec
did not define (EQL "" ""), but did define that operationally
equivalent data was EQL. Since the only side-effecting string
operations in Scheme set a string element (and don't change its
size), then "" can't be side-effected, and so by implication
(EQL "" "") should return T. However, some implementations extended
Scheme to provide operations to change a string's length. Those
operations (rightly, I think) interpreted the spec to say that
(EQL "" "") could return NIL. No portable predicate on "" can
detect that someone has added an operation that makes "" not fit
the model that Scheme had for strings. The issue here is that
sometimes it's the operators which cause the confusion, not the
data layout, so making a function just on data is not necessarily
- From Genera: What portable operation can detect that an array has
a leader (given that EQUAL ignores leaders). Answer: None. You have
to use implementation-dependent means to detect
- From Star Trek: Spock: "Captain, I'm registering a kind of energy
never before encountered." Man, the guys who designed his scanner
The code predicate would need to be ported to each vendor to
detect supported but non-standard features,
Then what's the point of claiming it's portable?
since (TRICKY X) would be standard if TRICKY
were user-defined, but would not be if it implemented some
What is "it" in this sentence?
Given such predicates you could safely descend through any lisp
structure, using the predicates to warn you of pitfalls ahead.
Given the above, I think this is naive.
Doing bits and pieces of syntax checking seems somewhat ad hoc, unless
the claim is that pathnames are and will be the only "standard" data
which have unpredictable format.
Well, as I mentioned above, there's a real empirical reason to believe
that if not the only one in that `class,' they are at least part of an
elite group. Streams might be another candidate, but I don't happen to
be interested in that.
In any case, I have grown very weary of arguments of the form
"Gosh, you thought up an interesting thing there, but before
I'll agree with it, I think you should generalize it a lot more
for no apparent reason." Lots of things we've proposed as cleanups
are incidences of larger problems, but I think we ought to just consider
what's proposed. If it's important to someone to solve the more general
case, let them write the proposal and I (at least) will consider it for
what it's worth. But in the absence of such a general proposal, I don't
agree that it's best to just admit defeat and do nothing. There is a lot
to be gained by solving subsets of problems and gaining experience for
the next round. Maybe ten years from now we'll know if a primitive like
this had unforseen problems, we'll know if it got any (or a lot of) use,
etc. The COMMON type was an example. It was a noble experiment and
probably should be put to death now that it's been demonstrated to be a
loser. But it didn't cost users at all, and it didn't cost implementors
much (an evening each of lost sleep for a few implementors here and there)
to have it there -- and we learned something in the process.