Packages and .NET assemblies

[Matthew Pocock]

Hi,

As another data-point, you may want to take a look at what maven2 does with 
POM files. Each project has a POM, produces one artifact, and then the 
artifact and POM go around together. Projects can be arranged into a 
hierachy, so that bulding a project will cause all of its child projects to 
be built. An artifact could be a .jar, .war, .so or anything else you build. 
The POM stores meta-data about the artifact, including dependencies, where 
the source-code repository is, the URL of the web site and so on. Each POM 
has a name,version,group where the group will normally identify the 
organisation and/or project that makes the artifact. There's a mechanism for 
tracking the transient dependencies between artifacts and for matching up 
compattible version ranges. This is all integrated with a web-hosted 
repository so that when you build/run with maven2, any binary dependencies 
required are got automatically. Lastly, there are two styles of version 
names. For releases, the normal dotted notation is used. During development, 
SNAPSHOT is appended. Snapshot versions are eagerly checked for updates, so 
support collaborative development of hot code. Dotted versions are lazily 
checked for updates, and it's assumed that if you have a copy of it, there's 
no point replacing it untill the version changes.

Can I put in a +1 vote for things built by haskell carrying around a 
digest/signature of the source code (or parse tree or perhaps just the 
externally visible symbols?), so that even if the versions match, we can get 
a message early during compilation or run-time telling us if there has been a 
clearly incompattible change? With propper package-management and 
multi-package build, this could even trigger the right dependencies to be 
recompiled.

Sorry if this sounds like a "You don't have my favorite language feature X" 
rant, but I've spent nearly 2 weeks chasing module dependencies, darc URLs, 
fiddling build orders and so on, most of which is stuff that could be 
automated if the cabal files where a little bit richer and the compiler a bit 
more paranoid, and if there was some global repository of cabals of the sw 
that people wish to make available to the community.

Matthew

ps my experience is that prefixing modules by a dotted organisation designator 
ala Java/.NET seems to work very well in practice

On Tuesday 11 July 2006 13:51, Simon Marlow wrote:
> I just took a deeper look at how .NET handles packages, since they have
> thought through many of the same issues and have a scheme that scales well.
>  There's a great deal of similarity with the schemes we're thinking about
> for Haskell.
>
> The executive summary:
>
>    - A .NET assembly fulfills the same function as a Haskell package: an
>      assembly is the unit of versioning and distribution, and carries with
>      it a bunch of metadata (author, copyright, etc.).
>
>    - An assembly is uniquely identified by a triple (name,version,culture).
>
>    - An assembly travels in a single file (.DLL)
>
>    - An assembly may define multiple namespaces (like A.B.C), and entities
>      within namespaces.  Much like modules in Haskell.
>
>    - Assemblies are not named directly in source code.  C# code
>      (for example) refers to namespaces and entities only.
>
>    - When compiling C# code, you name the DLLs that contain assemblies
>      to bring into scope (in fact, the transitive closure) using
>      command-line options.
>
>    - The C# compiler brings a set of assemblies into scope by default
>      (== exposed packages in GHC).
>
>    - The binary has baked into it the exact identity of the assemblies it
> was compiled against.
>
>    - At runtime, the binary might be rebound to different versions of the
>      assemblies it depends on, via a complicated structure of configuration
>      files.
>
> So there's no grafting, or even assembly-qualified imports.  How do they
> get away with this?  Well, one reason is that namespaces are generally
> globally unique, because the convention is to use names beginning with an
> organisation (eg. Microsoft.System).  So when you bring a bunch of
> assemblies into scope, their namespaces generally don't conflict.
>
> Interestingly, the assembly story is almost identical to what GHC supports
> right now, and when we change module identities to include the package name
> (which I'm working on now), it will be even closer.  Not that I necessarily
> think we can get away with doing nothing to the language, but at lesat this
> seems to argue for being conservative.
>
> Cheers,
> 	Simon
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries