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 <mfl...@cs.utah.edu> 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 racket-dev+unsubscr...@googlegroups.com. > > To post to this group, send email to racket-dev@googlegroups.com. > > 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 racket-dev+unsubscr...@googlegroups.com. > To post to this group, send email to racket-dev@googlegroups.com. > 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 racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-dev@googlegroups.com. 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.
