Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries

Iavor Diatchki iavor.diatchki at gmail.com
Sat Jun 7 13:20:10 EDT 2008

When I said "code" I was referring to the build system as well as the
Haskell code.  "Just changing a Makefile" is not a trivial issue, and
even if it was, it would still be a change that somebody would have to
make in all packages that depend on the code (and possibly, in a bunch
of packages that depend on _these_ packages to chanage version numbers
in dependecies).

And how would you setup the dependencies in the new code?  You would
either have to use an extra flag, just for the one Zipper module, or
you would need to have some kind of disjunction of dependencies.
Something like:
  (containers >= X) or (containers > Y and containers < X and Zipper)
where X is the new code got moved to containers, and Y is a known good
version of containers.  Does Cabal even support this kind of thing?

Of course, things like that are unavoidable in general, the question
is how often do we want to ask programmers to deal with this kind of
thing.  I think that it is completely unwarranted in the case of the
single ZIpper module.

On Fri, Jun 6, 2008 at 5:52 PM, Chris Smith <cdsmith at gmail.com> wrote:
> Iavor Diatchki wrote:
>> Or are we going to
>> require that it is already used by many people as a separate package,
>> and then we are going to ask everyone to change their code, so that they
>> can start using it from the new location?
> As an aside, I don't see why this would require anyone to change their
> code.  So long as people choose good module names, the movement of some
> module from one package to another at most changes a Makefile or .cabal
> file.  I actually rather like this about Haskell as it currently exists;
> third-party packages don't have to be isolated behemoths walled off by
> namespace issues.  In fact, there are good examples of cases where
> external packages define modules in Data.* module hierarchy with
> perfectly logical names.  The code is then entirely independent of
> packaging concerns.
> --
> Chris
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

More information about the Libraries mailing list