Re: [Caml-list] open Module (not?) considered harmful
On Sun, Nov 23, 2008 at 11:38:17AM +0100, Stefano Zacchiroli wrote: > On Thu, Nov 20, 2008 at 11:41:03AM +, Richard Jones wrote: > > > 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); > > That's interesting, but requires support in all involved library. Do > you know how CPAN authors are required to annotate what is "standard" > and what is not? It's left to the module authors to define how these labels work, although there are a lot of idiomatic uses. Rich. -- Richard Jones Red Hat ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
On Thu, Nov 20, 2008 at 11:41:03AM +, Richard Jones wrote: > > 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); That's interesting, but requires support in all involved library. Do you know how CPAN authors are required to annotate what is "standard" and what is not? Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
On Thu, Nov 20, 2008 at 12:31:47PM +0100, Daniel Bünzli wrote: > I disagree. Having to invoke a tool to know where an identifier comes > from when I read code involves one more (superfluous IMHO) action. Not > to mention that I do sometimes print code on real paper to read it. Fair enough. Once more though, the annoyance you are pointing out seems to me to be solved by a syntax extension (which we now have) which enables you to selectively open specific identifiers from a module, instead of only enabling to open all of it. > I do not object using open for external libraries that pack some > related _modules_ in a _single level_ hierarchy but I clearly see no > benefit of having to open things to use the standard library > (especially to use something as ubiquituous as lists). Well, given that Batteries is de facto extending the standard library to include external library, the distinction between stdandard and external it is kind of blurred in this case. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
On Thu, Nov 20, 2008 at 11:48:57AM +, Richard Jones wrote: > open Printf > open Format Let me stress once more that the Batteries hierarchy is not advertising anything like that. What is "advertising" (modulo syntax extensions helping out) is to open partial module paths which just contain other modules. I believe that scenario to be sensibly different than yours, and less prone to clashes. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
On Thu, Nov 20, 2008 at 11:29:44AM -, David Allsopp wrote: > > 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;; You are stretching quite a lot what is being proposed. You are deliberately taking two similar modules (two data structure modules, which also happen to be really similar ADTs), and opening them together. Doing that is asking for trouble, the only way to avoid that is forbidding entirely open, which nobody else has proposed either. What is being proposed wrt the Batteries hierarchy is to open module paths, which in most (maybe even all) of the cases just contain other modules. The potential clashes are related to module pairs, and wont exhibit the problem you shown, because the clashing modules will not be union-ed together. One will win over the other. > > > 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 Yes, which is one of the reason while I was proposing it. Still, you did not to comment on whether such an extension (which we already have, thanks to Nicolas) would be a satisfying solution for the open issue, which is basically my position. Cheers. -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
On Thu, Nov 20, 2008 at 02:41:12PM +0100, Nicolas Pouillard wrote: > Given the crowd of people wanting it, I've added a link [1] to the > camlp4 wiki [2] :) Erm, given the crowd of people wanting it, what about including it in legacy camlp4? :-) -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
> Consider > > open Array;; > open List;; I doubt anyone is recommending this. The module design dictates, to some extent, whether the module should be opened. Array and List clearly should not since they have commonly used function names. However, the proposed Data.Containers certainly should be opened. There is no confusion about private names in this case. If I am using Batteries, it will be clear which module "List" refers to. The bureaucracy of writing open statements at the top of every file would get cumbersome, but that can be avoided by the proposed short-circuiting. On Thu, Nov 20, 2008 at 6:29 AM, David Allsopp <[EMAIL PROTECTED]>wrote: > On 20 November 2008 10:49, Stefano Zacchiroli wrote: > > On Thu, Nov 20, 2008 at 10:33:03AM +, 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 [];; > > 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). > > > David > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] open Module (not?) considered harmful
Excerpts from Nicolas Pouillard's message of Thu Nov 20 14:01:53 +0100 2008: > 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 +, 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 > names. > > > 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. Given the crowd of people wanting it, I've added a link [1] to the camlp4 wiki [2] :) [1] http://aloxe.inria.fr/darcs/pa_import [2] http://brion.inria.fr/gallium/index.php/Camlp4_contributions -- Nicolas Pouillard aka Ertai ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
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 +, 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 names. > 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 ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
On Thu, Nov 20, 2008 at 11:29:44AM -, David Allsopp wrote: > Consider > > open Array;; > open List;; > > (* Hundreds of lines of code *) > > length [];; Oh god yes, I was bitten by almost this just a few days ago, except my code was: open Printf open Format (*...*) printf "I'm trying to debug something\n" (The file was quite literally not more than 15 lines long, but it took me a good hour to work out why that printf wasn't printing anything ...) Rich. -- Richard Jones Red Hat ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
On Thu, Nov 20, 2008 at 11:49:14AM +0100, Stefano Zacchiroli wrote: > On Thu, Nov 20, 2008 at 10:33:03AM +, 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 ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] open Module (not?) considered harmful
Le 20 nov. 08 à 11:49, Stefano Zacchiroli a écrit : 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. I disagree. Having to invoke a tool to know where an identifier comes from when I read code involves one more (superfluous IMHO) action. Not to mention that I do sometimes print code on real paper to read it. I want to be able to read code without the need of invoking tools every two lines, thus I try to follow this policy : - Any non prefixed identifier in a file is defined in that file. This makes reading and navigating through the code much more easier. The less there are implicit definitions in my code, the better. I do not object using open for external libraries that pack some related _modules_ in a _single level_ hierarchy but I clearly see no benefit of having to open things to use the standard library (especially to use something as ubiquituous as lists). Problem 2) "open Module" is too broad, hence it "splice in" the current scope all identifiers of Module. This problem doesn't occur if you pack only closely related _modules_ in the module you open. Best, Daniel ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] open Module (not?) considered harmful
On 20 November 2008 10:49, Stefano Zacchiroli wrote: > On Thu, Nov 20, 2008 at 10:33:03AM +, 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 [];; 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). David ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
