[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I like this proposal.  My reading of it is: "TYPE-OF may be purely
``informational'', but at least the value returned should consistent
as a type-specifier for the argument."  However, I think a few
emmendations are needed.

-- It should include a reference to the issue 
       The result of TYPE-OF must satisfy 
       (TYPEP object (TYPE-OF object)).
   requires the acceptance of 

-- The "Cost of non-adoption:" section says:
       Inability to use TYPE-OF in portable code except for 
       information display.
   However, the fact that (TYPE-OF 112312) is still permitted to
   return SI:MEDIUM-SIZE-FIXNUM means that full use of TYPE-OF is
   inherently non-portable anyway.  Hence this "inability" is moot. 
   Perhaps it would be better simply to focus on the inconsistency 
   permitted under the current loose definition.  I would also advise 
   changing the problem description part that claims the trouble is 
   with "portable applications"; it really is with an under-constrained
   definition that can cause one trouble regardless of whether or
   not he is "porting".

-- The sentence:
       The result of TYPE-OF cannot contain be a MEMBER type specifier, or T.
   should be emmended to include a rejection of NIL.

-- The first 15 lines or so the the Proposal section read like a
   mechanical program.  I'd suggest moving the following section more
   "up front", to better emphasize the intent of the proposal:
      The result of TYPE-OF must satisfy 
      (TYPEP object (TYPE-OF object)).
      The result of TYPE-OF must be an acceptable input to SUBTYPEP.
   Or, maybe some lines like:
      The result of TYPE-OF must be a type-specifier acceptable for use
      as the second argument to TYPEP and as input to SUBTYPEP.  In
      addition, the result must accurately describe the argument; that
      is, for any object <x>, (TYPEP <x> (TYPE-OF <x>)) must be true.
   would do it instead.

-- JonL --