[Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Richard Jones]

I wonder if anyone is interested (or opposed) to creating a true
parallel with CPAN for OCaml code?

Going beyond the Caml Humps this would provide a central place for
storing and downloading Caml libraries, and a place to register
library names, provide search and so on.

Comments?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Erik Arneson]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

On Tue, Jul 15, 2003 at 07:09:53PM +0100, Richard Jones wrote:
> I wonder if anyone is interested (or opposed) to creating a true
> parallel with CPAN for OCaml code?
> 
> Going beyond the Caml Humps this would provide a central place for
> storing and downloading Caml libraries, and a place to register
> library names, provide search and so on.
> 
> Comments?

At OSCon this year, somebody was talking about the FreePAN project.  It
might be worth looking into:

                       <http://www.freepan.org/>

-- 
;; Erik Arneson <erik@aarg.net>    AARG Net <http://www.aarg.net/> ;;
;; GPG Key ID: 2048R/8B4CBC9C           <http://erik.arneson.org/> ;;
;; "Civilization is only savagery silver-gilt." - H. Rider Haggard ;;


[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]

RE: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[BdB]

Definitely relevant idea. Cf.
http://caml.inria.fr/archives/200303/msg00422.html ("Our shrinking humps").
I've just actually discovered this article on the list, where my library for
I/O of PNM files is cited. This library disappeared from the Internet the
day I graduated. An archive would be all the more relevant as I don't think
I'm the only
student-turned-professional-maker-of-animated-PowerPoint-slideshows who
unfortunately doesn't have too much time to spend on programming and
supporting open source packages anymore.

As of now, I don't have the resource to host a page with this library which
is very small, very easy to write but also very, very boring to make.
Typically the thing you wish someone had done before you. Sure enough, I
ould probably set up a page on some free provider in one afternoon. But
since I can't commit to any resource beyond one week for dealing with
problems, I think it would be stupid to start putting it back online when I
don't have a plan for maintenance.

By the way, if anyone wants to maintain this PNM io library, I can probably
fish it out from my old back-ups. Also, if anyone wants to maintain a funny
camlp4 "french" binding where the keywords and syntax are changed to match
French keywords and syntax instead of English... it used to be on my
webpage.

Best regards,
Benoit.


-----Message d'origine-----
De : owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr]De la part de Richard Jones
Envoye : mardi 15 juillet 2003 20:10
A : caml-list@inria.fr
Objet : [Caml-list] CTAN/CPAN for Caml (COCAN ...?)


I wonder if anyone is interested (or opposed) to creating a true
parallel with CPAN for OCaml code?

Going beyond the Caml Humps this would provide a central place for
storing and downloading Caml libraries, and a place to register
library names, provide search and so on.

Comments?

Rich.

--
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to
you.
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris.
http://www.annexia.org/freeware/makeplus/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Alexander V. Voinov]

Hi All,

BdB wrote:

> Definitely relevant idea. Cf.
> http://caml.inria.fr/archives/200303/msg00422.html ("Our shrinking humps").
> I've just actually discovered this article on the list, where my library for
> I/O of PNM files is cited. This library disappeared from the Internet the
> day I graduated. An archive would be all the more relevant as I don't think
> I'm the only
> student-turned-professional-maker-of-animated-PowerPoint-slideshows who
> unfortunately doesn't have too much time to spend on programming and
> supporting open source packages anymore.
> 
> As of now, I don't have the resource to host a page with this library which
> is very small, very easy to write but also very, very boring to make.

Actually, I also have a small contribution (a simple but useable Oracle 
interface), but I don't know where to place it. It would be an offtopic in all 
places to which I have write access :-).

WBR

Alexander



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Issac Trotts]

Why not use savana.gnu.org or ftp.gnu.org or sourceforge.net ?  Then 
you'd have the
added benefit that people who don't know about OCaml would be more 
likely to find
out about your project.  It would tend to help OCaml's popularity.

Issac

Alexander V. Voinov wrote:

> Hi All,
>
> BdB wrote:
>
>> Definitely relevant idea. Cf.
>> http://caml.inria.fr/archives/200303/msg00422.html ("Our shrinking 
>> humps").
>> I've just actually discovered this article on the list, where my 
>> library for
>> I/O of PNM files is cited. This library disappeared from the Internet 
>> the
>> day I graduated. An archive would be all the more relevant as I don't 
>> think
>> I'm the only
>> student-turned-professional-maker-of-animated-PowerPoint-slideshows who
>> unfortunately doesn't have too much time to spend on programming and
>> supporting open source packages anymore.
>>
>> As of now, I don't have the resource to host a page with this library 
>> which
>> is very small, very easy to write but also very, very boring to make.
>
>
> Actually, I also have a small contribution (a simple but useable 
> Oracle interface), but I don't know where to place it. It would be an 
> offtopic in all places to which I have write access :-).
>
> WBR
>
> Alexander
>
>
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: 
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>
>


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[BdB]

€.02 here: there's a couple of stuff that a CPAN-like website could do
  1) hosting libs
  2) cross-referencing & automatic dependency generation
  3) registry (the business of ensuring non-collision)

It seems to me that the sites you mention only provide hosting among these
three points. Which is still interesting.

I would think that coding 2) is just a matter of motivation. ocamldep and
camlp4 should help.

As for the last point... well, one possible drawback of current O'CaML is
its module namespace. My fear is that module names are soon enough going to
look like JoesXMLParser to distinguish it from MikesXMLParser (betting on
the success of the initiative here). Well, actually there can be modules
within modules, so that's not exactly a flat module namespace. But if
someone makes a module called Joe.XMLParser, it has got to be defined in
joe.ml[i], which is in my opinion a pretty bad name to give to a file
containing an XML parser. Maybe java-like module namespace partition is
something worth considering for efficient community management?

-----Message d'origine-----
De : owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr]De la part de Issac Trotts
Envoyé : mercredi 16 juillet 2003 07:53
À : caml-list@inria.fr
Objet : Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)


Why not use savana.gnu.org or ftp.gnu.org or sourceforge.net ?  Then
you'd have the
added benefit that people who don't know about OCaml would be more
likely to find
out about your project.  It would tend to help OCaml's popularity.

Issac

Alexander V. Voinov wrote:

> Hi All,
>
> BdB wrote:
>
>> Definitely relevant idea. Cf.
>> http://caml.inria.fr/archives/200303/msg00422.html ("Our shrinking
>> humps").
>> I've just actually discovered this article on the list, where my
>> library for
>> I/O of PNM files is cited. This library disappeared from the Internet
>> the
>> day I graduated. An archive would be all the more relevant as I don't
>> think
>> I'm the only
>> student-turned-professional-maker-of-animated-PowerPoint-slideshows who
>> unfortunately doesn't have too much time to spend on programming and
>> supporting open source packages anymore.
>>
>> As of now, I don't have the resource to host a page with this library
>> which
>> is very small, very easy to write but also very, very boring to make.
>
>
> Actually, I also have a small contribution (a simple but useable
> Oracle interface), but I don't know where to place it. It would be an
> offtopic in all places to which I have write access :-).
>
> WBR
>
> Alexander
>
>
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>
>


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Florian Hars]

BdB wrote [about http://www.stud.enst.fr/~debourse/projects.html]
> This library disappeared from the Internet the
> day I graduated.

Yeah, isn't it funny that theese days the universities are among the 
worst destructors of public culture and knowledge?

Yours, Florian Hars.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Wolfgang Müller]

On Wednesday 16 July 2003 08:43, BdB wrote:
> €.02 here: there's a couple of stuff that a CPAN-like website could do
My $0.02 (for character table reasons ;-) )
>   1) hosting libs
>   2) cross-referencing & automatic dependency generation
>   3) registry (the business of ensuring non-collision)
>
> It seems to me that the sites you mention only provide hosting among these
> three points. Which is still interesting.

I agree completely here. I think it would be great to have some automatic 
installation or downloading facility like the CPAN module in perl. I think 
like this it would be easier to make people like me (i.e. newbies) look for 
useful stuff before starting to code, and make it easy for people to ship 
their code if it needs to be shipped. 

Personally, in my experience with CPAN IMHO what is needed most for shipping 
code is some code that generates a tarball of all the prerequisites needed 
for a given package of code, together with an idiot-proof makefile. Most 
people I work with do not like the -MCPAN (it can make problems if you're not 
root, you have to answer many questions, there are firewalls), so I cannot 
send them simple scripts that use the CPAN module for downloading the useful 
stuff, I have to do the actual tarballs myself.

> I would think that coding 2) is just a matter of motivation. ocamldep and
> camlp4 should help.

Oh, for this I am too newbyish

> As for the last point... well, one possible drawback of current O'CaML is
> its module namespace. My fear is that module names are soon enough going to
> look like JoesXMLParser to distinguish it from MikesXMLParser (betting on
> the success of the initiative here). Well, actually there can be modules
> within modules, so that's not exactly a flat module namespace. But if
> someone makes a module called Joe.XMLParser, it has got to be defined in
> joe.ml[i], which is in my opinion a pretty bad name to give to a file
> containing an XML parser. Maybe java-like module namespace partition is
> something worth considering for efficient community management?

...sounds great to a newbie like me...

Cheers,
Wolfgang

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Richard Jones]

On Wed, Jul 16, 2003 at 08:43:20AM +0200, BdB wrote:
> ?.02 here: there's a couple of stuff that a CPAN-like website could do
>   1) hosting libs
>   2) cross-referencing & automatic dependency generation
>   3) registry (the business of ensuring non-collision)

Another important point would be:

4) A standard packaging and build process.

For example, you can download any Perl package and type:

	perl Makefile.PL && make && sudo make install

You can use Perl's CPAN module to download, compile and install the
dependent packages with one command. It all works automatically
because all Perl packages follow a few fairly simple rules.

> As for the last point... well, one possible drawback of current O'CaML is
> its module namespace. My fear is that module names are soon enough going to
> look like JoesXMLParser to distinguish it from MikesXMLParser (betting on
> the success of the initiative here). Well, actually there can be modules
> within modules, so that's not exactly a flat module namespace. But if
> someone makes a module called Joe.XMLParser, it has got to be defined in
> joe.ml[i], which is in my opinion a pretty bad name to give to a file
> containing an XML parser. Maybe java-like module namespace partition is
> something worth considering for efficient community management?

I agree this is a problem, but a Java-like module namespace is about
the worst possible solution. Perl has many thousands of packages but
does not require it. Mostly this is because of an informal honour
system: no one names their package "CGI" unless it is absolutely the
best system for writing CGI scripts. Little-used or still-born
packages can also be kicked out of the archive.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Wolfgang Müller]

> I agree this is a problem, but a Java-like module namespace is about
> the worst possible solution. Perl has many thousands of packages but
> does not require it. Mostly this is because of an informal honour
> system: no one names their package "CGI" unless it is absolutely the
> best system for writing CGI scripts. Little-used or still-born
> packages can also be kicked out of the archive.

AFAIRemember, if you use a new toplevel namespace, and you want your stuff to 
be hosted at CPAN, you have to ask some CPAN mailing list, if this is OK, and 
if you're lucky in one of the first few tries, your post will spawn a 
discussion among the Gurus and yourself if this namespace is really 
necessary. Each toplevel namespace is agreed upon by the Gurus. But still, 
perl does do something similar to JAVA. A run of 

find |grep pm 

on a typical perl installation gives you something like:

...
/usr/lib/perl5/site_perl/5.6.1/i586-linux/XML/DOM/NamedNodeMap.pm
/usr/lib/perl5/site_perl/5.6.1/i586-linux/XML/DOM/DOMException.pm
/usr/lib/perl5/site_perl/5.6.1/i586-linux/XML/DOM/PerlSAX.pm
/usr/lib/perl5/site_perl/5.6.1/i586-linux/XML/DOM/NodeList.pm
/usr/lib/perl5/site_perl/5.6.1/i586-linux/XML/SAX/Base.pm
/usr/lib/perl5/site_perl/5.6.1/i586-linux/XML/SAX/ParserFactory.pm
/usr/lib/perl5/site_perl/5.6.1/i586-linux/XML/SAX/Exception.pm
/usr/lib/perl5/site_perl/5.6.1/i586-linux/XML/SAX/PurePerl.pm
...

XML::DOM::NodeList *is* found in XML/DOM/NodeList.pm, and this is what BdB 
meant, I think.

Cheers,
Wolfgang

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Florian Hars]

BdB wrote:
> Maybe java-like module namespace partition is
> something worth considering for efficient community management?

Rehashing the same discussions once a year:

http://caml.inria.fr/archives/200209/msg00307.html

There was no real conclusion the last time, though. The new option -pack 
is almost there, but not supported on all platforms.

Yours, Florian.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[John Max Skaller]

Erik Arneson wrote:

 
> At OSCon this year, somebody was talking about the FreePAN project.  It
> might be worth looking into:
> 
>                        <http://www.freepan.org/>
> 

Seem pretty broken at the moment, can't even mail
the developers to offer help :-)


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[John Max Skaller]

Richard Jones wrote:

> I wonder if anyone is interested (or opposed) to creating a true
> parallel with CPAN for OCaml code?

It is pointless to consider this UNTIL there Ocaml team
themselves decide on a packaging model.

This means some way of, for example, having
a heirarchical naming model without the top
level having to be a file containing all
the others.

It means some way of finding package and components,
and some way of installing them which doesn't require
either clobbering the main distribution or adding
a path component for every installed package.

I'm sure the team is aware of these issues, there has
been a lot of pressure to solve the problem. However thankfully
they seem not inclined to give a premature solution:
once there is a standard solution we'll all be stuck
with it for a long time.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Richard Jones]

On Fri, Jul 18, 2003 at 06:14:13PM +1000, John Max Skaller wrote:
> It is pointless to consider this UNTIL there Ocaml team
> themselves decide on a packaging model.

I agree, but is it really that hard?

There seems to be an informal standard right now. eg. camlimages which
I've been wrestling with all week:

$OCAMLLIB/camlimages/ contains the code and names top-level module
names. To compile you just use ocamlc -I +camlimages ...

> This means some way of, for example, having
> a heirarchical naming model without the top
> level having to be a file containing all
> the others.

I don't quite understand what you mean by this.

> It means some way of finding package and components,
> and some way of installing them which doesn't require
> either clobbering the main distribution or adding
> a path component for every installed package.

Or this ... When adding a package, just create a subdirectory of lib/ ?

> I'm sure the team is aware of these issues, there has
> been a lot of pressure to solve the problem. However thankfully
> they seem not inclined to give a premature solution:
> once there is a standard solution we'll all be stuck
> with it for a long time.

Indeed this is true.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
'There is a joke about American engineers and French engineers. The
American team brings a prototype to the French team. The French team's
response is: "Well, it works fine in practice; but how will it hold up
in theory?"'

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Shawn Wagner]

On Fri, Jul 18, 2003 at 06:14:13PM +1000, John Max Skaller wrote:
> Richard Jones wrote:
> 
> > I wonder if anyone is interested (or opposed) to creating a true
> > parallel with CPAN for OCaml code?
> 
> It is pointless to consider this UNTIL there Ocaml team
> themselves decide on a packaging model.

Among library writers, findlib's pretty ubiquitous. Almost everything I've
looked at either requires it or at lesat supports it via providing a META
file.

A findlib-based setup that downloads packages from a mirror, unpacks,
installs dependencies if needed, builds, and installs the package wouldn't
be too difficult to write. It'll just take someone to sit down and /do/ it.

Given a choice between having quick-and-dirty working code and code that
works the 'right' way, the latter's better, of course. But when the choice
is between working code and seeing 20 people never ever get past arguing
what the right way it should be done is (Which seems to be what happens
every time someone mentions an ocaml version of CPAN), I'll take something
that works.

-- 
Shawn Wagner
shawnw@speakeasy.org

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Stefano Zacchiroli]

On Fri, Jul 18, 2003 at 09:42:52AM +0100, Richard Jones wrote:
> There seems to be an informal standard right now. eg. camlimages which
> I've been wrestling with all week:
> 
> $OCAMLLIB/camlimages/ contains the code and names top-level module
> names. To compile you just use ocamlc -I +camlimages ...

Such a standard ensure no safety.

A naming schema should be used for all modules whose interfaces are used
in the final objects against which link to.

Camlimages itself is a good example of this property _not_ enforced
because it is named "camlimages", exports a lot of modules prefixed by
"ci_" but internally uses an "Image" module which MD5 sum is present in
all "ci_" modules.

An "image" module is shipped also by labltk which obviously, being a
different piece of software, has a different MD5 sum and can't be linked
along with camlimages.

A naming schema should be enforced not only for the toplevel library
modules, but for all modules being part of it.

Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Yamagata Yoriyuki]

From: Stefano Zacchiroli <zack@bononia.it>
Subject: Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)
Date: Fri, 18 Jul 2003 17:46:38 +0200

> Camlimages itself is a good example of this property _not_ enforced
> because it is named "camlimages", exports a lot of modules prefixed by
> "ci_" but internally uses an "Image" module which MD5 sum is present in
> all "ci_" modules.

What is the best practice to avoid such situation?  I can think of two
ways, but both are not satisfactory.

1) Obfuscate names of internal modules by hand.  I certainly do not
   want to do this.

2) Use pack option.  Until -pack generates cma files (not cmo), I am
   reluctant to employ this option.

Any other ways?

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Daniel Bünzli]

> 2) Use pack option.  Until -pack generates cma files (not cmo), I am
>    reluctant to employ this option.

The option -pack can generate cmo files.

Look there <http://caml.inria.fr/ocaml/htmlman/manual022.html>

Daniel

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Gerd Stolpmann]

Am Fre, 2003-07-18 um 16.29 schrieb Shawn Wagner:
> On Fri, Jul 18, 2003 at 06:14:13PM +1000, John Max Skaller wrote:
> > Richard Jones wrote:
> > 
> > > I wonder if anyone is interested (or opposed) to creating a true
> > > parallel with CPAN for OCaml code?
> > 
> > It is pointless to consider this UNTIL there Ocaml team
> > themselves decide on a packaging model.
> 
> Among library writers, findlib's pretty ubiquitous. Almost everything I've
> looked at either requires it or at lesat supports it via providing a META
> file.
> 
> A findlib-based setup that downloads packages from a mirror, unpacks,
> installs dependencies if needed, builds, and installs the package wouldn't
> be too difficult to write. It'll just take someone to sit down and /do/ it.

Recently I did an experiment called GODI ("Gerd's Ocaml Distribution").
The idea was to implement this kind of extended package management with
minimum effort. I call it an experiment, because the aim was not to
create a working system, but simply to find out what works and what does
not work.

At the beginning there was an analysis of the system environments. The
point is crucial for the success:

      * We have the Unix world, and we have the Windows port, both with
        totally different toolchains
      * We have Open Source systems (Linux distros, BSD distros) that
        have good library support, and we have proprietary systems that
        lack libraries (think of gtk).

Any package management system should integrate well with the operating
system it runs on. It should be possible to use the components of the
system as far as possible, and to create components of the system.
Anything else is impractical. For GODI, I have ignored the Windows
problem, but there could be a solution based on mingw (as good
compromise between "Unixfication" and system integration). So I
concentrated on the integration into Unix-style systems.

The library problem: Many Unixes do not have the C libraries we need, or
have only ancient versions. Example: Solaris has ndbm, but you usually
do not want it for new programs because of its limitations, better you
install gdbm or Berkeley DB. Other required libraries (for a useful
system) are completely missing, e.g. gtk. Further problems arise with
missing tools, e.g. gmake. Of course, this is not only an O'Caml
problem, but it is a problem of the users, and we have certainly to deal
with it.

The next point is that findlib is not enough. It cannot manage arbitrary
files, but only the linkable parts of libraries. (Don't forget that
libraries sometimes need tools (e.g. rpcgen), or data files (e.g.
message catalogs). findlib cannot manage these files.)

So we definetely need a database of installed files. Many operating
systems already have such databases (e.g. rpm is such a database), and
the question arises whether to use it for O'Caml packages or not. Pro:
better system integration, especially with the required libraries if the
system provides them. Con: The various package databases are very
different, and not every system has even one. (Note: Perl has its own
very simple file database, the .packlist files.)

For GODI, I have used one of the simplest available package databases,
the NetBSD package system. It is binary-only, records dependencies and
file checksums, and this is more or less already the end of the feature
list. It fulfils an absolute requirement: It runs everywhere because of
its simplicity.

For the finally used system, I would suggest that (1) we use our own
file database, and (2) allow it to record dependencies on the native
file database of the operating system ("foreign dependencies").

When we have a real file database, we can also provide C libraries that
are missing especially in proprietary operating systems.

This would be the "binary picture" of the package system: The packages
are the units of the file database. They can have dependencies on each
other, and they can have foreign dependencies on the system packages.
Every package that is an O'Caml library would follow findlib's
conventions.

Now the more difficult question: The build environment. For GODI, I have
used the NetBSD pkgsrc system as framework. It has the following
features:

      * The functions of the build environment are implemented with
        Makefiles (of course, the BSD "make" is used), and by including
        a Makefile of the framework into your own Makefile you can
        "load" a certain set of functions
      * Every binary package is created by the Makefile in a source
        directory. This Makefile is a "driver Makefile" that downloads
        the real source, builds it, installs it, and creates the binary
        package. The driver Makefile does usually not include the rules
        to compile the sources, it rather calls the Makefile contained
        in the sources for this purpose. 
      * The framework implements build-time dependencies and the
        automatic download of the source tar.gz.
      * There are much more functions, most of them related to building
        of C programs and libraries

The use of Makefiles for the build framework has one clear advantage:
its flexibility. More or less, the Makefiles are "action objects", and
including another Makefile is "inheritance", i.e. it is nothing but an
object-oriented build system.

The problem of the NetBSD approach is that the driver Makefiles to build
the packages are simple, unpackaged files. There are no "source
packages". If you want to update the driver Makefiles, you usually do
that by "cvs update". This is a simple solution, but there is no
guarantee that the current CVS state of the Makefiles works, especially
regarding the dependencies. One needs a release management, i.e. from
time to time the CVS depot must be stabilized.

I am not sure whether this is the right model for O'Caml packages.
First, you need people that integrate packages into the system (you need
a CVS account). Second, you need users with CVS experience. Third, it is
difficult to deviate from CVS, e.g. by installing different versions.

So far my GODI experiment. It is not yet available for download, but if
somebody is interested in it I can make a web page for it.

> Given a choice between having quick-and-dirty working code and code that
> works the 'right' way, the latter's better, of course. But when the choice
> is between working code and seeing 20 people never ever get past arguing
> what the right way it should be done is (Which seems to be what happens
> every time someone mentions an ocaml version of CPAN), I'll take something
> that works.

This is one of the reasons I actually did GODI. It is working code, and
it is now much harder to argue against its principles.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Fernando Alegre]

I use Debian and I am happy, thank you very much, but that's good enough
for me. I guess RedHat/Suse/Mandrake users think similarly, and windows
users... get what they pay for, sorry.

Packaging is off-topic. The on-topic problem is module naming. If I want
to use two packages in my program, but both have a module called Stuff,
I have a problem. Current workarounds:

1) Use -pack to wrap all package1 modules under Package1, and all package2
   modules under Package2. Problem: -pack uses a cmo instead of a cma. So,
   many unnecessary modules might be linked into my program. This affects
   compilation time and size, but it should not affect run time.

2) Manually rename some modules. Problem: Each time I upgrade, I have to
   do the renaming again. Time-consuming.

The on-topic question is: Is there something better that the OCaml developers
could provide without taking them too much effort? User-only solutions are
not going to make it.

On Sat, Jul 19, 2003 at 01:55:18PM +0200, Gerd Stolpmann wrote:

[long introduction to his own packaging system]

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Gerd Stolpmann]

Am Sam, 2003-07-19 um 14.18 schrieb Fernando Alegre:
> I use Debian and I am happy, thank you very much, but that's good enough
> for me. I guess RedHat/Suse/Mandrake users think similarly, and windows
> users... get what they pay for, sorry.

I.e. nothing. Debian is the only distribution with good O'Caml packages
I know. From a common point of view this is a very unsatisfactory
situation, because Debian is not the world.

> Packaging is off-topic. The on-topic problem is module naming. If I want
> to use two packages in my program, but both have a module called Stuff,
> I have a problem. Current workarounds:

I would say this is a minor problem, and not even a technical one. Why
don't you ask the developers to rename their modules?

> 1) Use -pack to wrap all package1 modules under Package1, and all package2
>    modules under Package2. Problem: -pack uses a cmo instead of a cma. So,
>    many unnecessary modules might be linked into my program. This affects
>    compilation time and size, but it should not affect run time.
> 
> 2) Manually rename some modules. Problem: Each time I upgrade, I have to
>    do the renaming again. Time-consuming.
> 
> The on-topic question is: Is there something better that the OCaml developers
> could provide without taking them too much effort? User-only solutions are
> not going to make it.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Fernando Alegre]

On Sat, Jul 19, 2003 at 02:38:37PM +0200, Gerd Stolpmann wrote:

> I.e. nothing. Debian is the only distribution with good O'Caml packages
> I know. From a common point of view this is a very unsatisfactory
> situation, because Debian is not the world.

I agree, but I still think packaging is off-topic for the Ocaml list. It has
nothing specific to the Ocaml language or the ocaml compilers/interpreters.
The real problem is managing module namespace, independently of how files are
organized.

> > Packaging is off-topic. The on-topic problem is module naming. If I want
> > to use two packages in my program, but both have a module called Stuff,
> > I have a problem. Current workarounds:
> 
> I would say this is a minor problem, and not even a technical one. Why
> don't you ask the developers to rename their modules?

We should be looking for solutions under our control. Developers might
refuse (and rightly so) to rename their modules, and then we are stuck.

I have two suggestions for the Ocaml developers:

1) Make -pack use cma instead of cmo
2) Add an -alias option to the compiler (and an #alias to the interpreter)
   so that modules in the cmi/cmo files use the alias name instead of the
   file name.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)

[Yamagata Yoriyuki]

From: Daniel Bünzli <daniel.buenzli@epfl.ch>
Subject: Re: [Caml-list] CTAN/CPAN for Caml (COCAN ...?)
Date: Sat, 19 Jul 2003 13:25:52 +0200

> > 2) Use pack option.  Until -pack generates cma files (not cmo), I am
> >    reluctant to employ this option.
> 
> The option -pack can generate cmo files.

That was my bad English.  I meant, "Unless -pack generates cma files
...".

But thinking more about this, I began to feel the current solution
(generating cmo files) is right because all files are supposed to be
packed into one module by -pack.  If -pack generates cma, some
"packed" modules may be not initialised, which is against the module
semantics of ocaml.

The problem here is, the roles of modules in ocaml are twofold, that
is, a unit of initialisation and a unit of the name-space.  So, if we
want packed modules to be individually initialised, we need something
other than a module.  Since introducing a "name-space syntax" clutters
the language, (and I think the ocaml syntax is already not so
elegant) I guess what we actually need is a tool that manages the name
space without modifying the source code.

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI

[Yamagata Yoriyuki]

From: Gerd Stolpmann <info@gerd-stolpmann.de>
Subject: Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))
Date: 19 Jul 2003 14:38:37 +0200

> I would say this is a minor problem, and not even a technical one. Why
> don't you ask the developers to rename their modules?

A name clash likely occurs if a library, say A, internally uses
another library, say B, and a user want to link A and the incompatible
version of the library B.

The developer of the library A could change the name of the internal
library B, but programmers (especially I) are sloppy.

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[BdB]

Packaging and easing the distribution of libraries, is one issue ; naming
hierarchy, i.e. ensuring non-collision of names used by different libraries,
is another one. Both issues are very on-topic and need to be addressed. The
only topic here is how to enable code reuse among the O'CaML community.

One question I have about "-pack": say you want to distribute
SomeDataFormat.Parsing, SomeDataFormat.PrettyPrinting and that you want to
factor in-memory representations of data into SomeDataFormat.Common (this
situation almost always occurs for I/O modules). How do you do this
with -pack? How do you distribute these 3 modules to developers? Developer 1
wants to only parse so should have Parsing and Common, developer 2 wants to
only print so should have PrettyPrinting and Common, and developer 3 wants
to do both so should have them all... Wouldn't "-pack" enable you to only
distribute one big SomeDataFormat module?

If so, then as of now the "-pack" option can't be used to distribute library
modules. Another way is to use prefixed top-level names such as
SomeDataFormat_Parsing for modules -- like in C, which does not have any
form of namespace structure, but whose community respects a code of practice
that is to give prefixes to all exported functions.

I personally am not too keen on this. One major issue I have with this is
that when you decide to release some files that were used internally, you
have to add a prefix to your top-level files. Staying at the top-level
implies having to run sed through all your code (in the easiest case). I
guess the intent of "-pack" was to simplify this...

GS> I would say [namespace clash] is a minor problem [...].

This problem is not minor. It has shown up in the past repeatedly up to the
point that people can't solve it on their own and send an email to the
mailing list, which usually spawns a thread similar to this one. It will all
the more occur as the community scales up.

Here's a pick of some threads in this mailing list:

     * << I observed that both camlimages and labltk have a module named
"Image". >> @ http://caml.inria.fr/archives/200303/msg00345.html

     * Someone wrote a module named "array.ml" and realized later they
couldn't access the "standard" array module anymore. Someone proposed to
rename the standard library modules to Std.* so that they don't clobber the
developer's namespace @ http://caml.inria.fr/archives/200208/msg00432.html

     * Name clash between findlib and dynlink's "Meta" modules @
http://caml.inria.fr/archives/200209/msg00232.html

GS> I would say [that name clash is] not even a technical [problem].

True! I am not talking about a specific language feature, but about a
problem whose solution may involve a combination of standard community
practices, utilities, and language features. Just because it is not entirely
technical does not mean it is not important.

GS> Why don't you ask the developers to rename their modules?

I do not think it is very wise to "ask" too much -- especially such boring
stuff as renaming -- in case of voluntary donations. Gerd, you are the
author of findlib, which has been found out to collide with dynlink's Meta
module, what did you think about having to rename all your modules to fl_*?
Because you are an exceptionally generous contributor to the O'CaML
community, you were willing to do this. But this raises the developer "entry
barrier" significantly.

All the requirements I can come up with for now are listed below; I am
curious to see what the list thinks about this. The numbers are just to keep
track, not a rank.

 1. The top-level namespace should always be free to end-application
developers
 2. There should be syntactic sugar like "open" to access elements of the
namespace in a context-sensitive manner -- some core namespaces should also
be "open"-ed by default.
 3. There should always be the option to use "fully qualified names" whose
interpretation is immune to context variations. At any point in the code,
all the namespace should be "locally accessible"; i.e. accessible by simply
typing stuff where the cursor is, not needing to modify anything elsewhere.
 4. It should be relatively painless for an application writer to spin off
some top-level files of an application as a community library. This means it
should be easy to move modules around in the namespace, or at least to push
top-level modules down to other areas in the namespace.
 5. The migration path for end-application developers should equally be easy
(from the currently-flat namespace)
 6. The SomeDataFormat example above must be able to be to be distributed in
three parts situated at a hierarchical level below SomeDataFormat.
 7. There should be room for
    - Modules managed by the core language team (like the java.* namespace
in Java)
    - Managed community modules : CPAN-like archives
    - Un-managed community modules : independent releases of libraries

Finally, I came across this old post by Yurii A. Rashkovskii @
http://caml.inria.fr/archives/200211/msg00002.html . I don't know if there
have been any follow-ups to it, but it gives an example of namespace added
through preprocessing. Worth reading at any rate...

BdB.

> -----Message d'origine-----
> De : owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr]De la part de Gerd Stolpmann
> Envoyé : samedi 19 juillet 2003 14:39
> À : Fernando Alegre
> Cc : Shawn Wagner; caml-list@inria.fr
> Objet : Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))
>
>
> Am Sam, 2003-07-19 um 14.18 schrieb Fernando Alegre:
> > I use Debian and I am happy, thank you very much, but that's good enough
> > for me. I guess RedHat/Suse/Mandrake users think similarly, and windows
> > users... get what they pay for, sorry.
>
> I.e. nothing. Debian is the only distribution with good O'Caml packages
> I know. From a common point of view this is a very unsatisfactory
> situation, because Debian is not the world.
>
> > Packaging is off-topic. The on-topic problem is module naming. If I want
> > to use two packages in my program, but both have a module called Stuff,
> > I have a problem. Current workarounds:
>
> I would say this is a minor problem, and not even a technical one. Why
> don't you ask the developers to rename their modules?
>
> > 1) Use -pack to wrap all package1 modules under Package1, and
> all package2
> >    modules under Package2. Problem: -pack uses a cmo instead of
> a cma. So,
> >    many unnecessary modules might be linked into my program.
> This affects
> >    compilation time and size, but it should not affect run time.
> >
> > 2) Manually rename some modules. Problem: Each time I upgrade, I have to
> >    do the renaming again. Time-consuming.
> >
> > The on-topic question is: Is there something better that the
> OCaml developers
> > could provide without taking them too much effort? User-only
> solutions are
> > not going to make it.
>
> Gerd

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Kip Macy]

> > I.e. nothing. Debian is the only distribution with good O'Caml packages
> > I know. From a common point of view this is a very unsatisfactory
> > situation, because Debian is not the world.
> 
> I agree, but I still think packaging is off-topic for the Ocaml list. It has
> nothing specific to the Ocaml language or the ocaml compilers/interpreters.

After having fought with a half-dozen semi-complete ocaml tar balls, I
couldn't disagree more. I'm hoping that the list is for the
general use of Ocaml and not just discussing language semantics. 


 		-Kip


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Gerd Stolpmann]

Am Sam, 2003-07-19 um 22.40 schrieb BdB:
> Packaging and easing the distribution of libraries, is one issue ; naming
> hierarchy, i.e. ensuring non-collision of names used by different libraries,
> is another one. Both issues are very on-topic and need to be addressed. The
> only topic here is how to enable code reuse among the O'CaML community.

Both are related, at least in the sense that problems with code reuse
are often detected by packagers, or by users of packages. Furthermore,
packagers are the natural "authority" to ask the upstream developers to
change their software for better reuse.

> GS> Why don't you ask the developers to rename their modules?
> 
> I do not think it is very wise to "ask" too much -- especially such boring
> stuff as renaming -- in case of voluntary donations. Gerd, you are the
> author of findlib, which has been found out to collide with dynlink's Meta
> module, what did you think about having to rename all your modules to fl_*?

Given that I restructure my libraries from time to time from the grounds
up, this is really one of the things I try to take easy. Other types of
changes cause much more problems, especially inconveniences by the users
who have to follow the changes.

> Because you are an exceptionally generous contributor to the O'CaML
> community, you were willing to do this. But this raises the developer "entry
> barrier" significantly.

Yes, sure. But other "processes" do this, too, especially the namespace
approach you suggest.

> All the requirements I can come up with for now are listed below; I am
> curious to see what the list thinks about this. The numbers are just to keep
> track, not a rank.
> 
>  1. The top-level namespace should always be free to end-application
> developers
>  2. There should be syntactic sugar like "open" to access elements of the
> namespace in a context-sensitive manner -- some core namespaces should also
> be "open"-ed by default.
>  3. There should always be the option to use "fully qualified names" whose
> interpretation is immune to context variations. At any point in the code,
> all the namespace should be "locally accessible"; i.e. accessible by simply
> typing stuff where the cursor is, not needing to modify anything elsewhere.
>  4. It should be relatively painless for an application writer to spin off
> some top-level files of an application as a community library. This means it
> should be easy to move modules around in the namespace, or at least to push
> top-level modules down to other areas in the namespace.
>  5. The migration path for end-application developers should equally be easy
> (from the currently-flat namespace)
>  6. The SomeDataFormat example above must be able to be to be distributed in
> three parts situated at a hierarchical level below SomeDataFormat.
>  7. There should be room for
>     - Modules managed by the core language team (like the java.* namespace
> in Java)
>     - Managed community modules : CPAN-like archives
>     - Un-managed community modules : independent releases of libraries

That sounds really complicated! I am more and more thinking that we are
on the wrong track. Every hierarchical solution has the disadvantage
that it needs administration. I have an alternative, the "relational
solution". What we want to manage is nothing but a database of top-level
modules, and we want to find a way to uniquely identify every row of the
"modules table". Currently, the rows have only two fields: "name", and
"contents". My suggestion is to introduce further fields, like "author",
"organization", maybe even "version" and so on. So a module can have a
set of attributes:

module M = sig
  attributes
    author = "Gerd Stolpmann",
    organization = "ocaml-programming.de",
    version = "42.5"

  ... further signature ...
end

You can now disambiguate module names by these attributes, e.g.

open M[author="Gerd Stolpmann"]
open M[version>="42.0"]

To minimize the notation, I would suggest a default selection for the
whole module context:

select author="Gerd Stolpmann" for M
select organization="INRIA" | organization="..." | ... for *

The latter would be applied to all unqualified occurrences of top-level
module names, so you have typically only one extra line at the top of
every module implementation.

I would suppose this is very simple to implement in the compilers. There
is already meta data for top-level modules (the MD5 checksum), so it is
only an extension of this.

The best thing is that it is very natural for developers of libraries to
add the attributes to their exported modules. Collisions can be fixed
incrementally as they occur (even packagers could fix them easily
themselves). Maybe there could be a "style guide" explaining the
problems and how to address them by proper attributing the modules.

What do you think about this?

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Christian Lindig]

On Sun, Jul 20, 2003 at 11:55:49AM +0200, Gerd Stolpmann wrote:
> I have an alternative, the "relational solution". 
> module M = sig
>   attributes
>     author = "Gerd Stolpmann",
>     organization = "ocaml-programming.de",
>     version = "42.5"
> 
>   ... further signature ...
> end
> 
> You can now disambiguate module names by these attributes, e.g.
> 
> open M[author="Gerd Stolpmann"]
> open M[version>="42.0"]

This is a fresh idea. But I get the impression that the essence of it is
to decouple the name of a module from the name of the file that contains
it.  Somebody suggested already an -alias directive for similar
purposes. 

We have to decide whether we want this decoupling to happen at the level
of the language (i.e. new syntax), or only the level of its
implementation (i.e. new compiler flags). Right now, the mapping of
module names to files is a matter of the compiler and mostly invisible
at the language level.  

-- Christian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI

[Yamagata Yoriyuki]

From: Gerd Stolpmann <info@gerd-stolpmann.de>
Subject: RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))
Date: 20 Jul 2003 11:55:49 +0200

> What we want to manage is nothing but a database of top-level
> modules, and we want to find a way to uniquely identify every row of the
> "modules table". Currently, the rows have only two fields: "name", and
> "contents". My suggestion is to introduce further fields, like "author",
> "organization", maybe even "version" and so on. So a module can have a
> set of attributes:

Honestly, I am not very inclined to publish my personal information
along with libraries....  It is better (for me) if modules are
specified by their checksum, or signatures (with some syntax sugar).

BTW, all collisions really occurred are between modules not available
from users.  This kind of problem can be solved if we can make
"private" modules completely invisible from the outside of packages.

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI

[Fernando Alegre]

On Mon, Jul 21, 2003 at 08:11:53AM +0900, Yamagata Yoriyuki wrote:
> 
> BTW, all collisions really occurred are between modules not available
> from users.  This kind of problem can be solved if we can make
> "private" modules completely invisible from the outside of packages.

Although this may be good enough in the short term, it won't avoid name
clashes in the long term. Inevitably, packages will eventually be created
with the same toplevel names as other existing packages. We'll need some
user tool to manage module namespaces when this occurs.

Fernando

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[james woodyatt]

On Sunday, Jul 20, 2003, at 11:30 US/Pacific, Christian Lindig wrote:
>
> This is a fresh idea. But I get the impression that the essence of it 
> is
> to decouple the name of a module from the name of the file that 
> contains
> it.  Somebody suggested already an -alias directive for similar
> purposes.
>
> We have to decide whether we want this decoupling to happen at the 
> level
> of the language (i.e. new syntax), or only the level of its
> implementation (i.e. new compiler flags). Right now, the mapping of
> module names to files is a matter of the compiler and mostly invisible
> at the language level.

Yeah, the more I think about this problem, the more convinced I am that 
the only way to solve the problem well enough to quiet the bulk of the 
complaining is to do something-- in the syntax of the language-- to 
couple the *name* of a module with the globally unique *identifier* of 
the library that contains it.

It seems to me that the compiler and the linker should be taught that 
all libraries have a hierarchical URI attributed to them.  These would 
not be locators.  They would be identifiers.

More importantly, to quiet the complaints about the real problem at 
hand-- promoting code re-use-- there should be new language syntax for 
specifying module paths to include the URI of the library.  I hesitate 
to propose one, but Gerd may be onto something:

	module Q = Queue[http://ocaml.org/lib/3.1]

There should also be well-defined functions for turning a library URI 
into an appropriate URL, e.g. a file:-scheme URL for local library 
paths, an http:-scheme URL for web library paths, etc.

That's my take.  I hope it doesn't suck.


-- 
j h woodyatt <jhw@wetware.com>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Richard Jones]

There are two big lessons from Java about how NOT to do this:

(1) $CLASSPATH

(2) uk.co.mycompany.unweildy.modules.names

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
 All new technology is irrelevant until it is taken up by the public.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Richard Jones]

On Mon, Jul 21, 2003 at 05:32:07PM +0100, Richard Jones wrote:
> There are two big lessons from Java about how NOT to do this:

Actually, THREE big lessons about how NOT to do this:

(3) ant

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
 All new technology is irrelevant until it is taken up by the public.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[james woodyatt]

On Monday, Jul 21, 2003, at 09:32 US/Pacific, Richard Jones wrote:
>
> There are two big lessons from Java about how NOT to do this:
> Actually, THREE big lessons about how NOT to do this:
>
> (1) $CLASSPATH

Yeah, the mistake here is that a resource *identifier* is not the same 
as a resource *locator*.  I'm less worried about the process the INRIA 
tools implement to locate .cmo and .cmi files than I am about the 
semantics the Ocaml language supports for identifying libraries under a 
federated naming authority.

The issue at hand-- for me, at least, as a guy writing a component 
toolkit-- is the anarchy caused by planting the root of the 
extended-module-path production in a single global namespace with no 
organization.  I can enjoy the occasional visits to anarchy: I've been 
to Burning Man more than once.  But I like to live and work in 
republics-- especially in republics where the citizens can afford their 
upkeep (but that's another rant).

> (2) uk.co.mycompany.unweildy.modules.names

Yeah again.  The problem here is the conflation of the module path with 
the naming authority.  When you want to use modules from multiple 
libraries with different naming authorities, you need a way to identify 
the library resource that contains the extended module path.  That's 
why we can't do it with just compiler and linker arguments.  We need 
new syntax.

Right now, there is one library that contains all extended module 
paths: the Standard Objective Caml library.  (Note well: I am not 
talking about a .cma file here.)

On my system, the contents of that library are located in 
<file:///usr/lib/ocaml/>.  Since there's only one library, I don't have 
to identify it explicitly in my code.  The locator is hard-coded into 
the compiler and linker.  I can use arguments/environment to change it, 
and even add multiple locators to search, but I can't change the fact 
that there is only one library that must contain all the extended 
module paths in my system.

Which wouldn't be so bad-- if there were an omniscient, omnipotent, 
omnibenevolent worldwide librarian to regulate top-level module name 
assignment.  There isn't one, and I'm pretty sure I don't want one.

> (3) ant

Yeah again again.  Don't get me wrong: I hate /usr/bin/make more than 
any of three of you.  But I don't regard 'ant' as an improvement.  That 
said, the topic of software construction tools is completely unrelated 
to the main issue that fished me out of lurk mode: the opportunity to 
agitate for multiple roots for extended-module-path and a federating 
naming authority for those roots.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[BdB]

Rich,

Could you please elaborate?

BdB.

> (1) $CLASSPATH

Sorry if we're supposed to understand what the criticism is, I don't.

> (2) uk.co.mycompany.unweildy.modules.names

Again, what are you criticizing? The convention of using Internet names as
namespaces authorities, or the "packages" language feature? Why?


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[BdB]

Hi,

Gerd's idea is indeed interesting. I think it subsums my original idea of a
namespace. Any basis for disambiguation is to use meta-data. In the Java
case, meta-data = package name = mono-dimensional hierarchical space. Gerd's
proposal is, the meta-data can be multidimensional.

I still think we should have at least the "primary key" of the meta-data to
be structured hierarchically. Hierarchy allows delegation, and delegation is
*very* good for namespace management. If I can easily claim some portion of
the namespace, I will use it and not bother anyone with it. Delegation is
the basis of namespace management.

If we have a hierarchy in one of the meta-data, we can state a community
naming policy like:
  /Std/* == managed by the language team
  /Hump/* == managed by some "community of hump gurus" (?) yet to be defined
  /* == managed by IANA (i.e. Internet TLDs): for contributors who want to
enable others to use their code but don't want to deal with hump gurus

This is just an example policy, and I insist that we should decouple the
mechanism discussion from the policy discussion. What is important is that
delegation can be enabled easily.

Flattening multi-dimensional meta-data to one dimension involves choosing an
arbitary order between keys. I find this very annoying for music. I can
never decide between "Beethoven/Sonatas/Piano/Moonshine Sonata",
"Piano/Sonatas/Beethoven/Moonshine Sonata", etc. So, you may call me a fan
of the general idea to have many metadata dimensions.

I'm not sure it happens as often for software modules, though. For Java,
there's a kind of implicit ordering between metadata: author is before. The
thing is, often times the hierarchy below the author is author-specific and
cannot be generalized to other authors. So it makes sense to be last, in my
opinion. Unlike music where genre, instrument and author are really
orthogonal to each other. Maybe version can be used to allow the same
library to be linked twice with two different versions in the same software,
but this looks like an odd case. We should check that there are no other
ways of solving the "two different library versions linkage" problem...

What I think we should not do is succomb to the "NIH syndrom." Let's be
honest: I see many criticism of Java's "simple and stupid" package model,
but I don't really understand: hasn't the Java community pretty much scaled
up and avoided the nameclash problem? I can certainly see shortcomings in
the Java approach, but anyone calling that a failure would be simply
negating the reality that there are millions of Java developers and that
namespace clash is not a problem there -- vs. how many O'CaML developers and
already lots of nameclash? Let's not be afraid or shameful to simply copy
what's working elsewhere.

Note for perl fans out there, I am considering Java and Perl's technical
solutions for namespaces to be roughly isomorphic. The naming policies are
certainly different, given the CPAN-managed namespace vs. IANA-managed
namespace, but I insist (again) on separating the two aspects.

I have a concrete proposal:

 * "Let's KISS first" (keep it simple and stupid). Let's start out by
building a mono-dimensional hierarchical namespace model a la Java. This
way, we can at least show the INRIA how we, as a community, would like it
done. Simply complaining about nameclash to the INRIA cannot be expected to
work -- especially considering what we are paying for O'CaML.

 * Gerd's relational metadata proposal is more powerful, but also
undoubtedly more difficult to implement; What I propose is step-by-step:
once we have a model for simple and stupid Java-like namespace, Gerd can
make a detailed proposition of an extension that introduces
multi-dimensional meta-data, and we can see then if it is worth it. In the
meantime, we should of course not rule out the possibility that meta-data
becomes multi-dimensional.



I have observed that the nameclash issue has shown up four to five times in
the past on this mailing list. Each time, what happened was that a
passionate brainstorming session followed, but no action was taken in the
end and nothing resulted but entertaining logs. I am getting tired of seeing
the same topic raised over and over again, and I don't think one more thread
of "why don't we just" posts is going to solve anything.

This is why I suggest that we work through the following steps:
  1/ agreeing on our purpose; expressing what is wrong now and how we would
like it to change, through a list of high-level requirements;
  2/ agreeing on what needs to be done, technically and non-technically, to
fulfil these requirements (language mods? compiler mods? preprocessor?
naming policy?)
  3/ doing it.

I have taken part in a couple of software-related community working groups
that have used similar processes and have produced useful solutions to the
problems they had set to resolve. That's why although such an approach takes
time and has overhead compared to regular mailing list participation, I hope
that this way we could finally *get rid* of this issue together instead of
just brainstorming about it regularly and not getting anything done. Only
through a continued effort on this topic can we progress. We could use the
mailing list to distribute work among us and sync up every week or two, mark
what we have done, agree on what to do next and on who does it. I would like
to invite interested people to seriously commit over time to solving the
nameclash issue through such an approach. *Not more time* is required than
what you currently spend on this mailing list, just the same amount of time
but that you will use to think about this one topic for a couple of months.

Who is on?

BdB.

PS: I am also noticing the total absence of the INRIA's expression on this
thread. I think the community is extremely motivated to help out the team,
but I would like to check whether it is welcome that the community does some
thinking about the nameclash issue. Not that I think that we should take
over development of O'CaML, but the "-pack" option does not seem to help
avoiding nameclash and I don't want to just complain about it...


> -----Message d'origine-----
> De : Christian Lindig [mailto:lindig@eecs.harvard.edu]
> Envoye : dimanche 20 juillet 2003 20:30
> A : Gerd Stolpmann
> Cc : BdB; Fernando Alegre; Shawn Wagner; caml-list@inria.fr
> Objet : Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))
>
>
> On Sun, Jul 20, 2003 at 11:55:49AM +0200, Gerd Stolpmann wrote:
> > I have an alternative, the "relational solution".
> > module M = sig
> >   attributes
> >     author = "Gerd Stolpmann",
> >     organization = "ocaml-programming.de",
> >     version = "42.5"
> >
> >   ... further signature ...
> > end
> >
> > You can now disambiguate module names by these attributes, e.g.
> >
> > open M[author="Gerd Stolpmann"]
> > open M[version>="42.0"]
>
> This is a fresh idea. But I get the impression that the essence of it is
> to decouple the name of a module from the name of the file that contains
> it.  Somebody suggested already an -alias directive for similar
> purposes.
>
> We have to decide whether we want this decoupling to happen at the level
> of the language (i.e. new syntax), or only the level of its
> implementation (i.e. new compiler flags). Right now, the mapping of
> module names to files is a matter of the compiler and mostly invisible
> at the language level.
>
> -- Christian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] licensing (was Re: GODI (was: CTAN/CPAN for Caml (COCAN ...?)))

[Alan Post]

> Not that I think that we should take over development of O'CaML, but
> the "-pack" option does not seem to help avoiding nameclash and I
> don't want to just complain about it...

You are actually not permitted by the license to "take over
development of O'CaML".  In practice, this means that it is indeed
very important what the INRIA folks think about any given issue.

  http://caml.inria.fr/ocaml/LICENSE.html

This page explains that ocaml compiler is licensed under the QPL,
rather than the GPL, because "proper attribution of results is crucial
in the research world."  Would any INRIA folks care to elaborate on
this?  I really haven't heard about cases where an academic didn't get
tenure because her free software project was forked.  I'm not an
academic, so perhaps I just don't hear about such events.

The page also says,

  We are aware that this clause of the QPL (distribution of modified
  versions as patches) can become uncomfortable for the development of
  programs derived from the OCaml compilers and tools. If so, consider
  becoming a member of the Caml Consortium: members of the Consortium
  benefit from less restrictive licensing conditions.

Though presumably the >= 2000 Euro license does not allow the
redistribution of modified ocaml compiler sources, either.

I would guess that the Caml Consortium license is aimed at
proprietary, binary-distribution forks of ocaml.  Note that a GPLed
public release of the ocaml compiler would not interfere with this
revenue source.


The page does not mention what will happen when INRIA stops funding
ocaml development.  If I understand correctly, it is INRIA as an
entity, rather than the ocaml developers, who owns the copyright to
the ocaml compiler.  An example of what can happen is qmail:  I
believe there have been no releases since 15 June 1998, leading to a
maze of patches.


I searched the list archives, and found much discussion of the library
license (the complications of the LGPL), but not much about ocaml
compiler licensing.  Twice, people asked about it:

  http://caml.inria.fr/archives/200111/msg00478.html
  http://caml.inria.fr/archives/200111/msg00464.html

but both questions went unanswered.

I'd be very interested to hear more about this.


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] licensing (was Re: GODI (was: CTAN/CPAN for Caml (COCAN ...?)))

[Dominique Quatravaux]

> I really haven't heard about cases where an academic didn't get
> tenure because her free software project was forked.

  RMS ? :-)

-- 
Dominique QUATRAVAUX                           Ingénieur senior
01 44 42 00 08                                 IDEALX


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] licensing (was Re: GODI (was: CTAN/CPAN for Caml (COCAN ...?)))

[BdB]

> > Not that I think that we should take over development of O'CaML, but
> > the "-pack" option does not seem to help avoiding nameclash and I
> > don't want to just complain about it...
>
> You are actually not permitted by the license to "take over
> development of O'CaML".  In practice, this means that it is indeed
> very important what the INRIA folks think about any given issue.

The community always has the ability to distribute patches.

I just don't think the community should try to think about major language
modifications on its own, not because of licensing, but because we just
won't be good at this.



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI

[Yamagata Yoriyuki]

From: "BdB" <bdbkun@wanadoo.fr>
Subject: RE: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))
Date: Tue, 22 Jul 2003 02:01:45 +0200

> Any basis for disambiguation is to use meta-data. In the Java
> case, meta-data = package name = mono-dimensional hierarchical space. Gerd's
> proposal is, the meta-data can be multidimensional.
> 
> I still think we should have at least the "primary key" of the meta-data to
> be structured hierarchically.

So we are going to define global identifies for modules.  Well, such a
move is neither necessary, nor sufficient for the conflict resolution,
unless the policy is strictly enforced, but then it has the own
drawback.  Global identification is certainly interesting facility,
but our problem (the conflict of the name space) raises well before
the problem of global identification.  Actually, we do not have the
method to manage the name space even locally.

I think we should tackle this problem by a step-by-step manner, like

    a) Make a tool consistently renaming the modules.  Also,
    modification of the compiler to "untie" the module name from the
    file name would be required.

    b) Incorporate these tools to package management tools.  For
    example, when installing a package, each module in the package is
    renamed to <package name>_<original module name>.  Also, we may
    need to add the "completion" facilities to the compiler, so that
    if <package name> is omitted, the compiler will automatically
    search the right module.

    c) Adopt hierarchical package names, say, Num_Matrix_<....> and
    enable users to "mount" these hierarchies to nodes they choose.  So,
    for example, some users choose stdlib resides the top level, while
    some users mount them under Stdlib... and so on.

I think many people have similar ideas.

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Christian Lindig]

On Mon, Jul 21, 2003 at 09:19:43AM -0700, james woodyatt wrote:
> Yeah, the more I think about this problem, the more convinced I am that 
> the only way to solve the problem well enough to quiet the bulk of the 
> complaining is to do something-- in the syntax of the language-- to 
> couple the *name* of a module with the globally unique *identifier* of 
> the library that contains it.

I agree and like to add another aspect: relative access of modules.
Sometimes we just want to use a standard module and we don't care where
it comes from exactly. At other times we just know that the module we
are looking for resides in the same directory as our current module
because we wrote it and put it there. The current OCaml syntax does not
distinguish between these two. I believe the C inventors had a good
reason to have both #include <...> and #include "..." (the latter
includes a file relative to the location of the source file that
contains it (and not relative to the $CWD of the compiler)).  

A well-designed library would refer relatively to its own modules, plus
some standard modules. It should compile independently of its position
in the file system.

-- Christian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Xavier Leroy]

I have followed this discussion with interest, although other
commitments prevented me from replying earlier.

I think there are two completely orthogonal issues:

1- Caml library packaging: standardizing and automating the
configuration, compilation, installation, dependency handling and
re-compilation when dependents change.

2- Name space management: avoiding the unfortunate situation where
several packages define compilation units that have the same names.

I agree with Gerd that the first issue (library packaging) is by far
the most acute.  The lack of a packaging framework currently makes
using third-party Caml libs in a development much harder than it
should be.

Someone objected that this isn't a Caml-specific issue and that it can
be handled by standard packaging tools.  Perhaps, but the problem is
that there are no standard packaging tools.  Even among Linux
distributions, the packaging tools vary widely.  Not to mention other
Unixes (BSD, Solaris, Tru64, ...), and MS Windows.  This flies in the
face of the cross-platform portability offered by the core Caml
system.  It's not reasonable to expect that the world will convert
overnight to Debian's "apt".  It's not reasonable either to expect
library writers to package their libs for 8 different packaging
systems, especially when most of them wouldn't touch Windows with a pole.
That's why other cross-platform programming environments
such as Perl and Python have developed their own packaging technology.

Library packaging is one of those "soft", un-glamorous problems: there
are no hard, open problems, just an endless series of small problems
to be solved and policy decisions to be taken.  I had interesting
discussions with several of you concerning possible designs, but
apparently these efforts ran out of steam.  I'm very happy to see that
Gerd (with his eminent practical sense) is giving it a try, and I wish
he'd get more constructive feedback on this.

Now, the name space management issue seems over-inflated to me.
Yes, it can happen, and may become a serious issue once we have
hundreds of libs that need to coexist.  But I think we can still get
a lot of mileage out of the current "global namespace for compilation
units" model.  In particular, most libraries can be set up so that
they define only *one* top-level module (i.e. compilation unit):

- put all sources in one file, possibly with sub-modules
  (not as ugly as it sounds -- see my Cryptokit library for an example);
- put all user-visible definitions in one file, say Mylib.ml, and 
  put internal definitions in other files with unlikely names such as
  MylibInternalFoo.ml, MylibInternalBar.ml, etc
- use ocamlc -pack to assemble the library files into one compilation
  unit.

Some people reject ocamlc -pack on the grounds that it prevents
link-time elimination of unused sub-modules.  I think they are jumping
to conclusions.  First, for many libraries, there is essentially no
opportunity for this link-time elimination, as every sub-module is
used.  Second, many libraries are small enough that the increase in
code size doesn't matter much.  Third, this is a "quality of
implementation" issue: I might be able to implement this link-time
elimination for the native-code compiler (ocamlopt -pack) at some
future time.  The problem remains for bytecode, though, but is perhaps
less acute due to the small size of bytecode.

Finally, as this discussion demonstrates eloquently, there is no
obviously good solution to the name space management problem.  Yes,
various things can be done either at the language level or at the
compiler level to support finer identification and re-naming of
compilation units.  But I'd rather not settle on a half-baked solution
to a non-acute problem.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Gerd Stolpmann]

Am Mit, 2003-07-23 um 11.35 schrieb Xavier Leroy:
> I have followed this discussion with interest, although other
> commitments prevented me from replying earlier.
> 
> I think there are two completely orthogonal issues:
> 
> 1- Caml library packaging: standardizing and automating the
> configuration, compilation, installation, dependency handling and
> re-compilation when dependents change.
> 
> 2- Name space management: avoiding the unfortunate situation where
> several packages define compilation units that have the same names.
> 
> I agree with Gerd that the first issue (library packaging) is by far
> the most acute.  The lack of a packaging framework currently makes
> using third-party Caml libs in a development much harder than it
> should be.
> 
> [...]
> That's why other cross-platform programming environments
> such as Perl and Python have developed their own packaging technology.

They did it also to demonstrate their usefulness in system
administration. I don't see that this is the natural application for a
universal language like O'Caml, so we could also reuse existing
packaging technologies provided they are portable enough. This is the
reason why I chose the NetBSD system for my experiments (which I have
actually done on Linux and Solaris, just to test the portability).
 
> Library packaging is one of those "soft", un-glamorous problems: there
> are no hard, open problems, just an endless series of small problems
> to be solved and policy decisions to be taken.  I had interesting
> discussions with several of you concerning possible designs, but
> apparently these efforts ran out of steam.  I'm very happy to see that
> Gerd (with his eminent practical sense) is giving it a try, and I wish
> he'd get more constructive feedback on this.

What I would like to hear is that:

- people are really interested in a source distribution
- people want to spend time and help packaging
- people want to contribute resources (e.g. network disk space)

The problem is that I have only very limited time for this, and I hope
that once the project is set up my assistance would not be needed any
longer.

> Now, the name space management issue seems over-inflated to me.
> Yes, it can happen, and may become a serious issue once we have
> hundreds of libs that need to coexist.  But I think we can still get
> a lot of mileage out of the current "global namespace for compilation
> units" model.  In particular, most libraries can be set up so that
> they define only *one* top-level module (i.e. compilation unit):
> 
> - put all sources in one file, possibly with sub-modules
>   (not as ugly as it sounds -- see my Cryptokit library for an example);
> - put all user-visible definitions in one file, say Mylib.ml, and 
>   put internal definitions in other files with unlikely names such as
>   MylibInternalFoo.ml, MylibInternalBar.ml, etc
> - use ocamlc -pack to assemble the library files into one compilation
>   unit.
> 
> Some people reject ocamlc -pack on the grounds that it prevents
> link-time elimination of unused sub-modules.  I think they are jumping
> to conclusions.  First, for many libraries, there is essentially no
> opportunity for this link-time elimination, as every sub-module is
> used.  Second, many libraries are small enough that the increase in
> code size doesn't matter much.  Third, this is a "quality of
> implementation" issue: I might be able to implement this link-time
> elimination for the native-code compiler (ocamlopt -pack) at some
> future time.  The problem remains for bytecode, though, but is perhaps
> less acute due to the small size of bytecode.

I think the real problem is that -pack is not supported on all
platforms, or only if you install GNU binutils. So up to now I have
understood -pack as an experiment.

> Finally, as this discussion demonstrates eloquently, there is no
> obviously good solution to the name space management problem.  Yes,
> various things can be done either at the language level or at the
> compiler level to support finer identification and re-naming of
> compilation units.  But I'd rather not settle on a half-baked solution
> to a non-acute problem.

Namespaces are not only a technical problem, but also a matter of good
organization. This is why almost every suggestion looks half-baked.
Furthermore, it was a bit surprising for me that most participants of
the discussion favoured hierarchical solutions, which would mean we need
some kind of "authority" administering the hierarchy. Very unlikely that
we ever get this, or can agree on it. (Don't forget that the Perl people
are often system administrators, and they are used to this kind of
management.) I really think that we should view namespaces as indexes to
an open, distributed database of modules (if this problem ever gets
acute), at least currently this would me more adequate to the grade of
organization of the O'Caml community.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[David Brown]

On Wed, Jul 23, 2003 at 11:35:46AM +0200, Xavier Leroy wrote:

> Finally, as this discussion demonstrates eloquently, there is no
> obviously good solution to the name space management problem.  Yes,
> various things can be done either at the language level or at the
> compiler level to support finer identification and re-naming of
> compilation units.  But I'd rather not settle on a half-baked solution
> to a non-acute problem.

Did anyone read my proposal to allow submodules to be compiled in
separate files?  I didn't see any feedback. Perhaps it was so confusing
that nobody understood it.

There are several other languages/compilers that use a technique like
this.  It probably can be done with very minor changes to the language
(probably no syntax change, just adding the semantics of modules in
separate files).  GHC implements it one way, whereas GNAT implements it
a different way.  I think discussing it could point to a clean
implementation.

The advantage is that there is nothing new added to the language.  I can
place my library as sub-modules of another module, and yet have them as
separate files.

I also disagree that the namespace problem is a minor issue.  I think it
will be a hindrance to use of Ocaml for moderate to large projects.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Fernando Alegre]

On Wed, Jul 23, 2003 at 10:56:27AM -0700, David Brown wrote:

> I also disagree that the namespace problem is a minor issue.  I think it
> will be a hindrance to use of Ocaml for moderate to large projects.

Me too :-)

The project I am working on consists of a dozen OCaml applications sharing
a common library. The library has so far 250 files and 50K lines of Ocaml
code. Most applications are also linked with Camlimages, LablGL, LablGtk,
plus some C and FORTRAN code.

Module namespace is starting to be a problem in this medium sized project.
On the other hand, packaging is a non-issue for us.

Fernando

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[Eray Ozkural]

Hi Gerd,

Haskell people have been working on hierarchical libraries for some time and I 
think they've come up with a really meaningful organization. It makes much 
more sense than an alphabetical list of 100 libraries.

You don't need some kind of authority to manage the hierarchy either. It's a 
self-organizing system :)

Cheers,

On Wednesday 23 July 2003 16:20, Gerd Stolpmann wrote:
> Namespaces are not only a technical problem, but also a matter of good
> organization. This is why almost every suggestion looks half-baked.
> Furthermore, it was a bit surprising for me that most participants of
> the discussion favoured hierarchical solutions, which would mean we need
> some kind of "authority" administering the hierarchy. Very unlikely that
> we ever get this, or can agree on it. (Don't forget that the Perl people
> are often system administrators, and they are used to this kind of
> management.) I really think that we should view namespaces as indexes to
> an open, distributed database of modules (if this problem ever gets
> acute), at least currently this would me more adequate to the grade of
> organization of the O'Caml community.
>
> Gerd

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners