caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: oliver <oliver@first.in-berlin.de>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: Gabriel Scherer <gabriel.scherer@gmail.com>,
	Edgar Friendly <thelema314@gmail.com>,
	caml-list@inria.fr
Subject: Re: more ideas (Re: [Caml-list] how could the community help with Oasis-DB;) towards a CPAN for OCaml?
Date: Fri, 16 Dec 2011 03:17:15 +0100	[thread overview]
Message-ID: <20111216021715.GA2066@siouxsie> (raw)
In-Reply-To: <1323877046.7750.42.camel@samsung>

On Wed, Dec 14, 2011 at 04:37:26PM +0100, Gerd Stolpmann wrote:
> Am Mittwoch, den 14.12.2011, 15:55 +0100 schrieb oliver:
> > On Wed, Dec 14, 2011 at 01:14:57PM +0100, Gerd Stolpmann wrote:
> > > Am Dienstag, den 13.12.2011, 21:22 +0100 schrieb oliver:
> > > > Hello,
> > > > 
> > > > 
> > > > I again want to mention R.
> > > > 
> > > > The installation procdure for users is very easy.
> > > > What I also like there, is that the documentation
> > > > includes references to books, which explain the algorithms
> > > > or other background information.
> > > > Maybe thats too much of what is needed for OCaml.
> > > > 
> > > > But it's what I do like there.
> > > > 
> > > > Also R-packages necessarily need to be documented,
> > > > have a manpage / package description.
> > > > 
> > > > Not sure if this is necessary with OCaml stuff,
> > > > because *.mli files are there, and ocamlc -i could
> > > > print the interfaces of the modules, if nothing else is there
> > > > to rely on.
> > > > But maybe these kinds of minimalistic documentation-generation
> > > > could be created automatically by the installing tools.
> > > > 
> > > > Nicely printed html-docs for interfaces are very helpful.
> > > > 
> > > > And also nice would be, to have such nicely printed documentation
> > > > also available at the server, even before downloading any packages.
> > > > So, browsing a package documentation online could be done
> > > > before downloading the package.
> > > 
> > > docs.camlcity.org
> > [...]
> > 
> > Yes, I see.
> > There are these nice htmlized-docs.
> > 
> > But I meant that this kind of docs also should also be on
> > a CPAN-like server for OCaml.
> > So every package that is available there should also be
> > documented in this way.
> 
> Yes, it's a third party server. What's the problem?
[...]

if it offers a shell and the possibility to install OCaml
(or maybe the admin could od that), then there is no problem.

ocamlc -i   and  caml2html  can be used then to create the docs
automotically.


> 
> My thinking here is different: We should lower the barriers for packages
> as far as possible. We are not in the position of CPAN who can reject
> packages not conforming to a relatively high standard.

People who are able to program in OCaml also might be able to
add some additional simple textfiles for further informations,
if necessary. Some more docs would be fine.
But maybe that not even is necessary for a minmal set of docs.

The creation of the interface docs can be done as mentioned above.
Additionally there was a module (forgot the name, but could look for it),
which also displays the hierrchy of modules (which module uses which other modules).

All this could be deon automatically, if the server at least offers a shell
and OCaml.

Unpacking an archive, applying ocamlc and caml2html could be done automatically.

And if one looks at CTAN, there are some additional simple text files (package descriptions)
which help organizing this.

I think overengineering is not a good idea, but a minimal helping text file should be
possible for people who claim to program in OCaml.

For example there was/is the Linux Software Map; it's already forgotten by most
people, but once was a very useful tool... it doies exist today, but maybe not very
frequently used.
But there it was a simple text file with some informations about the software,
that was added and had a very simple format.
It was parsed automatically and created the data dfor the search catalog.

Thats btw. a lot less effort than clikcing around in so many menues
in the modern web driven software hosting possibilities.

I think it should be possible to add such a simple textfile.

If that is too much for OCaml programmrs, I doubt that any person ever will want
to use the software that will be hosted there.

I think there are enough very knowledgable people hacking in OCaml.

So this little barrier should be able to cross.




> 
> docs.camlcity.org does the best in this situation: If there is a manual,
> you can look at this. But if not, there is at least a pretty-printed
> interface, and you can search these interfaces.

That's what I meant.
Is this doc generated automatically?

That's what I was looking for.

And the module-hierarchy of a program could also be added.

But the people who upload their stuff should be encouraged to add documentation.
Maybe some tools could help there.

I like it that C-extensions to R necessarily need a documentation file.
I would not insist on such a thing for OCaml, but if you look at what
the result is, when looking at R-package documentation, this is convincing.
It uses - like classical unix manpages - certain topics, which will be checked
if they are used.

If OCaml stands for quality, why not insisting at least on  a minimal
kind of documentation?

Ciao,
   Oliver

  reply	other threads:[~2011-12-16  2:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-10 21:44 [Caml-list] how could the community help with Oasis-DB; " Gabriel Scherer
2011-12-10 22:34 ` [Caml-list] " Edgar Friendly
2011-12-13 20:22 ` more ideas (Re: [Caml-list] how could the community help with Oasis-DB;) " oliver
2011-12-14 12:14   ` Gerd Stolpmann
2011-12-14 14:55     ` oliver
2011-12-14 15:37       ` Gerd Stolpmann
2011-12-16  2:17         ` oliver [this message]
2011-12-17 13:58 ` [Caml-list] Re: how could the community help with Oasis-DB; " Sylvain Le Gall
2011-12-17 21:50   ` Andrej Bauer
2011-12-17 23:27     ` Daniel Bünzli
2011-12-18  1:38       ` Edgar Friendly
2011-12-18  9:35     ` Benedikt Meurer
2011-12-18 19:46       ` Ashish Agarwal
2011-12-18 20:01         ` Benedikt Meurer
2011-12-18 20:12           ` Anil Madhavapeddy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111216021715.GA2066@siouxsie \
    --to=oliver@first.in-berlin.de \
    --cc=caml-list@inria.fr \
    --cc=gabriel.scherer@gmail.com \
    --cc=info@gerd-stolpmann.de \
    --cc=thelema314@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).