Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1

[Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>]

    Date: Mon, 9 Jan 89  12:22:27 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > Not so.  Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
    > When I last wrote a CL type system I needed a mess of parallel
    > COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
    > functions.  Using compilation-environment technology would have been far
    > preferable.
    > 
    > I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
    > code has the same sorts of needs.

    On the Explorer, both TYPEP and SUBTYPEP already implicitly use the
    compile-time environment when they are called from within COMPILE-FILE.
    Consequently, uses of these in macro expanders will see type definitions
    earlier in the same file without the macro writer needing to do anything
    special, so this capability could be used a lot without anyone realizing
    it.  I think it would be cleaner if these functions accepted optional
    environment arguments, which default to the compilation environment when
    within COMPILE-FILE.

The problem is defining "within" compile-file.  This is what the environment
argument determines.  A runtime call to make-array inside the guts of the
compiler (or other miscellaneous system code) which happens to be
unoptimized and calls subtypep should not be using type information from
the user's file.