- Haskell-Cafe - Haskell.org

Typeclassopedia exercises - my own answers published.
by David Banas 23 Feb '16

23 Feb '16

Hi all, I’ve published my own answers to some of the exercises in Brent Yorgey’s Typeclassopedia: Github hosted HTML preview: http://htmlpreview.github.io/?https://github.com/capn-freako/Haskell_Misc/b… Github source repository: https://github.com/capn-freako/Haskell_Misc/tree/v0.5/Typeclassopedia Thanks to Conal Elliott and Phil Ruffwind for their help. -db

1 0

Compile times and separate compilation
by Tom Ellis 22 Feb '16

22 Feb '16

Random thought about compile times: could separate compilation be made even more fine-grained by taking it to the level of individual top-level identifiers, rather than modules? This would probably help slow recompiles a lot. Tom

4 4

Fw: new important message
by dek5＠yandex.ru 22 Feb '16

22 Feb '16

Hello! New message, please read <http://stagetwo.co.uk/round.php?630lm> dek5(a)yandex.ru

1 0

Haskell ITA meetup in Florence, Italy (2016-03-26)
by Luca Molteni 22 Feb '16

22 Feb '16

Hello everyone I'd like to announce that on March 26 (2016-03-26) we're going to host the third meetup of the Haskell ITA user group (http://www.haskell-ita.it/) near Florence, Italy. This time we're going to focus more on the practical part rather than the talks, we're going to form some little group in order to create some small project or contribute to some open source library (Stack was proposed, but any suggestion is welcome). It's important if you decide to attend that you have the development environment already configured, you can use this guide (in italian) to do it: http://haskell-ita.it/2015/01/Installare_Haskell/ There will be people from all Italy, and we'll use the italian language during all the event. Here's the link for the registration: https://metooo.io/e/haskell-day-firenze Italian version will follow --- Iscrivetevi qui: https://metooo.io/e/haskell-day-firenze Questo è il terzo evento del gruppo dei programmatori Haskell Italiani. A differenza dei due precedenti, vogliamo concentrarci un po' più sull'aspetto pratico, quindi ci saranno un sacco di occasioni di sperimentare la programmazione funzionale pura direttamente sul proprio portatile. La proposta è di fare dei gruppetti di lavoro ristretti (2-6 persone, ideale 3-4) per lavorare su qualcosa di concreto, approfondire la conoscenza del linguaggio attraverso il confronto e divertirsi un po'. È importante avere già l'ambiente preparato seguendo questa guida: http://haskell-ita.it/2015/01/Installare_Haskell/ Il numero e quali talk al mattino è ancora da decidere e qualsiasi proposta è benvenuta, maggiori informazioni sul nostro sito: http://haskell-ita.it/2016/02/organizzazione-meetup-marzo-2016/ L.M.

2 2

funny comics about Monad
by sajeeb Bhm 22 Feb '16

22 Feb '16

check this one!

2 1

Re: [Haskell-cafe] Manual type-checking in graphs: Avoidable?
by Gesh 21 Feb '16

21 Feb '16

On February 19, 2016 10:54:11 PM GMT+02:00, Francesco Ariis <fa-ml(a)ariis.it> wrote: >hey Gesh, > >you are right (not able to compile it atm too, but it looks >correct and way elegant). >Maybe post it in the Ml to help OP? > >ciao ciao >F > > >On Fri, Feb 19, 2016 at 04:59:56PM +0200, Gesh wrote: >> I'm away from compiler at the moment, but... >> Shouldn't this work? >> > {-# LANGUAGE GADTs #-} >> > data NodeS = HamsterS | PersonS >> > data NodeP a where >> > Hamster :: String -> NodeP HamsterS >> > Person :: String -> NodeP PersonS >> > data Node = forall a. NodeP a >> > type Graph = Gr Node... >> > hamsters :: NodeP PersonS -> ... >> >> Basically the idea of that you reify the choice of constructor to the >type level, permitting static restriction of the constructors used. >> >> HTH, >> Gesh Oops, meant to send to list.

6 9

ANN: stack-1.0.4
by Emanuel Borsboom 20 Feb '16

20 Feb '16

See haskellstack.org for installation and upgrade instructions. Major changes: - Some notable changes in stack init: - Overall it should now be able to initialize almost all existing cabal packages out of the box as long as the package itself is consistently defined. - Choose the best possible snapshot and add extra dependencies on top of a snapshot resolver rather than a compiler resolver - #1583 <https://github.com/commercialhaskell/stack/pull/1583> - Automatically omit a package (--omit-packages) when it is compiler incompatible or when there are packages with conflicting dependency requirements - #1674 <https://github.com/commercialhaskell/stack/pull/1674>. - Some more changes for a better user experience. Please refer to the doc guide for details. - Add support for hpack, alternative package description format #1679 <https://github.com/commercialhaskell/stack/issues/1679> Other enhancements: - Docker: pass ~/.ssh and SSH auth socket into container, so that git repos work #1358 <https://github.com/commercialhaskell/stack/issues/1358> . - Docker: strip suffix from docker —version. #1653 <https://github.com/commercialhaskell/stack/issues/1653> - Docker: pass USER and PWD environment bariables into container. - On each run, stack will test the stack root directory (~/.stack), and the project and package work directories (.stack-work) for whether they are owned by the current user and abort if they are not. This precaution can be disabled with the --allow-different-user flag or allow-different-user option in the global config (~/.stack/config.yaml). #471 <https://github.com/commercialhaskell/stack/issues/471> - Added stack clean --full option for full working dir cleanup. - YAML config: support Zip archives. - Redownload build plan if parsing fails #1702 <https://github.com/commercialhaskell/stack/issues/1702>. - Give mustache templates access to a ‘year’ tag #1716 <https://github.com/commercialhaskell/stack/pull/1716>. - Have “stack ghci” warn about module name aliasing. - Add “stack ghci —load-local-deps”. - Build Setup.hs with -rtsopts #1687 <https://github.com/commercialhaskell/stack/issues/1687>. - stack init accepts a list of directories. - Add flag infos to DependencyPlanFailures (for better error output in case of flags) #713 <https://github.com/commercialhaskell/stack/issues/713> - stack new --bare complains for overwrites, and add --force option #1597 <https://github.com/commercialhaskell/stack/issues/1597>. Bug fixes: - Previously, stack ghci would fail with cannot satisfy -package-id when the implicit build step changes the package key of some dependency. - Fix: Building with ghcjs: “ghc-pkg: Prelude.chr: bad argument: 2980338” #1665 <https://github.com/commercialhaskell/stack/issues/1665>. - Fix running test / bench with --profile / --trace. - Fix: build progress counter is no longer visible #1685 <https://github.com/commercialhaskell/stack/issues/1685>. - Use “-RTS” w/ profiling to allow extra args #1772 <https://github.com/commercialhaskell/stack/issues/1772>. - Fix withUnpackedTarball7z to find name of srcDir after unpacking (fixes stack setup fails for ghcjs project on windows) #1774 <https://github.com/commercialhaskell/stack/issues/1774>. - Add space before auto-generated bench opts (makes profiling options work uniformly for applications and benchmark suites) #1771 <https://github.com/commercialhaskell/stack/issues/1771>. - Don’t try to find plugin if it resembles flag. - Setup.hs changes cause package dirtiness #1711 <https://github.com/commercialhaskell/stack/issues/1711>. - Send “stack templates” output to stdout #1792 <https://github.com/commercialhaskell/stack/issues/1792>. ------------------------------ Thanks to all our contributors for this release: - Aaron Wolf @wolftune <https://github.com/wolftune> - Artem Chernyak @achernyak <https://github.com/achernyak> - Dan Aloni @da-x <https://github.com/da-x> - Daniel Gasienica @gasi <https://github.com/gasi> - Emanuel Borsboom @borsboom <https://github.com/borsboom> - Erik Stevenson @narrative <https://github.com/narrative> - Gauthier Segay @smoothdeveloper <https://github.com/smoothdeveloper> - Greg Weber @gregwebs <https://github.com/gregwebs> - Grégoire Détrez @gdetrez <https://github.com/gdetrez> - Harendra Kumar @harendra-kumar <https://github.com/harendra-kumar> - Mark Karpov @mrkkrp <https://github.com/mrkkrp> - Martin Kolinek - Matt Gambogi @gambogi <https://github.com/gambogi> - Michael Sloan @mgsloan <https://github.com/mgsloan> - Michael Snoyman @snoyberg <https://github.com/snoyberg> - Oleg Grenrus @phadej <https://github.com/phadej> - Eldar Yakupov @panamiga <https://github.com/panamiga> - Prayag Verma @pra85 <https://github.com/pra85> - Simon Hengel @sol <https://github.com/sol> - Simon Jakobi @sjakobi <https://github.com/sjakobi> - Tristan Webb @drwebb <https://github.com/drwebb> - Yves Parès @YPares <https://github.com/YPares> And thanks also to the 150+ contributors to past releases!

1 0

Re: [Haskell-cafe] Manual type-checking in graphs: Avoidable?
by Johannes Waldmann 19 Feb '16

19 Feb '16

> .. a graph that described which people own which hamsters, This is a bipartite graph, or, a relation. You want a type like data Rel src tgt a = Rel { fore :: ! ( M.Map src (M.Map tgt a) ) , back :: ! ( M.Map tgt (M.Map src a) ) } where src = People, tgt = Hamster, and a = Bool. In general, a could be some extra weight information. - J.W. cf. https://gitlab.imn.htwk-leipzig.de/waldmann/pure-matchbox/blob/master/src/M…

5 6

Manual type-checking in graphs: Avoidable?
by Jeffrey Brown 19 Feb '16

19 Feb '16

I use FGL, which (roughly) defines type Gr a b as a graph on nodes of type a and edges of type b. Suppose you wanted a graph that described which people own which hamsters, knowing only their name. You would have to make node and edge types like this: data GraphNode = Person String | Hamster String data GraphEdge = Has where the strings represent their names. Suppose then you wanted to write a function that, given a person, returns the names of all their hamsters. To make sure the call makes sense, the function would have to first check that the input is in fact a person. Since persons and hamsters are both constructors of the same type, you can't let Haskell's robust, beautiful type-checking system distinguish them for you; you've got to write something like "case n of Person _ -> True; _ -> False". Is there some way around writing such manual checks? -- Jeffrey Benjamin Brown

5 6

Munich Haskell Meeting, 2015-02-23 @ 19:30
by Christian Neukirchen 19 Feb '16

19 Feb '16

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, February 23 at Cafe Puck at 19h30. For details see here: http://chneukirchen.github.io/haskell-munich.de/dates If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-feb-2016/ Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

Confusing behavior in Haskell networking libraries
by Alex Rozenshteyn 18 Feb '16

18 Feb '16

I was trying to write a web scraper, so I used scalpel <https://hackage.haskell.org/package/scalpel>. The website I wanted to scrape blocks my IP (I run a tor exit node), so I decided to use proxychains <http://proxychains.sourceforge.net/> (specifically, version 3.1-6 according to Debian). I ran into the following weird behavior: if I tell proxychains to run dns through the proxy, things are fine, but if I tell it to run dns in the clear or the URL I'm trying to connect to is an IP address (e.g. manually resolved), I always get timeouts (much faster than I should). (don't resolve dns over the proxy) % proxychains stack exec -- test-scalpel "http://ifconfig.co" ProxyChains-3.1 (http://proxychains.sf.net) |R-chain|-<>-201.175.94.245:38746-<><>-188.113.88.193:80-<--timeout (resolve dns over the proxy) % proxychains stack exec -- test-scalpel "http://ifconfig.co" ProxyChains-3.1 (http://proxychains.sf.net) |DNS-request| ifconfig.co |R-chain|-<>-201.175.111.245:10000-<><>-4.2.2.2:53-<><>-OK |DNS-response| ifconfig.co is 188.113.88.193 |R-chain|-<>-201.175.111.245:10000-<><>-188.113.88.193:80-<><>-OK (resolve dns over proxy, but use an IP to avoid actually doing it) % proxychains stack exec -- test-scalpel "http://188.113.88.193" ProxyChains-3.1 (http://proxychains.sf.net) |R-chain|-<>-201.175.111.245:10000-<><>-188.113.88.193:80-<--timeout curl does not have this behavior: % proxychains stack exec -- curl "http://188.113.88.193" ProxyChains-3.1 (http://proxychains.sf.net) |R-chain|-<>-201.172.16.131:55599-<><>-188.113.88.193:80-<><>-OK % proxychains stack exec -- curl "http://ifconfig.co" ProxyChains-3.1 (http://proxychains.sf.net) |DNS-request| ifconfig.co |R-chain|-<>-201.172.17.231:10000-<><>-4.2.2.2:53-<><>-OK |DNS-response| ifconfig.co is 188.113.88.193 |R-chain|-<>-201.172.17.231:10000-<><>-188.113.88.193:80-<><>-OK % vim proxychains.conf # to change the setting % proxychains stack exec -- curl "http://ifconfig.co" ProxyChains-3.1 (http://proxychains.sf.net) |R-chain|-<>-201.172.16.131:55599-<><>-188.113.88.193:80-<><>-OK wget and aria2c also behave like curl. wreq behaves like scalpel: % proxychains stack exec -- test-wreq "http://188.113.88.193" ProxyChains-3.1 (http://proxychains.sf.net) |R-chain|-<>-201.172.17.231:10000-<><>-188.113.88.193:80-<--timeout HTTP (the Haskell package) behaves differently than all the rest, failing to connect even where the rest succeed: % proxychains stack exec -- test-http "http://ifconfig.co" ProxyChains-3.1 (http://proxychains.sf.net) |DNS-request| ifconfig.co |R-chain|-<>-201.175.94.245:38746-<><>-4.2.2.2:53-<><>-OK |DNS-response| ifconfig.co is 188.113.88.193 |R-chain|-<>-201.175.94.245:38746-<><>-188.113.88.193:80-<--timeout Gists of the programs I ran: https://gist.github.com/rpglover64/f668ed372c63e271cf15 Anyone have any idea what's going on?

1 0

Closed classes
by David Feuer 18 Feb '16

18 Feb '16

I was thinking about ~two notions of "closed class" yesterday, and I'm curious if anyone's done any work on either concept. In each case, the class definition is followed by *all* of its instances, and the instances are checked *in order* (rather than based on specificity and OVERLAPS/OVERLAPPABLE pragmas). No backtracking: If the instance head matches, GHC commits to it. Associated types are treated as closed type families, and would work just the same (I don't think any significant extension to the closed type family mechanism would be required). This seems to make a very nice parallel to the usual open classes with open associated types. And it lets you combine overlapping instances with associated types without (I believe) risking type safety. Backtracking: GHC does not commit to the instance until it has satisfied the instance constraints. This lets instance writers offer multiple alternative instance constraints. Associated types would be a good bit trickier. One option would be to require all instances with the same head to share a type/data instance. The other (much more invasive) option would be to allow the instance chosen to guide the type selection, which would push the backtracking into the type checker.

5 10

Call for Haskell.org committee self-nominations
by John Wiegley 18 Feb '16

18 Feb '16

Dear Haskellers, It is time to put out the call for new volunteers to the haskell.org committee. We have one member due for retirement since this past October: Gershom Bazerman. The committee would like to thank him for his excellent service. To nominate yourself, please send an email to committee at haskell.org by March 4, 2016. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The role is about setting policy, providing direction/guidance for Haskell.org infrastructure, planning for the long term, and being fiscally responsible with the Haskell.org funds (and donations). As overseers for policy regarding the open source side of Haskell, committee members must also be able to set aside personal or business related bias and make decisions with the good of the open source Haskell community in mind. More details about the committee's roles and responsibilities are on https://wiki.haskell.org/Haskell.org_committee If you have any questions about the process, please feel free to e-mail us at committee at haskell.org, or contact one of us individually. Thank you, -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

1 0

STM unperformance
by Wojtek Narczyński 18 Feb '16

18 Feb '16

Dear list, I create four haskell threads, each performs disjoint STM transactions. The more system threads I add, the slower the program runs. With four system threads the performance is 14% of the nonparallel run. What is going on? $ ghc -v Glasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.8.4 $ ghc -O2 -threaded test-stm.hs $ time ./test-stm +RTS -N1 real 1.843s $ time ./test-stm +RTS -N2 real 7.469s $ time ./test-stm +RTS -N3 real 9.640s $ time ./test-stm +RTS -N4 real 13.144s $ cat test-stm.hs {-# LANGUAGE ScopedTypeVariables #-} import Control.Monad import Control.Concurrent import Control.Concurrent.STM import Control.Concurrent.STM.Stats import System.IO.Unsafe -- Copied from GHC docs children :: MVar [MVar ()] children = unsafePerformIO (newMVar []) waitForChildren :: IO () waitForChildren = do cs <- takeMVar children case cs of [] -> return () m:ms -> do putMVar children ms takeMVar m waitForChildren forkChild :: IO () -> IO ThreadId forkChild io = do mvar <- newEmptyMVar childs <- takeMVar children putMVar children (mvar:childs) forkFinally io (\_ -> putMVar mvar ()) -- Test case main = do forkChild $ newTVarIO 0 >>= incrManyTimes "thread1" forkChild $ newTVarIO 0 >>= incrManyTimes "thread2" forkChild $ newTVarIO 0 >>= incrManyTimes "thread3" forkChild $ newTVarIO 0 >>= incrManyTimes "thread4" waitForChildren dumpSTMStats -- Confirms no conflicts incrManyTimes :: String -> TVar Int -> IO () incrManyTimes l = incrRec (1000000 :: Int) where incrRec n v | n == 0 = pure () | otherwise = trackNamedSTM l (modifyTVar v (+1)) >> incrRec (n-1) v -- Wojtek

2 2

GHC worker/wrapper on multiple return values
by Tyson Whitehead 18 Feb '16

18 Feb '16

Recently discovered GHC generates sub-optimal code when you have - two levels of loops in the IO monad - the inner loop doesn't do that much work - the outer loop does a lot of work From dumping core I believe the issue is the worker/wrapper transformation doesn't produce return value unboxing (from the inner loop to the outer in this case) when there are multiple return values (as you windup with the IO monad due to passing around the State# RealWorld behind the scenes). Here is some simple code that demonstrates the issue. With a single return value {-# LANGUAGE BangPatterns #-} module Main (main) where main :: IO () main = do let a = l1 0 100000000 print a l1 :: Int -> Int -> Int l1 !a !n = case n>0 of True -> let m = l2 0 n 3 in l1 (a+m) (n-1) False -> a l2 :: Int -> Int -> Int -> Int l2 !a !n !m = case m>0 of True -> l2 (a+n) (n-1) (m-1) False -> a you get nice clean core that performs no allocations and runs beautifully. Doing the same thing within the IO monad (effectively lifting the return value above into a unboxed tupple) {-# LANGUAGE BangPatterns, MagicHash, UnboxedTuples #-} module Main (main) where main :: IO () main = do a <- l1 0 100000000 print a l1 :: Int -> Int -> IO Int l1 !a !n = do case n>0 of True -> do m <- l2 0 n 3 l1 (a+m) (n-1) False -> return a l2 :: Int -> Int -> Int -> IO Int l2 !a !n !m = do case m>0 of True -> l2 (a+n) (n-1) (m-1) False -> return a you don't get boxing and unboxing the return value between l1 and l2. This has quite a dramatic effect when l2 doesn't do the that much work (massive amounts of additional memory allocation and a 2x slow down). $ time ./Simple-pure 14999999850000000 51,912 bytes allocated in the heap ... real 0m0.322s ... $ time ./Simple-io 14999999850000000 1,600,051,936 bytes allocated in the heap ... real 0m0.634s Should I open a ticket against GHC about this issue? Possibly it wouldn't be that hard to get the work/wrapper stuff to work its unboxing magic on multiple return values too? Cheers! -Tyson [*] https://gist.github.com/twhitehead/5744eee28bcde85b9fa4

1 1

[announcement] filtrable: class of filtrable containers
by M Farkas-Dyck 18 Feb '16

18 Feb '16

I quietly posted this library to Hackage nearly a year ago, but lately learned that some seeking such a package had difficulty finding it, so i announce it now ☺ https://hackage.haskell.org/package/filtrable class Functor f => Filtrable f where mapMaybe :: (a -> Maybe b) -> f a -> f b catMaybes :: f (Maybe a) -> f a filter :: (a -> Bool) -> f a -> f a For laws, see docs on Hackage.

12 19

Haskell.org Committee Financial Statement 2015
by Gershom B 17 Feb '16

17 Feb '16

Dear Haskellers, The Haskell.org Committee [1] manages funds for haskell.org and oversees haskell.org infrastructure. The funds available to Haskell.org generally come from two sources: 1) Mentor payments from the Google Summer of Code program. 2) Since the end of 2013, occasional donations [2] from the Haskell community at large. Our funds are held by Software in the Public Interest, a 501(c)3 US non-profit, through which we also accept donations. In return for its services, SPI receives 5% of donations to Haskell.org. According to our charter, "Each year, the committee will post a statement of the haskell.org assets, and the transactions for that year." Included in this message is a brief statement of Haskell.org assets over the period 31 December 2014 - 31 December 2015. Note that our expenses are nearly entirely hosting, with a small overhead incurred by SPI and payment processing. The bulk of our income this year, over which we did minimal fundraising, is $7,000 in mentor payments from google summer of code 2014 (mentor payments for 2015 have not yet been received). Hosting fees are down from years past, as we have migrated more of our infrastructure away from Hetzner and to Rackspace, which donates to us free hosting. 1. Income and Expenses Total income over 2014: 7751.46 Total expenses over 2014: 892.03 ---- Net income over 2014: 6859.43 3. Total Balance Balance as of 31 December 2014: 26,422.91 Balance as of 31 December 2015: 33,547.34 Note: As of December 2015, we have a moved a large chunk of our balance out of the SPI-held account and to a new account set up directly under the control of Haskell.Org, as Haskell.Org is now registered as a nonprofit 501(c)(3). [1] https://wiki.haskell.org/Haskell.org_committee [2] https://wiki.haskell.org/Donate_to_Haskell.org Best, Gershom Bazerman for the Haskell.org Committee

1 1

Re: [Haskell-cafe] Yesod CSRF token
by Geraldus 17 Feb '16

17 Feb '16

Can you share your code? If you make your POST requests via forms make sure that you generation forms with Yesod functions, in this case it will insert hidden field with CSRF token to resulting form widget automatically. If you sending requests via XHR make sure to use `defaultCsrfMiddleware` from Yesod.Core. Hope this helps. ср, 17 февр. 2016 г. в 15:38, fr33domlover <fr33domlover(a)riseup.net>: > Hello, > > I started a new Yesod web app few days ago. I'm using stack, LTS-5.1, and > the > yesod-postgres scaffolding. > > When I try to log in into my new minimal app, I get an error: A valid CSRF > token wasn't present in HTTP headers or POST parameters. That's because the > POST request doesn't include that token for some reason. But I don't know > why. > > I found a recent PR which removes the CSRF token checking from the > scaffolding, > but I do want CSRF protection to work. As a Yesod beginner, I'm not sure > exactly why the token doesn't get inserted where it should (the Yesod book > says > yesod-form does insert it, so I assume this is a bug here) and how I can > fix > that. Even if I inserted the token manually into the login form, what > about all > the other POST requests my app may use, such as logout? > > I also found a commit that adds the token to the redirectToPost function in > yesod-core, but > > (1) It's in the most recent release, not in LTS > (2) I'm not sure it has anything to do with it because it seems to be some > sort > of JS based form > > Anyone knows whether this is a known issue and how to fix it? > > > > Thanks! > --fr33 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

2 1

Generalising Categories - categories of tuples
by Clinton Mead 17 Feb '16

17 Feb '16

Hi All I've been doing some work on generalising categories, basically so the composition operator (.) works for not just functions, but things like tuples of functions, whilst still retaining type inference. Control.Category is a bit too restrictive for such instances. You can see the details in my blog post here: https://clintonmeadprogramming.wordpress.com/2016/02/16/generalising-catego… Any comments appreciated, I hope people find it interesting. Also, a quick plug, I'm looking for work, so if there's any Haskell (and/or functional programing) work around Sydney, Australia going I'd be interested. :-) If people really think this is useful, tell me, and I'll try to put it up as a package. Alternatively, if it's already been done, I'd appreciate a pointer in that direction. Regards, Clinton Mead

3 4

Yesod CSRF token
by fr33domlover 17 Feb '16

17 Feb '16

Hello, I started a new Yesod web app few days ago. I'm using stack, LTS-5.1, and the yesod-postgres scaffolding. When I try to log in into my new minimal app, I get an error: A valid CSRF token wasn't present in HTTP headers or POST parameters. That's because the POST request doesn't include that token for some reason. But I don't know why. I found a recent PR which removes the CSRF token checking from the scaffolding, but I do want CSRF protection to work. As a Yesod beginner, I'm not sure exactly why the token doesn't get inserted where it should (the Yesod book says yesod-form does insert it, so I assume this is a bug here) and how I can fix that. Even if I inserted the token manually into the login form, what about all the other POST requests my app may use, such as logout? I also found a commit that adds the token to the redirectToPost function in yesod-core, but (1) It's in the most recent release, not in LTS (2) I'm not sure it has anything to do with it because it seems to be some sort of JS based form Anyone knows whether this is a known issue and how to fix it? Thanks! --fr33

1 0

FP Complete developers survey
by Tom Ellis 16 Feb '16

16 Feb '16

Last year FP Complete ran a large survey of Haskell developers. I can only find a synopsis here https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey but my memory tells me they also had a blog post with a more in-depth analysis of the numbers. I can't find it on their website. Does anyone know where it is, or am I imagining it? Tom

3 4

Worked up examples of Simon Marlow's code hot-swapping
by Christopher Allen 16 Feb '16

16 Feb '16

https://twitter.com/raichoo/status/699677135280205826 Mentioned here: https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell https://phabricator.haskell.org/rGHCbdfefb3b72a71cd0afca6e7766456c0d97c47c86 Are there any out there? Most stuff I've found for this is Plugins or something else. I suggested on Twitter it might be similar to the dynamic linking trick game devs use but I don't really know anything about what Simon specifically did. If anyone could please point to examples or deeper explanation that would be a great help, thank you. --- Chris Allen

1 0

[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 16 Feb '16

16 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

-XGADTs changes type for program that does not contain GADT
by Johannes Waldmann 12 Feb '16

12 Feb '16

Dear Cafe, the following type-correct program does not contain GADT syntax. When I activate GADT language pragma, it does no longer typecheck. {-# language GADTs, ScopedTypeVariables #-} data M a b dw :: (b -> b -> b) -> M a b -> M a b -> M a b dw f x y = x data Bar a b s = Bar { this :: M a (M b s), that :: M b (M a s) } f :: forall p q s . (s -> s -> s) -> Bar p q s -> Bar p q s -> Bar p q s f g x y = let -- diff :: forall p . M p s -> M p s -> M p s diff a b = dw g a b in Bar { this = dw diff (this x)(this y) , that = dw diff (that x)(that y) } I can fix this by declaring the type for `diff` as indicated in the comment. Otherwise, `diff` is not polymorphic (enough), as the error message shows. This behaviour is consistent over ghc-7.8,7.10,8-rc, so it's unlikely to be a bug. But it does seem to go against the claim of "conservative extension of HM" (Sect 6.6 of the ICFP'06 paper, Sect 4.9 of MS-CIS-05-26) http://research.microsoft.com/en-us/um/people/simonpj/papers/gadt/ - J.W.

3 2

FLTKHS on WIndows- Call for Help.
by aditya siram 11 Feb '16

11 Feb '16

Hi all, I am the author and maintainer of FLTKHS [1] a cross-platform GUI binding and I could use some help getting it installed on Windows. When I cut a release this past October it was working well on Windows 7 with MinGHC and CMake[2]. Unfortunately MinGHC is now no longer supported and I haven't had much luck getting it to work on with Stack and the mingw that now ships with recent versions GHC. The Stack team is not to blame, I am very much a noob on Windows. I have also recently lost access to my (woefully out-dated) Windows 7 box. As it stands FLTKHS does not work on GHC > 7.10.2 since that is the version supported by the final release of MinGHC. In short, if you are currently using this package on Windows with Stack, please tell me how you got it working. If not and you would benefit from this package could you give it a try and report back? It doesn't have to be a full write up or anything, just a short overview of what you did would be great. When I hear back I'll borrow a machine, try it out, update the documentation and cut another release. Thanks! -deech [1] http://hackage.haskell.org/package [2] http://hackage.haskell.org/package/fltkhs-0.4.0.2/docs/Graphics-UI-FLTK-Low…

1 0

Source code for Control.Parallel.Strategies
by Edward Grutman 11 Feb '16

11 Feb '16

Unable to find source code for Control.Parallel.Strategies module in the libraries folder of the latest ghc ( downloaded from GitHub two weeks ago. ).

2 1

Why do we want levity polymorphism?
by David Menendez 11 Feb '16

11 Feb '16

For context, there’s currently a big thread about the type of ($), which is going to be more complicated in GHC 8.0 due to levity/runtime rep polymorphism. As I understand it, the intention is that this more complex type will be hidden unless a levity polymorphism flag is active. From my perspective, makes the question of whether this type is too complicated for beginners moot. What puzzles me is that I still don’t understand what this feature is *for*. According to [1], levity polymorphism is a more principled replacement for OpenKind, which was a bit of hack. Fine. [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds OpenKind exists because developers wanted to use ($), undefined, and error with unboxed types. That’s understandable, but it doesn’t seem worth all this effort. Surely, having to use error# instead of error when working with unboxed or unlifed types is a small thing next to all the other differences. OpenKind is also used when doing type inference, because arguments to functions might be * or #. That’s more compelling, but doesn’t seem like something that needs to be exposed to the programmer. So, is that it? Are there less-trivial levity-polymorphic functions? Is this a step on a road to new features, like [2]? Is there an article or something that makes the case for this? [2] https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 1

Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
by Richard Eisenberg 11 Feb '16

11 Feb '16

I have made a ticket #11549 (https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a -fshow-runtime-rep flag (recalling that the name levity will soon be outdated) as described in this thread. I will make sure this gets in for the release of 8.0. Other points: - You're quite right that (.) could be generalized. But I'll wait for someone to really want this. - I don't have a non-contrived example of the use of ($) with unlifted types. It's quite possible that when adding the dirty runST hack, it was observed that an unlifted type would be OK. At that point, the type of ($) didn't need to become so elaborate. And now we're just trying not to change old (but perhaps unrequested) behavior. - For the record, this debate is entirely unrelated to the runST impredicativity hack. (Except, as noted above, perhaps in history.) That hack remains, basically unchanged. - On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > > I would call this a simplification rather than a lie. This is a very convincing argument. - Thanks, also, for the voice of support. What I love about the Haskell community is that we can have an impassioned debate full of strong opinions, and it all very rarely devolves into a proper flame war. All the posts I've seen in this thread have been constructive and helpful. Thanks. Richard

3 4

Re: [Haskell-cafe] tighter bounds for Data.Map operations (using min(n.m))?
by Johannes Waldmann 10 Feb '16

10 Feb '16

See also https://github.com/haskell/containers/issues/177 (which I found only now) - J.W.

1 0

tighter bounds for Data.Map operations (using min(n.m))?
by Johannes Waldmann 10 Feb '16

10 Feb '16

Dear Cafe, I wonder if some of the resource bounds in https://hackage.haskell.org/package/containers-0.5.7.1/docs/Data-Map-Strict… can be improved. I do not mean "improve the implementation", but "improve the (stated) bounds". For example, I am interested in intersection(With). Bound is stated as O(n+m) (*) This is a fine worst case bound - but I certainly use this function with the implied assumption that it will not visit both trees completely - in the case that one of them is small. So, what can we say in terms of min(n,m) ? Is it linear in that parameter? Perhaps with an additional factor log(max(n,m)) ? (for looking up the keys of the smaller tree in the larger one) The paper linked from the docs has this (p 18 before 9.3) "the running time of union is better for fortuitous inputs, for example, similar sized disjoint ranges, and trees which differ greatly in size" but does not make a formal statement. This is about union, not intersection, and not hedge_union, but it's the closest this paper gets to what I have in mind. Oh, and after that, same question for Data.IntMap. - J.W. (*) with the usual neglect for alphabetic order...

1 0

Hackage: Tarball and package description of package mtl differ
by Björn Peemöller 10 Feb '16

10 Feb '16

Hi Cafe, I just wanted to install the mtl package for GHC 8.0.1-rc2, but installation failed with Setup: Encountered missing dependencies: transformers ==0.4.* Taking a look at the package description [1], it specifies build-depends: base < 6, transformers >= 0.4 && < 0.6 but the Cabal description in the tarball [2] says build-depends: base < 6, transformers == 0.4.* Strangely, if I execute $ cabal unpack mtl-2.2.1 I obtain a version with the same specification as [1]. Does anybody has an explanation for this? Regards, Björn [1]: http://hackage.haskell.org/package/mtl-2.2.1/mtl.cabal [2]: http://hackage.haskell.org/package/mtl-2.2.1/mtl-2.2.1.tar.gz

2 2

Postdoctoral position in Functional, Constraint and/or Logic Programming
by Tom Schrijvers 10 Feb '16

10 Feb '16

Prof. Tom Schrijvers invites applications for a postdoctoral position in the area of functional, constraint and logic programming. The position revolves around domain-specific languages (DSLs) embedded in Haskell for constraint programming. It is part of the EU project GRACeFUL whose overarching theme is tools for collective decision making. Responsibilities You will work closely with prof. Schrijvers and his PhD students at KU Leuven, as well as with the GRACeFUL project partners across Europe, in order to conduct research activities for the GRACeFUL project. For more details: https://icts.kuleuven.be/apps/jobsite/vacatures/53613023 -- prof. dr. ir. Tom Schrijvers Research Professor KU Leuven Department of Computer Science Celestijnenlaan 200A 3001 Leuven Belgium Phone: +32 16 327 830 http://people.cs.kuleuven.be/~tom.schrijvers/

1 0

Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
by Richard Eisenberg 10 Feb '16

10 Feb '16

It may come as a surprise to many of you that I, too, am very worried about Haskell becoming inaccessible to newcomers. If we can't induct new people into our ranks, we will die. It is for this reason that I have always been unhappy with the FTP. But that ship has sailed. I fully agree with George's suggestion below that the default Prelude should be the beginner's Prelude. I believe I have argued this stance in the past, but louder voices prevailed. Perhaps I was wrong in branding: we should have a proper Prelude as the default, and make available a super whiz-bang advanced Prelude as well. I'm never very good about branding. I'd lend strong support to someone who articulates a concrete move in this direction, but I don't have the bandwidth to spearhead it myself. Despite the various arguments saying that the bits in Java are easier to understand than the bits in ($), I'm quite unconvinced. (Particularly about `static`. Even `class` is hard for true beginners.) And the boxed/unboxed distinction does come up early in Java: just try to write an ArrayList<int> and now you need to know about boxed types and unboxed ones. Chris's point that "it's not about the name" is valid. The Levity --> RuntimeRep change is not about the name, but about the functionality. Levity distinguished only between lifted and unlifted; RuntimeRep distinguishes between boxed/lifted, boxed/unlifted, and all the unboxed types with their different widths. I'm just clarifying that it's not simply a cosmetic name-change. The old type of ($) was always a lie. -XMagicHash just changes the parser, allowing the # suffix. It is only by convention that most (all?) unlifted things end in #. The old type of ($) was perhaps a harmless lie, but a lie nonetheless. Are we comfortable with lying? (Believe me, I'm not trying to impose some moral dimension to simplifying output!) In my mind, lying about types like this is in the same space as having a beginner's Prelude. And people will constantly discover that we're lying and get very confused. Having a whole host of flags that tell GHC to lie less is somewhat like having two versions of the language... only the differences manifest only in output instead of input. If we are comfortable with lying in this way: as I've offered, I can hide the type of ($) (and other representation-polymorphic things) behind a flag. Easy to do. Another great question that has come up is about Haddock output (Hackage). I think Haddock needs to add a facility where library authors can include specializations of an overly general type. This can be done in commentary, but it's not as prominent. Such a new feature would address the ($) problem, as ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b is a specialization of its real type. It would also help a great deal with FTP-related generalizations. I also want to respond directly to Kyle's comments: > I think its important to identify who you want your "customers" to be. If you only want the most advanced type theorists to use the language, that is perfectly fine, but what you lose are thousands of developers that can benefit the Haskell community without having to know advanced Typing. Rest assured, I want my "customers" to be everyone who wants to program. I've volunteered to teach a bit of Haskell to high schoolers, and I'd love a shot at a course where I teach it to people who have never programmed. > > Needing a "Beginners" mode in a language is *not* a feature, its a fundamental design flaw. It shows that the language was not sufficiently thought out and designed for everyone. On an intuitive level, this rings true for me. But when I think about the details, I'm less convinced. For example, take Scratch (scratch.mit.edu) which is wonderfully easy to learn and gives kids (and adults!) a great deal of fun. Yet it's painful to use when you know more. And the Racket folks have invested a lot of time in coming up with a curriculum to go with their language, and they explicitly have expertise levels. Needing these levels may just be part of the game. So, rest assured, I remain very receptive to these concerns. And I'd love concrete help in putting them to rest. Richard On Feb 5, 2016, at 6:30 PM, George Colpitts <george.colpitts(a)gmail.com> wrote: > +1 for Christopher's email > Richard, I disagree with "But it could indeed be explained to an intermediate programmer in another language just learning Haskell." Your explanation is good but it assumes you have already explained "types of kind *" and the boxed vs unboxed distinction. Admittedly the latter should be understood by most Java programmers but I doubt that intermediate programmers in other languages do. If I did have to explain "$" I would say, for now think of it in terms of it's pre 8.0 type. Alternatively avoid mentioning "$" to beginners. I don't believe it is in Hutton's book or any of Bird's although I might be wrong. > > Most intermediate programmers in another language struggle a lot with learning monads, witness all the monad tutorials. Absorbing monads is central, there is a lot that has to be explained before that. Minimizing that material would be a good thing. > > I have mixed feelings about a beginner's prelude best summarized by saying the proposed beginner's prelude should be the standard prelude and the current one should be an advanced prelude. If we have a beginner's prelude I feel we are saying that this is a hard to understand research language and we hope that someday you have enough education, energy and tenacity to get to the point where you understand it. If we do it the other way we are saying you have what you need but if you want more there is lots! > > On Fri, Feb 5, 2016 at 3:05 PM, Christopher Allen <cma(a)bitemyapp.com> wrote: > Changing the name doesn't fix the issue. The issue is the noise and the referent, not the referrer. There's a habit of over-focusing on names in programming communities. I think it'd be a mistake to do that here and risk missing the point. > > You can make all of the keywords in the Java example salient early on, but you cannot make the implementation details you're exposing in the type of ($) relevant unless they already have a year or two of Haskell under their belts. Listing out the keywords: > > 1. public > > 2. class > > 3. (class name) > > 4. static > > 5. void > > 6. (method name) > > 7. (method arguments) > > Explaining public, class, static, and void usually happens pretty soon after the basics in a Java course. Importantly, they're things you _need_ to know to get things done properly in Java. The same is not true of what is mentioned in the type of ($). > > The implicit prenex form and forall are irrelevant for learners until they get to Rank2/RankN which is very much beyond, "I am learning Haskell" and into, "I am designing an API in Haskell for other people to use". * vs. # is something many working and hobbyist Haskellers I've known will scarcely know anything about. > > There is a big difference, to my mind, between what is being exposed here in Java versus what is being exposed in the type ($). Consider that the boxed/unboxed distinction exists in Java but needn't come up in any beginner tutorials. > > >Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. > > We can't assume Haskell learners know what pointers are. This, again, creates unnecessary noise for learners by forcing exposure to things that are irrelevant for a very long time. > > > On Fri, Feb 5, 2016 at 12:13 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > Perhaps it will aid the discussion to see that the type of ($) will, for better or worse, be changing again before 8.0. > > The problem is described in GHC ticket #11471. The details of "why" aren't all that important for this discussion, but the resolution might be. The new (hopefully final!) type of ($) will be: > > > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b > > Once again, it's easy enough to tweak the pretty-printer to hide the complexity. But perhaps it's not necessary. The difference as far as this conversation is concerned is that Levity has been renamed to RuntimeRep. I think this is an improvement, because now it's not terribly hard to explain: > > --- > 1. Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. > 2. But sometimes, we don't care how a value is represented. In this case, we can be polymorphic in the choice of representation, just like `length` is polymorphic in the choice of list element type. > 3. ($) works with functions whose result can have any representation, as succinctly stated in the type. Note that the argument to the function must be boxed, however, because the implementation of ($) must store and pass the argument. It doesn't care at all about the result, though, allowing for representation-polymorphism. > > In aid of this explanation, we can relate this all to Java. The reference types in Java (e.g., Object, int[], Boolean) are all like types of kind *. The primitive types in Java (int, boolean, char) do not have kind *. Java allows type abstraction (that is, generics) only over the types of kind *. Haskell is more general, allowing abstraction over primitive types via representation polymorphism. > --- > > Could this all be explained to a novice programmer? That would be a struggle. But it could indeed be explained to an intermediate programmer in another language just learning Haskell. > > For point of comparison, Java is widely used as a teaching language. And yet one of the simplest programs is > > public class HelloWorld > { > public static void main(String[] args) > { > System.out.println("Hello, world!"); > } > } > > When I taught Java (I taught high-school full time for 8 years), I would start with something similar to this and have to tell everyone to ignore 90% of what was written. My course never even got to arrays and `static`! That was painful, but everyone survived. This is just to point out that Haskell isn't the only language with this problem. Not to say we shouldn't try to improve! > > We're in a bit of a bind in all this. We really need the fancy type for ($) so that it can be used in all situations where it is used currently. The old type for ($) was just a plain old lie. Now, at least, we're not lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth because it affects how easy the language is to learn? I don't really think anyone is advocating for (3) exactly, but it's hard to have (2) and not make things more complicated -- unless we have a beginners' mode or other features in, say, GHCi that aid learning. As I've said, I'm in full favor of adding these features. > > Richard > > On Feb 5, 2016, at 12:55 PM, Kyle Hanson <me(a)khanson.io> wrote: > >> I am also happy the discussion was posted here. Although I don't teach Haskell professionally, one of the things I loved to do was show people how simple Haskell really was by inspecting types and slowly putting the puzzle pieces together. >> >> Summary of the problem for others: >> From Takenobu Tani >> Before ghc7.8: >> >> Prelude> :t foldr >> foldr :: (a -> b -> b) -> b -> [a] -> b >> >> Prelude> :t ($) >> ($) :: (a -> b) -> a -> b >> >> Beginners should only understand about following: >> >> * type variable (polymorphism) >> >> >> After ghc8.0: >> >> Prelude> :t foldr >> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b >> >> Prelude> :t ($) >> ($) >> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >> (a -> b) -> a -> b >> >> >> With this change it looks like I will no longer be able to keep `$` in my toolbox since telling a beginner its "magic" goes against what I believe Haskell is good at, being well defined and easy to understand (Not well defined in terms of Types but well defined in terms of ability to precisely and concisely explain and define whats going on). >> >> It looks like where the discussion is going is to have these types show by default but eventually have an Alternative prelude for beginners. >> >> From Richard Eisenberg: >> - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. >> I don't like the idea of fragmenting Haskell into "beginners" and "advanced" versions. Its hard enough to get people to believe Haskell is easy. If they see that they aren't using the "real" prelude, Haskell will still be this magic black box that is too abstract and difficult to understand. If they have to use a "dumbed down" version of Haskell to learn, its not as compelling. >> >> There is something powerful about using the same idiomatic tools as the "big boys" and have the tools still be able to be easy to understand.... by default. Adding complexity to the default Haskell runs the risk of further alienating newcomers to the language who have a misconception that its too hard. >> >> Admittedly, I am not well informed of the state of GHC 8.0 development and haven't had time to fully look into the situation. I am very interested to see where this conversation and the default complexity of Haskell goes. >> >> -- >> Kyle >> >> >> On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> wrote: >> On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: >> > > What's changed? >> > >> > I was referring to a discussion on ghc-devs, see >> > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html >> > and mixed up addresses when replying. >> >> I'm glad you did, because this is the first I've heard of it! >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > Chris Allen > Currently working on http://haskellbook.com > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

27 59

Combining ST with STM
by Thomas Koster 10 Feb '16

10 Feb '16

Hi friends, I have an STM transaction that needs some private, temporary state. The most obvious way is to simply pass pure state as arguments, but for efficiency, I would like this state to be some kind of mutable array, like STArray. I know, STM has TVars and TArray, but since this state is private to the transaction, I am wondering if using TVars/TArrays for private state might be overkill that will unnecessarily slow down the STM commit process. The private state is, by definition, not shared, so including it in the STM log and commit process is, as far as I can tell, pointless. ST and STArray still appear to be the most appropriate tools for the private state, because STRefs and STArrays really, really are private. So this basically means I want to interleave ST and STM in a "safe" way. That is, if the STM transaction retries, I want the ST state to be vaporised as well. Ideally, I would love to be able to say something like this: -- | Copy the value from the shared TVar into the private STRef. load :: TVar a -> STRef a -> STSTM s () load shared private = do value <- liftSTM (readTVar shared) liftST (writeSTRef private value) Naturally, that STRef must originate from a call to newSTRef earlier in the same transaction and is private to it, just like the real ST monad. As far as I can tell, I am not trying to weaken either ST or STM in any way here. I found the STMonadTrans package on Hackage [1] that claims to implement ST as a monad transformer, STT, which sounds close to what I want. While its documentation does not mention STM, it does say that some monads are unsafe to use as a base monad for STT. Is STMonadTrans safe to use with STM? [1] https://hackage.haskell.org/package/STMonadTrans Thanks, Thomas Koster

4 9

ANNOUNCE: hoppy, qtah
by Bryan Gardiner 09 Feb '16

09 Feb '16

Are you sick and tired of the ease with which Haskell code flows onto the page? Even the thrill of binding to a C library losing its lustre? Look no further! I present to you a tool restoring the good old days of pointer arithmetic, manual memory management, and hours lost to the debugger: Hoppy is a new C++ FFI generator for Haskell. It takes Haskell code that describes a C++ API, and generates C++ and Haskell code to allow the two languages to interact. It supports a good subset of C++, including functions, classes, variables, enums and bitflags, operator overloading, constness, and simple templates. Adding a function takes only a few lines of code, and you normally don't need to write C++ yourself. For example, a definition for std::string is: c_string :: Class c_string = addReqIncludes [includeStd "string"] $ classAddFeatures [Assignable, Comparable, Copyable, Equatable] $ makeClass (ident1 "std" "string") (Just $ toExtName "StdString") [] [ mkCtor "new" [] , mkCtor "newFromCString" [TPtr $ TConst TChar] ] [ mkConstMethod' "at" "at" [TInt] $ TRef TChar , mkConstMethod' "at" "get" [TInt] TChar , mkConstMethod "c_str" [] $ TPtr $ TConst TChar , mkConstMethod "size" [] TSize , mkConstMethod OpAdd [TObj c_string] $ TObj c_string ] Now, writing a FFI generator isn't much fun unless you have a project to use it with. So I am pleased to also announce Qtah, a fresh set of Qt 4/5 bindings. These include portions of QtCore, QtGui, and QtWidgets, and are on the whole wildly incomplete, but are usable for basic tasks so far, and I am working on extending coverage. (On qtHaskell/hsQt: I started Qtah before qtHaskell began being updated in 2015 and I missed when that happened. My hope is that Qtah requires less code and effort to maintain; at least, qtHaskell contains a lot of generated code and I haven't seen where it came from, so please correct me if the generator is in fact available somewhere. Hoppy also doesn't (currently) do many of the fancy things that qtHaskell does, like overloading and garbage collection.) Both Hoppy and Qtah are young, and I am very interested in discussing how to make them most useful for the community. Because of questions such as this[1], their APIs (including those of generated bindings) should be considered experimental at this time. I will be uploading Hoppy to Hackage shortly. Becuase Qtah includes a shared library, I haven't figured out how to get that on Hackage yet, so you'll have to clone the repo yourself. http://khumba.net/projects/hoppy http://khumba.net/projects/qtah Happy hacking! Bryan Gardiner [1] https://gitlab.com/khumba/hoppy/issues/3

2 2

maps over arrays that provide the position index for the array and accelerate libraries?
by Rob Stewart 09 Feb '16

09 Feb '16

In vector library there's this useful function: imap :: (Int -> a -> b) -> Vector a -> Vector b And in Data.Map there's this similar function: mapWithKey :: (k -> a -> b) -> Map k a -> Map k b I'm looking for something similar in the array and accelerate libraries, i.e. On arrays in Data.Array.IArray: imap :: (IArray a e, IArray a e', Ix i) => (i -> e -> e') -> a i e -> a i e' And on Accelerate arrays: imap :: (Shape ix, Elt a, Elt b) => (Exp ix -> Exp a -> Exp b) -> Acc (Array ix a) -> Acc (Array ix b) Is anyone aware of such map implementations for arrays in the array and accelerate libraries, that provide your mapped function not only the element at a position, but also the index at that position? Thanks, -- Rob

2 1

Including a "XXX_stub.h" file from another Haskell library?
by Alp Mestanogullari 09 Feb '16

09 Feb '16

Hello -cafe! Let's say I have two Haskell libraries, `A` and `B`. `A` uses the FFI, `foreign export` to be precise, to make a Haskell function available to C land. This generates a "stub" C header file with a corresponding C function declaration. `B` has some C code in it and needs to include the stub header that was generated when compiling `A`, in order to call the function that I 'foreign export'ed in A. When I "naively" include the stub header file for the module in A that contains the 'foreign export' statement, inside one of the C files of the `B` library, the said header can't be found. Is what I want to do at all possible? If yes, how could I make this work? Thanks! -- Alp Mestanogullari

2 1

A Sliding TChan?
by Mark Fine 09 Feb '16

09 Feb '16

We're currently using a TMChan to broadcast from a single producer thread to many consumer threads. This works well! However, we're seeing issues with a fast producer and/or a slow consumer, with the channel growing unbounded. Fortunately, our producer-consumer communication is time-sensitive and tolerant of loss: we're ok with the producer always writing at the expense of dropping communication to a slow consumer. A TMBChan provides a bounded channel (but no means to dupe/broadcast) where a writer will block once the channel fills up. In our use case, we'd like to continue writing to the channel but dropping off the end of the channel. Clojure's core-async module has some related concepts, in particular the notion of a sliding buffer <https://clojure.github.io/core.async/#clojure.core.async/sliding-buffer> that drops the oldest elements once full. Has anyone encountered something similar in working with channels and/or have any solutions? Thanks! Mark

5 5

PSA: If you're serializing floating point numbers, don't use binary
by Francesco Mazzoli 09 Feb '16

09 Feb '16

Serialization of floating point numbers with binary is fantastically slow and incorrect if you’re using NaNs, see https://github.com/kolmodin/binary/issues/64 <https://github.com/kolmodin/binary/issues/64> https://github.com/kolmodin/binary/issues/69 <https://github.com/kolmodin/binary/issues/69> I recently spent half a day debugging performance problems because of this, and since backwards compatibility with older formats is required, this problem is probably not going to be solved. We decided to switch to cereal for this reason. With some patches <https://github.com/GaloisInc/cereal/pull/46> cereal was 30x faster for the data we were serializing (scientific computing, mostly Doubles packed in nested records containing vectors). The size of the serialized data is also roughly 3 times smaller – with binary a Double takes at least 25 bytes of space instead of 8. With Float it’s even worse, 25 bytes instead of 8.

2 2

ICFP 2016 Second Call for Papers
by Lindsey Kuper 09 Feb '16

09 Feb '16

ICFP 2016 The 21st ACM SIGPLAN International Conference on Functional Programming http://conf.researchr.org/home/icfp-2016 Second Call for Papers Important dates --------------- Submissions due: Wednesday, March 16 2016, 15:00 (UTC) https://icfp2016.hotcrp.com (now open) Author response: Monday, 2 May, 2016, 15:00 (UTC) - Thursday, 5 May, 2016, 15:00 (UTC) Notification: Friday, 20 May, 2016 Final copy due: TBA Early registration: TBA Conference: Monday, 19 September - Wednesday, 21 September, 2016 (note updated conference dates) Scope ----- ICFP 2016 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. Topics of interest include (but are not limited to): - Language Design: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. - Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and 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; monads; continuations; control; state; effects; program verification; dependent types. - Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. - Applications: 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 and 3D graphics programming; scripting; system administration; security. - Education: teaching introductory programming; parallel programming; mathematical proof; algebra. - 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. If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ------------------------------------ - By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at most 12 pages (6 pages for an Experience Report), in standard SIGPLAN conference format, including figures but ***excluding bibliography***. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. ***ICFP 2016 will employ a lightweight double-blind reviewing process.*** To facilitate this, submitted papers must adhere to two rules: 1. ***author names and institutions must be omitted***, and 2. ***references to authors' own related work should be in the third person*** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the PC and external reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. We have put together a document answering frequently asked questions that should address many common concerns: http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-R… (last updated February 8, 2016). - Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of your paper and learned your identity. - Each submission must adhere to SIGPLAN's republication policy, as explained on the web at: http://www.sigplan.org/Resources/Policies/Republication - 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 reviewer 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 given below. Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from at least one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard SIGPLAN 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 at http://www.sigplan.org/Resources/Author/ Submission: Submissions will be accepted at https://icfp2016.hotcrp.com. 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 72-hour period, starting at 15:00 UTC on Monday, 2 May, 2016, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for free downloads from the ACM DL. AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. Special categories of papers ---------------------------- In addition to research papers, ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to six pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ================= A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: - a new and thought-provoking way of looking at an old idea - an instructive example of program calculation or proof - a nifty presentation of an old or new data structure - an interesting application of functional programming techniques - a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission you wish to have treated as a pearl must be marked as such on the submission web page, and should contain the words ``Functional Pearl'' somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. Experience Reports ================== The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works ? or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: - insights gained from real-world projects using functional programming - comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum - project-management, business, or legal issues encountered when using functional programming in a real-world project - curricular issues encountered when using functional programming in education - real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal ICFP paper by its title, by its length, and by the criteria used to evaluate it. - Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words ``Experience Report'' followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. - An Experience Report is at most six pages long. Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. - Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. If functional programming worked for you in the same ways it has worked for others, you need only to summarize the results?the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterize your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. If your paper not only describes experience but also presents new technical results, or if your experience refutes cherished beliefs of the functional-programming community, you may be better off submitting it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. If you are unsure in which category to submit, the program chair will be happy to help you decide. Organizers ---------- General Co-Chairs: Jacques Garrigue (Nagoya University) Gabriele Keller (University of New South Wales) Program Chair: Eijiro Sumii (Tohoku University) Program Committee: Koen Claessen (Chalmers University of Technology) Joshua Dunfield (University of British Columbia, Canada) Matthew Fluet (Rochester Institute of Technology) Nate Foster (Cornell University) Dan Grossman (University of Washington, USA) Jurriaan Hage (Utrecht University) Roman Leshchinskiy (Standard Chartered Bank) Keisuke Nakano (The University of Electro-Communications) Aleksandar Nanevski (IMDEA Software Institute) Scott Owens (University of Kent) Sungwoo Park (Pohang University of Science and Technology) Amr Sabry (Indiana University) Tom Schrijvers (KU Leuven) Olin Shivers (Northeastern University) Walid Taha (Halmstad University) Dimitrios Vytiniotis (Microsoft Research, Cambridge) David Walker (Princeton University) Nobuko Yoshida (Imperial College London, UK) External Review Committee: See http://conf.researchr.org/committee/icfp-2016/icfp-2016-papers-external-rev….

1 0

Matrices as Applicatives and Monads
by Strikingwolf2012 . 09 Feb '16

09 Feb '16

I have been writing code encoding matrices here <https://github.com/Strikingwolf/Learning/blob/master/haskell/src/math/Matri…> as a learning experience. However, I cannot figure out a method to make Matrix an instance of Applicative and Monad. I believe it is possible, but I cannot find an implementation. For context my form of Matrix does not have a requirement to be of integers, it is just a 2-Dimensional array in essence. Thank you in advance for any help you may provide :)

2 1