Email list hosting service & mailing list manager

import/export asymmetry Matthias Neubauer (03 Dec 2005 16:19 UTC)
Re: import/export asymmetry bear (04 Dec 2005 04:21 UTC)
Re: import/export asymmetry Taylor Campbell (04 Dec 2005 15:09 UTC)

Re: import/export asymmetry Taylor Campbell 04 Dec 2005 15:09 UTC

   Date: Sat, 3 Dec 2005 20:20:52 -0800 (PST)
   From: bear <xxxxxx@sonic.net>

   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.