November 2007 - Haskell

CFP --- FOAL: Foundations of Aspect-Oriented Languages
by Ralf Laemmel 23 Nov '07

23 Nov '07

[You can actually check that indeed Haskell folks have contributed to this workshop in the past. -- Ralf] Call for papers: FOAL: *F*oundations *o*f *A*spect-Oriented *L*anguages A one day workshop affiliated with AOSD 2008 in Brussels, Belgium, on 31 March or 1 April 2008. Themes and Goals *FOAL* is a forum for research in foundations of aspect-oriented programminglanguages. Areas of interest include but are not limited to: - Semantics of aspect-oriented languages - Specification and verification for such languages - Type systems - Static analysis - Theory of testing - Theory of aspect composition - Theory of aspect translation (compilation) and rewriting The workshop aims to foster work in foundations, including formal studies, promote the exchange of ideas, and encourage workers in the semantics and formal methods communities to do research in the area of aspect-oriented programming languages. All theoretical and foundational studies of this topic are welcome. The goals of FOAL are to: - Make progress on the foundations of aspect-oriented programming languages. - Exchange ideas about semantics and formal methods for aspect-oriented programming languages. - Foster interest within the programming language theory and types communities in aspect-oriented programming languages. - Foster interest within the formal methods community in aspect-oriented programming and the problems of reasoning about aspect-oriented programs. Workshop Format The planned workshop format is primarily presentation of papers and group discussion. Talks will come in three categories: long (30 minutes plus 15 minutes of discussion), regular (20 minutes plus 5 minutes of discussion) and short (7 minutes plus 3 minutes of discussion). The short talks will allow for presentations of topics for which results are not yet available, perhaps for researchers who are seeking feedback on ideas or seek collaborations. We also plan to ensure sufficient time for discussion of each presentation by limiting the overall number of talks. Submissions Invitation to the workshop will be based on papers selected by the program committee; those wishing to attend but not having a paper to submit should contact the organizers directly to see if there is sufficient space in the workshop. FOAL solicits long, regular, and short papers on all areas of formal foundations of AOP languages. Submissions will be read by the program committee and designated reviewers. Papers will be selected for long, regular, and short presentation at the workshop based on their length, scientific merit, innovation, readability, and relevance. Papers previously published or already being reviewed by another conference are not eligible. Some papers may not be selected for presentation, and some may be selected for presentation in shorter talks than their paper length would otherwise command. We will limit the length of paper presentations and the number of papers presented to make sure that there is enough time for discussion. Papers presented at the workshop will be included in the ACM Digital Library, hence authors of accepted papers will be asked to transfer copyright to the ACM. However, as FOAL is a workshop, publication of extended versions of the papers in other venues will remain possible. We will also investigate having a special issue of a journal for revisions of selected papers after the workshop. Authors should note the following details: - Submissions are due no later than 23:00 GMT, 11 January 2008 (This is a firm deadline.) - Authors must indicate whether they wish to be considered for a long, regular, or short presentation. - Papers for long presentations must not exceed 10 pages in length; those for regular presentations must not exceed 7 pages in length, and those for short presentations must not exceed 3 pages in length. - We encourage use of the ACM Conference format for submissions, as this will be required for accepted papers. You must add page numbers (which are not part of the standard format) to your submissions, to make adding comments easier. We will notify the corresponding author of papers that are selected for presentation at the workshop by 8 February 2008. Early registration for AOSD (you must register for AOSD to attend the workshop) will end on 25 February 2008. Final versions of papers for the proceedings will be due on 1 March 2008. For more information, visit the FOAL Workshop home page (at http://www.eecs.ucf.edu/FOAL) Important Dates Submission Deadline 23:00 GMT, 11 January 2008 Notification of Acceptance 8 February 2008 Final Versions of Papers Due 1 March 2008 Workshop 31 March 2008 or 1 April 2008 Program Committee We are pleased to have assembled another exceptional program committee for FOAL this year: - Curtis Clifton (Program Committee Chair)— Rose-Hulman Institute of Technology - Jonathan Aldrich — Carnegie Mellon University - Paulo Borba — Universidade Federal de Pernambuco - Lodewijk Bergmans — University of Twente - William Griswold — University of California, San Diego - Günter Kniesel — University of Bonn - Shriram Krishnamurthi — Brown University - Ralf Lämmel — Universität Koblenz-Landau - Karl Lieberherr — Northeastern University - Hidehiko Masuhara — University of Tokyo - James Noble — Victoria University of Wellington - Klaus Ostermann — Darmstadt University of Technology - Hridesh Rajan — Iowa State University - Damien Sereni — Oxford Organizers - Gary T. Leavens — University of Central Florida - Curtis Clifton — Rose-Hulman Institute of Technology - Mira Mezini — Darmstadt University of Technology - Shmuel Katz — Technion–Israel Institute of Technology

1 0

Call for Contributions - Haskell Communities and Activities Report, December 2007 edition
by Andres Loeh 21 Nov '07

21 Nov '07

Dear Haskellers, so much has happened in the Haskell world in the past months. Therefore, although later than usual, I would very much like to collect contributions for the 13th edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/communities/ Submission deadline: 7 December 2007 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) ================================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it to the me. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! * If you are interested any project related to Haskell that has not previously been mentioned in the HC&A Report, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming 6 months. If you have only recently been exposed to Haskell, it might be a good idea to browse the May 2007 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! As the purpose of the report is to collect recent or current activities, I encourage you to update all existing summaries and reports. I will probably drop any topics that have not had any activity for the past year, i.e., since November 2006, but I would very much prefer you to present an updated description of the topic. Of course, new entries are more than welcome. Reports should generally be kept brief and informative, ranging from a few sentences to a few hundred words, to keep the whole report reasonably sized. Looking forward to your contributions, Andres (current editor) FAQ: Q: Which topics are relevant? A: *All* topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports over distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics I don't even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write ``wishlist'' items for libraries and language features you would like to see implemented. Q: How much should I write? A: There's no formal limit. But generally, entries should be short and to the point. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. There also is no minimum length of an entry! The reports aims at being as complete as possible, so please consider writing an entry, even if it's only a few lines long. Q: If I don't update my entry, but want to keep it in the report, what should I do? A: Tell me that there are no changes. I will reuse the old entry in this case, but I might drop it if it's older than a year, to give more room and more attention to projects that change a lot. Don't resent complete entries if you haven't changed them. Q: What format should I write in? A: The best format is a LaTeX source file, adhering to the template that's available at: http://haskell.org/communities/11-2007/template.tex There's also a LaTeX style file at http://haskell.org/communities/11-2007/hcar.sty that you can use to preview your entry. If you don't know LaTeX, then use plain text. If you modify an old entry, I will send you your old entry as a template within the next days.Please modify that template, rather than using your own version of the old entry about a template. Don't worry about writing correct LaTeX, I will be able to handle your file. Please don't use HTML or even DOC.

1 0

ANNOUNCE: fixpoint 0.1
by Roman Leshchinskiy 21 Nov '07

21 Nov '07

I'm pleased to announce fixpoint 0.1, a (for now) small generic programming library which allows data types to be manipulated as fixpoints of their underlying functors. The library is mostly based on "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire" by Erik Meijer, Maarten Fokkinga and Ross Paterson. The basic idea is to use associated data types, a recent GHC extension, to associate recursive types with their underlying functors. The core of the library is just one typeclass: class Functor (Pre t) => Fixpoint t where data Pre t :: * -> * -- | Projection from the data type to its underlying functor. project :: t -> Pre t t -- | Injection from the underlying functor into the data type. inject :: Pre t t -> t Here, Pre t is a functor such that its fixpoint is t. For instance, for lists we have: instance Fixpoint [a] where data Pre [a] s = Nil | Cons a s project [] = Nil project (x:xs) = Cons x xs inject Nil = [] inject (Cons x xs) = x : xs With this, we can easily define things like catamorphisms: cata :: Fixpoint t => (Pre t s -> s) -> t -> s cata f = f . fmap (cata f) . project which can then be used for generic programming: size :: (Fixpoint t, Foldable (Pre t)) => t -> Int size = cata (F.foldr (+) 1) At the moment, the package doesn't contain much more than the above but this will change soon(ish). To enjoy the minimalistic interface of fixpoint-0.1, grab it from Hackage or from my site: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fixpoint-0.1 http://www.cse.unsw.edu.au/~rl/code/fixpoint.html Comments and suggestion are always welcome. Roman

3 3

recursive deriving
by Alex Jacobson 21 Nov '07

21 Nov '07

When you want automated deriving of show/read etc., you need all the components of your type also to be instances of show/read but you won't want to *require* them to be automatically generated verions. Standalone deriving does the wrong thing here. Standalone deriving should not cause an overlapping instance error if someone derives an instance manually. Instead, the manually derived instance should be treated as more specific and win out. The other part of this problem is that you can't do automatic recursive deriving and this results in a ridiculous amount of boilerplate. I know some people have a theory that they want to avoid accidentally creating instances for things that shouldn't have them, but the solution to that is probably to add some declaration for types that prohibits automatic deriving for those types. The 99% case is that automatic deriving is ok. Proposed syntax: derive instance Show T recursively data T = T no-deriving (Ord,Eq) -Alex-

1 0

Coq Tutorial at POPL 2008: Using Proof Assistants for Programming Language Research
by Stephanie Weirich 20 Nov '07

20 Nov '07

====================================================================== Tutorial Announcement and Call for Participation Using Proof Assistants for Programming Language Research Or: How to Write Your Next POPL Paper in Coq San Francisco, CA, 8 Jan 2008 Co-located with POPL 2008 Sponsored by ACM SIGPLAN http://plclub.org/popl08-tutorial/ ======================================================================= The University of Pennsylvania PLClub invites you to participate in a tutorial on using the Coq proof assistant to formalize programming language metatheory. This tutorial will be tailored to people who are familiar with syntactic proofs of programming language metatheory (type soundness, etc.), but have never used a proof assistant. At the end of the day, participants will have a reading knowledge of Coq and a running start on using Coq in their own work. This tutorial will be hands-on, with breaks for exercises; participants are strongly encouraged to bring a laptop running Coq 8.1 (or a later release) and either Proof General or CoqIDE. Tutorial topics - Defining language semantics in Coq - Abstract syntax - Inductively-defined relations - Derivations - Proving simple results - Fundamental tactics - Automation - Forward and backward reasoning - Scaling up to POPLmark - Semantic functions and conversion - Sets and environments - Representing binding - Locally nameless representation - Freshness through cofinite quantification - Syntactic type soundness Registration will be through the POPL 2008 registration site: http://www.regmaster.com/conf/popl2008.html The tutorial is organized and presented by members of the University of Pennsylvania PLClub: Brian Aydemir, Aaron Bohannon, Benjamin Pierce, Jeffrey Vaughan, Dimitrios Vytiniotis, Stephanie Weirich, and Steve Zdancewic. Questions can be sent to Stephanie Weirich (sweirich(a)cis.upenn.edu)

1 0

Recruiting functional programmers
by John Hughes 20 Nov '07

20 Nov '07

Interested in recruiting Haskell programmers from Chalmers/Gothenburg university? As an experiment, I am planning a recruitment event here in December-see www.jobs-in-fp.org for how to take part. John Hughes

1 0

MTL violates coverage condition?
by Mike Haskel 20 Nov '07

20 Nov '07

Hi, A bit of a detailed technical question. I'm writing a library which makes heavy use of the MTL (Monad.State, etc) and monad transformers. I have a monad transformer, MymonadT, which I want to inherit relevant type classes from the monads it transforms, i.e. MonadState s m => MonadState s (MymonadT m). The MTL itself uses such instance declarations, such as MonadState s m => MonadState s (ReaderT r m). When I compile my library however (using ghc-6.6.1 and -fglasgow-exts) I get an illegal instance declaration error: "The Coverage Condition fails for one of the functional dependencies; Use -fallow-undecidable-instances to permit this." The code compiles with -fallow-undecidable-instances. As a reminder, MonadState is declared as class Monad m => MonadState s m | m -> s The coverage condition is described in http://research.microsoft.com/~simonpj/papers/fd-chr/jfp06.pdf on page 12. My own analysis suggests that the declaration of MonadState for ReaderT violates this condition as well. The coverage condition exists, this paper claims, to prevent infinite loops in type inference---someone could use some instance declarations violating this condition to write a function whose type is undecidable. Does 'MonadState s m => MonadState s (ReaderT r m)', found in Control.Monad.Reader violate the coverage condition as I believe it does? Can one write a function using this library to force the type inference engine to loop indefinitely? If not, what mitigating conditions prevent it? Can I write a similar declaration in my library and compile it with -fallow-undecidable-instances and without worry? Thanks, Mike

2 1

Re: [Haskell-cafe] ANN: The Monad.Reader Issue 9: SoC special
by Yitzchak Gale 19 Nov '07

19 Nov '07

Wouter Swierstra wrote: >> I am pleased to announce that a new issue of The Monad.Reader is now >> available: >> http://www.haskell.org/haskellwiki/The_Monad.Reader Dougal Stanton wrote: > Thanks Wouter, the haiku look great! ;-) I agree, they are fantastic! (And they are not "short".) Perhaps you were inspired by the classic 1998 Salon haiku challenge. In any case, I think a reference is appropriate: http://archive.salon.com/21st/chal/1998/01/26chal.html http://archive.salon.com/21st/chal/1998/02/10chal2.html Regards, Yitz

1 0

ANN: The Monad.Reader Issue 9: SoC special
by Wouter Swierstra 19 Nov '07

19 Nov '07

I am pleased to announce that a new issue of The Monad.Reader is now available: http://www.haskell.org/haskellwiki/The_Monad.Reader Issue 9 is a "Summer of Code Special" - it consists of three articles from student participants of Google's Summer of Code, describing the projects they worked on: * Thomas Schilling Cabal Configurations * Jason Dagit Darcs Patch Theory * Mathieu Boespflug TaiChi: how to check your types with serenity The Monad.Reader is a quarterly magazine about functional programming. It is less formal than a journal, but somehow more enduring than a wiki page or blog post. If you'd like to write something for the next issue of The Monad.Reader, please get in touch. I haven't fixed the deadline for the next issue just yet. I hope to send out an official call for copy fairly soon. Enjoy! Wouter 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

Bang patterns and declaration order
by Iavor Diatchki 19 Nov '07

19 Nov '07

Hello, I was playing around with "bang patterns" and I noticed that when combined with asynchronous exceptions they can lead to programs where the order of the declarations in a binding group is important! Here is an example: > import Control.Exception > import Prelude hiding (catch) > > main = putStrLn =<< eval_order > > test = "no exception" > where !_ = error "top down" > !_ = error "bottom up" > > eval_order = evaluate test `catch` \e -> > case e of > ErrorCall txt -> return txt > _ -> throw e Of course, this is a contrived exampled but, as far as I know, this was not possible in Haskell before (if anyone has an example to the contrary please send it to the list). By the way, with GHC 6.8.1 the above program prints "bottom up". This means that when there are multiple "banged" bindings they are evaluated starting with the last one in the text. I imagine than in most programs this is not particularly important, but it seems to me that it would be a bit nicer if we were to adjust the translation so that bindings were evaluated top to bottom (e.g., like in ML). Finally, the above program is accepted by GHC 6.8.1 without any special flags (e.g., no need for -XBangPatterns). Is this intentional? -- Iavor

5 4