[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
- To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
- Subject: Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Mon, 9 Jan 89 12:22:27 CST
- Cc: "Kim A. Barrett" <IIM@ECLA.USC.EDU>, cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of Sat, 7 Jan 89 12:24 EST from Richard Mlynarik <Mly@AI.AI.MIT.EDU>
- Sender: GRAY@Kelvin.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.