On Wed, 25 May 2011 05:17:46 -0700, Stephen Tetley <stephen.tet...@gmail.com>
wrote:
Hi Ivan
Forks are good, no?
The Parsec experience has suggested to me at least, that new author's
"capping" another author's work by bumping up to a major version,
causes a significant difficulties even when the original author has
gone.
As for wl-pprint, it was a very tidy library in its original
implementation - it's a pity it now has name clashes with Applicative.
My feeling is that a new library in a new namespace with some
attention to new combinator names would be better.
At the risk of returning to a recurring theme that often comes up but never
gets resolved satisfactorily, I'd like to make a cabal proposal:
Add to the .cabal file the following optional field:
Related-package: ACTION NAME VERSION Information
- The first word is the ACTION and is one of: "Replaces", "Redesigns", "Extends", or
"Alternative".
- The second word is the NAME of the related package.
- The third word is the VERSION of the related package.
- Any additional text is information describing how the packages relate in
descriptive terms and could be a multi-line paragraph like the existing
Description: field.
There may be multiple "Related-package" entries specifying different packages
and actions.
Conceptually, the ACTION indicates:
- Replaces: This package is intended as a newer replacement to use instead
of the older package. It intends to provide all the functionality of the
existing package, although perhaps with API or dependency modifications and
will probably evolve to provide additional functionality as well (this is
probably what Ivan's new package would specify).
- Redesigns: This package is intended as a replacement for the older
package. It intends to provide similar functionality, but using a new approach
and the API (and probably dependencies) is expected to have significant
changes. An example of this would be Parsec2 and Parsec3.
- Alternative: This package is a horizontal replacement for the other
package providing the same type of functionality. The API or dependencies may
be a bit different (e.g. mtl and transformers would be Alternatives of each
other) but the overall intent of the package is the same. The Information
should describe the difference between the two.
- Extends: This package uses the previous package and extends it with
complementary functionality. For example, attoparsec-binary extends attoparsec.
I would suggest the ACTION be limited to known terms such as the above, whereas
the Information is free-form for more clarification. The VERSION is important
to know where the relationship was established, especially for a Replaces or
Alternative type of package where the reference package continues to evolve as
well.
The HackageDB could the provide this information in the description page of a package,
and it could even automatically cross-reference and supplement the referred package
descriptions, so that if you are looking at the Parsec2 page it will also show a section
"This package has a Redesign: parsec3. The redesign states:
...[Information]......". This type of information can help people know what the
alternatives are for various packages and a general understanding of the reason for the
proliferation of packages (without having to search haskell-cafe and stack-overflow
archives for some discussion that provided the justification/recommendations).
Thoughts?
--
-KQ
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
