EdisonCore 1.2.1 → 1.2.1.1
raw patch · 3 files changed
+20/−221 lines, 3 filesdep +arraydep +containersdep ~QuickCheckdep ~basedep ~haskell98
Dependencies added: array, containers
Dependency ranges changed: QuickCheck, base, haskell98, mtl
Files
- COPYRIGHT +1/−1
- EdisonCore.cabal +19/−14
- README +0/−206
COPYRIGHT view
@@ -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
EdisonCore.cabal view
@@ -1,20 +1,25 @@ Name: EdisonCore-Version: 1.2.1+Cabal-Version: >= 1.2+Build-Type: Simple+Version: 1.2.1.1 License: OtherLicense License-File: COPYRIGHT Author: Chris Okasaki Maintainer: robdockins AT fastmail DOT fm-Synopsis: A library of efficient, purely-functional data structures (Core Implementations)+Synopsis: A library of efficent, purely-functional data structures (Core Implementations) Category: Data Structures-Stability: stable+Homepage: http://www.cs.princeton.edu/~rdockins/edison/home/+Stability: Stable Description: This package provides the core Edison data structure implementations, including multiple sequence, set, bag, and finite map concrete implementations with various performance characteristics. The- implementations in this package have no dependencies other than- those commonly bundled with Haskell compilers.-Hs-Source-Dirs: src-Exposed-modules:+ implementations in this package have no dependencies other than those+ commonly bundled with Haskell compilers.++Library+ Hs-Source-Dirs: src+ Exposed-modules: Data.Edison.Assoc.Defaults Data.Edison.Assoc.AssocList Data.Edison.Assoc.PatriciaLoMap@@ -41,15 +46,15 @@ Data.Edison.Seq.RevSeq Data.Edison.Seq.SimpleQueue Data.Edison.Seq.SizedSeq-Build-Depends:- base >= 1.0,- haskell98 >= 1.0,- mtl >= 1.0,- QuickCheck == 1.0,+ Build-Depends:+ base, haskell98, mtl, QuickCheck, EdisonAPI == 1.2.1-Extensions:+ if impl( ghc >= 6.8 )+ Build-Depends:+ containers, array+ Extensions: MultiParamTypeClasses FunctionalDependencies UndecidableInstances CPP-Ghc-Options: -funbox-strict-fields -fwarn-incomplete-patterns -O2+ Ghc-Options: -funbox-strict-fields -fwarn-incomplete-patterns -O2 -fglasgow-exts
− README
@@ -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.