March 2006 - Haskell - Haskell.org

Re: [Haskell] Haskell as a disruptive technology?
by Paul Johnson 29 Mar '06

29 Mar '06

Neil Mitchell wrote: >>> - Larger memory footprint > > > You are talking about GHC, not Haskell. Take a look at nhc98, which > has a small memory footprint. I don't want to get into a compiler flame war. The fact is that if you want to do huge datasets or very fast computation (the two tend to go together) then Haskell is the wrong language. This isn't an attack on Haskell, its a straightforward look at the strengths and weaknesses of the language. >> - Little integration with GUI tools. No "Visual Haskell" or "Borland >> Haskell" equivalents. > > > http://www.haskell.org/visualhaskell/ - indeed there is :) I've never used Visual Haskell, but from the web page two things stand out: 1: Its version 0.0. This is not for production use. 2: Its just a programming environment. The point I was making was about integration with GUI tools. You can't (AFAIK) draw a dialog box and then tie each button to a Haskell function in the IO monad. >> - Little integration with databases. > > > There are quite a few Haskell DB programs, I've never used any, but > they do exist. I have used HSQL, and it does what it does perfectly competently. But it requires a bunch of boilerplate code in the IO monad for every query. There are higher level libraries that build nice type-safe stuff on top of this, but they don't seem to be production strength yet. Remember that this is not about what Haskell could or should be in the future, its about what Haskell is right now. If you start a Haskell development project then this is the reality that you face. Now, we could try to fix these "deficiencies". That means playing catch-up with the entire infrastructure that has been erected around conventional languages. We will simply never succeed. Sure, we can probably do it with a 10th the manpower of the conventional languages, but they have 100 times our manpower to throw at the problem. Or we can play to our strengths by looking for markets where the negatives don't matter, or matter less than the positives. Haskell offers a value proposition that is very different to conventional languages. There is likely to be a market out there that is poorly served by conventional languages, but where Haskell will fit very nicely. All we have to do is find it and target it. Hmmm. I wonder about simulation and testing. Some time ago I asked here about doing discrete event simulation, and I have succeeded. (Unfortunately the resulting code is owned by my employer, so I can't share it). QuickCheck has shown a new approach to testing. Testing of stateful stuff using this approach would require a simulation of the thing to be tested. This might be a winning proposition. Paul.

14 18

Haskell Weekly News: March 27, 2006
by dons＠cse.unsw.edu.au 29 Mar '06

29 Mar '06

Haskell Weekly News: March 27, 2006 Greetings, and thanks for reading issue 30 of HWN, a weekly newsletter covering developments in the Haskell community. Each Monday, new editions are posted to [1]the Haskell mailing list and to [2]The Haskell Sequence. [3]RSS is also available. A busy, exciting week! 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ 3. http://sequence.complete.org/node/feed Announcements * monadLib 2.0. Iavor Diatchki [4]announced the release of monadLib 2.0 -- library of monad transformers for Haskell. 'monadLib' is a descendent of 'mtl', the monad template library that is distributed with most Haskell implementations. Check out the [5]library web page. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/13460 5. http://www.csee.ogi.edu/~diatchki/monadLib * Text.Regex.Lazy (0.33). Chris Kuklewicz [6]announced the release of [7]Text.Regex.Lazy. This is an alternative to Text.Regex along with some enhancements. GHC's Text.Regex marshals the data back and forth to C arrays, to call libc. This is far too slow (and strict). This module understands regular expression Strings via a Parsec parser and creates an internal data structure (Text.Regex.Lazy.Pattern). This is then transformed into a Parsec parser to process the input String, or into a DFA table for matching against the input String or FastPackedString. The input string is consumed lazily, so it may be an arbitrarily long or infinite source. 6. http://article.gmane.org/gmane.comp.lang.haskell.libraries/4464 7. http://sourceforge.net/projects/lazy-regex * HDBC 0.99.2. John Goerzen [8]released HDBC 0.99.2, along with 0.99.2 versions of all database backends. John says "If things go well, after a few weeks of testing, this version will become HDBC 1.0.0". [9]HDBC is a multi-database interface system for Haskell. 8. http://article.gmane.org/gmane.comp.lang.haskell.general/13504 9. http://quux.org/devel/hdbc * Planet Haskell. Isaac Jones [10]asked if someone could volunteer to set up "Planet Haskell", an RSS feed aggregator in the style of Planet Debian, Planet Gnome or Planet Perl. Happily, Antti-Juhani Kaijanaho stepped up, and now Planet Haskell is live at [11]http://planet.haskell.org. Antti-Juhani asks that any Haskell people with blogs submit their feed urls to him, so check it out! 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/12033 11. http://planet.haskell.org/ * Haskell on Gentoo Linux Duncan Coutts [12]writes that GHC 6.4.1 has been marked stable on x86, amd64, sparc and ppc, for [13]Gentoo Linux. (We also support ppc64, alpha and hppa.) Gentoo also has a collection of over 30 Haskell libraries and tools. There is also a #gentoo-haskell [14]irc channel on freenode. 12. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/9557 13. http://packages.gentoo.org/search/?sstring=ghc 14. http://haskell.org/haskellwiki/IRC_channel * Concurrent Yhc. The Yhc dev team [15]reports that Yhc now includes support for concurrency! The interface is the same as Concurrent GHC. Currently only + Control.Concurrent + Control.Concurrent.MVar + Control.Concurrent.QSem are implemented, however many other abstractions can be written in Haskell in terms of MVars. 15. http://www.haskell.org//pipermail/yhc/2006-March/000085.html * GHC 6.4.2 Release Candidates Simon Marlow [16]announced that GHC was moving into release-candidate mode for version 6.4.2. [17]Grab a snapshot and try it out. The available builds are: x86_64-unknown-linux (Fedora Core 5), i386-unknown-linux (glibc 2.3 era), and Windows (i386-unknown-mingw32). Barring any serious hiccups, the release should be out in a couple of weeks. 16. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/9588 17. http://www.haskell.org/ghc/dist/stable/dist/ * HaRe 0.3. Sneaking out without us noticing, in January, a [18]new snapshot of HaRe, the Haskell refactoring tool, was released. This snapshot of HaRe 0.3 is now compatible with the latest GHC and Programmatica. New refactorings have also been added. 18. http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html Haskell' This section covers activity on [19]Haskell' standardisation process. * [20]Bringing discusison to a close * [21]Time to focus discussion * [22]Collections interface * [23]MonadPlus reform * [24]Strict tuples * [25]seq as a class method * [26]Alternatives to . for composition * [27]Concurrency * [28]Pre-emptive or co-operative concurrency * [29]Liberal type synonyms 19. http://hackage.haskell.org/trac/haskell-prime 20. http://article.gmane.org/gmane.comp.lang.haskell.prime/1084 21. http://thread.gmane.org/gmane.comp.lang.haskell.prime/992 22. http://article.gmane.org/gmane.comp.lang.haskell.prime/1003 23. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1005 24. http://thread.gmane.org/gmane.comp.lang.haskell.prime/995 25. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1033 26. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1041 27. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1057 28. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1057 29. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1075 Discussion * Disruptive Haskell. Paul Johnson [30]forked a long discussion on how Haskell can be seen as a disruptive technology, and what Haskell's "brand" might be. Many interesting contributions were made. 30. http://thread.gmane.org/gmane.comp.lang.haskell.general/13475 * Bit streaming Haskell. Per Gustafsson, having made a proposal to extend the Erlang `binary' data type from being a sequence of bytes (a byte stream) to being a sequence of bits (a bitstream), with the ability to do pattern matching at the bit level, [31]asked for help writing efficient (and beautiful) Haskell versions of his [32]bitstream benchmarks. Several improved programs were submitted, bringing the Haskell code into line with the OCaml and Erlang entries. 31. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/12040 32. http://bitbenches.infogami.com/ Quotes of the Week Pseudonym's condensed LtU guide to the static types vs dynamic types debate: * Haskell-vs-Scheme is an issue on which reasonable people differ. * Ruby-vs-Java is an issue on which unreasonable people differ. Everything else is details. :-) Seen on #haskell: shapr :: Science News had an article about a tribe of isolated villagers in Brazil that don't have recursion or indirection in their language. Contributing to HWN You can help us create new editions of this newsletter. Please see the [33]contributing information, send stories to dons -at- cse.unsw.edu.au. The darcs repository is available at darcs get http://www.cse.unsw.edu.au/~dons/code/hwn 33. http://haskell.org/haskellwiki/HWN

1 0

ANN: HDBC 0.99.2
by John Goerzen 28 Mar '06

28 Mar '06

Hello, I'm pleased to (at long last) announce the release of HDBC version 0.99.2, along with 0.99.2 versions of all database backends. If things go well, after a few weeks of testing, this version will become HDBC 1.0.0. HDBC is a multi-database interface system for Haskell -- more on it below. Since 0.99.0, several major things have been updated or enhanced: * Complete rework of memory management system. * Standardized memory management system for all database backends. * Support for querying metadata (type, size, etc.) about columns both in result sets and in database tables * Support for querying the level of transaction support in the underlying DB * ODBC driver has support for working with databases such as MySQL that don't support transactions * Testsuite enhancements for all the above I believe that these modifications will make HDBC suitable as a full-fledged backend for HaskellDB. HDBC is available from: http://quux.org/devel/hdbc gopher://quux.org/1/devel/hdbc Version 0.99.2 has also been uploaded to Debian unstable. Features of HDBC ---------------- * Ability to use replacable parameters to let one query be executed multiple times (eliminates the need for an escape function) * Ability to access returned rows by column number * Ability to read data from the SQL server on-demand rather than reading the entire result set up front * HUnit testsuite for each backend driver * Well-defined standard API and easy backend driver implementation * Lazy reading of the entire result set (think hGetContents, but for the results of SELECT) (see sFetchAllRows) * Support for translation between Haskell and SQL types * Support for querying database server properties * Add-on package (hdbc-missingh) to integrate with MissingH, providing a database backend for AnyDBM. * Support for querying metadata such as column names. In addition, there is extensive documentation for HDBC. Backend drivers exist for Sqlite v3, PostgreSQL, and ODBC. MySQL is supported via the ODBC driver and the ODBC testsuite passes against MySQL (saving the transaction tests, which aren't supported by MySQL). In addition, there is a odbc-missingh package that can turn and HDBC database into an AnyDBM backend for MissingH. (Sqlite3 could be very handy there) Darcs repositories are available for all of this at http://darcs.complete.org/ Thanks, -- John

1 0

unicode/internalization issues
by Bulat Ziganshin 28 Mar '06

28 Mar '06

Hello haskell-prime, i've planned some time ago to open unicode/internalization wiki page, what reflects current state of the art in this area. here is the information i have, please add/correct me if i don't know something or wrong. 1. Char supports full Unicode range (about million of chars) instead of just 8-bit ASCII: implemented in GHC 6.0 and Hugs 2005 (i'm not sure about exact versions) 2. Character classification/convertion routines in Data.Char: all Unicode chars managed properly starting from GHC 6.4 and Hugs 2005. Author of this update, Dmitry Golubovsky, also provides it as additional lib for ghc 6.2.2, and i think it is possible to extend his work to work with any compiler supporting "wide" Chars. 3. Unicode support in I/O routines, i.e. ability to read/write UTF-8 encoded files and files what use other Unicode byte encodings: not implemented in any compiler, afaik, but there are 3rd-party libs: Streams library, New I/O library, and even CharIO module from jhc sources 4. Support for UTF-8 encoded source files: implemented in ghc 6.5 and jhc. afaik, ghc's support is more advanced because it uses abovementioned routines to classify Chars, so you can use any national characters in identifiers according to their case, and all other symbols in operators. because ghc 6.5 supports ONLY utf-8 encoded source files, these creates some problems when compiling files created for previous versions of ghc (or for other compilers) and using ASCII encoding with national (>chr 127) chars in comments and especially string literals. GHC team asked their users for best solution of this problem if i don't mentioned here any issues regarding unicode/internalization, please add this -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

RE: [Haskell] Haskell as a disruptive technology?
by Tim Docker 28 Mar '06

28 Mar '06

Robert Dockins wrote: > All we have to do is be ready for it when it arrives. > When people see that, using Haskell, they can write programs using 1) > fewer man-hours with 2) fewer bugs which 3) scale effortlessly to > highly parallel hardware to beat the pants off C/C++/Java/what-have- > you, they'll be beating down the doors to get it. > I'd love to see Haskell on highly concurrent hardware becoming more > of a reality: Haskell on the Cell is a great idea; I'd love to see > Haskell over MPI (using YHC bytecode maybe?); Haskell-over-GPU (you > know you like it!); and of course, SMP Haskell is also interesting. > One of the things I love about Haskell is that the language > definition transcends execution strategy/environment. I think your enthusiasm outstrips reality a bit here. STM appear to provide a much improved model for concurrent programming on shared memory architectures (I say "appears" here because I've read the papers but haven't used it). Whilst this applies directly to the limited scalability of new multi-core desktop machines, I don't think it's going to provide huge benefits to the more scalable architectures based upon message passing (eg MPI and Cell). I'd be pleased to be corrected, but I'm not aware of any mainstream haskell libs/extensions that make implementing message passing concurrent systems fundamentally easier than in other languages. Tim

1 0

ANNOUNCE: lhs2tex-1.11
by Andres Loeh 27 Mar '06

27 Mar '06

lhs2TeX version 1.11 ==================== We are pleased to announce a new release of lhs2TeX, a preprocessor to generate LaTeX code from literate Haskell sources. lhs2TeX includes the following features: * Highly customized output. * Liberal parser -- no restriction to Haskell 98. * Generate multiple versions of a program or document from a single source. * Active documents: call Haskell to generate parts of the document (useful for papers on Haskell). * A manual explaining all the important aspects of lhs2TeX. Changes (w.r.t. lhs2TeX 1.9) ---------------------------- [Note that 1.10 has never been released to avoid confusion with some privately distributed versions.] * Specification code is now handled correctly (that is, ignored) in the "code" and "newcode" styles. * Comments and Pragmas are handled in a better way by the "newcode" style. * There are some new forms of implicit formatting directives. * The LaTeX code produced in the poly style looks slightly more beautiful. * There is a new Library section, containing some frequently used formatting directives. * Generation of file/linenumber directives in the produced LaTeX code, for Stefan Wehr's "adjust" tool. Based on a patch submitted by Stefan Wehr. * lhs2TeX can now replace ghc's literate preprocessor. * Improved efficiency of \eval and \perform (to call ghci or hugs from lhs2TeX documents). Requirements and Download ------------------------- A source distribution that should be suitable for Unix-based environments is available from http://www.iai.uni-bonn.de/~loeh/lhs2tex/ It has been verified to build on Linux and MacOSX. Binaries will be made available on request. You need a recent version of GHC (6.4.1 is tested, 6.2.2 might work) to build lhs2TeX, and, of course, you need a TeX distribution to make use of lhs2TeX's output. The program includes a configuration that is suitable for use with LaTeX. In theory, there should be no problem to generate code for other TeX flavors, such as plainTeX or ConTeXt. Happy lhs2TeXing, Andres Loeh and Ralf Hinze lhs2TeX(a)andres-loeh.de ralf(a)informatik.uni-bonn.de

2 1

Haskell as a disruptive technology?
by Paul Johnson 27 Mar '06

27 Mar '06

I'm reading Clayton Christensen's classic book "The Inventor's Dilemma". The gist, for those who haven't heard of it, is that successful large companies are tuned for "sustaining" technology improvements: small incremental improvements. But every so often a "disruptive" technology comes along that leaves the incumbents flat-footed. Christensen presents a detailed case study of the hard drive industry, where at every stage in the shrinkage of disk drives (14" mainframe, 8" minicomputer, 5.25" microcomputer, 3.5" for early laptops) the incumbent companies could not see the attraction of the smaller size drives to be sold in small markets for small margins. Instead they pursued premium customers in the high end of the computer industry. Something similar happened to steam shovels. Hydraulic diggers were initially small and low value, sold to farmers and builders to dig trenches. Steam shovels were sold to quarries and big construction projects, and that was where the money was. The steam shovel companies subsequently went bust and hydraulics now rules the world. The problem for the incumbents was never the technology: both disk drive makers and steam shovel manufacturers were capable of mastering and using the new technology. The problem was identifying and targetting markets. The term "disruptive market" might actually be more descriptive. For example, most camera manufacturers have made the switch to digital. The technology is radically different, but the market is just the same. On the other hand the smaller disk drives were essentially the same technology, but sold to a very different market with different value networks and propositions. Which leads me to consider Haskell. Haskell has all the signs of a disruptive technology: a different value proposition which stacks up badly against current industry norms, but has attributes that are likely to be valued by someone somewhere. The question is, who? Haskell's current value proposition, relative to "standard" programming languages (as I see it): + Faster development (4-10 times) + More reliable software (hard to quantify, but probably a similar improvement) + Good concurrency support with STM. + Good support for loosely structured data such as XML. - Slower programs (Shootout efforts notwithstanding) - Larger memory footprint - Little integration with GUI tools. No "Visual Haskell" or "Borland Haskell" equivalents. - Little integration with databases. - Little integration with mainstream software development. No analysis or design methods or notations. Haskell development appears to be primarily a matter of paying a bunch of very bright developers to cut code. - Concerns about support and maintenance. Those bright developers may not be around in the long term. So: we seem to be looking for a market that is currently under-served by incumbent languages because its not worth bothering with. It doesn't need complex databases (although a few ODBC queries are OK) or lots of GUI dialogs. The software is likely to be run on comparitively few computers (so that development cost is more important than hardware cost), or else do something that is not very computationally intensive. It is likely to have some degree of concurrency or soft real time (to use that STM capability), and have a short lifespan so that maintenance is not too much of a concern. Bear in mind that this market may well not use software at present, or it may be using computers in a way that is not thought of as "programming". For example they may be using horribly complex Excel macros to do stuff. The current pain point may actually be reliability and verification rather than development cost. They probably think that hiring programmers to solve their problems is beyond their budget, and attempts to sell them a conventional development contract will fail to even get a hearing. I don't know what this market might be. Does anyone have any ideas? Paul.

7 6

Re: [Haskell] Haskell as a markup language
by oleg＠pobox.com 25 Mar '06

25 Mar '06

shelarcy wrote: > SXML can add useful function for macro, like this; > > (define (M:link keyword url) > `(a (@ (href ,url)) ,keyword)) > > (define (M:link_amazon keyword asin) > (M:link keyword > `("http://www.amazon.co.jp/exec/obidos/ASIN/" ,asin "/someone_id/"))) > > (define (M:book keyword urn) > `((cite ,(M:link keyword `("urn:isbn:" ,urn))) > " (" ,(M:link_amazon "Amazon" urn) ") ")) > > and M:link can use SXML code in its parameter any place; > > ,(M:link `("SXML " (em "can write") " this.") "http://foo.bar/") HSXML can do all this, too (modulo replacement of the round parentheses with a pair of square ones). First, we need `Transparent' SPAN: the grouping of SPAN-level elements. TSPAN is an administrative element, which is precisely equivalent to the sequence of SPAN-level elements in its content. It is useful as a return value from a function, if a function needs to return several SPAN-level elements. The body of TSPAN has the content Inline, and the TSPAN element itself is in the Inline context. TSPAN is the `inline' analogue of TDIV (which works in the block context). > newtype TSPAN a = TSPAN a deriving Show > tspan x = build (as_inline . HW . TSPAN . rev'apppend HNil) nil_inline x > > instance RenderInline b => RenderInline (HW CT_inline (TSPAN b)) where > render_inline f (HW (TSPAN body)) = render_inline f body We can now write > link url body = a (attr [href (URL url)]) body > > link_amazon asin = > link (concat ["http://www.amazon.co.jp/exec/obidos/ASIN/",asin, > "/someone_id/"]) which is the close analogue of the SXML code above, only the 'body' argument is the last one. That seems to be more consistent, although tastes may vary. we can write a simple test > test1 = as_block (p [[link_amazon "123.456" "Amazon book"]]) where the body of the link is a simple string. But we can make it a bit more complex: > test2 = as_block (p [[link_amazon "123.456" [[tspan "Amazon" "book"]]]]) In fact, we can use arbitrary _inline_ markup in the body of the link: > book urn body = as_block $ > p [[link ("urn:isbn:" ++ urn) body]] > "(" [[link_amazon urn [[tspan [[em "Amazon"]] nosp ".com"]]]] ")" > test3 = book "123.456" "Amazon book" Again, the body of the 'book' doesn't have to be a simple string. We can use arbitrary _inline_ markup. > test4 = book "123.456" > [[tspan "HSXML" [[em [[strong "can"]] "write"]] "this," "too."]] But the following leads to the type error ``Couldn't match `CT_inline' against `CT_block''' -- testb = book "123.456" -- [[h1 "HSXML" [[em [[strong "can"]] "write"]] "this," "too."]] Indeed, the h1 element is a block rather than inline element. Rendering of test4 above > test4h :: IO () = runHTMLRender $ render test4 gives the expected output. Perhaps we should move to Cafe for further discussion?

2 2

[CFP] 2006 ACM SIGPLAN Workshop on ML
by Francois Pottier 23 Mar '06

23 Mar '06

********************************************************************* * The 2006 ACM SIGPLAN Workshop on ML * * * * September 16, 2006 * * * * Colocated with the 11th ACM SIGPLAN * * International Conference on Functional Programming (ICFP 2006), * * Portland, Oregon. * * * * Call for Papers * * * * http://gallium.inria.fr/ml2006/ * ********************************************************************* Important dates * Submission deadline: Saturday 3rd June 2006. * Notification of acceptance: Saturday 8th July 2006. * Final paper due: Saturday 29th July 2006. Scope The ML family of programming languages, whose most popular variants are SML and OCaml, has inspired a tremendous amount of computer science research, both practical and theoretical, and ML continues to underpin a variety of applications, ranging from compilers and theorem provers to low-level system software. This workshop aims to provide a forum for discussion and research on existing and future ML and ML-like languages. We seek papers on any ML-related topic, including (but not limited to): * applications. * extensions: objects, classes, concurrency, distribution and mobility, semi-structured data handling, etc. * type systems: inference, modules, specification, error reporting, etc. * implementation: compilers, interpreters, partial evaluators, garbage collectors, etc. * environments: libraries, tools, editors, debuggers, cross-language interoperability, etc. * semantics. Both experimental and theoretical papers are welcome. Each paper should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. In order to encourage lively discussion, submitted papers may describe work in progress. Papers must be submitted in either PDF format or as PostScript documents that are interpretable by Ghostscript. They must be printable on US Letter sized paper. Papers should be formatted using the ACM SIGPLAN style guidelines available at http://www.acm.org/sigs/sigplan/authorInformation.htm The length should be no more than 12 pages. Proceedings will be published by ACM Press and will appear in the ACM Digital Library. Authors of accepted papers will be required to sign the ACM copyright form. General Chairs and Program Chairs Andrew Kennedy Microsoft Research Ltd, 7 JJ Thomson Ave, Cambridge CB3 0FB, UK akenn(a)microsoft.com François Pottier INRIA Rocquencourt BP 105 78153 Le Chesnay Cedex FRANCE francois.pottier(a)inria.fr Programme Committee Derek Dreyer (Toyota Technological Institute at Chicago) Matthew Fluet (Cornell University) John Harrison (Intel Corporation) Haruo Hosoya (University of Tokyo) Andrew Kennedy (Microsoft Research Cambridge, co-chair) Eugenio Moggi (Università di Genova) Michael Norrish (National ICT Australia) François Pottier (INRIA Rocquencourt, co-chair) Ian Stark (University of Edinburgh) Alley Stoughton (Kansas State University) Jérôme Vouillon (CNRS and Université Paris 7) Stephanie Weirich (University of Pennsylvania)

1 0

Re: haskell.org libraries and tools page needs some fixing
by Bulat Ziganshin 22 Mar '06

22 Mar '06

Hello Björn, Wednesday, March 22, 2006, 1:35:42 PM, you wrote: BB> I recently wanted to add some libraries to BB> http://www.haskell.org/haskellwiki/Libraries_and_tools and noticed a BB> number of problems. there is also HCAR report. my thoughts is what we should create some central repository including libs/apps/papers/communities and so on and replace both this page and HCAR with it. then anyone should include himself here and edit the info as progress does. i also created Library/Streams as possible part of this future enciclopedy, having in mind that Library page will list all libs documented on haskellwiki. another interesting place which should list libs is hackage repository i think that we should discuss this question and develop a common place where everyone will list his libs/apps/... and document it as much as he wants -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1