February 2016 - Haskell-Cafe

[TFPIE 2016] 1st call for papers
by Peter Achten 16 Feb '16

16 Feb '16

Trends in Functional Programming in Education (TFPIE 2016) Call for papers https://wiki.science.ru.nl/tfpie/TFPIE2016 The 5th International Workshop on Trends in Functional Programming in Education, TFPIE 2016, will be held on June 7, 2016 at the University of Maryland College Park in the USA. It is co-located with the Symposium on Trends in Functional Programming (TFP 2016) which takes place from June 8 - 10. *** Goal *** The goal of TFPIE is to gather researchers, teachers and professionals that use, or are interested in the use of, functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas and work-in-progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. The program chair of TFPIE 2016 will screen submissions to ensure that all presentations are within scope and are of interest to participants. Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website/wiki. Visitors to the TFPIE 2016 website/wiki will be able to add comments. This includes presenters who may respond to comments and questions as well as provide pointers to improvements and follow-up work. After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles for publication in the journal Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. TFPIE workshops have previously been held in St Andrews, Scotland (2012), Provo Utah, USA (2013), Soesterberg, The Netherlands (2014), and Sophia-Antipolis, France (2015). *** Program Committee *** Stephen Chang at Northeastern University in Massachusetts, USA Marc Feeley at Université de Montréal in Québec, Canada Patricia Johann at Appalachian State University in North Carolina, USA Jay McCarthy at University of Massachusetts Lowell in Massachusetts, USA (Chair) Prabhakar Ragde at University of Waterloo in Ontario, Canada Brent Yorgey at Hendrix College in Arkansas, USA *** Submission Guidelines *** TFPIE 2016 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: - FP and beginning CS students - FP and Computational Thinking - FP and Artificial Intelligence - FP in Robotics - FP and Music - Advanced FP for undergraduates - Tools supporting learning FP - FP in graduate education - Engaging students in research using FP - FP in Programming Languages - FP in the high school curriculum - FP as a stepping stone to other CS topics - FP and Philosophy *** Best Lectures *** In addition to papers, we request "best lecture" presentations. What is your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. *** Submission *** Papers and abstracts can be submitted via EasyChair at the following link: https://easychair.org/conferences/?conf=tfpie2016 It is expected at at least one author for each submitted paper will attend the workshop. *** Registration & Local Information *** Please see the TFP site for registration and local information: http://tfp2016.org/ *** Important Dates *** April 27, 2016: Submission deadline for draft TFPIE papers and abstracts May 3, 2016: Notification of acceptance for presentation May 13, 2016: Registration for TFP/TFPIE closes June 7, 2016: Presentations in Maryland, USA July 7, 2016: Full papers for EPTCS proceedings due. September 1, 2016: Notification of acceptance for proceedings September 22, 2016: Camera ready copy due for EPTCS Submission of an abstract implies no obligation to submit a full version; abstracts with no corresponding full versions by the full paper deadline will be considered as withdrawn.

1 0

ghc commit and ticket mails
by Takenobu Tani 16 Feb '16

16 Feb '16

Hi cafe, I introduce ghc development information. The ghc developers always have many works as a volunteer. You can know and learn their amazing activities [1][2]. (You can also subscribe mailing lists [3][4].) [1] https://mail.haskell.org/pipermail/ghc-tickets/ [2] https://mail.haskell.org/pipermail/ghc-commits/ [3] https://mail.haskell.org/mailman/listinfo/ghc-commits [4] https://mail.haskell.org/mailman/listinfo/ghc-tickets Regards, Takenobu

1 0

transformers appears to benefit from more inline
by Oliver Charles 16 Feb '16

16 Feb '16

Hi everyone, I've recently been playing with a little mtl-like approach to streaming data, whereby I have a single type class - MonadYield - which can yield data, and then I use various implementations of this type class to implement operations. My usual approach to this is to implement this by newtyping around appropriate "off-the-shelf" monad transformers from the transformers library, but I found that this incurs a significant performance penalty. I've tried to put some fairly extensive benchmarks in place, which you can find at https://github.com/ocharles/monad-yield. In that repository is a README.md file that describes how I have been performing these benchmarks. The benchmarks are defined over a common interface that each implementation of MonadYield exports. The benchmarks are defined in "Benchmarks.hs", and the three implementations are "Transformers.hs" (using transformers from GHC), "TransformersInline.hs" (using transformers-ocharles from that repository, which has many more INLINE pragmas) and "Inline.hs" (which doesn't depend on anything other than base). There are three main benchmarks that are ran - one is benchmarking essentially the cost of ReaderT, the next the cost of StateT, and the last a composition of ReaderT over StateT over ReaderT. The results of the benchmark can be found here: https://ocharles.github.io/monad-yield/. It seems that the current darcs release of transformers loses every time, but if I sprinkle {-# INLINE #-} across the definition of lazy state, I get identical performance to just writing out the lazy state monad by hand. I was very surprised to see that I have to pay when I use transformers, and it seems like this cost can be removed at the cost of slightly larger interface files. Before I submit a patch, I'd love to hear others thoughts. Should {-# INLINE #-} be necessary? Is there any reason not to add it to every symbol in transformers? -- ocharles

3 2

Catch-22 at GHC bug wiki.
by Doug McIlroy 15 Feb '16

15 Feb '16

Having forgotten my login name, I have had to register at the GHC bug wiki under a different name with a different email address. I see no way for me to clean up the mess. Can anyone tell me how to reach the wiki keepers to get help?

3 2

problem with GHC bug wiki
by Doug McIlroy 15 Feb '16

15 Feb '16

Can anyone tell me how to contact the keepers of the GHC bug wiki about a probem with the wiki--not a GHC ticket? Thanks in advance, Doug

1 0

New type of expressions containing (error ...) includes noisy implicit parameter
by Christopher Allen 15 Feb '16

15 Feb '16

Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] This is on by default and insofar as I've been able to try, it's avoidable in a default GHCi 8.0 REPL session. I'm glad I caught this before our book goes to print in a couple months. We'd managed to avoid talking about implicit parameters in 1,100+ pages of book but now we're forced to acknowledge their existence in the 4th of 32 chapters. This slipped past the radar more stealthily than the earlier stages of BBP did for 7.10. I was hearing about BBP on the GHC Trac pretty early on for months on end. Was the thinking that people still used implicit parameters for anything or taught them? On the one hand, this is a nice change and something I personally attempted (and failed) to make easier in GHC 7.10. The implementation making the types noisy rankles and didn't seem necessary when I investigated it between 7.8 and 7.10. Could you warn us when (educationally relevant?) stuff like this is coming down the pipe before the RC please? Ideally during the design phase. I think this was discussed as part of FTP to avoid future debacles. This isn't just a pedagogical problem, this is a UX problem. The users don't _care_ that call stack information is being carried around. Why would they? It happens without any mention in the types in almost every other programming language. We checked after the previous thread where ($) occurred in the book. ($) is in the second chapter of the book, which is the first chapter of Haskell code. Now we have to hand-wave something completely impossible for them to understand (chapter 2 is expressions, types are chapter 5) or edit ($) out of the book until they can understand it. We can't write it completely out of the book because ($) gets used all over the place and we don't want encountering it to throw them off. --- Chris Allen

11 21

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
by Doug McIlroy 13 Feb '16

13 Feb '16

> The DNS as namespace means you have a spot that's guaranteed to be free for your code That's fine at the time, but maintainers come and go while software lives on. A name space that depends on who holds the reins and pays the rent seems rather ephemeral. Doug

3 2

conduit: Inexhaustible source
by David Turner 13 Feb '16

13 Feb '16

Hi, I've got a conduit thing that yields infinitely many values and never exits, which I've given the type ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> () o m Void - a bit like Source m o = ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> () o m () except that it can't exit due to the Void. (One side-question: why is Source m o not ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> Void o m ()?) I would now like to get the first item it yields; I'm currently using Data.Conduit.List.head but of course this returns a Maybe o in case the upstream thing exits. Is there a way to do this without that Maybe? I can't see anything obvious, but nor can I think of a terribly good reason why not. One thing that I was pondering was a kind of fuse operator with a type like ... ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> a b m r1 -> ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> b c m r2 -> ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> a c m (Either r1 r2) ... which returns the result of whichever thing exits first. Does such a thing exist? Does it even make sense? If it existed, I think I could use it here as it'd specialise to ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> () o m Void -> ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> o Void m o -> ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> () Void m (Either Void o) and of course (Either Void o) is isomorphic to o so I'd be home and dry. Having written this, I'm now also struggling to work out what the thing of type ConduitM <https://hackage.haskell.org/package/conduit-1.2.6/docs/Data-Conduit.html#t:…> o Void m o would be. Maybe I'm going about this all the wrong way, or maybe I'm just confused? Any help greatly appreciated! Cheers, David

2 3

Re: [Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic
by Johannes Waldmann 13 Feb '16

13 Feb '16

As Manuel wrote: > I expect that every single person teaching Haskell > is going to be unhappy about it. Indeed I am. (Will be teaching beginners next term.) - J.W.

29 75

typeclass for transformation of Euclidean points
by Christopher Howard 12 Feb '16

12 Feb '16

Hi. What I'd like to have for a program I am working on is a generic typeclass for objects that can be treated like points on a 2D plane, and a few simple transform functions (e.g., addition, rotation around an origin) which I could combine to make more complex transformations. Of course, it would be trivial to do this myself, but it seems like the sort of thing somebody would have thought of already. Does anybody know of a package providing this? (I didn't see an obvious one when searching with hoogle.) -- http://justonemoremathproblem.com

2 1