[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
- To: Gray@DSG.csc.ti.com, Mly@AI.AI.MIT.EDU
- Subject: Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
- From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
- Date: Mon, 9 Jan 89 19:06 EST
- Cc: IIM@ECLA.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: <2809362147-10213162@Kelvin>
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
> 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
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.