On 2011-12-29, at 8:50 AM, Nikodemus Siivola wrote:
> P1 has alias P2 for P3, and P2 also exists. Current package is P1. How
> are symbols in P2 and P3 printed? Does *PRINT-READABLY* matter?
> (1) Always use global names. Problem: read-print-consistency is lost.
OTOH, stop doing it wrong. The root problem isn't that consistency is lost so much as that the user locally nicknamed the name *of a package they interact with already*.
> (1b) Always use global names. Signal an error in the presence of
> aliases shadowing global names in the printed output if
> *PRINT-READABLY* is true.
Hence, I'm fine with this. If it really matters, I think a triple-colon syntax can be hacked in.
> (3) If we add SB-EXT:*PRINT-PORTABLY*, then setting it to NIL could
> also enable printing using an escape syntax which always refers to
> global names, removing any ambiguiety.
I'd still always use global names, but I can agree to that.
> (2) Always use local names. Problem: read-print-consistency is
> partially lost. (Assuming the printed output contains only fully
> qualified symbols, previously it would have been readable into any
> package -- now only to P1.)
> (2b) Always use local names. Signal an error in presence of aliases in
> the printed output shadowing global names if *PRINT-READABLY* is true.
Well, the way I see aliases being useful (to reduce the overhead of not USEing packages) makes me want to minimize their effect on the behaviour of programs. 2/2b are more intrusive, and would make me think stop and think somewhat longer before using aliases.
> I think I like 2b to start with, with 3 as a future option -- but
> could live with 1b as well.
I'm more of a 1/1b kind of person, with 3 as a low-priority feature.