- Haskell - Haskell.org

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

27 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 24 Mar '06

24 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

Haskell as a markup language
by oleg＠pobox.com 21 Mar '06

21 Mar '06

We demonstrate that Haskell as it is, with no TH or other pre-processors, can rather concisely represent semi-structured documents and the rules of their processing. In short, Haskell can implement SXML (ssax.sourceforge.net) right in its syntax and with the *open* and extensible set of `tags'. The benefit of Haskell is of course in static type guarantees, such as prohibiting an H1 element to appear in the character content of other elements. It also seems that the specification of various pre-post-order and context-sensitive traversals is more concise in Haskell compared to Scheme. Again, we are talking about the existing Haskell, i.e., Haskell98 plus common extensions. No Template Haskell or even overlapping instances are required. The features of our framework are: - extensibility: at any time the user can add new `tags' and new transformation/traversal modes. - static safety: there are no dynamics, and no variant data types for elements or attributes, and thus no possibility of a run-time pattern-match failure. - static guarantees: the framework statically ensures that a `block-level element' cannot appear in the inline (i.e., character) content and that a character-content entity cannot appear in a pure element content. Some entities (e.g., `title') may be either element or attribute. OTH, many other entities may not occur in the attribute context. Thus the generated XML or HTML document will not only be well-formed: it would also satisfy some validity constraints. More validity constraints can be added to the framework. - flexibility of the traversal: the same document can be transformed in pre-, post-, accumulating or other ways, even within the same session. A document can be processed in a pure function, or in a monadic action, including an IO action. In the latter case, we can, e.g., verify URLs as we generate an HTML document. A `tag' can be transformed depending of the transformation modes and tag's context: e.g., the same `(title "title")' expression may appear as an attribute or an element -- and it will be rendered differently by the (X)HMTL serializer. - pleasant syntax, which closely resembles SXML. We can write (p "string" "string1" br "string3") without unnecessary commas and other syntactic distractions. We take polyvariadic functions to the new level (pun intended). We also exploit functional dependencies on a per-instance level -- which is a very useful but, alas, rarely used technique. We introduce two frameworks for representing semi-structured data in Haskell. In one, semi-structured data is truly a heterogeneous structure -- and so can be showed, stored, written and read. In the second approach, semi-structured data are represented as a monadic value, polymorphic over the rendering monad. Different choices of the monad give different views of data. In GHC, this amounts to representing semi-structured data by linked dictionaries; in JHC, both approaches are probably equivalent. The first representation is quite reminiscent of HList; the second has clear SYB3 (``Scratch your boilerplate with class'') overtones, although the realization is quite different. In particular, there is no need for recursive instances. Because of the amount of code involved (to describe common HTML tags and their constraints), this message is not the complete code. The code is available from http://pobox.com/~oleg/ftp/Haskell/HSXML.tar.gz Please see the files HSXML.hs, HSXML_HTML.hs and the sample code sample1c.hs for the data-centric framework. The monad-centric framework is in one self-contained file CSXML.hs. The first framework is more in line with SXML, and so will be considered here. Our running example, inspired by the Haskell.org web site, is: test_haskell = (document (head [title "Haskell" longdash "HaskellWiki"] [meta_tag [description "All about the language" br "Haskell"]]) (body [h1 "Haskell"] [div (attr [title "titleline"]) [p [[a (attr [href (FileURL "/haskellwiki/Image:Haskelllogo.jpg")]) "Haskell" br "A <purely functional> language"]] br ] [p "Haskell is a general purpose," [[em [[strong "purely"]] "functional"]] "programming language"]])) We should point out the absence of commas. The [[x]] syntax can be replaced with a simple [x], but that would require overlapping instances. So far, we have avoided overlapping instances. Incidentally, in many Scheme systems (and, reputedly, in R6RS) square brackets are taken to be synonymous to the round ones. We see that the |br| can be used in various contexts: in the character content of an element and of an attribute (cf. `description' for the latter). However, if we try to replace "Haskell" within the `description' attribute with [[em "Haskell"]] we get an error that Couldn't match `CT_attr' against `CT_inline' Expected type: CT_attr Inferred type: CT_inline OTH, the string "Haskell" that appears within |h1| element may be replaced with [[em "Haskell"]]. However, if we try to enter (h1 [[h1 "Haskell"]]) we get type error Couldn't match `CT_inline' against `CT_block' Indeed, the element |H1| is not allowed in the `inline' context. We can transform the test_haskell data structure in many ways (e.g., extract all the titles, renumber sections, etc). We can also render it in HTML. The result is quite predictable: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <head> <title>Haskell— HaskellWiki</title> <meta name="description" content="All about the language Haskell"></meta> </head> <body> <h1>Haskell</h1> <div title="titleline"> <p><a href="/haskellwiki/Image:Haskelllogo.jpg">Haskell <br> A <purely functional> language</a> <br> </p> <p>Haskell is a general purpose,<em><strong>purely</strong>functional</em>programming language</p> </div> </body> We should note that |title| -- which can be either an element or an attribute -- is indeed rendered differently depending on the context. Just to emphasize the extensibility of the framework, we show how easy it is to add new elements. For example, the `tags' |longdash|, |a|, |div| and |title| are not defined in the base file HSXML.hs. We add these tags in sample1c.hs, as follows: Let us start with an abbreviation for the long dash. It may appear in the character content of an element or an attribute > data LongDash = LongDash deriving Show > longdash :: Check_ia LongDash ct => HW ct LongDash > longdash = HW LongDash > > -- and how to render it in HTML > instance RenderInline (HW ct LongDash) where > render_inline f _ = emit_lit "—" >> return f Actually, the latter instance describes rendering of longdash in any |MonadRender m| -- any monad that defines morphisms |emit|, |emit_elem| and |emit_attr|. Anchor is an inline element with an inline content > data Anchor a b = Anchor a b deriving Show > a attrs body = > build (as_inline . HW . Anchor (as_block attrs) . rev'apppend HNil) > nil_inline body > > instance (Render a, RenderInline b) =>RenderInline (HW ct (Anchor a b)) where > render_inline f (HW (Anchor attrs body)) = > emit_elem "a" [] (Just (render attrs)) (render_ib body) > >> return False Title can be either - a block-level element whose content is CT_inline - an attribute (whose content is, therefore, CT_attr) > newtype Title a = Title a deriving Show > title x = build ((`as_ctx` co) . HW . Title . rev'apppend HNil) nil_ab x > where nil_ab = HW HNil `as_ctx` ci > (ci,co) = title_ctx > class Check_ia (Title ()) i => TitleCtx i o | i -> o, o -> i where > title_ctx :: (HW i a, HW o a) ; title_ctx = undefined > instance TitleCtx CT_attr CT_battr > instance TitleCtx CT_inline CT_block It can be rendered context-sensitively: > instance RenderInline a => Render (HW CT_battr (Title a)) where > render (HW (Title x)) = emit_attr "title" > ((render_inline False x) >> return ()) > instance RenderInline a => Render (HW CT_block (Title a)) where > render (HW (Title x)) = emit_elem "title" [Hint_nl] Nothing > (render_ib x) It seems many of the SXML transformations (cf. the `examples' directory of the SSAX distribution or CVS repository, ssax.sf.net) can be rendered in Haskell. More examples are forthcoming.

2 1

CFP2: Mathematically Structured Functional Programming
by Conor McBride 21 Mar '06

21 Mar '06

SECOND CALL FOR PAPERS Workshop on Mathematically Structured Functional Programming MSFP 2006 Kuressaare, Estonia, 2 July 2006 http://cs.ioc.ee/mpc-amast06/msfp/ a satellite workshop of MPC 2006 a "small workshop" of the TYPES project Background Something wonderful happened when monads arrived in Haskell: some human mathematics explaining the structure of certain computational phenomena became a mechanical means to implement those phenomena. It's a good way to go about functional programming - to dig out the mathematical structure underlying a problem and set it to work! There's more where monads came from, and we want it. This new workshop is about getting it. In recent years, a diverse array of mathematical structures has appeared in our programs: monads dualise to comonads and generalise to Freyd categories aka 'arrows'; 'container' types have a generalised polynomial structure supporting generic programming, not to mention a differential calculus; isomorphisms from 'high school algebra' are used to search libraries and repair type errors; coalgebras give structure to recursion; the list goes on... MSFP is broad in scope, covering the extraction of functionality from structure wherever it can be found. It complements the remit of its host conference, Mathematics of Program Construction, by seeking to enrich the language and toolset available for specifications and programs alike. It is also a "small workshop" of the FP6 IST coordination action TYPES. Invited speakers Andrzej Filinski, Kbenhavns Universitet John Power, University of Edinburgh Important dates * Submission of papers: 10 April 2006 * Notification of authors: 8 May 2006 * Camera-ready version: 5 June 2006 Topics Submissions are welcome on, but by no means restricted to, topics from the following partially computed coinductive list: * structured effectful computation * structured recursion * structured tree and graph operations * structured syntax with variable binding * structures for datatype-genericity * structures for search * structured representations of functions * structured manipulation of mathematical structure * structured <thunk> in functional programming Authors concerned about the suitability of a topic are very welcome to contact Conor McBride, ctm(at)cs.nott.ac.uk. Submission and publication Papers in pdf not exceeding 15 pages and adhering to the eWiC style must be submitted by 10 April 2006 via an online submission webpage. Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. Accepted papers must be presented at the workshop by one of the authors. The proceedings of MSFP 2006 will be published in the Electronic Workshops in Computing (eWiC) series of the British Computer Society, http://ewic.bcs.org/. After the workshop, the authors of the best papers will be invited to submit revised and expanded versions to a special issue of the Journal of Functional Programming from Cambridge University Press. Programme committee Yves Bertot, INRIA Sophia Antipolis Marcelo Fiore, University of Cambridge Masahito Hasegawa, Kyoto University Graham Hutton, University of Nottingham Paul Levy, University of Birmingham Andres Lh, Universitt Bonn Christoph Lth, Universitt Bremen Conor McBride, University of Nottingham (co-chair) Marino Miculan, Universit degli Studi di Udine Randy Pollack, University of Edinburgh Amr Sabry, Indiana University Tarmo Uustalu, Institute of Cybernetics (co-chair) Main conferences MSFP 2006 is a satellite workshop of the 8th International Conference on Mathematics on Program Construction, MPC 2006, to take place 3-5 July. Co-located with MPC 2006, the 11th International Conference on Algebraic Methodology and Software Technology, AMAST 2006, will follow 5-8 July. Venue Kuressaare (pop. 16000) is the main town on Saaremaa, the second-largest island of the Baltic Sea. Kuressaare is a charming seaside resort on the shores of the Gulf of Riga highly popular with Estonians as well as visitors to Estonia. The scientific sessions of MPC/AMAST 2006 will take place at Saaremaa Spa Hotel Meri, one among the several new spa hotels in the town. The social events will involve a number of sites, including the 14th-century episcopal castle. Accommodation will be at Saaremaa Spa Hotels Meri and Rtli. To get to Kuressaare and away, one must pass through Tallinn (pop. 402000), Estonia's capital city. Tallinn is famous for its picturesque medieval Old Town, inscribed on UNESCO's World Heritage List. TYPES support MSFP 2006 is an official workshop of the EU FP6 IST coordination action TYPES. Participants from TYPES sites/subsites may use project funds to cover their travel and participation. Local organizers MPC/AMAST 2006 is organized by Institute of Cybernetics, a research institute of Tallinn University of Technology. The local organizers are Tarmo Uustalu (chair), Monika Perkmann, Juhan Ernits, Ando Saabas, Olha Shkaravska, Kristi Uustalu. Contact email address of the local organizers: mpc06(at)cs.ioc.ee. This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0