On Thu, Nov 20, 2008 at 11:49:14AM +0100, Stefano Zacchiroli wrote:
> On Thu, Nov 20, 2008 at 10:33:03AM +0000, Richard Jones wrote:
> > Encouraging developers to open modules is also usually a bad idea,
> > except in very limited circumstances (hello Printf).
> 
> Why? You and others failed me to convince of this. Or, better, I'm
> sure there are problems with that, but they just show deficiencies
> inherited from other parts of the language.
> 
> Problem 1) once you open you loose the information where an identifier
>   comes from. True, but it is a tool deficiency, not an intrinsic
>   deficiency.
>   AFAIU Ocamlwizard addresses that [1].

Well, it is a tool deficiency, but the fact is that it's a deficiency
we have, and until someone writes the tuareg extension for
ocamlwizard, we'll continue to have this deficiency.  (Better not
forget vi users, ocamde users, Eclipse, etc.)  'Course, that fixes the
editor part, but there's still all the other places where OCaml code
can be displayed - eg. on web pages, in version control systems, in
books, .. - so better extend ocamlwizard to those areas too.

[...]
>   The most straightforward solution to this problem to me looks like
>   providing a syntax equivalent like "from Module import foo, bar"
>   which selectively imports only some identifiers from a given module.

Again, Perl gets this mostly right, in that the module developer can
define "modes of use" of the module.  In Perl something like:

  use CGI qw(:standard);

causes all the "standard" symbols to be imported (as defined by the
module author).  Or you can import just the symbols you want.  As
befits a dynamic language, the implementation is completely flexible
-- at runtime the module sees the literal string parameter and can
decide to export any combination of symbols it likes based on the
string parameter.  An example of how flexible and idiomatic that can
be is shown here:

  http://search.cpan.org/dist/CGI.pm/CGI.pm#SPECIAL_FORMS_FOR_IMPORTING_HTML-TAG_FUNCTIONS

Rich.

-- 
Richard Jones
Red Hat