- Haskell-Cafe - Haskell.org

List instance of Alternative: why (++)?
by Theodore Lief Gannon 28 May '17

28 May '17

Fiddling around, I found myself wanting: coalesce :: [a] -> [a] -> [a] -- or -- :: (Foldable t) => t a -> t a -> t a coalesce a b = if null a then b else a I expected this to be (<|>) (it is for Maybe!) but instead I find no canonical implementation of it anywhere, and what seems like a useless instance Alternative []. What's the rationale?

7 8

Yesod Problem - passing values inside a route
by Michael Litchard 28 May '17

28 May '17

Below I have an example from the Yesod <https://www.yesodweb.com/book/forms> book. The form action maps to a route. How do I pass a value to that route. I know it has something to do with ^ but I can't see to make it work right. {-# LANGUAGE MultiParamTypeClasses #-}{-# LANGUAGE OverloadedStrings #-}{-# LANGUAGE QuasiQuotes #-}{-# LANGUAGE TemplateHaskell #-}{-# LANGUAGE TypeFamilies #-}import Control.Applicativeimport Data.Text (Text)import Yesod data App = App mkYesod "App" [parseRoutes|/ HomeR GET/input InputR GET|] instance Yesod App instance RenderMessage App FormMessage where renderMessage _ _ = defaultFormMessage data Person = Person { personName :: Text , personAge :: Int } deriving Show getHomeR :: Handler Html getHomeR = defaultLayout [whamlet| <form action=@{InputR}> <--- problem line -- want to do this <form action=@{InputR ^haskellValue}> <p> My name is <input type=text name=name> and I am <input type=text name=age> years old. <input type=submit value="Introduce myself"> |] getInputR :: Text -> Handler Html getInputR label = do person <- runInputGet $ Person <$> ireq textField label <*> ireq intField "age" defaultLayout [whamlet|<p>#{show person}|] main :: IO () main = warp 3000 App

2 1

stack problems
by Dennis Raddle 28 May '17

28 May '17

Trying to learn stack. I'm following the tutorial on this page: https://docs.haskellstack.org/en/stable/GUIDE/ I built helloworld. Then I modified Lib.hs to include Data.Text.IO, as the tutorial specifies. I typed 'stack build' and got the error that the text package wasn't installed, as the tutorial says I would. I then modified helloworld.cabal to have these lines: build-depends: base , helloworld , text and typed 'stack build' again. I got the exact same output - an error on building Lib.hs, 'Failed to load interface for Data.Text.IO. I checked that I really modified al lthe right files and can't find anything I did wrong.

3 3

ThEdu'17: 2nd Call for Extended Abstracts & Demonstrations
by Achim D. Brucker 27 May '17

27 May '17

(Apologies for duplicates) Call for Extended Abstracts & Demonstrations ThEdu'17 Theorem proving components for Educational software http://www.uc.pt/en/congressos/thedu/thedu17 at CADE 26 International Conference on Automated Deduction 6-11 August 2017 Gothenburg, Sweden http://www.cade-26.info/ ThEdu'17 Scope Computer Theorem Proving is becoming a paradigm as well as a technological base for a new generation of educational software in science, technology, engineering and mathematics. The workshop brings together experts in automated deduction with experts in education in order to further clarify the shape of the new software generation and to discuss existing systems. Topics of interest include: * methods of automated deduction applied to checking students' input; * methods of automated deduction applied to prove post-conditions for particular problem solutions; * combinations of deduction and computation enabling systems to propose next steps; * automated provers specific for dynamic geometry systems; * proof and proving in mathematics education. Important Dates Extended Abstracts: 18 June 2017 Author Notification: 2 July 2017 Final Version: 16 July 2017 Workshop Day: 6 August 2017 Submission Interested researchers are invited to submit extended abstracts and system descriptions. Both kinds of submissions should be approximately 5 pages in length and present original unpublished work not submitted elsewhere. Submission is in PDF format via easychair, https://easychair.org/conferences/?conf=thedu17 formatted according to http://www.easychair.org/publications/easychair.zip The extended abstracts and system descriptions will be made available online. At least one author is expected to presents his/her submission at ThEdu'17. Joint publication in companion with other CADE26 events is under consideration (as a volume in the EPiC Series in Computing). Program Committee Francisco Botana, University of Vigo at Pontevedra, Spain Achim D. Brucker, University of Sheffield, United Kingdom Filip Maric, University of Belgrade, Serbia Walther Neuper, Graz University of Technology, Austria (co-chair) Pavel Pech , University of South Bohemia, Czech Republic Pedro Quaresma, University of Coimbra, Portugal (co-chair) Vanda Santos, CISUC, Portugal Wolfgang Schreiner, Johannes Kepler University, Austria Burkhart Wolff, University Paris-Sud, France -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Re: [Haskell-cafe] wiki account request
by Flavio Villanustre 27 May '17

27 May '17

I just created an account for you. You should be receiving a temporary password via email in the next few minutes. Please let me know if you need any further assistance to log in. Best, Flavio On May 27, 2017 02:50, "jzeus" <jzeus(a)protonmail.com> wrote: username "jzeus"

1 0

problems with stack, config.yaml
by Dennis Raddle 26 May '17

26 May '17

A year ago I tried to install stack on my MacBook. Just recently I tried again, and it asked me if I wanted to upgrade rather than install. I did so, but got an error (some message from GHC saying 'the thing that should never happen, happened' or something like that). So I thought, okay let me try uninstalling stack first, then installing it, and going from there. So I did that, and I'm working the stack tutorial, and upon doing "stack setup" I got a parse error in config.yaml. "Error in $.params: failed to parse field 'params', expected Map k a, encountered String" As far as the question of where I got my config.yaml from, I edited something that was there to add some specific information, but I am not sure if I changed anything else. Here is the config.yaml that produces the above error: # This file contains default non-project-specific settings for 'stack', used # in all projects. For more information about stack's configuration, see # http://docs.haskellstack.org/en/stable/yaml_configuration/ # The following parameters are used by "stack new" to automatically fill fields # in the cabal config. We recommend uncommenting them and filling them out if # you intend to use 'stack new'. # See https://docs.haskellstack.org/en/stable/yaml_configuration/#templates templates: params: author-name:Dennis author-email:dennisraddle@gmail.com category:programming copyright:2017 github-username:Dennis

2 1

Adding support for user defined data types to cassandra-cql
by Cody Goodman 26 May '17

26 May '17

Hello all, I wrote some template Haskell code that looks up data in a cassandra database in the system.schema_columns table using this library: https://github.com/the-real-blackh/cassandra-cql/blob/master/Database/Cassa… Currently cassandra-cql lets you make queries like this: getColFamInfo :: Query Rows () (Text, Text, Text, Text, Text) getColFamInfo = "select keyspace_name, columnfamily_name, column_name, type, validator from system.schema_columns" And then it returns type (Text,Text,Text,Text,Text). I'd prefer to be able to write a query like: data MyRecord = MyRecord { a :: Text, b :: Text, c :: Text, d :: Text } getColFamInfo :: Query Rows () (Maybe MyRecord) getColFamInfo = "select keyspace_name, columnfamily_name, column_name, type, validator from system.schema_columns" Point being: I have types being generated from cassandra, but I have no idea where I'd start modifying the cassandra-cql library to use those types. Could anyone offer any direction? Also... Below is a snippet of how Query is implemented, but you can find the full code here: https://github.com/the-real-blackh/cassandra-cql/blob/master/Database/Cassa… Query Looks like: { - START CODE -} -- | The first type argument for Query. Tells us what kind of query it is. data Style = Schema -- ^ A query that modifies the schema, such as DROP TABLE or CREATE TABLE | Write -- ^ A query that writes data, such as an INSERT or UPDATE | Rows -- ^ A query that returns a list of rows, such as SELECT -- | The text of a CQL query, along with type parameters to make the query type safe. -- The type arguments are 'Style', followed by input and output column types for the -- query each represented as a tuple. -- -- The /DataKinds/ language extension is required for 'Style'. data Query :: Style -> * -> * -> * where Query :: QueryID -> Text -> Query style i o deriving Show queryText :: Query s i o -> Text queryText (Query _ txt) = txt instance IsString (Query style i o) where fromString = query . T.pack -- | Construct a query. Another way to construct one is as an overloaded string through -- the 'IsString' instance if you turn on the /OverloadedStrings/ language extension, e.g. -- -- > {-# LANGUAGE OverloadedStrings #-} -- > ... -- > -- > getOneSong :: Query Rows UUID (Text, Text, Maybe Text) -- > getOneSong = "select title, artist, comment from songs where id=?" query :: Text -> Query style i o query cql = Query (QueryID . hash . T.encodeUtf8 $ cql) cql { - END CODE -} Thanks, Cody Goodman

1 0

Munich Haskell Meeting, 2017-05-29 @ 19:30
by Christian Neukirchen 25 May '17

25 May '17

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 29 at Max Emanuel Brauerei at 19h30. We'll try to get seats outside, so please be on time. For details see here: http://muenchen.haskell.bayern/dates.html 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-may-2017/ Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

Haskell performance when it comes to regex?
by Bram Neijt 24 May '17

24 May '17

Dear reader, I decided to do a little project which is a simple search and replace program for large text files. Written in Haskell, it does a few different regex matches on each line and stores them in a leveldb key-value store to create a consistent/reviewable search-replace index. It should provide for some simple/brute-force anonymization of data and therefore I called it hanon (sorry, could not think of a better name). https://github.com/BigDataRepublic/hanon The code works, but I've done some benchmarking to compare it with Python and the code is about 80x slower then doing the same thing in Python, making it useless for larger data files. I'm obviously doing something wrong. Could you give me tips on improving the performance of this code? Probably mainly looking at https://github.com/BigDataRepublic/hanon/blob/master/src/Mapper.hs where the regex code lives? Greetings, Bram

5 5

Accepted projects for Summer of Haskell 2017
by Niki Vazou 24 May '17

24 May '17

Hey all, We are happy to announce the 15 projects accepted for Summer of Haskell 2017 and that the community bonding period has begun. If there are people who would like to co-mentor a project, please let us know. # Haskell.org projects 1. Safe streaming with linear types Student: Edvard Hübinette Mentor: Arnaud Spiwack 2. Improve the GHC Performance test suite Student: Shivansh Rai Mentor: Ben Gamari 3. Haskell IDE Engine Student: Zubin Duggal Mentor: Alan Zimmerman 4. Last Mile for cabal new-build Student: Francesco Gazzetta Mentor: Daniel Wagner 5. Totality checking base with Liquid Haskell Student: Sean Leffler Mentor: Niki Vazou Co-mentor: Eric Seidel 6. Modularizing haskell-mode and improving haskell-interactive-mode Student: Vasantha Ganesh Kanniappan Mentor: Gracjan Polak 7. Haskey (an embedded key-value store modeled after LMDB) Student: Henri Verroken Mentor: Steven Keuchel Co-mentor: George Karachalias 8. Improve the Shake-Based Hadrian Build System for GHC Student: Zhen Zhang Mentor: Andrey Mokhov 9. GHC Performance improvements Student: Igor Popov Mentor: Jose Calderon 10. Improvement of Hackage Matrix Builder Student: Andika Demas Riyandi Mentor: Herbert Valerio Riedel 11. WebGHC (a WebAssembly backend for GHC) Student: Michael Vogelsang Mentor: Will Fancher # code.world projects 12. Better collaborative coding features for CodeWorld Student: Parv Mor Co-mentor: Michael Chavinda Co-mentor: Anthony Green 13. Improvements to parsing, compiling, and errors for CodeWorld Student: Pranjal Tale Primary Mentor: Kyle Butt Secondary Mentor: Chris Smith 14. Exporting and sharing CodeWorld projects Student: Venkatraman Srikanth Primary Mentor: Theo Belaire Secondary Mentor: Han Wang 15. Improve editor tooling for CodeWorld Student: Eric Roberts Primary Mentor: Emin Karayel Secondary Mentor: Fernando Alegre We would like to thank all students who applied for the quality proposals. We received 68 so selecting the projects was extremely difficult. Yet, three new positions opened during selection period to accept high quality applications. Summer of Haskell 2017 is made possible by our generous sponsors: - [haskell.org](http://haskell.org) kicked things off this year by funding a student and organizing the Summer of Haskell 2017 after a successful [Summer of Haskell 2016]( https://mail.haskell.org/pipermail/haskell-cafe/2016-December/125702.html) - [Asahi Net](https://asahi-net.jp/en/) is a Japanese Internet service provider that has been running stable systems for over 25 years. They are a proud sponsor of the Summer of Haskell, and contribute to the Japanese Haskell community. - [Awake Networks](http://www.awakenetworks.com/) is building a next generation network security and analytics platform. They are a proud sponsor of the Summer of Haskell and contribute broadly to the Haskell community. - [CodeWorld](http://code.world/) is an educational project that blends mathematics and Haskell programming into a visual playground. Chris Smith has volunteered to fund two students to work on CodeWorld in particular. - [Digital Asset](http://digitalasset.com/) provides Distributed Ledger solutions for financial institutions globally. They have developed a pure, typed, functional, domain specific language for writing contracts, called DAML. They are a proud sponsor of the Summer of Haskell and contribute broadly to the Haskell community. - [Facebook](http://facebook.com/) uses Haskell in its [anti-abuse infrastructure]( https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/) and as part of that effort we open-sourced the [Haxl]( https://github.com/facebook/Haxl) framework which is being used at scale in production to automatically parallelise data-fetching code. We're delighted to be able to support the Haskell community's efforts by sponsoring a student for this year's Summer of Haskell. - [Fugue Inc.](http://fugue.co/) radically simplifies cloud operations with its software-defined system for dynamically orchestrating and enforcing cloud infrastructure at scale. Fugue uses Haskell in its product and is proud to sponsor a student to improve the ecosystem. - [Galois](http://galois.com/) applies cutting-edge computer science and applied mathematics to solve difficult technological problems, delivering practical solutions tailored to our clients’ needs. Haskell and other functional programming languages are key tools we use in providing these solutions. - [IOHK](https://iohk.io/) is a technology company committed to using peer-to-peer technologies to provide financial services to the three billion people who don't have them. We implement our first-principles cryptographic research in Haskell and we are committed to the development of the Haskell ecosystem. - [Tweag I/O](http://tweag.io) is a network of software innovation labs across Europe. We develop novel solutions and products for our clients around the world. Haskell is key to delivering fast, correct and maintainable code. We have shipped Haskell in anything from tiny web services to large high-performance compute clusters with custom hardware. We're particularly keen to help the community grow Haskell into the strongest systems programming language and ecosystem out there. We're very proud to sponsor a student this summer to help make it happen. Davean has volunteered to fund a student expressly to work on the [Hadrian build system for GHC](/ideas.html#hadrian-ghc). Steven Keuchel has provided funds for a student to work on Haskey. Niki Vazou & Jasper Van der Jeugt

1 0

ANNOUNCE: Haskell Communities and Activities Report (32nd ed., May 2017)
by Mihai Maruseac 24 May '17

24 May '17

On behalf of all the contributors, we are pleased to announce that the Haskell Communities and Activities Report (32nd edition, May 2017) is now available, in PDF and HTML formats: http://haskell.org/communities/05-2017/report.pdf http://haskell.org/communities/05-2017/html/report.html All previous editions of HCAR can be accessed on the wiki at https://wiki.haskell.org/Haskell_Communities_and_Activities_Report Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. We hope you will find it as interesting a read as we did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline) to the call. The editors collect all the contributions into a single report and feed that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ======================================== End of September 2016: target deadline for contributions to the November 2017 edition of the HCAR Report ======================================== Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editors for a simple e-mail reminder in November (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 24 May '17

24 May '17

> On Wed May 24 07:57:09 UTC 2017, Alejandro Serrano Mena wrote: > I know I am just jumping in the middle of an already long > discussion. Hi Alejandro, your input is very welcome. I know there have been many posts, so Richard's right the idea now needs writing up in detail in one place. > > > > Bottom line: You win. I'm convinced. Apartness guards .. > > > > Even better, I think apartness guards would be very easy > > to implement. All the plumbing is already installed: we > > basically just have to add a switch. > > > I would like to advise against this idea of apartness > guards. I've tried myself some years ago, and I remember > them being quite complicated to describe. ... That's interesting. What did you try? How did you test for apartness? I roughed out the rules a few posts back. Bottom of https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127103.html The body of that post has worked examples. I can also translate guards into Haskell2010 + MPTCs, providing there's a primitive for type-level type comparison. (Which we could write today with Closed Type Families.) See https://mail.haskell.org/pipermail/haskell-cafe/2017-May/127090.html discussion of (?~). This is essentially the 'case-preparing' technique from HList [2004]. > The main problem is that apartness may end up > introducing some sort of backtracking > in the type checking process -- something > completely undesirable. I agree that's not just undesirable, but unacceptable. (Backtracking is a weakness of Instance chains IMO.) With the guards I'm thinking of, an instance either applies at a usage site or does not (after taking guards into account). Or type refinement hasn't advanced enough to decide. Then that instance remains 'in play'. This is exactly the same process as currently. If an instance does apply (with guards) then it is guaranteed to be the only instance. IOW all other instances are excluded. So: > Furthermore, they make the work of > the overlapping checks much harder. The guards remove any need for overlapping checks. Instead the compiler must unify the usage site with the instance head, then substitute into the guards. If a guard comes out false under that subst, reject the instance. If all guards come out true, select the instance. If some guards come out 'not proven', it needs more type refinement. So you can't have OverlappingInstances as well as InstanceGuards. (Or at least not for the same class/type family. That's a bit of backwards compatibility awkwardness I mentioned.) AntC

1 0

Re: [Haskell-cafe] Nomyx V1.0, the only game where you can change the rules
by Corentin Dupont 24 May '17

24 May '17

Hi Ben! Thanks a lot, it's corrected. The GUI tutorial is based on an old version of the GUI, although the principles remain the same. The new GUI is much more intuitive (I hope). Cheers! On Wed, May 24, 2017 at 10:00 AM, Ben Kolera <ben.kolera(a)gmail.com> wrote: > Hi Corentin, > > I notice that you've got some broken links on that first page. Namely: > > part 1 Nomyx GUI > <http://www.corentindupont.info/blog/posts/2014-09-23-first-Nomyx-tutorial.h…> > part 2 Nomyx Language > <http://www.corentindupont.info/blog/posts/2014-09-23-Nomyx-Language.html> > > Just thought that you may want to know. Your game looks fun! :) > > Cheers, > Ben > > On Wed, 24 May 2017 at 03:27 Corentin Dupont <corentin.dupont(a)gmail.com> > wrote: > >> Hi Haskellers, >> in case you didn't see it on Reddit (sorry for cross-posting): >> >> I released Nomyx V1.0 <http://www.nomyx.net/>! >> Nomyx is a unique game where you can change the rules of the game itself >> while playing it. >> The major novelty in this version is that you can play even without >> knowing how to program. There is a library of rules that are ready to be >> proposed. >> >> A match is going on on the theme "Foundation" (and we need more players). >> Please join! >> >> You can login here: http://www.nomyx.net:8000/Nomyx >> The games are discussed on the mailing list: nomyx-game(a)googlegroups.com >> >> Here is a video introduction of the game: http://vimeo.com/58265498 >> I created a tutorial to learn how to play: http://www.corentindupont. >> info/blog/posts/Programming/2014-09-23-Nomyx-Language.html >> >> Some background: this is an implementation of a Nomic [1] game in Haskell >> (I believe the first complete implementation of a Nomic game on a >> computer). At the beginning, the initial rules are describing: >> >> - how to add new rules and change existing ones. For example a >> unanimity vote is necessary to have a new rule accepted. >> - how to win the game. For example you win the game if you have 5 >> rules accepted. >> >> But of course even that can be changed! >> >> Cheers, Corentin >> >> [1] https://en.wikipedia.org/wiki/Nomic >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > >

1 0

Nomyx V1.0, the only game where you can change the rules
by Corentin Dupont 23 May '17

23 May '17

Hi Haskellers, in case you didn't see it on Reddit (sorry for cross-posting): I released Nomyx V1.0 <http://www.nomyx.net/>! Nomyx is a unique game where you can change the rules of the game itself while playing it. The major novelty in this version is that you can play even without knowing how to program. There is a library of rules that are ready to be proposed. A match is going on on the theme "Foundation" (and we need more players). Please join! You can login here: http://www.nomyx.net:8000/Nomyx The games are discussed on the mailing list: nomyx-game(a)googlegroups.com Here is a video introduction of the game: http://vimeo.com/58265498 I created a tutorial to learn how to play: http://www.corentindupont.info/blog/posts/Programming/2014-09-23-Nomyx-Lang… Some background: this is an implementation of a Nomic [1] game in Haskell (I believe the first complete implementation of a Nomic game on a computer). At the beginning, the initial rules are describing: - how to add new rules and change existing ones. For example a unanimity vote is necessary to have a new rule accepted. - how to win the game. For example you win the game if you have 5 rules accepted. But of course even that can be changed! Cheers, Corentin [1] https://en.wikipedia.org/wiki/Nomic

1 0

Re: [Haskell-cafe] How to define a type in a TemplateHaskell function and use it in the same function?
by Anthony Clayden 23 May '17

23 May '17

> On Mon May 22 09:45:49 UTC 2017, Saurabh Nanda wrote: > Is there any way to have as single TH function, define a type, > and use the type, as well? In short, no. You must define/compile the TH function in a separate module, then import to where you want to use it. See second bullet of this: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… And any intro to TH will also explain why it's hard. At first I was puzzled why you didn't get an error message explaining that more clearly, but I can see your usage of the TH function is also incorrect. You're trying to make a data declaration. So that must appear at top level in the program. It makes no sense to appear inside a monad. Also I suspect the imported TH function `makeAdaptorAndInstance` is trying to generate an instance declaration. This must also appear at top level, not inside a monad. > Cross-posted from StackOverflow: ... Yes, that answer has also moved the $( ... ) to top level. AntC

1 0

How to define a type in a TemplateHaskell function and use it in the same function?
by Saurabh Nanda 22 May '17

22 May '17

Cross-posted from StackOverflow: http://stackoverflow.com/questions/44107336/how-to-define-a-type-in-a-templ… Is there any way to have as single TH function, define a type, and use the type, as well? Relevant code below. `PersonPoly2` is being defined by `makeRecordSplice` and then being passed to `makeAdaptorAndInstance` (provided by Opalaye), which is also a TH function. Relevant code given below: {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} module Lib where import Data.Profunctor.Product.TH (makeAdaptorAndInstance) import Language.Haskell.TH makeRecordSplice :: Q [Dec] makeRecordSplice = [d| data PersonPoly2 a b = Person2 { id :: a , name :: b } |] makeRecordAndAdapter :: Q [Dec] makeRecordAndAdapter = do record <- makeRecordSplice adapter <- makeAdaptorAndInstance "pPerson2" (mkName "PersonPoly2") return $ record ++ adapter ------------- /home/Projects/scratch/app/Main.hs:26:1: error: ‘PersonPoly2’ is not in scope at a reify Failed, modules loaded: Lib. -- Saurabh.

1 0

OverloadedRecordFields in GHC 8.2.1-rc2
by aditya siram 21 May '17

21 May '17

Hi, I'm trying out the GHC 8.2.1 release candidate [1], added 'OverloadedRecordFields' and I get an error saying it's an 'Unsupported Extension'. Am I doing something wrong? Thanks! -deech [1] https://mail.haskell.org/pipermail/ghc-devs/2017-May/014197.html

2 4

Re: [Haskell-cafe] Type Instance Partiality [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 21 May '17

21 May '17

> On Wed May 17 11:58:24 UTC 2017, Anthony Clayden wrote: >> On Mon May 15 16:20:09 UTC 2017, Richard Eisenberg wrote: >> ... >> See my recent draft paper ... > Yes I can see the sense in grounding type family > instances with class instances as Associated Types. Errk I see a fly in the ointment with these 'closed classes'/associated types. Suppose: A class with two assoc types * One assoc type needs the instances in a specific sequence. * The other assoc type needs the instances in a different sequence. Here's a simple (as in daft!) example: > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, FlexibleInstances #-} > > class (Flip a ~ b, Flop b ~ a) => FlipMaybe a b where > type Flip a > type Flop b > instance (a' ~ b) => FlipMaybe (Maybe a') b where > type Flip (Maybe a') = a' > type Flop b = Maybe b > instance (a ~ b') => FlipMaybe a (Maybe b') where > type Flip a = Maybe a > type Flop (Maybe b') = b' (If we wrote a closed class in that sequence, it would get `Flip` right but `Flop` wrong.) Those instances overlap at `FlipMaybe (Maybe a') (Maybe b')`, but we can't write a coherent instance for that overlap. (Using Instance Chains, we'd want a `Fail`.) This is how the instances would go with guards: > {-# LANGUAGE ..., InstanceGuards #-} > > instance (a' ~ b) > => FlipMaybe (Maybe a') b | b /~ (Maybe _) where > type Flip (Maybe a') = a' > type Flop b | b /~ (Maybe _) = Maybe b > instance (a ~ b') > => FlipMaybe a (Maybe b') | a /~ (Maybe _) where > type Flip a | a /~ (Maybe _) = Maybe a > type Flop (Maybe b') = b' Note these don't overlap (taking guards into account). IOW we get no available instance for the overlap above. >> it's really proposing dropping type families in favor of >> functional dependencies -- but only for partial type families. ... BTW, while exploring that daft example, I kinda got it to work by declaring `Flip`, `Flop` as stand-alone closed families. But had trouble with the (~) constraints on the class. I changed them to bidirectional FunDeps | a -> b, b -> a and all worked OK. With superclass `(Flop b ~ a)` ghc 8.0.1 complained Couldn't match type Flop b with Maybe b arising from the superclasses of an instance declaration In the instance declaration for FlipMaybe (Maybe a') b and contrariwise for `(Flip a ~ b)` This is perhaps similar to trac #9918 that you mention in the partiality paper. AntC

1 0

Haskell for Mac
by Dennis Raddle 19 May '17

19 May '17

Discovered an amazing $24.99 app: Haskell for Mac. IDE with playgrounds, I expect my small personal projects to work fine with this program, and development should proceed faster now. However I can't find documentation. For instance I'm not getting auto indentation to work for me, and I don't know how to create new modules. There is a community forum, but currently broken - can't log in. Wondering if anyone here has used this app and could direct me to docs. D

2 1

Reminder: Call for Presentations: CUFP 2017, September 7-9, Oxford, UK
by Alex Lang 19 May '17

19 May '17

This is just a reminder that there are 3 weeks until the deadline for CUFP 2017 submissions. I'll be at Compose conference today if anybody wants to ask me any questions. My badge reads "Alexandre Lang". The CFP and the form for submitting presentations proposals can be found at: http://cufp.org/2017/call-for-presentations.html ------------------------------------------------------------------------ > 2017 Call for Presentations > > Workshop for Commercial Users of Functional Programming 2017 > Sponsored by SIGPLAN > CUFP 2017 > Co-located with ICFP 2017 > Oxford, UK > September 7-9 > Talk Proposal Submission Deadline: 9 June 2017 > > The annual CUFP event is a place where people can see how others are > using functional programming to solve real world problems; where > practitioners meet and collaborate; where language designers and users > can share ideas about the future of their favorite language; and where > one can learn practical techniques and approaches for putting functional > programming to work. > > ------------------------------------------------------------------------ > > Giving a CUFP Talk > > If you have experience using functional languages in a practical > setting, we invite you to submit a proposal to give a talk at the event. > We're looking for two kinds of talks: > > Retrospective reports are typically 25 minutes long. Now that CUFP has > run for more than a decade, we intend to invite past speakers to share > what theyâ€™ve learned after a decade spent as commercial users of > functional programming. We will favour experience reports that include > technical content. > > Technical talks are also 25 minutes long, and should focus on teaching > the audience something about a particular technique or methodology, from > the point of view of someone who has seen it play out in practice. These > talks could cover anything from techniques for building functional > concurrent applications, to managing dynamic reconfigurations, to design > recipes for using types effectively in large-scale applications. While > these talks will often be based on a particular language, they should be > accessible to a broad range of programmers. > > We strongly encourage submissions from people in communities that are > underrepresented in functional programming, including but not limited to > women; people of color; people in gender, sexual and romantic > minorities; people with disabilities; people residing in Asia, Africa, > or Latin America; and people who have never presented at a conference > before. We recognize that inclusion is an important part of our ission > to promote functional programming. So that CUFP can be a safe > environment in which participants openly exchange ideas, we abide by the > SIGPLAN Conference Anti-Harassment Policy: > > http://www.sigplan.org/Resources/Policies/Anti-harassment > > If you are interested in offering a talk, or nominating someone to do > so, please submit your presentation before 09 June 2017 via the CUFP > 2017 Presentation Submission Form: > > https://goo.gl/forms/KPloANxHHwdiaoVj2 > > You do not need to submit a paper, just a short proposal for your talk. > There will be a short scribe's report of the presentations and > discussions but not of the details of individual talks, as the meeting > is intended to be more of a discussion forum than a technical > interchange. > > Nevertheless, presentations will be recorded and presenters will be > expected to sign an ACM copyright release form. > > Note that we will need presenters to register for the CUFP workshop and > travel to Oxford at their own expense. There are some funds available to > would-be presenters who require assistance in this respect. > > ------------------------------------------------------------------------ > > Program Committee > > Alex Lang (Tsuru Capital), co-chair > Rachel Reese (Mulberry Labs), co-chair > Garrett Smith (Guild AI) > Danielle Sucher (Jane Street) > Jasper Van der Jeugt (Fugue) > Yukitoshi Suzuki (Ziosoft) > Evelina Gabasova (University of Cambridge) > Brian Mitchell (Jet.com) > > ------------------------------------------------------------------------ > > More information > > For more information on CUFP, including videos of presentations from > previous years, take a look at the CUFP website at http://cufp.org. Note > that presenters, like other attendees, will need to register for the > event. Acceptance and rejection letters will be sent out by July 15th. > Guidance on giving a great CUFP talk > > Focus on the interesting bits: Think about what will distinguish your > talk, and what will engage the audience, and focus there. There are a > number of places to look for those interesting bits. > > Setting: FP is pretty well-established in some areas, including formal > verification, financial processing, and server-side web services. An > unusual setting can be a source of interest. If you're deploying > FP-based mobile UIs or building servers on oil rigs, then the challenges > of that scenario are worth focusing on. Did FP help or hinder in > adapting to the setting? > > Technology: The CUFP audience is hungry to learn about how FP techniques > work in practice. What design patterns have you applied, and to what > areas? Did you use functional reactive programming for user interfaces, > or DSLs for playing chess, or fault-tolerant actors for large-scale > geological data processing? Teach us something about the techniques you > used, and why we should consider using them ourselves. > > Getting things done: How did you deal with large-scale software > development in the absence of pre-existing support tools that are often > expected in larger commercial environments (IDEs, coverage tools, > debuggers, profilers) and without larger, proven bodies of libraries? > Did you hit any brick walls that required support from the community? > > Don't just be a cheerleader: It's easy to write a rah-rah talk about how > well FP worked for you, but CUFP is more interesting when the talks also > cover what doesn't work. Even when the results were all great, you > should spend more time on the challenges along the way than on the parts > that went smoothly.

1 0

exporting Constructors as pattern-only
by Andrew Butterfield 19 May '17

19 May '17

All, is there any way in Haskell to export a *data* type so that importing modules can pattern match, but not use the constructors to build anything? My use case is an AST with invariant - I want the convenience of pattern matching with the safety of having to build using functions exported by the model rather than the constructors directly. e.g given data T = T1 Bool | T2 Int | TT T T t1 :: Bool -> T t2 :: Int -> T tt :: T -> T -> T from outside I can write f(T1 False) = tt (t1 True) (t2 42) but not f(T1 False) = TT (T1 True) (T2 42) ? Regards, Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland

2 2

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 19 May '17

19 May '17

> On Fri May 12 17:22:35 UTC 2017, Richard Eisenberg wrote: > > ... [in] closed type families. (We > would also have to eliminate non-linear patterns, > replacing them with some other first-class test for > equality. > AntC's proposed disequality constraints then become > straightforward pattern guards. Guards don't have to be just disequalities. If you want to eliminate non-linear patterns, use _equality_ guards. Full example: > type family F a b where > F a a = a > F Int b = b > F a Bool = a > Translates to: > type instance F a b | a ~ b = a > type instance F a b | a ~ Int, a /~ b = b > type instance F a b | b ~ Bool, a /~ Int, a /~ b = a (Each instance after the first has disequality guards to negate the earlier instances' equalities., i.e. the earlier instances 'shadow' the overlap.) > It's currently unclear to me how to do this > right. ... > Assuming we have a primitive type-level equality test (?~), returning type-level Bool; we can use helper functions. The first instance desugars to a call > ... = F_a_b_Eq (a ?~ b) a b > type instance F_a_b_Eq True a b = a (Needs UndecidableInstances.) > Section 5.13.2 of my thesis dwells on this, without > much in the way of a concrete way forward.) We use type equality testing all the time. In fact instance selection relies on it. 5.13.2 says: "they [equality testing rules] cannot handle the case where Equals a a reduces to True, where a is locally bound type variable." ?? I thought GHC's equality test requires types to be grounded, i.e. not merely type vars, in order to be judged equal. Or did that change recently? Isn't that to do with impredicativity and the dreaded monomorphism: the same typevar might get a different forall-qualified type in different use sites. Contrast types can be judged dis-equal without necessarily being grounded. [HList paper section 9 refers.] AntC

3 3

parallel package, rts ROOT vs WEAK policy and reachable sparks
by Ruben Astudillo 18 May '17

18 May '17

Dear list This mail is long, but only the 3 last paragraphs are questions, the rest is context. Recently started reading the history of the parallel package. On the changelog of version 2.2 says (I quote) "This module has been rewritten in version 2. The main change is to the 'Strategy a' type synonym, which was previously a -> Done and is now a -> Eval a. This change helps to fix the space leak described in "Runtime Support for Multicore Haskell". The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This is why we must return a "new" value after applying a Strategy, so that the application can evaluate each spark created by the Strategy." I know where are currently on version 3.3. Yet I decided to research a little more on the paper cited. On it is discussed the issue of policy for when to GC sparks. Around page 7 of the paper (I quote) ROOT: Treat (non-fizzled) sparks as roots for the garbage col- lector. That is, retain all such sparks and the graph they point to. WEAK: Only retain (non-fizzled) sparks that are reachable from the roots of the program. The problem is, neither of these policies is satisfactory. WEAK seems attractive, because it lets us discard sparks that are no longer required by the program. However, the WEAK policy is completely incompatible with strategies. Consider the parList strategy: parList :: Strategy a -> Strategy [a] parList strat [] = done parList strat (x:xs) = strat x ‘par‘ parList strat xs Each spark generated by parList is a thunk for the expression “ strat x ”; this thunk is not shared, since it is created uniquely for the purposes of creating the spark, and hence can never fizzle. Hence, the WEAK policy will discard all sparks created by parList , which is obviously undesirable(*). Question 1: Under WEAK policy, On (*) I understand the sparks cannot be fizzle'd, but how are the parList spark not reachable from the roots of the program? surely this function doesn't exist on its own. Somewhere in the program I must be a function that is executed that has an let val = ... `using` parList ... in ... val ... which would make the sparks reachable. Making it a *good* policy to have IMHO. This probably has to do with my understanding of reachable sparks. Question 2: The ROOT policy is discuted to be better, because it supports parList (and old parallel library versions). Yet, the old docs of parallel recomend to that "if you are gonna spark, make sure you use the result to avoid space leaks" ie filter you data before and only spark on that. Is this intuition correct? Question 3: What is the current situation of this? have weak pointers helped in this regard? -- Ruben

2 1

Happy Parsers and constraints
by Alan & Kim Zimmerman 18 May '17

18 May '17

Hi all If I have a happy parser for an AST that is polymorphic, is there any way to put constraints on the individual rules? e.g. if I have data Foo a = Foo String a and a rule something like foo :: { (Show a) => Foo a } foo : otherrule { Foo (show $1) $1 } Because of the way the tables are constructed in happy, the Show constraint is not attached to the point where the rule RHS is applied. Is this simply impossible? Alan

1 0

Digital Asset is hiring Haskell programmers in NYC
by Francesco Mazzoli 18 May '17

18 May '17

TL;DR: We are hiring Haskell programmers in New York City. Feel free to talk to me about it at the NYC Compose conference, if you are around. My badge reads "Francesco Mazzoli" :). Or send me an email at <francesco.mazzoli(a)digitalasset.com>. Digital Asset is a FinTech startup developing distributed ledger technology. Functional programming, and in particular Haskell, play a major role in our tech stack, specifically in the implementation of our smart contract language, DAML. DAML is a functional, typed, total programming language implementing a very general way to formally encode contracts. The designers of DAML all come from the Haskell community, with several members having a history of research in functional programming languages. Thus, we care deeply about principled solutions and formal methods. The team is currently based in Zurich and Sydney, and we're looking to expand to New York City, where the company headquarters are located. The job is on-site in Manhattan. The open role focuses on the development of the tooling supporting DAML, which is written in Haskell. The role can also involve development of production- related components operated by our customers, which are written in Scala. You can find a more corporate job posting here <https://boards.greenhouse.io/digitalasset/jobs/493155#.WR2lfBOGOHo>, although it does not reflect precisely the nature of this role. You can also find a more corporate article about DAML here <https://digitalasset.com/press/introducing-daml.html>. If you're at the NYC Compose conference, then feel free to talk to me (Francesco Mazzoli) about this job posting or about anything else you like. Thanks, Francesco -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

1 0

Why is GHCi so hard to kill?
by Jeremy Henty 18 May '17

18 May '17

If I put ghci into a loop by entering "last $ repeat ()" then the process is impossible to interrupt or kill except with "kill -KILL". (Although it can be stopped with Ctrl-Z.) "kill -TERM" does not work. The same is true if I run a runhaskell script containing "main = putStrLn $ show $ last $ repeat $ ()". Is there a reason for ghci being so unkillable? It is generally considered a bad idea for a program to ignore the TERM signal. (Details: Debian Linux Jessie 8.8, GHC 8.0.2 (built from source).) Regards, Jeremy Henty

3 2

matrix package maintenance
by Daniel Díaz Casanueva 17 May '17

17 May '17

Hallo Haskell-Cafe! I am the author and maintainer of the matrix package: http://hackage.haskell.org/package/matrix https://github.com/Daniel-Diaz/matrix For several reasons, mostly time related, I can't give this package the attention it deserves. GitHub issues are not being properly taken care of, and development stopped long time ago. Instead of leaving the package in this state, I thought about giving maintenance powers to anybody interested in continuing this work, or even change its direction in any (reasonable) way. I know the package has some users, so maybe any of you wants to do it. Otherwise, I guess I should try to allocate some time to at least fix some of the issues posted in GitHub. Meanwhile, sorry for the long waiting time that I have imposed on the users of this package that have reported problems or submitted PRs. King regards, Daniel Díaz.

3 2

Type Instance Partiality [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 17 May '17

17 May '17

> On Mon May 15 16:20:09 UTC 2017, Richard Eisenberg wrote: > ... > See my recent draft paper (expanding on the "What are type families" blog post) here: > http://cs.brynmawr.edu/~rae/papers/2017/partiality/partiality.pdf .. > it's really proposing dropping type families in favor of functional dependencies > -- but only for partial type families. ... Thanks for the paper - hard going for me! Yes I can see the sense in grounding type family instances with class instances as Associated Types. I'm not finding it helpful to bring in Functional Dependencies. Your paper only mentions them towards the end [Related Work]; it might be "inspired by" FunDeps, but they don't appear in the paper as such. I'm also not finding it helpful to bring in Instance Chains [despite Garrett's involvement]. There's one major attractive feature of Instance Chains that you kinda mention ["negations" in Related Work], but which closed classes can't support. I see this as a major weakness of your proposal. > The key observation is this: partiality in types is bizarre, and we don't want it. ... Huh? Nearly all type families (and class instances) are partial. You perhaps mean "don't want it" as purist type-theoreticians(?) As a developer of applications I definitely do want it: I want to write instances only for 'sensible' patterns, and have the compiler catch usages not supported by declared instances. Your examples include many from HList: all of those are partial. I mean there's instances (eliding some details): > instance HOccurs e (HCons e l') -- found the element > instance (HOccurs e l') -- search the tail > => HOccurs e (HCons e' l') -- not this element There's deliberately not: > -- instance HOccurs e HNil -- Fail: not found Let alone: > -- instance HOccurs e (Maybe a) -- not an HList! Even if we rewrite to DataKinds, GHC has no knowledge that there's a closed set of type constructors. The only type family that usually is total is the type equality test (yielding a type-level Boolean), and your Introduction tells me that's problematic. sheesh > So, any time we use a partial type family, > you need to have a class constraint around. > The class constraint ensures that we evaluate the type family > only within its defined domain. OK. Good. > Now tied to classes, partial type families are more like > convenient syntax for functional dependencies. You perhaps mean the effect achieved by declaring > class (F a b ~ c) => C a b c where ... constraints with Type Families on a class context? OK yes that achieves the effect of FunDeps. And it's more convenient syntax. > There is also treatment of partial closed type families > via a new construct, closed classes > (somewhat like instance chains but weaker). As you predicted, I dislike closed classes even more than closed families. Let me explain what feature of Instance Chains you've left out. [Section 3.1.2 "Explicit Failure" of the 2010 paper] Sometimes I deliberately want there to be no instance for some specific pattern. I typically can't achieve that with Overlapping Instances. So: * Instance Chains have an explicit `Fail` case. [good] * HList has an instance with a Fail constraint. [clumsy] (I.e. an instance constraint to a class with no instance. See HOccursNot with class Fail in the HList paper section 6 at "Static look-up") * Type family instances (currently) don't have constraints, so this is hard work to arrange. IOW what's going on is _deliberately_ a partial type function. > > I expect AntC would prefer disequality guards over closed classes. Yes. Because I can 'precision control' which instances are available. Take HOccursNot (validates an HList to make sure some element does not occur, typically in combo with making sure the list has exactly one occurrence): > class HOccursNot e l -- no methods! use for constraint only > instance HOccursNot e HNil > -- instance omitted, see below > instance (HOccursNot e l') > => HOccursNot e (HCons e' l') | e /~ e' -- guarded Without disequality guards, the HList paper has to insert a bogus overlapping instance for a matched element type: > instance (Fail (TypeFound e)) => HOccursNot a (HCons e l') > ... The big problem with branched instances is that it was > awkward to describe the overlap between two branched instances. > AntC might argue that, if we just had disequality guards, > it would all be much simpler. He might be right. This is an important point; we must be careful. The rule for instances with guards is: no overlaps! (That is, after taking guards into account.) That is how "to describe the overlap between two branched instances": there is no overlap. The heads might overlap, but the guards force them apart. Any sort of attempt to control overlap can be stymied by imports. A closed set of instances avoids that. (I would say at cost of needing to read all preceding instances to understand the conditions for a later instance.) With guards, I can attach all the conditions to the instance itself. And then compare to each other instance to validate no overlaps -- even for imports. How would I describe the semantics, within the formalism in your partiality paper? Section 6.3: "we use axioms [xi] to witness type family reductions. That is, if there is an equation `type F Int = Bool` in scope, then we have an axiom [xi] that proves `F Int ∼ Bool`." Ok for in scope > type F a | a /~ Int = Char we get an axiom: (F a ~ Char <=> a /~ Int) -- bi-implication. [Unashamedly stolen from the CHR work.] This axiom system is coherent providing there are no other equations for `F`. Note also with disequalities we get an inference rule: a /~ b, b ~ c ===> a /~ c AntC

1 0

INLINE pragmas on unexported accessor functions
by Timotej Tomandl 17 May '17

17 May '17

Hello, I have the following accessor function, which is not exported out of the module: {-# INLINE left #-} left :: forall k. (Ord k) => Node k ->Node k left NullNode = NullNode left (Node _ l _) = l just for completness the type of Node is data Node k = NullNode | Node k (Node k) (Node k) I have determined upon inspecting the Core from ddump-simpl, that the INLINE pragma makes no difference, as such I would like to ask what's the convention/rule of thumb in the case of INLINE/INLINABLE pragmas on unexported accessor functions? Timo

1 0

Well-behaved instances, guards [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 16 May '17

16 May '17

> On Tue May 16 01:26:00 UTC 2017, Anthony Clayden wrote: (Might as well write it up, while it's fresh in my mind.) >> On Mon May 15 16:20:09 UTC 2017, Richard Eisenberg wrote: >> I do have to say all this talk has made me think more >> about apartness constraints in FC, at least. >> They might be a touch simpler than the current story. >> > The trouble is that the semantics for overlap > has never been spelled out. > (Nor, I suspect the criterion for > a 'well-behaved' set of instances. > I can volunteer that for you.) A set of instances is well-behaved wrt overlap iff for each pairing of instances, one of: 1. The instances are apart. (No overlap.) 2. One of the instances is strictly more specific. (Total overlap.) IOW the two instances unify, producing a substitution; and that substitution is exactly the more specific instance. 3. Neither instance is more specific (Partial overlap.) IOW the two instances unify, producing a substitution; and that substitution is more specific than either. And 3b. There is a third instance at exactly that substitution. So each instance becomes case 2 overlapping that third. Example: > class C a b > instance C Int b -- (A) > instance C Char b -- (B) apart from (A), case 1 > instance C Int Int -- (C) more specific than (A), case 2 > instance C a Bool -- (D) partial overlap to (A), case 3 > instance C Int Bool -- (E) intersect of (A), (D), case 3a > instance C Char Bool -- (E') 'cos (D) also overlaps (B) For a compiler to police case 3b is too hard: * It needs search for a suitable intersecting instance, so can't be validated instance-by-instance. * That intersect might be in a different module, so works against separate compilation. * That intersect (if it's declared), might itself not be well-behaved. * That intersect might not be needed. (Perhaps there's no call needing `C Int Bool`.) so it would be superfluous to declare it. (For this reason GHC doesn't look for such an instance until/unless it finds a use site.) * For the intersect, perhaps the needed definition is the same as one of the other instances. Say, `C Int Bool` defined same as `C Int b`, but different to `C a Bool`. There's no way to express that: you must repeat the code. These difficulties are somewhat relaxed for type families (not class instances): If the unifying substitution yields equal rhs's for the two equations, the instances are accepted. Example > type instance F Int b = b > type instance F a Int = a Overlap at `F Int Int`. Under either equation the result is `Int`, so this is accepted. I suspect that even with a total overlap, case 2; when GHC is trying to select the instance, it's in a state of nervous cluelessness as to the grounds/evidence for why to select an instance. Particularly if it is to reject the more specific instance: Is it sure some use site can never unify more specifically? This must be particularly hard for repeated type vars (non-linear patterns in the instance head). > instance C Bool (a, a) -- vs > instance C Bool (a, b) How do instance guards help? They eliminate the need to search for case 3a. A set of (possibly guarded) instances is well-behaved wrt overlap iff for each pairing of instances, one of: 1. They are apart. (No overlap.) 4. They overlap, so unify producing a substitution; And 4b. Under that substitution into the guards, the guards force the instances apart. Note no need to consider any other instances. Furthermore we can validate looking purely at the instance decls (including guards), we don't need to delay to possibly ambiguous uses. Re-work instances (A) to (E) above: > instance C Int b | b /~ Int -- (A) guard to de-overlap (C) > instance C Char b -- (B) apart, no need for guards > instance C Int Int -- (C) most specific, no guards > instance C a Bool | a /~ Int, -- (D) de-overlap (A) > a /~ Char -- also de-overlap (B) > -- instance C Int Bool -- (E) not needed, treat as (A) > -- instance C Char Bool -- (E') not needed, treat as (B) Show how the guards for (D) force it apart from (A): The instance heads unify to `C Int Bool`. Substitute {a ~ Int, b ~ Bool} into the guards. For (A) we get (Bool /~ Int) ==> True. For (D) we get (Int /~ Int, Int /~ Char) ==> False. So one guard (at least) is False. They're apart. The guards also drive the grounds/evidence for resolving overlapping heads. Suppose a use site wants `C Char Bool`. There's two eligible heads: (B), (D). Substitute wanted {a ~ Char, b ~ Bool} into the guards. None for (B). For (D) (a /~ Int, a /~ Char) ==> False. So select (B). And to take the repeated type var example. Declare: > instance C Bool (a, b) | a ~ b -- (F) > instance C Bool (a, b) | a /~ b -- (G) Suppose a use site wants ` C Bool (Int, b')`. That is, b' is a unification variable, not yet resolved. Substitute {a ~ Int, b ~ b'} into the guards. We have (F) (Int ~ b'); (G) (Int /~ b') Neither True; neither False. They do tell us we must improve b', to resolve the selection. Instance guards are to apply just as much for type instances. (So they can be distributed at associated types.) Example > type instance F Int b = b > type instance F a Bool | a /~ Int = a Rules for guards: a) The guards are a comma-sep list of equal (~) or apart (/~) comparisons. b) The comparands must be same-kinded. (I'll leave the poly kinded case for Richard ;-) c) Can only use type vars from the head. (I.e. not introduce extra vars, which contexts can do.) d) No type functions -- too hard, and not injective. e) Can use wildcard `_` as a type place-holder. f) Can use Type constructors to arbitrary nesting. As an example of d), the classic > type instance IsaFunction ((->) a b) = True > type instance IsaFunction c | c /~ ((->) _ _) = False Note the False case must match plain `Int` and `Maybe c'` and `Either e c'`. So putting this is valid but wouldn't be general enough: > type instance IsaFunction (c a b) | c /~ (->) = False AntC

1 0

GUI for Servant clients?
by Ivan Lazar Miljenovic 16 May '17

16 May '17

I have a project where I'm using Servant to write a server. There will be some admin tasks involved (predominantly manual account sign-up, to restrict who is allowed to access it), and it will be much easier for the actual administrators to do so with a visual interface of some kind (because I somehow don't see them being able to use curl ;-) Whilst I could try and integrate web pages for the admin tasks into the server, from a separation of concerns and security pen-testing point of view, it would be preferable to instead expose the admin tasks as authenticated endpoints and use a client for that. Is there anything close to having a relatively automated solution to "here is the Servant API types, here is the workflow it should follow, now give me some webpages" (which I could preferably either package up using threepenny-gui, Electron or just a few HTML files I can email to the project admins - who all run Windows - to use)? It doesn't have to look pretty, just work. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

2 1

Position of a constraint in a function's signature
by Al Zohali 16 May '17

16 May '17

Dear Cafe! I've encountered quite strange behaviour in GHC (v8.0.2) and I would like to ask you to give me a hint. Suppose we have the following functions: ---- foo :: (Show a) => Int -> a -> [String] foo n = replicate n . show bar :: Int -> (Show a) => a -> [String] bar n = replicate n . show baz :: Int -> a -> (Show a) => [String] baz n = replicate n . show ---- This won't compile, and that is ok. But if we add `RankNTypes` extension, this will compile and (:t) will give us the same signature for all three functions. There are two things I cannot get: 1) Why do this even compile? I saw constraints being defined either in the beginning of a signature or right after `forall` expression. I thought that it was a rule (or convention), but it's not. Is this way of declaring constraints (in the middle of a signature) discouraged or can be considered as a bug? 2) Even if this was supposed to be so, why was the constraint in `baz` hoisted to the top? There are at least two ways to interpret that signature: ---- baz :: Int -> a -> forall a. (Show a) => [String] baz :: forall a. (Show a) => Int -> a -> [String] ---- Is there any reason why the second one was chosen?

3 3

Partially applied type families
by Soham Chowdhury 15 May '17

15 May '17

Relatedly, there is a sketch of something like a "case construct" on Richard's blog, where he talks about a "type instance where" syntax that allows closed interdependent sets of family instances. Is that something that was later found to be infeasible? On Fri, May 12, 2017, 17:53 <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > Today's Topics: > > 1. Re: Fast JSON validation - reducing allocations (Arjen) > 2. Re: Fast JSON validation - reducing allocations (David Turner) > 3. Re: [ghc-proposals/cafe] Partially applied type families > (Anthony Clayden) > > > > ---------- Forwarded message ---------- > From: Arjen <arjenvanweelden(a)gmail.com> > To: David Turner <dct25-561bs(a)mythic-beasts.com>, Haskell Cafe < > haskell-cafe(a)haskell.org> > Cc: > Bcc: > Date: Fri, 12 May 2017 12:16:45 +0200 > Subject: Re: [Haskell-cafe] Fast JSON validation - reducing allocations > On Fri, 2017-05-12 at 10:48 +0100, David Turner wrote: > > On 12 May 2017 at 09:27, Arjen <arjenvanweelden(a)gmail.com> wrote: > > > Maybe this is a silly question, and please let me know why if so, > > > but: > > > > > > Has anyone thought about parallelizing it for multiple messages in > > > order to "produce garbage faster"? While reducing allocation will > > > make > > > the single validations faster, doing multiple ones might improve > > > the > > > throughput per GC ratio. This assumes that the amount of live data > > > in > > > the heap is small, making GC sort of constant time, and having > > > multiple > > > cores available. > > > > Not a silly question at all. Adding the following incantation: > > > > `using` parListChunk 100 rseq > > > > does quite happily spread things across all 4 cores on my development > > machine, and it's certainly a bit faster. To give some stats, it > > processes ~24 events between GCs rather than ~6, and collects ~2MB > > rather than ~500kB. The throughput becomes a lot less consistent, > > however, at least partly due to some bigger GC pauses along the way. > > As Ben's statistics showed, our allocation rate on one thread is > > around 4TBps, which is already stressing the GC out a bit, and > > parallelising it doesn't make that problem any easier. > > > > I know in the OP I said "we have a stream" (accidental MLK misquote) > > but in fact there are a bunch of parallel streams whose number > > exceeds the number of available cores, so we don't anticipate any > > enormous benefit from spreading the processing of any one stream > > across multiple cores: single-threaded performance is what we think > > we should be concentrating on. > > > > Cheers, > > > > David > > > Apologies for spamming, but if you want more mutator time between > garbage collections, try increasing the nursery size. I get a lot less > time in GC and also much less sync's on GC (according to -s). It seems > to reduce the execution time by a third using something -A8M or -A64M > (quite extreem). In a large program, this effect might be less. > > kind regards, Arjen > > > > > > > ---------- Forwarded message ---------- > From: David Turner <dct25-561bs(a)mythic-beasts.com> > To: Arjen <arjenvanweelden(a)gmail.com> > Cc: Haskell Cafe <haskell-cafe(a)haskell.org> > Bcc: > Date: Fri, 12 May 2017 11:24:23 +0100 > Subject: Re: [Haskell-cafe] Fast JSON validation - reducing allocations > On 12 May 2017 at 11:00, Arjen <arjenvanweelden(a)gmail.com> wrote: > >> Happy to read that you have more success than I with parListChunk. >> I expect(ed) the sparks to be cheap, so this might help if the various >> incoming streams are very unbalanced in length and/or message sizes. >> I agree that multi-processing a single stream does not make much sense >> if you already have multiple concurrent streams. >> >> Nice to see that adding on parallelism in Haskell (GHC) is that easy >> (in this case) and with a very good speed-up factor! >> >> kind regards, Arjen >> > > Ah, ok, this is strange. The production system is definitely faster with > the parallel strategy (on one stream) but my Criterion benchmarks are much > slower. I've updated the code and results on Github ( > https://github.com/DaveCTurner/json-validator) Probably not going to be > able to look at the parallel version much more, but thought you might like > a look. > > Cheers, > > > > > ---------- Forwarded message ---------- > From: Anthony Clayden <anthony_clayden(a)clear.net.nz> > To: haskell-cafe(a)haskell.org > Cc: > Bcc: > Date: Fri, 12 May 2017 22:46:45 +1200 > Subject: Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type > families > > 2 days ago Richard Eisenberg (and mniip) wrote: > > > ... > > On incremental improvements / the "half-baked" nature of > > type families: I agree completely. ... > ["half-baked" is Richard quoting mniip] > > > ... the weird place of type families in the language. > > It is my hope that Dependent Haskell will obviate > > a lot of these concerns, allowing us to deprecate > > type families as we know them > > (you would just use an ordinary function in types > > instead). > > I don't want to sidetrack the github discussion > on mniip's proposal. > https://github.com/ghc-proposals/ghc-proposals/pull/52 > > So please explain here in what way > type families are "half baked". > > The part of type families I find > hard to use and hard to reason about > is closed type families. > I'd be very happy to deprecate them, > if there was something that did overlaps better. > > >From what I can make out, though, > in Richard's Dissertation, > they can't be promoted to "ordinary functions > in types". > > If the closed equations were ordinary > functions in types, you could go: > > > type family F a b > > type instance F Int b = b > > type instance F a Bool | a /~ Int = a > > -- non-unifiability guard > > With no need for a closed sequence of choices. > > Is this the "case-like computations" > others talk about on the proposal? > > > AntC > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

2 1

eta-expansion and cost of extra thunk on ghc
by Ruben Astudillo 15 May '17

15 May '17

Dear list On a class, we recently discussed the join function for a (State s) value (we where implementation Monad passing through Functor) join :: State s (State s a) -> State s a join outstate = State $ \s0 -> let (innerstate, s1) = runState outstate s0 in runState innerstate s1 On this, we eta-expand outstate to in a sense "pattern match" on what we know about it. We were thinking on the cost of the extra wrapping we do here for this "pattern matching". Because eta-expanding is one a of the 3 primitive operations on lambda calculus, we concluded it should be free (modulo presence of seq). Is this true on ghc? -- -- Ruben

2 1

Why is Megaparsec treating these two operators differently?
by Jeffrey Brown 14 May '17

14 May '17

I used Text.Megaparsec.Expr to write a minimal (56 lines) 2-operator recursive parser. It's on github[1]. It outputs a binary tree of the following form: data AExpr = Var String | Pair AExpr AExpr deriving (Show) The operator table supplied to makeExprParser defines two operators, # and ##. ## binds after #, but both of them refer to the same function, the Pair constructor of the AExpr data type: aOperators :: [[Operator Parser AExpr]] aOperators = [ [ InfixN # symbol "#" *> pure (Pair) ] , [ InfixN # symbol "##" *> pure (Pair) ] ] The # operator works in isolation: > parseMaybe aExpr "a # b" Just (Pair (Var "a") (Var "b")) Parentheses work with the # operator: > parseMaybe aExpr "(a # b) # (c # d)" Just (Pair (Pair (Var "a") (Var "b")) -- whitespace added by hand (Pair (Var "c") (Var "d"))) And the # and ## operators work together as intended: > parseMaybe aExpr "a # b ## c # d" Just (Pair (Pair (Var "a") (Var "b")) -- whitespace added by hand (Pair (Var "c") (Var "d"))) But the ## operator in isolation does not parse! > parseMaybe aExpr "a ## b" Nothing [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/howt… -- Jeff Brown | Jeffrey Benjamin Brown Website <https://msu.edu/~brown202/> | Facebook <https://www.facebook.com/mejeff.younotjeff> | LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>(I often miss messages here) | Github <https://github.com/jeffreybenjaminbrown>

3 6

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 165, Issue 19
by Keith Ramsay 14 May '17

14 May '17

On 5/12/17, haskell-cafe-request(a)haskell.org <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Haskell IDE Engine users? (Alan & Kim Zimmerman) > 2. Fast JSON validation - reducing allocations (David Turner) > 3. Re: Fast JSON validation - reducing allocations (Bardur Arantsson) > 4. Re: Fast JSON validation - reducing allocations (David Turner) > 5. Re: Fast JSON validation - reducing allocations (Bardur Arantsson) > 6. Re: Fast JSON validation - reducing allocations (Eric Seidel) > 7. Re: Fast JSON validation - reducing allocations (Ben Gamari) > 8. Re: Fast JSON validation - reducing allocations (Ben Gamari) > 9. Re: Fast JSON validation - reducing allocations (David Turner) > 10. Re: Fast JSON validation - reducing allocations (Ben Gamari) > 11. Re: Fast JSON validation - reducing allocations (David Turner) > 12. Re: Fast JSON validation - reducing allocations (Arjen) > 13. Re: Fast JSON validation - reducing allocations (David Turner) > 14. Re: Fast JSON validation - reducing allocations (Arjen) > 15. Re: Fast JSON validation - reducing allocations (Arjen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 May 2017 16:02:17 +0200 > From: "Alan & Kim Zimmerman" <alan.zimm(a)gmail.com> > To: haskell <haskell-cafe(a)haskell.org> > Subject: [Haskell-cafe] Haskell IDE Engine users? > Message-ID: > <CANma%3DH9bVt9bY%3DPmTBy4kCrMGUVAdD1A_sWWmc96EazrkmM3Ug(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Stupid question, but is anyone using/integrating HIE into anything at the > moment? > > I am considering rearranging the internals to orient it toward being mainly > a Language Server Protocol backend , and I want to see who would be > affected. > > Alan >

1 0

natVal straight to Word#
by Timotej Tomandl 13 May '17

13 May '17

Hi, I am using type-level naturals constrained to be at max the size of Word#, as such I have found myself casting the type-level naturals first to Integer and then to Word# like this type MaxConstraint a=a<=MaxNat toNatural :: forall n. (MaxConstraint n,KnownNat n)=>Natural n toNatural = Natural (integerToWord (natVal (Proxy :: Proxy n))) where MaxNat is the hard-coded value of maxBound :: Word for now, type MaxNat=18446744073709551615 My data type and the constrained constructor for Natural are data Natural (x::Nat) where Natural :: (MaxConstraint x)=>{-# UNPACK #-} !Word# -> Natural x I have tried to eliminate the integerToWord cast from toNatural, yet I have failed at doing so. As such I would like to ask, if anyone has some insight, whether it is possible to eliminate this one step of indirection. The only option I came up with is writing GHC plugin to do this. Timo

4 3

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 13 May '17

13 May '17

> On Sat May 13 06:40:47 UTC 2017, mniip wrote3: >> On Fri, May 12, 2017 at 01:22:35PM -0400, Richard Eisenberg wrote: >> >> My interpretation of mniips use of this descriptor was .. > That is very much correct, but what I was exactly referring to was not > the necessary limitations of type families (such as inability of partial > application) but rather their unnecessary limitations. For example only > being able to pattern-match at the top-level, or, with > InjectiveTypeFamilies, lack of 'result arg1 -> arg2' type injectivity. Don't we get limited injectivity through type family calls appearing in Equality constraints? > class (F a b ~ c) => C a b c We might have: > type instance F Int b = b And a use site which gives (a ~ Int). Then we can improve via (b ~ c). >> I agree that closed type families are bizarre and perhaps a misfeature >> -- though I think they are a good incremental step toward something better. > Closed type families have proven very useful to me, ... Thanks mniip. Yes useful to me too. (As a major user of HList-alikes.) > so I don't agree with calling them a misfeature, ... I think there were plenty of people suggesting other ways to achieve the same end. If "something better" comes out of the experience, we've lost 7~8 years of opportunity. > however I can see where you're coming from : > throughout the entire language we enforce the notion that we > can't have a "proof of type inequality" and then > closed type families give us just that. I don't like calling it "type inequality". It's proof of non-unifiability. And the rules for that are easy to write down. (Admittedly a bit messy to apply in practice.) The key fact is that Oleg et al demonstrated how it worked way back in 2004. And it works in Hugs! I don't see what's so hard. > Indeed, their semantics could be made more apparent. Disequality guards make it blimmin obvious. As described in Sulzmann & Stuckey 2002. AntC

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 13 May '17

13 May '17

> On Fri May 12 17:22:35 UTC 2017, Richard Eisenberg wrote: > > > On May 12, 2017, at 6:46 AM, Anthony Clayden wrote: > > So please explain here in what way > > type families are "half baked". > > My interpretation of mniip's use of this descriptor was > a reference to the fact that type families aren't just > functions, don't support `case`, ... ?? But the instance mechanism is in effect case; only considerably more powerful: > I agree that closed type families are bizarre and perhaps > a misfeature -- though I think they are a good incremental > step toward something better. What would be far better is > if we could just use `case`, and then the closed type > family syntax would desugar into case statements, much > like how normal functions work. So > > type family F a b where > F Int b = b > F a Bool = a > > (AntC's example) would really mean > > type F a b = case a of > Int -> b > _ -> case b of > Bool -> a > _ -> F a b > But this is terrible for type improvement!: It insists on working through the args left to right. And through the equations top to bottom. Contrast all the good work Richard did for closed families, to 'look ahead', detect confluence of equations, and try to make progress in solving equations. As described here https://typesandkinds.wordpress.com/2013/04/29/coincident-overlap-in-type-f… and in the 2013 paper. i.e. to mimic the behaviour of stand-alone instances. > We understand the semantics of case expressions, ... At the term level yes. But that semantics is not appropriate at the type level. Type-level programming is somewhat like term level; but quite a lot different. At the term level, we never expect to 'improve' an argument from knowledge of the result. So expecting them to behave the same, or deliberately hobbling type improvement to be like term-level case expressions is just not ergonomic. What's so difficult to understand about instances? The worst mis-feature for me about closed families, is I have to put all the instances together, not alongside the corresponding class instances -- even as associated types. 'Grounding' type instances with methods, and therefore with class instances seems to be a Good Thing, according to these musings https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/ Closed families aren't extensible when I declare a new type. The part of the (class) instance mechanism that's difficult to reason about is overlaps. So the idea of the (dis)equality guards on instances -- which can apply to class or type instances -- is to remove overlaps: essentially, if the heads overlap (are unifiable), the guards must disambiguate which instance to choose. I can't introduce in a different module an instance that overlaps. AntC

1 0

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 13 May '17

13 May '17

> 2 days ago Richard Eisenberg (and mniip) wrote: > ... > On incremental improvements / the "half-baked" nature of > type families: I agree completely. ... ["half-baked" is Richard quoting mniip] > ... the weird place of type families in the language. > It is my hope that Dependent Haskell will obviate > a lot of these concerns, allowing us to deprecate > type families as we know them > (you would just use an ordinary function in types > instead). I don't want to sidetrack the github discussion on mniip's proposal. https://github.com/ghc-proposals/ghc-proposals/pull/52 So please explain here in what way type families are "half baked". The part of type families I find hard to use and hard to reason about is closed type families. I'd be very happy to deprecate them, if there was something that did overlaps better. >From what I can make out, though, in Richard's Dissertation, they can't be promoted to "ordinary functions in types". If the closed equations were ordinary functions in types, you could go: > type family F a b > type instance F Int b = b > type instance F a Bool | a /~ Int = a > -- non-unifiability guard With no need for a closed sequence of choices. Is this the "case-like computations" others talk about on the proposal? AntC

3 2

Re: [Haskell-cafe] Fast JSON validation - reducing allocations
by Ben Gamari 12 May '17

12 May '17

David Turner <dave.c.turner(a)gmail.com> writes: > Ben, Eric, thanks for your help. A whole new world of low-level statistics > opens up before me... > No worries! > You're not wrong. > > I've trawled through the STG as best as I can for a newbie. The function > with a large number in the 'Alloc' column looks pretty much to be the heart > of the `step` function. There's a lot of nesting but it looks largely to be > just checking the bounds on array indices, which I don't think allocates > anything. > Something that I should have mentioned earlier is that STG has the nice property that all allocation is syntactically obvious: allocated closures manifest as `let`s. This makes it fairly easy to pick out possible allocation sites, even in large dumps. > However I see this this little snippet at the very bottom of the nesting: > > case > indexArray# [ds1_sl1b > y2_sl5H] > of > _ [Occ=Dead] > { (##) ipv8_sl60 [Occ=Once!] -> > case > ipv8_sl60 > of > _ [Occ=Dead] > { GHC.Word.W8# dt6_sl62 [Occ=Once] -> > case > ss_sl5v > of > dt7_sl63 > { __DEFAULT -> > (#,,#) [__word 1 > dt6_sl62 > dt7_sl63]; > }; > }; > }; > > > I'm guessing that the `indexArray` call is the line that reads `nextState = > aTransitionsTable makeAutomaton AU.! (currentState, nextByte)`, and to me > it looks like it might be unboxing the thing it's getting out of the array. > Not sure that counts as an allocation, but I'm surprised anyway. > The unboxing should just involve looking at the value field of the W8# closure (e.g. a memory dereference) and putting the value in a machine register. There is no allocation here as far as I can see. > I'll keep digging anyway, but it'd be good to hear of any progress at your > end too. Hope it didn't spoil your lunch! Far from it! It was nice to have a puzzle to ponder. Cheers, - Ben

4 10

Re: [Haskell-cafe] Fast JSON validation - reducing allocations
by David Turner 11 May '17

11 May '17

Ben, Eric, thanks for your help. A whole new world of low-level statistics opens up before me... On 11 May 2017 at 18:57, Ben Gamari <ben(a)smart-cactus.org> wrote: > Eric Seidel <eric(a)seidel.io> writes: > > > On Thu, May 11, 2017, at 09:12, David Turner wrote: > >> Could anyone help, e.g. by pointing me at the bit in the Core that is > >> allocating within the main loop? > > > > GHC has a -ticky flag that tracks precisely where allocations are > > happening. It's quite low level (you may have to stare at the STG in > > addition to the Core to interpret the results) but I've found it > > incredibly useful when trying to understand performance swings in GHC's > > own benchmarks. > > > > https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky > > > > You can enable it per module, which is nice break from the > > rebuild-the-world -prof, but the flip side IIRC is that if the > > allocations are happening in a module that wasn't compiled with -ticky > > (e.g. somewhere inside Data.Array) you might not see them. > > Indeed, -ticky is wonderful for this sort of thing since it doesn't > affect Core-to-Core optimization, meaning that the instrumented program > will behave very similarly to the uninstrumented version (just a bit > slower due to counter overhead). > > I had a quick look at your example over lunch. I started like this > (after commenting out the aeson benchmark in Main), > > $ ghc app/Main.hs -isrc -O2 -ddump-stg -fforce-recomp \ > -ddump-to-file -dsuppress-idinfo -ddump-simpl -rtsopts \ > -ticky -ticky-allocd > $ app/Main +RTS -rticky.out Ok, I was just about to ask about the Alloc'd column as mine was all zeroes, but the -ticky-allocd was what I needed, thanks. > The table suggests a few nice starting points: $w$j1_slJT is allocated > quite a bit, probably by $wgo7_slHA. Next we can turn to the STG output > (src/Automaton.dump-stg) to try to understand why this is. Reading STG > generally tends to be quite hard due to the rather large, deeply nested > trees that most programs compile to. You're not wrong. I've trawled through the STG as best as I can for a newbie. The function with a large number in the 'Alloc' column looks pretty much to be the heart of the `step` function. There's a lot of nesting but it looks largely to be just checking the bounds on array indices, which I don't think allocates anything. However I see this this little snippet at the very bottom of the nesting: case indexArray# [ds1_sl1b y2_sl5H] of _ [Occ=Dead] { (##) ipv8_sl60 [Occ=Once!] -> case ipv8_sl60 of _ [Occ=Dead] { GHC.Word.W8# dt6_sl62 [Occ=Once] -> case ss_sl5v of dt7_sl63 { __DEFAULT -> (#,,#) [__word 1 dt6_sl62 dt7_sl63]; }; }; }; I'm guessing that the `indexArray` call is the line that reads `nextState = aTransitionsTable makeAutomaton AU.! (currentState, nextByte)`, and to me it looks like it might be unboxing the thing it's getting out of the array. Not sure that counts as an allocation, but I'm surprised anyway. I'll keep digging anyway, but it'd be good to hear of any progress at your end too. Hope it didn't spoil your lunch! Cheers, > While turning this over in my head I realized that this is the sort of > program which may be helped significantly by GHC 8.2's improved join > point handling. Indeed the timings seem to support this hypothesis: > > GHC 8.0.2 > > benchmarking json-validator/Automaton/testEvent > time 22.84 μs (22.76 μs .. 22.94 μs) > 1.000 R² (1.000 R² .. 1.000 R²) > mean 22.84 μs (22.76 μs .. 22.94 μs) > std dev 297.4 ns (221.8 ns .. 378.8 ns) > > Alloc rate 4,015,256,078,038 bytes per MUT second > > GHC 8.2 > > benchmarking json-validator/Automaton/testEvent > time 9.221 μs (9.141 μs .. 9.318 μs) > 0.998 R² (0.996 R² .. 1.000 R²) > mean 9.163 μs (9.084 μs .. 9.356 μs) > std dev 399.8 ns (193.0 ns .. 745.4 ns) > variance introduced by outliers: 54% (severely inflated) > > Alloc rate 123,141,635 bytes per MUT second > > > Wow! I suspect your allocations have now vanished. Ooo, that's more like it. Could you run again using the following to get Criterion's estimate of the allocations-per-call? json-validator-exe --regress allocated:iters +RTS -T Cheers, David On 11 May 2017 at 19:45, David Turner <dave.c.turner(a)gmail.com> wrote: > On 11 May 2017 at 19:40, Ben Gamari <ben(a)smart-cactus.org> wrote: > >> Ccing Luke Maurer under the assumption that he will appreciate seeing >> the fruits of his labor. >> >> >> David Turner <dct25-561bs(a)mythic-beasts.com> writes: >> >> > Dear Café, >> > >> (snip) >> > >> > There's a copy of the relevant code for option 4 at >> > https://github.com/DaveCTurner/json-validator. I've hacked around with >> it a >> > bit since producing the numbers above, so it's now apparently a bit >> slower >> > than Aeson but allocates less too (~65kB). >> > >> > Could anyone help, e.g. by pointing me at the bit in the Core that is >> > allocating within the main loop? >> > >> While turning this over in my head I realized that this is the sort of >> program which may be helped significantly by GHC 8.2's improved join >> point handling. Indeed the timings seem to support this hypothesis: >> >> GHC 8.0.2 >> >> benchmarking json-validator/Automaton/testEvent >> time 22.84 μs (22.76 μs .. 22.94 μs) >> 1.000 R² (1.000 R² .. 1.000 R²) >> mean 22.84 μs (22.76 μs .. 22.94 μs) >> std dev 297.4 ns (221.8 ns .. 378.8 ns) >> >> Alloc rate 4,015,256,078,038 bytes per MUT second >> >> GHC 8.2 >> >> benchmarking json-validator/Automaton/testEvent >> time 9.221 μs (9.141 μs .. 9.318 μs) >> 0.998 R² (0.996 R² .. 1.000 R²) >> mean 9.163 μs (9.084 μs .. 9.356 μs) >> std dev 399.8 ns (193.0 ns .. 745.4 ns) >> variance introduced by outliers: 54% (severely inflated) >> >> Alloc rate 123,141,635 bytes per MUT second >> >> >> Wow! I suspect your allocations have now vanished. >> > > > Ooo, that's more like it. > > Could you run again using the following to get Criterion's estimate of the > allocations-per-call? > > json-validator-exe --regress allocated:iters +RTS -T > > Cheers, > > David > >

1 0

Fast JSON validation - reducing allocations
by David Turner 11 May '17

11 May '17

Dear Café, We have a stream of ~900byte JSON documents (lazy ByteStrings) that we would like to validate (NB not parse) as quickly as possible. We just need to check that the bytes are a syntactically valid JSON document and then pass them elsewhere; we do not care what the content is. The documents are encoded in UTF-8 and have no extraneous whitespace. We have made a number of attempts: 1. Use Aeson to parse the documents and then discard the result. This was actually pretty good: Criterion clocked it at ~30us per document. 2. A hand-written Attoparsec parser. This did quite a bit worse: ~70us per document. 3. Use Get (from the binary package), which was a bit messier as it was factored to avoid all backtracking, but managed to get down to around ~20us per document. 4. Build a table-based, Word8-labelled DFA (with a minor hack to deal with values-within-values) and run it with ByteString.Lazy.foldl'. Also around ~20us per document. We didn't pursue the Attoparsec idea any further, but the other three all allocate ~85kB per document, and this now seems to be the limiting factor for performance. In more detail, looking at the threadscope output, we see it parse 5 or 6 documents in ~150us (allocating ~500kB) and then run the GC, which takes about another 150us. The GC stats indicate that it's only copying a couple of kB of live data each time, so most of that 500kB is junk. Now 85kB per document is ~96B per byte, which is only a pointer-and-a-half. It's not entirely surprising that there's this much allocation going on each time round the loop, but we'd like to try and get rid of it. I've tried the usual strictness tricks and have peered in a mystified fashion at the output of -ddump-simpl but am none the wiser. There's a copy of the relevant code for option 4 at https://github.com/DaveCTurner/json-validator. I've hacked around with it a bit since producing the numbers above, so it's now apparently a bit slower than Aeson but allocates less too (~65kB). Could anyone help, e.g. by pointing me at the bit in the Core that is allocating within the main loop? Many thanks, David

4 6

Haskell IDE Engine users?
by Alan & Kim Zimmerman 11 May '17

11 May '17

Stupid question, but is anyone using/integrating HIE into anything at the moment? I am considering rearranging the internals to orient it toward being mainly a Language Server Protocol backend , and I want to see who would be affected. Alan

1 0

Constraining constraints
by Clinton Mead 11 May '17

11 May '17

I posted the following on stackoverflow <http://stackoverflow.com/questions/43827374/what-is-a-can-be-derived-from-c…>, but it hasn't got too much attention so I thought I'd ask here: I can write the following: {-# LANGUAGE RankNTypes #-}{-# LANGUAGE FlexibleInstances #-}{-# LANGUAGE UndecidableInstances #-}{-# LANGUAGE ConstraintKinds #-} f :: Integral a => (forall b. Num b => b) -> a f = id And all is good. Presumably GHC can derive Integral from Num so all is well. I can be a bit tricker, yet I'm still fine: class Integral x => MyIntegral xinstance Integral x => MyIntegral x class Num x => MyNum xinstance Num x => MyNum x f' :: MyIntegral a => (forall b. MyNum b => b) -> a f' = id So lets say I want to generalise this, like so: g :: c2 a => (forall b. c1 b => b) -> a g = id Now obviously this will spit the dummy, because GHC can not derive c2 from c1, as c2 is not constrained. What do I need to add to the type signature of g to say that "you can derive c2 from c1"?

3 2

Galois is hiring
by Daniel Wagner 10 May '17

10 May '17

Here's our official announcement: > Galois is hiring! We're looking for researchers, principal investigators, software engineers, and project leads, including those with expertise in functional programming, formal methods, machine learning, embedded systems, computer security, or networking. We have offices in Arlington VA, Dayton OH, and Portland OR with positions available at all locations. For more info or to submit your resume, please see our website: http://galois.com/careers <http://galois.com/careers>. Here's a few things I like about Galois [1]: * Deep technical problems. I've been involved in projects to develop a prototype voting system that gives cryptographic guarantees of privacy and correctness; to get a line of mobile phones' crypto subsystems certified; to build a tool for doing asynchronous hardware design; and to obfuscate programs in a cryptographically strong way. Every day in the break room I hear about projects my coworkers are in that are as exciting or more in terms of technical depth. * Flexibility. For example, I like variety, so I've joined up with several projects even in my short stay here, working for a few months on each; but other people like stability and prefer working full-time on a single project for long periods, and both modes are well-supported. You also get quite a lot of say over what projects you'll be working on; what you'll be doing on a given project; what technologies are most appropriate for that project's goals (I've used Haskell in some way in almost every project so far... I might be biased here); even where you get your work done on any given day (Need to work from home because there's ice on the roads, or because the cable guy said they'd be there "somewhere between 10 and midnight", or just because you want to head to a coffee shop for the ambience for the day? No problem!). * Training. Everybody here is a world-class expert, and I feel like I've learned a ton just by overhearing lunch conversations. The company also goes out of its way to support structured training. I was a complete crypto noob prior to joining, but they let me spend company time on a Coursera course so that I can at least see the blood after I've shot my own foot. Each year I've been here, everyone has also been given a week for "innovation time" that need not be spent on anything directly funded from outside; many folks spend this time getting acquainted with a new technology (or inventing one!). * Location. Portland is a medium-sized city -- just large enough to have one of everything. The weather goes a little below freezing for a few days each year and a little above body temperature for a few days each year -- which is a small price to pay for the temperate weather we get the rest of the time. Walking distance from the building we're in covers a lot of ground. If those things sound exciting to you, check out our openings at http://galois.com/careers. ~d [1] Cross-posted from reddit; apologies if this looks familiar! We're still actively looking for talented folks. https://www.reddit.com/r/haskell/comments/5r3vhz/galois_is_hiring/

1 0

Looking for (possibly temporary) maintainers
by Julian K. Arni 10 May '17

10 May '17

Hi cafe! I'm going to be away from the internet from late May till early September, so I'm trying to ensure that all my packages have someone who could be responsible for them in the meantime. Minimally, this would involve reviewing new PRs and making releases with them, but you'd be free to take on a more active role too. If you want to continue being a maintainer after that, you'd be very welcome, but I do intend to help. Most of the packages already have other maintainers, but these don't: - bookkeeper (https://github.com/turingjump/bookkeeper) - extensible records library - verdict (https://github.com/jkarni/verdict) - refinement-type-like opaque types - servant-quickcheck (https://github.com/haskell-servant/servant-quickcheck) - quickcheck properties of entire APIs If you're interested, send me an email! Thanks, Julian Arni

1 0

GHC cross compilation survey
by Moritz Angermann 10 May '17

10 May '17

Dear friends, as some of you might have noticed, together with obsidian.systems, I’m trying to make cross compiling GHC a bit easier. To that extend, I’d like to invite you to fill out a short survey[1], so we understand the needs of the community better. Please follow the attached link and fill out the survey! Cheers, Moritz [1]: https://medium.com/@zw3rk/hello-world-a-cross-compilation-survey-890cb95029…

1 1

Announce: Haskell Platform 8.0.2-a builds for Windows 10 Creators Update
by Gershom B 10 May '17

10 May '17

As many people know, the recent Windows 10 Creators Update broke the latest GHC 8.0.2 release. [1] We're happy to announce that there are now new 8.0.2-a builds on the Haskell Platform website that include the patch prepared by GHC HQ, and the hashes have been updated appropriately as well: https://www.haskell.org/platform/windows.html Note that this is not a new HP release in any official sense, nor are these new HP builds. These are the existing installers with the replacement of one file. Accordingly, they have new file names and hashes. However, all else remains the same. Similarly, no builds for other platforms have been updated. If you are not using Windows 10, this doesn't affect you in any way. And if you are, you probably already ran into this. Apologies for about a week of tardiness in getting this out, which is entirely due to my frazzledness. Happy Haskell Hacking all, Gershom [1] https://mail.haskell.org/pipermail/ghc-devs/2017-April/014131.html

1 0

Error using Judy arrays (was: Re: [Biohaskell] hash map/associative structure)
by Ketil Malde 09 May '17

09 May '17

On 2017-05-04 12:14 (+0200), Michał J Gajda <mjgajda(a)gmail.com> wrote: > Interesting. Do You have an error report filed anywhere to peruse? Well, I wrote the below. In the mean time, I've tried replacing "insertWith" with a manual lookup and update. This changed the cases where the segfaults happen, but didn't eliminate them. And I tried using the safe freeze function, to no avail. And I implemented some of the functionality using a Vector, which gives correct results (but without reimplementing a real hashtable, it can only be used for the histogram collection, not k-mer counting, since with large k that requires full 64-bit indexes into the vector) I've also run on several different computers, so I don't think it's a hardware error. -k ---------------------------------------- So: I have a program that indexes k-mers (fixed-size words) as Word64's, storing the different ones along with their counts in a Judy array, and at the end, writing to a file. So an associative map mapping k-word -> count. Then, the second stage re-reads this file, and builds a histogram, tallying how often each count occurs. let's call this count -> frequency For some time, this just seemed to work. But then I implemented an expectation-maximization algorithm to model the frequency distributions, and that failed to terminate in some cases. Going back, I found the following histogram to cause the trouble: ==> SRR901891_1.32.hist <== 865 809 866 775 867 757 868 781 869 725 870 778 871 795 872 774 873 771 48036128 2017612633061982208 Notice that last value? Apparently, there are 2.018e18 different k-mers with a frequency of 48036128. This is clearly not right. Notice also that the latter number is 0x01c000...000. Does this carry any special meaning? One possibility is of course some garbage in the k-mer count index, but I also have a dump command that prints the contents as text. I can find nothing wrong with that, and the highest count k-mers look like this: % sort -nr -k2 *dump* | head tgggggtccagccatggagaagagtttagaca 1670602 gggggtccagccatggagaagagtttagacac 1653146 gtctaaactcttctccatggctggacccccaa 1638158 gaatattatttgggggtccagccatggagaag 1567591 ggaatattatttgggggtccagccatggagaa 1539378 actagtgcttaggaaatctattggaggcagaa 1532596 gcttctgcctccaatagatttcctaagcacta 1531091 aggaatattatttgggggtccagccatggaga 1528806 ctagtgcttaggaaatctattggaggcagaag 1527682 aaaggaatattatttgggggtccagccatgga 1518392 One thing to look into is how the histogram is built. I have wrapped this in a function (mk_judy, code below) that returns a struct of operations, called FreqCount. mk_judy takes as an argument the number of bits to use in the index - but this isn't really used for anything (JudyL is JudyL). Yet, when I changed this parameter from 16 to 32, the last line changed to: 17180896 2017612633061982208 And with 64: 37271776 2017612633061982208 The latter number is always the same, the former ends with 0x8e0, but appears to vary in the most significant bits. Everything else is the same in the histograms, I did a diff on the outputs. -- Code ---------------------------------------- mk_judy :: Int -> IO FreqCount mk_judy l = do j <- J.new :: IO (J.JudyL Int) let ac k = k `seq` J.insertWith (+) k 1 j gc k = k `seq` fromMaybe 0 `fmap` J.lookup k j sc k v = J.insert k v j es = J.unsafeFreeze j >>= J.elems ks = J.unsafeFreeze j >>= J.keys as = J.unsafeFreeze j >>= J.toList return $ FreqCount { key_bits = l , add_count = ac, get_count = gc, set_count = sc , keys = ks, counts = es, assocs = as } -- Code ---------------------------------------- If we're sure there is nothing wrong with the Judy library, the only other thing I can think of is the unsafeFreeze. I'm pretty sure I don't modify the Judy array after accessing it through the "frozen" functions - but could it e.g. be the case that j is frozen with some operations still unevaluated? I tried adding "j `seq`" before unsafeFreeze, and got: 33769696 2017612633061982208 Again, 0x...8e0 and the usual 0x01c0... Anyway, that's where it stands at the moment. I'm not sure what to do, it does worry me that this counting seems to fail on occasion. Note also that the histogram gets truncated (always at the same place, after 873), and it should really go up to 1.5 million. ---------------------------------------- -- If I haven't seen further, it is by standing in the footprints of giants

2 1