April 2015 - Haskell-Cafe

Anyone interested in taking over network-uri?
by Johan Tibell 14 Apr '15

14 Apr '15

Hi! I find myself with less time to hack lately and I'm trying to reduce the number of libraries I maintain so I can invest time in new things. Would anyone be interested taking over maintenance of network-uri? It should not be much work at all. Bump a few dependencies and fix a bug or two. The package is very widely used so I suggest that the new maintainer should avoid breaking changes whenever possible*. * In other words, if you want to completely rethink network URI handling, this package is probably not the place for it. -- Johan

4 5

Haskell Weekly News
by Kim-Ee Yeoh 14 Apr '15

14 Apr '15

*Top picks:* - Aditya Siram announces the first release of Haskell bindings <http://haskell.1045720.n5.nabble.com/Announcement-FLTKHS-Bindings-to-the-FL…> to the C++-based FLTK cross-platform GUI library. FLTK <http://www.fltk.org/> can be used to build a modern windows-and-widgets-based desktop app and comes with a UI builder called FLUID. - The startup called Helium releases a "homegrown Webmachine-inspired web framework in Haskell." <http://blog.helium.com/helium/2015/04/01/helium-webmachine-airship.html> Airship is very small (just under 1000 LoC) and extremely unopinionated: it works with any WAI-compatible web server and any templating language (including none at all!). Reddit discussion. <http://www.reddit.com/r/haskell/comments/312pk2/haskell_webmachine_airship/> - Adam Chlipala releases a new Ur/Web library for producing custom event-planning web apps <http://www.impredicative.com/pipermail/ur/2015-April/001928.html> quickly. All you need to do is "assemble highly parametrized components." - Abe Voelker <https://blog.abevoelker.com/you-got-haskell-in-my-ruby-cleaner-ruby-validat…> finds himself wanting algebraic data types and pattern matching when writing Ruby. He presents an evolution of a file upload validator, culminating in a finale that uses an Either monad provided by a Ruby gem called Kleisli. - Eitan Chatav shares a correct-by-construction JSON serializer/deserializer <http://lpaste.net/130064> using lens-json. - Wouldn't it be neat to get profiling info without stopping the program and pissing off your users? Mark Wotton <https://ghc.haskell.org/trac/ghc/ticket/10235> has filed exactly such a feature request. - Is Call Arity optimization to blame for your 7.10 compilation slowdowns? Joachim Breitner <http://ghc.haskell.org/trac/ghc/ticket/10293> investigates. - Ever felt Haskell on Windows is 2nd class, even though it's Tier-1 according to the Platform? Well, installing hmatrix on Win requires additional steps, as Redditor wrvn <http://www.reddit.com/r/haskell/comments/322iut/trying_to_install_hmatrix_o…> kindly explains. - Do you program in Haskell using emacs? You must be using haskell-mode then. Here's monthly news <https://github.com/haskell/haskell-mode/wiki/Month-in-haskell-mode-March-20…> straight from the haskell-mode development team. - Dominic Steinitz <http://haskell.1045720.n5.nabble.com/A-Random-Strawman-tp5768239.html> raises awareness about the brokenness of System.Random. Solution? Use tf-random for now. - Big number exponentiation segfaults, in this reddit discussion. <http://www.reddit.com/r/haskell/comments/31yajd/can_you_explain_this/> Turns out it's a bug <https://ghc.haskell.org/trac/ghc/ticket/10282> involving the GNU Multi-precision Library. Make sure you have the latest GMP version 6. - Devan Stormont <https://voyageintech.wordpress.com/2015/04/02/haskell-library-for-forecast-…> creates his first hackage library that obtains weather forecast data via a web-based API. He writes, "The really brilliant part is in being able to completely replace a core piece of an app within a single day and having complete confidence in the result. It’s moments like this that make you really happy to be working with such a powerful language as Haskell." - Carl <http://stackoverflow.com/questions/29455850/pretty-printing-with-free-monad…> reminds us that GADT can always be pattern-matched in a case expression. "It's let expressions that cause GHC to provide amusing messages about its brain exploding." - Zohaib Rauf <http://zohaib.me/yet-another-what-is-a-monad-post/> publishes a monad tutorial. He explains that the 'M' in 'M a' is "some metadata wrapped around 'a'." *Tweets of the week:* - John Carmack: <https://twitter.com/ID_AA_Carmack/status/585871417855516672> If I had to write software that my life depended on, I would seriously consider using Haskell. - shanelogsdon: <https://twitter.com/shanelogsdon/status/586145419639578625> tried the #haskell web framework http://www.spock.li/ last night with a meaningless micro benchmark. ~38k req/s is pretty quick - AlexanderKatt: <https://twitter.com/AlexanderKatt/status/583279982186786817> 'it is entirely unnecessary to understand category theory in order to understand monads in #haskell' said the guys who know category theory - justusadam_: <https://twitter.com/justusadam_/status/586939066748379136> I'm warming up to the idea of using #Haskell more. Wonderful language but the syntax and some of the concepts were difficult to understand - least_nathan: <https://twitter.com/least_nathan/status/581544451597709312> Algebraic Data Types Considered Harmful: once you use them, every language lacking them drives you to madness. #LangSec - chwthewke: <https://twitter.com/chwthewke/status/583385239138996224> #Haskell is a very hot programming language :) No, really, an hour of it and my laptop is on the verge of becoming a brown dwarf :D - robinbateboerop: <https://twitter.com/robinbateboerop/status/583396694047481857> Troll tries to get banned from #Haskell IRC channel, decides to learn Haskell <http://buff.ly/1NFKWiX> instead. - stephan_gfx: <https://twitter.com/stephan_gfx/status/583493468162400256> Cool, cabal will multithread installation/build if you run it with the -j option. cabal install -j <package_name> - Pythux: <https://twitter.com/Pythux/status/583535948408958976> One thing I learned at Haskell's meetup yesterday: it's possible to create a start-up with Haskell full stack! #Haskell #Awesome *Quote of the week:* - Lisp, Haskell and other FP are currently killing it in the quiet world of DSLs, especially Mining, Oil & Gas industries which need to parse petaflops of seismic data and reservoir simulations, need rapid prototyping, need formally verified drilling platform components that field engineers can interact with easily, and HPC algorithms for financial trading. -- Source <https://news.ycombinator.com/item?id=9317567#up_9318837> -- Kim-Ee

1 0

ANNOUNCE: fast-tags 1.0
by Evan Laforge 13 Apr '15

13 Apr '15

fast-tags makes vi (and now emacs) tags from haskell source. It does so quickly and incrementally. I have it bound to vim's BufWrite to keep tags always updated, and it's basically instant. It works with hsc, literate haskell, and mid-edit files with syntax errors. I've announced this before, but I'm doing it again because it's been a long time and there was a major update. I bumped to 1.0 to reflect that it's not dead, it just does everything I need it to do, so further development is unlikely unless someone finds a bug. That's just for me of course, if someone else wants to add features they are welcome to do so. The major update was almost entirely thanks to Sergey Vinokurov and a few others who contributed a bunch of patches. Details and changelog are at http://hackage.haskell.org/package/fast-tags-1.0 Source is at https://github.com/elaforge/fast-tags

1 0

[Announcement] FLTKHS - Bindings to the FLTK GUI Toolkit
by aditya siram 13 Apr '15

13 Apr '15

I'm pleased to announce the first release of Haskell bindings [1] to the FLTK GUI [2] toolkit. It now works smoothly on Windows (64-bit), Linux and Mac allowing you to create truly cross-platform native GUI applications in pure Haskell and deploy statically linked executables with no dependencies. Most of the FLTK API is covered except for a few minor widgets which I plan to get to in the next release. Motivation behind the package and installation instructions are found in the Haddocks [3]. And to get you started it ships with a number of demos. If you have any issues please report them on the Github [4] page. I'd also love any other feedback so feel free to comment here or email me at the address listed on the Hackage [5] page. Hope you enjoy! [1] https://hackage.haskell.org/package/fltkhs-0.1.0.2 [2] http://fltk.org [3] https://hackage.haskell.org/package/fltkhs-0.1.0.2/docs/Graphics-UI-FLTK-Lo… [4] http://github.com/deech/fltkhs [5] https://hackage.haskell.org/package/fltkhs-0.1.0.2

2 2

Static executables in minimal Docker containers
by Michael Snoyman 13 Apr '15

13 Apr '15

I'm trying to put together a minimal Docker container consisting of nothing but GHC-compiled static executables. Below you can see a full interaction I've had with GHC and Docker. The high level summary is that: * When compiled statically, the executable runs just fine in both my host OS (Ubuntu 14.04) and an Ubuntu 14.04 Docker image * That same executable run from a busybox (or a "scratch" image, not shown here since it's slightly longer to set up) hangs and then runs out of memory I've watched the process in top, and it uses up a huge amount of CPU and memory. I get the same behavior whether I compiled with or without optimizations or the multithreaded runtime. I also get identical behavior with both GHC 7.8.4 and 7.10.1. I'm not sure how best to proceed with trying to debug this, any suggestions? vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ cat > hello.hs <<EOF main :: IO () main = putStrLn "Static Hello" EOF vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ghc -optl-static -optl-pthread hello.hs -static [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... /opt/ghc/7.8.4/lib/ghc-7.8.4/rts-1.0/libHSrts.a(Linker.o): In function `internal_dlopen': (.text+0x5c): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ./hello Static Hello vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ docker run --rm -v $(pwd)/hello:/usr/local/bin/hello:ro ubuntu:14.04 /usr/local/bin/hello Static Hello vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ docker run --rm -v $(pwd)/hello:/usr/local/bin/hello:ro busybox /usr/local/bin/hello hello: out of memory (requested 1048576 bytes) vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4

2 2

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Simon Peyton Jones 13 Apr '15

13 Apr '15

David If you would like to lead a debate, and drive it to a conclusion, that would be most helpful. Usually it's constructive to write a wiki page that sets out the design choices, with examples to illustrate their consequences, to set the terms of the debate. Otherwise you risk misunderstandings, with red herrings being discussed repeatedly. Thanks Simon | -----Original Message----- | From: davidterei(a)gmail.com [mailto:davidterei@gmail.com] On Behalf Of | David Terei | Sent: 12 April 2015 09:52 | To: Simon Peyton Jones | Cc: Omari Norman; ghc-devs(a)haskell.org; haskell Cafe | Subject: Re: Generalized Newtype Deriving not allowed in Safe Haskell | | On 10 April 2015 at 01:48, Simon Peyton Jones <simonpj(a)microsoft.com> | wrote: | > | prefer, such as only exporting the Coerce instance if all the | > | constructors are exported, it seems that the ship sailed on these | > | > Coercible is relatively recent; I don't think we should regard it as | cast in stone. | > | > But yes, the Coerbible instance of a newtype is only available when | the data constructor for the newtype is lexically in scope. | | Yes, so as you point out in the paper, this is done to preserve | abstractions, but the same rule isn't applied to data types since some | types like IORef don't even have constructors that can be in scope. | | Ideally I'd like to find a way forward that works for everyone and | isn't just a Safe Haskell mode setting. | | I think the first question is, are there situations where you'd want to | use `coerce` internally to a module but disallow it externally? The | role mechanism is a little awkward as it doesn't allow this (although | it does for newtype's). If yes, then I think we should start there. | | If it seems we don't need external vs internal control, then we could | simply change the default to be that GHC sets referential type | parameters to nominal and allows them to be weakened to referential | through role annotations. We could use hackage to test how much | breakage this would cause. | | The third option is something Safe Haskell specific, so probably | applying the newtype constructor rule to data types. | | > | > Simon | > | > | -----Original Message----- | > | From: davidterei(a)gmail.com [mailto:davidterei@gmail.com] On Behalf | > | Of David Terei | > | Sent: 10 April 2015 09:38 | > | To: Simon Peyton Jones | > | Cc: Omari Norman; haskell Cafe; ghc-devs(a)haskell.org | > | Subject: Re: Generalized Newtype Deriving not allowed in Safe | > | Haskell | > | | > | I'll prepare a patch for the userguide soon. | > | | > | As for something better, yes I think we can and should. It's on my | > | todo list :) Basically, the new-GND design has all the mechanisms | > | to be safe, but sadly the defaults are rather worrying. Without | > | explicit annotations from the user, module abstractions are | broken. | > | This is why we left GND out of Safe Haskell for the moment as it | is | > | a subtle and easy mistake to make. | > | | > | If the module contained explicit role annotations then it could be | > | allowed. The discussion in | > | https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions | > | that I prefer, such as only exporting the Coerce instance if all | > | the constructors are exported, it seems that the ship sailed on | > | these bigger changes sadly. | > | | > | Cheers, | > | David | > | | > | On 9 April 2015 at 00:56, Simon Peyton Jones | > | <simonpj(a)microsoft.com> | > | wrote: | > | > There is a long discussion on | > | > https://ghc.haskell.org/trac/ghc/ticket/8827 | > | > about whether the new Coercible story makes GND ok for Safe | Haskell. | > | > At a type-soundness level, definitely yes. But there are other | > | > less-clear-cut issues like “breaking abstractions” to consider. | > | The > decision on the ticket > (comment:36) seems to be: GND | stays | > | out of Safe Haskell for now, but > there is room for a better | > | proposal. | > | > | > | > | > | > | > | > I don’t have an opinion myself. David Terei and David Mazieres | > | are in > the driving seat, but I’m sure they’ll be responsive to | user input. | > | > | > | > | > | > | > | > However, I think the user manual may not have kept up with | #8827. | > | The | > | > sentence “GeneralizedNewtypeDeriving — It can be used to violate | > | > constructor access control, by allowing untrusted code to | > | manipulate > protected data types in ways the data type author did | > | not intend, > breaking invariants they have established.” | vanished | > | from the 7.8 > user manual (links below). Maybe it should be | restored. | > | > | > | > | > | > | > | > Safe Haskell aficionados, would you like to offer a patch for | the | > | manual? | > | > And maybe also a less drastic remedy than omitting GND | altogether? | > | > | > | > | > | > | > | > Simon | > | > | > | > | > | > | > | > From: Omari Norman [mailto:omari@smileystation.com] > Sent: 09 | > | April 2015 02:44 > To: haskell Cafe > Subject: Generalized | Newtype | > | Deriving not allowed in Safe Haskell > > > > When compiling | code | > | with Generalized Newtype Deriving and the > -fwarn-unsafe flag, I | > | get > > > > -XGeneralizedNewtypeDeriving is not allowed in Safe | > | Haskell > > > > This happens both in GHC 7.8 and GHC 7.10. | > | > | > | > | > | > | > | > I thought I remembered reading somewhere that GNTD is now part | of | > | the > safe language? The GHC manual used to state that GNTD is | not | > | allowed > in Safe > Haskell: | > | > | > | > | > | > | > | > | > | | https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- | > | ha | > | > skell.html#safe-language | > | > | > | > | > | > | > | > But this language on GNTD not being part of the safe language | was | > | > removed in the 7.8 manual: | > | > | > | > | > | > | > | > | > | | https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- | > | ha | > | > skell.html#safe-language | > | > | > | > | > | > | > | > The GHC release notes don't say anything about this one way or | > | the other. | > | > Thoughts? | > | > | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Dealing with GHC 7.10 prelude imports
by Brendan Hay 13 Apr '15

13 Apr '15

Hi, I've run into a couple of cases when attempting to support multiple GHC versions in my libraries (7.6.3 -> 7.10) where I've repeatedly made mistakes due to being warned about unused imports for various modules that are now part of the Prelude such as Data.Monoid, Data.Foldable, etc. which I subsequently remove either manually or via editor automation sufficiently indistinguishable from magic. This then results in successful compilation on 7.10 and failure on earlier versions of GHC due to missing imports (ie. Data.Monoid (mappend, mempty)), which prior to my current workflow of manually building on multiple versions of GHC before releasing a new version, manifested once or twice only after uploading to Hackage. Now this is all user/workflow error on my part, but I wondered if others have some kind of trick up their sleeve for avoiding these kind of issues? I could attempt to tailor the compiler's warning flags appropriately, but it bodes ill for spotting genuinely unused imports. Cheers, Brendan

5 5

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Richard Eisenberg 12 Apr '15

12 Apr '15

On Apr 12, 2015, at 9:51 AM, David Terei <dave.terei(a)gmail.com> wrote: > > Ideally I'd like to find a way forward that works for everyone and > isn't just a Safe Haskell mode setting. Agreed. I'm not convinced this can be done, but it's certainly worth trying. > > I think the first question is, are there situations where you'd want > to use `coerce` internally to a module but disallow it externally? The > role mechanism is a little awkward as it doesn't allow this (although > it does for newtype's). If yes, then I think we should start there. Yes, the ability to use `coerce` within one module but not elsewhere would be nice. This can currently be simulated (without too much difficulty) with newtypes. A datatype D can have a more permissive role signature than an equivalent newtype N (where `newtype N = MkN D`). The package then exports N (without its constructor). This effectively allows local uses of `coerce`, even for datatypes. A more direct mechanism would be better, but I don't think we should bend over backwards for it. > > If it seems we don't need external vs internal control, then we could > simply change the default to be that GHC sets referential type > parameters to nominal and allows them to be weakened to referential > through role annotations. We could use hackage to test how much > breakage this would cause. I worry that the breakage would be significant. But, now that authors have had a chance to put in role annotations, maybe it wouldn't be so bad. The change to GHC to make this happen is trivial: just change default_role in TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an all-of-Hackage test, but I'm happy to support someone else who does. Richard

1 0

Re: [Haskell-cafe] Generalized Newtype Deriving not allowed in Safe Haskell
by Richard Eisenberg 10 Apr '15

10 Apr '15

Here's an idea: For a module to be Safe, then for each exported datatype, one of the following must hold: 1) The datatype comes with a role annotation. 2) The module exports all of the datatype's constructors. 3) If the datatype is defined in a place other than the current module, the current module exports no fewer data constructors than are exported in the datatype's defining module. Why? 1) The role annotation, even if it has no effect, shows that the programmer has considered roles. Any mistake here is clearly the programmer's fault. 2) This datatype is clearly meant not to be abstract. `Coercible` then gives clients no more power than they already have. 3) This is subtler. It is a common idiom to export a datatype's constructors from a package-internal module, but then never to export the constructors beyond the package. If such a datatype has a role annotation (in its defining module, of course), then we're fine, even if it is exported abstractly later. However, suppose we are abstractly re-exporting a datatype that exports its constructors from its defining module. If there is no role annotation on the datatype, we're in trouble and should fail. BUT, if the datatype were exported abstractly in its defining module, then we don't need to fail on re-export, because nothing has changed. Actually, we could simplify the conditions. Change (2) to: 2') The module exports all of the datatype's visible constructors. I think explaining in terms of separate rules (2) and (3) is a little clearer, because the re-export case is slightly subtle, and this subtlety can be lost in (2'). This proposal would require tracking (in interface files, too) whether or not a datatype comes with a role annotation. This isn't hard, though. It might even help in pretty-printing. An alternative would be to have a way of setting roles differently on export than internally. I don't think this breaks the type system, but it's yet another thing to specify and support. And we'd have to consider the possibility that some module will import a datatype from multiple re-exporting modules, each with different ascribed role annotations. Is this an error? Does GHC take some sort of least upper bound? I prefer not to go here, but there's nothing terribly wrong with this approach. Richard On Apr 10, 2015, at 9:37 AM, David Terei <dave.terei(a)gmail.com> wrote: > I'll prepare a patch for the userguide soon. > > As for something better, yes I think we can and should. It's on my > todo list :) Basically, the new-GND design has all the mechanisms to > be safe, but sadly the defaults are rather worrying. Without explicit > annotations from the user, module abstractions are broken. This is why > we left GND out of Safe Haskell for the moment as it is a subtle and > easy mistake to make. > > If the module contained explicit role annotations then it could be > allowed. The discussion in > https://ghc.haskell.org/trac/ghc/ticket/8827 has other solutions that > I prefer, such as only exporting the Coerce instance if all the > constructors are exported, it seems that the ship sailed on these > bigger changes sadly. > > Cheers, > David > > On 9 April 2015 at 00:56, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: >> There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 >> about whether the new Coercible story makes GND ok for Safe Haskell. At a >> type-soundness level, definitely yes. But there are other less-clear-cut >> issues like “breaking abstractions” to consider. The decision on the ticket >> (comment:36) seems to be: GND stays out of Safe Haskell for now, but there >> is room for a better proposal. >> >> >> >> I don’t have an opinion myself. David Terei and David Mazieres are in the >> driving seat, but I’m sure they’ll be responsive to user input. >> >> >> >> However, I think the user manual may not have kept up with #8827. The >> sentence “GeneralizedNewtypeDeriving — It can be used to violate constructor >> access control, by allowing untrusted code to manipulate protected data >> types in ways the data type author did not intend, breaking invariants they >> have established.” vanished from the 7.8 user manual (links below). Maybe >> it should be restored. >> >> >> >> Safe Haskell aficionados, would you like to offer a patch for the manual? >> And maybe also a less drastic remedy than omitting GND altogether? >> >> >> >> Simon >> >> >> >> From: Omari Norman [mailto:omari@smileystation.com] >> Sent: 09 April 2015 02:44 >> To: haskell Cafe >> Subject: Generalized Newtype Deriving not allowed in Safe Haskell >> >> >> >> When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe >> flag, I get >> >> >> >> -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell >> >> >> >> This happens both in GHC 7.8 and GHC 7.10. >> >> >> >> I thought I remembered reading somewhere that GNTD is now part of the safe >> language? The GHC manual used to state that GNTD is not allowed in Safe >> Haskell: >> >> >> >> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell… >> >> >> >> But this language on GNTD not being part of the safe language was removed in >> the 7.8 manual: >> >> >> >> https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell… >> >> >> >> The GHC release notes don't say anything about this one way or the other. >> Thoughts? >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

3 2

indexed writer monad
by Nicholls, Mark 10 Apr '15

10 Apr '15

Anyone? I can handle monads, but I have something (actually in F#) that feels like it should be something like a indexed writer monad (which F# probably wouldn't support). So I thought I'd do some research in Haskell. I know little or nothing about indexed monad (though I have built the indexed state monad in C#). So I would assume there would be an indexed monoid (that looks at bit like a tuple?)... e.g. (a,b) ++ (c,d) = (a,b,c,d) (a,b,c,d) ++ (e) = (a,b,c,d,e) ? There seems to be some stuff about "update monads", but it doesn't really look like a writer. I could do with playing around with an indexed writer, in order to get my head around what I'm doing....then try and capture what I'm doing...then try (and fail) to port it back. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

3 12