On Sun, Jul 27, 2008 at 03:58:40PM -0400, Paul Hudak wrote: > John Lato wrote: >> Do you know yet what format this refactoring will take? > > First of all, I should make it clear that we don't intend to eliminate > anything. But I (and many of my students) believe that darcs Haskore is > currently unwieldy for a newcomer to grasp. This can be partly > alleviated by tutorial material, but I believe that the problem is more > deeply rooted. In particular, we would like to: > > * Reconsider some of the basic premises in the design of core Haskore. > * Revisit the organization of Haskore (in terms of the core, media > types, interfaces, etc). > * Reconsider some of the coding conventions (such as the use of > generic types named "T" in each module). > > In addition, there are certain things missing in the overall design that > we would like to add -- most notable for me is real-time MIDI. > >> Will the >> entire Haskore continue to be released as one package, or as multiple >> packages? > > One package.
i personally think that haskore will be usable for more projects and problem domains if the process of splitting it into smaller, more palatable packages, is not abandoned. just a few examples: * most of the file i/o (most notably midi) code could be immediately useful for many other projects * type classes for pitched, durational, temporal and other entities are not only useful in algorithmic music composition, but, if revised a little and extended appropriately, also in structural analysis of symbolically notated music and feature extraction from recorded/notated music in general * some of the underlying principles and data structures for sequential and parallel composition, event lists, etc. can be useful in other contexts i feel that for many tasks haskore is quite big a hammer, and while there's no one size that fits all, i believe that identifiying sub-package that can be factored out (with clearly defined interfaces) would also be benefitial for the internal design of haskore itself. <sk> _______________________________________________ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
