Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Wanted: your feedback on the hierarchy of OCaml Batteries Included
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-11-20 (13:02)
From: Nicolas Pouillard <nicolas.pouillard@g...>
Subject: RE: [Caml-list] open Module (not?) considered harmful
Excerpts from David Allsopp's message of Thu Nov 20 11:29:44 UTC 2008:
> On 20 November 2008 10:49, 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.
> Consider
> open Array;;
> open List;;
> (* Hundreds of lines of code *)
> length [];;

That's not a good example, because I consider the shadowing above as
an ambiguity on certain identifiers. Don't confuse short names and ambiguous

> The code is now is brittle in terms of the order of the open statements at
> the top of the file and will fail to compile if they're swapped. Of course,
> if you don't care about that kind of subtle refactoring error then open is
> completely fine. Personally, I find that kind of brittleness irritating -
> and it also has the potential to waste a huge amount of time if you have to
> refactor the code.
> Whether you find code less readable with or without module names is of
> course a matter taste and IIRC, OCaml 3.11 .annot files contain the
> necessary information to expand them so there could be a nice editor plugin
> to expand or remove module paths...
> > >   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.
> Which, for values only, is of course a trivial camlp4 extension... and could
> be generalised to include type declarations and so on with only a little
> more work. The .NET languages have a syntax for selectively importing
> classes from a namespace rather than the entire namespace (and it's
> different from Java's in that you can rename the class while you do it).

I have a trivial camlp4 extension for that actually if someone is interested,
feel free to ask.

Nicolas Pouillard aka Ertai