- Haskell - Haskell.org

Strafunski
by Christopher Brown 03 Apr '06

03 Apr '06

Hi, I am trying to use Strafunski with GHC 6.5 and was wondering if someone could help me. I have all the instances for Term and Typeable defined for my data types, but when I try to compile with GHC 6.5 I get lots of "overlapping instance" errors. In particular, it seems the instances I am using (generated by DrIFT) are clashing with the ones in Data.Typeable. Is there a way I can fix this? Also I have heard that it is possible to add "deriving Typeable" to each data type and I don't need to use the instances I have created. However, now it complains that it can't find instances for Term - but I can't derive from Term. Does anyone have any ideas how I can get Strafunski working with GHC 6.5? Thanks. Chris. Christopher Brown PhD Student, University of Kent. http://www.cs.kent.ac.uk/people/rpg/cmb21/ cmb21(a)kent.ac.uk

2 2

Haskell Weekly News: April 03, 2006
by dons＠cse.unsw.edu.au 02 Apr '06

02 Apr '06

Haskell Weekly News: April 03, 2006 Greetings, and thanks for reading issue 31 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. Headlines also go to [4]haskell.org. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ 3. http://sequence.complete.org/node/feed 4. http://haskell.org/ Haskell' This section covers activity on [5]Haskell' standardisation process. * FFI, 'safe' and 'unsafe', parts [6]1 and [7]2 * [8]newtype deriving * [9]Standardise deepSeq * [10]MVar semantics * [11]Thread priorities * Concurrency, parts [12]1, [13]2 and [14]3. * [15]FD improvement, variable quantification & generalised propagation 5. http://hackage.haskell.org/trac/haskell-prime 6. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1089 7. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1178 8. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1145 9. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1151 10. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1152 11. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1155 12. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1174 13. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1179 14. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1183 15. http://article.gmane.org/gmane.comp.lang.haskell.prime/1193 Discussion * Mobile Haskell. Dmitri O.Kondratiev [16]asked about running Haskell on a PowerPC Windows Mobile device. John Meacham [17]responded with some interesting notes regarding Haskell on the Nokia 770. 16. http://article.gmane.org/gmane.comp.lang.haskell.cafe/12165 17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/12173 * GHCi as a debugger. Lemmih [18]wrote on "whether it would be possible to call GHCi from interpreted byte-code. It turned out that it was, and it was even fairly easy". Great stuff! 18. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/14166 * Clearer reflection. Krasimir Angelov [19]proposed some ideas for a better Reflection API for Haskell. Currently we have Typeable and Data classes which provide some pieces of information about the data types at runtime. typeOf provides runtime information about the type of a given variable. dataTypeOf provides almost the same information but with some extras. There is some overlap between the TypeRep and DataType types. Some pieces of information you can get from the TypeRep, other from the DataType and some other from both of them. There is also an information which is inaccessible from either TypeRep and DataType. 19. http://article.gmane.org/gmane.comp.lang.haskell.libraries/4500 Quotes of the Week Seen on #haskell: Lemmih:: calling an out-of-scope function isn't as easy as I had hoped TuringTest:: They got it work in Haskell without understanding Haskell. It is quite an achievement, of some description. tennin:: [very #haskell] anyone know of any good books/papers on the application of category theory to databases? Smokey`:: I can't believe it, Haskell is starting to draw me away from C++... I swore i'd never turn from C++ Contributing to HWN You can help us create new editions of this newsletter. Please see the [20]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 20. http://haskell.org/haskellwiki/HWN

1 0

Scheme Workshop 2006
by Robby Findler 31 Mar '06

31 Mar '06

Dear all, I'm writing to let you know about the upcoming Scheme and Functional Programming workshop -- specifically that the submission deadline is June 9, about 2 months from now. The workshop will be held Portland Oregon on September 17, the day before ICFP. We look forward you your submissions! Best, Robby ============================================================ The purpose of the workshop is to discuss experience with and future developments of the Scheme programming language, as well as general aspects of computer science loosely centered on the general theme of Scheme. http://scheme2006.cs.uchicago.edu/ IMPORTANT DATES Submission deadline: Friday June 9 Author notification: Friday June 30 Final versions due: Friday July 14 Workshop: Sunday September 17, the day before ICFP CALL FOR PAPERS Papers are invited concerning all aspects of the design, semantics, theory, application, implementation, and teaching of Scheme. Some example areas include (but are not limited to): * Language design Scheme's simple syntactic framework and minimal static semantics has historically made the language an attractive lab bench for the development and experimentation of novel language features and mechanisms. Topics in this area include modules systems, exceptions, control mechanisms, distributed programming, concurrency and synchronisation, macro systems, and objects. Past, present and future SRFIs are welcome. * Type systems Static analyses for dynamic type systems, type systems that bridge the gap between static and dynamic types, static systems with type dynamic extensions, weak typing. * Theory Formal semantics, calculi, correctness of analyses and transformations, lambda calculus. * Implementation Compilers, runtime systems, optimisation, virtual machines, resource management, interpreters, foreign-function and operating system interfaces, partial evaluation, program analysis and transformation, embedded systems, and generally implementations with novel or noteworthy features. * Program-development environments and tools The Lisp and Scheme family of programming languages have traditionally been the source of innovative program-development environments. Authors working on these issues are encouraged to submit papers describing their technologies. Topics include profilers, tracers, debuggers, program understanding tools, performance and conformance test suites and tools. * Education Scheme has achieved widespread use as a tool for teaching computer science. Papers on the theory and practice of teaching with Scheme are invited. * Agile Methogologies Dynamic languages seem to share a symbiotic relationship with agile software development methodologies. In particular, the dynamic type checking of Scheme clearly benefits from test-driven development, but that same dynamic checking makes the software more easily adapted to changing requirements. * Applications and experience Interesting applications which illuminate aspects of Scheme experience with Scheme in commercial or real-world contexts; use of Scheme as an extension or scripting language. * Scheme pearls Elegant, instructive examples of functional programming. A Scheme pearl submission is a special category, and should be a short paper presenting an algorithm, idea or programming device using Scheme in a way that is particularly elegant. Following the model of earlier workshops, experience papers need not necessarily report original research results; they may instead report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! ORGANIZERS Program Chair Robby Findler, University of Chicago Program Committee John Clements, Cal Poly Sebastian Egner, Philips Research Robby Findler, University of Chicago Cormac Flanagan, UC Santa Cruz Erik Hilsdale, Google Eric Knauel, University of Tubingen Steering Committee William D. Clinger, Northeastern University Marc Feeley, University of Montreal Robby Findler, University of Chicago Dan Friedman, Indiana University Christian Queinnec, University Paris 6 Manuel Serrano, INRIA Olin Shivers, Georgia Tech Mitchell Wand, Northeastern University

1 0

Network advice needed
by Andreas Marth 31 Mar '06

31 Mar '06

Hallo! While I am not a Haskell newbie I am a network newbie and need your advice. A few years ago I coded some business logic in Haskell which is used in an application. The application mainly consists of a GUI which calls the Haskell program. The whole application is installed at the computer it is used on. Now it shall be possible to use it from any computer within the company net. (They use Windows and any kind of scripting or ActiveX is okay when needed.) Because response time is an issue I think a client/server solution is not feasible. What I need to know now is if it is possible to pull the application from a server and run it locally. What would be required? What is the way to go? Which kind of complications are to be expected? (To clarify a bit more I am not concerned about the GUI that will be reimplemented - probably in JAVA - I am concerned about the business logic.) Any help, hints, thoughts are really appreciated. :-) Andreas

2 1

CFP: Multithreading in Hardware and Software... TV06, post CAV workshop Aug 21-22, 2006
by Simon Marlow 31 Mar '06

31 Mar '06

[posting on behalf of Ganesh <ganesh(a)cs.utah.edu>] Workshop on Multithreading in Hardware and Software: Formal Approaches to Design and Verification TV 2006 A FLoC'06 / CAV Affiliated Workshop August 21-22, 2006, Seattle, WA Scope of Workshop The use of threading is already widespread, and will experience explosive growth moving into the future, given that tomorrow's performance / energy goals will be met through the increased use of threads and "multicores" (chip level multiprocessors). Unfortunately, the correctness problems in this arena are daunting, as well as are far from being solved. TV06 invites papers addressing the tussle between correctness, reliability, and performance in this space. It is clear that well-engineered solutions in this space will require paying adequate attention to several areas, including (but clearly not limited to): * analysis, testing, and verification techniques for threaded systems * experience building reliable and high-performance threaded systems * case studies of verifying threaded systems * language design and formal semantics pertaining to threading * logics and models of concurrency, including transaction memories * model checking multithreaded programs * shared memory consistency models at the hardware, language, and library levels * runtime verification for multithreaded programs and systems * threading issues in multicore systems and chips * designing formally well-specified high-performance thread libraries * understanding threading issues in specific areas such as high-performance computing (e.g., OpenMP), general purpose libraries (e.g., PThreads), and languages (e.g., C#, Java) We invite researchers and engineers working on all aspects of threading, especially the above, to submit a paper as per specifications below. TV06 is hosted by the premier CAV conference, which is part of FLoC 2006 (Federated Logic Conference). which encompasses 6 conferences and over 30 workshops, and will be held in August in Seattle. Please visit http://research.microsoft.com/floc06 for a full description of these events, as well as a catchy poster. This location, setting, and timing promises ample opportunities for ample intellectual and social interactions. We especially welcome practitioners and system designers to describe a roadmap of priorities, given that many challenging problems need to be solved in short order. Invited Speakers * Vijay Saraswat, IBM T.J. Watson Research Labs, Yorktown Heights, NY * Maurice Herlihy, Brown University, Providence, RI Program Committee * Arvind MIT CSAIL, USA * Hans Boehm HP, USA * Ching Tsun Chou Intel,Santa Clara,USA * Byron Cook Microsoft Research, Cambridge,UK * Robert P. Cook Georgia Southern University, USA * Cormac Flanagan UC Santa Cruz, USA * Mike Kirby University of Utah, USA * Timothy G. Mattson Intel, DuPont, USA * John Regehr University of Utah, USA * Scott Stoller SUNY at Stony Brook, USA * Shaz Qadeer Microsoft Research, USA * Yue Yang Microsoft, USA Important Dates Deadline for submissions: May 1, 2006 Notification of acceptance: June 9, 2006 Final manuscript due: July 15, 2006 Workshop: August 21-22, 2006 Paper Submission Submissions must be made electronically in PDF format, following the instructions on the TV06 Web site, which is http://www.cs.utah.edu/tv06. Submissions must use the ACM SIG Proceedings format with letter-size paper (see http://www.acm.org/sigs/pubs/proceed/template.html for details). Two categories of papers will be accepted: * long : 10-15 pages, describing in-depth investigations * short: 4-6 pages, describing a tool, position statement, etc. Papers should contain a concise abstract of approximately 150 words, clearly stating the nature of the contributions. At least one author of each accepted paper is required to register for TV06 (registration information coming soon at http://www.cs.utah.edu/tv06) as well as give a presentation at the workshop. Papers should be self-contained, and describe original work, but may be based on (and may contain) portions from a previously published paper, provided it also includes substantial new work. A journal special issue based on selected papers from this workshop is under consideration. Email questions, if any, to tv06(a)cs.utah.edu Organizers Ganesh Gopalakrishnan, School of Computing, University of Utah, Salt Lake City, UT 84112, USA John W. O'Leary, Strategic CAD Labs, Intel Corporation, Hillsboro, OR, USA -- For questions and other information, please email tv06(a)cs.utah.edu or check http://www.cs.utah.edu/tv06 ---

1 0

(CFP) Workshop on Logic-based Programming Environments
by Wim Vanhoof 31 Mar '06

31 Mar '06

----------------------------------------------------------- WLPE' 06 - CALL FOR PAPERS Workshop on Logic-based Methods in Programming Environments (satellite workshop of ICLP’06) August 16, 2006 Seattle (Washington), USA http://lml.ls.fi.upm.es/~susana/Conferences/WLPE06/ ----------------------------------------------------------- Aim and Scope ------------- The 16th Workshop on Logic-based methods in Programming Environments will take place in Seattle (Washington), USA, as a satellite workshop of ICLP'06, the 22th International Conference on Logic Programming. This workshop will continue the series of successful international workshops on logic programming environments held in Ohio, USA (1989), Eilat, Israel (1990), Paris, France (1991), Washington, USA (1992), Vancouver, Canada (1993), Santa Margherita Ligure, Italy (1994), Portland, USA (1995), Leuven, Belgium and Port Jefferson, USA (1997), Las Cruces, USA (1999), Paphos, Cyprus (2001), Copenhagen, Denmark (2002), Mumbai, India (2003), Saint Malo, France (2004) and Sitges, Spain (2005). The workshop aims at providing an informal meeting for the researchers working on logic-based tools for development and analysis of programs. This year we want to emphasize two aspects: on one hand we want to discuss the presentation, pragmatics and experiences of such tools; on the other one, we want to shift the traditional focus on environment tools for logic programming to logic-based environmental tools for programming in general. Specific topic areas relevant to the workshop include, but are not limited to: * tools for debugging and testing * tools for static and dynamic analysis * systems for program verification and validation * code generation from specifications * termination and non-termination analyzers * reasoners on occurs-check freeness and determinacy * profilers and performance analyzers * systems for types and modes analyzes * module systems * optimization tools. In addition to papers describing more conceptual work on environmental tools, we solicit papers describing the implementation of and experimentation with such tools. Submission guidelines --------------------- Length of papers can range from 2 to 17 pages, preferably in LNCS format. Authors are requested to submit their paper using the submission webpage at http://vampire.cs.man.ac.uk/WLPE-06/ Alternatively, authors can send a copy of their paper (in pdf or ps format) to the workshop coordinator (wva(a)info.fundp.ac.be) An informal proceedings will be published as a technical report of the University of Namur and distributed at the workshop. After the workshop, the proceedings will be publicly available on-line in the Computing Research Repository (CoRR). Important dates --------------- Submission: May 15, 2006 Notification: June 15, 2006 Camera-ready: July 10, 2006 Workshop: August 16, 2006 Workshop organizers ------------------- Susana Muñoz-Hernández (Universidad Politécnica de Madrid, Spain) Wim Vanhoof (coordinator) (Univeristy of Namur, Belgium) Program Committee ----------------- María Alpuente (Universidad Politécnica de Valencia, Spain) Mireille Ducassé (INSA/IRISA, Rennes, France) John Gallager (Roskilde University, Denmark) María García de la Banda (Monash University, Australia) José Manuel Gómez-Pérez (ISOCO Madrid, Spain) Gopal Gupta (University of Texas at Dallas, U.S.A) Moreno Falaschi (Università di Udine, Italy) Pat Hill (University of Leeds, U.K.) Michael Leuschel (Heinrich-Heine-Universitat Düsseldorf, Germany) Fred Mesnard (Université de La Réunion, France) Susana Muñoz-Hernández (Universidad Politécnica de Madrid, Spain) Kostis Sagonas (Uppsala University, Sweden) Alexander Serebrenik (Technische Universiteit Eindhoven, The Netherlands) Zoltan Somogyi (University of Melbourne, Australia) Wim Vanhoof (University of Namur, Belgium)

1 0

RE: [Haskell] Haskell as a disruptive technology?
by Tim Harris 30 Mar '06

30 Mar '06

Hi, > I had to chuckle at this one in particular, since the implementation > of transactions in Haskell was based on experiences with prototype > software TM in Java and C#! In truth, Haskell adds a few things to > the mix that make STM dramatically better. Most important are STM > and STRef---it's no longer possible to accidentally commingle > transactional and non-transactional access to the same storage, or to > do I/O in the middle of a transaction by mistake. I don't think that the Haskell STM implementation is as closely based on the Java / C# work as it appears... Before Simon Marlow's SMP extensions we relied on there being only a single thread running in an STM operation in the RTS at any time, so the STMCommit operation could run without interference. Even with SMP support, and the possibility of multiple threads in the RTS, we've never aimed for non-blocking progress because we assume that the number of OS threads will be tuned to the number of available cores. As well as the use of the STM monad to separate out IO/tx/non-tx access, I think the big thing that we learnt from the Haskell work was the retry/orElse abstractions for composable blocking. BTW, I've put a copy of another recent STM-Haskell paper online at http://research.microsoft.com/~tharris/drafts/2006-invariants-draft.pdf. It's about defining invariants over transactionally-managed data structures -- feedback's very welcome! Cheers, Tim

2 1

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

29 Mar '06

Sorry to have been out of the discussion for so long. I've just upgraded to Fedora Core 5. Multimedia and the proprietary NVidia 3d driver have yet to be added, but at least email is now up. Robert Dockins wrote: > FWIW, I'd like to voice my agreement with this view. The hardware manufacturers are > hard at work building the perfect niche for Haskell -- all of commodity desktop computing! > Moore's law is still packing more transistors onto the silicon, and it seems like people have > run out of ideas for what to do with them, so they just start duplicating cores ;-) 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. Sorry. I really wish I could agree, but I don't. Like I said earlier, it doesn't matter how good your technology is, if you go up against the incumbents you will lose every time. Here is how I see it playing out: 1: People start to complain that effective use of multicore CPUs is very hard. The trade press editorialize on the problem: is this the end of the computer performance revolution. 2: Sun and Microsoft bring out support for STM in Java and C# respectively. The trade press editorialize on this wonderful new technology. Haskell may get a mention as the original prototype, "but now its ready for mainstream use". 3: The Java and C# support turns out to be unsafe, partial and inefficient. Long articles are written in the trade press about how to make sure your programs use it properly. Programmers with proven experience in these flavours get big pay rises. 4: We sit around wondering what happened. "Its not fair: we had this years ago and done right. Why is everyone using the broken stuff?" I've seen this happen before, with Eiffel. From around 1989 I was telling people that Eiffel was the way to go. It was better than C++ in every way, and garbage collection was a great win. Nobody would try Eiffel. They said GC was inefficient, and anyway real programmers didn't need it. Then Java came out, and a couple of years later a project manager who had previously ignored my enthusiasm about Eiffel told me how great it was to have GC in Java, and how few bugs they were getting as a result. I managed a weak smile. Getting good concurrency support on SMP is important, of course. But its not going to beat Java and C++ on their home turf. That is the point of disruptive technologies: they start out in a niche and then spread. First find a niche. One of the lessons Clayton Christensen draws from his study of disruptive technologies is that the market for them is unknown and unknowable. As a rule you don't identify and analyse it, you notice it by accident and have the agility to exploit it. One example from the book: Honda initially tried to sell its motorcycles by competing head-on with incumbents like Harley Davidson. They got nowhere, but when the frustrated marketroids took their sample bikes out on the sand dunes for some fun, friends asked where they could get one. So the marketroids got a few as a favour to their friends. And *their* friends asked for some too, and it eventually dawned on Honda that there was a whole new market for light recreational sport bikes that their model was just right for. So it is with Haskell. I've spent some time looking for niches where Haskell might fit. I've got a couple of ideas (test harnesses and experimental simulations), but if I or anyone else laid out a marketing programme based on those ideas then it would very likely be wrong in some important way. What we need to do is to look for lots of similar sorts of software: marginal opportunities that are poorly served by the big incumbents, but where Haskell can shine. When you find something like that then push Haskell and see if it fits. If you win then spread the word, and get your new converts to do the same *in their speciality*. Then we will be going places. Paul.

2 1

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 28 Mar '06

28 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