<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<blockquote
cite="mid:cbd17e16-713d-cec6-d154-a462d2e74fef@cs.otago.ac.nz"
type="cite"> Here's another meta-format worthy of consideration. <br>
A *package* is a collection of resources with relationships <br>
between them and relationships linking them to other things <br>
like authors (think Dublin Core). <br>
</blockquote>
<p>
I really like this approach of thinking about packages. Apart from
the obvious benefits of some concrete format like RDF (e.g. mixing
with OpenDocument files), this way of thinking could open the door
to some interesting ways to see existing problems. As an
extension, those perspectives might lead to fruitful experiments.
(After all Haskell was originally created as an language to be
experimented with - so why not expand that to packaging?) Just two
ideas off the top of my head:</p>
<ul>
<li>
<p>One could proclaim that part of the
orphan-instances-/forced-imports-ugliness stems from the fact
that instances formulate a kind of <i>relationship</i>
between declarations and are thus fundamentally different from
these other declarations. So one might want to experiment with
separating both by adapting the package format and see what
benefits or drawbacks that brings.</p>
</li>
<li>
<p>Similarly one could proclaim that one of the things that
makes the dependency purgatory difficult to navigate is that
version numbers alone do not encode enough information - but a
finer grained analysis might. E.g. imagine you could say "I
have tested with package <i>X</i> in version 0.3.4. But feel
free to substitute any other version as long as functions <i>A</i>
and <i>B</i> haven't changed, because these are the only ones
I use." There are obvious problems with such an approach, but
I propose that we can only find a way forward by experimenting
- including experimenting with such details of the
relationship.<br>
</p>
</li>
</ul>
<p>Note that I'm not saying that experiments like these are
impossible with a format like cabal or yaml. All I'm saying is
that thinking of packages as resources in relationships makes it
easier to think in these ways. An appropriate representation could
be both a tool to shape our thoughts and a tool that, being
specialized for the representation of relationships, makes it
easier to incorporate experimental features without breaking the
ecosystem. It will probably be unavoidable to "inject" some code
into the solver for a specific package for such experiments, but I
hope that understanding the details will make it possible to see
ways how to do that in safe and portable ways.</p>
<p><br>
</p>
<p>MarLinn<br>
</p>
</body>
</html>