#

## 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.

    -------

Copyright 1996-2001, Xanalys Inc. All rights reserved.