Issue: PATHNAME-EXTENSIONS (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 29 Dec 88 11:52:09 PST
    From: Jim McDonald <jlm@lucid.com>

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

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

    (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
   helpful.
 - 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 
   implementation-dependent features!
 - From Star Trek: Spock: "Captain, I'm registering a kind of energy
   never before encountered." Man, the guys who designed his scanner
   were geniuses...


    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
    vendor-specific magic.)

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.