- Haskell - Haskell.org

ANN: ListLike-3.0.1
by John Lato 09 Feb '11

09 Feb '11

Hello, I am pleased to announce the release of ListLike-3.0.1. ListLike provides polymorphic functions with a Data.List-style api for many different data types, including lists, arrays, and bytestrings. Changes in ListLike-3.0.1: - The ListLike instance for Data.Map.Map has been removed, as it did not obey several important list properties and could lead to unexpected results. - A new instances for Data.Sequence.Seq has been added - bugfixes in the default instances for groupBy and nubBy - Some default methods have improved performance Many thanks to John Goerzon for his ongoing contributions to the Haskell community. Sincerely, John Lato

1 0

ANN: monad-control-0.2 & a challenge
by Bas van Dijk 09 Feb '11

09 Feb '11

Dear all, I just released control-monad-0.2 a library for lifting control operations, like exception catching, through monad transformers: http://hackage.haskell.org/package/monad-control-0.2 darcs get http://bifunctor.homelinux.net/~bas/monad-control/ To quote the NEWS file: * Use RunInBase in the type of idLiftControl. * Added this NEWS file. * Only parameterize Run with t and use RankNTypes to quantify n and o -liftControl :: (Monad m, Monad n, Monad o) => (Run t n o -> m a) -> t m a +liftControl :: Monad m => (Run t -> m a) -> t m a -type Run t n o = forall b. t n b -> n (t o b) +type Run t = forall n o b. (Monad n, Monad o, Monad (t o)) => t n b -> n (t o b) Bumped version from 0.1 to 0.2 to indicate this breaking change in API. * Added example of a derivation of liftControlIO. This derivation of liftControlIO is really enlightening. It shows the recursive structure of liftControlIO applied to a stack of three monad transformers with IO as the base monad: t1 (t2 (t3 IO)) a: (Note that the derivation in the API documentation also shows the types of the intermediate computations) liftControlIO = liftLiftControlBase $ -- instance MonadControlIO t1 liftLiftControlBase $ -- instance MonadControlIO t2 liftLiftControlBase $ -- instance MonadControlIO t3 idLiftControl -- instance MonadControlIO IO = \f → liftControl $ \run1 → -- Capture state of t1 liftControl $ \run2 → -- Capture state of t2 liftControl $ \run3 → -- Capture state of t3 -- At this point we've captured the state of all transformers -- and have landed in the base (IO) monad. -- So we can start executing f: let run ∷ RunInBase (t1 (t2 (t3 IO))) IO run = -- Restore state liftM (join ∘ lift) ∘ liftM (join ∘ lift) -- Identity conversion ∘ liftM (join ∘ lift) ∘ liftM return -- Run ∘ run3 ∘ run2 ∘ run1 in f run This derivation clearly shows what is happening: first the state of all transformers is captured using the liftControl operations. Each capture supplies us a run function that allows us to run a computation of the respected monad transformer. When we arrive in the base (IO) monad we can start executing f. f expects a run function :: ∀ b. t1 (t2 (t3 IO)) b → IO (t1 (t2 (t3 IO)) b) which allows it to run a t1 computation in IO. The IO computation then returns a new t1 computation that has the final state of the given t1 computation. This can later be used to restore that final state. Although the derivation is correct, I'm not really happy with it from a performance perspective. In the created run function there are two places where it can do better: * The identity conversion: (liftM (join ∘ lift) ∘ liftM return) could be replaced with something more efficient like (liftM (join ∘ lift ∘ return)) or (liftM id) or just id. * The restore conversion: (liftM (join ∘ lift) ∘ liftM (join ∘ lift)) could be replaced with (liftM (join ∘ lift ∘ join ∘ lift)). This transformation is correct according to the Functor law: liftM f ∘ liftM g = liftM (f ∘ g). I haven't figured out yet how to change monad-control in such a way that it generates this more efficient derivation. So I'm posting this as a challenge to you! Good luck, Bas

1 0

Second call for submissions: Monad.Reader special poetry and fiction edition
by Brent Yorgey 08 Feb '11

08 Feb '11

Ten days until the submission deadline. "Nein": what I won't take for an answer. Eighth to eighteenth February, Seven thousand minutes twice, Sick's he who can't write aught. Five submissions now; Four more, at least? Three'd be fair To no- One. http://themonadreader.wordpress.com/2011/01/19/call-for-copy-special-poetry…

1 0

ICFP 2011: Second Call for Papers
by Wouter Swierstra 08 Feb '11

08 Feb '11

===================================================================== Second Call for Papers ICFP 2011: International Conference on Functional Programming Tokyo, Japan, Monday 19 -- Wednesday 21 September 2011 http://www.icfpconference.org/icfp2011 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Titles, abstracts & keywords due: Thursday 17 March 2011 at 14:00 UTC Submissions due: Thursday 24 March 2011 at 14:00 UTC Author response: Tuesday & Wednesday 17-18 May Notification: Monday 30 May 2011 Final copy due: Friday 01 July 2011 Conference: Monday-Wednesday 19-21 September 2011 Scope ~~~~~ ICFP 2011 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, and 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, concurrency, or parallelism. Particular topics of interest include * Language Design: type systems; concurrency and distribution; modules; components and composition; metaprogramming; relations to imperative, object-oriented, or logic programming; interoperability * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; mathematical logic; monads; continuations; delimited continuations; global, delimited, or local effects * Transformation and Analysis: abstract interpretation; partial evaluation; program transformation; program calculation; program proofs; normalization by evaluation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security; education * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By 17 March 2011, 14:00 UTC, submit a title, an abstract of at most 300 words, and keywords. * By 24 March 2011, 14:00 UTC, submit a full paper of at most 12 pages (6 pages for a Functional Pearl and for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.acm.org/sigplan/republicationpolicy.htm In addition, authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no rewiewer will read the annotated copies of the previous reviews. Overall, 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. 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 on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents by signing an additional permission form at the time of the presentation. 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. 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 at http://www.acm.org/sigs/sigplan/authorInformation.htm Submission: Submissions will be accepted electronically at a URL to be named later. Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 48-hour period, starting at 14:00 UTC on Tuesday 17 May 2010, to read reviews and respond to them. Special Journal Issue: There will be a special issue of the Journal of Functional Programming with papers from ICFP 2011. The program committee will invite the authors of select accepted papers to submit a journal version to this issue. Conference Chairs: Manuel M T Chakravarty, University of New South Wales, Australia Zhenjiang Hu, National Institute of Informatics (NII), Japan Program Chair: Olivier Danvy, Aarhus University, Denmark Program Committee: Kenichi Asai, Ochanomizu University, Japan Josh Berdine, Microsoft Research, UK Adam Chlipala, Harvard University, USA William Cook, University of Texas at Austin, USA Maribel Fernandez, King's College London, UK Ronald Garcia, Carnegie Mellon University, USA Neal Glew, Intel Labs, USA Jacques Garrigue, Nagoya University, Japan Suresh Jagannathan, Purdue University, USA Sam Lindley, University of Edinburgh, UK Frank Pfenning, Carnegie Mellon University, USA Paola Quaglia, University of Trento, Italy Alexis Saurin, University of Paris VII, France Mike Spivey, Oxford University, UK Kristian Stoevring, University of Copenhagen, Denmark Doaitse Swierstra, Utrecht University, The Netherlands David Van Horn, Northeastern University, USA Rene Vestergaard, JAIST, Japan Edwin Westbrook, Rice University, USA

1 0

ANNOUNCE: intel-aes-0.1.2 (Accelerated AES and RNG)
by Ryan Newton 08 Feb '11

08 Feb '11

Dear Haskellers, I've released a package to address the topic raised by Simon in this thread: http://www.mail-archive.com/haskell-cafe@haskell.org/msg83901.html I am pleased to announce that it generates random numbers as fast as System.Random.StdGen but with better statistical properties when generators are split. When newer hardware supporting AESNI is available, it will run an additional 2X faster. You can find it here: http://hackage.haskell.org/package/intel-aes https://github.com/rrnewton/intel-aes/wiki This release is non-portable (linux 64-bit only). I'm looking for intrepid Windows hackers to help me get it running on Windows. The underlying Intel AESNI Sample library comes with a .bat, but I haven't got it working yet. Likewise someone who knows how to port assembly to Mac OS... Cheers, -Ryan

1 0

ANN: case-insensitive-0.1
by Bas van Dijk 07 Feb '11

07 Feb '11

Dear all, I had this old module laying around that I wrote some time ago. I dusted it off and uploaded it to Hackage: http://hackage.haskell.org/package/case-insensitive-0.1 The package provides the module Data.CaseInsensitive which exports the CI type constructor which can be parameterised by a string-like type like: String, ByteString, Text, etc.. Comparisons of values of the resulting type are then insensitive to cases. It is my hope that one day packages like snap-core[1], http-types[2] or wai[3] all use this common way of making strings case insensitive. Regards, Bas [1] http://hackage.haskell.org/packages/archive/snap-core/latest/doc/html/Data-… [2] http://hackage.haskell.org/packages/archive/http-types/0.3.0/doc/html/Netwo… [3] http://hackage.haskell.org/packages/archive/wai/latest/doc/html/Network-Wai…

2 2

ANNOUNCE: pwstore 1.0 (Secure password storage)
by Peter Scott 07 Feb '11

07 Feb '11

Hi everyone, If you need to store and verify passwords, the usual advice is to use bcrypt. It neatly handles all the security issues, with a simple API. But Haskell doesn't have bcrypt bindings, so people are tempted to roll their own password storage methods, and perhaps get it wrong. I decided to fix that. The pwstore library handles all the details of password storage for you, in a way that should be so easy to use that there's no reason not to use it. WHAT IT DOES You hash and salt passwords with one function, and verify user input against these password hashes with another function. For more information, see the API docs: http://hackage.haskell.org/packages/archive/pwstore-fast/1.0/doc/html/Crypt… HOW IT WORKS The basic algorithm is this: * Combine the user's password with a randomly-generated salt. * Hash this slowly. By iterating SHA-256 a few thousand times, we make brute-force guessing a lot less practical. * Store this has along with the salt. This scheme is essentially an implementation of the PBKDF1 key derivation function (as specified in RFC 2898) with some convenience code around it to make it easy to use and really hard to mess up. WHERE TO GET IT There are two packages on Hackage, which you can get with cabal-install: 1. pwstore-fast is the preferred version. 2. pwstore-purehaskell has the same API, but only pure Haskell dependencies. It's usable, but about 25 times slower than pwstore-fast. http://hackage.haskell.org/package/pwstore-fast http://hackage.haskell.org/package/pwstore-purehaskell The source code is on GitHub: https://github.com/PeterScott/pwstore/ Any comments, questions, or patches are welcome. -Peter

3 2

ANN: monad-control-0.1
by Bas van Dijk 06 Feb '11

06 Feb '11

Dear all, Several attempts have been made to lift control operations (functions that use monadic actions as input instead of just output) through monad transformers: MonadCatchIO-transformers[1] provided a type class that allowed to overload some often used control operations (catch, block and unblock). Unfortunately that library was limited to those operations. It was not possible to use, say, alloca in a monad transformer. More importantly however, the library was broken as was explained[2] by Michael Snoyman. In response Michael created the MonadInvertIO type class which solved the problems. Then Anders Kaseorg created the monad-peel library which provided an even nicer implementation. monad-control is a rewrite of monad-peel that uses CPS style operations and exploits the RankNTypes language extension to simplify and speedup most functions. A very preliminary and not yet fully representative, benchmark shows that monad-control is on average about 2.6 times faster than monad-peel: bracket: 2.4 x faster bracket_: 3.1 x faster catch: 1.8 x faster try: 4.0 x faster mask: 2.0 x faster Note that, although the package comes with a test suite that passes, I still consider it highly experimental. API DOCS: http://hackage.haskell.org/package/monad-control INSTALLING: $ cabal update $ cabal install monad-control TESTING: The package contains a copy of the monad-peel test suite written by Anders. You can perform the tests using: $ cabal unpack monad-control $ cd monad-control $ cabal configure -ftest $ cabal test BENCHMARKING: $ darcs get http://bifunctor.homelinux.net/~bas/bench-monad-peel-control/ $ cd bench-monad-peel-control $ cabal configure $ cabal build $ dist/build/bench-monad-peel-control/bench-monad-peel-control DEVELOPING: The darcs repository will be hosted on code.haskell.org ones that server is back online. For the time being you can get the repository from: $ darcs get http://bifunctor.homelinux.net/~bas/monad-control/ TUTORIAL: This short unpolished tutorial will explain how to lift control operations through monad transformers. Our goal is to lift a control operation like: foo ∷ M a → M a where M is some monad, into a transformed monad like 'StateT M': foo' ∷ StateT M a → StateT M a The first thing we need to do is write an instance for the MonadTransControl type class: class MonadTrans t ⇒ MonadTransControl t where liftControl ∷ (Monad m, Monad n, Monad o) ⇒ (Run t n o → m a) → t m a If you ignore the Run argument for now, you'll see that liftControl is identical to the 'lift' method of the MonadTrans type class: class MonadTrans t where lift ∷ Monad m ⇒ m a → t m a So the instance for MonadTransControl will probably look very much like the instance for MonadTrans. Let's see: instance MonadTransControl (StateT s) where liftControl f = StateT $ \s → liftM (\x → (x, s)) (f run) So what is this run function? Let's look at its type: type Run t n o = ∀ b. t n b → n (t o b) The run function executes a transformed monadic action 't n b' in the non-transformed monad 'n'. In our case the 't' will be a StateT computation. The only way to run a StateT computation is to give it some state and the only state we have lying around is the one from the outer computation: 's'. So let's run it on 's': instance MonadTransControl (StateT s) where liftControl f = StateT $ \s → let run t = ... runStateT t s ... in liftM (\x → (x, s)) (f run) Now that we are able to run a transformed monadic action, we're almost done. Look at the type of Run again. The function should leave the result 't o b' in the monad 'n'. This 't o b' computation should contain the final state after running the supplied 't n b' computation. In case of our StateT it should contain the final state s': instance MonadTransControl (StateT s) where liftControl f = StateT $ \s → let run t = liftM (\(x, s') → StateT $ \_ → return (x, s')) (runStateT t s) in liftM (\x → (x, s)) (f run) This final computation, "StateT $ \_ → return (x, s')", can later be used to restore the final state. Now that we have our MonadTransControl instance we can start using it. Recall that our goal was to lift "foo ∷ M a → M a" into our StateT transformer yielding the function "foo' ∷ StateT M a → StateT M a". To define foo', the first thing we need to do is call liftControl: foo' t = liftControl $ \run → ... This captures the current state of the StateT computation and provides us with the run function that allows us to run a StateT computation on this captured state. Now recall the type of liftControl ∷ (Run t n o → m a) → t m a. You can see that in place of the ... we must fill in a value of type 'm a'. In our case this will be a value of type 'M a'. We can construct such a value by calling foo. However, foo expects an argument of type 'M a'. Fortunately we can provide one if we convert the supplied 't' computation of type 'StateT M a' to 'M a' using our run function of type ∀ b. StateT M b → M (StateT o b): foo' t = ... liftControl $ \run → foo $ run t However, note that the run function returns the final StateT computation inside M. So the type of the right hand side is now 'StateT M (StateT o b)'. We would like to restore this final state. We can do that using join: foo' t = join $ liftControl $ \run → foo $ run t That's it! Note that because it's so common to join after a liftControl I provide an abstraction for it: control = join ∘ liftControl Allowing you to simplify foo' to: foo' t = control $ \run → foo $ run t Probably the most common control operations that you want to lift through your transformers are IO operations. Think about: bracket, alloca, mask, etc.. For this reason I provide the MonadControlIO type class: class MonadIO m ⇒ MonadControlIO m where liftControlIO ∷ (RunInBase m IO → IO a) → m a Again, if you ignore the RunInBase argument, you will see that liftControlIO is identical to the liftIO method of the MonadIO type class: class Monad m ⇒ MonadIO m where liftIO ∷ IO a → m a Just like Run, RunInBase allows you to run your monadic computation inside your base monad, which in case of liftControlIO is IO: type RunInBase m base = ∀ b. m b → base (m b) The instance for the base monad is trivial: instance MonadControlIO IO where liftControlIO = idLiftControl idLiftControl directly executes f and passes it a run function which executes the given action and lifts the result r into the trivial 'return r' action: idLiftControl ∷ Monad m ⇒ ((∀ b. m b → m (m b)) → m a) → m a idLiftControl f = f $ liftM $ \r -> return r The instances for the transformers are all identical. Let's look at StateT and ReaderT: instance MonadControlIO m ⇒ MonadControlIO (StateT s m) where liftControlIO = liftLiftControlBase liftControlIO instance MonadControlIO m ⇒ MonadControlIO (ReaderT r m) where liftControlIO = liftLiftControlBase liftControlIO The magic function is liftLiftControlBase. This function is used to compose two liftControl operations, the outer provided by a MonadTransControl instance and the inner provided as the argument: liftLiftControlBase ∷ (MonadTransControl t, Monad base, Monad m, Monad (t m)) ⇒ ((RunInBase m base → base a) → m a) → ((RunInBase (t m) base → base a) → t m a) liftLiftControlBase lftCtrlBase = \f → liftControl $ \run → lftCtrlBase $ \runInBase → f $ liftM (join ∘ lift) ∘ runInBase ∘ run Basically it captures the state of the outer monad transformer using liftControl. Then it captures the state of the inner monad using the supplied lftCtrlBase function. If you recall the identical definitions of the liftControlIO methods: 'liftLiftControlBase liftControlIO' you will see that this lftCtrlBase function is the recursive step of liftLiftControlBase. If you use 'liftLiftControlBase liftControlIO' in a stack of monad transformers a chain of liftControl operations is created: liftControl $ \run1 -> liftControl $ \run2 -> liftControl $ \run3 -> ... This will recurse until we hit the base monad. Then liftLiftControlBase will finally run f in the base monad supplying it with a run function that is able to run a 't m a' computation in the base monad. It does this by composing the run and runInBase functions. Note that runInBase is basically the composition: '... ∘ run3 ∘ run2'. However, just composing the run and runInBase functions is not enough. Namely: runInBase ∘ run ∷ ∀ b. t m b → base (m (t m b)) while we need to have ∀ b. t m b → base (t m b). So we need to lift the 'm (t m b)' computation inside t yielding: 't m (t m b)' and then join that to get 't m b'. Now that we have our MonadControlIO instances we can start using them. Let's look at how to lift 'bracket' into a monad supporting MonadControlIO. Before we do that I define a little convenience function similar to 'control': controlIO = join ∘ liftControlIO Bracket just calls controlIO which captures the state of m and provides us with a runInIO function which allows us to run an m computation in IO: bracket ∷ MonadControlIO m ⇒ m a → (a → m b) → (a → m c) → m c bracket before after thing = controlIO $ \runInIO → E.bracket (runInIO before) (\m → runInIO $ m >>= after) (\m → runInIO $ m >>= thing) I welcome any comments, questions or patches. Regards, Bas [1] http://hackage.haskell.org/package/MonadCatchIO-transformers [2] http://docs.yesodweb.com/blog/invertible-monads-exceptions-allocations/ [3] http://hackage.haskell.org/package/monad-peel

1 0

SLE 2011 - 2nd Call for papers
by João Fernandes 06 Feb '11

06 Feb '11

============================================================ 2nd CALL FOR PAPERS SLE 2011 4th International Conference on Software Language Engineering Braga, Portugal, 3-6 July 2011 http://planet-sl.org/sle2011/ Co-located with the 4th Summer School on Generative and Transformational Techniques in Software Engineering (GTTSE 2011) ============================================================= IMPORTANT DATES * 2011: Paper submission: April 08 (midnight Apia Samoa time) Author notification: May 13 Paper submission for online proceedings: June 17 Conference: July 03-06 Camera-ready copy submission for post-proceedings: August 29 --------------------------------------------------------- Software language engineering is devoted to topics related to artificial languages in software engineering. The foremost mission of the International Conference on Software Language Engineering (SLE) is to encourage and organize communication between communities that traditionally have looked at soft- ware languages from different, more specialized, and yet complementary perspectives. Thus, technologies, methods, experiments and case studies from modelware, grammarware, and ontologyware serving the objectives of software languages are of particular relevance to SLE. We invite high-quality submissions to all conference tracks. Submissions must be PDF files following the Springer LNCS style and will be managed using the EasyChair submission system. Please check the conference web site for further information. SLE 2011 will include a Doctoral Symposium that will provide a supportive yet questioning setting in which PhD students can present their work, including goals, methods, and preliminary results. The Symposium aims to provide students with useful guidance and feedback on various aspects of their research from established researchers and the other student attendees. Please forward this call to anyone who might be interested. http://planet-sl.org/sle2011/ --------------------------------------------------------- PAPER SUBMISSION Submitted papers must be original work and must not be previously published in, currently submitted to, or currently in consideration for any journal, book, conference, or workshop. Each submitted paper will be reviewed closely by at least three members of the program committee. Accepted papers will be distributed at the conference via the online proceedings as well as published in the post-proceedings, which will appear in the Springer Lecture Notes in Computer Science (LNCS) series. Authors will have the opportunity to revise their accepted paper(s) for the pre- and post- proceedings. For an accepted paper to appear in the proceedings, at least one author must attend the event and present the work. --------------------------------------------------------- RESEARCH PAPERS Research papers should report a substantial research contribution to SLE and/or a successful application of SLE techniques. We solicit high-quality contributions in the area of SLE ranging from theoretical and conceptual contributions to tools, techniques, and frameworks that support the aforementioned lifecycle activities. We list examples of tools, techniques, applications, and problems of interest to clarify the types of contributes that we seek: * Formalisms used in designing and specifying languages and tools that analyze such language descriptions * Language implementation techniques * Program and model transformation tools * Composition, integration, and mapping tools for managing different aspects of software languages or different manifestations of a given language * Transformations and transformation languages between languages and models * Language evolution * Approaches to elicitation, specification, or verification of requirements for software languages * Language development frameworks, methodologies, techniques, best practices, and tools for the broader language lifecycle covering phases such as analysis, testing , and documentation. * Design challenges in SLE * Applications of languages including innovative domain-specific languages or "little" languages The preceding list is neither exclusive nor exhaustive. Visit the conference web site for more information about the scope and topics of interest of SLE, or contact the program co-chairs with questions. Page limit: 20 --------------------------------------------------------- SHORT PAPERS Short papers may describe interesting or thought-provoking concepts that are not yet fully developed or evaluated, make an initial contribution to challenging research issues in SLE, or discuss and analyze controversial issues in the field. Page limit: 10 --------------------------------------------------------- TOOL DEMONSTRATION PAPERS Because of SLE's ample interest in tools, we seek papers that present software tools related to the field of SLE. These papers will accompany a tool demonstration to be given at the conference. The selection criteria include the originality of the tool, its innovative aspects, the relevance of the tool to SLE, and the maturity of the tool. Submissions may also include an appendix (that will not be published) containing additional screen-shots and discussion of the proposed demonstration. Page limit: 10 --------------------------------------------------------- MINI-TUTORIAL PAPERS SLE is composed of various research areas, such as grammarware, modelware, language schemas, and semantic technologies. The cross product of attendees at SLE creates a situation where the contribution from one session may be difficult to understand by those not initiated to the area. To help unite the various communities of SLE 2011, we solicit mini-tutorials that provide discussion points for mapping common ideas between related and complementary research topics of SLE. A mini-tutorial submission should be between 15 and 20 pages. --------------------------------------------------------- DOCTORAL SYMPOSIUM The Doctoral Symposium provides a forum for both early and late-stage PhD students to present their research and get detailed feedback and advice from researchers both in and out of their particular research area. Submissions are invited from PhD students working on any topic that falls within the SLE conference remit. Submissions consist of two parts, a research abstract and a letter of recommendation from the student's supervisor. See the upcoming Doctoral Symposium call for submissions for full details. Participants will also be invited to present a poster on their research as part of the conference poster session. ------------------------------------------------------------ GENERAL CHAIR João Saraiva Universidade do Minho, Portugal jas(a)di.uminho.pt PROGRAM CO-CHAIRS Uwe Aßmann Dresden University of Technology, Germany uwe.assmann(a)tu-dresden.de Anthony Sloane Macquarie University, Australia anthony.sloane(a)mq.edu.au DOCTORAL SYMPOSIUM CHAIRS Perdita Stevens University of Edinburgh, UK perdita.stevens(a)ed.ac.uk Eric Van Wyk University of Minnesota, USA evw(a)cs.umn.edu PROGRAM COMITTEE Adrian Johnstone, University of London, UK Aldo Gangemi, Semantic Technology Laboratory, Italy Alexander Serebrenik, Eindhoven University of Technology, Netherlands Ana Moreira, FCT/UNL, Portugal Anthony Cleve, University of Namur, Belgium Anya Helene Bagge, University of Bergen, Norway Bernhard Rumpe, Aachen University, Germany Bijan Parsia, University of Manchester, UK Brian Malloy, Clemson University, USA Bruno Oliveira, Seoul National University, Korea Chiara Ghidini, FBK-irst, Italy Daniel Oberle, SAP Research, Germany Eelco Visser, Delft University of Technology, Netherlands Eric Van Wyk, University of Minnesota, USA Fernando Pereira, Federal University of Minas Gerais, Brasil Fernando Silva Parreiras, University of Koblenz-Landau, Germany Friedrich Steimann, University of Hannover, Germany Görel Hedin, Lund University, USA Ivan Kurtev, University of Twente, Netherlands James Power, National University of Ireland, Ireland Jean-Marie Favre, OneTree Technologies, France Jeff Gray, University of Alabama, USA Jeff Z. Pan, University of Aberdeen, UK João Paulo Fernandes, Univ. of Minho& Univ. of Porto, Portugal John Boyland, University of Wisconsin-Milwaukee, USA John Grundy, Swinburne University of Technology, Australia Jordi Cabot, University of Toronto, Canada Jurgen Vinju, CWI, Netherlands Laurence Tratt, Middlesex University, UK Marjan Mernik, University of Maribor, Slovenia Mark van den Brand, Eindhoven University of Technology, Netherlands Michael Collard, University of Akron, USA Nicholas Kraft, University of Alabama, USA Paul Klint, CWI, Netherlands Paulo Borba, Federal University of Pernambuco, Brazil Peter Haase, University of Karlsruhe, Germany Peter Mosses, Swansea University, UK Ralf Möller, Hamburg University of Technology, Germany Silvana Castano, University of Milan, Italy Steffen Zschaler, Lancaster University, UK York Sure, University of Koblenz-Landau, Germany Zhenjiang Hu, National Institute of Informatics, Japan ORGANIZATION COMMITTEE José Creissac Campos (Finance Chair) Universidade do Minho, Portugal João Paulo Fernandes (Web and Publicity co-Chair) Universidade do Porto& Universidade do Minho, Portugal Jurgen Vinju (Workshop Selection Chair) CWI, The Netherlands Vadim Zaytsev (Publicity co-Chair) CWI, The Netherlands

1 0

Polymorphic types in RHS of type instances
by Steven Keuchel 05 Feb '11

05 Feb '11

Hi list, I was wondering why GHC doesn't allow usage of polymorphic types in the right-hand side of type instance declarations for type families. The GHC user guide states: "The right-hand side of a type instance must be a monotype (i.e., it may not include foralls) [...]", but it doesn't state the reason. I stumbled upon this limitation when I was trying to generically calculate Johann's and Ghani's interpreter (transformers) for nested data types from their "Initial Algebra Semantics is Enough!" paper. Cheers, Steven

1 0