Would it perhaps be possible to support compilation “warnings” in addition to flat-out errors? I think the logic behind this change is good—simply adding exports being a potentially breaking change is problematic—but being completely silent about it is also possibly confusing. Having a concept of warnings in addition to halting errors would at least warn developers when building modules that something is going on.
Alexis > On Jun 23, 2015, at 06:36, Matthew Flatt <[email protected]> wrote: > > I've pushed a change to `module` so that a definition can shadow any > import, not just initial imports from the `#lang` line. > > This change is intended to reduce compatibility problems that are > created by adding an export to an existing library. The change doesn't > avoid or solve the problem in general, because conflicting imports > still trigger an error. So, it's still better to avoid adding exports > where there's a good chance of conflicts (e.g., because the added name > is short or follows a common pattern). This change might provide a > useful amount of flexibility when adding an export really seems better. > > I'm sure we've discussed this change before, and I have been opposed. > Unlike the initial import, where all bindings within a module could be > considered nested under it, other `require`s and definitions all bind > in the same scope within a module. Sam has convinced me that more > liberal shadowing is worth a try, anyway. > > For now, order matters: definitions can only shadow bindings from > preceding `require`s. Lifting that constraint, so that a definition can > effectively suppress a later import, may or may not be a good idea; in > any case, it's tricky with the old macro expander, and we can revisit > this ordering question later (if the initial experiment works out). > It's possible for an imported macro to be used in an expansion before a > shadowing definition is discovered, as in internal definition contexts. > An identifier still cannot be imported multiple times (with different > bindings) or defined multiple times. > > Naturally, I advise against intentionally writing code that depends on > shadowing imports, not only because it makes code less clear, but > because we should revert the change if the experiment doesn't turn out > well. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/20150623133639.202626501C7%40mail-svr1.cs.utah.edu. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/F85A7CA9-2E61-4365-A4D6-A357301CAE9B%40gmail.com. For more options, visit https://groups.google.com/d/optout.
