Number: 2249

Date: 25-Sep-84 09':15':47

Submitter: Kaplan

Source: Kaplan

Subject: GETFILEPKGTYPE implementation issues

Assigned To: 

Attn: Masinter, Kaplan

Status: Open

In/By: 

Problem Type: Design - Impl

Impact: Moderate

Difficulty: 

Frequency: 

Priority: Hopefully

System: Programming Environment

Subsystem: File Package

Machine: 1132

Disk: 

Lisp Version: 24-Sep-84 09':49':01

Source Files: 

Microcode Version: 5124

Memory Size: 4096

File Server: 

Server Software Version: 

Disposition: '
["Sannella.PA" "25-Sep-84 11':24':52" Subject': Status':(New->Open) Impact':(->Moderate) Description':]

Description: '
GETFILEPKGTYPE currently deals with both types and coms, and sometimes coerces between them.  Here is a discussion of issues surrounding this implementation':'
'
Date': 25 AUG 84 22':49 PDT'
From': MASINTER.PA'
Subject': GETFILEPKGTYPE'
To':   kaplan'
'
The current version does the right thing except in one case': if something is both a COM and also a synonym for another TYPE, then'
'
GETFILEPKGTYPE(something) will *not* return something but rather the thing it is a synonym for.'
'
The only instance of this in the system is GLOBALRESOURCES. It is a valid file package command, but it is also a synonym for the type RESOURCES.'
'
GETFILEPKGTYPE(GLOBALRESOURCES) returns RESOURCES instead of GLOBALRESOURCES.'
'
(now, GETFILEPKGTYPE(GLOBALRESOURCES TYPE) *should* return RESOURCES, but if you don''t say, it should default to returning the arg if the arg is valid as a COM or a TYPE.)'
'
Since this has little or no effect on any code that I know of, I think I will leave it in until I cool off ... it may be a few years.'
'
------'
'
From': KAPLAN.pa'
Date': 26-Aug-84 11':33':10 PDT'
Subject': Re': GETFILEPKGTYPE'
In-reply-to': Your message of 25 AUG 84 22':49 PDT'
To': MASINTER'
cc': kaplan'
'
Sounds good.'
'
Seems to me that the real bug is in any caller that doesn''t specify an ONLY.  I have always been confused by the fact that the system somehow seems unwilling to clearly make the distinction between COMS and TYPES, tending to fold them together.'
'
I think this is a design flaw.  In reality, there should be a separate GETFILEPKGCOM distinct from GETFILEPKGTYPE.  Any caller who doesn''t want to discriminate (I submit there should be none such) should be forced to explicitly call them both.'
'
In short, I think this whole tempest arises cause of an original conceptual bug':  I think it was Warren who never quite understood that it was an only an accident that many coms had the same name as the type that they dumped.'
'
Well, maybe we''ll fix that in a couple of years too.'
'
Let sleeping dogs lie...'
'
--Ron'
'
-------'
'
From': masinter.pa'
Date': 26-Aug-84 14':13':58 PDT'
Subject': Re': GETFILEPKGTYPE'
In-reply-to': Your message of 26-Aug-84 11':33':10 PDT'
To': KAPLAN'
cc': MASINTER'
'
There are a number of functions for which the either a type or a command are acceptable': WHEREIS, SHOWDEF, DELFROMFILE, MOVETOFILE come to mind.'
'
The problem with two different functions and calling both is that the various coersions should only apply after non-coerced values are rejected e.g.'
'
(GETFILEPKGTYPE foo)'
'
means'
'
(OR (GETFILEPKGTYPE foo ''TYPE ''NOCOERCE)'
    (GETFILEPKGTYPE foo ''COM ''NOCOERCE)'
   (GETFILEPKGTYPE foo ''TYPE T)'
    (GETFILEPKGTYPE foo ''COM]'
'
------'
'
From': KAPLAN.pa'
Date': 26-Aug-84 22':33':32 PDT'
Subject': Re': GETFILEPKGTYPE'
In-reply-to': Your message of 26-Aug-84 14':13':58 PDT'
To': masinter'
cc': KAPLAN'
'
I know that either a type or command are acceptable to a number of functions (WHEREIS, SHOWDEF, etc.), but to tell you the truth, I don''t know why.  The fact that I could move "VARS" commands from one file to another just doesn''t make sense to me.  I can believe moving definitions of type variable, but not commands that happen to have that name.  If I say to move FOO where FOO is a command, not a type, does that mean to move the kinds of types that FOO would dump?'
'
This is precisely the lurking confusion that has been in there since 1978.  I think that it stems from the fact that some types have commands of the same name, which means that you can perform lots of type-based operations on what look like command names--but you are really performing them on the type of the same name.  We then generalized from this accidental ambiguity and came to the conclusion that somehow we must be able to treat all commands, even ones that do not also name types, as types for some number of operations.'
'
If I''m missing something here, please set me straight and end all these years of confusion!'
'
--Ron'
'
--------'
From': masinter.pa'
Date': 26-Aug-84 23':33':32 PDT'
Subject': Re': GETFILEPKGTYPE'
In-reply-to': Your message of 26-Aug-84 22':33':32 PDT'
To': KAPLAN'
cc': masinter'
'
there are often commands which don''t correspond to TYPEs. For example, BITMAPS.'
'
It makes a lot of sense to say'
'
move the BITMAP X from file A to file B and it used to work, before your recent excursion into the file package. '
'
In no longer works because you changed the GETFILEPKGTYPE inside MAKENEWCOM to only accept TYPE, which just isnt reasonable.'
'
'
--------'
'
From': kaplan.pa'
Date': 27-Aug-84  8':40':23 PDT'
Subject': Re': GETFILEPKGTYPE'
In-reply-to': Your message of 26-Aug-84 23':33':32 PDT'
To': masinter'
cc': KAPLAN'
'
Ahh, but the known glich there is that BITMAPS is a separate command.  Many people would be much happier if the VARS command worked reasonably when it encountered a datatype, so that we could flush BITMAPS, ARRAYS, CURSORS as commands.  Then you''d have to be more honest':  if you wanted to be able to move bitmaps from A to B, then you''d have to define a type BITMAPS instead of sneaking it in under the vars  command.  The BITMAPS command is very sneaky, remember, trying to look like a VARS command for some operations (cause that''s what it is really dumping, only with a funny printer and what used to be funny behavior under move).  If you wanted to move bitmaps, you should really say you want to move VARS.'
'
The propensity to invent commands to dump special types of vars is driven by the inadequacy in PRINTDEF concerning embedded (or top-level) datatypes.  As a minimum, that printing defect requires a special printing handle, but it has seemed unreasonable to then have to go and define all the rest of the mechanism to make bonafide types.  So we let the type/com distinction get confused--and also, for some of these special commands, we went in and editted some of the system filepkg functions (INFILECOMS I seem to recall particularly) so has to specifically include ARRAYS and BITMAPS as if they were vars.'
'
This is hack upon hack, all because we were (I was) unwilling to bite off the pretty-print problem, cause I didn''t understand the various new conventions for vertical bar HPRINT read macros, which would be used systematicallly by pretty to dump embedded datatypes.'
'
--Ron'
'
'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date: 25-Sep-84 11':24':52