Issue SUBTYPEP-ENVIRONMENT Writeup

Issue:             SUBTYPEP-ENVIRONMENT

References:        DEFTYPE,

                   TYPEP, SUBTYPEP,

                   UPGRADED-ARRAY-ELEMENT-TYPE,

                   UPGRADED-COMPLEX-PART-TYPE

Related issues:    Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS

                   Issue CLOS-MACRO-COMPILATION

                   Issue DEFTYPE-DESTRUCTURING

                   Issue CONSTANTP-ENVIRONMENT

Category:          CHANGE, ADDITION

Edit history:      V1, 02 Jan 1989, ???

                   V2, 12 Feb 1991, Sandra Loosemore


Problem description:


  Defining macros including DEFTYPE, DEFSTRUCT, DEFCLASS, and

  DEFINE-CONDITION are permitted to note type definitions at

  compile-time in such a way that those definitions are visible only to

  the file compiler and not to the evaluator.  This can lead to

  incorrect behavior in user code that deals with the type system, for

  example in macro expansion functions.  Such code needs to explicitly

  indicate in some way whether it wishes to deal with the type system as

  seen by the file compiler (the "remote environment"), or in the 

  current environment.


Proposal (SUBTYPEP-ENVIRONMENT:ADD-ARG):


  Add an optional environment argument to TYPEP, SUBTYPEP,

  UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE.  If the

  argument is NIL or not supplied, it defaults to the null lexical

  environment and current global environment.


  Clarify that &ENVIRONMENT may appear in the lambda-list of a DEFTYPE 

  form, as with DEFMACRO.


Examples:


  ???


Rationale:


  This is consistent with the mechanism used elsewhere to specify what

  environment name/definition lookups should be performed in.

  

Current Practice:


  Chestnut's Lisp-to-C translator supports this mechanism.


Cost to Implementors:


  Minor.  Implementations that don't support the notion of "remote

  environments" can ignore the environment arguments.


Cost to Users:


  Minor.  Users may have to be more careful about passing environment

  arguments around.


Cost of non-adoption:


  Programs that try to manipulate type information at compile-time will

  break in some implementations.


Performance impact:


  Minor.


Benefits:


  The cost of non-adoption is avoided.


Esthetics:


  Looks OK to me.


Discussion:


  Version 1 of this issue was lost.  Version 2 is a completely new

  writeup.


  Loosemore and Barrett support this proposal.


  There may be confusion about why TYPE-OF does not need an

  environment argument.  Recall that compile-time type definitions made

  by DEFSTRUCT, DEFCLASS, and DEFINE-CONDITION are permitted to be

  partial or incomplete.  Essentially, the only information that is

  required at compile-time is that a name/type mapping exists and the

  subtype/supertype relationships between all of the type specifiers.

  On the other hand, the type must be fully defined before instances can

  be created.  If no instances can be created, then TYPE-OF has no need

  to know about the type.  TYPE-OF also has no need to know about type

  specifiers defined with DEFTYPE.


-------