January 2006 - Haskell

Haskell': Kicking off the process of defining the next Haskell standard.
by Isaac Jones 21 Jan '06

21 Jan '06

let haskell' = succ haskell98 in Announcing the Haskell' ("Haskell-Prime") process. A short time ago, I asked for volunteers to help with the next Haskell standard. A brave group has spoken up, and we've organized ourselves into a committee in order to coordinate the community's work. It will be the committee's task to bring together the very best ideas and work of the broader community in an "open-source" way, and to fill in any gaps in order to make Haskell' as coherent and elegant as Haskell 98. Our task is broadly defined by our mission statement: The Haskell programming language is more-or-less divided into two "branches". The Haskell 98 standard is the "stable" branch of the language, and that has been a big success. A lot of progress has been made over the last few years in the "research" branch of the Haskell language. It is constantly advancing, and we feel that it is time for a new standard which reflects those advancements. Haskell' will be a conservative refinement of Haskell 98. It will be the work of this committee to adopt a set of language extensions and modifications and to standardize a new set of libraries. We will strive to only include tried-and-true language features, and to define them at least as rigorously as Haskell 98 was defined. This standard will reflect the realities of developing practical applications in the Haskell language. We will work closely with the rest of the Haskell community to create this standard. Your Haskell' Committee is as follows (slightly munged email addresses follow): * Manuel M T Chakravarty <chak at cse.unsw.edu.au> * John Goerzen <jgoerzen at complete.org> * Bastiaan Heeren <bastiaan at cs.uu.nl> * Isaac Jones <ijones at galois.com> * John Launchbury <john at galois.com> * Andres Loeh <loeh at iai.uni-bonn.de> * Simon Marlow <simonmar at microsoft.com> * John Meacham <john at repetae.net> * Ravi Nanavati <ravi at bluespec.com> * Henrik Nilsson <nhn at cs.nott.ac.uk> * Ross Paterson <ross at soi.city.ac.uk> * Simon Peyton-Jones <simonpj at microsoft.com> * Don Stewart <dons at cse.unsw.edu.au> * Audrey Tang <autrijus at gmail.com> * Simon J. Thompson <S.J.Thompson at kent.ac.uk> * Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> * Stephanie Weirich <sweirich at cis.upenn.edu> The editors are Isaac Jones and John Launchbury. Feel free to contact any of us with any concerns or questions. If you don't know who to direct your questions to, email Isaac Jones ijones(a)syntaxpolice.org. Community involvement is vital to our task, and there will be a way for members of the community to make formal proposals. In the opening phases, please use these more informal resources to help us coordinate Haskell': * The haskell-prime mailing list. All technical discussion will take place here, or (if other meetings take place) be reported here. Anyone can subscribe, and any subscriber can post questions and comments, and participate in discussions. Anyone can read the list archives. http://haskell.org/mailman/listinfo/haskell-prime * A wiki / issue tracking system to document consensus and to track ongoing tasks. This system is publicly readable, but only committee writable so that we may present it as the "official" output of the committee. If you ever feel that the wiki is not accurate as to the consensus, please alert the committee! http://hackage.haskell.org/trac/haskell-prime * A darcs code repository for experiments, proposed libraries,and complex examples. darcs is a decentralized system, so anyone can use it, but patches should be sent to Isaac Jones: http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode Please join us in making Haskell' a success. your, Haskell' Committee p.s. Please feel free to forward this announcement to appropriate forums.

1 0

Re: [Haskell] Modelling languages for FP (like UML for OO)
by David Barton 19 Jan '06

19 Jan '06

Philippa Cowderoy and Mads Lindstrom wrote: ----- Original Message ----- From: "Philippa Cowderoy" <flippa(a)flippac.org> To: "Mads Lindstrøm" <mads_lindstroem(a)yahoo.dk> Cc: <haskell(a)haskell.org> Sent: Thursday, January 19, 2006 8:16 AM Subject: Re: [Haskell] Modelling languages for FP (like UML for OO) On Thu, 19 Jan 2006, Mads [ISO-8859-1] Lindstrøm wrote: > Hi all > > In object-oriented programming, UML is used to model programs. In > functional programming (especially Haskell) we use ??? > Haskell :-) > I am mainly interested in the macro level. That is modules, classes, > class instances, ... Not in modellering the internals of a function. > I tend to just write the equivalent haskell code with the function definitions left out. I suspect the only thing that can really be gained with a more graphical language is drawing dependancy lines between modules and the like - though I was never big on the formalised modelling languages in the first place, so I may not be the best person to conclude that. ------------------------------------------------------- I do not wish to take away anything from Philippa's reply, but I do wish to toot my own project. Dr. Perry Alexander and myself are in the final stages of moving a Systems Level Design Language (SLDL) to standardization. It is called Rosetta, and is suited to the kind of modeling you are referring to (among other things). It is logic based rather than lamda calculus based, but the "execution subset" that is coming to be a kind of defacto standard (as opposed to the standard itself) is pretty much Haskell --- the CADSTONE product is called R-Haskell, as it translates that subset directly into Haskell. More information may be found at http://www.sldl.org And, by the way, we at EDAptive Computing are looking for someone to work on our own Rosetta projects, particularly with direct experience with theorem provers and model checkers --- using as much as designing and implementing. If anyone is interested, or has any questions about Rosetta, by all means drop me a line. Dave Barton EDAptive Computing

3 2

Re: [Haskell] Simple IO Regions
by Sean Seefried 19 Jan '06

19 Jan '06

> Dominic Steinitz wrote: >> Can someone give an explanation of how the marks get built up? > > Suppose we have a class TypeEq a b so that the constraint TypeEq holds > whenever a and b are the same. Then the type Int and the type > TypeEq a Int => a > are kind of equivalent, right? The HList library plays many tricks > like that. The idea is that we can replace a definite type with a type > variable subject to some constraint (which we can fix later on). > In some respects, constraints are more convenient: they float, their > order does not matter, their duplicates are automatically > eliminated. Just what we need to build a set... > It ``follows'' then that instead of building the union of types, we > can build the union of constraints. The latter operation is trivial: > the typechecker does that all the time. If we restrict the scope of > the type variable by quantification, the scope of the corresponding > constraint is likewise restricted. The quantification also builds > eigen-variables (which are distinct from anything else) -- so we get > 'gensym' on the type level for free. That is all there is to it... Olge, I found this explanation really useful. I was wondering if you could explain to me what you mean by eigen-variable though? Sean

2 1

Bluespec, Inc. is seeking full-time software engineers
by Ravi Nanavati 18 Jan '06

18 Jan '06

Introduction: Bluespec, Inc. is a hardware design startup based in Waltham, Massachusetts that is building the next generation of Electronic Design Automation (EDA) tools. Bluespec's toolset, which is based on functional programming technology, delivers a high-level design and verification environment to current Verilog and VHDL designers of ASICs and FPGAs. Bluespec is the first high-level synthesis product that accelerates the design cycle and reduces verification costs while retaining the ability to deliver no-compromise hardware. Bluespec's technical team includes the noted programming-language luminaries Rishiyur Nikhil and Joe Stoy. Join Bluespec and be part of what's next in silicon design! For further details, please visit our website: www.bluespec.com Positions: Multiple openings for both entry-level and senior software engineers Roles and responsibilities: - Software engineers have end-to-end ownership of features and components within Bluespec's hardware synthesis and simulation toolset - starting with definition and continuing through architecture, implementation, testing and documentation. - They work directly with customers to resolve their critical technical issues. When necessary, they are also responsible for training new customers on the Bluespec toolset and being a "first contact" for customer support. - Engineers also must develop a strong, customer-focused understanding of Bluespec's product suite. They apply that understanding to developing prototype designs to flesh out new capabilities as well as testing and benchmarking existing features. - Engineers are also expected to be flexible and adapt to changing roles and responsibilities over time as the technical and business needs of the company evolve. Requirements: - BS/MS/Ph.D degree with Computer Science or Electrical Engineering as a major - Strong programming background with a wide variety of languages (languages of specific interest include Haskell, C, Tcl/Tk and Perl) - Functional programming experience strongly preferred - Hardware design experience strongly preferred - Knowledge of Verilog/VHDL/SystemVerilog/SystemC is a plus - Knowledge of current EDA products is a plus - Strong communication, leadership and interpersonal skills - Ability to thrive in a dynamic, rapidly-changing environment - Working knowledge of Linux/UNIX/Windows Where to Apply: Applicants should send resumes to skp(a)bluespec.com (Sathyam Pattanam, VP Engineering) or careers(a)bluespec.com (Human Resources). Principals only - no agencies, please.

1 0

RE: [Haskell] Simple IO Regions
by Simon Peyton-Jones 18 Jan '06

18 Jan '06

I really like the way you use a set of constraints (IN m1 ms, IN m2 ms, IN m3 ms) to maintain the set of marks. Previously I've thought of using a nested tuple type (m1, (m2, (m3 ()))) to maintain the set, but that is far less convenient. Very neat. Why do you need the instance IN () b ? Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of | oleg(a)pobox.com | Sent: 17 January 2006 10:13 | To: haskell(a)haskell.org | Subject: [Haskell] Simple IO Regions | | | This message shows a very simple implementation of Monadic Regions | (for the particular case of IO and reading the file). The technique | *statically* guarantees that neither a file handle nor any computation | involving the handle can leak outside of the region that created | it. Therefore, the handle can be safely closed (and its resources | disposed of) whenever control leaves the corresponding 'withFile' | block. Many handles can be open simultaneously, the type system | enforces the proper nesting of their regions. The technique has no | run-time overhead and induces no run-time errors. Unlike the previous | implementation of monadic regions, only the basic extensions | (higher-ranked types and one two-parameter type class) are used. No | undecidable instances, no functional dependencies (let alone | overlapping instances) are required. In fact, the implementation uses | only one trivial typeclass and one trivial instance. | | Perhaps such an approach to File IO can be more widely used? It | trivially generalizes to database IO and other kinds of IO. | | The motivation for monadic regions has been best explained by: | | Brandon Moore wrote on Haskell Cafe: | > I'm assuming you understand how the type on runST and the STRef | > operations ensure that, even though you *can* smuggle out an STRef in | > the result from runST, you will never be able to use it again. | > | > The idea was to do the equivalent thing with databases: use fancy types | > to ensure that handle can only be used inside to origination withDB or | > withCursor or whatever, and the bracketing function can release the | > resource on the way out, without worrying about it being used again. | | Benjamin Franksen wrote: | | > I think this is an extremely good idea. I have been very frustrated | > with finalizers because of their limitations (can't rely on them being | > called at all), so have (reluctantly) been using the unsafe bracket | > version. Making it safe via a type system trick is really the way to | > go. | | | Let us start with the tests | | > {-# OPTIONS -fglasgow-exts #-} | > | > module IORegionsTest where | > | > import IORegions -- see below | > | > test0 = withFile "/etc/motd" (const $ return True) | > | > reader q = do | > c1 <- qGetChar q | > c2 <- qGetChar q | > return [c1,c2] | > | > test1 = withFile "/etc/motd" reader | > test1r = runIOM test1 >>= print | | Instead of handles, we have Qs -- marked handles. The are created by | the function withFile and used similar to regular handles. A special | IOM monad is a newtype away from the regular IO. The phantom type | parameter of the IOM monad maintains the marks of the regions. | | *IORegionsTest> :t reader | reader :: (Monad (IOM marks), IORegions.IN mark marks) => | Q mark -> IOM marks [Char] | | the type of the reader shows that it takes a marked handle and yields | a marked IO computation. The constraint IN assures that the | computation must be marked with the mark of the handle. | | If we attempt to leak the handle: | *> test2 = withFile "/tmp/i.hs" (\q -> return q) | | we get | Inferred type is less polymorphic than expected | Quantified type variable `mark' escapes | In the second argument of `withFile', namely `(\ q -> return q)' | | The following is OK: we perform the computation and return its result: | > test3 = withFile "/etc/motd" (\q -> (qGetChar q)) | | If we attempt to return the unperformed computation itself: | *> test4 = withFile "/tmp/i.hs" (\q -> return (qGetChar q)) | | we get | Could not deduce (IORegions.IN mark marks1) | from the context (IORegions.IN mark marks) | arising from use of `qGetChar' at IORegionsTest.h... | | As we said earlier, more than one handle can be at play at the same | time: | | > reader2 q1 q2 = do | > c1 <- qGetChar q1 | > c2 <- qGetChar q2 | > return [c1,c2] | > test5 = withFile "/etc/motd" (\q1 -> | > withFile "/etc/motd" (\q2 -> reader2 q1 q2)) | > | > test5r = runIOM test5 >>= print | | Incidentally, the inferred type of reader2 is | | *IORegionsTest> :t reader2 | reader2 :: (Monad (IOM marks), | IORegions.IN mark1 marks, | IORegions.IN mark marks) => | Q mark -> Q mark1 -> IOM marks [Char] | | Obviously, the resulting computation is marked with the marks of both | argument handles. | | With two handles, we can actually return a handle -- provided we | return an outermost handle from the innermost region (but not the | other way around). For example, the following is wrong | | *> test6 = withFile "/etc/motd" | *> (\q2 -> | *> do | *> q' <- withFile "/etc/motd" (\q -> return q) | *> qGetChar q') | | | but the following is OK: | > test7 = withFile "/etc/motd" | > (\q2 -> | > do | > q' <- withFile "/etc/motd" (\q -> return q2) | > qGetChar q') | | Ditto for the computation: | | The following is the improper leakage and leads to a type error: | | *> test8 = withFile "/etc/motd" | *> (\q2 -> | *> do | *> a <- withFile "/etc/motd" (\q -> return (qGetChar q)) | *> a) | | But the following is fine: | | > test9 = withFile "/etc/motd" | > (\q2 -> | > do | > a <- withFile "/etc/motd" (\q -> return (qGetChar q2)) | > a) | > | > test9r = runIOM test9 >>= print | | | -- The file IORegions.hs follows. | | {-# OPTIONS -fglasgow-exts #-} | | -- Simple IO Regions | | module IORegions (runIOM, qGetChar, withFile, | -- Only types are exported, not their data constructors! | Q, IOM) where | | import Control.Exception | import System.IO | | -- The marked IO monad. The data constructor is not exported. | -- The type 'marks' is purely phantom (and is never instantiated, actually) | newtype IOM marks a = IOM (IO a) deriving Monad | unIOM (IOM x) = x | | -- The marked IO handle. The data constructor is not exported. | newtype Q mark = Q Handle | | -- |IN mark marks| asserts that |mark| is a member of the mark set |marks| | -- The mark set is really a set, and the best of all, it's typechecker | -- that maintains it. We don't need to do anything at all. | class IN a b | instance IN () b | | -- Reading from a marked handle. The mark must be within the marks | -- associated with the IOM monad | qGetChar :: (IN mark marks) => Q mark -> IOM marks Char | qGetChar (Q h) = IOM $ hGetChar h | | -- There must not be an operation to close a marked handle! | -- withFile takes care of opening and closing (and disposing) of | -- handles. | | -- Open the file, add the markset constraint for the duration of the body, | -- and make sure the marked handle does not escape. | -- The marked handle is closed on normal or abnormal exit from the | -- body | -- The type system guarantees the strong lexical scoping of | -- withFile. That is, we can assuredly close all the handles after | -- we leave withFile because we are assured that no computations with | -- marked handles can occur after we leave withFile. | | withFile :: FilePath -> (forall mark. IN mark marks => Q mark -> IOM marks a) | -> IOM marks a | withFile filename proc = | IOM( | bracket | (openFile filename ReadMode) | (hClose) | (\handle -> unIOM $ proc ((Q handle) :: Q ()))) | | -- Running the IOM monad | runIOM :: (forall mark. IOM mark a) -> IO a | runIOM = unIOM | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

4 3

Time Profiling Haskell
by Thomas Davie 18 Jan '06

18 Jan '06

I have a program that I *know* can run faster... I know there's duplicated effort in there somewhere, the question is where. The heap profile reflects exactly what I would expect it to, so I want a reasonably accurate time profile. Is there any way to get such a thing? Thanks Bob

2 1

Haskell Weekly News: January 16, 2006
by dons＠cse.unsw.edu.au 18 Jan '06

18 Jan '06

Haskell Weekly News: January 16, 2006 Greetings, and thanks for reading the 20th issue of HWN, a weekly newsletter for 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. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ 3. http://sequence.complete.org/node/feed New Releases * hdbc-odbc. John Goerzen [4]released the first version of hdbc-odbc, the ODBC backend for HDBC. With this driver, you can use HDBC to connect to any database for which ODBC drivers exist, including such databases as MySQL, Oracle, MS SQL Server 4. http://article.gmane.org/gmane.comp.lang.haskell.general/13007 Resources and Tools * Haskell Performance Resources. Simon Marlow [5]opened up a [6]wiki page to collect the community wisdom on writing high performance Haskell code. This is particularly relevant given the discussions regarding the language shootout recently, with many interesting techniques proposed. 5. http://article.gmane.org/gmane.comp.lang.haskell.general/13018 6. http://haskell.org/haskellwiki/Haskell_Performance_Resource Discussion * Arrays. Bulat Ziganshin [7]wrote an interesting RFC on the various Haskell array interfaces. 7. http://article.gmane.org/gmane.comp.lang.haskell.general/12992 * Functional Java. Graham Klyne [8]alerted us to [9]FunctionalJ, an open source library for functional programming in Java. This might be useful to those unfortunates trapped on the JVM. Additionally, Bjorn Bringert [10]mentioned a similar library, Higher-Order Java (HOJ), he wrote a few years ago. 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/10898 9. http://www.theserverside.com/news/thread.tss?thread_id=38430 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/10900 * Data structures. Duncan Coutts was [11]looking for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. 11. http://thread.gmane.org/gmane.comp.lang.haskell.general/13073 * Language Shootout, continued. Many entries have been improved on the [12]Computer Language Shootout, and after several years of complaints that micro-benchmarks are meaningless, and that the tests are biased against purely functional languages, it's great to see that [13]Haskell is now ranked 2nd overall. 12. http://shootout.alioth.debian.org/gp4/ 13. http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all Darcs Corner * darcsweb 0.14. Alberto Bertogli [14]released darcsweb 0.14. 14. http://article.gmane.org/gmane.comp.version-control.darcs.user/9207 Quotes of the Week <palomer> grr, sml can't derive Ord <palomer> sml is a pain to use sometimes <palomer> but sometimes it's a joy! <palomer> ugh, I take it back, it's a pain Contributing to HWN You can help us create new editions of this newsletter. Please see the [15]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 15. http://sequence.complete.org/hwn-contrib

2 2

Call for Papers - GPCE'06
by Emir Pasalic 17 Jan '06

17 Jan '06

Apologies for multiple/overlapping posts. ------------------------------------------------------------------------ -- CALL FOR TECHNICAL PAPERS Fifth International Conference on Generative Programming and Component Engineering (GPCE'06) http://www.gpce.org/06/ October 22-26, 2006 Portland, Oregon (co-located with OOPSLA'06) Sponsored by ACM SIGPLAN, in cooperation with ACM SIGSOFT. Proceedings to be published by ACM Press. ------------------------------------------------------------------------ -- IMPORTANT DATES * Pre-submission: April 30, 2006 * Submission: May 5, 2006, 23:59, Apia time (firm deadline, no extensions) * Notification: June 28, 2005 SCOPE Generative and component approaches are revolutionizing software development similar to how automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (elevating program specifications to compact domain-specific notations that are easier to write, maintain, and analyze) are key technologies for automating program development. GPCE provides a venue for researchers and practitioners interested in foundational techniques for enhancing the productivity, quality, and time-to-market in software development that stems from deploying standard componentry and automating program generation. In addition to exploring cutting-edge techniques for developing generative and component-based software, our goal is to foster further cross-fertilization between the software engineering research community and the programming languages community. ------------------------------------------------------------------------ -- SUBMISSIONS 10 pages in SIGPLAN proceedings style (sigplanconf.cls) reporting research results and/or experience related to the topics above (PC co-chairs can advise on appropriateness). We particularly encourage original high-quality reports on applying GPCE technologies to real-world problems, relating ideas and concepts from several topics, or bridging the gap between theory and practice. ------------------------------------------------------------------------ -- TOPICS GPCE seeks contributions in software engineering and in programming languages related (but not limited) to: * Generative programming Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, and step-wise refinement Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, and program transformation Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, and reflection * Generative techniques for Product-line architectures Distributed, real-time and embedded systems Model-driven development and architecture * Component-based software engineering Reuse, distributed platforms and middleware, distributed systems, evolution, patterns, development methods, deployment and configuration techniques, and formal methods * Integration of generative and component-based approaches * Domain engineering and domain analysis Domain-specific languages (DSLs) including visual and UML-based DSLs * Separation of concerns Aspect-oriented and feature-oriented programming, Intentional programming and multi-dimensional separation of concerns * Industrial applications Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program committee is happy to advise on the appropriateness of a particular subject. ------------------------------------------------------------------------ -- General Chair Stanislaw Jarzabek (National University of Singapore, Singapore) Program Committee Program Chairs: Douglas Schmidt (Vanderbilt University, USA) Todd Veldhuizen (Indiana University, USA) Program Committee Members: Giuseppe Attardi (University of Pisa, Italy) Elisa Baniassad (Chinese University of Hong Kong, China) Don Batory (University of Texas at Austin, USA) Ira Baxter (Semantic Designs, USA) Shigeru Chiba (Tokyo Institute of Technology, Japan) Charles Consel (INRIA/LaBRI, France) Krzysztof Czarnecki (University of Waterloo, Canada) Aniruddha Gokhale (Vanderbilt University, USA) Jeff Gray (U. of Alabama Birmingham, USA) George Heineman (Worcester Polytechnic Institute, USA) Zhenjiang Hu (University of Tokyo, Japan) H.-Arno Jacobsen (University of Toronto, Canada) Oleg Kiselyov (FNMOC, USA) Fabio Kon (University of São Paolo, Brazil) Karl Lieberherr (Northeastern University, USA) Joe Loyall (BBN Technologies, USA) Mira Mezini (Darmstadt University of Technology, Germany) Torben Æ. Mogensen (DIKU, Denmark) Emir Pasalic (Rice University, USA) Calton Pu (Georgia Tech, USA) Tim Sheard (Portland State University, USA) Yannis Smaragdakis (Georgia Tech, USA) Michael Stal (Siemens, Germany) Peri Tarr (IBM TJ Watson, USA) Peter Thiemann (Freiburg University, Germany) Eelco Visser (Utrecht University, The Netherlands) Workshops/Tutorials chairs: Christa Schwanninger (Siemens, Germany) Arno Jacobsen (University of Toronto, Canada) Publicity chair: Emir Pasalic (Rice University, USA) Steering Committee: Don Batory (University of Texas at Austin, USA) Krzysztof Czarnecki (University of Waterloo, Canada) Ulrich Eisenecker (University of Leipzig, Germany) Stanislaw Jarzabek (National University of Singapore, Singapore) Eugenio Moggi (University of Genoa, Italy) Greg Morrisett (Harvard University, USA) Frank Pfenning (Carnegie Mellon University, USA) Tim Sheard (Portland State University, USA) Yannis Smaragdakis (Georgia Tech, USA) Walid Taha (Rice University, USA) For additional information, clarification, or questions please feel free to contact the Program Committee Co-chairs (Gpce06-chairs-l(a)mailman.rice.edu) ------------------------------------------------------------------------ -- GPCE Tutorials and Workshops GPCE Tutorials, extending over a half or full day, give a deeper or broader insight than conventional lectures. GPCE Workshops provide intensive collaborative environments, where generative and component technologists meet to discuss and resolve challenging problems in the field. Tutorial and workshop proposals are due Mar 18, 2006.

1 0

Haskell DB bindings (was Re: ANN: HDBC (Haskell Database Connectivity)
by Tim Docker 17 Jan '06

17 Jan '06

oleg(a)pobox.com wrote: > Incidentally, the difficulty with finalizers was precisely the > argument for using enumerators rather than cursors in database > APIs. Takusen has implemented that idea; takusen currently supports > Sqlite, PostgreSQL and Oracle, has a test suite. Its performance test > shows that takusen can retrieve 2 million rows from a table without > running out of memory. The differences between HDBC and HSQL have been recently discussed. Where does Takusen fit into this picture? From the above, it sounds like it has quite a different API. Are all 3 of these actively maintained? As someone who may wish to construct a haskell db binding for a new db, it's not clear to which API it should conform. Sometimes choice is a burden... Tim

5 5

darcsweb installed
by Simon Marlow 17 Jan '06

17 Jan '06

I have installed darcsweb on darcs.haskell.org. To browse the available darcs repositories, go here: http://darcs.haskell.org/darcsweb It's also available as http://hackage.haskell.org/darcsweb. Note that currently I have omitted GHC, the reason being that the GHC repository is so big that some of the operations on a file (eg. history, annotate) cause darcs to eat up CPU for several minutes on the server. So to avoid the server becoming bogged down with darcs processes I've just omitted the GHC repository for now. Cheers, Simon

2 1