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

["BdB" <bdbkun@wanadoo.fr>]

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