January 2008 - Haskell

ANNOUNCE: HStringTemplate -- An Elegant, Functional, Nifty Templating Engine for Haskell
by Sterling Clover 27 Jan '08

27 Jan '08

HStringTemplate is a port of Terrence Parr’s lovely StringTemplate (http://www.stringtemplate.org) engine to Haskell. It is available, cabalized, at: darcs get http://code.haskell.org/HStringTemplate/ As interest has grown in using Haskell for web applications, there has been an increasing buzz about the need for a good templating engine in Haskell. Why might we need this? After all, Haskell has lovely combinator libraries for generating HTML programmatically, enforcing good form through its type system. But sometimes, we don’t want well-formed HTML. We want the ugly stuff that floats around to deal with eight varieties of browser incompatibilities and the latest silly ajax trick. Or sometimes we’re working with a team of graphic designers, and they want to work in almost-HTML. Or sometimes we just want to be able to change the design of a web application on the fly, completely independent of our program logic, and of, heavens forbid, recompiling and possibly messing with a live application. So template engines are popular, and indeed, considered a key part of most web frameworks out there. One problem — they’re mainly awful, imperatively-conceived behemoths that capriciously mix program logic with display and, consequently, entail a great deal of overhead. Enter StringTemplate, a nifty and fairly-well developed template format that’s both pure and functional, and therefore pretty much the only one of its kind. Indeed, it also seems to be getting heavy use in code generation because its paradigm maps neatly to traversing parse-trees. HStringTemplate is not feature-complete, and indeed is only at version 0.1. But it should implement pretty much everything in the standard StringTemplate 3.0 grammar, only nicer, because it’s in Haskell. There are scads of different recursive constructs and ways to handle inclusion and inheritance. Furthermore, HStringTemplate handles conditionals, and sports also a very Haskellish implementation of custom rendering. Templates can be constructed that return strings, ShowSs, bytestrings, or even pretty printer Docs that handle wrapping, indentation, and fill elegantly. Even better, these templates are parsed and compiled only once, after which point there isn't a syntax tree anymore, just a function that operates on the environment of attributes that have been passed to it. Where I take it from here depends in part on what sort of response I get, so patches, gripes, API comments and feature requests are all more than welcome. Please note that I'm still working in 6.6.1. Everything should be in place to compile properly with the base split, but if it isn't, again, patches more than welcome. Full announcement at: http://fmapfixreturn.wordpress.com/ --SC

4 4

Re: [Haskell-cafe] Why functional programming matters
by Michael Reid 25 Jan '08

25 Jan '08

Yaakov Nemoy wrote: > I'm still very much a newbie, but the one thing that struck me as the > best feature coming from Python is the static typing. Changing the > type of a function in Python will lead to strange runtime errors that > take some work to debug, whereas, when I tinker with a program in > Haskell, I already know it will work once it compiles. > I'm quite new to Haskell as well and I must echo this sentiment. The mainstream has somewhat realized that its a waste of time to tell the compiler the type of _everything_. Learning Haskell has completely reversed my feeling that static typing is an old outdated idea. The power of Haskell's type system makes it feel like you are programming in a dynamic language to some degree, yet all of it is type-checked, and that is just *really* cool. Honestly, when I first started reading a Haskell tutorial I was convinced that it was an runtime-typed language like Python. When the tutorial moved on to explain that it is statically typed I could barely believe it. The second thing I might want to highlight is the power of monads and other techniques like arrows and FRP. Granted, these are not easy concepts to impart in a talk, but I think they were really an important discovery in FP as they deal with the "problem" of IO in such a beautifully orthogonal way. Following on that, more advanced structures like arrows and how all of this can contribute to really powerful DSLs I think is a pretty big selling point. Actually, come to think of it, one great way to show off the language is to show off the power of some of the libraries that have been written. For example, show how easily a parser can be created w/ Parsec; or show an example of FRP w/ Yampa. These examples will likely tantalize the programmers in the audience to want to learn more. Good luck! /mike.

2 1

Why functional programming matters
by Simon Peyton-Jones 23 Jan '08

23 Jan '08

Friends Over the next few months I'm giving two or three talks to groups of *non* functional programmers about why functional programming is interesting and important. If you like, it's the same general goal as John Hughes's famous paper "Why functional programming matters". Audience: some are technical managers, some are professional programmers; but my base assumption is that none already know anything much about functional programming. Now, I can easily rant on about the glories of functional programming, but I'm a biased witness -- I've been doing this stuff too long. So this message is ask your help, especially if you are someone who has a somewhat-recent recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc". I'm going to say some general things, of course, about purity and effects, modularity, types, testing, reasoning, parallelism and so on. But I hate general waffle, so I want to give concrete evidence, and that is what I particularly want your help with. I'm thinking of two sorts of "evidence": 1. Small examples of actual code. The goal here is (a) to convey a visceral idea of what functional programming *is*, rather than just assume the audience knows (they don't), and (b) to convey an idea of why it might be good. One of my favourite examples is quicksort, for reasons explained here: http://haskell.org/haskellwiki/Introduction#What.27s_good_about_functional_… But I'm sure that you each have a personal favourite or two. Would you like to send them to me, along with a paragraph or two about why you found it compelling? For this purpose, a dozen lines of code or so is probably a maximum. 2. War stories from real life. eg "In company X in 2004 they rewrote their application in Haskell/Caml with result Y". Again, for my purpose I can't tell very long stories; but your message can give a bit more detail than one might actually give in a presentation. The more concrete and specific, the better. E.g. what, exactly, about using a functional language made it a win for you? If you just reply to me, with evidence of either kind, I'll glue it together (regardless of whether I find I can use it in my talks), and put the result on a Wiki page somewhere. In both cases pointers to blog entries are fine. Quite a lot of this is FP-ish rather than Haskell-ish, but I'm consulting the Haskell mailing lists first because I think you'll give me plenty to go on; and because at least one of the talks *is* Haskell-specific. However, feel free to reply in F# or Caml if that's easier for you. Thanks! Simon

3 2

ANNOUNCE: Harpy 0.4 - Runtime code generation for x86 machine code
by Martin Grabmueller 23 Jan '08

23 Jan '08

We are pleased to announce the release of Harpy 0.4, a library for runtime code generation for x86 machine code. Harpy is available from Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy-0.4 Also see Harpy's homepage, which features two tutorials and access to the darcs repo (and to the Haddock documentation, until it is available from Hackage, too): http://uebb.cs.tu-berlin.de/harpy/ Harpy is supposed to be built with GHC 6.8 and GHC 6.6 (with Cabal 1.2 or greater). Please report any build problems you encounter. This release features the following additions and fixes: - New convenience top-level module "Harpy", which re-exports Harpy.CodeGenMonad, Harpy.Call and Harpy.X86Assembler - It is now possible to override Harpy's automatic code buffer management. The new field 'customCodeBuffer' in the type 'CodeGenConfig' can be set to 'Just (buf, size)', where 'buf' is a pointer to a memory region of 'size' bytes. Harpy will then use the supplied code buffer and will not perform any automatic code buffer allocation on overflow. Overflow checking is still performed and will result in an exception in the CodeGen monad. - When using the high-level assembler in X86Assembler, the code buffer is automatically protected from overflow. - Floating point operations added to X86Assembler (only for double operands yet). - Preliminary support for SSE instructions. Currently, only the packed and scalar floating-point arithmetic operations are supported (both in the low-level module Harpy.X86CodeGen and as methods in Harpy.X86Assembler) - Code buffer default size has been increased from 128 to 4096 bytes. - The CodeGenMonad fails when a label is defined twice. - It is now possible to associate names with labels, using the new operation newNamedLabel. The given names will show up in the disassembly, which makes debugging of generated code much easier. - The doc directory contains a second, slightly larger tutorial now. - The examples/evaluator directory contains a small example interpreter for arithmetic expressions, which translates expressions entered at the keayboard to machine code on the fly. This is the demo program we presented at the Haskell Workshop 2007. Happy Haskell Hacking with Harpy, Martin and Dirk

1 0

ICFP2008 Call for Papers
by Matthew Fluet (ICFP Publicity Chair) 21 Jan '08

21 Jan '08

Call for Papers ICFP 2008: International Conference on Functional Programming Victoria, BC, Canada, 22-24 September 2008 http://www.icfpconference.org/icfp2008 Submission deadline: 2 April 2008 ICFP 2008 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects and concurrency. Particular topics of interest include * Applications and Domain-Specific Languages: systems programming; scientific and numerical computing; symbolic computing; artificial intelligence; databases; graphical user interfaces; multimedia programming; scripting; system administration; distributed-systems and web programming; XML processing; security * Foundations: formal semantics; lambda calculus; type theory; monads; continuations; control; state; effects * Design: algorithms and data structures; modules; type systems; concurrency and distribution; components and composition; relations to object-oriented or logic programming * Implementation: abstract machines; compile-time and run-time optimization; just-in-time compilers; memory management; parallel hardware; interfaces to foreign functions, services, components or low-level machine resources * Transformation and Analysis: abstract interpretation; partial evaluation; program transformation * Software-development Techniques: design patterns; specification; verification; validation; debugging; test generation; tracing; profiling * Functional Pearls: elegant, instructive, and fun essays on functional programming * Practice and Experience: novel results drawn from experience in education or industry. Experience Reports are also solicited, which are short papers (2-4 pages) that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are below. What's different this year? ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * No double blind reviewing. Instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~ By Wednesday, 2 April 2008, 09:00 AM Apia time, submit an abstract of at most 300 words and a full paper of at most 12 pages (4 pages for an Experience Report), including bibliography and figures. The deadline will be strictly enforced and papers not meeting the page limits are summarily rejected. Authors have the option to attach supplementary material to a submission, on the understanding that reviewers are not expected to read it. A submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It 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. The technical content should be accessible to a broad audience. Each submission must adhere to SIGPLAN's republication policy, as explained on the web. Violation risks summary rejection of the offending submission. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to ACM. They may have the option to have their presentation videotaped and published along with the conference proceedings in the ACM Digital Library. Video recordings will only be released at the consent of the presenter, which is expressed by signing an additional copyright release/permission form. Formatting ~~~~~~~~~~ Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. If this requirement is a hardship, make contact with the program chair at least one week before the deadline. ICFP proceedings are printed in black and white. It is permissible to include color in a submission, but you risk annoying reviewers who will have to decide if your final paper will be understandable without it. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available from SIGPLAN. Submission ~~~~~~~~~~ Submissions will be accepted electronically; the submission page is not yet ready. The deadline is set at Samoan time, so if your submission is in by 09:00 AM Wednesday according to your local time, wherever you are, the submission will be on time. The world clock (http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=2&year=200…) can give you the equivalent in your local time, e.g.,1:00 PM Wednesday in Seattle, 4:00 PM Wednesday in New York, and 9:00 PM Wednesday in London. Citation ~~~~~~~~ We recommend (but do not require) that you put your citations into author-date form. This procedure makes your paper easier to review. For example, if you cite a result on testing as ``(Claessen and Hughes 2000)'', many reviewers will recognize the result instantly. On the other hand, if you cite it as ``[4]'', even the best-informed reviewer has to page through your paper to find the reference. By using author-date form, you enable a knowledgeable reviewer to focus on content, not arbitrary numbering of references. LaTeX users can simply use the natbib package along with the plainnat bibliography style. Author response ~~~~~~~~~~~~~~~ You will have a 48-hour period, starting at 09:00 on 21 May 2008 Apia time, to read and respond to reviews. Special categories of papers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In addition to research papers, ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to four pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ~~~~~~~~~~~~~~~~~ A Functional Pearl is an elegant essay about something related to functional programming. It might offer: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom Functional Pearls are not restricted to the above varieties, however. While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. A pearl should be concise, instructive, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. Some advice from Richard Bird: * Throw away the rule book for writing research papers. * Get in quick; get out quick. * Be self-contained; don't go deep into related work, with lengthy references. * You are telling a story, so some element of surprise is welcome. * Above all, be engaging. * Give a talk on the pearl to non-specialists, your students, or your department. If you changed the order of presentation for the talk, consider using the new order in the next draft. * Put the pearl away for a while, then take it out and polish it again. Experience Reports ~~~~~~~~~~~~~~~~~~ ICFP has long solicited submissions on the practice and experience of functional programming. But reports of experience are inherently different from research papers, and when judged by the criteria of scientific merit, novelty, or research contribution, they have not competed well against traditional ICFP submissions. Yet we believe that the functional-programming community would benefit from being able to draw on and cite the experience of others. For this reason, we have introduced the ICFP Experience Report. Unlike a normal ICFP paper, the purpose of an Experience Report is not to add to the body of knowledge of the functional-programming community. Rather, the purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works---or to describe what obstacles prevent it from working. An Experience Report is distinguished from a normal ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words ``Experience Report'' followed by a colon. * An Experience Report is at most 4 pages long. Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not present novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. Possible topics for an Experience Report include, but are not limited to * Insights gained from real-world projects using functional programming * Comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * Project-management, business, or legal issues encountered when using functional programming in a real-world project * Curricular issues encountered when using functional programming in education * Real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. If functional programming worked for you in the same ways it has worked for others, you need only to summarize the results---the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterize your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. If your paper not only describes experience but also presents new technical results, or if your experience refutes cherished beliefs of the functional-programming community, you may be better off submitting it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. If you are unsure in which category to submit, the program chair will be happy to help you decide. Other information ~~~~~~~~~~~~~~~~~ Conference Chair ~~~~~~~~~~~~~~~~ James Hook (Portland State University) Program Chair ~~~~~~~~~~~~~ Peter Thiemann Albert-Ludwigs-Universität Georges-Köhler-Allee 079 79110 Freiburg, Germany Email: icfp08(a)informatik.uni-freiburg.de Phone: +49 761 203 8051 Fax: +49 761 203 8052 Mail sent to the address above is filtered for spam. If you send mail and do not receive a prompt response, particularly if the deadline is looming, feel free to telephone and reverse the charges. Program Committee ~~~~~~~~~~~~~~~~~ Derek Dreyer (Max Planck Institute for Software Systems) Robert Ennals (Intel Research) Kathleen Fisher (AT&T Research) Zhenjiang Hu (University of Tokyo) Frank Huch (University of Kiel) Andrew Kennedy (Microsoft Research) Kevin Millikin (Google) Henrik Nilsson (University of Nottingham) Chris Okasaki (United States Military Academy) Brigitte Pientka (McGill University) Rinus Plasmeijer (University of Nijmegen) Alan Schmitt (INRIA) Chung-chieh Shan (Rutgers) Mitchell Wand (Northeastern University) Stephen Weeks (Jane Street Capital) Important Dates (at 09:00 Apia time, UTC-11) ~~~~~~~~~~~~~~~ Submission: 2 April 2008 Author response: 21 May 2008 Notification: 16 June 2008 Final papers due: 7 July 2008 ICFP 2008 Web Site ~~~~~~~~~~~~~~~~~~ http://www.icfpconference.org/icfp2008/ Special Journal Issue ~~~~~~~~~~~~~~~~~~~~~ There will be a special journal issue with papers from ICFP 2008. The program committee will invite the authors of select accepted papers to submit a journal version to this issue.

1 0

Re: [Haskell] Ancient, but still having fun
by Thorkil Naur 19 Jan '08

19 Jan '08

Young Man, On Saturday 19 January 2008 00:07, Simon Peyton-Jones wrote: > Friends, > > It's Friday 18 January 2008, which makes it my 50th birthday. Congratulations! > ... > Ancient or not, I'm still having a terrific time in this community. When I first became addicted to functional programming, as a result of Arthur Norman's 4-lecture course, and David Turner's SK-combinator papers, I never dreamt of what a wild and fascinating ride it would turn out to be. > > Thank you all! > > Simon > ... Rest assured that there are many of us having a terrific time too. And not least because of your in many ways fabulous presence. Thank you Simon. Best regards Thorkil

1 0

Ancient, but still having fun
by Simon Peyton-Jones 18 Jan '08

18 Jan '08

Friends, It's Friday 18 January 2008, which makes it my 50th birthday. I spent part of the day happily polishing Geoff Mainland's patch that adds quasi-quoting to GHC, and committing it to the GHC HEAD. I'm happy to say that this is increasingly the story: more and more people are getting involved with making GHC into a better compiler. Better still, many more people are involved in making Haskell a successful and increasingly-influential language. I'm boggled by the sheer number of libraries that are announced these days in each issue of the Haskell Weekly (sic) News. And for the first time I'm getting invitations out of the blue to speak about Haskell at mainstream professional-developer conferences. Suddenly Haskell is cool. Ancient or not, I'm still having a terrific time in this community. When I first became addicted to functional programming, as a result of Arthur Norman's 4-lecture course, and David Turner's SK-combinator papers, I never dreamt of what a wild and fascinating ride it would turn out to be. Thank you all! Simon

1 0

Re: [Haskell-cafe] ANNOUNCE: HStringTemplate -- An Elegant, Functional, Nifty Templating Engine for Haskell
by Sterling Clover 18 Jan '08

18 Jan '08

Graham, I'm sort of playing fast and loose with referential transparency here, as I actually am with stringTemplateFileGroup as well. They both use unsafeIO to do what they want, and in corner cases could give silly, though not dangerous results (i.e., in the sense of being hazardous to your program, these calls are substantially less worrisome than head). stringTemplateFileGroup could conceivably be in IO, if it was strict in reading all the files in the directory it was passed, but cacheSTGroup would force every access to a group to take place in IO, which would make the library somewhat of a pain to work with. My semi-justification for this is that its referentially- transparent-enough for most use cases, in that just about the only thing one would be doing with a StringTemplate result would be outputting it again in some form anyway. In my experience, being able to "hot-edit" templates for a live app is a key benefit of a templating system, and forcing everything into IO to get that seems like an undue burden on end-users. On the other hand, I'm also open to implementing an IO API that's safe and renaming the current functions to something somewhat scarier, or moving both them and their IO equivs to distinct modules so that end users could choose which to import. A number of options seem reasonable here. --Sterl. (btw, I fixed the typo you emailed me about in the repo, and also made a few other changes I documented at http:// fmapfixreturn.wordpress.com/) On Jan 16, 2008, at 8:19 PM, Graham Fawcett wrote: > On Jan 14, 2008 2:47 AM, Sterling Clover <s.clover(a)gmail.com> wrote: >> HStringTemplate is a port of Terrence Parr's lovely StringTemplate >> (http://www.stringtemplate.org) engine to Haskell. > > This is very cool. > > Your docs describe a function, cacheSTGroup: > > cacheSTGroup :: Int -> STGen a -> STGen a > Given an integral amount of seconds and a group, returns a group > cached for that span of time. Does not cache "misses." > > How does this work without breaking referential transparency? > Shouldn't it be in the IO monad if it is time-dependent? > > Graham

1 0

PAPP 2008 - Deadline Extension
by Clemens Grelck 17 Jan '08

17 Jan '08

*** DEADLINE EXTENSION *** Papers now due: January 20, 2008 ===================================================== PAPP 2008 Fifth International Workshop on aPpplications of declArative and object-oriented Parallel Programming part of The International Conference on Computational Science June 23-25, 2008, Krakow, Poland http://f.loulergue.free.fr/PAPP2008 ===================================================== AIMS AND SCOPE Computational Science applications are more and more complex to develop and require more and more computing power. Parallel and grid computing are solutions to the increasing need for computing power. High level languages offer a high degree of abstraction which ease the development of complex systems. Moreover, being based on formal semantics, it is possible to certify the correctness of critical parts of the applications. Algorithmic skeletons, parallel extensions of functional languages such as Haskell and ML, parallel logic and constraint programming, parallel execution of declarative programs such as SQL queries, genericity and meta-programming in object-oriented languages, etc. have produced methods and tools that improve the price/performance ratio of parallel software, and broaden the range of target applications. The PAPP workshop focuses on practical aspects of high-level parallel programming: design, implementation and optimization of high-level programming languages, libraries, middlewares and tools (performance predictors working on high-level parallel/grid source code, visualisations of abstract behaviour, automatic hotspot detectors, high-level GRID resource managers, compilers, automatic generators, etc.), applications in all fields of computational science, benchmarks and experiments. Research on high-level grid programming is particularly relevant as well as domain specific parallel software. The aim of all these languages and tools is to improve and ease the development of applications. Thus the Fifth PAPP workshop focuses on applications. The PAPP workshop is aimed both at researchers involved in the development of high level approaches for parallel and grid computing and computational science researchers who are potential users of these languages and tools. Topics We welcome submission of original, unpublished papers in English on topics including: * applications in all fields of high-performance computing and visualisation (using high-level tools) * high-level models (CGM, BSP, MPM, LogP, etc.) and tools for parallel and grid computing * high-level parallel language design, implementation and optimisation * modular, object-oriented, functional, logic, constraint programming for parallel, distributed and grid computing systems * algorithmic skeletons, patterns and high-level parallel libraries * generative (e.g. template-based) programming with algorithmic skeletons, patterns and high-level parallel libraries * benchmarks and experiments using such languages and tools All the contributions should illustrate the proposed techniques on a significant application. PAPER SUBMISSION AND PUBLICATION Prospective authors are invited to submit full papers in English presenting original research. Submitted papers must be unpublished and not submitted for publication elsewhere. Papers will go through a rigorous reviewing process. Each paper will be reviewed by at least three referees. The accepted papers will be published in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series, as part of the ICCS proceedings. Submission must be done through the ICCS website: http://www.iccs-meeting.org/iccs2008/papers/upload.php. We invite you to submit a full paper of 8 pages formatted according to the rules of LNCS, describing new and original results, no later than January 20, 2008. Submission implies the willingness of at least one of the authors to register and present the paper. An early email to papp at free.fr with your intention to submit a paper would be greatly appreciated (especially if you have doubts about the relevance of your paper). Accepted papers Accepted papers should be presented at the workshop. Authors will be invited to submit extended and revised versions of their papers. Accepted manuscripts will be published in a special issue of Scalable Computing: Practice and Experience. Important Dates * January 20, 2008 - Full paper due * March 1, 2008 - Notification * March 15, 2008 - Camera-ready paper due * September 15, 2008 - Journal version due PROGRAMME COMMITTEE * Marco Aldinucci (University of Pisa, Italy) * Anne Benoit (ENS Lyon, France) * Umit V Catalyurek (The Ohio State University, USA) * Manuel Chakravarty (University of New South Wales, Australia) * Frédéric Gava (University Paris XII Val de Marne, France) * Alexandros Gerbessiotis (NJIT, USA) * Clemens Grelck (University of Luebeck, Germany) * Iwasaki Hideya (The University of Electro-communications, Japan) * Paul H J Kelly (Imperial College London, UK) * Christoph Kessler (Linköpings Universitet, Sweden) * Rita Loogen (University of Marburg, Germany) * Frédéric Loulergue (The University of Orléans, France) * Kiminori Matsuzaki (The University of Tokyo, Japan) * Samuel Midkiff (Purdue University, USA) * Susanna Pelagatti (University of Pisa, Italy) * Bruno Raffin (INRIA, France) * Casiano Rodriguez Leon (University La Laguna, Spain) ORGANIZERS * Dr. Anne BENOIT Laboratoire d'Informatique du Parallelisme Ecole Normale Supérieure de Lyon 46 Allée d'Italie 69364 Lyon Cedex 07 - France * Pr. Frederic LOULERGUE Laboratoire d'Informatique Fondamentale d'Orléans Université d'Orléans Batiment IIIA - Rue Léonard de Vinci - BP6759 45067 Orléans Cedex 2 - France

1 0

Should the following program be accepted by ghc?
by Bruno Oliveira 17 Jan '08

17 Jan '08

Hello, I have been playing with ghc6.8.1 and type families and the following program is accepted without any type-checking error: > data a :=: b where > Eq :: a :=: a > decomp :: f a :=: f b -> a :=: b > decomp Eq = Eq However, I find this odd because if you interpret "f" as a function and ":=:" as equality, then this is saying that if f a = f b then a = b but clearly this does not hold in general. For example: f 1 = 0 f 2 = 0 So, we have that "f 1 = f 2" but this does not imply that "1 = 2". Ofcourse, that before ghc6.8, we add no type-level functions so maybe it was ok to consider the program above. However, with open type functions the following program is problematic and crashes ghc in style: > type family K a > c :: K a :=: K b -> a :=: b > c Eq = Eq with the following error message: ghc-6.8.1: panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-apple-darwin): Coercion.splitCoercionKindOf base:GHC.Prim.sym{(w) tc 34v} co_aoW{tv} [tv] <pred>main:Bug.K{tc rom} a{tv aoS} [sk] ~ main:Bug.K{tc rom} b{tv aoT} [sk] It seems to me that the "decomp" should be rejected in the first place? Maybe the fact that "decomp" is accepted is a bug in the compiler? Any comments? Cheers, Bruno Oliveira

8 8