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.
On Fri, 2 Dec 2005, Matthias Neubauer wrote: >It looks to me that the specification of imports and the specification >of exports follow different philosophies of declaring things. > >With imports, some names may get imported implicitly by importing >other libraries as a whole. If you read an import declaration you >cannot be sure what exactly gets imported (or, to put it differently, >what is required by the module.) > >With exports, on the other hand, you have to *explicitly* name *all* >the bindings that get exported. If you look at a module, it is always >clear what it provides. Yeah, I saw that too. Honestly, I'd prefer it were the other way 'round, but I know I'm in the minority with that opinion. Most coders want a very succinct import directive, because they'll have to write it many times, and any relevant complex information in the export directive, because it has to be written once. The laziness-as-virtue thing means fewer keystrokes wins. 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. 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. Bear