Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Hi Benedikt, You're right, we should make this kind of decision. For the moment, we are focusing on different issues (e.g. standardising I/O, enumerations, module names, etc), in an effort to obtain a base relatively fast, something which could be tested both with existing code and new applications. It is our hope that this will yield enough interest for people to comment and discuss policies regarding exceptions, labels, etc. Cheers, David On Fri, 2008-12-19 at 11:00 +, Benedikt Grundmann wrote: Somehow I forgot reply back when you posted this reply. And I was just reminded when I read this: Batteries is meant to serve the following purposes: [snip] provide consistent abstractions and APIs for otherwise independent libraries. on http://wiki.cocan.org/events/europe/ocamlmeetinggrenoble2009 How can you expect to provide consistent abstractions if you are not willing to make those decisions? Cheers, Bene -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Latest News of French Research: System being liquidated. Researchers angry. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Somehow I forgot reply back when you posted this reply. And I was just reminded when I read this: Batteries is meant to serve the following purposes: [snip] provide consistent abstractions and APIs for otherwise independent libraries. on http://wiki.cocan.org/events/europe/ocamlmeetinggrenoble2009 How can you expect to provide consistent abstractions if you are not willing to make those decisions? Cheers, Bene 2008/11/18 David Teller david.tel...@univ-orleans.fr: Ok, that's an interesting point. Now, we just need to all agree on one standard :) On Tue, 2008-11-18 at 12:28 +, Benedikt Grundmann wrote: Do you see any better way of managing the complexity of all this? Yes don't introduce it at all, make a decision to use or not use labels and stick with it. Similarly make a decision to use or not use exceptions as the default, suffix / rename alternative functions as appropriate (consistently). Consistency is a big win. Not only as it speeds you up when you read/modify other people's code it also reduces the amount of decisions you have to do when writing new code. http://ocaml.janestreet.com/?q=node/28 Cheers, Bene -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. -- Calvin: I try to make everyone's day a little more surreal. (From Calvin Hobbes) ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Wed, Nov 19, 2008 at 05:37:51PM +, Richard Jones wrote: Regarding the advantages see my previous post, where I put some motivations. Regarding the difficulties of moving modules around, how harder is than moving a module around when you have no hierarchy? Well I guess what I _meant_ to say was that if your modules aren't in a hierarchy to start with, then you won't be tempted to move them around the hierarchy :-) ... which sounds like cheating :) -- 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Fri, 2008-11-21 at 00:18 +0100, Daniel Bünzli wrote: Le 20 nov. 08 à 22:12, David Teller a écrit : If anyone is willing to work on a solution for linking documentation from third-party libraries into one transparent source, as suggested by Richard Jones, please contact me. I'm not sure I understand what you want to acheive. If it is only a documentation issue cannot that be done with ocamldoc's -dump and - load ? No, it's not. You cannot ask everyone to regenerate all the documentation of every single package they have as often as they install new packages. The problem is linking already-generated documentation post-facto. Batteries (pack) 1. Standard (automatically opened) Is this Pervasives ? If it is I think the latter name is more descriptive. It is the replacement for [Pervasives], indeed. And I'm pretty sure that, for beginners, [Pervasives] is more confusing than [Standard]. Since it's automatically opened anyway, most people won't need to know the name. 13. Threads (A module containing aliases to Condition, Event...) 19. CoThreads (as Threads but with implementations coming from coThreads) If Threads and CoThreads are really semantically compatible I think that your idea of only having everything in Threads and CoThread is better and sufficient (i.e. top-level Condition, CoCondition, etc. should be dropped). Advise the users to open Threads/Cothreads to use the modules (or functorize their code on Concurrency). This allows to quickly switch from one implementation to the other by changing the toplevel open directive. With the current proposal users may be tempted to use Condition directly, and what happens if some have used Condition and others CoCondition in their modules and we suddenly try to use them toghether ? Well, that was my argument for hierarchies. Stop stealing my arguments :) More seriously, sure. While I personally find this solution a little clumsier than the previous hierarchy, ymmv. Of course when you look it as a long list it does, but that's a presentation issue. This proposal is much more convenient to use in your code and that's what eventually matters (at least to me). Thanks for the new proposal. Well, I've started working on a new generation of documentation generation should make navigation by topics feasible. I'll try and have a prototype within 1-2 weeks. Best, Daniel Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Erkki Seppala a écrit :
Richard Jones [EMAIL PROTECTED] writes:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
However, this would take away some of the benefits. For example I
prefer using the least amount of opening of modules, to make it easier
to see where the values come from, and let module S = System would
give me both IO and File reachable through S.IO and S.File
I subscribe to Richard Jones and Zheng's comments,
Using a dot means that the System namespace cannot be extended by
external packages. If you use an underscore then an external package
can extend the namespace (eg. by providing System_Newpackage)
I'm not sure how beneficial it would be that an external package can
extend the hierarchy anyway.
Disllowing third parties to extend the namespace enforces organization
of libraries in terms of PROVIDER, FUNCTIONNALITY. For the galaxy of
small modules porviding multi-purpose functionnalities, hiding the
provider from the name space makes programs and module lists more
legible. For instance, in CPAN (Perl) providers does usually not appear
in the namespace, and searching functionnalities in the wealth of
modules in CPAN is made (more) easy by this.
___
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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Excerpts from Maxence Guesdon's message of Wed Nov 19 21:11:24 +0100 2008: On Wed, 19 Nov 2008 10:46:24 +0100 Paolo Donadeo [EMAIL PROTECTED] wrote: Couldn't we take inspiration from the Python standard library [1]? Python hasn't namespace but is provided with a module system similar to OCaml *and* the standard library is really impressive. And nobody can say Python is a bureaucratic language like Java :-) [1] http://www.python.org/doc/2.5.2/lib/lib.html Hello, I think a hierarchy in the documentation is very useful: it helps beginners understand the big picture about all available modules and help developers find the functions they look for. But in the code, I think it is really more convenient to only have one level of standard modules. By the way, I, too, always prefix idents with the module they come from, (like in List.length) and only open a module to use fields and constructors, so using Data.Containers.List.length or whatever is longer than List.length is not an option. Having a shortcut List for Data.Containers.List does not convince me, because the problem will remain with modules with no shortcut. So hierarchy in documentation: yes; in the code: no. No one (I guess) would recommend you to use fully qualified paths as in Data.Containers.List.length of course. Data.Containers.List.length is the external name, made to be well organized not to be quick to type, the way to use it to open it *OR* to define an internal name for it : module L = Data.Containers.List And then use L.length, L.map... I know that the choice of name qualification, opening, or local modules is controversial, however I would like to point out that the external name don't need to be the same than the internal name. Cheers, -- 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Thu, Nov 20, 2008 at 10:28:07AM +0100, Nicolas Pouillard wrote: No one (I guess) would recommend you to use fully qualified paths as in Data.Containers.List.length of course. Data.Containers.List.length is the external name, made to be well organized not to be quick to type, the way to use it to open it *OR* to define an internal name for it : module L = Data.Containers.List And then use L.length, L.map... I've lost the plot on what problem are we trying to solve .. except for the original one which is Windows users are too stupid to use a packaging system, so let's give them everything in a single installer. But surely having everyone using privately named modules is a bad idea? The private names chosen won't be consistent, and they require a reference back to the top of the code to find out which module they are really using. Encouraging developers to open modules is also usually a bad idea, except in very limited circumstances (hello Printf). 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Excerpts from Richard Jones's message of Thu Nov 20 11:33:03 +0100 2008: On Thu, Nov 20, 2008 at 10:28:07AM +0100, Nicolas Pouillard wrote: No one (I guess) would recommend you to use fully qualified paths as in Data.Containers.List.length of course. Data.Containers.List.length is the external name, made to be well organized not to be quick to type, the way to use it to open it *OR* to define an internal name for it : module L = Data.Containers.List And then use L.length, L.map... I've lost the plot on what problem are we trying to solve .. except for the original one which is Windows users are too stupid to use a packaging system, so let's give them everything in a single installer. But surely having everyone using privately named modules is a bad idea? The private names chosen won't be consistent, and they require a reference back to the top of the code to find out which module they are really using. Encouraging developers to open modules is also usually a bad idea, except in very limited circumstances (hello Printf). Actually having to look at the top of each file (and only the top), is my favorite option. That's in fact exactly what I already do. -- 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Dear list, Feedback from active members of the list (and a few other shy people who seem to prefer answering off-list:)) seems to indicate that Batteries shouldn't have a general hierarchies of modules but rather a flat list of modules with a few submodules here and there, along with a documentation allowing navigation by topics. While that's not my personal judgement, I'm willing to go along. So here's a reworked map of the library, along with a few placeholders to get an idea of where upcoming modules will fit. Text version follows and html version available on-line: http://dutherenverseauborddelatable.wordpress.com/2008/11/20/ocaml-batteries-included-the-hierarchy-reloaded/ . While I personally find this solution a little clumsier than the previous hierarchy, ymmv. Again, feedback is appreciated. If anyone is willing to work on a solution for linking documentation from third-party libraries into one transparent source, as suggested by Richard Jones, please contact me. I'm sure it is feasible, with a (un)healthy dose of JavaScript, but I'm not sure that current members of Batteries have enough brainpower available to work on this on top of Batteries. Cheers, David Batteries (pack) 1. Standard (automatically opened) 2. Legacy A. Arg B. Array C. ... 3. Future (things that should become standard eventually) A. Lexers I. C II. OCaml = I. Control = 4. Exceptions 5. Return 6. Monad (Interfaces for monadic operations ) I.1. Concurrency 7. Concurrency (Interfaces for concurrency operations) === I.1.i. Built-in threads === 8. Condition 9. Event 10. Mutex 11. RMutex 12. Thread 13. Threads (A module containing aliases to Condition, Event...) === I.1.ii. coThreads === 14. CoCondition 15. CoEvent 16. CoMutex 17. CoRMutex 18. CoThread 19. CoThreads (as Threads but with implementations coming from coThreads) === I.1.iii. Shared memory === 20. Shm_* (Placeholders) = II. IO = 21. IO A. BigEndian 22. Codec (common interfaces for compressors/decompressors) 23. GZip 24. Bz2 25. Zip 26. Transcode (Unicode transcoding) = III. Mutable containers = 27. Array A. Cap I. ExceptionLess II. Labels B. ExceptionLess a. Labels 28. Bigarray A. Array1 B. Array2 a. Array3 29. Dllist 30. Dynarray 31. Enum A. ExceptionLess a. Labels 32. Global 33. Hashtbl A. Make I. ExceptionLess i. Labels = IV. Persistent containers == 34. Lazy 35. List A. ExceptionLess B. Labels 36. Map A. Make I. ExceptionLess II. Labels 37. Option A. Labels 38. PMap 39. PSet 40. RefList A. Index 41. Queue 42. Ref 43. Set A. Make I. ExceptionLess II. Labels 44. Stack 45. Stream = V. Data = 46. Unit V.1. Logical 47. Bool 48. BitSet V.2. Numeric 49. Numeric (Interfaces for number-related stuff) 50. Big_int 51. Common 52. Complex 53. Float 54. Int 55. Int32 56. Int64 57. Native_int 58. Num 59. Safe_float (placeholder) 60. Safe_int V.3 Textual data 61. Text (Definition of text-related interfaces) 62. Buffer 63. Char 64. UTF8 65. Rope 66. UChar 67. String 68. StringText (A module containing aliases to String and modified Char) 69. RopeText (As StringText but with implementations from Rope and UChar 70. UTF8Text (As StringText but with implementations from UTF8 and) UChar A. Labels = V. Distribution-related stuff = 71. Packages 72. Compilers = VI. Internals = 73. Gc 74. Modules 75. Oo A. Private 76. Weak A. Make = VIII. Network (placeholders) = 77. URL 78. Netencoding A. Base64 B. QuotedPrintable a. Q b. URL A. Html VIII.1. Http 79. Http 80. Http_client 81. Cgi_* 82. Httpd_* 83. MIME VIII.2. Ftp 84. Ftp_client VIII.3. Mail 85. Netmail 86. Pop 87.
Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Le 20 nov. 08 à 22:12, David Teller a écrit : If anyone is willing to work on a solution for linking documentation from third-party libraries into one transparent source, as suggested by Richard Jones, please contact me. I'm not sure I understand what you want to acheive. If it is only a documentation issue cannot that be done with ocamldoc's -dump and - load ? Batteries (pack) 1. Standard (automatically opened) Is this Pervasives ? If it is I think the latter name is more descriptive. 13. Threads (A module containing aliases to Condition, Event...) 19. CoThreads (as Threads but with implementations coming from coThreads) If Threads and CoThreads are really semantically compatible I think that your idea of only having everything in Threads and CoThread is better and sufficient (i.e. top-level Condition, CoCondition, etc. should be dropped). Advise the users to open Threads/Cothreads to use the modules (or functorize their code on Concurrency). This allows to quickly switch from one implementation to the other by changing the toplevel open directive. With the current proposal users may be tempted to use Condition directly, and what happens if some have used Condition and others CoCondition in their modules and we suddenly try to use them toghether ? While I personally find this solution a little clumsier than the previous hierarchy, ymmv. Of course when you look it as a long list it does, but that's a presentation issue. This proposal is much more convenient to use in your code and that's what eventually matters (at least to me). Thanks for the new proposal. 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, Nov 18, 2008 at 12:32:31PM +, Richard Jones wrote: On Tue, Nov 18, 2008 at 01:15:39PM +0100, David Teller wrote: Do you see any better way of managing the complexity of all this? I'm still not getting where the benefit of having this hierarchy is, except that it adds a Java-like complexity and will create hard-to-manage churn if a module ever moves. Regarding the advantages see my previous post, where I put some motivations. Regarding the difficulties of moving modules around, how harder is than moving a module around when you have no hierarchy? -- 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, Nov 18, 2008 at 09:50:14PM +, Richard Jones wrote: If there is nothing in the Net module (and ignoring the linking issue) you can actually achieve that by using -pack. Just redo the pack on the client whenever it installs a new package in the namespace. No ? No because Net isn't necessarily an empty module, nor does it magically pull in all the modules underneath it (which would be impossible because the Net::* space is constantly changing). Still, the idea of doing the pack on the client-side is an interesting one. That way users can install libraries with some kind of metadata (maybe incorporated in META files) which tell where do they fit into the hierarchy, and the hierarchy is re-assembled for the client. BUT that would horribly break down with checksum assumptions, I believe. -- 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Yes, but that's not a good reason to give up hierarchies completely. The advantage of hierarchies is to have less top-level roots, which reduce the likelihood of clashes with external libraries. I think that the name clash problem is overblown. Really. Would it arise concretly I prefer developer cooperation rather than have the problem solved beforehand by forcing a bureaucracy on me (and even the hierarchy cannot prevent the problem completely). Besides in batteries the maintainers control everything that is below the Batteries module so it is their duty to avoid clashes in their name space and would a clash with an external library B occur I can use Batteries.B to refer to the battery one. Someone mentionned python's library, if it corresponds to this [1], then I see no hierarchy there (OTOH nobody tells me that python users are actually screaming for a hierarchy on their list). Best, Daniel [1] http://docs.python.org/library/ ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Someone mentionned python's library, if it corresponds to this [1], then I see no hierarchy there (OTOH nobody tells me that python users are actually screaming for a hierarchy on their list). The Python library hierarchy is very flat, for example all markup tools are presented into a tree of packages [1] for user convenience. Nobody actually complains about this situation. [1] http://docs.python.org/library/markup.html -- Paolo ~ ~ :wq ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Wed, Nov 19, 2008 at 02:38:05PM +0100, Stefano Zacchiroli wrote: On Tue, Nov 18, 2008 at 12:32:31PM +, Richard Jones wrote: On Tue, Nov 18, 2008 at 01:15:39PM +0100, David Teller wrote: Do you see any better way of managing the complexity of all this? I'm still not getting where the benefit of having this hierarchy is, except that it adds a Java-like complexity and will create hard-to-manage churn if a module ever moves. Regarding the advantages see my previous post, where I put some motivations. Regarding the difficulties of moving modules around, how harder is than moving a module around when you have no hierarchy? Well I guess what I _meant_ to say was that if your modules aren't in a hierarchy to start with, then you won't be tempted to move them around the hierarchy :-) 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Stefano Zacchiroli wrote: Still, the idea of doing the pack on the client-side is an interesting one. [...] BUT that would horribly break down with checksum assumptions, I believe. It would also mean someone's executables (contents and size) will depend on the libraries installed during the compilation, which is even worse. -- Stéphane ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended by
external packages. If you use an underscore then an external package
can extend the namespace (eg. by providing System_Newpackage)
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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
This raises two questions:
1) how important is it to allow third-party modules to extend the
namespace?
2) how important is it to offer a uniform package structure (where
levels are always separated by '.' rather than some level by '.' and
some by '_')?
For the moment, we have considered point 1 not very important and point
2 a little more. There are several reasons to disregard point 1. Among
these, clarity of origin (as in is this module endorsed by Batteries or
not?) and documentation issues (as in gosh, this module pretends to be
part of [Data] but I can't find the documentation anywhere in the
documentation of Batteries, wtf?).
Do you believe that we should have chosen otherwise?
Cheers,
David
On Tue, 2008-11-18 at 10:06 +, Richard Jones wrote:
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended by
external packages. If you use an underscore then an external package
can extend the namespace (eg. by providing System_Newpackage)
Rich.
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings
liquidations.
___
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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Le 18 nov. 08 à 11:29, Erkki Seppala a écrit : For example I prefer using the least amount of opening of modules, to make it easier to see where the values come from Same here. This is why I'm a little bit sceptical about this hierarchy. With the current standard library if I suddenly want to use Int32.of_int, I know I just need to type Int32.of_int in my source. With your proposal I need to remember that it is in Data.Numeric and go at the beginning of my file to open it or write Data.Numeric.Int32.of_int, to me this brings bureaucracy without any benefit. And lack of bureaucracy is one of the reasons I like ocaml (and dislike java for example). Besides Hierarchies are anyway limited in their descriptive power and one day you'll find something that will fit in two places, Rope is already an example being both Data.Persistent and Data.Text. Thus my proposal would be to _present_ them as a hierarchy (but even here a mean to tag/browse the modules with/by keywords would do a better job) but keep the actual module structure of Batteries as flat as possible, everything just under the toplevel Batteries. When I code I really don't want to have to think about all these open directives that essentially bring nothing. 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote: Besides Hierarchies are anyway limited in their descriptive power and one day you'll find something that will fit in two places, Rope is already an example being both Data.Persistent and Data.Text. That's correct, there are plenty of modules which could fit in different places. For the moment, we decided that every module should appear only in one place. However, we could easily change this -- in fact, to allow this, we only need to alter our documentation generator. Thus my proposal would be to _present_ them as a hierarchy (but even here a mean to tag/browse the modules with/by keywords would do a better job) but keep the actual module structure of Batteries as flat as possible, everything just under the toplevel Batteries. When I code I really don't want to have to think about all these open directives that essentially bring nothing. Browsing by keywords sounds like an interesting idea. I'm adding this to our TODO list. Of course, the next step will be to actually add these keywords and that's going to be much longer if we intend to tag all values. However, we disagree on the necessity of a hierarchy. There are two good reasons why the base library of OCaml doesn't have a hierarchy (almost): it's small and there are almost no redundancies between modules. Neither is true for Batteries. For an example of this redundancy, consider threads. For the moment, we have five thread-related modules: [Threads], [Mutex], [RMutex], [Condition] and [Event]. These modules, which are essentially the same modules as those of the base library, are all submodules of [Control.Concurrency.Threads]. Now, I personally like [Control.Concurrency] but I agree that this is debatable. The reason why we group these modules into [Threads] is because sooner or later, we are going to have four or five other thread-related modules called [Threads], [Mutex], [Condition], [Event] and perhaps [RMutex]. These modules will get into [Control.Concurrency.CoThreads]. They won't replace the first batch, they will exist side-by-side. Of course, we could trim the hierarchy and remove [Control.Concurrency] -- trimming the hierarchy is the main reason for launching this thread, incidentally. But, to keep things ordered, we will still need modules [Threads.Threads], [Threads.Mutex], [Threads.RMutex]... [CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a hierarchy already. coThreads is not an exceptional case, mind you. We may end up with two definitions of [Graphics], several data structures with the same name but different purposes, etc. There's also the issue of labels and other partial redefinitions of modules. The OCaml base library defines [Array]/[ArrayLabels], [List]/[ListLabels], [Map]/[MoreLabels.MapLabels] etc. In Batteries Included, we define [Array], [Array.Labels], [List], [List.Labels], which clutters less the list of modules and makes for something more consistent, especially since [FooLabel] is not the only kind of module [Foo] with a variant: we also have [Array.ExceptionLess], for operations without exceptions, and [Array.Cap] for read-only/write-only arrays. Other variants may still appear. Do you see any better way of managing the complexity of all this? Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, Nov 18, 2008 at 01:15:39PM +0100, David Teller wrote: Do you see any better way of managing the complexity of all this? I'm still not getting where the benefit of having this hierarchy is, except that it adds a Java-like complexity and will create hard-to-manage churn if a module ever moves. API changes are handled really badly in OCaml, ironically because of the lack of a textual preprocessor. You can't just write this every time lablgtk / calendar / latest culprit decides to change their API: #ifdef LABLGTK 210 let icon = GMisc.image () in icon#set_stock icon_type ~size:size; icon #else let icon = GMisc.image () in icon#set_stock `DIALOG_ERROR; icon#set_icon_size `DIALOG; icon #endif (Well, you can run -pp cpp, but that breaks other stuff) 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote: Le 18 nov. 08 à 11:29, Erkki Seppala a écrit : For example I prefer using the least amount of opening of modules, to make it easier to see where the values come from Same here. This is why I'm a little bit sceptical about this hierarchy. With the current standard library if I suddenly want to use Int32.of_int, I know I just need to type Int32.of_int in my source. With your proposal I need to remember that it is in Data.Numeric and go at the beginning of my file to open it or write Data.Numeric.Int32.of_int, to me this brings bureaucracy without any benefit. And lack of bureaucracy is one of the reasons I like ocaml (and dislike java for example). I forgot to answer that part. In Batteries, for the moment, we decided to keep the module names of the base library as shortcuts to our new modules. Consequently, you can still write your [Int32.of_int] in addition to our new [Int32.print], etc. The old modules are still available as submodules of [Legacy], if needed. Should you wish to flatten the complete hierarchy, assuming that it's possible and that there are no collisions on names, that's also something which you can do quite easily. We even provide some syntactic sugar for this. It's just the matter of writing a file my_batteries.ml along the lines of module Array= Data.Mutable.Array module List = Data.Persistent.List ... module PosixThreads = Control.Concurrency.Threads.Threads module PosixMutex = Control.Concurrency.Threads.Mutex module CoThreads= Control.Concurrency.CoThreads.Threads ... module ArrayExn = Data.Mutable.Array include ExceptionLess (*syntactic sugar*) module ArrayLabels= Data.Mutable.Array include Labels module ArrayCapExn= Data.Mutable.Array.Cap include ExceptionLess module ArrayCapLabels= Data.Mutable.Array.Cap include Labels ... I personally don't like name [ArrayCapLabels] but I can't think of any better name to represent this once we have removed any hierarchy. I personally prefer the hierarchy but, once again, the majority may disagree. So if you believe this is better, the next logical step would be to design a full and consistent list of modules including all the modules which already appear in the current version of Batteries, and with some space left for OCamlnet, OCamlnae, Reins, Camomile, ULex, Camlp4, CoThreads and a few others. I truly mean it, if you can provide us with something you consider more comfortable and as future-proof, we may adopt it. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Ok, that's an interesting point. Now, we just need to all agree on one standard :) On Tue, 2008-11-18 at 12:28 +, Benedikt Grundmann wrote: Do you see any better way of managing the complexity of all this? Yes don't introduce it at all, make a decision to use or not use labels and stick with it. Similarly make a decision to use or not use exceptions as the default, suffix / rename alternative functions as appropriate (consistently). Consistency is a big win. Not only as it speeds you up when you read/modify other people's code it also reduces the amount of decisions you have to do when writing new code. http://ocaml.janestreet.com/?q=node/28 Cheers, Bene -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 12:32 +, Richard Jones wrote: API changes are handled really badly in OCaml, ironically because of the lack of a textual preprocessor. You can't just write this every time lablgtk / calendar / latest culprit decides to change their API: #ifdef LABLGTK 210 let icon = GMisc.image () in icon#set_stock icon_type ~size:size; icon #else let icon = GMisc.image () in icon#set_stock `DIALOG_ERROR; icon#set_icon_size `DIALOG; icon #endif Side-note: That's certainly something we could add to Batteries, if needed. Camlp4 is pretty-much necessary to use Batteries anyway and Camlp4 already defines IFDEF, INCLUDE, etc. We would just need to complete that DSL perhaps to accept any valid OCaml expression and call the ocaml interpreter to evaluate these expressions. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Le 18 nov. 08 à 13:15, David Teller a écrit : But, to keep things ordered, we will still need modules [Threads.Threads], [Threads.Mutex], [Threads.RMutex]... [CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a hierarchy already. If you include in batteries an external package that has its own hierarchy and is designed to be opened I don't mind having that hierarchy. In that case you can just add the new toplevel entry CoThread. And if I want to use CoThread, I just open CoThreads, not Control.Concurrency.CoThreads. Just try to keep it as flat as possible, don't try to force modules in an ad-hoc hierarchical taxonomy to try to sort out modules. I don't care if the toplevel list of modules is three hundred pages long if there is an efficient mean to access their documentation (like tags). I do however care a lot if it becomes bureaucratic to be able to _use_ a module in my code. Le 18 nov. 08 à 13:22, Richard Jones a écrit : Easy - look at CPAN[1]. If you want to scale a project you have to make decisions that allow a distributed network of people to cooperate, without needing too much central coordination. But (unfortunately, sorry to repeat that) Batteries is not a CPAN like initiative. It aims at giving a library of modules/syntax extensions selected by the library maintainers, as such it is inherently centralized and I don't think that questions (1) or (2) are actually pertinent for the project. 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Hi, I personally prefer the hierarchy but, once again, the majority may disagree. So if you believe this is better, the next logical step would be to design a full and consistent list of modules including all the modules which already appear in the current version of Batteries, and with some space left for OCamlnet, OCamlnae, Reins, Camomile, ULex, Camlp4, CoThreads and a few others. I truly mean it, if you can provide us with something you consider more comfortable and as future-proof, we may adopt it. Paraphrasing Einstein, I think the hierarchy should be as flat as possible, but no flatter. For example, I see no reason to materialise in the hierarchy the separation between persistent and mutable data structures. The should be a documentation issue. However, and as you noted, there are cases where some hierarchisation may remove namespace clutter and allow for better code reuse. Cheers, Dario Teixeira ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 05:31 -0800, Dario Teixeira wrote: Paraphrasing Einstein, I think the hierarchy should be as flat as possible, but no flatter. For example, I see no reason to materialise in the hierarchy the separation between persistent and mutable data structures. The should be a documentation issue. However, and as you noted, there are cases where some hierarchisation may remove namespace clutter and allow for better code reuse. Duly noted. As you may see on our candidate replacement hierarchy, we intend to merge Data.Persistent and Data.Mutable into Data.Containers. Whether we flatten further remains open to debate. Thanks, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, Nov 18, 2008 at 03:23:33PM +0100, David Teller wrote: On Tue, 2008-11-18 at 05:31 -0800, Dario Teixeira wrote: Paraphrasing Einstein, I think the hierarchy should be as flat as possible, but no flatter. For example, I see no reason to materialise in the hierarchy the separation between persistent and mutable data structures. The should be a documentation issue. However, and as you noted, there are cases where some hierarchisation may remove namespace clutter and allow for better code reuse. Duly noted. As you may see on our candidate replacement hierarchy, we intend to merge Data.Persistent and Data.Mutable into Data.Containers. More generally, I would like to advertise a bit more the proposed *replacement* hierarchy reported at the bottom of David's blog post [1]; do a text search for One possible replacement and start reading from there. Several problems with the current hierarchy which have been pointed out in this thread were notice by ourselves as well, and are already, at least partly, solved by the proposed new hierarchy. Cheers. [1] http://dutherenverseauborddelatable.wordpress.com/2008/11/18/batteries-hierarchy/ -- 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 14:24 +0100, Daniel Bünzli wrote: Le 18 nov. 08 à 13:15, David Teller a écrit : But, to keep things ordered, we will still need modules [Threads.Threads], [Threads.Mutex], [Threads.RMutex]... [CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a hierarchy already. If you include in batteries an external package that has its own hierarchy and is designed to be opened I don't mind having that hierarchy. In that case you can just add the new toplevel entry CoThread. And if I want to use CoThread, I just open CoThreads, not Control.Concurrency.CoThreads. Just try to keep it as flat as possible, don't try to force modules in an ad-hoc hierarchical taxonomy to try to sort out modules. I don't care if the toplevel list of modules is three hundred pages long if there is an efficient mean to access their documentation (like tags). I do however care a lot if it becomes bureaucratic to be able to _use_ a module in my code. I concur that tags make a considerable difference. But let us return to threads for one second. There is a very good reason to have two distinct modules [Threads] and [CoThreads] with 4-5 submodules each: functors. Assuming [Threads] and [CoThreads] implement the same interface -- which they do -- I can write a module which takes as argument either [Threads], [CoThreads] or [WhateverThreads] and produces a pseudo-concurrent/truly concurrent/whatever implementation of an algorithm. The same thing could apply to latin-1 strings vs. Unicode strings (this is essentially what happens in Camomile). Now, there are certainly several possibilities. Here's one which doesn't involve a deep hierarchy: * [Thread], [Mutex], [Concurrent], [Event] remain top-level modules * [Threads] is also a top-level module, which contains aliases to [Thread], [Mutex], [Concurrent], [Event] * [CoThreads] is also a top-level module, which contains its own implementations of [Thread], [Mutex], [Concurrent], [Event] We could do the same for strings * [String], [Char], [Rope], [UChar] remain top-level modules * we introduce a new module [Strings] containing [String] and [Char] * we introduce another new module [UStrings] containing an alias [String] to [Rope] and an alias [Char] to [UChar] And for numbers * [Float], [Int], [SafeInt], [BigInt] and hypothetical [SafeFloat] and [BigFloat] (don't ask me what a BigFloat is supposed to be) remain top-level modules * we introduce a new module [Numeric] containing [Float] and [Int] * we introduce a new module [SafeNumeric] containing [SafeFloat] aliased as [Float], [SafeInt] aliased as [Int] * we introduce a new module [BigNumeric] containing [BigFloat] aliased as [Float], [BigInt] aliased as [Int] etc. To me, this seems like the only way to combine no hierarchy and modularity. However, I have the nasty feeling that this is going to end up messy, cluttered and otherwise both unmaintainable and unusable (despite tags). Le 18 nov. 08 à 13:22, Richard Jones a écrit : Easy - look at CPAN[1]. If you want to scale a project you have to make decisions that allow a distributed network of people to cooperate, without needing too much central coordination. But (unfortunately, sorry to repeat that) Batteries is not a CPAN like initiative. It aims at giving a library of modules/syntax extensions selected by the library maintainers, as such it is inherently centralized and I don't think that questions (1) or (2) are actually pertinent for the project. No, we're not CPAN. If someone wishes to build a CPAN, please feel free to do it. That may actually be easier to do once Batteries 1.0 has landed. However, Richard's remark remains interesting. So perhaps redesigning Batteries to have an open namespace structure is a good idea. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, Nov 18, 2008 at 01:49:09PM +0100, David Teller wrote: P.S.: I've pointedly ignored your perch on POD :) In my mind, that's a very different topic. For the moment, we'll stick with ocamldoc. I've used POD selectively even in OCaml projects, mainly because it is by far the easiest way to generate man pages. OCamldoc is great for developer documentation (APIs etc) but POD is super-simple for making manual pages. cf man page: http://hg.et.redhat.com/virt/applications/virt-top--devel/?f=5b38082d8aa4;file=virt-top/virt-top.pod vs ocamldoc documentation: http://hg.et.redhat.com/virt/applications/ocaml-libvirt--devel/?f=893899664388;file=libvirt/libvirt.mli One place where POD really stands out, and could be replicated by camlp4, is for standalone programs that combine argument parsing, usage and man page all in one place. In many cases you can keep the option parsing, implementation of the option, and documentation for the option right next to each other. http://perldoc.perl.org/Getopt/Long.html#Documentation-and-help-texts 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tuesday 18 November 2008 10:06:25 Richard Jones wrote:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended by
external packages. If you use an underscore then an external package
can extend the namespace (eg. by providing System_Newpackage)
I don't follow. Can you not use include to extend an existing module:
# module Array = struct
include Array
let empty = [||]
end;;
module Array :
sig
external length : 'a array - int = %array_length
...
val empty : 'a array
end
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Excerpts from Jon Harrop's message of Tue Nov 18 19:17:23 +0100 2008:
On Tuesday 18 November 2008 10:06:25 Richard Jones wrote:
On Tue, Nov 18, 2008 at 10:56:18AM +0100, David Teller wrote:
open System.IO;;
open System.File;;
Your biggest problem is using dot ('.') instead of underscore ('_').
Using a dot means that the System namespace cannot be extended by
external packages. If you use an underscore then an external package
can extend the namespace (eg. by providing System_Newpackage)
I don't follow. Can you not use include to extend an existing module:
# module Array = struct
include Array
let empty = [||]
end;;
module Array :
sig
external length : 'a array - int = %array_length
...
val empty : 'a array
end
Yes but that's the same than saying you can change a value:
let x = 42
let x = x + 1
So you make a new module but don't extend it.
--
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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, Nov 18, 2008 at 06:17:23PM +, Jon Harrop wrote: I don't follow. Can you not use include to extend an existing module: # module Array = struct include Array You're missing the point which is scalability - how to deal with distributed parties who are loosely coordinated. The above scheme allows one person to extend the Array module, but not two people, unless they coordinate with each other about which order they extend it (or both have incompatible extensions). 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tuesday 18 November 2008 18:59:14 Richard Jones wrote: On Tue, Nov 18, 2008 at 06:17:23PM +, Jon Harrop wrote: I don't follow. Can you not use include to extend an existing module: # module Array = struct include Array You're missing the point which is scalability - how to deal with distributed parties who are loosely coordinated. The above scheme allows one person to extend the Array module, but not two people, unless they coordinate with each other about which order they extend it (or both have incompatible extensions). If the library creator did not use functors or classes to make their design reusable then the only solution for the user is to include all of the implementations they require: module Array = struct include RichardsArray include JonsArray end Given the lack of libraries available for OCaml anyway, this seems like a very minor concern to me. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, Nov 18, 2008 at 08:17:36PM +, Jon Harrop wrote: If the library creator did not use functors or classes to make their design reusable then the only solution for the user is to include all of the implementations they require: You're talking about something completely different. In Perl they have: Net Net::Amazon Net::BitTorrent Net::FTPServer (and a million others[1]) The proposal is to have a hierarchy of OCaml modules, of this sort: Net Net.Amazon Net.BitTorrent Net.FTPServer (and a million more) which doesn't scale. However, using '_' as a separator scales because distributed, loosely coordinated parties can add new modules ad hoc to such a namespace. Rich. [1] http://www.cpan.org/modules/by-module/Net/ -- 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Le 18 nov. 08 à 20:22, Richard Jones a écrit : The proposal is to have a hierarchy of OCaml modules, of this sort: Net Net.Amazon Net.BitTorrent Net.FTPServer (and a million more) which doesn't scale. If there is nothing in the Net module (and ignoring the linking issue) you can actually achieve that by using -pack. Just redo the pack on the client whenever it installs a new package in the namespace. No ? 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On 11/18/2008 7:17 PM, Jon Harrop wrote: I don't follow. Can you not use include to extend an existing module: # module Array = struct include Array let empty = [||] end;; module Array : sig external length : 'a array - int = %array_length ... val empty : 'a array end In addition to this being non-modular, this extension scheme does not work well with hiararchy as it forces you to mention all the siblings of the ancestors of the module you want to extend. E.g. if you start from: module M = struct module M1 = struct module M11 = struct ... end module M12 = struct ... end module M13 = struct ... end ... end module M2 = struct ... end module M3 = struct ... end ... end and you want to extend M11, you need to write: module M' = struct module M1 = struct module M11 = struct include M.M1.M11 (* extension here *) end module M12 = M.M1.M12 module M13 = M.M1.M13 ... end module M2 = M.M2 module M3 = M.M3 ... end Frankly, I don't think that having a nice and well-organized hierarchy of modules really matters. Things like having uniform interfaces, consistent idioms and compatible types across libraries seem much more important to me. Anyway, if a hierarchy is desired, I fail to see any advantage of using . instead of e.g. _ (easily extensible + does not force you to link everything). -- Alain ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tuesday 18 November 2008 09:56:18 David Teller wrote: Now, we've decided that our current hierarchy is perhaps somewhat clumsy and that it may benefit from some reworking. Before we proceed, we'd like some feedback from the community... I only have one major concern: you say with the large number of modules involved, we would need a hierarchy of modules but the number of modules involved is tiny (a few dozen in OCaml compared to tens or even hundreds of thousands in any industrial-strength language) because OCaml has very few libraries. Yet your module hierarchies are already enormous and often require a longer sequence of modules to reach simple functionality than is required in a comparatively-huge library like .NET. To me, the most striking example is printf which is just printf in F#, Printf.printf in OCaml and is now Text.Printf.printf in OCaml+Batteries. Surely this is a step in the wrong direction? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On 11/19/2008 12:49 AM, Jon Harrop wrote: Perhaps that could be solved with extensive Camlp4 hacking to rename the previous modules (even coming from an include) to avoid the clash? I don't think so. It seems you need type information. That brings its own problems, of course. You no longer have a real hierarchy so you cannot do anything at a given depth in the hierarchy, e.g. apply mid-level module to a functor. Jon, come on. Is it a joke or do you seriously think that not being able to apply a functor to a subtree of the hierarchy matters in any way in this context? -- Alain ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tuesday 18 November 2008 22:07:33 Alain Frisch wrote: and you want to extend M11, you need to write: module M' = struct module M1 = struct module M11 = struct include M.M1.M11 (* extension here *) end module M12 = M.M1.M12 module M13 = M.M1.M13 ... end module M2 = M.M2 module M3 = M.M3 ... end Ah, yes. Otherwise you get Multiple definition of the module name Perhaps that could be solved with extensive Camlp4 hacking to rename the previous modules (even coming from an include) to avoid the clash? Frankly, I don't think that having a nice and well-organized hierarchy of modules really matters. Things like having uniform interfaces, consistent idioms and compatible types across libraries seem much more important to me. Indeed. I think the current system would withstand an order of magnitude more (popular) libraries. I'd also recommend the SML Basis library and F# for inspiration: they both contain some great designs. Anyway, if a hierarchy is desired, I fail to see any advantage of using . instead of e.g. _ (easily extensible + does not force you to link everything). That brings its own problems, of course. You no longer have a real hierarchy so you cannot do anything at a given depth in the hierarchy, e.g. apply mid-level module to a functor. No doubt people will want both so we'll end up with an ad-hox mix of . and _ separators. In that case, I'd prefer to flatten every _ (assuming names didn't clash). -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 23:30 +, Jon Harrop wrote: On Tuesday 18 November 2008 09:56:18 David Teller wrote: I only have one major concern: you say with the large number of modules involved, we would need a hierarchy of modules but the number of modules involved is tiny (a few dozen in OCaml compared to tens or even hundreds of thousands in any industrial-strength language) because OCaml has very few libraries. Yet your module hierarchies are already enormous and often require a longer sequence of modules to reach simple functionality than is required in a comparatively-huge library like .NET. Well, we're trying to be future-proof. Don't you think we should? To me, the most striking example is printf which is just printf in F#, Printf.printf in OCaml and is now Text.Printf.printf in OCaml+Batteries. Surely this is a step in the wrong direction? Well, if you it's just the matter of [printf], we can add it to [Batteries.Standard] to import it in the standard namespace. The biggest question is how many things we want imported in that standard namespace. Or you could start your files with [open Text.Printf] or [module P = Text.Printf] or any similar combination. Oh, and, [Printf.printf] works, too. This is one of the modules which have a shortcut to their path in the hierarchy, to mirror the base library. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Wednesday 19 November 2008 06:29:52 David Teller wrote: On Tue, 2008-11-18 at 23:30 +, Jon Harrop wrote: I only have one major concern: you say with the large number of modules involved, we would need a hierarchy of modules but the number of modules involved is tiny (a few dozen in OCaml compared to tens or even hundreds of thousands in any industrial-strength language) because OCaml has very few libraries. Yet your module hierarchies are already enormous and often require a longer sequence of modules to reach simple functionality than is required in a comparatively-huge library like .NET. Well, we're trying to be future-proof. Sure. Don't you think we should? No. :-) I think it is extremely unlikely that OCaml will get many more libraries so I do not think it is worth spending much time designing infrastructure to cope with that eventuality. To me, the most striking example is printf which is just printf in F#, Printf.printf in OCaml and is now Text.Printf.printf in OCaml+Batteries. Surely this is a step in the wrong direction? Well, if you it's just the matter of [printf], we can add it to [Batteries.Standard] to import it in the standard namespace. The biggest question is how many things we want imported in that standard namespace. Or you could start your files with [open Text.Printf] or [module P = Text.Printf] or any similar combination. You could but it will still deter newbies: open Text.Printf printf Hello world!\n etc. Oh, and, [Printf.printf] works, too. This is one of the modules which have a shortcut to their path in the hierarchy, to mirror the base library. Sure. I would certainly vote for flattening out the hierarchy as much as possible though. For example, I would keep containers in List, Array etc. and not nest them in Data or Containers or Collections. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ 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
