[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
- To: Eric Benson <eb@LUCID.COM>
- Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Fri, 14 Oct 88 16:09:59 CDT
- Cc: CL-Compiler@SAIL.Stanford.edu, "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- In-reply-to: Msg of Fri, 7 Oct 88 17:59:47 pdt from Eric Benson <eb@LUCID.COM>
- Sender: GRAY@Kelvin.csc.ti.com
> I would like to combine all of these aspects into returned values from
> ENVIRONMENT-VARIABLE-KIND and ENVIRONMENT-FUNCTION-KIND (and probably
> change those names). That's going to mean a lot of returned values,
> though. Does anyone think that's a bad idea?
That's going to make it slower by collecting more information than you
probably need at any one time; is that a concern for what you want to
use this for?
> "All the rest of this stuff" is useful to code walkers for the same
> reason it's useful to compilers.
Useful for it's own bookkeeping yes, but does the code walker really
need to have the compiler use the same data structures so that the code
walker can access what the compiler knows?
> The extent of environment objects has been discussed before. I don't
> remember whether that became a full-fledged cleanup issue, but I think
> it is orthogonal to this issue.
It might be orthogonal in theory, but in practical terms it makes a big
difference to whether this proposal is feasible to implement as an
addition to existing compilers.
> In this case, I suspect that CLOS is going to need more than
> ENVIRONMENT-TARGET to do everything it needs to do.
>
> What is your suspicion based on?
On preliminary thinking about how environments need to be handled in our
CLOS implementation; hopefully in a couple of weeks I will have
developed a clearer idea about this.