April 2007 - Haskell - Haskell.org

Software Engineering and Functional Programming (with Haskell)
by Sukit Tretriluxana 05 Apr '07

05 Apr '07

Hi all, I'm a Software Engineering (SE) Master's degree student at CMU. As part of the program, each of us needs to present a topic that's related to SE. I am picking Functional Programming with Haskell as the topic as I believe it has a lot of direct impact on SE due to its nature that requires a the whole new world of thinking process, design, analysis, development, testing, and deployment. Unfortunately my instructor disagrees that the topic is relevant. In his response, he mentioned that he will accept the topic only if I can prove the following. Haskell has been around for quite a while. To convince me, you'll have to give me references that I can read about nontrivial examples of significant software systems already built exclusively with Haskell which includes the software engineering principles applied in this environment and the software measures that demonstrate the claims. I welcome the opportunity for you to provide me with such in-depth research references to support your viewpoint. Straight of the bat, I have very limited visibility in terms of finding him the resources to prove this. I am wondering if any of you all here could shed some light where I can find a couple compelling evidences to convince him. In fact, my presentation topic is not specifically tied to Haskell but more to FP. So any resources that provide such information on FP in general would do as well. Thanks, Ed

5 5

ANNOUNCE: OmegaGB, Haskell Game Boy Emulator
by Bit Connor 04 Apr '07

04 Apr '07

OmegaGB is an emulator for the Nintendo Game Boy, written in pure haskell. It's in a very early state, and only barely shows the title screen of a few games. It uses gtk2hs for the user interface, but there is also a version that doesn't require gtk2hs and uses ascii art. The main problem I am having is getting decent performance. I have set up a darcs repository in the hopes of receiving advice or patches to improve performance. You can find more information about the program at the website: http://www.mutantlemon.com/omegagb/ The program works by maintaining a state of all of the gameboy hardware: cpu registers, memory, and internal timers for various interrupts and other things. A function is used to update the state: updateMachineDisplayFrame :: JoypadKeyStates -> ((RegisterStates, Memory), IrqStates) -> (Display, ((RegisterStates, Memory), IrqStates)) This approach does not give enough performance, and the emulator is not able to run in real time. I have experimented with replacing most of the state with mutable IORefs and an IOUArray for the memory. This gave approximately double the performance, but that is still only 10% of real time speed on my computer. And all this is still without emulating most of the GB graphics hardware, which will require quite a bit more computations. I originally started this project to explore whether haskell is really a capable language in the domain of performance critical applications. I think that with the right optimizations, OmegaGB will be able to do real time emulation. Unfortunately, I am not experienced enough to know what kind of optimizations to use. This is why I am calling out for help. Thanks, Bit Connor PS: Here is some of the profiling output from a typical run: total time = 174.10 secs (3482 ticks @ 50 ms) total alloc = 31,338,925,440 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc renderScanLine Machine 28.6 17.9 machineCpuExecute' Machine 12.6 11.4 tickHBlank Machine 9.1 21.1 tickHBlankMode0 Machine 6.3 13.7 executeInstruction Cpu 5.6 1.6 test02 GuiTest02 5.0 1.4 tickDIV Machine 4.7 13.1 irqUpdate Machine 3.4 0.8 transformIrq Machine 3.3 3.2 tickHBlankMode3 Machine 3.1 6.9 mcti Cpu 2.2 0.5 setRegState Machine 1.9 1.7 setReg2State Machine 1.7 1.8 doFromTo GuiDrawUtil 1.6 1.5 updateMachine Machine 1.4 0.5 updateMachineDisplayFrame Machine 1.3 0.5 writeFlags CpuExecution 1.2 0.3 fetchInstruction Machine 1.1 0.5

2 2

Articles on the value of strong typing
by Jacob Atzen 03 Apr '07

03 Apr '07

Hello list, I am a student at the IT University of Copenhagen doing my final thesis on Domain Specific Languages implemented as embedded languages in Ruby. As you might know Ruby uses a somewhat lax form of typing compared to Haskell which is apparently highly utilized for creating embedded DSL's, at least in the academic world. Additionally many of the articles on embedded languages in Haskell use the typing features of Haskell as an argument for using Haskell in this setting. This lead me to the question: Are there any scientific empirical studies of the values of static / stronger type systems as found in Haskell, C# or Java in real world settings? Or any studies comparing weaker type systems in terms of programmer efficiency, defect ratio, etc. I have been unable to find any such studies as it supposedly is "common knowledge" that strong type systems are of great value. Additionally the people I have asked the question was not aware of any such studies, so now I'm trying this list. Please note that I am looking for papers or articles, preferably from the academic community, and not personal opinions (as valid as they may be). -- Thank you, - Jacob Atzen

6 6

2nd IEEE International Workshop on Software Stability at Work (SSW 2007)
by E.Segura 03 Apr '07

03 Apr '07

The 2nd IEEE International Workshop on Software Stability at Work SSW 2007 Invitation Las Vegas, USA, August 13-15, 2007 (in conjunction with IEEE IRI 2007) http://www.sis.pitt.edu/~iri07/ (IEEE IRI 2007 Link) http://www.sis.pitt.edu/~iri07/wkshpCFP3.html (Main Link) http://www.engr.sjsu.edu/~fayad/workshops/IRI07-SSW (Workshop Link 2) http://www.vrlsoft.com/workshops/SSW07 (Workshop Link 3) Greetings, I would like to invite you to participate in The 2nd IEEE International Workshop on Software Stability at Work. (SSW 2007)" In conjunction with The 2007 IEEE International Conference on Information Reuse and Integration (http://www.sis.pitt.edu/~iri07/) which will take place in Las Vegas, Nevada, August 13-15, 2OO7 by submitting a paper or two before or on April 15, 2007. A call of papers for the workshop is enclosed and it can be found at: http://www.sis.pitt.edu/~iri07/wkshpCFP3.html (Main Link) http://www.engr.sjsu.edu/~fayad/workshops/IRI07-SSW (Workshop Link 2) http://www.vrlsoft.com/workshops/SSW07 (Workshop Link 3) Accepted papers will be published in the proceedings (EI Index) of the The 2007 IEEE International Conference on Information Reuse and Integration (IEEE IRI 2007). The workshop selected best papers will be published in online Journal of International Journal Of Patterns (IJOP). Looking forward to your submission and participation in the workshop! All the best, Cheers, Dr. M.E. Fayad (Chair) Dr. Rami Bahsoon (Co-Chair) Dr. Chia-Chu Chiang (Co-Chair) Dr. Shasha Wu (Co-Chair) -- ijop.org -- Powered by PHPlist, www.phplist.com --

1 0

CFP - 2nd IEEE International Workshop Towards Stable and Adaptable Software Architectures (SASA 2007)
by E. Segura 03 Apr '07

03 Apr '07

The 2nd IEEE International Workshop Towards Stable and Adaptable Software Architectures SASA 2007 Invitation Las Vegas, USA, August 13-15, 2007 (in conjunction with IEEE IRI 2007) http://www.sis.pitt.edu/~iri07/ (IEEE IRI 2007 Link) http://www.sis.pitt.edu/~iri07/wkshpCFP2.html (Workshop Link 1) http://www.engr.sjsu.edu/~fayad/workshops/SASA07 (Workshop Link 2) http://www.vrlsoft.com/workshops/SASA07 (Workshop Link 3) Greetings, I would like to invite you to participate in The 2nd IEEE International Workshop Towards Stable and Adaptable Software Architectures (SASA 2007)" In conjunction with The 2007 IEEE International Conference on Information Reuse and Integration (http://www.sis.pitt.edu/~iri07/) which will take place in Las Vegas, Nevada, August 13-15, 2OO7 by submitting a paper or two before or on April 15, 2007. A call of papers for the workshop is enclosed and it can be found at: http://www.sis.pitt.edu/~iri07/wkshpCFP2.html (Workshop Link 1) http://www.engr.sjsu.edu/~fayad/workshops/SASA07 (Workshop Link 2) http://www.vrlsoft.com/workshops/SASA07 (Workshop Link 3) Accepted papers will be published in the proceedings (EI Index) of the The 2007 IEEE International Conference on Information Reuse and Integration (IEEE IRI 2007). The workshop selected best papers will be published in online Journal of International Journal Of Patterns (IJOP). Looking forward to your submission and participation in the workshop! All the best, Cheers, Dr. M.E. Fayad (Chair) Dr. Rami Bahsoon (Co-Chair) Dr. Tarek Helmy (Co-Chair) Eduardo M. Segura (Co-Chair) -- ijop.org -- Powered by PHPlist, www.phplist.com --

1 0

Matlab/BLAS/LAPack and Re: [Haskell-cafe] Mathematics in Haskell Re: Why the Prelude must Die
by Alexander McPhail 03 Apr '07

03 Apr '07

Since I brought this up (search haskell' list) I should probably volunteer to help. If people agree I can coordinate an effort to build a mathematically sound hierarchy. Unfortunately my mathematical knowledge is less than ideal for this purpose (I am actively remedying this at university). However, if there is an administrative burden I volunteer to shoulder it. On a related note I have written a binding to Matlab data files and arrays if anyone is interested, and I am embarking on a project to bind to CBLAS and CLAPack. Vivian > > Jacques Carette wrote: > > > >> perhaps i was mistaken in thinking that there is a group of > >> math-interested haskellers out there discussing, developing, and > >> documenting the area? or perhaps that group needs introductory > >> tutorials presenting its work? > > My guess is that there are a number of people "waiting in > the wings", > > waiting for a critical mass of features to show up before really > > diving in. See http://www.cas.mcmaster.ca/plmms07/ > > for my reasons for being both interested and wary). > > > > Probably the simplest test case is the difficulties that people are > > (still) encountering doing matrix/vector algebra in Haskell. One > > either quickly encounters efficiency issues (although PArr might > > help), or typing issues (though many tricks are known, but not > > necessarily simple). Blitz++ and the STL contributed > heavily to C++ > > being taken seriously by people in the scientific computation > > community. Haskell has even more _potential_, but it is > definitely unrealised potential. > > > > I am one of those mathematicians "waiting in the wings." > Haskell looked > very appealing at first, and the type system seems perfect, > especially for > things like multilinear algebra where currying and duality is > fundamental. > I too was put off by the Num issues though--strange mixture > of sophisticated > category theory and lack of a sensible hierarchy of algebraic objects. > > However, I've decided I'm more interested in helping to fix > it than wait; > so count me in on an effort to make Haskell more > mathematical. For me that > probably starts with the semigroup/group/ring setup, and good > arbitrary-precision as well as approximate linear algebra support. > > -- > > I've been watching this thread for quite a while now, and it seems to > me that there is quite a bit of interest in at least working on a new > Prelude. I've also noticed a 'The Other Prelude' page on the wiki > [http://haskell.org/haskellwiki/The_Other_Prelude] and they seem to > have a start on this. So it seems that we should actually start this, > because people will contribute. Can somebody with good Cabal skills > and maybe access to darcs.haskell.org start a new library for people > to start patching? > > Bryan Burgers > > > > On Apr 2, 2007, at 3:24 PM, Andrzej Jaworski wrote: > > >> I too was put off by the Num issues though--strange mixture of > >> sophisticated > >> category theory and lack of a sensible hierarchy of algebraic > >> objects. > > > > Perhaps we should replace CT with lattice theoretic thinking (e.g. > > functor = monotonic > > function) before cleaning up the type-related mess? > > See: http://citeseer.ist.psu.edu/269479.html > > > >> so count me in on an effort to make Haskell more mathematical. > >> For me that > >> probably starts with the semigroup/group/ring setup, and good > >> arbitrary-precision as well as approximate linear algebra support. > > > > I agree: semigoups like lattices are everywhere. > > Then there could be a uniform treatment of linear algebra, > > polynomial equations, operator > > algebra, etc. So, perhaps haste is not a good advice here? > > > > -Andrzej > >

1 0

ANNOUNCE: new FGL version (April 2007)
by Martin Erwig 03 Apr '07

03 Apr '07

FGL - A Functional Graph Library, Version: April 2007 ===================================================== A new release of the Functional Graph Library for Haskell is available at: http://eecs.oregonstate.edu/~erwig/fgl/haskell/ This release fixes some bugs in the implementation of several basic inspection functions. -- Martin

2 1

haskell communities worthy of academic study?
by Claus Reinke 01 Apr '07

01 Apr '07

Asked how she had come to choose GHC as the topic for her award-nominated PhD dissertation, freshly graduated doctor of software archeology Simone Tolduso revealed: "At first, there were a few small curiosities that triggered my interest, like why were darcs patches sent to the cvs-ghc mailinglist, or why did GHC releases traditionally bundle the predecessor of the current Cabal version when the missing libraries depended on its successor? But then I looked into the repository, with its layers on layers of build systems, source formats, deprecation warnings, directory structure fragments, todo logs, broken builds resulting either from OS-tools advancing and playing havoc with the built-in assumptions of fragile build configurations or from multiple, partially completed, mutually incompatible heart-liver-and-lung transplants supporting the newest language extensions (which of course were all needed to build the compiler branch supporting said features, and whose documentation tended to be spread over user manual, API comments, mailing list threads, research papers, plus half a dozen different Wikis and ticket trackers), supported by often outdated documentation in a never-ending variety of formats, and I knew I had stumbled onto a goldmine. Not to mention remains of earlier projects (what were fptools, or libraries?), a variety of test and compilation languages (including Haskell, C, Perl, Python, alongside the usual scripting suspects), or the proliferation of sediment layers into user space by the simple, but ingeneous, means of binary incompatibility. In spite of its comparatively small size, the project was beginning to rival the complexities of other Microsoft products of the same period. In what seems to have been an attempt to push open source ideas to their logical conclusion, you actually had to guess at the right combination of versions for a number of independently evolving toolchains, libraries, OSes, and use those to bootstrap from a consistent snapshot of the compiler, library, and sometimes even tool sources, or nothing works - a situation which was later increasingly exacerbated by the dispersion of the Haskell Cabal replacing coordinated releases. Preliminary mining of the relevant mailinglist and bug tracker archives suggests that binary releases were mainly public data points used to indicate intermediate states of GHC _not_ suitable for specific applications (apart from the obligatory Cabal pre-version lacking the new features needed for installing the extra libraries, other examples include versions of Data.ByteString _not_ based on the famous paper, _not_ supporting essential optimisations, or _not_ supporting API safety fixes). So there seemed to be no way to avoid direct access to the source repositories with their associated build processes and toolchains. And let us not forget that, unlike the programmers at the time, we are in the fortunate situation of already having complete repositories for the pieces and dependencies involved. Finding matching versions is a non-trivial, but essentially combinatorial exercise, while for them, the process of building GHC would often have involved developing and submitting the patches that make up our repositories of all the pieces of software GHC builds depended on. We still haven't found the key that enabled the ancients to navigate this labyrinth and to keep their toolchains up to date while still making any progress in their daily work, not to mention recording such progress via darcs (in itself written in Haskell, and not free of troubles). Agent-based simulations of developer communities at arbitrary slices through the repositories show the majority of agents getting stuck in a recursive cycle of installing, debugging, and updating dependency chains without ever reaching a productive state, so we do know that we are missing some crucial information. Several of my correspondents have come to favour the somewhat controversial theory that the general programmer in those days must have been substantially more intelligent than people are today. And it does make sense, in a way - I mean, if anyone had been the slightest bit bothered by all this complexity, surely someone would have tried to simplify things? Of course, my work has not all been happy progress: for instance, while there really was an 'evil mangler', the equally persistent rumour that GHC was named after some scottish town has turned out to be a wild goose chase (cf Appendix GC); my colleagues in dirt archeology assure me there was no town called 'glorious'. The 'real' archeologists, as they call themselves, had a field day laughing about my gullability there. Still, there are so many burried treasures in this area - just waiting to be investigated." Dr Tolduso is currently working on a follow-on project, "Haskell by committee - design and syntax through the ages". Dept. of Software Archeology, University of New Atlantis (for immediate release)

4 3