- Haskell-Cafe - Haskell.org

ICFP 2014 Student Research Competition: Call for Submissions
by David Van Horn 16 May '14

16 May '14

====================================================================== CALL FOR SUBMISSION SRC@ICFP 2014 Gothenburg, Sweden 1-3 September 2014 http://www.icfpconference.org/icfp2014/src.html Co-located with the International Conference on Functional Programming (ICFP 2014) ====================================================================== Student Research Competition ------------------------ This year ICFP will host a Student Research Competition where undergraduate and postgraduate students can present posters. The SRC at the ICFP 2014 consists of three rounds: Extended abstract round: All students are encouraged to submit an extended abstract outlining their research (800 words). Poster session at ICFP 2014: Based on the abstracts, a panel of judges will select the most promising entrants to participate in the poster session which will take place at ICFP. Students who make it to this round will be eligible for some travel support to attend the conference. In the poster session, students will have the opportunity to present their work to the judges, who will select three finalists in each category* (graduate/undergraduate) to advance to the next round. ICFP presentation: The last round will consist of an oral presentation at the ICFP to compete for the final awards in each category. Prizes ----- * Both the top three graduate and the top three undergraduate winners will receive prizes of $500, $300, and $200, respectively. * All six winners will receive award medals and a two-year complimentary ACM student membership, including a subscription to ACMâ€™s Digital Library. * The names of the winners will be posted on the SRC web site. * The overall first place winner of the SRC will be invited to participate in the ACM SRC Grand Finals, an on-line round of competitions among the winners of other conference-hosted SRCs. * Grand Finalists and their advisors will be invited to the Annual ACM Awards Banquet for an all-expenses-paid trip, where they will be recognized for their accomplishments along with other prestigious ACM award winners, including the winner of the Turing Award (also known as the Nobel Prize of Computing). * The top three graduate Grand Finalists will receive an additional $500, $300, and $200. Likewise, the top three undergraduate Grand Finalists will receive an additional $500, $300, and $200. All six Grand Finalists will receive Grand Finalist certificates. * The ACM, Microsoft Research, and our industrial partners provide financial support for students attending the SRC. You can find more information about this on the ACM website. Eligibility -------- The SRC is open to both undergraduate (not in a PhD programme) and graduate students (in a PhD programme). Upon submission, entrants must be enrolled as a student at their universities, and are ACM student members. Furthermore, there are some constraints on what kind of work may be submitted. Previously published work: Submissions should consist of original work (not yet accepted for publication). If the work is a continuation of previously published work, the submission should focus on the contribution over what has already been published. We encourage students to see this as an opportunity to get early feedback and exposure for the work they plan to submit to the next ICFP or POPL. Collaborative work: Students are encouraged to submit work they have been conducting in collaboration with others, including advisors, internship mentors, or other students. However, submissions are individual, so they must focus on the contributions of the student. Submission Details --------------- Each submission should include the student authorâ€™s name, institutional affiliation, e-mail address, and postal address; research advisorâ€™s name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in attacking the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to computer science and explain the significance of those results. The abstract must describe the studentâ€™s individual research and must be authored solely by the student. If the work is collaborative with others and/or part of a larger group project, the abstract should make clear what the studentâ€™s role was and should focus on that portion of the work. The extended abstract must not exceed 800 words and must not be longer than 2 pages. The reference list does not count towards these limits. To submit an abstract, please register through the submission page and follow the instructions. Abstracts submitted after the deadline may be considered at the committee's discretion, but only after decisions have been made on all abstracts submitted before the deadline. If you have any problems, don't hesitate to contact the competition chair. Important Dates ------------- * Deadline for submission: 29 June * Notification of acceptance: 14 July Selection Committee ---------------- Jeremy Gibbons, University of Oxford Andrew Kennedy, Microsoft Research Cambridge Matthieu Sozeau, INRIA Paris Sam Tobin-Hochstadt, Indiana University Meng Wang, Chalmers University of Technology (Chair) Stephanie Weirich, University of Pennsylvania Transport of your poster ------------------- You can either bring your poster on your own to the conference or mail it to the local organizers: Attn.: Meng Wang Chalmers University of Technology Department of Computer Science and Engineering SE-412 96 Göteborg, Sweden If you choose to mail, please make sure that the poster will arrive at the latest on 30th August 2014.

1 0

Parent Modules: Common Functions or Re-Exportation?
by Sacha Sokoloski 16 May '14

16 May '14

So as a relatively long term user of haskell at this point, one issue which I've never found a simple solution to is the one stated in the thread. That is, given modules Foo, Foo.Bar, and Foo.Baz, should Foo reexport Bar and Baz, or should Foo provide common functions for Bar and Baz? In the first case, the common functions would have to be provided by some third module Foo.Util, which for some reason I find unsatisfying, as it means all my my modules have these Util after Util after Util module floating aroudn. My natural tendency is follow the second case, but then of course when it comes to actually using the code that I've written, I no longer have such a nicely exposed interface outside of the particular library. One simply can't eat ones cake and have it too. Maybe this problem is just silly, but perhaps others have always been left feeling ambivalent across similar lines, and have somehow found a pleasant solution for when this particular crossroads is reached? Cheers, - Sacha Sokoloski

2 1

Fwd: Composable events: Applicative and Alternative
by Tikhon Jelvis 16 May '14

16 May '14

Oops, forgot to include the list. ---------- Forwarded message ---------- From: Tikhon Jelvis <tikhon(a)jelv.is> Date: Fri, May 16, 2014 at 12:27 PM Subject: Re: [Haskell-cafe] Composable events: Applicative and Alternative To: Corentin Dupont <corentin.dupont(a)gmail.com> It sounds like you're trying to solve the same problems as FRP. In fact, this was basically the original impetus for FRP: making events (and reactive programs in general) nicely composable. Perhaps you could take a look at how event streams work in frameworks like Reactive-Banana? Reactive-Banana doesn't make its events applicatives, but it's a perfectly reasonable thing to do: there's a great explanation in Conal's "Push-Pull Functional Reactive Programming"[1] in section 2.2.4. On Fri, May 16, 2014 at 12:15 PM, Corentin Dupont <corentin.dupont(a)gmail.com > wrote: > > I created a DSL to manage and create events (see under). It's an instance > of Applicative and Alternative, which make them compose nicely. > The idea is that when an event is firing, I look the corresponding event > in the tree and replace it by its value using Pure. > > For example onInputText will trigger the display of a form with a text > field on the screen, and when the player validates the form, the same > onInputText is searched in the tree by the engine and replaced by the > text value. This is where the difficulty begins: > > --> How to make Event an instance of Eq? How to search and replace > through it? > > The problem is the EventProduct primitive, that forbids to make the DSL an > instance of Eq: > EventProduct :: Event (a -> b) -> Event a -> Event b > > Should I replace it by: > EventProduct :: Event a -> Event b -> Event (a,b) > > But then, bye-bye Applicative/Alternative instances! > How can I make the tree of events searchable/traversable and still > maintain the Applicative instance? > > Thanks!! > Corentin > > > On Sat, May 3, 2014 at 8:02 PM, Corentin Dupont <corentin.dupont(a)gmail.com > > wrote: > >> Hi Cafe!! >> >> For my game Nomyx, I am using events that the player can program. For >> example, the player can register a callback that will be triggered when a >> new player arrives. He can also program some forms (with buttons, >> checkboxes, textboxes...) to appear on the Web GUI. The problem is those >> events are not composable: he has to create and handle them one by one. >> >> So I'm thinking of making those events composable by making them an >> instance of Applicative and Alternative. >> For Applicative, this makes events composable very much like in >> Applicative-Functors and Reform. I can build neat composed events such as >> (full program below): >> >> onInputMyRecord :: Event MyRecord >> onInputMyRecord = MyRecord <$> onInputText <*> onInputCheckbox >> >> For Alternative, I haven't seen any example of it on the net. The idea >> is that the first event that fires is used to build the alternative: >> >> onInputMyAlternative :: Event Bool >> onInputMyAlternative = (True <$ onInputButton) <|> (False <$ >> onInputButton) >> >> Here is an example program: >> >> {-# LANGUAGE GADTs #-} >> >> module ComposableEvents where >> >> import Control.Applicative >> import Data.Time >> import Data.Traversable >> >> type PlayerNumber = Int >> >> data Event a where >> OnInputText :: PlayerNumber -> Event String -- A textbox >> will be created for the player. When filled, this event will fire and >> return the result >> OnInputCheckbox :: PlayerNumber -> Event Bool -- Idem with a >> checkbox >> OnInputButton :: PlayerNumber -> Event () -- Idem with a >> button >> OnTime :: UTCTime -> Event () -- time event >> EventSum :: Event a -> Event a -> Event a -- The first >> event to fire will be returned >> EventProduct :: Event (a -> b) -> Event a -> Event b -- both events >> should fire, and then the result is returned >> Fmap :: (a -> b) -> Event a -> Event b -- transforms >> the value returned by an event. >> Pure :: a -> Event a -- Create a fake >> event. The result is useable with no delay. >> Empty :: Event a -- An event that >> is never fired. >> >> instance Functor Event where >> fmap = Fmap >> >> instance Applicative Event where >> pure = Pure >> (<*>) = EventProduct >> >> instance Alternative Event where >> (<|>) = EventSum >> empty = Empty >> >> onInputText = OnInputText >> onInputCheckbox = OnInputCheckbox >> onInputButton = OnInputButton >> onTime = OnTime >> >> -- A product type >> data MyRecord = MyRecord String Bool >> >> -- A sum type >> data MyAlternative = A | B >> >> -- Using the Applicative instance, we can build a product type from two >> separate event results. >> -- The event callback should be called only when all two events have >> fired. >> onInputMyRecord :: Event MyRecord >> onInputMyRecord = MyRecord <$> onInputText 1 <*> onInputCheckbox 1 >> >> -- other possible implementation (given a monad instance) >> -- onInputMyRecord' = do >> -- s <- onInputText >> -- b <- onInputCheckbox >> -- return $ MyRecord s b >> >> -- Using the Alternative instance, we build a sum type. >> -- The event callback should be called when the first event have fired. >> onInputMyAlternative :: Event MyAlternative >> onInputMyAlternative = (const A <$> onInputButton 1) <|> (const B <$> >> onInputButton 1) >> >> allPlayers = [1 .. 10] >> >> -- Now complex events can be created, such as voting systems: >> voteEvent :: UTCTime -> Event ([Maybe Bool]) >> voteEvent time = sequenceA $ map (singleVote time) allPlayers >> >> singleVote :: UTCTime -> PlayerNumber -> Event (Maybe Bool) >> singleVote timeLimit pn = (Just <$> onInputCheckbox pn) <|> (const >> Nothing <$> onTime timeLimit) >> >> vote :: UTCTime -> Event Bool >> vote timeLimit = unanimity <$> (voteEvent timeLimit) >> >> unanimity :: [Maybe Bool] -> Bool >> unanimity = all (== Just True) >> >> >> --Evaluation >> --evalEvent :: Event a -> State Game a >> --evalEvent = undefined >> >> With this DSL, I can create complex events such as time limited votes >> very neatly... >> There is much left to do for a full implem: the way to register callbacks >> on complex events, the evaluator and the event manager. >> Have you heard about a similar implementation? It seems pretty useful. >> Maybe in FRP frameworks? >> >> Thanks a lot!! >> Corentin >> PS: I copied this example also in >> https://github.com/cdupont/Nomyx-design/blob/master/ComposableEvents.hs. >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

2 2

Composable events: Applicative and Alternative
by Corentin Dupont 16 May '14

16 May '14

Hi Cafe!! For my game Nomyx, I am using events that the player can program. For example, the player can register a callback that will be triggered when a new player arrives. He can also program some forms (with buttons, checkboxes, textboxes...) to appear on the Web GUI. The problem is those events are not composable: he has to create and handle them one by one. So I'm thinking of making those events composable by making them an instance of Applicative and Alternative. For Applicative, this makes events composable very much like in Applicative-Functors and Reform. I can build neat composed events such as (full program below): onInputMyRecord :: Event MyRecord onInputMyRecord = MyRecord <$> onInputText <*> onInputCheckbox For Alternative, I haven't seen any example of it on the net. The idea is that the first event that fires is used to build the alternative: onInputMyAlternative :: Event Bool onInputMyAlternative = (const True <$> onInputButton) <|> (const False <$> onInputButton) Here is an example program: {-# LANGUAGE GADTs #-} module ComposableEvents where import Control.Applicative import Data.Time import Data.Traversable type PlayerNumber = Int data Event a where OnInputText :: PlayerNumber -> Event String -- A textbox will be created for the player. When filled, this event will fire and return the result OnInputCheckbox :: PlayerNumber -> Event Bool -- Idem with a checkbox OnInputButton :: PlayerNumber -> Event () -- Idem with a button OnTime :: UTCTime -> Event () -- time event EventSum :: Event a -> Event a -> Event a -- The first event to fire will be returned EventProduct :: Event (a -> b) -> Event a -> Event b -- both events should fire, and then the result is returned Fmap :: (a -> b) -> Event a -> Event b -- transforms the value returned by an event. Pure :: a -> Event a -- Create a fake event. The result is useable with no delay. Empty :: Event a -- An event that is never fired. instance Functor Event where fmap = Fmap instance Applicative Event where pure = Pure (<*>) = EventProduct instance Alternative Event where (<|>) = EventSum empty = Empty onInputText = OnInputText onInputCheckbox = OnInputCheckbox onInputButton = OnInputButton onTime = OnTime -- A product type data MyRecord = MyRecord String Bool -- A sum type data MyAlternative = A | B -- Using the Applicative instance, we can build a product type from two separate event results. -- The event callback should be called only when all two events have fired. onInputMyRecord :: Event MyRecord onInputMyRecord = MyRecord <$> onInputText 1 <*> onInputCheckbox 1 -- other possible implementation (given a monad instance) -- onInputMyRecord' = do -- s <- onInputText -- b <- onInputCheckbox -- return $ MyRecord s b -- Using the Alternative instance, we build a sum type. -- The event callback should be called when the first event have fired. onInputMyAlternative :: Event MyAlternative onInputMyAlternative = (const A <$> onInputButton 1) <|> (const B <$> onInputButton 1) allPlayers = [1 .. 10] -- Now complex events can be created, such as voting systems: voteEvent :: UTCTime -> Event ([Maybe Bool]) voteEvent time = sequenceA $ map (singleVote time) allPlayers singleVote :: UTCTime -> PlayerNumber -> Event (Maybe Bool) singleVote timeLimit pn = (Just <$> onInputCheckbox pn) <|> (const Nothing <$> onTime timeLimit) vote :: UTCTime -> Event Bool vote timeLimit = unanimity <$> (voteEvent timeLimit) unanimity :: [Maybe Bool] -> Bool unanimity = all (== Just True) --Evaluation --evalEvent :: Event a -> State Game a --evalEvent = undefined With this DSL, I can create complex events such as time limited votes very neatly... There is much left to do for a full implem: the way to register callbacks on complex events, the evaluator and the event manager. Have you heard about a similar implementation? It seems pretty useful. Maybe in FRP frameworks? Thanks a lot!! Corentin PS: I copied this example also in https://github.com/cdupont/Nomyx-design/blob/master/ComposableEvents.hs.

1 1

Object oriented haskell.
by silvio 16 May '14

16 May '14

Hi Haskell, I've been wondering if (.) is so cool in other languages why can't we make it even cooler in haskell. And went on to implement such a (.) based on multiparameter type classes and type families. type family Output object action class Action object action where (.) :: object -> action -> Output object action I'm not sure if this has been done before like this but i didn't find anything. I used Map as an example, and here is what I ended up with: > :m -Prelude > import Prelude hiding ((.)) > import Object > import Object.Example > import Data.Map hiding (size) > let m = empty . [ 'f' := Just 1, 'o' := Just 2, 'o' := Nothing ] > m fromList [('f',Just 1),('o',Nothing)] > m . 'f' Just 1 > m . size 2 I also have a pretty cool (almost) solution to the name collision problem. Visit the project homepage for a more thorough explanation. https://github.com/yokto/object And to those who gonna hate on me because they like the (.) as function composition I have only this to say. type instance Output (b -> c) (a -> b') = (a -> c) instance (b ~ b') => Action (b -> c) (a -> b') where f . g = f Prelude.. g Have fun, Silvio

17 32

make "cabal repl" run a custom preprocessor before loading
by Markus Läll 15 May '14

15 May '14

Hi Cafe, I'm wondering how to run a custom preprocessor with "cabal repl"? The case is that I have a package with an executable and a library. The executable works fine with "ghc-options: -F -pgmF ./xxx.sh" in its cabal config section, but the library seems to ignore it when I put the same line into the library's section and then run "cabal repl". Also, the substitutions didn't happen when running GHC directly with -F and -pgmF in expression mode (-e). -- Markus Läll

3 3

Get "cabal repl" to dump ghc options?
by Carlo Hamalainen 15 May '14

15 May '14

Hi, The cabal repl command works out a bunch of GHC options. Is there any way to dump these options without actually starting the repl? In particular, things like this: ghcOptPackageDBs = [ GlobalPackageDB , SpecificPackageDB \"/home/carlo/foo/.cabal-sandbox/x86_64-linux-ghc-7.6.3-packages.conf.d\",SpecificPackageDB \"dist/package.conf.inplace\" ] Basically it would be nice to get the contents of replOpts just before this bit of code: https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/GHC.… -- Carlo Hamalainen http://carlo-hamalainen.net

3 3

First call for papers IFL 2014
by publicityifl＠gmail.com 15 May '14

15 May '14

Hello, Please, find below the first call for papers for IFL 2014. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- CALL FOR PAPERS 26th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2014 NORTHEASTERN UNIVERSITY/BOSTON, USA OCTOBER 1-3, 2014 http://ifl2014.github.io We are pleased to announce that the 26th edition of the IFL series will be held at Northeastern University in Boston, USA. The symposium will be held from 1st to 3rd of October 2014. Scope ----- The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2014 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2014 will use a post-symposium review process to produce the formal proceedings. All participants of IFL 2014 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Submission Details ------------------ Submission deadline draft papers: September 1 Notification of acceptance for presentation: September 5 Early registration deadline: September 10 Late registration deadline: September 17 Submission deadline for pre-symposium proceedings: September 24 26th IFL Symposium: October 1-3 Submission deadline for post-symposium proceedings: December 15 Notification of acceptance for post-symposium proceedings: January 31 2015 Camera-ready version for post-symposium proceedings: March 15 2015 Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Topics ------ IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2014, please contact the PC chair at samth(a)cs.indiana.edu. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications Peter Landin Prize ------------------ The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee ------------------- Sam Tobin-Hochstadt, Indiana University (Chair) Rinus Plasmeijer, Radboud University Nijmegen (Co-Chair) Atze Dijkstra, Utrecht University Colin Runciman, University of York Graham Hutton, University of Nottingham Mary Sheeran, Chalmers University of Technology Patricia Johann, Appalachian State University Matthew Fluet, Rochester Institute of Technology Josef Svenningsson, Chalmers University of Technology Malgorzata Biernacka, University of Wroclaw Peter Achten, Radboud Univerity Nijmegen Laura Castro, University of A Corua Hai Paul Liu, Intel Labs Kathryn Gray, Cambridge University Lars Bergstrom, Mozilla Research Lindsey Kuper, Indiana University Nicolas Wu, Oxford T. Stephen Strickland, University of Maryland Xavier Clerc, INRIA Venue ----- The 26th IFL will be held in association with the College of Computer and Information Science at Northeastern University. It can be reached quickly and easily by public transport.

1 0

ANN: fsnotify-0.1
by Roman Cheplyaka 15 May '14

15 May '14

A new version of fsnotify, a cross-platform filesystem notification library, is available. http://hackage.haskell.org/package/fsnotify-0.1.0.1 The main user-visible changes since the last version are: * ability to stop a listening job * ability to set a polling interval (when polling is used) * a couple of small semantic changes (see [changelog] for details) * improved documentation Plus, there was a fair bit of internal refactoring, including a new test suite. [changelog]: https://github.com/haskell-fswatch/hfsnotify/blob/master/CHANGELOG.md There's still a long-standing bug about wrong event types being generated on OS X. We know how to fix it (basically, use kqueue instead of OS X's own API), but I don't have time to do it. So if anyone is interested, help would be welcome! See https://github.com/haskell-fswatch/hfsnotify/issues/36 Thanks to Miguel Mitrofanov for providing access to an OS X host, which was extremely valuable while working on and testing this version. Roman

1 0

case, GADTs, Arrows
by Miguel Mitrofanov 15 May '14

15 May '14

Hi Café! Are there EXACT rules for desugaring "case" construct in Arrow syntax? The documentation says just "The translation is similar to that of if commands". But that can't be right in case of GADTs. For example, let's say we have data A where A :: Show s => s -> A Then the following would work fine: proc () -> do a <- arr A -< "test" case a of A s -> returnA -< show s But if we abstract part of it: b :: (Arrow a, Show s) => a s String b = proc(s) -> returnA -< show s proc() -> do a <- arr A -< "test" case a of A s -> b -< s then it fails. Now, I'm not asking why exactly does it fail. I understand, that type classes are just data types, and, if arrow is fixed, then the real type of "b" would be b :: Show s -> a s String and that can't be combined with something of type a () (Show s, s). So, the second example shouldn't work at all (although the error message could use some improvement). But I'm surprised that the first one does. Another unexpected thing is that it still requires ArrowChoice from the arrow, although there are no binary alternatives here. Therefore, the rules would be quite helpful.

3 2