EdisonAPI 1.2.1 → 1.2.2

raw patch · 4 files changed

+19/−216 lines, 4 filesdep −haskell98dep ~basesetup-changedPVP: major bump suggested

API removals or changes: PVP suggests a major version bump

Dependencies removed: haskell98

Dependency ranges changed: base

API changes (from Hackage documentation)

Files

• COPYRIGHT +1/−1
• EdisonAPI.cabal +17/−8
• README +0/−206
• Setup.hs +1/−1

@@ -1,6 +1,6 @@ Copyright (c) 1998-1999 Chris Okasaki Portions Copyright (c) 2002 Andrew Bromage-Portions Copyright (c) 2006 Robert Dockins+Portions Copyright (c) 2006-2007 Robert Dockins Portions Copyright (c) 2006 David F. Place Portions Copyright (c) 2006 Ross Paterson and Ralf Hinze 

@@ -1,15 +1,25 @@+Build-type:     Simple Name:           EdisonAPI-Version:        1.2.1+Version:        1.2.2 License:        OtherLicense License-File:   COPYRIGHT Author:         Chris Okasaki Maintainer:     robdockins AT fastmail DOT fm-Synopsis:       A library of efficient, purely-functional data structures (API)+Synopsis:       A library of efficent, purely-functional data structures (API) Category:       Data Structures-Stability:      stable+Homepage:	http://www.cs.princeton.edu/~rdockins/edison/home/+Stability:      Stable Description:-   This package provides the typeclasses that form the Edison-   API and other common utility modules.+   Edison is a library of purely functional data structures written by+   Chris Okasaki.  It is named after Thomas Alva Edison and for the+   mnemonic value EDiSon (Efficent Data Structures).+   Edison provides several families of abstractions, each with+   multiple implementations.  The main abstractions provided by Edison are:+   Sequences such as stacks, queues, and dequeues;+   Collections such as sets, bags and heaps; and+   Associative Collections such as finite maps and priority queues+    where the priority and element are distinct.+ Hs-Source-Dirs: src Exposed-modules:      Data.Edison@@ -21,11 +31,10 @@      Data.Edison.Seq      Data.Edison.Seq.ListSeq Build-Depends:-     base >= 1.0,-     haskell98 >= 1.0,+     base >= 2.0 && < 5,      mtl >= 1.0 Extensions:      MultiParamTypeClasses      FunctionalDependencies      UndecidableInstances-Ghc-Options: -funbox-strict-fields -fwarn-incomplete-patterns -O2+Ghc-Options: -funbox-strict-fields -fwarn-incomplete-patterns

@@ -1,206 +0,0 @@-Edison: A Library of Efficient Data Structures-Version: 1.2.1-Dec 15, 2006---About Edison--------------------------Edison is a library of purely function data structures for Haskell-originally written by Chris Okasaki.  Conceptually, it consists of two-things:-  1) A set of type classes defining data the following data structure-     abstractions: "sequences", "collections" and "associative collections"-  2) Multiple concrete implementations of each of the abstractions.--In theory, either component may be used independently of the other.--This release is an update to (hopefully) make Edison easier to use,-mostly by updating Edison to use the most current Haskell tools.-The following major changes have been made since version 1.1, which-was released in 1999.--  * Typeclasses updated to use fundeps (by Andrew Bromage)-  * Implementation of ternary search tries (by Andrew Bromage)-  * Modules renamed to use the hierarchical module extension-  * Documentation haddockized-  * Source moved to a darcs repository-  * Build system cabalized-  * Unit tests integrated into a single driver program which exercises-    all the concrete implementations shipped with Edison-  * Multiple additions to the APIs (mostly the associated collection API)---Hopefully, these changes will make Edison more accessible than it has-been previously.---License--------------------------Edison is released under an MIT style license.  See the COPYRIGHT-file for details.----Building Edison--------------------------Edison is distributed as a set of related Cabal packages.-The EdisonAPI package contains the main API typeclass definitions.-The EdisonCore package provides the main concrete implementations;-this package depends on the EdisonAPI package.  The Edison-test-package contains the test suite and depends on both packages.--You may either manually invoke cabal for each of the sub-packages-as appropriate, or you may use the included Makefile, which will-build and install the EdisonAPI and EdisonCore packages-automaticly.--If you do not have an executable named 'runhaskell' on your search-path, you will need to edit the Makefile and set the RUNHS variable-appropriately (or run the cabal commands manually).--If you wish to build the API docs, you will first need to-build the relevant package and type the following command in-the package subdirectory:--runhaskell Setup.hs haddock---A Note about Cabal versions--------------------------------------This version of edison builds correctly with Cabal version 1.1.4,-which is shipped with GHC 6.4.2.  To build on earlier versions,-it should suffice to:--s/UndecidableInstances/AllowUndecidableInstances/ -s/Hs-Source-Dirs:/Hs-Source-Dir:/--in the .cabal files.----Notes on portability-------------------------Short version:--Edison is expected to work correctly on recent GHC and Hugs (with-extensions enabled).  Other Haskell implementations may also work, but-have not been tested.---Longer version:--Edison uses a number of extensions beyond Haskell 98, the current-official Haskell standard.  These include:--  * Multi-parameter typeclasses-  * Functional dependencies-  * Undecidable instances--In all cases, these extensions are used to allow the typeclass-abstractions to be expressed.  These extensions are fairly popular-and seem likely to make it in some form into a Haskell standard-(hopefully in the not too distant future).--Currently, Edison builds and runs correctly under GHC and Hugs.-More specificly, most development and testing has been done with-GHC 6.4.1, and the test suite builds and runs to completion with no errors.-With Hugs (March 2005 release) and the '-98' option, all of the core Edison-data structures should work correctly.  Unfortunately, the test suite will-not load, due to differences in Hugs' and GHC's implementations of -multi-parameter typeclasses.--As the extensions used are not recent developments, I also expect that less-recent versions of GHC and Hugs will also work.  Other implementations-may also work correctly with Edison, but this has not been tested.----The Story on Edison Packages-------------------------------------Cabal is a nice tool for building and distributing Haskell projects.  However,-it has the slightly undesirable property that the "Package" unit is the atomic-unit of compilation, documentation and of dependency resolution.  In order to-support implementations which have varying external dependencies, Edison has been-split into multiple cabal sub-packages, which cooperate.  The root package is-named 'EdisonAPI' and it contains the typeclass specifications, together with-extensive documentation and a few utility classes.  'EdisonAPI' essentially-represents a design contract.  The 'EdisonCore' package contains core Edison-implementations.  These implementations have no dependencies beyond the standard-libraries.  Other implementation modules are planned: these other modules-may have dependencies on eg, Adiran Hay's AVL tree implementation or Don-Stewart's Fast Packed String, etc.  Additionally there is a unit test package.-Currently it is tied to the 'EdisonCore' package, but in the future it will-provide basic unit testing capabilities for extended implementations as well.-----Edison Versioning--------------------------As the maintainer of Edison, I take API stability very seriously.  My goal is-that programs written against Edison will not suffer from version drift.-However, I also wish to allow Edison to incorporate new ideas and evolve into a-better way to use data structures in Haskell.  In order to help accommodate these-somewhat opposing goals, I have adopted the following versioning scheme.  Respect-the versioning scheme, and you should have no compatibility problems.---Each Edison release number is composed of four components:--  xxx.yyy.zzz.www-   ^   ^   ^   ^-   |   |   |   |-   |   |   |   +------ patch level-   |   |   +---------- API version number-   |   +-------------- minor version number-   +------------------ major version number---The API version number and/or patch level may be omitted for brevity.  When-omitted, they are assumed to be 0.--I have adopted the (pre-2.6) Linux kernel versioning scheme for major and-minor numbers: the major number is incremented at major updates (ie, something-on the order of total API re-engineering or complete rewrites).  Minor numbers-represent "branches" of development.--Releases with even minor numbers are "stable" releases (0 is considered even).-For example, the Edison 1.2 release is a stable release. Even numbered releases-will have stable user-visible APIs; my goal is that any program compiled against-an Edison stable release will work correctly for all later Edison releases with-the same major and minor version numbers.  This means that API changes will be-limited to additions.  However, I intend that even additions be rare, and they will-only be considered with compelling evidence that the lack of the feature in question-inhibits desirable use cases.  The user-visible behavior of an implementation will-only be changed if it was originally in violation of the contract (ie, a bug).--*NOTE*-THE EXACT BEHAVIOR OF AMBIGUOUS OPERATIONS IS NOT CONSIDERED USER-VISIBLE BEHAVIOR,-nor is the behavior of unsafe operations when used in violation of their preconditions.-Ambiguous operations may change their behavior in stable releases as long as such-changes still obey the design contract.---Releases with odd minor numbers are "development" branches.  Such releases-are branched from the immediately preceding stable release minor number.-For example, the Edison 1.3 development branch will be forked from the Edison 1.2-release family.  No guarantees are made about the user-visible APIs for development-branches.  API operations may be added, deleted, or have the terms of their design-contracts altered in development branches, and implementations may freely change their-behavior.  Eventually development branches are stabilized and transform into the next-even-numbered stable release.--For both even and odd minor numbers, the third component represents the "API version".-Any change to the API will cause a bump in the API version number.  For stable branches,-this should be fairly rare; for odd branches, it may occur rather frequently.--The fourth component is incremented for each official release whenever the first three-components are not altered.  Two Edison versions which differ only in their patch level-should have identical APIs.

@@ -1,3 +1,3 @@ #!/usr/bin/env runhaskell import Distribution.Simple-main = defaultMainWithHooks defaultUserHooks+main = defaultMain