Adding a warning sounds useful to me. I've pushed that change. At Tue, 23 Jun 2015 07:13:21 -0700, Alexis King wrote: > 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-s > vr1.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-A357301CAE9 > B%40gmail.com. > 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/20150623235737.928A96501DA%40mail-svr1.cs.utah.edu. For more options, visit https://groups.google.com/d/optout.
