This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
Date: Sat, 3 Dec 2005 20:20:52 -0800 (PST) From: bear <bear@xxxxxxxxx> The reason I'd like it the other way round (where you explicitly list every binding you're importing) is because when I'm debugging, and I see a mysterious function call that appears to be messing up or does something I don't understand, it would be nice to be able to just glance up at the import directive and be able to see where that function is imported from. You could determine this with a simple development environment feature to show the importation path of a binding. However, your problem is more easily solved by... The way it is now, you have to "just know" that foo-incr was defined and exported in your foo-math library or your foo-rings library, or your foo-resource library, or wherever. And IMO, that creates code that's more opaque than it needs to be and makes it hard for developers new to any particular project to be useful. ...the requirement imposed by the module system that modules (libraries) cannot import a single identifier from two different modules (libraries). Overly lenient implementations could cause confusion here, but helpfully strict ones would require you to annotate where you are selectively importing. You would then have to write (using my proposed syntax) (import ... foo-math (modify foo-rings (hide foo-incr)) ...) or some other appropriate modification to the importation.