Hi all I thought about these things too. My 2 cents:
Am Sun, 27 Jul 2008 15:58:40 -0400 schrieb Paul Hudak <[EMAIL PROTECTED]>: > 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. Yep, I got started with the original package in minutes (I was especially impressed about TestHaskore, and the OS-specific midiplayers.) With the darcs version I had to tweak the .cabal file, remove some subdirs that didnt compile with that modified .cabal, had to install a lot of additional packages etcpp. That was really cumbersome. > 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). I had a discussion on the last point with a colluege at our department (Software-Engineering) recently. In OO-Software, I typically think in Components, Layers and Interfaces and the goal for good design is to minimize dependencies so you can exchange components later, or locate problems easily. One thing I have no idea about in FP is how to make a good design for a large program. In Java, or C++ there is a quite good mapping from the language to the filesystem: Java: Classes and Interfaces -> *.java, Packages -> Directories C/C++: Headers -> *.h, Implementation -> *.c One "concept" is mapped to some kind of file. In Haskell there are only "modules" and I cant grasp the corresponding "concepts" and how they should be mapped to files: 1) A (arbitrary?) collection of functions -> One file? What functions belong together? 2) A generic Type -> One file (this seems to be the way Henning went, explained here: http://www.haskell.org/haskellwiki/Qualified_names ) what functions belong to the Type? And how should I organize the other functions ? Or the other way around ( since we have only "modules"): What makes up a module, why not put everything in one module, or do one module per function (as extrema) ? What is the "right" way? I would be really happy if someone could direct me to some books or stuff on the web where such things are discussed. Because this is really really interesting ... (perhaps mail me privately ...) Oops, back to haskore: In general I like Hennings approach, but perhaps it's to much "OO-style"? And perhaps there are parts of the code that cannot be organized in this way. Perhaps we need different kinds of modules ? In any way one needs explicit "guidelines", then any contributors can adhere to them, and any occasional (or heavy) src-code reader will know what a construct like (e.g.) "Music.T.fromSomething something" means. > > Will the entire Haskore continue to be released as one package, or as > > multiple packages? > > One package. As I mention above: for me, a clean design has very few and clear dependencies, for me part of the problem with the current codebase is that some things are too complicated. Therefore, I would like to think about splitting off some things that IMHO do note belong to the "core" of haskore. I think especially of these interfaces to "sound-generators": I would like to use haskore on top of a standard ghc installation and simply play some MIDI. Other components like complicated interfaces to csound and supercollider, or lilypond, or interesting apps that _use_ haskore to create or analyse specific kinds of music could very well be their own projects. haskells infrastructure in these regards is quite good nowadays (hackage, mkcabal etc) so it shoudl not be a problem of ressources... BTW: We could use the wiki-pages to organize the efforts, I like todo-lists, overviews, mission statements, code conventions, links to documentation (tutorial and haddock) etc. I would do it, but I will wait for some statements from Henning ;-) Best regards, Sebastian. _______________________________________________ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
