Interned pathnames propagating bad information

[Robert W. Kerns <RWK at SCRC-TENEX>]

    Date: 20 March 1982 01:25-EST
    From: Alias for KMP <turnip at MIT-AI>
    In System 79.25, ZMail 40.7, Remote-File 2.0, LMFILE-Remote 5.3,
    microcode 849, 60.45Hz, on Lisp Machine Twenty-two:

    I loaded a file into an editor buffer. It had no associated package, so it
    took on the package KBE: because I was already editting a file in that package.
    I am not sure I approve of this behavior.
I am sure that I do not.

    I then wrote the file to AI:KMP;FSF > and FS:KMP;FSF.LISP#>. Then I went into
    a ZWEI breakpoint and did (QC-FILE "AI:KMP;FSF") and it didn't compile right
    because the KBE package shadows LET and I hadn't loaded the shadow definition.
    So I said fine, I'll go to USER:. So I went to a Lisp Listener in USER: and 
    did QC-FILE again the same way, but it still compiled in KBE:. Now since the file
    doesn't have the word KBE: in it anywhere and since I was in USER: in the listener,
    it was odd to me that it should happen this way. I assume the info comes from
    the interned pathnames. This is probably a bug.
No, I wouldn't call this a bug.  What package something is compiled in should
not depend on what package you happen to have current when you compile it.
The package really is a property of a given file.  The problem is just that
the package had never been set currectly.

    So I went back to the editor and did M-X Set PackageUSER and went back to the
    lisp listener and tried again. It still compiled in KBE. That was my bug, because
    the file defaults for the buffer were now AI:KMP;FSF.LISP#>. Fine. So I did
    C-X C-W AI:KMP;FSF > assuming the file properties as now understood by ZWEI for
    the FS: file would correctly be inherited by AI:KMP;FSF > ... they were not. This
    I believe to have been your bug. I went back to my lisp listener and tried the
    QC-FILE again and it still compiled in KBE:.
Yes, I believe this is a bug.  ZWEI should set the properties in the
generic pathname when it writes out a file.
    I went back into the editor and did M-X Set PackageUSER yet again, and sure
    enuf, this time it worked. I was able to compile the file in USER: as I had
    wanted to originally.

    I have seen this screw someone in the past and they didn't have the slightest
    idea what was going on or where the invalid package info was coming from.
    Took me a while looking at their stuff and finally I figured out it was probably
    due to interned pathnames. Interning anything is dangerous unless carfully 
    controlled. I hope these bugs can be fixed to avoid others' future confusion.
Well, I would quibble that the problem is not the interned pathnames.
The problem is the uncontrolled propogation of defaulted information.
Even if it did assume KBE for the package, it should not have saved that
information since it didn't actually know.  When it DID have information\n from the user, then it did NOT save it.  It wouldn't matter to the symptoms
whether it saved it in an INTERNED pathname, or as an actual property of
the file on disk.

I think ZWEI should assume USER unless a file has a property list saying
otherwise, and M-X Set Package should SET THE FILE'S PROPERTY LIST.
Also, ^X^W should update the information in the pathname, for the name
it writes out to.

Anyway, thanks for your comments, Kent.  I'll see about getting this
fixed up.