Number: 41

Date: 17-Mar-84  0':00':52

Submitter: Sannella.pa

Source: desRivieres.pa

Subject: READ, OPENSTRINGSTREAM, & RDTBL  ---> FULLNAME invariant discussion

Assigned To: 

Attn: Kaplan, JonL

Status: Open

In/By: 

Problem Type: Bug

Impact: Moderate

Difficulty: 

Frequency: Everytime

Priority: 

System: Language Support

Subsystem: Read and Print

Machine: 

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["JonL.pa" "24-Sep-84 01':47':41" Attn':]'
["JonL.pa" "24-Sep-84 01':48':26" Attn': Disposition': Description': Edit-By': Edit-Date':]

Description: '
Date':  8 MAR 84 21':45 PST'
From': ROACH.PA'
Subject': READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS'
To':   LISPSUPPORT'
cc':   ROACH'
'
     Do the following':'
'
	(SETSYNTAX ''$ ''(MACRO FIRST NONIMMEDIATE ESCQUOTE FOO))'
'
	(DEFINEQ (FOO (LAMBDA (STREAM RDTBL)'
	  (LIST ''BAR (READ STREAM RDTBL)))))'
'
	(SETQ STRING "$MEEF")'
'
	(SETQ STREAM (OPENSTRINGSTREAM STRING))'
'
Then (READ STREAM) produces (BAR (BAR MEEF)) instead of the expected'
answer (BAR MEEF).  Suppose FOO had been'
'
	(DEFINEQ (FOO (LAMBDA (STREAM RDTBL)'
	  (PRINT ''EEK T)'
	  (LIST ''BAR (READ STREAM RDTBL)))))'
'
Then (READ STREAM) would have produced (BAR EEK (BAR EEK MEEF)).'
If instead of printing EEK, FOO printed (GETFILEPTR STREAM), then'
(READ STREAM) would have produced (BAR 0 (BAR 1 MEEF)).'
     One source of problems': FOO is being passed the fullname of'
STREAM (i.e. "$MEEF") rather than STREAM itself.'
				Kelly'
-----'
Date':  9 Mar 84 14':11 PST'
From': Kaplan.pa'
Subject': Re': READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS'
In-reply-to': ROACH.PA''s message of 8 MAR 84 21':45 PST'
To': ROACH.PA'
cc': LISPSUPPORT.PA'
'
Yes the user function is deliberately being passed the fulname of the file, instead of the stream.  This was done originally because user functions might not be prepared to handle stream arguments, and might be doing outragious things to them like packing chars on, STRPOS etc.'
'
In the case of the string stream, this is obviously a mistake, since the stream created by OPENSTRINGSTREAM is not cached in the open file table.  A new stream is then created and cached with the fullname (= the string) is passed in to READ.'
'
I''m willing to change the specs so that the macro function gets the stream, and hope that it doesn''t cause lots of incompatibilities.  This is another step on the migration from filenames to streams.'
'
Opinions?'
'
--Ron '
-----'
Date':  9 MAR 84 15':22 PST'
From': ROACH.PA'
Subject': Re': READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS'
To':   Kaplan, ROACH'
cc':   LISPSUPPORT'
'
In response to the message sent   9 Mar 84 14':11 PST from Kaplan.pa'
'
     A second anomally (I think) in my bug report was that if you'
print to the T stream during the middle of the READ, what you printed'
showed up in what you read.'
				Kelly'
-----'
Date':  9 MAR 84 17':59 PST'
From': JONL.PA'
Subject': Re': READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS'
To':   Kaplan, ROACH'
cc':   LISPSUPPORT, JONL'
'
In response to the message sent   9 Mar 84 14':11 PST from Kaplan.pa'
'
Definitely!'
'
Feed all internal functions, including user-settable macrocharacter functions,'
the STREAM rather than any "name" for it.'
-----'
Date':  9 MAR 84 18':13 PST'
From': ROACH.PA'
Subject': Re': READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS'
To':   JONL, Kaplan'
cc':   LISPSUPPORT, ROACH'
'
In response to the message sent   9 MAR 84 17':59 PST from JONL.PA'
'
     I also think that all system code should be using STREAMs rather'
than FULLFILENAMEs as file handles.  This is necessary if we are ever'
to have more than one stream reading the same file.'
				Kelly'
-----'
Date':  9 MAR 84 20':32 PST'
From': JONL.PA'
Subject': Re': READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS'
To':   Kaplan, ROACH'
cc':   JONL, LISPSUPPORT'
'
In response to the message sent   9 Mar 84 19':15 PST from Kaplan.pa'
'
Grumble, do you realize what kind of task you are taking on?  Interlisp-10'
doesn''t have STREAMs, and the kludgy patch-up in DCODEFOR10 which uses'
JFNs isn''t general enough.'
'
pdp-10, R.I.P. ?  and shared code too?'
'
Would it be satisfactory for READ simply to pass to the macrochar function'
just exactly the argument that it received?'
-----'
Date':  9 Mar 84 19':15 PST'
From': Kaplan.pa'
Subject': Re': READ, OPENSTRINGSTREAM, & RDTBL PROBLEMS'
In-reply-to': ROACH.PA''s message of 9 MAR 84 18':13 PST'
To': ROACH.PA'
cc': JONL.PA, Kaplan.PA, LISPSUPPORT.PA'
'
OK, I''ll do it, and we''ll all take the heat.'
'
--Ron'
-----'
Date': 12 Mar 84 20':36 PST'
From': desRivieres.pa'
Subject': Lisp': OPENSTRINGSTREAM'
To': LispSupport.pa'
cc': desRivieres.pa'
Lisp-System-Date':  1-Mar-84 14':24':22'
Machine-Type': Dorado'
'
I''m having trouble with OPENSTRINGSTREAM when I subsequently READ it with my own readtable, which has most special characters wired as read macros (including [,],(,), and '').  Most of the time, I get END OF FILE.  Things work just fine if I supply the same string directly to READ.  Similarly, there are no problems if no read table is passed to READ. '
'
--- Jim '
-----'
Date': 14 Mar 84 23':46 PST'
From': Kaplan.pa'
Subject': Re': AR 41':  READ, OPENSTRINGSTREAM, & RDTBL'
To':  LISPSUPPORT.PA,'
Cc': DesRivieres, Lispcore^'
'
I looked the problem, originally reported by Kelly and manifested again, I believe, by AR41 from DesRivieres, about readmacros on string-streams getting passed the string itself, which is the fullname, so that the readmacro re-reads things that were previously read.  The problem was that there was no link from the string to that particular stream':  the next read from the string, inside the readmacro function, would create an entirely new stream and read it from the beginning.'
'
The idea that we discussed, of having READ always pass the stream instead of the fullname, seemed problematical, since there were in fact a number of machine-independent readmacro functions in the system that specifically test the filename (usually to see if it was (EQ -- T).'
'
So I postponed making the giant leap, and instead took the smaller step of not having streams produced by OPENSTRINGSTREAM have the string as their name.  Not having an explicit name, their FULLNAME is the stream datum itself.'
'
String streams that are produced by implicitly by simply reading from the string will have the string name, so that they will continue to show up on openfiles, and thus also be retrievable again by subsequent IO operations.'
'
Jim':  You might try your string reading macros in the next <lispcore> loadup.'
'
--Ron'
-----'
Date': 15 Mar 84 01':05 PST'
From': desRivieres.pa'
Subject': Re': AR 41':  READ, OPENSTRINGSTREAM, & RDTBL'
In-reply-to': Kaplan.pa''s message of 14 Mar 84 23':46 PST'
To': Kaplan.pa'
cc': LISPSUPPORT.PA, DesRivieres.pa, Lispcore^.pa'
'
Good stuff!  The changes you made to \GETSTREAM and OPENSTRINGSTREAM have completely cured the problems that I reported in AR 41.'
'
---Jim '
-----'
Date': 16 MAR 84 11':06 PST'
From': JONL.PA'
Subject': Re': AR 41':  READ, OPENSTRINGSTREAM, & RDTBL'
To':   Kaplan, LISPSUPPORT'
cc':   DesRivieres, Lispcore^, JONL'
'
In response to the message sent  14 Mar 84 23':46 PST from Kaplan.pa'
'
I don''t like this solution.  The FULLNAME operation was the only'
way to get a handle on the string for which this stream was created (by'
calling OPENSTRINGSTREAM).'
'
I still think it''s appropriate for the reader simply to pass through unchanged'
the argument given to READ.  That way, any questions about format of the "file"'
are simply deferred to the readmacro function;  any such function that needs'
to look at the fullname can call FULLNAME itself.'
-----'
Date': 16 Mar 84 14':12 PST'
From': Kaplan.pa'
Subject': Re': AR 41':  READ, OPENSTRINGSTREAM, & RDTBL'
In-reply-to': JONL.PA''s message of 16 MAR 84 11':06 PST'
To': JONL.PA'
cc': Kaplan.PA, LISPSUPPORT.PA, DesRivieres.PA, Lispcore^.PA'
'
Passing thru the argument given to READ unchanged requires the same kind of editting of all the existing macro functions that passing thru the stream would require.  The user can say (READ NIL), with NIL --> T.  The macro functions are also testing (EQ FILE T), and would behave incorrectly.  Passing thru the name unchanged would also be a step backwards down the path we want to go on--towards passing streams only.'
'
If we wanted to go around and edit all the affected macro functions, one tack to take is to make them internally call FULLNAME on the file argument, and test that against T if that''s what they want to do.  That would make it work whether we passed in the user''s partial name, or the stream. '
'
This is for the future, when we have more energy for random perturbations.  (And also, we would have to make sure that FULLNAME  of a fullname ran acceptably fast on the 10).'
'
--Ron'
-----'
Date': 17 MAR 84 13':40 PST'
From': JONL.PA'
Subject': Re': AR 41':  READ, OPENSTRINGSTREAM, & RDTBL'
To':   Kaplan, JONL'
cc':   LISPSUPPORT, DesRivieres, Lispcore^'
'
In response to the message sent  16 Mar 84 14':12 PST from Kaplan.pa'
'
The documented macrocharacter function interface doesn''t specify that the '
"file" argument has been in any way perturbed, so any changes to such a'
"perturbation" should affect only the system-supplied macrochar fns which'
depended upon this undocumented kludge.'
'
True, the "right" way to go is to coerce to STREAMs, but my R.I.P comments'
still apply for any code that wants to be compatible with the PDP10.'
'
How about this as an "interim" measure':'
  1) convert any litatom argument to READ into FULLNAME of that litatom'
  2) leave STREAM arguments alone'
Certainly, no PDP10 code would be affected by point (2), and point (1)'
would catch all current cases of PDP10 READs.'
'
In fact, I can''t see any other solution in general for STREAMS (than to'
leave them alone) since it is perfectly acceptable to create a stream'
which supports most I/O operations except FULLNAME.  Worse yet, how ever'
can one expect FULLNAME to  be information-preserving when there are multiple'
streams open on the same file.'
'
There aren''t that many system-supplied macrocharacter fns (simply scanning'
the three initial readtables will find them all).  They could simply have'
(SETQ FULL (COND ((STREAMP FILE) (FULLNAME FILE)) (T FILE)))'
which, by point (1) above, would always guarantee that FULL was the'
FULLNAME of the file, but would never call FULLNAME unnecessarily (especially'
on the PDP10).'
-----'
Date': 17 MAR 84 22':54 PST'
From': MASINTER.PA'
Subject': Re': AR 41':  READ, OPENSTRINGSTREAM, & RDTBL'
To':   JONL, Kaplan'
cc':   LISPSUPPORT, DesRivieres, Lispcore^'
'
 In response to the message sent 17 MAR 1984 1340-PST by JONL.PA'
'
I think Ron introduced the minimal change which had the positive characteristics of':'
'
a) it actually fixed the problem which started the whole thing'
'
b) it didn''t break anything else'
'
c) it didn''t commit us to immediately undertaking major rewrites of the system that we don''t have the resources to pursue.'
'
There are a number of major items which are demanding attention from Ron , you, me, etc. which this discussion merely distracts us from. Lets put in an AR, conversion from FULLNAME to STREAM, and schedule it with the rest of the items in the queue. '
'
On this topic, I''d like to re-solicit from people what their "top-ten" tasks for the coming six months are; i.e., what are the major items that you think are important to get resolved in the near future. (Not just the ones that are on your personal agenda.)'
-----'
Date': 18 MAR 84 00':15 PST'
From': JONL.PA'
Subject': Re': AR 41':  READ, OPENSTRINGSTREAM, & RDTBL'
To':   MASINTER, Kaplan'
cc':   LISPSUPPORT, DesRivieres, Lispcore^, JONL'
'
In response to the message sent  17 MAR 84 22':54 PST from MASINTER.PA'
'
Wrong. '
'
It breaks the ability to find out what STRINGP the STREAM came from.'
It also breaks the ability to re-open a stringstream.  I have used  the'
former many times, and wanted the latter ocasionally.  But of course, '
in I-10, this isn''t "broken", since it does''t have STREAMs.'
'
Larry, have you even ever used OPENSTRINGSTREAM?'
'
-----'
Date': 18 Mar 84 19':35 PST'
From': JonL.pa'
Subject': AR41': READ problem identified for OPENSTRINGSTREAM'
To': Kaplan.pa'
cc': LispSupport.pa, Lispcore^.pa, DesRivieres.pa, JonL.pa'
In-Reply-To': your msg of 16 Mar 84 14':12 PST'
Lisp-System-Date':  7-Mar-84 13':56':45'
Machine-Type': Dorado'
'
I''ve just looked at the ASSIST file (where the readmacro function definitions are) -- there is nothing complicated going on at all there so I don''t think there will be any problem fixing the OPENSTRINGSTREAM problem in a way that '
   *** doesn''t require any new development'
   *** doesn''t even require editing the macrochar fns'
   *** doesn''t break the fullfilename facility for non-FILE streams'
   *** doesn''t take more than 5 minutes'
'
The following "one-line" patch to \APPLYREADMACRO ( where the comment appears in the DEFINEQ below) completely fixes the problems reported by Kelly and Jim -- namely just use the STREAM unless it''s FULLNAME is a litatom':'
'
[DEFINEQ (\APPLYREADMACRO (STREAM MACDEF ANSCELL)'
   (DECLARE (USEDFREE #CURRENTRDTBL#))'
    (PROG ((FULL (fetch FULLNAME of STREAM)))'
          (if (LITATOM FULL)'
	       then    (* Some system-supplied macros depend upon being'
			       able to see T rather than anything else)'
		   (SETQ STREAM FULL))'
          (RETURN (APPLY* (fetch MACROFN of MACDEF)'
			           STREAM #CURRENTRDTBL# ANSCELL]'
'
Looks like it takes more work to read all the messages about why this problem is unsolvable that to just go ahead and fix it right. '
'
On that score, let me make a plea (to LispCore^) that when you feel some *important* topic needs to be discussed [e.g., what are the 10 ten projects just beyond our resources now], please use a different Subject line in the mail header than the mail you currently happen to be reading.'
-----'
From': kaplan.pa'
Date': 18-Mar-84 20':20':56 PST'
Subject': AR41'
To': JonL, Lispsupport'
'
I think I thought of that, but rejected it for reasons that I can''t remember now.  Will try to rethink.'
'
But for the record':'
'
  The fix I installed does not make it impossible to re-open an explicit string stream, if a closed instance of such a thing is given to OPENSTRINGSTREAM.  What is required is a generic facility for re-opening basebyte streams--a facility that should be installed anyway (on the last cycle, I added that kind of thing to various other file devices).  The string stream, even without having a pointer to the string iteself, has enough information to reopen from the stream.  And indeed, if the user held on to the string instead of the stream, he could always get a new instance.'
'
  The only capability that was lost in my fix was the ability to get back the string from the stream via FULLNAME.  '
'
  Note that none of this stuff with explict string streams can affect backward compatibility with 10 code, since such things never existed on the 10.  '
'
I agree that it is a slight non-feature not to be able to get back to the string from the stream--ceteris paribus, access to more information is better than access to less.'
'
  I will try to resurrect the reasons for not following JonL''s suggestion.  If I can''t, either I will back out my changes to OPENSTRINGSTREAM and \GETSTREAM on AOFD and stick in a fix in \APPLYREADMACRO--or submit an AR putting that on the action list.'
'
--Ron'
-----'
Date': 18 Mar 84 23':00 PST'
From': desRivieres.pa'
Subject': Re': AR41 and AR39'
In-reply-to': JonL.pa''s message of 18 Mar 84 19':35 PST'
To': LispSupport.pa'
cc': Kaplan.pa, Jonl.pa, Lispcore^.pa, DesRivieres.pa, Sybalsky.pa'
'
There is also a problem with OPENSTREAM, and it may be related to the one with OPENSTRINGSTREAM and to the one I reported to John Sybalsky (AR 39) concerning characters being lost when READing a stream opened with OPENTEXTSTREAM. '
'
My most recent observation is that obtaining a stream via (OPENSTREAM ''FOO ''INPUT) vs. (GETSTREAM (OPENFILE ''FOO ''INPUT)) are not equivalent --- the later seems to work; the former occasionally drops characters. First, I saw'
'
          72':(PEEKC STREAM)'
          %'
          73':(READC STREAM)'
          %('
'
and then a couple minutes later':'
'
          90':(PEEKC STREAM)'
          %'
          91':(PEEKC STREAM)'
          %('
'
'
(I''m placing my bets on some piece of code that searches ahead for the next delimiter which fails to unread the character properly.)'
   '
---Jim'
-----'
Date': 18 MAR 84 22':34 PST'
From': MASINTER.PA'
Subject': FULLNAME invariant'
To':   lispcore^'
'
Whatever the resolution of the readmacro issue (more on that below), it is expected of all streams S that'
(EQ S (GETSTREAM (FULLNAME S) mode))'
if (OPENP S mode).'
'
This translates to the fact that if'
you have the stream and get its FULLNAME that you can pass the FULLNAME around just as well.'
'
This requirement is why the FULLNAME of things like display streams and such are just the stream itself. '
'
While it is a nice idea to be able to take a string stream and find out what the original string was, using FULLNAME for that purpose would cause it to violate the above requirement unless the string->stream mapping were cached independently.'
'
Ron introduced OPENSTREAMSTRING or OPENSTRINGSTREAM exactly to avoid the overhead of the caching (which IS maintained if you just call (GETSTREAM "abcd").'
'
-----'
Date': 19 MAR 84 19':22 PST'
From': JONL.PA'
Subject': Re': FULLNAME invariant'
To':   MASINTER, lispcore^'
cc':   JONL'
'
In response to the message sent  18 MAR 84 22':34 PST from MASINTER.PA'
'
In the later paragraphs of this note, I will propose a new function TRUENAME;'
it simply isn''t reasonable to have OPENSTRINGSTREAM return something from '
which you *** can''t find a back pointer to the string ***.'
'
Unfortunately, this "invariant" you mention is nowhere documented, nor implied'
in the manual or in the relase notes.  Furthermore it simply *** cannot *** be'
maintained when we permit multiple streams on file devices -- a capability'
which the MacLisp world has had "for decades".'
'
Also, I checked the half-dozen places in system code that use'
the FULLNAME access, and 90% of them are merely informational -- e.g.,'
when \EOSERROR is called, it''s trying to tell you something more than'
the octal address of the STREAM which hit end-of-file.  The other 10%'
are used in cases where the stream has assuredly been obtained from a'
file device, and thus it will have a litatom fullname; these are the places'
that will have to be inspected when multiple openings are permitted.'
'
All that being said against the alleged "invariant", I find that I must'
concur with Ron -- that, if you, Larry Masinter, seem to think that'
there is such an invariant, then just maybe maybe some other user out'
there in the hinterland watched the results of FULLNAME on file devices'
and began to write code  thinking the same thing.'
'
In order not to risk finding out the hard way if there really are such'
users with "breakable" code, I propose to add a new function to FILEIO called'
TRUENAME which will return the full file name (if the stream is connected'
to some real file on a device), and othewise will return the TRUENAME property'
from the "property list" of the stream, the OTHERPROPS field.'
'
'
TRUENAME is appropriate, since this "invariant" is expressly disavowed'
in the MacLisp world (which has such a named function) -- one simply has'
to "hang onto" the stream because he can''t generally find it again by simply'
knowing the file''s name.  Also, it''s conceivable that someday the fullname'
field will differ from the "true" name of the file -- this happens on the'
ITS file system because of "indirect" files, which are supported in any of'
the other popular operating systems.'
'
-----'
'
From': kaplan.pa'
Date': 19-Mar-84 22':37':25 PST'
Subject': Re': FULLNAME invariant'
In-reply-to': JONL''s message of 19 MAR 84 19':22 PST'
To': JONL'
cc': MASINTER, lispcore^'
'
I think there are two very separate uses to which FULLNAME is being put.'
'
One is the use of the FULLNAME of a file/stream as a handle on that file/stream.  In this use, the invariant that Larry pointed out must be preserved.  It was not being preserved by explicitly opened string streams, and I fixed that by making the FULLNAME of such streams be the stream itself.This make the read macro case work properly (not needing the change suggested later by JonL), but more than that, it made things like (READ (FULLNAME x)) produce the desired behavior of reading from the stream x, and not some new stream whose bytes were the same as the bytes underlying x.'
'
The second use of FULLNAME currently is to provide some user comprehensible description of the stream.  This is what is used in error messages, ought to be used in the pname of the stream, and is not subject to any invariant requirements.  The description is essentially pure text.  The most useful description for a string stream is in fact the string that the stream was originally built on.  This was the reason that I originally made the string be the fullname, and in my innocence and ignorance, triggered the bugs that prompted this endless discussion.'
'
My fix to make sure that the invariant property required by use (1) was obeyed had the undesirable side-effect of eliminating the string as serving the use (2) purpose, as JonL has observed.'
'
JonL also correctly observes that in the long run the use (1) invariant cannot be maintained in the current fashion for any stream.  This is because we will eventually allow for multiple streams open on the same file, so that if the fullname is simply the full name of the file as it is known on its device, then there could be several streams with the same name.  [Indeed, the string streams were installed as the first tentative move in this direction, so it is not surprising that they provoked this conceptual confusion].'
'
We will eventually have to decide how to deal with this, either by eliminating the notion of a type-able fullname as a handle on a stream, by including an integer in the fullname that indicates which stream instance is being specified, or in some other way.  But this is for the future--I didn''t want to solve this problem when I made my bug fix, nor do I want to solve it now.'
'
However, it does seem important to distinguish the descriptive use of the fullname from the identifier use, because the descriptive use is important and will always be with us.  If we start making the distinction now, we will have one less problem to deal with when we finally bite the bullet.'
'
I think we should provide some access fns in the stream record to store the description when the description is not the same as the fullname, as a property in the OTHERPROPS field of the stream.  This would be used in system code when reporting errors involving the stream, peraps by the defprint, etc.  We should also provide a user handle on this field, perhaps by attributes in GETFILEINFO/SETFILEINFO, or perhaps now is the time to introduce the STREAMPROP function (cause we are really getting at properties of the stream, not the file behind it).  In either case, I prefer an attribute name like DESCRIPTION instead of JonL''s proposal of TRUENAME--the whole point is that this description does not "name" anything.'
'
I agree with JonL that this should be done, but it is not high on my list of things to do.  It probably has a tail of a week or so before everything comes together.'
'
--Ron'
'
-----'
'
Date': 20 Mar 84 11':07 PST'
From': masinter.pa'
Subject': Re': FULLNAME invariant'
In-reply-to': kaplan.pa''s message of 19-Mar-84 22':37':25 PST'
To': kaplan.pa, JonL'
cc': lispcore^.pa'
'
Thanks for your analysis. This "invariant" indeed cannot be maintained once we allow multiple streams on the same file; we should spec out the design for the multiple-stream proposal so that this and other ramifications are clear. We should fix the system read macros not to test (EQ file T), but what SHOULD they be testing???'
'
In the interim, it seems that many of the desirata would be alleviated if the printout of the stream datatype were fixed, e.g., if you had a string-stream on "This is a very long stream"'
it could print out as'
'
[stream]"This..."'
'
and a stream on {phylum}<LispCore>Fugue>Full.sysout;1 could printout'
'
[stream]{Phylum}<LispCore>Fugue>Full.sysout;1.'
'
Since the string can be very long, cutting off the printout after a fixed number of characters might be reasonable.'
'
I started this on [phylum]<LispUsers>STREAMPNAME. Basically, it just DEFPRINTs STREAM to print out something different. This needs to be expanded to handle the ''final version'' of string-streams.'
'
I would imagine that, once the ''informational aspect'' of the FULLNAME is gone, it would be more reasonable to change the end-of-file error to have the ''offender'' be the STREAM rather than the FULLNAME.'
'
This is (a) less likely to break extant code, since the PNAME of datatypes is advertised as implementation and machine-dependent (b) ALSO necessary on the way to multiple-streams-on-the-same-file (since the end-of-file is on the STREAM and not the file), (c) gives more useful information in a lot of different contexts (e.g., in a stack inspector window, would be nice to see the STREAM argument with more info).'
'
-----'
'
Date': 22 Mar 84 13':52':51 PST (Thursday)'
From': masinter.PA'
Subject': Re': FULLNAME invariant'
In-reply-to': JONL''s message of 19 MAR 84 19':22 PST'
To': JONL'
cc': MASINTER, lispcore^'
'
I never did understand what TRUENAME was meant to be, that was different than FULLNAME when there was a FULLNAME, and "the string that started this" when there wasn''t.'
'
What is TRUENAME of a BSP connection? of {RS232}? of the keyboard? '
'
-----'
'
Date': 26 MAR 84 17':36 PST'
From': JONL.PA'
Subject': Re': FULLNAME invariant'
To':   masinter'
cc':   lispcore^, JONL'
'
In response to your message sent  22 Mar 84 13':52':51 PST (Thursday)'
'
TRUENAME differs from FULLNAME in that certain file systems can have "indirect"'
files; this means that there is a file catalog entry for, say, the fullname'
[Server]<Directory>Name.ext;2  which causes data block sharing with the file'
[Server]<AnotherDirectory>AnotherName.AExt;8    The "string that initiated" '
the opening may be something like the fullname (which of course FULLNAME '
would return), but TRUENAME would return the "real" name where the data reside.'
'
'
The keyboard stream has a fullname (arbitrarily chosen) of KEYBOARD':'
I''m not sure if all BSP streams have litatom fullnames.'
At any rate, where there is a sensible fullname, then TRUENAME should just'
defer to it (modulo the indirection mentioned above).'
'
'
-----'
'
Date': 13 Apr 84 00':27 PST'
From': JonL.pa'
Subject': Need AR for re-opening of BASEBYTES streams, etc.'
To': LispSupport'
...'
A second AR should deal with a NAME field of some sort for strings.  I''ve proposed a function TRUENAME which would initially do a LISTGET on the OTHERPROPS field of the stream (for a TRUENAME property), and failing that, would fetch any litatom found in the FULLFILENAME field.  Future extensions to the file ssytems we deal with may require a more interactive "name" finding mechanism -- in particular I''m thinking of file systems with indirect aliasing.'
'
'
Date':  7 May 84 15':24 PDT'
From': JonL.pa'
Subject': Re': fix (READ string) not to cause permanent storage allocation'
In-reply-to': kaplan.pa''s message of 7-May-84  8':07':41 PDT'
To': kaplan.pa'
cc': SHULMAN@RUTGERS, JonL.pa, MASINTER.pa, LispSupport.pa, Raim.pasa'
'
A point to remember': after all the discussion about the potential "FULLNAME invariant", we still haven''t got a version of OPENSTRINGSTREAM which remembers what string the stream came from.  Thus the string can easily go away "instantly" at the first GC after the call to OPENSTRINGSTREAM returns.'
'
The win, as far as Jeff is concerned, is that he need not succumb to the "awful kludge".'
'
-- JonL --'
'
'


Workaround: 

Test Case: 

Edit-By: JonL.pa

Edit-Date: 24-Sep-84 01':48':27