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
